From 5598714182870077854 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,305abf126cd51bfd,start X-Google-Attributes: gidf78e5,public From: Craig Perras Subject: implementing persistence with std library Date: 1997/07/28 Message-ID: #1/1 X-Deja-AN: 259855751 X-Original-Date: Sun, 27 Jul 1997 21:24:04 -0700 Organization: Wolfe Internet Access, L.L.C. X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBM9zbC0y4NqrwXLNJAQFNVwIAssu7oERnrlnD5vqbGBS+9Pil+4MPoaLK 8uzz5RBtjU5Nm+5Zfc9u9U2TAU2udOsjAQ9a1EkNqO0V8iVlycsEkQ== =H/8V Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com i am trying to implement a simplistic persistence scheme for standard library components. i have therefore created a PAlloc (persistent allocator) type, designed to be used with STL containers. i would like to make persistence the property of objects, not classes. the only way i can think of doing this is to parameterize all classes which use STL components with class ALLOC. for instance, if i have an Invoice class which keeps a list of Entries, i would do this if i didn't care about hard-coding persistence: class Invoice { public: ... private: list< Entry, less, PAlloc > m_entries; }; to make persistence a property of individual objects, i do this: template class Invoice { public: ... private: list< Entry, less, Alloc > m_entries; }; is this how the standard libraries were meant to be used? at first glance, this doesn't appear to be much of a hardship except for 2 things: 1 - std::strings are paramaterized by allocators. i use strings in nearly all my classes. 2 - i've been using SGI's STL library, where they use static functions in their allocators. this means you can't actually pass in an allocator object, but the static allocate and deallocate functions are used. however, i noticed in the standard that you pass in an allocator object. passing in an allocator object means you need to keep a reference to that object, increasing the size of all containersi (including strings!). this size increase may be unacceptable. is the SGI implementation conforming to the standard (or, more precisely, by a subset of the standard)? i think their implementation is superior - there is no space or run-time overhead. the only side-effect is you can't use run-time polymorphism. but considering it's an allocator, which presumably needs to have good performance, who would want to? any ideas or advice is greatly appreciated. --craig --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]