- Boost - lists.preview.boost.org

RE: [boost] Re: Date-Time
by Powell, Gary 20 Apr '04

20 Apr '04

Rob Stewart wrote: >From: David Abrahams <dave(a)boost-consulting.com> >> "Jeff Garland" <jeff(a)crystalclearsoftware.com> writes: >> > On Wed, 14 Apr 2004 13:04:34 +0100, Val Samko wrote >> >> >> >> Does that mean that add_month won't be implemented? What if we call >> >> it inc_month, instead of add_month? inc_month (Increase Month) >> >> in no way assumes that the day of the month will stay the same, >> >> it will just increase the month. >> > >> > Yes, perhaps a different name would help eliminate any confusion that we are >> > doing 'math' here. >> >> I think readability is more important. Nobody but pedants have >> problems with string + string. Likewise I think: >> >> d + 2*months >> >> or whatever is better than the functional-looking alternatives. >If there was universal acceptance of what it means to add two >months to a date, I might agree. Given the imprecise notion of >what it means to add two months, however, I disagree. >"next_month" or "increment_month" versus "add_month" better >distinguish the imprecision. Here I totally agree with Rob, adding months is a non-intuitive operation and calling out the precision helps the readability of the program. It makes perfect sense to do d + (30 * days) but not with Months. Yours, -Gary-

6 17

Re: [thread] again
by Christophe Meessen 20 Apr '04

20 Apr '04

Hello, regarding thread local storage we have come up with a different perspective of the problem. First we where not very happy with boost threads because it requires a copy of the functor object. This does not allow to put non copyable object as member variables of the functor object. Knowing that mutex are none copyable objects, for good reasons, one understand that this API is far too constraining. I guess such design choices was driven by the requirement that the functor object lifetime is tighlty linked to the thread lifetime. The join function is also too limited synchronization mechanism. And finally we where also not happy with the thread local storage approach. We seeked a design which was simple and could provide a satisfying solution for all these aspects and we came up with the following design. We chose the start&run model used in many thread API because it allows to initialize the thread object before it is started and collect result after the thread terminated. The thread object is the obvious place to use as thread local storage. This is because stored data is explicitely defined and its use is statically checked. It is also automatically destroyed with the thread object is destroyed. Thread objects are dynamically allocated and referenced through intrusive pointer. Thus thread objects can have none copyable member variables and getting out of scope doesn't destroy the thread object. The thread object life time is controlled through an intrusive smart pointer. When the internal thread main function start it instantiate a smart pointer on itself as local variable. Then it calls the virtual run by changing the 'this' context to the objects context. In the run method users have access to the thread object member variables and methods. When the thread main function terminate normally or because of an exception, the smart pointer is destroyed. If there is no other reference to the thread object, it is then deleted and all its local storage information with it. In the thread local storage managed by the system/pthread we only store a pointer to the thread object. This is to allow to get access to the thread object from anywhere in the code. This is equivalent of the this variable for objects but for threads. Thus the thread class has a static self() method returning a reference on the current thread object. For dynamically storage, one can add a map to the thread object. The user can pick the key and value types which are the most appropriate for his needs. The map will be automatically destroyed when the thread object is destroyed. A default thread object will be provided to support classical C function or functor calls. But the basic underlying model is to use a thread object. It also to be noted that boost thread implementation would start the thread before the boost thread object instantiation would complete. Such constrains should not be imposed to the users. There is thus a need to know when a thread has started and when it has terminated. When the start call completes, it doesn't mean the thread has already started. This is reflected by a state variable that would also specify if the thread terminated normally or was aborted because of an exception or cancelled (which should also use the exception model). Regarding synhcronization we have also made a slight move away from boost API which was aslo the best seen so far. We make a distinction between locks and latch. A lock has no method. When it is constructed it immediately attempts to lock the mutex, and the destructor release the mutex. Thus when a lock is instantiated, the mutex can be assumed to be locked by the thread who performed the instantiation on its call stack. When a latch is instantiated, the mutex is not locked. The following methods lock, unlock, try_lock and timed_lock are used to control the referenced mutex. When a latch variable is destroyed it automatically unlock the mutex if it was currently locking it. We believe there was a possible confusion in the initial lock state of boost locks. It is not orthogonal. We also beleived there was a performance penalty by not providing atomic lock object. The lock and latch are encapsulated classes of mutexes. And we would by default support two kinds of mutexes, classical pthread mutex and spin lock mutexes. Spin lock mutexes would support locks and not latch locks. spin locks would be used to serialize access to shared resources like smart pointer counters, monitoring variables etc. We also droped the "scoped_" in front of the lock class name because it is implicit, standard and shortens the name. -- Bien cordialement, Ch. Meessen

4 3

RE: [boost] date-generators (was Date-Time)
by Hurd, Matthew 20 Apr '04

20 Apr '04

> On Behalf Of Jeff Garland > Subject: Re: [boost] date-generators (was Date-Time) > > On Mon, 19 Apr 2004 14:22:53 -0400 (EDT), Rob Stewart wrote > > > > That does make sense, but so does the "date wrapper" idea. The > > latter provides a convenient means to use operator overloading > > meaningfully while making the behavior of those operators > > specific to the wrapper type. I think the date wrapper approach > > will prove easier to use, but more cumbersome to implement. > > I have no idea what the 'date wrapper approach' is... > > Jeff Some further quick thoughts from my dark past... Most places I've been, typically finance related, have had dates, date expressions, date generators and calendars as concepts. Date expressions give you the concept of the last day of the month. They can give you the third Wednesday of the month. I'm used to just strings like: 3wed+2b (3rd Wednesday + 2 business days), -1Sun+1b (Last Sunday + next business day), -1d (last day of the month). Strikes me that date expressions would look nice as expression templates. Extend this with date generators that can generate such dates for month patterns (every 3 months, explict months) within the context of a calendar. Calendars with holidays and being able to combine them for transactions is important. You can then refer to the second business day after the third Wednesday and such things. A typical use of a calendar is to have calendars for business jurisdictions and be able to union them. The usual implementation I've used is a bit field of days of the year for however many years, though a holiday list and look up might make more sense. A default "Western" calendar only has Sat,Sun as non-business days. Date expressions can get interesting when you're trying to represent various business rules, e.g. -Sun+2b unless it is less than 3 days before the end of the month then it is -Sun-1b, which can lead you down the path of extending the syntax to include comparisons, conditional representation and the notion of "instance". E.g (-sun+2b) <= -3d ? (-sun+2b) : (-sun-1b). Now that's fun :-) Once place I worked had easter, the lunar calendar and the like to do some further unusual stuff. Adding something to a date could be a date expression: 1. date_add( date(2004,2,29), "+3M : -d") // 31 May 2004 2. date_add( date(2004,2,29), "+1M : -0b") // 29th Mar if a business day, previous b day if not one Hmmm, I forget how that bit used to work, but you get the idea... Generate a date or dates from some specification, the last day of the month is a simple specification. $0.005 Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 3

Re: [boost] Re: [thread] again
by Christophe Meessen 20 Apr '04

20 Apr '04

reHello, Unfortunately I don't have the time to reverse ingneer the boost_dev thread code. So maybye Michael Glassford can help me and answer the following questions. The most fundamental problem I found in boost thread is the functor copy. So is this still present in the new thread API ? Will the start&run thread API model be available in the new boost thread package ? If not, why ? -- Bien cordialement, Ch. Meessen

2 1

Thoughts on Unicode and Strings
by Reece Dunn 20 Apr '04

20 Apr '04

Here are my thoughts on Unicode strings, based partially on the current discussions of the topic. As I understand it, the problem with strings (standard character and Unicode strings) can be broken down into several stages: [1] Storage And Representation This is how the underlying string is stored (allocation and memory mapping policy) and how it is represented (which is governed by locale, but at this stage, it is best to know the type: UTF-8, UTF-16, UTF-32, etc.) The storage can easily be represented as a container type, and so we have: template < typename CharT, template< typename T, class A > class Container = std::vector, class AllocT = std::allocator< CharT > > class string_storage: public Container< CharT, AllocT > { }; Here, I have chosen std::vector as the standard storage policy, as this reflects the current storage policies; thus, basic_string< CharT, Traits > would therefore be based on string_storage< CharT >. It would be easy, then, to select other representations like a reference counted storage (a variant of std::auto_ptr< std::vector >) and even an SGI-like rope! (Although, this would mean that a new std::roped_vector class would need to be implemented: does such a thing already exist in Boost?) [2] Basic Type And Iteration The basic representation is more complex, because now we are dealing with character boundaries (when dealing with UTF-8 and UTF-16 views of a Unicode string). At this stage, combining characters and marks should not be concerned with, only complete characters. The Unicode string should provide at least 3 types of iterator, regardless of the internal representation (NOTE: as such, they will be implementation dependant on how the string is represented): * UTF-8 -- provides access to the UTF-8 representation of the string; * UTF-16 -- provides access to the UTF-16 representation of the string; * UTF-32 -- provides access to the Unicode character type. Therefore, no matter what the representation, it should be possible to use the UTF-32 iterator variant and "see" the string in native Unicode; this should, therefore, be the standard iterator and the others should be used when converting between formats. NOTE: I am not well versed in how Unicode is represented, so I do not know how feasible it is to implement backwards traversal, but I do know that it would probably be wise to know the position of the last good end of a Unicode character (e.g. when dealing with multi-character UTF-8 and UTF-16 representations). As a side note, it should be feasible to provide specialist wrappers around existing Unicode libraries (like Win32 (CharNext, etc.), ICU and libiconv?), so I would suggest having something akin to char_traits in basic_string. RATIONALE: Why standardize on the UTF-32 view? Because UTF-8 and UTF-16 are multi-character encodings of UTF-32 (not considering combining marks at this stage), whereas UTF-32 is a single character encoding. [3] Algorithms, Locales, etc. These are build upon the UTF-32 view of the Unicode string, like the string algorithms in the Boost library. Therefore, instead of str.find( unicode_string( "World" )), you would have find( str, unicode_string( "World" )). I would also suggest that there be another iterator that operates on std::pair< unicode_string::iterator, unicode_string::iterator > to group combining marks, etc. Thus, there would also be a function unicode_string::utf32_t combine ( std::pair< unicode_string::iterator, unicode_string::iterator > & ucr ) that will map the range into a single code point. You could therefore have a combined_iterator that will provide access to the sequence of combined characters. NOTE: If ucr.first == ucr.second, then combine( ucr ) = *( ucr.first ). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

5 7

RE: [boost] date-generators (was Date-Time)
by Hurd, Matthew 20 Apr '04

20 Apr '04

> Jeff Garland > > On Mon, 19 Apr 2004 19:14:12 -0400, Hurd, Matthew wrote > > Strikes me > > that date expressions would look nice as expression templates. > > Sure but the real requirement is that they be strings because > these things get > read in from databases and files in real apps -- they don't tend to be > hardcoded in code. Yep. A little spirit grammar would do the job though a little slowly. Once we can have strings for compile time template programming and a suitable parser things might be different. The distinction will blurr. I remember some banter quite a while a go about using char arrays for meta programming. Would it be possible to use boost pp to process a convenient macro string into a char array form for further meta-processing? In this vein, are string and floating point types as template parameter manipulation thingos (thingos: ISO C+ 5.2.1.3*) up for inclusion in C++0X? > Which is why I'm starting to see all these logical constructs > as just another > form of date generation type that has a set of rules and > combines 2 elements > (a date and month count in this case) to get another date. I guess: single_date_generator :: date x adjustment x result spec -> date where adjustment is the month count. Regards, Matt Hurd. ------------------------------- *don't look that up, I'm joking IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [boost] serialization: review
by Robert Ramey 20 Apr '04

20 Apr '04

Thorsten Ottosen wrote: > Why isn't there a base class for all archieves? I think that would be useful > with class hierachies...for example, I need to implement two function and > cannot use & anymore. Consider this > struct mammal : boost::noncopyable > { > private: > friend class boost::serialization::access; > virtual void do_serialize( boost::archive::text_oarchive& ar, unsigned > version ) = 0; > virtual void do_serialize( boost::archive::text_iarchive& ar, unsigned > version ) = 0; > template< class Archive > > void serialize( Archive & ar, unsigned version ) > { > do_serialize( ar, version ); > } > public: > virtual const std::string& name() const = 0; > virtual unsigned age() const = 0; > virtual ~mammal() {} > }; I don't understand the need for this. Given that mammal is an abstract base class with no state variables of its own, it needs no serialization at all. Just declare it as abstract using BOOST_IS_ABSTRACT(mammal). Only the serialization of the derived classes need be specified. > I can't figure out exactly how the library save/loads pointers when these > cannot be allocated on the stack. Please expand some more on this. > a.. What is your evaluation of the documentation? > I miss more specific type requirements. For example, is it necessary to > have a default constructor? Is it necessary to be stack-allocable? Must > the destructor be public? Good point. > I did try to extend the library to use my new smart containers; I was > almost successful. I would love to hear more about this. I would hope that it would easy to be totally successful. > I would like to see the focus shift from vector<T*> towards > vector< shared_ptr<T> > and ptr_vector<T>. using T* array[sz] or > vector<T*> is inherently unsafe if the pointers are heap-allocated. I believe that enforcing this is outside my role as a library creator. > I tried to extend the library to support my smart containers, but I > couldn't figure out what I did wrong. I think I might have saved them > correctly, but I cannot figure out to load them. However, I do think that > is a problem that can be solved together with Robert. (Robert, you can > find the ptr_vector in the sandbox. If you could cast a glance on the > code and tell me how the body of load_collection should look like, it > would be great.) I'll look at it. Thorsten > Some general nitpicks/comments (with these comments my test works on vc71, > como4.3.3, g++3.3.1: > 1. have you planned to use concept checks I'm intrigued with concept checks for something like this but I havn't had the time to spend on it. > 2. documentation: can the width of the html be made adaptive to the window > width? The right window must be scrolled to see it's contents which is > annoying. This drives me crazy also. Unfortunately, I haven't been able to figure out what causes this. I believe it's a Microsoft IE issue - but who knows. I would be grateful to anyone can explain to me how to fix this. 3. const members uses a const-cast to re-init them. AFAICT, this is undefined behavior (cmp 7.1.5.1). I guess the need for serialization is just another reason for not having const members. > this has come up from time to time. I've tried to promote the view that > const members shouldn't be serialized but I couldn't convince everyone. > I consider it outside my role as a library developer to try to enforce > this. > 4. AFAICR, the use of placement new require proper alignment, so the > object must eg. be heap-allocated. Is that guaranteed? I believe this has been addressed. Objects allocated on the stack use aligned storage to handle this. > 5. I think the exception code should be returned by a function: > exception_code code() const; this is how eg. the regex_error exception in > tr1 will do it. > 6. remove trailing comma in archive_exception.hpp: "unregistered_cast // > base - derived relationship not registered with" OK - though I don't think its an error. > 7. archive/detail/basic_oarchive.hpp includes itself Whoops. > 8. is_abstract.hpp: there is something wierd about the is_abstact struct. > uncommented the first part to be able to compile. I don't see this. > 9. serialization/serialization.hpp: why all the static casts? > template<class Archive, class T> > inline void serialize( > Archive & ar, T & t, const BOOST_PFTO unsigned int file_version >){ > access::serialize(ar, t, static_cast<const unsigned int>(file_version)); > } > AFAICT, they should be removed. Comeau has the follwing warning: type > qualifier is meaningless on cast type They wouldn't be there except they provide a work around for compilers which do not support Partial Template Function Specialization. On conforming compilers, the BOOST_PFTO resolves to nothing so the cast wouldn't be necessary. So commeau is correct. I don't know how much effort I want to invest to suppress benign warnings for specific compilers. > 10. nvp.hpp: line 50: > ar & t.value(); > There is on t-parameter. OK - interesting the default implementation was never instantiated. > 11. /archive/detail/oserializer.hpp", line 244: NULL reference is not > allowed > return * static_cast<const basic_pointer_oserializer *>(NULL); ^ > This not yet legal C++ (but the committee is changing that) use a static > member and return that instead. > Also, why all the static_casts? In this case the reason is that when handling issues regarding preamble, object-id, class id etc. the pointer to the object is handled as void * . This permits the archive library to be pre-compiled and not have to be recompiled for every instance. When such a void pointer is passed back to a specific archive-type combination it has to be case back to the orginal type to permit the calling of type serialization functions. This is really a result reconciliation of conflicting goals. a) serialization of pointers abstract and otherwise b) serialization of pointers in a non-intrusive manner c) limit pointless instantiation. d) not require that user classes import headers related solely to implementation. For pointers this has generated a design which takes the typed pointer converts it to void pointer, handles preamble and book keeping, converts it back to typed pointer and (de)serializes the data. The requirement of non-intrusiveness means we can't just pass around a base class pointer - hence the need for casting. > 12. two-phase lookup problems: > /boost/archive/basic_text_oarchive.hpp", line 65: error #20: > identifier "This" is undefined > archive::save(* This(), t); ^ > Solution: prefix base class functions with this->. I'm not sure I understand this but I don't see it doing any harm. If this is a problem, the following would make more sense to me. archive::save(* common_oarchive<Archive>::This(), t); > remark: why is this->This()->XX() necessary? this->xx() should do it. Hmm - I don't see this. save(Archive & ar, T t) is implemented in a more derived class. Common_oarchive<Archive> rededirects it downward to that class. I would expect this->xx() to give and undefined error. I could use archive::save(* static_cast<Archive *>(this)t); though I'm not sure you would find that anymore appealing. > 13: archive/text_oarchive.hpp, similar lookup problems. this->newtoken(), > this->delimiter = this->none; as before - I don't see a problem but changing it doesn't hurt anything. > 14: /archive/detail/basic_iarchive.hpp", line 46: error #20: > identifier "basic_iarchive_impl" is undefined > boost::scoped_ptr<basic_iarchive_impl> pimpl; ^ >solution: remember to forward declare basic_iarchieve_impl. Do the same for >basic_oarchieve_impl. OK - I had thought that using friend class made that unnecessary. > 15: /archive/detail/archive_pointer_iserializer.hpp", line 42: error #284: > (+detail/iserializer.hpp", line 240:) > NULL reference is not allowed > return *static_cast<const basic_iserializer *>(NULL); ^ > Solution: use a static member again. > 16: two-phase lookup problems in archive/basic_text_iarchive.hpp", > Solution: prefix by this->. > 17. when you save_collection_impl.hpp (eg in vector.hpp) there is no need > to specify template arguments again since they will be deduced. I presume you mean that: template<class Archive, class U, class Allocator> inline void save( Archive & ar, const std::vector<U, Allocator> &t, const unsigned int file_version ){ stl::save_collection<Archive, std::vector<U, Allocator> >( ar, t ); } Can be replaced with: template<class Archive, class U, class Allocator> inline void save( Archive & ar, const std::vector<U, Allocator> &t, const unsigned int file_version ){ stl::save_collection<Archive, std::vector>( ar, t ); } But what about: template<class Archive, class U, class Allocator> inline void load( Archive & ar, std::vector<U, Allocator> &t, const unsigned int file_version ){ stl::load_collection< Archive, std::vector<U, Allocator>, stl::archive_input_seq<Archive, std::vector<U, Allocator> >, stl::reserve_imp<std::vector<U, Allocator> > >(ar, t); } This can't be replaced with: template<class Archive, class U, class Allocator> inline void load( Archive & ar, std::vector<U, Allocator> &t, const unsigned int file_version ){ stl::load_collection< Archive, std::vector stl::archive_input_seq<Archive, std::vector>, stl::reserve_imp<std::vector> >(ar, t); } Isn't a little bit of redundancy OK giving the alternative of having to keep the details of deducibility in one's brain? > 18. implementation of save_collection(). you cannot use unsigned int count > portably. I don't see this. > Instead you should use the new collection traits (reviewed after > this review) as follows: > typename boost::size_type_of< Collection >::type count = size( s ); > then the code will also work for iterator views and arrays. Similar > comments apply to load_collection_impl.hpp I wanted to make the library buildable under 1.31 . > 19. missing #include <boost/serialization/nvp.hpp> in serialization.hpp Whoops - thanks. Robert Ramey

2 1

Boost Function Shadow Warnings
by Stephan T. Lavavej 20 Apr '04

20 Apr '04

I found some shadow warnings lurking in Boost Function. boost/function/function_template.hpp:474: warning: declaration of `invoker_type' shadows a member of `this' boost/function/function_template.hpp:481: warning: declaration of `allocator_type' shadows a member of `this' Stephan T. Lavavej http://nuwen.net

2 1

Re: [boost] [Serialization] Formal Review
by Robert Ramey 19 Apr '04

19 Apr '04

Matthew Vogt wrote: * What is your evaluation of the documentation? ... > I think the documentation addresses extending the library with > serialization of external types better than it addresses extending the > library with new archives (although, this is probably a biased view :) ) True. I didn't anticipate this much interest in making new archive classes. Also making a new archive class is harder than specifying a new serialization so I spent less effort on explaining it. > That said, the library seems not to limit anything an archive implementor > may want to do. My only remaining concern is regarding controlling access > to indiviual overloads of 'save' or 'load'. This seems to break down, due > to the fact that all accesses are from the 'access' class. I would be curious to see a specific example of this. 4) Finally, I would like reviewers to indicate parts of the library that might become standalone boost libraries. While this will have little bearing on the acceptance / rejection of the library it might allow a reduction in the size of the library. Some sections of code are definitely candidates for extraction from the serialization library, largely identified by Robert in the 'Miscellaneous' section of the documentation. The strong typedef and state_saver utilities could be extracted, perhaps to the utility library. Perhaps the extended type info infrastructure is useful outside the library. > The dataflow iterators are very interesting, but I'm not sure how they > interact with the iterator adaptors library, or with sandbox views > library. I would love to see separate discussion of this (on a separate thread please). This area overlaps with iteratator adaptors and views an maybe collection traits and who know what else. This is something I've always wanted and now I (almost) have it. My current implementation (not yet uploaded) is much improved but has the same interface and intention. > The unicode conversion code is certainly useful, but I imagine it might be > better to leave it as an implementation detail of serialization, until > someone volunteers to investigate a complete solution for this issue. I would love to see someone take this out. Ron Garcia wrote this and it worked to my satisfaction. I had problems making a good test and with portability to other compilers/libraries. Maybe Ron or someone else wants to move this to somewhere else. Robert Ramey

3 2

Re: [boost] Re: Using Serialization for binary marshalling
by Robert Ramey 19 Apr '04

19 Apr '04

Matthew Vogt wrote: > Yes, I had better explain here. In the case that I'm addressing, the > format is not a means to an end, but an end in itself. The goal of this > effort is to use the serialization library framework not to produce > reversible transformations between arbitrary C++ and a byte stream, but to > take targeted C++ objects and produce known binary representations. > I don't think it is a case of coupling, merely one of limitation. An > object that can be serialized into XDR format must use only a limited > range of C++ types in it's composition - but having accepted that > limitation, it can still be serialized into a less limiting archive type > with the same code. OK - I'm still wary, but if you find this doable and useful more power to you. > > 3) I'm curious about the override for the saving of vector. ... > > > I need to override the serialization of vector, because the vector must be > > serialized with a known policy to yield a required layout in the archive. > > The fact that this serialization happens (at this point in time) to be > > exactly the same as the default implementation is not relevant - that can > > be changed at any time, but the CDR, XDR and other binary formats must > > not change. > > I'm still not convinced - its seems to me that it shouldn't need to be > overridden for XDR and CDR which is what these classes do. What about list, > deque, set, etc. > > 3) I'm curious about the override for the saving of vector. ... > Well, I never thought these were necessary, remembering that I am > providing for classes, which are designed to be serialized into a > particular binary format. In a binary format, all collections will boil > down to a group of repetitions, which are either preceded by a > length/count argument, or whose length is a defined property of the > format itself. Correct. That's exactly what the current implementations of STL classes do. So my question is why override vector for you xdr/cdr archives? > For me, vector has always sufficed, in either fixed_length<>, or > variable_length<> guise. Perhaps others have differing experience. For your xdr/cdr archives to appealing to the boost users that have asked for this and for these archives to be tested to the same standards, all STL collections will have to be handled. I do not think the override for vector is necessary. If it is necessary then its probably necessary to provide overrides for all the STL collection classes. > But there are inherent limitations in marshalling (per my usage). > Pointers, which are adeptly handled by the general library, are not valid > elements of a marshalled data set. I disagree here, I think the ability to pass "equivalent" pointers across space( marshalling ) is just as valuable as the ability to pass them acrose time ( persistence ). This puts a fine point on my views. I think that in the past, much of the difficulty of the topic was due the fact that different people viewed in terms of marshalling and other in terms of persistence and there is a lot of overlap. (One attempt to define "serialization" when to 200 words !). I believe my definition as stated in the start of the documentation factored out the commonality and I resolved to focus on that. I also believe that this has turned out to be one of the main reasons that the library has been embraced to the extent that it has. This explains my reluctance to consider Marshalling as a special case. I would like to see your xdr/cdr archives finished off at the same level of generality as the other archives. Any special purpose marshalling would leverage off that. Robert Ramey

2 1