- 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

Re: Re: Serialization Formal Review #2
by Robert Ramey 19 Apr '04

19 Apr '04

Matthias Troyer wrote: > I have two more questions regarding the serialization library which I > need to have answered before I can see if I can read my old archives > with your library: > 1. when overloading the save/load functions in an archive, do I bypass > writing preambles and other class information or do I need to overload > operator <<? What is the difference between implementing operator<< and > save? > 2. which functions do I need to implement in my archive class to skip > writing the standard preamble that your archives write? Is it just the > init function or are there more functions? Depending on the implementation traits for each class, there may be a preamble written by the serialization library. This contains information such as version number, class id info, perhaps export key, etc required by the s library to reconstruct a faithful reproduction of the original data. If there is a preamble, there is no information in that can be discarded and still reproduce the original data. In general it can't be guaranteed that one can read an arbitrary file format created independently of the serialization library. With the serialization library, it's the class/instance structure that drives the file format rather than the other way around. To transition to use the serialization library the strategy would be: a) add serialization to the classes desired. b) write a program which reads the "old" data files using the "old" method - whatever that might be. c) invoke serialization to save in the desired new format. The old data files should no longer be necessary. Best regards Matthias

2 1

Re: [boost] a note on serialization docs
by Robert Ramey 19 Apr '04

19 Apr '04

David Abrahams wrote: > When viewing [boost] a note on serialization docs > http://www.rrsd.com/boost/libs/serialization/doc/index.html in IE6, > the right ends of some of the words are tucked underneath the > scrollbar at the right of the window. The HTML or stylesheet should > have some kind of margin to prevent this effect. This annoys me also. Even worse is thie fact that some lines don't break. I've toyed around with this but haven't found the fix. Its especially odd to me given that it imports the style.css from the boost directory but other pages don't show this behavior. I believe its some MSIE quirk. If anyone knows how to address this I'm all ears. Robert Ramey

1 0

static sized strings
by Reece Dunn 19 Apr '04

19 Apr '04

There is currently a static-sized array in the Boost library that allows you to operate on arrays of fixed size. I was wondering if something similar exists for strings, in particular, providing buffer-overflow safe string operations. I have an nstring< std::size_t n > string class that provides size-safe copying and comparison, allowing for you to do things like: nstring< 20 > s; s.copy( "Hello World!" ) if( s == "Hello" ) ... // note: this will succeed! This is useful for things like processing file format headers, as it allows things like: struct tar_header { nstring< 100 > name; ... nstring< 8 > magic; ... }; if( hdr.magic == "ustar\x20\x20\0" ) // GNU TAR archive ... else if( hdr.magic == "ustar\0" ) // POSIX TAR archive ... else // invalid format I also have a formatter class that provides buffer-safe printf-like operations on the constructor and as a functor, e.g.: formatter< 512 > fmt( "%s: %s", type, msg ); std::cout << fmt << '\n'; std::cout << fmt( "error: %s", msg ) << '\n'; This can be useful when you need to format a string without making use of a string buffer, e.g.: std::ostringstream fmt; fmt << type << ": " << msg; std::cout << fmt.str() << '\n'; fmt.str( std::string()); // clear string buffer fmt << "error: " << msg; std::cout << fmt.str() << '\n'; Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

[thread] again ;)
by John Torjo 19 Apr '04

19 Apr '04

Dear boosters, As far as I've heard a while back, the only reason [thread] library cannot be built as a static library was because of TSS. That to me (and to others as I've seen) seems quite a show-stopper - in a lot of apps I don't use the [thread] lib just because of this. Most of my multi-threaded applications (around 95%) and as I know a lot of other multi-threaded apps. don't need TSS. Even if they do, usually they don't need advanced clean-up code (reason for why [thread] was required to be a DLL). ***Most*** of the time, any allocated TSS objects can be let to leak resources (which they hardly have - mostly IMHO some small amount of allocated memory). The above make me think that we really should enable [thread] to be a static library again ;). It should be documented in the docs that the static version of the [thread] runtime will leak TSS objects, and users can choose whether they will use [thread] as a DLL or as a runtime static lib. What do others think? As a side-note, allowing the [thread] lib to be a static lib is quite simple (please you gurus out there, correct me if I'm wrong). In fact, here's the patch. (note: config.hpp = boost/thread/detail/config.hpp, and I did not modify the jamfile.V2, since I can't test it) Best, John // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #ifndef BOOST_THREAD_CONFIG_WEK01032003_HPP #define BOOST_THREAD_CONFIG_WEK01032003_HPP #include <boost/config.hpp> // insist on threading support being available: #include <boost/config/requires_threads.hpp> #if defined(BOOST_HAS_WINTHREADS) # if defined(BOOST_THREAD_BUILD_DLL) # define BOOST_THREAD_DECL __declspec(dllexport) # elif defined(BOOST_DYN_LINK) // john.torjo # define BOOST_THREAD_DECL __declspec(dllimport) # else # define BOOST_THREAD_DECL // linking to library # endif #else # define BOOST_THREAD_DECL #endif // BOOST_HAS_WINTHREADS // john.torjo /* // // Automatically link to the correct build variant where possible. // #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_THREAD_NO_LIB) && !defined(BOOST_THREAD_BUILD_DLL) // // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: // #define BOOST_LIB_NAME boost_thread // // If we're importing code from a dll, then tell auto_link.hpp about it: // # define BOOST_DYN_LINK // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled */ #endif // BOOST_THREAD_CONFIG_WEK1032003_HPP # Copyright (C) 2001-2003 # William E. Kempf # # Permission to use, copy, modify, distribute and sell this software # and its documentation for any purpose is hereby granted without fee, # provided that the above copyright notice appear in all copies and # that both that copyright notice and this permission notice appear # in supporting documentation. William E. Kempf makes no representations # about the suitability of this software for any purpose. # It is provided "as is" without express or implied warranty. # # Boost.Threads build Jamfile # # Additional configuration variables used: # 1. PTW32 may be used on Win32 platforms to specify that the pthreads-win32 # library should be used instead of "native" threads. This feature is # mostly used for testing and it's generally recommended you use the # native threading libraries instead. PTW32 should be set to be a list # of two strings, the first specifying the installation path of the # pthreads-win32 library and the second specifying which library # variant to link against (see the pthreads-win32 documentation). # Example: jam -sPTW32="c:\pthreads-win32 pthreadVCE.lib" # Declare the location of this subproject relative to the root. subproject libs/thread/build ; # Include threads.jam for Boost.Threads global build information. # This greatly simplifies the Jam code needed to configure the build # for the various Win32 build types. import ./threads ; { template thread_libs ## sources ## : <template>thread_base ## requirements ## : <sysinclude>$(BOOST_ROOT) ## default build ## : ; # Base names of the source files for libboost_thread. CPP_SOURCES = condition mutex recursive_mutex thread tss xtime once exceptions barrier threadmon ; lib boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <runtime-link>static # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; dll boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <define>BOOST_THREAD_BUILD_DLL=1 <runtime-link>dynamic # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; stage bin-stage : <dll>boost_thread <lib>boost_thread #: <tag><debug>"d" : debug release ; install thread lib : <dll>boost_thread <lib>boost_thread ; }

3 6

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

19 Apr '04

Jeff Garland wrote: > I believe that Matthew has now demonstrated that archive extension is > possible, which I believe is one of the major changes from the first > review. That said, any documentation of this process would clearly be a > plus. In a typical proprietary archives writing of the version and type > numbers will need to be shut off. So I can imagine documenting these > sorts of issues. As it turns out, type id, and object id are really required only for pointers and version is in fact optional. It would be possible to make an archive which: a) trapped (BOOST_STATIC_ASSERT) attempts to serialize a pointer b) trapped attempt to save/load object id and class id c) implemented null serialization of version numbers and trapped attempts to use version number != 0 This would work only on serializations that had implementation attributes of no versioning, and no object tracking. If used on other types, it would trap at compiler time. I believe that you would have what you wanted. In general, the part of the library which saves/loads the preamble is invoked only for pointers. An easy way to check this is to generate XML archive and find that there are not attributes for this types. Robert Ramey

2 1

a note on serialization docs
by David Abrahams 19 Apr '04

19 Apr '04

When viewing http://www.rrsd.com/boost/libs/serialization/doc/index.html in IE6, the right ends of some of the words are tucked underneath the scrollbar at the right of the window. The HTML or stylesheet should have some kind of margin to prevent this effect. Cheers, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 1

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

19 Apr '04

> Jeff Garland writes: > Yes, for 'random access' archives (think relational database buffer here) > it's possible the archive process will need additional meta-data not > provided in the base library setup (think mapping of classes to tables and > attributes to columns). And yes, I've implemented this one before as well > -- it's a very handy bit of infrastructure. > but in fact I believe given the current library it could now > be done by writing and archive and perhaps some enhancements to the > registration. I faced the same problem with XML meta-data. I resolved with the NVP wrapper which kept XML out of the library core - really a big thing for me as I have had to continually refactor to keep things from growing totally out of control. I'm sure this idea of making a wrapper which includes meta-data along with the data itself is going to be useful in cases like this. > I think in the past Robert has considered this "out of scope", Well, yes. I have fought a continuing battle to limit scope. > BTW, I think the references should include a reference to this paper which > discusses many of these variations and design issues. > http://www.ubilab.org/publications/print_versions/pdf/plop-96-serializer.pdf I've seen this paper, and at this suggestion was made before. I think I included a reference to it but the link moved. There's another whole field to plow regarding web references as opposed to published ones. Robert Ramey

1 0

move semantics
by Andrea Torsello 19 Apr '04

19 Apr '04

Hi, I have been investigating move semantics and think that I came up with a solution that is strongly influenced by both David Abrahams' move approach and Andrei Alexandrescu's mojo, but solves some of the problems I have encountered with them. The basic idea is to use the explicit keyword to force the compiler to use the X(X const &) constructor only in two cases. 1) When explicitly copying a const object i.e. X const x; X y(x); //use explicit copy constructor 2) When passing by const ref void f(X const &); X makeX(); void foo() { f(makeX()); //use explicit copy constructor } In all other cases the other constructor take precedence. Note that the template trick David Abrahams uses in his move approach would lead to an error on a conforming compiler when confronted with case #2 (unless more recent versions corrected this). I chose to keep the temporary and constant subtypes from mojo because they allow me to discriminate between const values, non-const rvalues and non-const rvalues. The lack of this capability was the major problem I had with David Abrahams' move. My use-case was a vector-like container that increases but never decreases the size of its backing store. In order to provide the never decreasing backing-store semantic, operator = moves the backing store from a temporary only if the new data does not fit in the existing space. Hence, operator = must be able to discriminate between temporaries and non-temporaries. My solution fullfills almost all the requirements I had: 1) passing by value moves non-const rvalues and copies everithing else. 2) its is transparent to the user of the class. Alexandrescu's Mojo fails this because of the special return type, while Abrahams' move fails it because of the pass-by-const-ref problem described above. 3) it allows to discriminate between constants, non-const lvalues, and non-const rvalues. Alexandrescu's Mojo allows it, while Abrahams' move does not. 4) Provides move semantics to templated classes with (almost) no odd side-effect. The only side-effect is that template type deduction does not work with temporary discrimination. Hence in the sample code the template type of the "discriminate" function must be specified explicitly. please find attached a sample file illustrating my move approach. I tested the code with gcc 3.3.1 and successfully compiled it with comeau online. What do you think? Andrea Torsello P.S. please cc me as I am not subscribed and I check the mailinglist archives sporadically begin 666 move_test.cc M(VEN8VQU9&4\:6]S=')E86T^#0H-"@T*=7-I;F<@<W1D.CIC;W5T.PT*=7-I M;F<@<W1D.CIE;F1L.PT*#0IN86UE<W!A8V4@;6]V90T*>PT*"71E;7!L871E M(#QC;&%S<R!4/B!S=')U8W0@96YA8FQE9 T*"7L-"@D)8VQA<W,@8V]N<W1A M;G0@+R\@='EP92!S=6=A<B!F;W(@8V]N<W1A;G1S#0H)"7L-"@D)8V]N<W0@ M5"H@9&%T85\[#0H)"7!U8FQI8SH-"@D)97AP;&EC:70@8V]N<W1A;G0H8V]N M<W0@5"8@;V)J*2 Z(&1A=&%?*"9O8FHI('M]#0H)"6-O;G-T(%0F(&=E="@I M(&-O;G-T('L@<F5T=7)N("ID871A7SL@?0T*"0E].PT*#0H)"6-L87-S('1E M;7!O<F%R>2 Z('!R:79A=&4@8V]N<W1A;G0@+R\@='EP92!S=6=A<B!F;W(@ M=&5M<&]R87)I97,-"@D)>PT*"0EP=6)L:6,Z#0H)"65X<&QI8VET('1E;7!O M<F%R>2A4)B!O8FHI(#H@8V]N<W1A;G0H;V)J*2![?0T*"0E4)B!G970H*2!C M;VYS="![(')E='5R;B!C;VYS=%]C87-T/%0F/BAC;VYS=&%N=#HZ9V5T*"DI M.R!]#0H)"7T[#0H-"@EO<&5R871O<B!T96UP;W)A<GDH*0T*"7L-"@D@(" @ M<F5T=7)N('1E;7!O<F%R>2AS=&%T:6-?8V%S=#Q4)CXH*G1H:7,I*3L-"@E] M#0H);W!E<F%T;W(@8V]N<W1A;G0H*2!C;VYS= T*"7L-"@D@(" @<F5T=7)N M(&-O;G-T86YT*'-T871I8U]C87-T/&-O;G-T(%0F/B@J=&AI<RDI.PT*"7T- M"@T*#0H)<')O=&5C=&5D.@T*"0EE;F%B;&5D*"D@>WT@+R\@:6YT96YD960@ M=&\@8F4@9&5R:79E9"!F<F]M#0H)"7YE;F%B;&5D*"D@>WT@+R\@:6YT96YD M960@=&\@8F4@9&5R:79E9"!F<F]M#0H)?3L-"GT-"@T*=&5M<&QA=&4\='EP M96YA;64@5#X-"F-L87-S(%D@.B!P=6)L:6,@;6]V93HZ96YA8FQE9#Q9/%0^ M(#X-"GL-"G!U8FQI8SH-"G1Y<&5D968@='EP96YA;64@;6]V93HZ96YA8FQE M9#Q9/%0^(#XZ.G1E;7!O<F%R>2!T96UP;W)A<GD[#0IT>7!E9&5F('1Y<&5N M86UE(&UO=F4Z.F5N86)L960\63Q4/B ^.CIC;VYS=&%N="!C;VYS=&%N=#L- M"@T*62@I('M]#0H-"F5X<&QI8VET(%DH63Q4/B!C;VYS=" F*2![(&-O=70@ M/#P@(F5X<&QI8VET(&-O<'D@8V]N<W1R=6-T;W)<;B([('T-"EDH63Q4/B8I M('L@8V]U=" \/" B;F]N+6-O;G-T(&QV86QU92!C;W!Y(&-O;G1R=6-T;W)< M;B([('T-"EDH8V]N<W1A;G0I('L@8V]U=" \/" B8V]N<W0@8V]P>2!C;VYS M=')U8W1O<EQN(CL@?0T*62AT96UP;W)A<GDI('L@8V]U=#P\(")N;VXM8V]N M<W0@<G9A;'5E(&UO=F4@8V]N<W1R=6-T;W)<;B([('T-"GT[#0H-"@T*=&5M M<&QA=&4\='EP96YA;64@5#X-"ED\5#X@;6%K95DH*2![<F5T=7)N(%D\5#XH M*3M]#0H-"G1E;7!L871E/'1Y<&5N86UE(%0^#0I9/%0^(&-O;G-T(&UA:V59 M8V]N<W0H*2![<F5T=7)N(%D\5#XH*3M]#0H-"@T*=&5M<&QA=&4\='EP96YA M;64@5#X-"G9O:60@9V5T62A9/%0^*2![?0T*#0IT96UP;&%T93QT>7!E;F%M M92!4/@T*=F]I9"!G9719<F5F*%D\5#XF*2![?0T*#0IT96UP;&%T93QT>7!E M;F%M92!4/@T*=F]I9"!G97198V]N<W1?<F5F*%D\5#X@8V]N<W0@)BD@>WT- M"@T*#0IT96UP;&%T93QT>7!E;F%M92!4/@T*=F]I9"!D:7-C<FEM:6YA=&4H M63Q4/B8I('MC;W5T(#P\(")D:7-C<FEM:6YA=&4Z(&YO;BUC;VYS="!L=F%L M=65<;B([?0T*#0IT96UP;&%T93QT>7!E;F%M92!4/@T*=F]I9"!D:7-C<FEM M:6YA=&4H='EP96YA;64@63Q4/CHZ8V]N<W1A;G0I('MC;W5T(#P\(")D:7-C M<FEM:6YA=&4Z(&-O;G-T('9A;'5E7&XB.WT-"@T*=&5M<&QA=&4\='EP96YA M;64@5#X-"G9O:60@9&ES8W)I;6EN871E*'1Y<&5N86UE(%D\5#XZ.G1E;7!O M<F%R>2D@>V-O=70@/#P@(F1I<V-R:6UI;F%T93H@;F]N+6-O;G-T(')V86QU M95QN(CM]#0H-"FEN="!M86EN*"D-"GL-"ED\:6YT/B!Y,3L-"ED\:6YT/B!C M;VYS="!Y,CL-"@T*63QI;G0^('0Q*'DQ*3L@+R]C;W!Y(&YO;BUC;VYS="!L M=F%L=64-"ED\:6YT/B!T,BAY,BD[("\O8V]P>2!C;VYS="!L=F%L=64-"ED\ M:6YT/B!T,RAM86ME63QI;G0^*"DI.R O+V-O<'D@=&5M<&]R87)Y#0I9/&EN M=#X@=#0H;6%K95EC;VYS=#QI;G0^*"DI.R O+V-O<'D@8V]N<W0@=&5M<&]R M87)Y#0H-"F=E=%EC;VYS=%]R968H>3$I.R O+W!A<W,M8GDM8V]N<W0M<F5F M(&YO;BUC;VYS="!L=F%L=64-"F=E=%EC;VYS=%]R968H>3(I.R O+W!A<W,M M8GDM8V]N<W0M<F5F(&-O;G-T(&QV86QU90T*9V5T66-O;G-T7W)E9BAM86ME M63QI;G0^*"DI.R O+W!A<W,M8GDM8V]N<W0M<F5F(&YO;BUC;VYS="!T96UP M;W)A<GD-"F=E=%EC;VYS=%]R968H;6%K95EC;VYS=#QI;G0^*"DI.R\O<&%S M<RUB>2UC;VYS="UR968@8V]N<W0@=&5M<&]R87)Y#0H-"F=E=%DH>3$I.R O M+W!A<W,M8GDM=F%L=64@;F]N+6-O;G-T(&QV86QU90T*9V5T62AY,BD[("\O M<&%S<RUB>2UV86QU92!C;VYS="!L=F%L=64-"F=E=%DH;6%K95D\:6YT/B@I M*3L@+R]P87-S+6)Y+79A;'5E(&YO;BUC;VYS="!T96UP;W)A<GD-"F=E=%DH M;6%K95EC;VYS=#QI;G0^*"DI.R O+W!A<W,M8GDM=F%L=64@;F]N+6-O;G-T M('1E;7!O<F%R>0T*#0ID:7-C<FEM:6YA=&4\:6YT/BAY,2D[("\O;F]N+6-O M;G-T(&QV86QU90T*9&ES8W)I;6EN871E/&EN=#XH>3(I.R O+V-O;G-T(&QV M86QU90T*9&ES8W)I;6EN871E/&EN=#XH;6%K95D\:6YT/B@I*3L@+R]N;VXM M8V]N<W0@=&5M<&]R87)Y#0ID:7-C<FEM:6YA=&4\:6YT/BAM86ME66-O;G-T M/&EN=#XH*2D[("\O8V]N<W0@=&5M<&]R87)Y#0H-"@T*<F5T=7)N(# [#0I] ` end

5 38

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

19 Apr '04

Jeff Garland wrote: >> Robert Ramey wrote: >> So I'm skeptical of trying to adjust to "old" proprietary formats >> with the serialization library. > Well, I believe you are taking too narrow a view here. OK, I'll expand my horizon a bit. I can see how one might want to make special purpose archive which only handles a subset of all possible C++ structures. So it really comes down to evaluating the specific situation. There is nothing in the serialization library which conflicts with such usage so I'm happy to remain agnostic ( though still perhaps wary ) on this case. I wonder what happens when we need "special" information in the archive. I faced the same problem with XML where we need the name of the instance variable. I solved it by making the NVP wrapper which has worked well. However it does introduce a coupling between the archive and the serialization which I had strived to avoid. The best I could do was to make it optional and transparent to those archives which didn't use it. In order to do this I had to make all archive classes aware of it. Well, for XML this might be justified but in general I would find it objectionable. When one makes the archive dependent upon the serialization (E.G. by addressing only a subset of all C++), he won't be able to run the torture test suite. Personally, I consider this a significant liability. So anyway, if it works for a specific problem, then of course I've got no concerns. If its proposed as addition to the library, I would like to see it be universal as the current ones are - if only for the reason that a new archive can be subjected to the torture test with very little effort. So to summarize, if one wants/needs to make special purpose archive which handles a subset of all types - no problem. But it probably would not be of interest outside of the particular application. Robert Ramey

1 0

Re: [boost] Re: Serialization compile errors on CW9
by Robert Ramey 19 Apr '04

19 Apr '04

Message: 1 Date: Sun, 18 Apr 2004 13:54:08 -0400 From: Miro Jurisic <macdev(a)meeroh.org> Subject: To: Message-ID: <macdev-C68DBE.13540818042004(a)sea.gmane.org> In article <20040418160047.656883147E(a)acme.west.net>, "Robert Ramey" <ramey(a)rrsd.com> wrote: > Miro Jurisic wrote: > namespace detail { > #if BOOST_WORKAROUND... > typedef ::mbstate_t mbstate_t; > #else > typedef std::mbstate_t mbstate_t; > #endif > } OK - thanks, done, Robert Ramey

1 0

Named params library and BGL
by Vladimir Prus 19 Apr '04

19 Apr '04

I've just made an attempt to use the named parameters library (currently in review queue, and available at http://groups.yahoo.com/group/boost/files/named_params.zip) to simply properties in BGL. Currently, to initialize all properties one has to do: edge_descriptor e = add_edge(....); put(e, g, vertex_color, 10); put(e, g, vertex_name, "foo"); I hope that with the named parameters library it will be possible to do: add_edge(v1, v2, (vertex_color = 10, vertex_name = "foo"), g); I've tried to implement this idea, but run into the problems. First issue is documentation: it gives foo_impl(foo_keywords(a0)); as example, while the code uses: return f_impl(f_keywords()(t, name_)); Which has extra '()' after f_keywords. The second problem is that I need to create a type for 'keywords' (derived from 'keywords<...>' and use it for passing arguments). The docs suggest to create a number of forwarding functions, but given that a number of vertex properties can be rather large (and is actually unbounded), this does not seem good. So, now can do: vertex_property p = prop_keywords()(color = 10, name = "foo"); but I'd rather like: vertex_property p((color = 10, name = "foo")); So, the operator, will be overloaded to create something I can index with 'tag type' and get a value. In fact, this will allow to avoid declaring 'pop_keywords' -- since again, user can declare it's own keywords so it's not clear how to define that class. The example I've played with is at: http://zigzag.cs.msu.su:7813/p.cpp Comments are appreciated. - Volodya

4 9

RE: Boost Digest, Vol 700, Issue 1
by S G Ganesh 19 Apr '04

19 Apr '04

I am an engineer in HP's aCC compiler team. We are actively working on Boost defects and the internal developmental version of the compiler compiles many of the Boost libraries successfully. There is a compiler patch (for both PA and IPF) coming up by end of this month: if any of you are interested and have a support contract, you can register for beta testing. The current compiler status for aCC shows that the pass percentage is dismal 26%, but with this patch, it should be more than 70% (we are working on improving it further). Many libraries, such as regex, bind, any, thread already compile successfully with this patch compiler. Please note that the fixes are in the compiler without modifying the Boost sources; we came across a few defects in the Boost sources which we can share with you so that they can be fixed (or provide a workaround or #ifdefed). It would be great if we can work together to resolve any issues, which will be mutually beneficial. If you come across any defects in the compiler while compiling the Boost sources, you can file bug reports for the same. Any issues on developing with aC++ compiler will be immediately responded in cxx-dev(a)cup.hp.com newsgroup. -Ganesh S G Ganesh HP PA C++ Compiler Front-end Team Phone: +91-80-2205 1832 ------------------------------ Message: 15 Date: Sat, 17 Apr 2004 11:54:11 +0100 From: "John Maddock" <john(a)johnmaddock.co.uk> Subject: Re: [boost] boost on HP-UX 11i To: <boost(a)lists.boost.org> Message-ID: <06af01c4246a$58c62350$cbfc0352@fuji> Content-Type: text/plain; charset="iso-8859-1" > I recently downloaded boost libraries to use the smart_ptr libraries. It > appears to be working. But several other libraries, as shown by the > compiler report is not. I also noticed that last run date is 9 months > ago. Is anybody working on getting boost to work on aCC? I would be very > surprised if nobody has tried before since HP is a top-tier vendor, but > I couldn't find any useful information from the archives. If not, I > would like to take a stab at getting it to work. I have contact with HP > aCC techs to fix problems if it is a compiler problem. I'm particularly > interested in getting the libraries regex and spirit (for now, more > later) to work. I did a search on the boost archive and the last > reference to this subject was written back in August 14, 2003: I'd love to see regex working with aCC if it's humanly possible, if you want to mail me privately with any queries you may have that would be fine - especially if you have a working relationship with HP personnel - we've managed to persuade quite a few other vendors to work with us, and even to use Boost for their internal regression tests, HP is one of the notable exceptions so far :-| John.

2 1

serialization: review
by Thorsten Ottosen 19 Apr '04

19 Apr '04

Hi Robert, Here is my review of your library. a.. What is your evaluation of the design? Seems fine. I have a few issues though. 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() {} }; Some way of supporting only one do_serialize() to preserve the order would be nice. a.. What is your evaluation of the implementation? There are some minor compiler problems and suggestions listed below. I can't figure out exactly how the library save/loads pointers when these cannot be allocated on the stack. a.. What is your evaluation of the documentation? I already gave some feedback on the introduction. In general it seems ok. I like the comparison with other lbraries. 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? a.. What is your evaluation of the potential usefulness of the library? It's certainly useful. a.. Did you try to use the library? With what compiler? Did you have any problems? yes, see below. I can compile my code with vc71, gcc3.3 comeau 4.3.3. a.. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5 hours. It's neither a glance nor an in-depth study. I did try to extend the library to use my new smart containers; I was almost sucessful. a.. Are you knowledgeable about the problem domain? hm...no. a.. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion yes. But I think the pointer part of the library need to be given extra thought; 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 tried to extend the library to support my smart containers, but I coulnd'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.) freestanding libraries: Obvious candidates are (a) BOOST_STRONG_TYPEDEF (could maybe be part of utility) (b) dataflow_iterators best regards 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 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. 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. 4. AFAICR, the use of placement new require proper alignment, so the object must eg. be heap-allocated. Is that guaranteed? 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" 7. archive/detail/basic_oarchive.hpp includes itself 8. is_abstract.hpp: there is something wierd about the is_abstact struct. I uncommented the first part to be able to compile. 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 10. nvp.hpp: line 50: ar & t.value(); There is on t-parameter. 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? 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->. remark: why is this->This()->XX() necessary? this->xx() should do it. 13: archive/text_oarchive.hpp, similar lookup problems. this->newtoken(), this->delimiter = this->none; 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. 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. 18. implementation of save_collection(). you cannot use unsigned int count portably. 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 19. missing #include <boost/serialization/nvp.hpp> in serialization.hpp begin 666 smart_container.cpp M(VEN8VQU9&4@/&9S=')E86T^#0HC:6YC;'5D92 \<W1R:6YG/@T*(VEN8VQU M9&4@/&EO<W1R96%M/@T*(VEN8VQU9&4@/&)O;W-T+V%R8VAI=F4O=&5X=%]O M87)C:&EV92YH<' ^#0HC:6YC;'5D92 \8F]O<W0O87)C:&EV92]T97AT7VEA M<F-H:79E+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T:6]N+W-T M<FEN9RYH<' ^#0HC:6YC;'5D92 \8F]O<W0O<V5R:6%L:7IA=&EO;B]V97)S M:6]N+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T:6]N+W-P;&ET M7VUE;6)E<BYH<' ^#0HC:6YC;'5D92 \8F]O<W0O<V5R:6%L:7IA=&EO;B]V M96-T;W(N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+W-E<FEA;&EZ871I;VXO97AP M;W)T+FAP<#X-"B-I;F-L=61E(#QB;V]S="]P=')?8V]N=&%I;F5R+W!T<E]V M96-T;W(N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+V%S<VEG;B]S=&PN:'!P/@T* M(VEN8VQU9&4@/&)O;W-T+VYO;F-O<'EA8FQE+FAP<#X-"@T*+R\O+R\O+R\O M+R\O+R\O+R\O+R\O+R\O+R\O+PT*+R\@<'1R('9E8W1O<B!S97)I86QI>F%T M:6]N#0H-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T:6]N+V-O;&QE8W1I M;VYS7W-A=F5?:6UP+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S97)I86QI>F%T M:6]N+V-O;&QE8W1I;VYS7VQO861?:6UP+FAP<#X-"B-I;F-L=61E(#QB;V]S M="]S97)I86QI>F%T:6]N+W-P;&ET7V9R964N:'!P/@T*#0IT96UP;&%T93QC M;&%S<R!!<F-H:79E+"!C;&%S<R!5+"!C;&%S<R!!;&QO8V%T;W(^#0II;FQI M;F4@=F]I9"!S879E* T*(" @($%R8VAI=F4@)B!A<BP-"B @("!C;VYS="!B M;V]S=#HZ<'1R7W9E8W1O<CQ5+"!!;&QO8V%T;W(^("9T+ T*(" @('5N<VEG M;F5D(&EN="!F:6QE7W9E<G-I;VX-"BD-"GL-"B @("!B;V]S=#HZ<V5R:6%L M:7IA=&EO;CHZ<W1L.CIS879E7V-O;&QE8W1I;VXH(&%R+"!T("D[#0I]#0H- M"G1E;7!L871E/&-L87-S($%R8VAI=F4L(&-L87-S(%4L(&-L87-S($%L;&]C M871O<CX-"FEN;&EN92!V;VED(&QO860H#0H@(" @07)C:&EV92 F(&%R+ T* M(" @(&)O;W-T.CIP=')?=F5C=&]R/%4L($%L;&]C871O<CX@)G0L#0H@(" @ M=6YS:6=N960@:6YT(&9I;&5?=F5R<VEO;@T**0T*>PT*+RH@,2X@8V]M<&EL M97,L(&)U="!C<F%S:&5S#0H@(" @(" @('-T;#HZ;&]A9%]C;VQL96-T:6]N M/ T*(" @(" @("!!<F-H:79E+ T*(" @(" @("!B;V]S=#HZ<'1R7W9E8W1O M<CQ5+"!!;&QO8V%T;W(^+ T*(" @(" @("!S=&PZ.F%R8VAI=F5?:6YP=71? M<V5Q/$%R8VAI=F4L(&)O;W-T.CIP=')?=F5C=&]R/%4L($%L;&]C871O<CX@ M/BP-"B @(" @(" @<W1L.CIR97-E<G9E7VEM<#QB;V]S=#HZ<'1R7W9E8W1O M<CQ5+"!!;&QO8V%T;W(^(#X-"B @(" ^*&%R+"!T*3L-"B @(" J+PT*?0T* M#0HO+R!S<&QI="!N;VXM:6YT<G5S:79E('-E<FEA;&EZ871I;VX@9G5N8W1I M;VX@;65M8F5R(&EN=&\@<V5P87)A=&4-"B\O(&YO;B!I;G1R=7-I=F4@<V%V M92]L;V%D(&UE;6)E<B!F=6YC=&EO;G,-"G1E;7!L871E/&-L87-S($%R8VAI M=F4L(&-L87-S(%4L(&-L87-S($%L;&]C871O<CX-"FEN;&EN92!V;VED('-E M<FEA;&EZ92@-"B @("!!<F-H:79E("8@87(L#0H@(" @8F]O<W0Z.G!T<E]V M96-T;W(\52P@06QL;V-A=&]R/B F('0L#0H@(" @8V]N<W0@=6YS:6=N960@ M:6YT(&9I;&5?=F5R<VEO;@T**7L-"B @("!S<&QI=%]F<F5E*&%R+"!T+"!F M:6QE7W9E<G-I;VXI.PT*?0T*#0H-"B\O+R\O+R\O+R\O+R\O+R\O+PT*+R\@ M8VQA<W,@:&EE<F%C:'D-"@T*<W1R=6-T(&UA;6UA;" Z(&)O;W-T.CIN;VYC M;W!Y86)L90T*>PT*<')I=F%T93H-"B @(" -"B @("!F<FEE;F0@8VQA<W,@ M8F]O<W0Z.G-E<FEA;&EZ871I;VXZ.F%C8V5S<SL-"B @("!V:7)T=6%L('9O M:60@9&]?<V5R:6%L:7IE*"!B;V]S=#HZ87)C:&EV93HZ=&5X=%]O87)C:&EV M928@87(L('5N<VEG;F5D('9E<G-I;VX@*2 ](# [#0H@(" @=FER='5A;"!V M;VED(&1O7W-E<FEA;&EZ92@@8F]O<W0Z.F%R8VAI=F4Z.G1E>'1?:6%R8VAI M=F4F(&%R+"!U;G-I9VYE9"!V97)S:6]N("D@/2 P.PT*(" @( T*(" @('1E M;7!L871E/"!C;&%S<R!!<F-H:79E(#X-"B @("!V;VED('-E<FEA;&EZ92@@ M07)C:&EV92 F(&%R+"!U;G-I9VYE9"!V97)S:6]N("D-"B @("![#0H@(" @ M(" @(&1O7W-E<FEA;&EZ92@@87(L('9E<G-I;VX@*3L-"B @("!]#0H@(" @ M#0IP=6)L:6,Z#0H-"B @("!V:7)T=6%L(&-O;G-T('-T9#HZ<W1R:6YG)B!N M86UE*"D@8V]N<W0@/2 P.PT*(" @('9I<G1U86P@=6YS:6=N960@(" @(" @ M(" @(&%G92@I(&-O;G-T(" ](# [#0H@(" @(" @(" @#0H@(" @=FER='5A M;"!^;6%M;6%L*"D@>WT-"GT[#0H-"G-T9#HZ;W-T<F5A;28@;W!E<F%T;W(\ M/"@@<W1D.CIO<W1R96%M)B!O<RP@8V]N<W0@;6%M;6%L)B!M("D-"GL-"B @ M("!R971U<FX@;W,@/#P@(FYA;64@/2 B(#P\(&TN;F%M92@I(#P\("(@86=E M(#T@(B \/"!M+F%G92(a)I.R -"GT-"@T*<W1R=6-T(&%P92 Z('!U8FQI8R!M M86UM86P-"GL-"B @("!A<&4H*3L-"B @("!A<&4H(&-O;G-T('-T9#HZ<W1R M:6YG)B!N86UE+"!U;G-I9VYE9"!A9V4@*3L-"B @("!V:7)T=6%L(&-O;G-T M('-T9#HZ<W1R:6YG)B!N86UE*"D@8V]N<W0[#0H@(" @=FER='5A;"!U;G-I M9VYE9" @(" @(" @(" @86=E*"D@8V]N<W0[#0IP<FEV871E.@T*(" @('9I M<G1U86P@=F]I9"!D;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT M7V]A<F-H:79E)B!A<BP@=6YS:6=N960@=F5R<VEO;B I.PT*(" @('9I<G1U M86P@=F]I9"!D;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7VEA M<F-H:79E)B!A<BP@=6YS:6=N960@=F5R<VEO;B I.PT*(" @( T*(" @('-T M9#HZ<W1R:6YG(" @;F%M95\[#0H@(" @=6YS:6=N960@(" @("!A9V5?.PT* M?3L-"@T*<W1R=6-T('=H86QE(#H@<'5B;&EC(&UA;6UA; T*>PT*(" @('=H M86QE*"D[#0H@(" @=VAA;&4H(&-O;G-T('-T9#HZ<W1R:6YG)B!N86UE+"!U M;G-I9VYE9"!A9V4@*3L-"B @("!V:7)T=6%L(&-O;G-T('-T9#HZ<W1R:6YG M)B!N86UE*"D@8V]N<W0[#0H@(" @=FER='5A;"!U;G-I9VYE9" @(" @(" @ M(" @86=E*"D@8V]N<W0[#0IP<FEV871E.@T*(" @('9I<G1U86P@=F]I9"!D M;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7V]A<F-H:79E)B!A M<BP@=6YS:6=N960@=F5R<VEO;B I.PT*(" @('9I<G1U86P@=F]I9"!D;U]S M97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7VEA<F-H:79E)B!A<BP@ M=6YS:6=N960@=F5R<VEO;B I.PT*(" @( T*(" @('-T9#HZ<W1R:6YG(" @ M;F%M95\[#0H@(" @=6YS:6=N960@(" @("!A9V5?.PT*?3L-"@T*0D]/4U1? M0TQ!4U-?15A03U)47T=5240H(&%P92P@(F%P92(@*0T*0D]/4U1?0TQ!4U-? M15A03U)47T=5240H('=H86QE+" B=VAA;&4B("D-"@T*+R\O+R\O+R\O+R\O M+R\O+R\-"B\O(&]R9&5R:6YG<PT*#0IS=')U8W0@:6Y?;F%M95]O<F1E<@T* M>PT*(" @(&)O;VP@;W!E<F%T;W(H*2@@8V]N<W0@;6%M;6%L)B!L+"!C;VYS M="!M86UM86PF('(@*0T*(" @('L-"B @(" @(" @<F5T=7)N(&PN;F%M92@I M(#P@<BYN86UE*"D[#0H@(" @?0T*?3L-"@T*+R\O+R\O+R\O+R\O+R\O+R\- M"B\O('1E<W0-"@T*:6YT(&UA:6XH*0T*>PT*(" @('1R>0T*(" @('L-"@T* M(" @(" @("!U<VEN9R!N86UE<W!A8V4@8F]O<W0Z.F%S<VEG;FUE;G0[#0H@ M(" @(" @( T*(" @(" @("!B;V]S=#HZ<'1R7W9E8W1O<CQM86UM86P^('9E M8SL-"B @(" @(" @+R\@87-S:6=N('!O<W-I8FEL:71Y.B!O;F4@;75S="!B M92!A8FQE('1O('-P96-I9GD@=&AE('1Y<&4@=&\@8V]N<W1R=6-T#0H@(" @ M(" @("\O(&5G#0H@(" @(" @("\O('!T<E]A<W-I9VX\87!E/B@@=F5C("DH M(E@B+"!Y("D[(&%S<VEG;CQA<&4^*"!V96,@*2 ](&YE=R!!<&4H(")8(BP@ M>2 I.R -"B @(" @(" @+R\@<'1R7V%S<VEG;CQW:&%L93XH('9E8R I*")8 M(BP@>2 I.R -"B @(" @(" @=F5C("L](&YE=R!A<&4H(")&<F%N:R(L(#$R M("DL(&YE=R!A<&4H(")"971T>2(L(#D@*2P@;F5W('=H86QE*" B2F]N87,B M+" S," I+"!N97<@=VAA;&4H(")'97)D82(L(#(T("D[#0H@(" @(" @("\O M=F5C+G-O<G0H(&EN7VYA;65?;W)D97(H*2 I.PT*(" @(" @(" -"B @(" @ M(" @<W1D.CIO9G-T<F5A;2!O9G,H(")M86UM86QS+F1A="(@*3L-"B @(" @ M(" @8F]O<W0Z.F%R8VAI=F4Z.G1E>'1?;V%R8VAI=F4@;W5T7W1E>'0H(&]F M<R I.PT*(" @(" @("!O=71?=&5X=" \/"!V96,[#0H@(" @(" @(&]F<RYC M;&]S92(a)I.PT*(" @(" @("!S=&0Z.FEF<W1R96%M(&EF<R@@(FUA;6UA;',N M9&%T(B I.PT*(" @(" @("!B;V]S=#HZ87)C:&EV93HZ=&5X=%]I87)C:&EV M92!I;E]T97AT*"!I9G,@*3L-"B @(" @(" @8F]O<W0Z.G!T<E]V96-T;W(\ M;6%M;6%L/B!C;W!Y.PT*(" @(" @("!I;E]T97AT(#X^(&-O<'D[#0H@(" @ M(" @( T*(" @(" @("!F;W(H('-I>F5?="!I(#T@,#L@:2 \('9E8RYS:7IE M*"D[("LK:2 I#0H@(" @(" @(" @("!S=&0Z.F-O=70@/#P@=F5C6VE=(#P\ M(&-O<'E;:5T@/#P@)UQN)SL-"B @("!]#0H@(" @8V%T8V@H('-T9#HZ97AC M97!T:6]N)B!E("D-"B @("![#0H@(" @(" @('-T9#HZ8V]U=" \/"!E+G=H M870H*3L@#0H@(" @?0T*?0T*#0HO+R\O+R\O+R\O+R\O+R\O+R\O+R\O#0HO M+R!I;7!L96UE;G1A=&EO;B!A<&4-"@T*87!E.CIA<&4H*0T*>PT*?0T*#0IA M<&4Z.F%P92@@8V]N<W0@<W1D.CIS=')I;F<F(&YA;64L('5N<VEG;F5D(&%G M92 I(#H@;F%M95\H(&YA;64@*2P@86=E7R@@86=E("D-"GL-"GT-"B @(" - M"F-O;G-T('-T9#HZ<W1R:6YG)B!A<&4Z.FYA;64H*2!C;VYS= T*>PT*(" @ M(')E='5R;B!N86UE7SL-"GT-"B @(" -"G5N<VEG;F5D(&%P93HZ86=E*"D@ M8V]N<W0-"GL-"B @("!R971U<FX@86=E7SL-"GT-"B @(" -"G9O:60@87!E M.CID;U]S97)I86QI>F4H(&)O;W-T.CIA<F-H:79E.CIT97AT7V]A<F-H:79E M)B!A<BP@=6YS:6=N960@=F5R<VEO;B I#0I[#0H@(" @87(@/#P@;F%M95\@ M/#P@86=E7SL-"GT-"@T*=F]I9"!A<&4Z.F1O7W-E<FEA;&EZ92@@8F]O<W0Z M.F%R8VAI=F4Z.G1E>'1?:6%R8VAI=F4F(&%R+"!U;G-I9VYE9"!V97)S:6]N M("D-"GL-"B @("!A<B ^/B!N86UE7R ^/B!A9V5?.PT*?0T*#0HO+R\O+R\O M+R\O+R\O+R\O+R\O+R\O+R\O#0HO+R!I;7!L96UE;G1A=&EO;B!W:&%L90T* M#0IW:&%L93HZ=VAA;&4H*0T*>PT*?0T*#0IW:&%L93HZ=VAA;&4H(&-O;G-T M('-T9#HZ<W1R:6YG)B!N86UE+"!U;G-I9VYE9"!A9V4@*2 Z(&YA;65?*"!N M86UE("DL(&%G95\H(&%G92 I#0I[#0I]#0H@(" @#0IC;VYS="!S=&0Z.G-T M<FEN9R8(a)=VAA;&4Z.FYA;64H*2!C;VYS= T*>PT*(" @(')E='5R;B!N86UE M7SL-"GT-"B @(" -"G5N<VEG;F5D('=H86QE.CIA9V4H*2!C;VYS= T*>PT* M(" @(')E='5R;B!A9V5?.PT*?0T*(" @( T*=F]I9"!W:&%L93HZ9&]?<V5R M:6%L:7IE*"!B;V]S=#HZ87)C:&EV93HZ=&5X=%]O87)C:&EV928@87(L('5N M<VEG;F5D('9E<G-I;VX@*0T*>PT*(" @(&%R(#P\(&%G95\@/#P@;F%M95\[ M#0I]#0H-"G9O:60@=VAA;&4Z.F1O7W-E<FEA;&EZ92@@8F]O<W0Z.F%R8VAI M=F4Z.G1E>'1?:6%R8VAI=F4F(&%R+"!U;G-I9VYE9"!V97)S:6]N("D-"GL- A"B @("!A<B ^/B!A9V5?(#X^(&YA;65?.R -"GT-"@T* ` end

1 0

filesystem::change_extension doc error (1_31_0)
by Jeff Flinn 19 Apr '04

19 Apr '04

In http://www.boost.org/libs/filesystem/doc/convenience.htm#extension under the heading change_extension appears: path basename( const path & ph, const std::string & new_extension ); which should read: path change_extension( const path & ph, const std::string & new_extension ); Jeff F

2 1

Boost views library
by Vladimir Prus 19 Apr '04

19 Apr '04

Hi Roland, [I'm sending this message both to the list and to you personally in case you don't read the list regularly]. I'm wondering what's the status of your "views" library, which is now in Boost sandbox? I'm rather interested to use it and see in in Boost, and I have some questions: 1. Do you plan to work on it anytime soon and push it to review? 2. It (specifically filter_iterator) does not work for me (see the attached compile log). Is there any change you'll fix the problems? Will it be OK if I fix the problems? 3. I would have expected that there is some common 'view' class which provides definitions for typedefs and functions like 'empty' and that individual views only define methods which really differ, like begin/end. Was this design ever considered. 4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like: for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....); Is it possible add such functions? - Volodya

2 6

[Serialization] Formal Review
by Matthew Vogt 19 Apr '04

19 Apr '04

Formal review points: * What is your evaluation of the design? The design is rather complex - it certainly allows great flexibility, at the cost of ready comprehensibility. I realise that the complexity has accrued as a result of the library's extensive 'generalisation' phase; it would be nice to see a brief 'design and evolution' section in the documents. It's a little hard to comment on the design without having participated in the first review; I hope other reviewers can address this. * What is your evaluation of the implementation? The implementation seems quite clean, and well ordered. I think the comments in the code need a review pass, since they are occasionally out-of-sync with the code they comment upon. Also, it would be nice to see a bit more commentary on the purpose of the various classes that make up the implementation, which aren't covered by the documentation. The library includes part of the code as '.ipp' files, for inclusion into user '.cpp' files. This is not a common practise in boost libraries; perhaps it needs to be documented somewhere in the Boost:More Information section. * What is your evaluation of the documentation? The documentation is excellent. The layout is ideal, progressing through tutorial, reference and implementation sections. 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 :) ) I think the 'Advice' section is redundant; these points should be moved to the relevant reference section instead. * What is your evaluation of the potential usefulness of the library? I think the library is potentially of very wide applicability, due largely to its extensibility in the separate domains of types and archives. * Did you try to use the library? With what compiler? Yes, with GCC 3.2.2, without problems. * How much effort did you put into your evaluation? I read the documentation closely, investigated portions of the implementation, and tried to extend the library with types and archives. * Are you knowledgeable about the problem domain? Yes, and no; the library's applicability is broad, so few people will have extensive knowledge of the whole problem domain. I am more familiar with serialization for marshalling than for persistence, or for interoperability. * Do you think the library should be accepted as a Boost library? Yes. I can't think of any major issues that would force further re-design in the library, although new implementation detail issues are surely likely; I think it should be accepted now. Addressing Jeff's questions: 1) This is a large, complex, and important library. Please don't wait till the end of the review period to start your review -- there is no additional room in the review schedule to extend the review period. This is a brief review; please ask if you would like detail on any response. 2) I am particularly interested in hearing from parties that have tried to extend the library by adding serialization for a new type or by building a new type of archive. The ability to easily extend the library for new types and novel types of archives is critical for this library. As mentioned earlier, I think that the documentation covers the handling of types better than extension with archives. The section 'New Archives' needs to address the difference between overriding 'save' and 'save_override', and 'operator>>'. Also, discussion of the archive's preamble, and how to disable or modify it seems to be necessary. 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. 3) If you reviewed the library during the first review, I would like your evaluation of whether the new version of the library addresses your original concerns. Also, if this is a re-review I would appreciate if you could send me a weblink from the mail archive to your original review posting(s). Not me. 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. 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. The code dealing with XML formatting and escaping is in a similar situation. Thanks Robert, for your efforts Matt

1 0

VC8!!!
by firingme 19 Apr '04

19 Apr '04

Welcome to use Microsoft Visual C++ 8.0 tools. Setting environment for using Microsoft Visual C++ tools. E:\VC8>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.30703.05 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ]

6 5

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

19 Apr '04

Matthew Vogt writes: > Actually, XDR and CDR are of secondary interest for me; For me too, but these have be much requested and finishing these off in a polished way will be significant contribution to the library for many users. > I'm interested in > being able to save to proprietary formats (which often means that the > applications involved never got around to specifying a standard > format...). There must be thousands of ad-hoc binary formats in use > today. Hmmm - I'm a little wary of this. Though I'm not sure I know what you mean. Some persons interested in the library have hoped it can be used to generate some specific format. But that format doesn't accommodated all the information required to rebuild and arbitrary C++ data structure so in order to do one ends up coupling the serialization of classes to the archive format - just exactly what the serialization library is designed to avoid. Actually, My current thinking is to add a section to the documentation ( I love my documentation ! Many people have contributed to it by careful reading and criticism) which suggests a transition path from a proprietary format to usage of the serialization library. This transition would be basically a) make a program which loads all your "old" data in the "old" way. b) serialize the structures. So I'm skeptical of trying to adjust to "old" proprietary formats with the serialization library. >> 1) I wonder why you derived ordered_oarchive from >> basic_binary_oprimitive<Archive, OStream> > I'm using the save_binary / load_binary functions from > basic_binary_oprimitive > and basic_binary_iprimitive. Maybe we'll consider factoring this out into a standalone function. We'll keep and eye on this for now. In fact, if the salient feature of XDR is Endian awarness, alignment etc. I'm wondering if some of the functionality of your classes shouldn't be moved into your own version of load_binary thereby making inheriting the native one unnecessary. > 2) there's some stuff in boost that addresses alignment in a guaranteed? > Portable manner that may relevant here. Sse #include > <boost/aligned_storage.hpp> . BTW - the best way to make your code portable > without cluttering up with #ifdef etc... is to use more boost stuff - let > other people clutter up their code with #ifdef all over the place. > Yes, but the aligned_storage template helps with platform-specific > alignment within the machine. I don't see how it helps with > platform-independent alignment within the content of the archive... OK - I would like to see that made a little more transparent and better explained with comments. It's an important part of the issues being addressed. > 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. [ Points 4-6 conceded ] >> 7) I'm just a little queasy about using the term marshalling. In fact >> any of the archive implementations could be used for marshalling - not >> just a binary one (XML is the favorite flavor of the month). So I >> think it's sort of misleading. > Yes, I see what you're saying. I'll have a think about this - but the > term 'marshalling' is not particularly prevalent in the code. Even if > the term does have broad application, I think I am using it in the > traditional sense. Your library does marshalling ( as understand the term is usually used ). My complaint is that its too modest. Your library does more than that. When I started this library there was strong usage of the term "persistence" which lead to the misconception that the library had nothing to do with "marshalling". I see serialization as use in a number of things - persistence, marshalling and who knows what else? (e.g. generating a crc on the whole data state of the program to detected changes). That's why I went to much effort to avoid this characterization of the library. Your addition will gain strength from leveraging on this and by fitting in with the established pattern will be found easier to use. This will make it more successful. Also by following such a pattern it will almost entirely eliminate the need for special documentation. > 8) in my native binary archive, I used a template parameter for the stream > class. As it stands, I don't test or use the corresponding archive for wide > character streams because the WEOF would need special treatment. I haven't > spent any time on this. Perhaps you've addressed this in some way. > No, I was hoping you'd have it all sorted out - I've never used a stream > specialised with anything but char. In fact, it doesn't really make sense > to me, to produce binary output as anything but a byte stream - I was just > following your lead, really :) That's basically why I haven't spent any time on it. I made it templated on the stream class basically motivated by symmetry with the other archives. It should be finished by addressing the WEOF/EOF issue and using a code convert facet which turns the wchar_t interface into a byte stream. This way it would be useful to programs which are built around wchar_t rather than char. I suspect more programs in the future will do this. Its not very hard, but not of urgent interest. BTW - this might be better reason to derive from basic_binary_oprimitive. Robert Ramey

3 5

[Boost-bugs] [ boost-Bugs-937606 ] filesystem::directory_iterator returns incorrect listing
by SourceForge.net 19 Apr '04

19 Apr '04

Bugs item #937606, was opened at 2004-04-19 14:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=937606&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Roewen (s-a-t-a-n) Assigned to: Nobody/Anonymous (nobody) Summary: filesystem::directory_iterator returns incorrect listing Initial Comment: directory_iterator doesn't work correctly under debian linux (sarge/testing). Returns an invalid iterator value, which can cause a segmentation-fault, and drops the last item from the resulting listing. path dir = "my_dir"; if ( exists(dir) || !is_directory(dir) ) return; directory_iterator itr(dir), end; while ( itr != end ) { const path &p = *itr++; //-- do something with it } When I had a directory with only one file, no actual filenames were returned. When calling methods such as leaf() on const path &p, it would cause a seg-fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=937606&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 19 Apr '04

19 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Jueves, Abril 15, 2004 7:50 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal > How about just allowing any MPL sequence to specify the indices? mpl_index_list does precisely this. Check the MPL part in the advanced topics section of the docs. > > Also, it would be a nice syntactic convenience to allow the main > container template to accept a "variable" number of parameters, > and then > allow the indices to be specified as parameters directly to the main > container template. > Pardon? Do you mean something like multi_index_container < employee, ordered_unique<...>, unordered_unique<...> > without the index_list<> nesting? This cannot be done, as multi_index_container accepts an additional argument, the allocator class. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 7

Re:[boost] Serialization compile errors on CW9
by Robert Ramey 18 Apr '04

18 Apr '04

Miro Jurisic wrote: > I am trying to play with Serialization #18 on CodeWarrior 9, and I ran > into the following problems: > mbstate_t is not in the global namespace when using CW9 and MW STL > (I didn't test with gcc STL). This caused compile errors in > archive/codecvt_null.hpp. I altered the workaround already present for > Borland, but I believe this is the wrong answer, because it puts a using > declaration in a header file. We're open to suggestions. > That leaves me with the following two errors in compiling > text_oarchive.cpp... I am not sure what to do about these two errors, > but I am too tired to stare at them right now, so I am posting them here > in hope that someone can make sense out of them... the second error in > particular makes no sense to me at all. meeroh My formatting: > Error : illegal explicit conversion from > 'boost::iterator_facade< > boost::archive::iterators::insert_linebreaks< > boost::archive::iterators::base64_from_binary< > boost::archive::iterators::transform_width< > const char *, 6, 8, char > >, > Char > >, > 72, > Char > >, > char, > boost::single_pass_traversal_tag, > char, > char > >' > to 'const char *' ... I recently cleaned up and streamlined the implementation of the "dataflow iterators" in my local copy. I don't know if this will make the above disappear. I sort of doubt it. I'm suspicious of the transition from char to const char. I'll look at this. > Error : object > 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive> > ::text_oarchive_impl `base constructor'(std::basic_ostream<char, > std::char_traits<char>> &, unsigned int)' redefined This looks like a compiler issue in getting bool/int confused. Try Changing basic_text_oprimitive<std::ostream>( os, 0 != (flags & no_codecvt) ) At around line 63 in file text_oarchive.hpp to basic_text_oprimitive<std::ostream>( os, static_cast<bool>(0 != (flags & no_codecvt)) ) Robert Ramey

3 2

Serialization compile errors on CW9
by Miro Jurisic 18 Apr '04

18 Apr '04

I am trying to play with Serialization #18 on CodeWarrior 9, and I ran into the following problems: mbstate_t is not in the global namespace when using CW9 and MW STL (I didn't test with gcc STL). This caused compile errors in archive/codecvt_null.hpp. I altered the workaround already present for Borland, but I believe this is the wrong answer, because it puts a using declaration in a header file. Inside iterator_facade, I had to change: Derived const& derived() const { return static_cast<Derived const&>(*this); } to Derived const& derived() const { return *static_cast<Derived const*>(this); } Without that change, CW gives a warning saying that the function returns a reference to an automatic variable. I am pretty sure the warning is wrong, but this change silenced it, and I don't have the time to read over the spec to find out if the warning is correct or not. That leaves me with the following two errors in compiling text_oarchive.cpp... I am not sure what to do about these two errors, but I am too tired to stare at them right now, so I am posting them here in hope that someone can make sense out of them... the second error in particular makes no sense to me at all. meeroh Error : illegal explicit conversion from 'boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost::archi ve::iterators::base64_from_binary<boost::archive::iterators::transform_width<cons t char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>' to 'const char *' (instantiating: 'boost::archive::basic_text_oprimitive<std::basic_ostream<char, std::char_traits<char>>>::save_binary(const void *, unsigned long)') (instantiating: 'std::copy<boost::archive::iterators::insert_linebreaks<boost::archive::iterators ::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, boost::archive::iterators::ostream_iterator<char>>(boost::archive::iterators::ins ert_linebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iter ators::transform_width<const char *, 6, 8, char>, char>, 72, char>, boost::archive::iterators::insert_linebreaks<boost::archive::iterators::base64_fr om_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, boost::archive::iterators::ostream_iterator<char>)') (instantiating: 'boost::operator!=<boost::archive::iterators::insert_linebreaks<boost::archive::i terators::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char, boost::archive::iterators::insert_linebreaks<boost::archive::iterators::base64_fr om_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>(const boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost::archiv e::iterators::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char> &, const boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost::archiv e::iterators::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char> &)') (instantiating: 'boost::archive::iterators::insert_linebreaks<boost::archive::iterators::base64_f rom_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>::insert_linebreaks<boost::iterator_facade<boost::archive::iterators::insert _linebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iterato rs::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>>(boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost: :archive::iterators::base64_from_binary<boost::archive::iterators::transform_widt h<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>)') (instantiating: 'boost::archive::iterators::base64_from_binary<boost::archive::iterators::transfo rm_width<const char *, 6, 8, char>, char>::base64_from_binary<boost::iterator_facade<boost::archive::iterators::inser t_linebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iterat ors::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>>(boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost: :archive::iterators::base64_from_binary<boost::archive::iterators::transform_widt h<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>)') (instantiating: 'boost::archive::iterators::transform_width<const char *, 6, 8, char>::transform_width<boost::iterator_facade<boost::archive::iterators::insert_l inebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iterators ::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>>(boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost: :archive::iterators::base64_from_binary<boost::archive::iterators::transform_widt h<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>)') transform_width.hpp line 105 super_t(Base(BOOST_MAKE_PFTO_WRAPPER(static_cast<T>(start)))), Error : object 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::text_oarchive _impl `base constructor'(std::basic_ostream<char, std::char_traits<char>> &, unsigned int)' redefined (instantiating: 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::text_oarchive _impl `base constructor'(std::basic_ostream<char, std::char_traits<char>> &, unsigned int)') text_oarchive.hpp line 61 text_oarchive_impl(std::ostream & os, unsigned int flags = 0) : -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

3 2

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

17 Apr '04

Matthew Vogt wrote: > Is anyone else interested in using Robert Ramey's serialization library > for the purpose of marshalling data into pre-determined binary formats? Interest has been expressed for XDR in the past. Basically, I see this as a very positive thing and want to do everything I can to support your efforts. Your code supports save and load for two new formats (XDR and CDR). This is a valuable contribution. I'm also pleased that the serialization library has been deemed (at least by one person) to be worthy of investment of such an effort ( 1500 lines of code !). I took a little time to scan your attachments. My examination was cursory and feel free to correct any thing I didn't get right. Here are my comments. 1) I wonder why you derived ordered_oarchive from basic_binary_oprimitive<Archive, OStream> . It doesn't seem that any of the functionality basic_binary_oprimitive actually used. I presume the same goes for ordered_iarchive . 2) there's some stuff in boost that addresses alignment in a guaranteed? Portable manner that may relevant here. Sse #include <boost/aligned_storage.hpp> . BTW - the best way to make your code portable without cluttering up with #ifdef etc... is to use more boost stuff - let other people clutter up their code with #ifdef all over the place. 3) I'm curious about the override for the saving of vector. It seems to me equivalent to the one included with the system. And if vector requires special treatment, what about the list, et al. This doesn't seem necessary to me. Perhaps the fact that I did treat strings specially was misleading. I considered this a special case. I don't think vectors are in this context. 4) Missing license, authorship etc. Also add more comments and description and explanation of motivation for things that might not be obvious. This is a work of literature and art that will live for a long time - make it worthy. 5) I took great pains to organize code so that users of the library would not be including things that were strictly implementation. This is the origin of the *.ipp files. You might want to consider the same. Any template that does have a serializable type as a parameter (ie only archive) is a candidate for this treatment. In fact I would like to see a more "formal" separation of interface and implementation. 6) Get the bjam system running if you haven't already. It would be quite easy to add your archives to the set tested. Currenty, the test system runs about 30-40 tests on each archive type. It's a torture test ( and still I'm finding bugs). I think it would take you maybe an hour to tweak the bjam script and the code in serialization/test/test_tools.hpp to run all the tests on your own archive classes - ( maybe I should add information on doing this to the manual - it never occurred to me that someone would get to this point so soon) This is an absolute must if you want to have your addition seriously considered. 7) I'm just a little queasy about using the term marshalling. In fact any of the archive implementations could be used for marshalling - not just a binary one (XML is the favorite flavor of the month). So I think it's sort of misleading. I think it is very helpful that your naming scheme xdr_oarchive, cdr_oarchive, leverages on the existing one. 8) in my native binary archive, I used a template parameter for the stream class. As it stands, I don't test or use the corresponding archive for wide character streams because the WEOF would need special treatment. I haven't spent any time on this. Perhaps you've addressed this in some way. I didn't look in that much detail. I suspect that's enough to keep you motivated. Good luck and thanks for working on and with the library. Robert Ramey

2 1

[date-time] special value problem
by Pavol Droba 17 Apr '04

17 Apr '04

Hi, I have a problem with the date-time library. I have a code like this: namespace date=boost::gregorian; date::date dtMin(date::min_date_time); cout << dtMin << endl; Last line throws out-of-range exception. As far as I understand the meaning of min_date_time, this should not happen. If this is a standard behaviour, how can I get the minimal displayable date? Thanks, Pavol

2 2

heads up : free version of MSVC71 available!
by Bronek Kozicki 17 Apr '04

17 Apr '04

Just released: http://msdn.microsoft.com/visualc/vctoolkit2003/ It contains full version of *optimizing* compiler and linker, identical with ones present in Visual Studio .NET 2003 Professional. Included full implementation of standard C and C++ libraries, linked statically (sorry Boost.Thread) and few samples (plus support for .NET, as usual). Whole download is 32MB, Windows 2000/XP/2003 required to run. No IDE, no ATL, no MFC - just good C++ optimizing compiler run from command line and great implementation of C++ standard library, everything available for free under liberal license. B.

1 0

Re: [boost] Thoughts on Unicode and Strings
by Reece Dunn 17 Apr '04

17 Apr '04

Marshall Clow wrote: >>>"Reece Dunn" writes: >>> > 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. >I'm pretty sure that this is a bad assumption. Why is this a bad assumption? At the unicode_string level, we are talking about individual Unicode characters as specified by unicode.org. As an example, U+0x20 (space) can be represented simply on all encodings; U+0x2192 (left arrow) requires 2 bytes for UTF-8 encoding; U+0x1Dxxxx (I think these are the Fractur characters) require 3 UTF-8, 2 UTF-16 and 1 UTF-32. By treating a Unicode string as a virtual UTF-32 string (no matter what the underlying encoding is) makes it easier to use on a higher level, because you are dealing with the characters as they are represented on the Unicode tables. This makes it easier if there are mixed-width characters in the string: U+0x300A hello U+0x300B ==> [<<] hello [>>] >You can't just ignore combining characters. I am not ignoring combining characters. All I'm saying is that dealing with grapheme clusters at this stage makes processing Unicode strings too complex. They should be treated as a view *on top of the underlying unicode_string represtentation*. >I believe that Miro posted an example of how (even using UTF-32), you >may not have a single character <<-->> single "entry" mapping. I understand that now (see my other post), but dealing with it all at one level would make the interface too complex and would become too difficult to manage. You could have something like: struct grapheme_cluster: public std::pair< unicode_string::utf32_iterator, unicode_string::utf32_iterator > { inline grapheme_cluster( unicode_string & us ): std::pair< unicode_string::utf32_iterator, unicode_string::utf32_iterator > ( us.utf32_begin(), us.utf32_end()) { } ... inline bool is_single() const { return( first == second ); } inline unicode_string::utf32_t get_base() const { return( *first ); } bool advance(); // implementation defined; false iff end of string ... }; NOTE: if is_single() is true, then is_base() will be the value of the unicode character, otherwise it is the primary character with the combining characters removed. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

boost on HP-UX 11i
by DY, JERRY U (SBCSI) 17 Apr '04

17 Apr '04

Hi, I recently downloaded boost libraries to use the smart_ptr libraries. It appears to be working. But several other libraries, as shown by the compiler report is not. I also noticed that last run date is 9 months ago. Is anybody working on getting boost to work on aCC? I would be very surprised if nobody has tried before since HP is a top-tier vendor, but I couldn't find any useful information from the archives. If not, I would like to take a stab at getting it to work. I have contact with HP aCC techs to fix problems if it is a compiler problem. I'm particularly interested in getting the libraries regex and spirit (for now, more later) to work. I did a search on the boost archive and the last reference to this subject was written back in August 14, 2003: [boost] Re: Release of 1.30.2 imminent by David Abrahams other posts by this author Aug 14 2003 2:47PM messages near this date > On HP-UX: > aCC53800: http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#optiona l_test-a cc > aCC33380: http://boost.sourceforge.net/regression-logs/cs-hpux-links.html#optional _test-ac c > > This is a compiler crash. aCC is definitely broken beyond repair. I'm not going ot worry about that Thanks! -Jerry

3 2

minute patch: boost/config/posix_features.hpp
by Ralf W. Grosse-Kunstleve 17 Apr '04

17 Apr '04

We experience compiler errors using MIPSpro C++ under IRIX. The problem goes away if we apply this patch: Index: boost/config/posix_features.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/posix_features.hpp,v retrieving revision 1.15 diff -r1.15 posix_features.hpp 79c79 < # if defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE >= 500) --- > # if defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500) I can check this in, but I wanted to ask first if the "+0" was left off intentionally. It seems unlikely because "+0" is used consistently everywhere else, but just in case, is my patch OK? Thanks, Ralf __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

2 1

Re: [boost] Thoughts on Unicode and Strings
by Reece Dunn 16 Apr '04

16 Apr '04

Jeremy Maitin-Shepard wrote: >"Reece Dunn" writes: > > [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.) >I am not sure what you mean by "governed by locale." I believe the What I meant was that things like character identification, upper/lower case conversion, etc. would be in the locale, although I did not express this too well. I know there are issues associated with using locales and I have very little experience with them to comment. > > 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 >. > >I do like this idea, although I think something like this might be >better: > >template <encoding enc, class Container = ...> class unicode_string; > >"encoding" would be an enumeration type, such that enc would specify >one of UTF-8, UTF-16, or UTF-32. This is, I would say, a more explicit >way to specify the encoding that relying on the size of the type >specified, and also it avoids problems in cases where the platform does >not have distinct types for UTF-16 and UTF-32 code units (unlikely, I >admit). That would be a better idea. You would need something like: template< int > class encoding_type{}; class encoding_type< utf8_enc >{ typedef char type; } // ... template < encoding enc, template< typename T, class A = std::allocate< T > > class Container = std::vector > class unicode_string: public Container< encoding_type< enc >::type > { ... }; >One issue which would need to be dealt with is that while it seems >necessary for some containers, such as a rope, to have direct access to >the container, publicly inheriting this unicode_string from the >container type means that the additions to the interface must be more >limited. I don't get this. Surely the roped_vector, or whatever rope-like container is used, will have an STL container interface like std::vector so you would use them interchangeably. The unicode_string facilities would make use if the insert/append functions, iterators, etc of the storage container to implement their specific facilities. Thus, all the rope internals would be handled by roped_vector (or whatever the rope container is called), allowing you to use it like a std::vector, so the user of the container would be removed from the internals. This is the idea of having a Container as a template in the first place. > > [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. >This seems reasonable, although I practice the UTF-32/code-point >iterator would be the most likely to be used. Agreed, but the others would be useful: writing the string to a file as an example. This is why I suggest that the UTF-32 iterator is the default iterator (i.e. unicode_string::iterator is a UTF-32 iterator). > > 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. >I would say there is not much need to provide "specialist wrappers" >over other libraries. Presumably, a lot of a Boost Unicode library >could use code from ICU, but there is no advantage in attempting to use >platform-specific facilities, and doing so would surely introduce >inefficiency and great complication. Okay. It was just an idea :) > > 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. >Yes, most processing would at the very least need to internally use >this code-point iterator. >There is a significant advantage, however, in standardizing on a single >POD-array representation as well, such that much of the library need not >be templated (and thus implemented largely in header files, and thus >compiled each use), and less efficient functions could also be provided >which allow arbitrary iterators through runtime polymorphism. I think >it will be particularly important to examine this trade-off, because >Unicode support involves a large number of heavy-weight facilities. Agreed. However, this is contradictory to allowing the user to specify the container used for string storage. Maybe having a templatized version for users that want a custom storage policy, like a rope, and a static representation (UTF-16?) for those that are not bothered about how the unicode string is stored. The interfaces of these should be the same to allow the higher-level facilities to interoperate with both representations. > > [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" )). > >Well, except that you would want the strength, etc. to be adjustable, >and of course localized, and string literals pose additional problems... The logic behind this was for unicode_string to deal with navigating through the internal represtentation and mapping to the internal representation. The find functions, etc could then be implemented by iterating over the UTF-32 iterators and could be done as a template, e.g. string algorithms. > > 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. > >These code point groups are referred to as grapheme clusters, and I >certainly agree that it is necessary to provide an iterator interface >to grapheme clusters. I would not suggest, however, that normalization >be integrated into that interface, because only a small portion of the >possible grapheme clusters can be normalized into a single code point, >and I don't think it is a particularly common operation to do so, >especially for only a single grapheme cluster. That makes sense. Going further into grapheme clusters would be too complicated for a generic unicode library, as you would need to then consider how to map the cluster into the appropriate font: this would be platform specific and far too complex (e.g. overlaying combining marks, etc.)! Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Re: boost::thread, win32 implementation woes
by Patrick Dreyer 16 Apr '04

16 Apr '04

Markus Schöpflin wrote: > Boosters, > > there are some pitfalls using boost::thread on the win32 plattform > if DLLs are involved. As I could find nothing in the documentation > mentioning this I would like to ask if a strong warning could be > added, that creating threads in DllMain() or in a global object > living in a DLL will deadlock. This is especially suprising as > using _beginthread() or CreateThread() does work in such places. > > The problem is, when boost::thread creates a thread it explicitly > waits for the start up of the newly created thread. But if the > creator of the thread itself is in DllMain() or something alike > the newly created thread won't start until the creator leaves > DllMain(). > > The documentation for CreateThread() in the plattform SDK says > the following on this subjekt: "During process startup and DLL > initialization routines, new threads can be created, but they > do not begin execution until DLL initialization is done for the > process." My knowledge tells me, that you should not do any "complex" things during the Dll initialization, including starting threads. Have a look into the MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… There it says: ----- Begin MSDN DllMain ----- The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary), because this can result in a DLL being used after the system has executed its termination code. It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. It is common for the entry-point function to create synchronization objects such as critical sections and mutexes, and use TLS. Do not call the registry functions, because they are located in Advapi32.dll. If you are dynamically linking with the C run-time library, do not call malloc; instead, call HeapAlloc. Calling imported functions other than those located in Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions in their DLLs call LoadLibrary to load other system components. Conversely, calling those functions during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized. Because DLL notifications are serialized, entry-point functions should not attempt to communicate with other threads or processes. Deadlocks may occur as a result. Note: To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Otherwise, you can have the initialization routine create a named mutex, and have each routine in the DLL call the initialization routine if the mutex does not exist. Be sure to use a unique mutex name for each process that loads the DLL. ----- End MSDN DllMain ----- The second last paragraph tells you why boost::thread causes a deadlock. But as I pointed out below: try not to do any "complex" things during the Dll initialization. I recommand to revise your design. I'm sure there is a simpler and cleaner solution than to having a thread started during the Dll initialization. Patrick

2 1

Re: [boost] Re: Serialization Formal Review #2
by Robert Ramey 16 Apr '04

16 Apr '04

Thorsten Ottosen wrote: > class gps_position > { > public: > int degrees; > int minutes; > float seconds; > gps_position(){}; > gps_position(int d, int m, float s) : > degrees(d), minutes(m), seconds(s) > {} > }; > I think it should be stated that this is not recommended practice, ie, > this class has a non-trivial invariant and should not have public members. I might add a friend rather than use public. But this small code snipet is used to illustrate the non-intrusive serialization - nothing more. BTW the actual demo programs don't use this. What is the non-trivial invariant here? > A better example might be to use std::pair. > The examples use pointers in arrays and pointers in standard containers. I > think the text shouldstate that this is not recommended; or even better, > throw in a shared_ptr instead. The code in the example is inherently > exception unsafe. > Therefore I also think that container< shared_ptr<T> > should be supported > by default whereas container< T* > is, well, ok if you don't have > exceptions somehow. Writing a good tutorial is much harder than it looks. My main motivation was to introduce one concept at a time. The basic building blocks of serialization are serialization of primitives, pointers and classes - both intrusive and non-intrusive. All the rest is the result of composition of these basic operations. My tutorial reflects this. That's why serialization implementations of standard library components such as pair, vector, etc are described at the end rather than at the beginning - they are not primitive operations. Anyway, I'll consider adding some comments to remind the reader of the intended purpose of he tutorial example. Robert Ramey

3 2

Re: Re: [boost] Serialization Formal Review #2
by Robert Ramey 16 Apr '04

16 Apr '04

Matthias Troyer wrote: > After a few tweaks - which I will report later - I got serialization to > compile on my installation of MacOS X. That is very good news - it's a platform I never tried. Please try and run the bjam test suite as well. > I have a question that does not seem to be addressed in the > documentation: What is the difference betweem save and save_override or > > load and load_override? > demo_fast_binary_archive.cpp uses save_override and load_override but I > could not find it documented? Making a new archive class is described in the section "New Archives - Implementation". The model for an archive class is: ///////////////////////////////////////////////////////////////////////// // class trivial_iarchive - read serialized objects from a input text stream class trivial_iarchive : public boost::archive::common_iarchive<trivial_iarchive> { // permit serialization system priledged access to permit // implementation of inline templates for maximum speed. friend class boost::serialization::load_access; // member template for loading primitive types. // Override for any types/templates that special treatment template<class T> void load(T & t); public: ////////////////////////////////////////////////////////// // public interface used by programs that use the // serialization library // the >> operator template<class T> trivial_iarchive & operator>>(T & t){ boost::serialization::load(* This(), t); return * This(); } // archives are expected to support this function void load_binary(void *address, size_t count); }; So in theory one has to implement the two undefined functions. For each primitive data type, int, float, etc. or any type designated as primitive define a "load" template for function to read them from the file. For each data type that you want to treat specially - rather than allowing the serialization library to do the job - define an overload for the >> operator. That should be all there is too it. The archive classes included in the library are much more elaborate for a number of reasons. Among others these are: a) portability to platforms which fail to support Partial Template Function Ordering. This is what make the load_override functions necessary so that we can apply the "extra argument" work around to simulate PTFO for these platforms. They are not part of an public interface but rather internal artifacts of the implementation of these archives. b) the desire that the archives be templates so that they could work with both char and wchar_t i/o c) the desire to factor out common code for text primitives so that it wouldn't have to be duplicated for xml and text archives. > I can implement an > optimized archive along the lines of demo_fast_binary_archive.cpp, but > extended to also support std::vector, std::valarray, ... Before doing that, I would suggest making a test application with the standard binary archive and try to get some baseline timings. I would be curious to know the results of this. Remember that the point of demo_fast_binary_archive.cpp isn't so much to propose a faster archive ( though it may be ) but really to illustrate how one might derived from one of existing archives to alter its behavior. Robert Ramey

2 1

Re: Re: [boost] Re: [serialization] + [boost.python serialization of python object
by Robert Ramey 16 Apr '04

16 Apr '04

Ralf W. Grosse-Kunstleve wrote: > Going off on a tangent: does the boost serialization library have support > for portable serialization of large arrays (e.g. std::vector<double>)? Yes - all STL templates are included. Robert Ramey

2 1

intrusive_ptr doc bug?
by Andreas Huber 16 Apr '04

16 Apr '04

Hi there >From intrusive_ptr.html: <quote> Every new intrusive_ptr instance increments the reference count by using an unqualified call to the function intrusive_ptr_add_ref, passing it the pointer as an argument. Similarly, when an intrusive_ptr is destroyed, it calls intrusive_ptr_release; this function is responsible for destroying the object when its reference count drops to zero. The user is expected to provide suitable definitions of these two functions. On compilers that support argument-dependent lookup, intrusive_ptr_add_ref and intrusive_ptr_release should be defined in the namespace that corresponds to their parameter; otherwise, the definitions need to go in namespace boost. </quote> It's the last 8 words that don't make much sense to me. That would force some libraries using intrusive_ptr to make using declarations or directives in headers. IMHO there's no other choice but to put the two functions in the global namespace for compilers that do not support ADL. What am I missing? Thanks & Regards, Andreas

2 2

Re: Re: Re: Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

"Peter Dimov" > The types in l_ are always add_value processed, the types in the other listN > that stores references to the arguments at the call site are not. In > > bind(f, a1, a2)(b1, b2); > > bind(f, a1, a2) creates a list2 that holds the values of a1 and a2, > add_value-processed. The call (b1, b2) creates a list2<B1&, B2&> that holds > references to b1 and b2. > > These are all implementation details. I don't see why you seem so worried > about them. In particular, add_value is only present because of the need to > support MSVC 6. On a compiler that supports partial specialization, it's > possible to use an unadorned list2<A1, A2> as l_. Many other implementation > variations are also possible. Okay, now that I know add_value is a workaround, that clears up a bit of my confusion. I'm working on a typelist variety of bind that works with Loki typelist defined functors. My apologies for my wording of my initial confusion with the bind library. I should have thought about asking why bind was designed thus in a less arrogant way than I initially asked. Hopefully bad first impressions on boost are forgotten faster than bad first impressions with parents. Best, John

1 0

Re:[boost] Re: [serialization] register_type and dll/so module
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > Thanks for the link. However, the current BOOST_CLASS_EXPORT mechanism > will not work with DLLs. That's because global/static variable (the > extended_type_info_typeid instance) is not shared by DLLs. > I guess we may have to make the serialization library a dll and export > the extended_type_info_typeid instance as a global variable. Clearly you understand the main issue here. I believe its fixable although I'm not sure that making the library a DLL in itself will addresse it. Basically we have to find the tweak so that there is one and only one type table be it in the main program or in the DLL of the library. I'm sure it will require a subtle adjustment in the library. If you managed to figure this out let me know. I'll also take a look at it. Robert Ramey

1 0

Re: [boost] [serialization] register_type and dll/so module
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > In the serialization library, when classes are never serialized directly > but rather through a pointer to the base class, the user need to call > register_type so that the archive contains information about the derived > classes. > However, sometimes those derived classes are implemented in another > dynamic loaded (dll/so) module. The type of the derived classes will > not be known at compile time. How can cope with this? Does the library > provide any facilities to help the user in this situation? This is still under consideration. Right now its not clear what the best way to handle this is. The package contains demo_pimpl and I have a demo_plugin example on my desk - but I don't think I'm ready to give a good answer to this question. Just going into speculation mode I would consider: a) build the library as a DLL. b) build the serialization of another type as another DLL c) use BOOST_CLASS_EXPORT for the ser d) pray that the type registration maintains a single type/key table in the main program or library DLL data space. So clearly we're into new territory here. Your questions suggest that you're taking the serialization library to places were no one has gone before. Just out of curiosity, what is the application you're working on? Robert Ramey

1 0

[serialization] + [boost.python] serialization of python object
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > According to the documentation of boost.python, > one can derive from c++ base class in Python and override the virtual > functions in Python. However, is it possible to serialize the objects > of the python class using the serialization library? I think we're a little ways off from that. If you want to get started now take a look Plugin Archive Adaptor in the manual section "Future Directions" Robert Ramey

4 3

Re: Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> So e.g. list1 is always instantiated with a reference type, to what? the original type, or the add_value processed type? > and thus it > also stores the arguments > as references. I still think that those types are processed by add_value before being used. The bind_t L template parameter is instantiated with a list of add_value modified types through list_av_N in the bind calls, which leads me to believe that the listN represented by l_ object in bind_t has types of either value<T>, reference_wrapper<T>, or other bind_t structures. So are the types stored in listN (A1, A2, ... ) ever the original type or the original reference type? Or are they always add_value<T> processed? Many thanks 4 your time, John

2 1

gcc34 , boost::random problem
by Neal D. Becker 16 Apr '04

16 Apr '04

In file included from /usr/include/boost/random.hpp:46, from TestPn.cc:1: /usr/include/boost/random/lagged_fibonacci.hpp: In member function `void boost::random::lagged_fibonacci_01<RealType, w, p, q>::init_modulus()': /usr/include/boost/random/lagged_fibonacci.hpp:276: error: `std::pow' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp: In member function `void boost::random::lagged_fibonacci_01<RealType, w, p, q>::seed(It&, It)': /usr/include/boost/random/lagged_fibonacci.hpp:309: error: `std::fmod' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp:310: error: `std::pow' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp: In function `std::basic_ostream<_CharT2, _Traits2>& boost::random::operator<<(std::basic_ostream<_CharT2, _Traits2>&, const boost::random::lagged_fibonacci_01<RealType, w, p, q>&)': /usr/include/boost/random/lagged_fibonacci.hpp:357: error: `std::pow' has not been declared In file included from /usr/include/boost/random/ranlux.hpp:25, from /usr/include/boost/random.hpp:47, from TestPn.cc:1: /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::init_modulus()': /usr/include/boost/random/subtract_with_carry.hpp:268: error: `std::pow' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::seed(uint32_t)': /usr/include/boost/random/subtract_with_carry.hpp:280: error: `std::fmod' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::seed(It&, It)': /usr/include/boost/random/subtract_with_carry.hpp:295: error: `std::fmod' has not been declared /usr/include/boost/random/subtract_with_carry.hpp:296: error: `std::pow' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In function `std::basic_ostream<_CharT2, _Traits2>& boost::random::operator<<(std::basic_ostream<_CharT2, _Traits2>&, const boost::random::subtract_with_carry_01<RealType, w, s, r, val>&)': /usr/include/boost/random/subtract_with_carry.hpp:351: error: `std::pow' has not been declared

1 0

reference binding
by Dill, John 16 Apr '04

16 Apr '04

> > Its learning curve is > > inherently steep and more importantly, it simply cannot be flattened by > > making bind less useful. > > I guess the current design gives maximal power; so it it seems ok. Requering > that the > user calls > > bind( f, local_copy( i ) ) > > would document that the programmer knows that f takes a reference, but that > it > can act on a copy. However, once you know the mechanism, you would be > irritated by such constraints. > > Thorsten I agree with Thorsten's point. The first inclination when binding a function with a reference is that the arguments passed to that bind functor is actually passed by reference. That is what you are actually saying in your bind statement. While having pass-by-value may be more convenient and occur more often, the counter-intuitiveness of the semantics will lead to subtle bugs in people's code who misunderstand or forget bind's behavior in this area. It is not a matter of reducing the power of bind or "hand-holding" as has been said, but enforcing the semantics of what the programmer is actually saying. If you are binding to a reference argument, you should not need a ref( arg ) to say that the argument really is a reference. If you are binding to a reference, and want to pass by value, let the programmer type the extra 5-10 characters and explicitly say that he's changing the semantics of the bind. I personally like "bind( f, value( i ) )" myself. All that would need to be done is to introduce a argument_traits type class that will wrap references with a reference_wrapper, and also provide a value() wrapper. If you are binding often to a reference and want to pass-by-value, you might need to re-evaluate your interface. Just my 2 cents. Best, John

4 3

RE: [boost] library for managing a large number of FILE objects
by Michiel Salters 16 Apr '04

16 Apr '04

I'm wondering whether this can be generalized. Basically, I imagine a class "virtually" holding objects of some type T, with the restriction that it may not hold more than N actual objects of type T, and holds data<T> objects to create the other objects. You'd have a policy<T> which would create a T from a data<T> and later destroy it. The assumption is that a data<T> would be a lot cheaper than an actual T. Your case would be a specialization with T==FILE* and data<T> being just the file name. The policy<FILE*>::create(data<FILE*>) method would call fopen, the policy<FILE*>::destroy() would fclose it. The default policy<T>::create( data<T> data_T ) can probably call new T( data_T ) and return that. Regards, Michiel Salters > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jody Hagins > Sent: vrijdag 16 april 2004 1:57 > To: boost(a)lists.boost.org > Subject: [boost] library for managing a large number of FILE objects > > > > I know that C++ IOStreams are supposed to take over the world, and > cstdio with FILE is considered taboo by some C++ > efficionados. However, > due to many reasons, lots of code still uses cstdio FILE I/O. > One issue > that comes up from time to time is the need to manage more files than > the OS will allow a single process to have open simultaneously. I > process tons of data, and this is an issue for me. I have developed a > small library that provides on-demand caching of FILE > pointers, so that > an application can "open" as many FILEs as necessary, and use them as > normal. A simple LRU eviction algorithm is used to reclaim FILEs when > "all" have been used. > > I was discussing this library with another developer, and he > said he has > seen several questions recently about a similar issue, and he > advised me > to ask if there was interest here. This library, however, > does not seem > "on the edge" enough though... > > A very simple example of how you can use the library (of course there > are better ways to do the following, but it is meant to be a > small easy > to use example). > > > // Open 10,000 FILEs > wjh::file_cache file_cache; > std::vector<wjh::cached_fptr> fp; > for (int i = 0; i < 10000; ++i) > { > std::stringstream strm; > strm << "FILE_" << i; > wjh::cached_fptr fptr = file_cache.open(strm.str().c_str(), "w"); > if (!fptr) > { > std::cerr << strm.str() << ": " << strerror(errno) << std::endl; > break; > } > fp.push_back(fptr); > } > > // Randomly write to a particular file. > for (int i = 0; i < 200000; ++i) > { > int x = rand() % fp.size(); > fprintf(fp[x], "file %d, iteration %d\n", x, i); > } > > > Is it something useful for more than just me (and the pitiful > souls who > work for me and must use it) on this list? > > Is it something worth posting here? > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

RE: [boost] Re: boost on HP-UX 11i
by DY, JERRY U (SBCSI) 16 Apr '04

16 Apr '04

Dave, >> I would be very surprised if nobody has tried before since HP is a >> top-tier vendor > >I have tried, but not in the last 9 months. HP may be "top-tier" but >if so their compilers have not proven to be of the same caliber as the >rest of the company, at least when it comes to compiling Boost code. >The number and severity of the compiler bugs, and the poor quality of >the error messages, made the job infeasibly hard. If you have notes that might be useful or helpful for me (to save me time), I would appreciate it. I have been quite successful in porting code over to aC++ over the years and have reported several compiler/linker/debugger bugs to the HP response center and worked with them to fix problems or find workarounds. The last one I helped fix was the ANTLR parser generator. I'm frantically reading the documentation ... the more I read, the more I like it. A lot of code that we have already written definitely would be better if we had boost years ago. Thanks! -Jerry

3 2

Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> > While having pass-by-value > > may be more convenient and occur more often, the counter-intuitiveness > > of the semantics will lead to subtle bugs in people's code who > > misunderstand or forget bind's behavior in this area. > > A bold prediction in the face of contradictory evidence. Can you elaborate? You may have no problems understanding the library, but the first time I tried to bind with a reference, I ran into the same confusion. I am speaking from my own limited experience with the library. I've read the documentation: // Start of docs The arguments that bind takes are copied and held internally by the returned function object. For example, in the following code: int i = 5; bind(f, i, _1); a copy of the value of i is stored into the function object. boost::ref and boost::cref can be used to make the function object store a reference to an object, rather than a copy: int i = 5; bind(f, ref(i), _1); // End of docs I know this makes it explicit that you need a ref or cref to have bind store a reference to an object, but there is no reasoning behind this design decision in the documentation, or that I can find in the implementation and I've not stumbled across it in the mail archives. Best, John

4 3

[serialization] register_type and dll/so module
by Li Lirong 16 Apr '04

16 Apr '04

Hi, In the serialization library, when classes are never serialized directly but rather through a pointer to the base class, the user need to call register_type so that the archive contains information about the derived classes. However, sometimes those derived classes are implemented in another dynamic loaded (dll/so) module. The type of the derived classes will not be known at compile time. How can cope with this? Does the library provide any facilities to help the user in this situation? Best regards, Lirong

2 3

[serialization] + [boost.python] serialization of python object
by Li Lirong 16 Apr '04

16 Apr '04

Dear All, According to the documentation of boost.python, one can derive from c++ base class in Python and override the virtual functions in Python. However, is it possible to serialize the objects of the python class using the serialization library? Thanks and best regards, Lirong

1 0

library for managing a large number of FILE objects
by Jody Hagins 16 Apr '04

16 Apr '04

I know that C++ IOStreams are supposed to take over the world, and cstdio with FILE is considered taboo by some C++ efficionados. However, due to many reasons, lots of code still uses cstdio FILE I/O. One issue that comes up from time to time is the need to manage more files than the OS will allow a single process to have open simultaneously. I process tons of data, and this is an issue for me. I have developed a small library that provides on-demand caching of FILE pointers, so that an application can "open" as many FILEs as necessary, and use them as normal. A simple LRU eviction algorithm is used to reclaim FILEs when "all" have been used. I was discussing this library with another developer, and he said he has seen several questions recently about a similar issue, and he advised me to ask if there was interest here. This library, however, does not seem "on the edge" enough though... A very simple example of how you can use the library (of course there are better ways to do the following, but it is meant to be a small easy to use example). // Open 10,000 FILEs wjh::file_cache file_cache; std::vector<wjh::cached_fptr> fp; for (int i = 0; i < 10000; ++i) { std::stringstream strm; strm << "FILE_" << i; wjh::cached_fptr fptr = file_cache.open(strm.str().c_str(), "w"); if (!fptr) { std::cerr << strm.str() << ": " << strerror(errno) << std::endl; break; } fp.push_back(fptr); } // Randomly write to a particular file. for (int i = 0; i < 200000; ++i) { int x = rand() % fp.size(); fprintf(fp[x], "file %d, iteration %d\n", x, i); } Is it something useful for more than just me (and the pitiful souls who work for me and must use it) on this list? Is it something worth posting here?

2 2

Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> Hello John, > > There's a big technical reason: > > If bind would have reference semantics, you could not do this: > > bind(f, 1, _1) > > Bind would have to take its arguments as > > template <class F, class A, class B, ...> > bind( F, A&, B&, ...) > > 1 is a non-const rvalue, which cannot be bound to non-const reference. I think I almost got it now, but I'm still a little confused about bind_template.hpp where the list template parameters are A1&, A2&, A3&, ... list1 for example stores a template parameter A1 as "A1 a1;". So this ends up not actually being a reference to a normal type T, but to the value<T> wrapper class? If not, what type is actually A1& in the listN declarations in bind_template.hpp? Thanks, John

2 1

Error in token_functions.hpp
by Joe Gottman 16 Apr '04

16 Apr '04

I am getting errors including the new version of token_functions.hpp without first including tokenizer.hpp. When I do, I get the following error (my compiler is VC++ 6.0): rror C2065: 'is_pointer' : undeclared identifier Including tokenizer.hpp first gets rid of the problem. I think you just need to add the line #include <boost/type_traits/is_pointer.hpp> to token_functions.hpp. Joe Gottman

1 0

Desired libraries - n-ary trees, hashing and arbitrary-precision ints
by Dave 16 Apr '04

16 Apr '04

Hello all, I just want to mention three libraries I have a need for which, I believe, are not currently in Boost. My purpose is to see if they are under development and what alternatives I have in the meantime. 1. A dictionary implemented in terms of a user-supplied hashing policy 2. A generic n-ary tree library parameterized by a vertex's user-defined satellite data; to be used in a generic state space search library I am writing and in storing a parse tree for an expression interpreter. Perhaps BGL could be used here????? Not sure of its appropriateness... 3. The frequently-requested arbitrary precision integer library Thanks, Dave

3 2

[serialization] Archives for binary marshalling
by mvogt＠juptech.com 16 Apr '04

16 Apr '04

For anyone interested in extending Robert Ramey's serialization library with derived archive types, the attached archives may be interesting. Included are an archive template for ordered binary marshalling output (big- or little-endian), and rudimentary specialisations for CDR and XDR formats. These aren't really new archives, since they derive from Robert's basic_binary archive classes, but they do demonstrate to some extent what needs to be done to modify the archive output. Issues I've had in extending the archives: - The difference between overriding 'save', 'save_override', 'vsave' and operator<< is not immediately obvious... - Controlling access to individual save/load overloads still has me stumped - There's something weird with initializing wchar_t's going on... Questions or comments welcome. Matt ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify mail.administrator(a)jupiters.com.au **********************************************************************

3 2

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 15 Apr '04

15 Apr '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Jueves, Abril 15, 2004 6:21 pm Asunto: [boost] Re: [indexed_set] revised naming proposal > Joaquín Mª López Muñoz <joaquin(a)tid.es> writes: > > >> > If I decided to rename index_list as indices: what > >> > would be your proposal for mpl_index_list? > >> > >> 'indexed_by_list<>' ? > >> > > > > Well, this is less satisfying, I'd rather "mpl" appear in the > name. What > > about "mpl_indexed_by"? > > Oof. What does this MPL stand for?? > Apart from index_list, there is an alternative construct called mpl_index_list such that, for example: mpl_index_list<mpl::vector<K1,...,Kn> > is equivalent to index_list<K1,...,Kn> mpl_index_list is provided as a convenience for MPL metaprograms synthezising instantiations of indexed_set. "mpl_indexed_by" is a possible renaming for "mpl_index_list" should we decide to rename "index_list" as "indexed_by". Suggestions for better names? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] suggestion on Serialization Library
by Robert Ramey 15 Apr '04

15 Apr '04

Allen Yao wrote: > It is not very convenient for me to use macros like > BOOST_SERIALIZATION_SPLIT_FREE, BOOST_SERIALIZATION_SPLIT_MEMBER to deal > with splitted load/save functions. Permit me to re-state your suggestion in order to test my understanding of it. Similar to the manner which we have created other serialization traits such as boost::serialization::version<T> create another one such as boost::serialization::split<T> Whose default implementation would return false. Please correct me if I've misunderstood this. It's a worthy idea. I'm not saying I'm convinced it's a good idea but certainly worthy of consideration. Here is my assessment. Currently to split serialize member function into save/load one uses template<class Archive> void serialize( Archive & ar, const unsigned int file_version ){ boost::serialization::split_member(ar, *this, file_version); } Or equivalently: BOOST_SERIALIZATION_SPLIT_MEMBER() With your suggestion this would change to: namespace boost { namespace serialization { struct split<my_class> { typedef mpl::false_ type; BOOST_STATIC_CONSTANT(bool, value = split::type::value); }; } // namespace serialization } // namespace boost Or in line with the other serialization traits: BOOST_SERIALIZATION_SPLIT (my_class So a) I don't see what would be gained as far as convenience, utility, and transparency compared to the current system. b) It would entail significant effort to implement and make the internals of the serialization library even more elaborate than they already are. c) It would require more documentation than the current system. > Additionally, when dealing with load/save functions of template class, > these macros help little. Users also have to read and understand what > these macros actually do and write their own serialize function to call > split_free or split_member accordingly. I don't think this change would help that situation. > I suggest that these implementation details on how the serialization > library determine to use single serialize function or splitted load/save > functions should be totally encapsulated and hidden behind the scene. This is widely held point of view that I don't always agree with. Sometimes hiding too much gives the illusion of ease of use but in fact introduces modal behavior which makes the operation hard to understand. In the worst cases it introduces a compile time global variable with compile time side-effects that are hard to trace back to the trait setting. So, I'm more wary about using traits than other people seem to be. > Am I missing something? I don't think you're missing anything. It would be possible to implement such an additional trait. We just disagree on whether it's a good idea. That's all. Robert Ramey

1 0

Re: [boost] Re: Re: Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 15 Apr '04

15 Apr '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Miércoles, Abril 14, 2004 7:25 pm Asunto: Re: [boost] Re: Re: Re: [indexed_set] revised naming proposal [...] > > Don't forget "indices" or "indexes" in lieu of "index_list." > > multi_index_container > < > employee, > indices< > ordered_unique<member<employee,string,&employee::name> >, > ordered_non_unique<member<employee,int,&employee:age> >, > > > > If I decided to rename index_list as indices: what would be your proposal for mpl_index_list? Leave it like that? (check the MPL section on the advanced topics page, in case you don't know about this construct.) Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 5

Big integer library
by Richard Peters 15 Apr '04

15 Apr '04

Hello, A few months ago there was some discussion about an arbitrary magnitude integer library. I have now implemented such a library, which is located at http://groups.yahoo.com/group/boost/files/big_integer/. There are a few (incomplete) other libraries that provide the same kind of functionality. The main difference between this library and other libraries is that this library uses expression templates to avoid the creation of temporary values, which when the values become large provide an increase in performance. The library is not finished yet: most noticeably the test files are far from complete, but there are also a few others things like the documentation looks a bit ugly. Also a to-do is replacing the core operations like addition and multiplication by more efficient ones, and provide options to use external libraries like GNU MP. I am presenting you already with this library though, to see if it meets the desires for this kind of library, to see if there are things missing in this library, and maybe get some help from other members interested in further developing this library. best regards, Richard Peters

2 1

Re: reference binding
by Dill, John 15 Apr '04

15 Apr '04

> So in summary, you weren't confused about how the library works; you > just were unhappy that you had no justification for how it works. > That lends no credence to your claim that "the counter-intuitiveness > of the semantics will lead to subtle bugs in people's code who > misunderstand or forget bind's behavior in this area." Alright. > P.S. if you want to understand the justification, see > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm Thanks, John

1 0

suggestion on Serialization Library
by Allen Yao 15 Apr '04

15 Apr '04

It is not very convenient for me to use macros like BOOST_SERIALIZATION_SPLIT_FREE, BOOST_SERIALIZATION_SPLIT_MEMBER to deal with splitted load/save functions. Additionally, when dealing with load/save functions of template class, these macros help little. Users also have to read and understand what these macros actually do and write their own serialize function to call split_free or split_member accordingly. I suggest that these implementation details on how the serialization library determine to use single serialize function or splitted load/save functions should be totally encapsulated and hidden behind the scene. I suggest that a traits class to be used by the user instead of macros like BOOST_SERIALIZATION_SPLIT_FREE. For example, the traits class can be named "serialization_traits", its default implementation is somthing as follows: template <typename T> struct serialization_traits { static const bool has_split_load_save = false; }; It can be (partially) specialized for types that has split load/save functions. Then, the serialization library can use this traits class to determine whether to call a single serialize function or splitted load/save functions for a specific type. Am I missing something? Best regards. Yao, Zhen

2 1

Re: Big integer library
by Richard Peters 15 Apr '04

15 Apr '04

One note on portability: the example and test file compile under Visual C++ 7.1 and gcc 3.2.2 best regards, Richard Peters ----- Original Message ----- From: "Richard Peters" <r.a.peters(a)student.tue.nl> > Hello, > > A few months ago there was some discussion about an arbitrary magnitude > integer library. I have now implemented such a library, which is located at > http://groups.yahoo.com/group/boost/files/big_integer/. > > There are a few (incomplete) other libraries that provide the same kind of > functionality. The main difference between this library and other libraries > is that this library uses expression templates to avoid the creation of > temporary values, which when the values become large provide an increase in > performance. > > The library is not finished yet: most noticeably the test files are far from > complete, but there are also a few others things like the documentation > looks a bit ugly. Also a to-do is replacing the core operations like > addition and multiplication by more efficient ones, and provide options to > use external libraries like GNU MP. > I am presenting you already with this library though, to see if it meets the > desires for this kind of library, to see if there are things missing in this > library, and maybe get some help from other members interested in further > developing this library. > > best regards, > > Richard Peters >

1 0

[Boost-bugs] [ boost-Bugs-935605 ] constructor of special_values
by SourceForge.net 15 Apr '04

15 Apr '04

Bugs item #935605, was opened at 2004-04-15 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935605&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: andrasiel (andrasiel) Assigned to: Nobody/Anonymous (nobody) Summary: constructor of special_values Initial Comment: I've a problem when trying to use the ptime constructor of special values ptime(special_values sv) Constructor for infinities, not-a-date-time ptime t1(neg_infin); ptime t2(pos_infin); ptime t3(not_a_date_time); gcc does not find this constructor and indeed it is not listed in the candidate list. the exact error is : -------------------------------------------------------- database.cpp:241: error: no matching function for call to ` boost::posix_time::ptime::ptime(boost::date_time::special_values)' /usr/include/boost/date_time/posix_time/ptime.hpp:32: error: candidates are: boost::posix_time::ptime::ptime(const boost::posix_time::ptime&) /usr/include/boost/date_time/posix_time/ptime.hpp:45: error: boost::posix_time::ptime::ptime(const boost::posix_time::int64_time_rep&) /usr/include/boost/date_time/posix_time/ptime.hpp:42: error: boost::posix_time::ptime::ptime(boost::gregorian::date) /usr/include/boost/date_time/posix_time/ptime.hpp:39: error: boost::posix_time::ptime::ptime(boost::gregorian::date, boost::posix_time::time_duration) --------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935605&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-935596 ] to_simple_string link problem
by SourceForge.net 15 Apr '04

15 Apr '04

Bugs item #935596, was opened at 2004-04-15 13:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935596&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: andrasiel (andrasiel) Assigned to: Nobody/Anonymous (nobody) Summary: to_simple_string link problem Initial Comment: 935571 time_from_string link problem (i'm the anonymous poster of that request ) I tried some other things like conversions from ptime std::string ts("2002-01-20 23:59:59.000"); std::cout<<boost::posix_time::to_iso_string(t1)<<std::endl; std::cout<<boost::posix_time::to_simple_string(t1)<<std::endl; std::cout<<boost::posix_time::to_iso_extended_string(t1)<<std::endl; the conversion from ptime to simple string return also a link error: Linking prog ... database.o(.gnu.linkonce.t._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthENS0_13simple_formatEE12format_monthERKS3_RSo+0x13): dans la fonction « boost::date_time::month_formatter<boost::gregorian::greg_month, boost::date_time::simple_format>::format_month(boost::gregorian::greg_month const&, std::basic_ostream<char, std::char_traits<char> >&)»: : undefined reference to `boost::gregorian::greg_month::as_short_string() const' (conversions to iso and iso extended are working) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935596&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

intel-win32 8.x config/ADL problem
by David Abrahams 15 Apr '04

15 Apr '04

Check it out, I can't get the following program to compile, even with -Qoption,c,--arg_dep_lookup: namespace ns1 { class X{}; int swap(X&, X&); } namespace ns2 { template <class T> void swap(T&, T&); } int main() { ns1::X x; using ns2::swap; int y = swap(x,x); } Shouldn't we be setting BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL for this compiler? It's actually a different bug in some details, I realize, but the macro does say the right thing. Also, where is the test for that macro? I don't see any in libs/config/test. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 7

regex lib: bug with sets and back ref
by Benzinger, Ralph 15 Apr '04

15 Apr '04

Hello, The following behavior seems to be a bug: * regex '([a-c]+)\1' finds 'abcabc' at offset 0 in text 'abcabc' * regex '([abc]+)\1' finds 'bcbc' at offset 1 in text 'abcbc' * regex '([a-c]+)\1' finds nothing in text 'abcbc' ??? Can anybody confirm this? Tried both POSIX and Perl syntax/match mode. Ralph

2 1

[Boost-bugs] [ boost-Bugs-935571 ] time_from_string link problem
by SourceForge.net 15 Apr '04

15 Apr '04

Bugs item #935571, was opened at 2004-04-15 04:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935571&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: time_from_string link problem Initial Comment: I'm using libboost-date-time1.31.0 I have a link error when trying this code example : std::string ts("2002-01-20 23:59:59.000"); boost::posix_time::ptime t(boost::posix_time::time_from_string(ts)); Linking prog ... database.o(.gnu.linkonce.t._ZN5boost9date_time19month_str_to_ushortINS_9gregorian10greg_monthEEEtSs+0x119): dans la fonction « unsigned short boost::date_time::month_str_to_ushort<boost::gregorian::greg_month>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)»: : undefined reference to `boost::gregorian::greg_month::get_month_map_ptr()' collect2: ld a retourné 1 code d'état d'exécution source : http://www.boost.org/libs/date_time/doc/class_ptime.html ptime time_from_string(const std::string&) >From delimited string. std::string ts("2002-01-20 23:59:59.000"); ptime t(time_from_string(ts)) thank you al_x7(a)hotmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935571&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: [static_assert] Bad compiler message
by Reece Dunn 15 Apr '04

15 Apr '04

Vladimir Prus wrote: >Brian McNamara wrote: > > More generally, I would really like a Boost library which lets me > > generate custom error messages portably. >[snip] > > Is there interest in this? > >Sure. In particular, I'd like to see a number of static assertions added to >BGL, to make error messages less confusing. I would be interested in it, especially in relation to meta-programming intensive libraries like Spirit that can generate somewhat unwieldy error messages! Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

1 0

Burgeoning Move Semantics Library
by David Abrahams 15 Apr '04

15 Apr '04

I have to stop playing with this stuff and get back to work now, but over the weekend I started a library that allows a "reasonably convenient, useful amount" of move semantics. Many compilers implement enough (N)RVO that implicit moving from rvalues is unneccessary, and those seem to coincide roughly with the compilers where we have to internally shut off some capability because of the compiler's interpretation of 8.5.3/5 (**). So it seems you can pretty much eliminate all needless copies. Here's what you can do with the current state of the move library, which supplies macros (eeeeew!) to avoid code duplication: struct X : boost::movable<X> { BOOST_LVALUE_COPY_CTOR( X, (rhs)(: initializers...), { // copy ctor body }) BOOST_LVALUE_ASSIGN( X, (rhs), { // copy assign body }) X(move_from<X> rhs) { // move ctor logic } X& operator=(move_from<X> rhs) { // move assign logic } }; boost::movable<X> just encapsulates the conversion to move_from<X> and makes the copy ctor/assignment private, so you can always replace it with a written-out conversion to move_from<X> if you don't like the "MI non-EBO" (or other) impact of library-mandated inheritance. This work owes inspiration to Rani Sharoni's "improved auto_ptr" (http://tinyurl.com/2rxpj) and of course one must acknowledge Andrei Alexandrescu for being crazy enough to even try doing this in a library in the first place (Mojo). Eric Friedman had an earlier boost/move.hpp in the sandbox based on Mojo (which I replaced with his permission), and I adapted his tests, in addition to my own, to work with the new code. It might make sense to use this library to optimize selected Boost components; shared_ptr, any, and dynamic_bitset come to mind, just off the top of my head. You can find the code in boost/move.hpp and tests in libs/move/test/*.cpp. It "basically works" with all MSVC versions, Borland, gcc-2.95, gcc-3.3.1, comeau (strict warnings mode only, until I find out how to detect that we're in strict errors mode), and all intel-win32 versions. I don't know how to make gcc-3.2 work yet. The places where it fails, certain things seem to compile which one would prefer to cause an error. Enjoy, Dave (**) see http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1610.html -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 11

[serialization] all wide tests were failing
by Robert Ramey 15 Apr '04

15 Apr '04

> What this means is that destructor of archive *really should* call 'flush' > on the stream. After I've made basic_text_oprimitive's destructor to flush > stream: > template<class OStream> > basic_text_oprimitive<OStream>::~basic_text_oprimitive(){ > os.flush(); > } > The test_vector passed with wide stream. I'm rerunning other tests now. Good call. I never would have guessed this. > In fact, I'm getting suspicious about changing codecvt at all. I suppose > that if somebody is using wide streams, he already deals with encoding > somehow, so why serialization library should try to second-guess the user? I have also started to have second thoughts about this. In the original version I didn't concern myself with codecvt . This created problems however: a) the i/o library silently used a codecvt facit that just narrowed the output characters - silently throwing away the high order bits on wide characters. This behavior was surprising, confusing and hard to find. b) even on char ouput, the default codecvt facet when through a large amount of code when all that was really necessary was to pass the characters through without change. That is, the standard library implementation picks a facet which may not behave in the manner that we (the user) expects. So I determined that I would "fix" this in the library. The state-saver system worked in perfectly. The possibility that it might not possible change the codecvt facet after the file is opened has made me wonder about this. I'm still undecided. The dinkumware library definitely works in this way and I believe that STL Port does also. Removing "automatic" imbue/unimbue to for the library would simplify the library and remove some "hidden" behavior - which I like. But it would also guarantee that many (or most) users would be getting something other than what they expect. I'm still considering this. Robert Ramey

2 1

message attachments missing?
by Robert Ramey 15 Apr '04

15 Apr '04

Am I the only one unable to open message attachments such as http://lists.boost.org/MailArchives/boost/attachments/20040415/31f013f2/mars halling.zip Or is something not functioning with the system? Robert Ramey

2 1

Yo, move semantics anyone - errors in move.cpp example
by Roman Yakovenko 15 Apr '04

15 Apr '04

Hi. The example "move.cpp" could not be compiled on MSVC 7.1. Reasons: 1. The obvious one X& operator=(X rhs) { std::cout << "ASSIGN #" << id << (owner?"":" (EMPTY)") << " <== #" << rhs.id << (rhs.owner?"":" (EMPTY)") << std::endl; owner = rhs.owner; rhs.owner = false; assert(owner); //MISSING RETURN VALUE; } 2. error C2664: 'sink' : cannot convert parameter 1 from 'const X' to 'X' Definitions: X const z7; void sink(X) Error location: std::cout << " ------ test 15, pass const lvalue by-value ------- " << std::endl; sink(z7); I think compiler is wrong here. It should call template <class T> X(T& rhs, typename enable_if_same<X const,T>::type = 0) constructor. Or may be I wrong, and missed something Roman > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Wednesday, April 14, 2004 5:05 PM > To: boost(a)lists.boost.org > Subject: [boost] Yo, move semantics anyone? > > > Hi, > > I'm just wondering if the deafening silence indicates a lack of > interest or whether something else is going on? > Feedback would be appreciated. > > Thanks! > > David Abrahams <dave(a)boost-consulting.com> writes: > > > I have to stop playing with this stuff and get back to work now, but > > over the weekend I started a library that allows a "reasonably > > convenient, useful amount" of move semantics. Many compilers > > implement enough (N)RVO that implicit moving from rvalues is > > unneccessary, and those seem to coincide roughly with the compilers > > where we have to internally shut off some capability because of the > > compiler's interpretation of 8.5.3/5 (**). So it seems you > can pretty > > much eliminate all needless copies. > > > > Here's what you can do with the current state of the move library, > > which supplies macros (eeeeew!) to avoid code duplication: > > > > struct X > > : boost::movable<X> > > { > > BOOST_LVALUE_COPY_CTOR( > > X, (rhs)(: initializers...), > > { > > // copy ctor body > > }) > > > > BOOST_LVALUE_ASSIGN( > > X, (rhs), > > { > > // copy assign body > > }) > > > > X(move_from<X> rhs) > > { > > // move ctor logic > > } > > > > X& operator=(move_from<X> rhs) > > { > > // move assign logic > > } > > }; > > > > boost::movable<X> just encapsulates the conversion to > move_from<X> and > > makes the copy ctor/assignment private, so you can always replace it > > with a written-out conversion to move_from<X> if you don't like the > > "MI non-EBO" (or other) impact of library-mandated inheritance. > > > > This work owes inspiration to Rani Sharoni's "improved auto_ptr" > > (http://tinyurl.com/2rxpj) and of course one must acknowledge Andrei > > Alexandrescu for being crazy enough to even try doing this in a > > library in the first place (Mojo). Eric Friedman had an earlier > > boost/move.hpp in the sandbox based on Mojo (which I > replaced with his > > permission), and I adapted his tests, in addition to my own, to work > > with the new code. > > > > It might make sense to use this library to optimize selected Boost > > components; shared_ptr, any, and dynamic_bitset come to > mind, just off > > the top of my head. > > > > You can find the code in boost/move.hpp and tests in > > libs/move/test/*.cpp. It "basically works" with all MSVC versions, > > Borland, gcc-2.95, gcc-3.3.1, comeau (strict warnings mode > only, until > > I find out how to detect that we're in strict errors mode), and all > > intel-win32 versions. I don't know how to make gcc-3.2 work yet. > > The places where it fails, certain things seem to compile which one > > would prefer to cause an error. > > > > Enjoy, > > Dave > > > > (**) see http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1610.html > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

tools/regression/run_tests.sh
by Jody Hagins 14 Apr '04

14 Apr '04

Straight out of CVS, run_tests.sh has the following on line 88: export BOOST_BUILD_PATH="$boost_build_path" "$BOOST_BUILD_PATH" which, of course, generates an error. Does anyone know the intent of this line? I can think of two obvious possibilities... 1. Prepend $boost_build_path to BOOST_BUILD_PATH, in which case it should be something like: if [ "${BOOST_BUILD_PATH}" ]; then BOOST_BUILD_PATH="$boost_build_path:$BOOST_BUILD_PATH" else BOOST_BUILD_PATH="$boost_build_path" fi which is a bit verbose, but probably necessary for max /bin/sh portability. 2. Just set it to boost_build_path: BOOST_BUILD_PATH="$boost_build_path" However, there could be some other intent, so I am not sure how I want to fix this. Anyone know? Thanks! -- Jody Hagins

2 4

Re: [boost] Re: Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 14 Apr '04

14 Apr '04

Hi Rob, ----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 12, 2004 11:17 pm Asunto: Re: [boost] Re: Re: [indexed_set] revised naming proposal > From: =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= <joaquin(a)tid.es> > > De: Rob Stewart <stewart(a)sig.com> > > [index_list naming] > Now that I am, what about changing it to "indexes" or "indices" > according to your preference? IOW, I don't think "list" needs to > be part of the name at all. That name works fine regardless of > whether it is elaborated. It does not look bad, actually. But I'm really trying to narrow the target down now. Do you have strong objections to index_list? Nobody else complained. [moving into boost::container] > > Well, it's all about not wasting effort. Hopefully, some > > other boosters (and the authors of container libraries > > in Boost) will jump in and express themselves for a > > That will be ideal. I wasn't paying attention, but has this been > addressed in a separate thread with an appropriate subject in > order to garner their involvement? No. I don't feel like rising the noise level more than now by beginning a new thread. IMHO, it's unlikely that this will get any more attention (and it could be that it does not deserve it after all.) [philosophical discussion about convenience of 1st level namespaces] (excuse my snipping) Well, just for the record, what's your "vote" about pushing/not pushing into boost:container? It is not clear to me which side you're a supporter of. So far, noone has expressed any strong opinion on either option. (btw, thanks for involving into this discussion) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

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

14 Apr '04

Rob wrote: >> >> Ok, but you need more than just LAST, you need LAST-1, LAST-2, and LAST-3 >Why? I can't imagine a good use case for wanting one, two, or >three days before the end of the month as a special form of date. To make this work: date d = January LAST-1; // the 30th add_month(d); d == February 27th or 28th depending on the leap year, add_month(d); d == March 30th; Which is why the specialized function is the way to go. LAST isn't enough and anything else is cumbersome, buggy and hard to maintain. Yours, -Gary-

2 1

RE: [boost] Re: Yo, move semantics anyone?
by Powell, Gary 14 Apr '04

14 Apr '04

>David Abrahams wrote: >> I'm just wondering if the deafening silence indicates a lack of >> interest or whether something else is going on? >The latter. Thanks for your efforts, I for my part will definitely have >a closer look on it when time allows. Stephan wrote: >BTW, what was the result of the proposal on clarification of this? Dave went to Sidney and pitched it. It passed as a Defect Report which is great news as it means that the current crop of compilers are required to fix this now not in N years when the C++0X standard is released. Yours, -Gary-

2 1

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

14 Apr '04

>From: Jody Hagins <jody-boost-011304(a)atdesk.com> >> "Powell, Gary" <powellg(a)amazon.com> wrote: >> >> > That would surprise me as well. >> > >> > date = January 30; >> > >> > add_month(date); >> > add_month(date); >> > >> > date == March 30 ? Not March 28/29 No? >I'd expect April 1st or 2nd, depending upon whether it was a leap >year. I'm not sure what you're saying you'd expect. I'd expect March 30th. >For my expected result, it would simply increment the month and >then check for the corresponding day of the month. If it's past >the end of the month, it falls back to advancing by 30 days. >Then, the logic is repeated by the second call. I understand what you think you want but in practice I don't think it would work out as nicely as you think now. >> Or, instead, you use something like... >> >> date = January END or LAST; >> >> meaning the last day of the month. Then, adding a month would always >> jump to the last day of the next month. I imagine with... >That would work well. Ok, but you need more than just LAST, you need LAST-1, LAST-2, and LAST-3 That's why I use seconds.. >> date = February 28; >> add_month(date); >> >> you would want March 28, and not March 31??? >Yes. I would expect this as well. the 28th is either LAST, or just plain old 28th. Personally I like Jeff's solution, that you provide the increment function. Because it sounds like we have different use cases for "next month" The loose case of "see you for your next appointment next month", and "delivery is in One Month". Where 30 days is the "next month" vs the calendar end. Yours, -Gary-

2 1

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

14 Apr '04

>Bob Bell wrote: >The interpretation that makes sense to me is: adding one month means the >same day of the next month, unless the date's not valid, in which case I >expect moving backwards to the latest date of said month. That's what >humans do when you say "next month", so I would think anything else >would be surprising. That would surprise me as well. date = January 30; add_month(date); add_month(date); date == March 30 ? Not March 28/29 No? Which means of course a lot of state has to be held by date, because otherwise February does rounding. As in the number of days until the end of the month. Yours, -Gary-

7 11

Date-Time
by Val Samko 14 Apr '04

14 Apr '04

I did not find any functions in Date-Time library to add a number of months to a given day, or to obtain the last/first day of the month. I mean something like date add_month(const date&, int month_count); date first_date_of_month(const date&); date last_date_of_month(const date&); I understand that I can use the month_iterator instead of add_month, and end_of_month_day instead of last_date_of_month, but since the functionality I described is heavily used in some applications (accounting for instance), it would be much simpler just to call add_month, ... functions. Is there any particular reason why they are not provided? Val Samko http://val.digiways.com

4 15

FSM offtopic question
by Erdei Andras 14 Apr '04

14 Apr '04

can someone suggest a free, preferably windoze tool for creating graphics represantion of FSMs ? something using an editable format, but allowing GIF/BMP/whatever export for documentation would be nice. tia andras

2 1

[serialization] all wide tests were failing because...
by Vladimir Prus 14 Apr '04

14 Apr '04

Robert, if you recall, all wide archive tests were failing for me. They still failed with #18, and now I finally (after quite some debugging) know why. The error I was getting was: Exception in "call_test_main": std::length_error: basic_string::reserve It occured even on test_vector, which is fairly simple. The generated data contained this: 22 boost::serialization .... note that this was for wide archive, where the data should have being in UCS-4 encoding, i.e. ('2' <zero> <zero> <zero> '2' ...) The reason, once found, is simple: { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); } You change codecvt in archive constructors and the archive also has locale saver. The destructor for archive is called *before* destructor for 'os'. At this time, codecvt is switched back, right? So, when destructor of 'os' calls 'close' which flushes the data, you're using default codecvt. If I add explicit 'os.close()' after writing to archive, the written data is correct. What this means is that destructor of archive *really should* call 'flush' on the stream. After I've made basic_text_oprimitive's destructor to flush stream: template<class OStream> basic_text_oprimitive<OStream>::~basic_text_oprimitive(){ os.flush(); } The test_vector passed with wide stream. I'm rerunning other tests now. In fact, I'm getting suspicious about changing codecvt at all. I suppose that if somebody is using wide streams, he already deals with encoding somehow, so why serialization library should try to second-guess the user? - Volodya

1 0

Re: [boost] Serialization. Pointer to constant object.
by Robert Ramey 14 Apr '04

14 Apr '04

Alexey Nikitin wrote: ... >void f3(A const* a, text_oarchive& oa) >{ > oa << a; >} >Why compiled function f1 and f2 but not f3 ? Good point. I have a fix - but it won't work for compilers that don't support Partial Template Specialization. I haven't been able to find a more general fix. Robert Ramey

2 1

[program_options] Unicode support
by Vladimir Prus 14 Apr '04

14 Apr '04

Hello, it seems that Unicode support is the last issue that should be addressed before the library can be added to CVS. Since the issue is somewhat tricky, I'd appreciate some comments before I start coding. The initial description of the approach I plan is at http://zigzag.cs.msu.su:7813/program_options/html/program_options.design.ht… or http://zigzag.cs.msu.su/~ghost/program_options/html/program_options.design.… So summarize the document, user would be able to pass wchar_t** to the parse_command_line function. If specific option needs unicode, this can be specified like this: ("email", unicode::value<Email>(), "email address") I believe the change will be mostly transparent and won't affect ascii usage. All options are very welcome! TIA, Volodya

9 30

question regarding basic_stream::imbue
by Robert Ramey 14 Apr '04

14 Apr '04

I have a simple question regarding basic_stream::imbue(locale &) Can it be applied after a file is opened? The state saver libray seems to suggest that it can. Some information suggests that it can if the file is position at the start. Experience with dinkumware and STLport suggests that it can't. If it can't what's the best way to work around it? Robert Ramey

2 1

[serialization] utf8 test glitch
by Vladimir Prus 14 Apr '04

14 Apr '04

Robert, to make utf8 test pass, I had to apply the attached patch. Seems like there was a typo which manifected itself only on 4-bit wchar_t -- one of the trailing bytes did not have the high bit set, so the facet returned an error. - Volodya

1 0

Re:[boost] Serialization #18
by Robert Ramey 14 Apr '04

14 Apr '04

Alexey Nikitin wrote: >I think it is not good idea to use "using namespace ...;" in header files. I agree - I'll fix it. Robert Ramey

1 0

circular_buffer question
by Neal D. Becker 14 Apr '04

14 Apr '04

I'm looking at circular_buffer. It appears to me that operator[] uses "add", and that "add" only allows a positive value of offset? It is not difficult to allow arbitrary values, and this is very useful. if "position" is the current "m_first" and "allocated" is the allocated buffer size, the index could be calculated: int index (int offset) const { int x = (offset + position) % int(allocated); if (x >= 0) return x; else return x + allocated; }

4 6

Boost Regex Understanding Captures topic
by Edward Diener 13 Apr '04

13 Apr '04

While the documentation for this topic is excellent, the one thing missing, I believe, is that the term "Captures" is never defined. I believe a brief single line at the very top of the topic defining the term would be judicious.

3 3

mirroring boost cvs ?
by Toon Knapen 13 Apr '04

13 Apr '04

We would like to mirror the boost cvs for internal users (in our company). We could of course run a script every night that performs a 'cvs checkout' followed by a 'cvs import'. But this way for instance, the versions of all files in our mirror do not correspond to the version of all files on the official boost trunk. There are also tools out there to do this but this requires that specific daemons are run on the server side (i.e. by sourceforge). Any ideas ? Thanks, toon

2 1

[Patch] iterator/iterator_facade.hpp collides with macros on i386-pc-solaris2.8
by Brad Spencer 13 Apr '04

13 Apr '04

In iterator/iterator_facade.hpp, there are a lot of template arguments that have names like "R1" and "D2". Unfortunately, these "all caps" tokens are fodder for collisions with macros. On i386-pc-solaris2.8, for some reason, "R1" is defined to be "9" (it's some kind of register identification macro) and so instead of: template < . . . , class R1, . . . > we get template < . . . , class 9, . . . > which, of course, doesn't work :) I've attached a patch against 1.31.0 (the trunk for this file) to fix this one file by adding "_type" to the end of all such all-caps names. I have not tested it very well. Perhaps there should be a policy to avoid names that are likely to collide with system macros? Just using mixed case (or lower case) is probably enough. Thanks for the great software! -- ------------------------------------------------------------------ Brad Spencer - spencer(a)infointeractive.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

2 3

Serialization. Pointer to constant object.
by Alexey Nikitin 13 Apr '04

13 Apr '04

#include <boost/archive/text_oarchive.hpp> #include <boost/serialization/serialization.hpp> using namespace boost::archive; using namespace boost::serialization; class A { friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, const unsigned int file_version) {} }; void f1(A const& a, text_oarchive& oa) { oa << a; } void f2(A* a, text_oarchive& oa) { oa << a; } void f3(A const* a, text_oarchive& oa) { oa << a; } Why compiled function f1 and f2 but not f3 ? Regards, Alexey.

1 0

Assignment library: review
by Gennadiy Rozental 13 Apr '04

13 Apr '04

Hi, This is formal review for the assignment library. Library present partial solution for frequent problem of collection initialization. In spite of several implementation issues I incline to accept this submission subject to resolution of Design Issue 1. Design --------------------------------------------- 1. Global operator+= and operator<< I believe defining global operator+= and operator<< is unacceptable (and it is global, cause to be used they require to be brought into space by using statement). I propose to remove it and introduce instead operator+= and implementation in headers dedicated to specific stl containers like this: template <class T, class Alloc> inline insert_assigner<std::list<T,Alloc> > operator+=( std::list<T,Alloc>& c, const typename std::list<T,Alloc>::value_type& v ) { return insert_assigner<std::list<T,Alloc> >( c, v ); } and operator << in appropriate extension headers. 2. Forwarding problem This library is affected by forwarding problem. I do not know how important it is, but may be we should use by-value scheme used by boost::bind? 3. Library doesn't allow to create const collections. Well, I am not sure whether or not it's doable but currently it's not supported Implementation --------------------------------------------- 1. insert_assigner( C& c, const value_type& v ) as well as fixed_size_assigner( const iterator& begin, const iterator& end, const value_type& v ) are unnecessary 2. Should we use Boost::pp to implement insert_assigner, fixed_size_assigner e.t.c. and have configurable limit? 3. Obviously code needs to be refactored into smaller pieces. One header per stl container. Also by default it shouldn't include boost related extensions 4. ~fixed_size_assigner This method may throw an exception. Does it always safe to rely on uncaught_exception call? Could we move this somehow out of destructor? 5. No function template ordering handling Why not use usual trick with extra long parameter? 6. Why not use tuple_insert_assigner for matrix assignment? Wouldn't be safer? 7. Promised support for MSVC 6.0 doesn't seems to work Code --------------------------------------------- 1. Why insert_assigner needs to include <boost/call_traits.hpp> 2. What is make.hpp,template.hpp? 3. I would name insert as append, cause it actually does not support inside the collection and this is after all is assignment library 4. Code comments needs to be removed Tests --------------------------------------------- 1. Tests doesn't seem to perform runtime correctness checks in most cases or rely on assert for checks. It would be preferable to use more graceful error checks. Good job, Gennadiy.

6 20

iterator_adaptor distance question
by Neal D. Becker 13 Apr '04

13 Apr '04

According to http://boost.org/libs/iterator/doc/iterator_facade.html#minus """ template <class Dr1, class V1, class TC1, class R1, class D1, class Dr2, class V2, class TC2, class R2, class D2> typename enable_if_interoperable<Dr1,Dr2,difference>::type operator -(iterator_facade<Dr1,V1,TC1,R1,D1> const& lhs, iterator_facade<Dr2,V2,TC2,R2,D2> const& rhs); Return Type: if is_convertible<Dr2,Dr1>::value then difference shall be iterator_traits<Dr1>::difference_type. Otherwise difference shall be iterator_traits<Dr2>::difference_type Returns: if is_convertible<Dr2,Dr1>::value then -((Dr1 const&)lhs).distance_to((Dr2 const&)rhs). Otherwise, ((Dr2 const&)rhs).distance_to((Dr1 const&)lhs). """ Is the preference for the former case over the latter intentional? This caused some surprise when I tried to re-implement my cycle_iterator_adapator (a kind of circular buffer adaptor). std::copy (b, a, ...) will do: template<typename _RandomAccessIter, typename _OutputIter> inline _OutputIter __copy(_RandomAccessIter __first, _RandomAccessIter __last, _OutputIter __result, random_access_iterator_tag) { typedef typename iterator_traits<_RandomAccessIter>::difference_type _Distance; for (_Distance __n = __last - __first; __n > 0; --__n) { *__result = *__first; ++__first; ++__result; } return __result; } As I implemented cycle_iterator_adaptor distance_to, it was expecting that given iterators [a,b], you probably want a positive distance from a to b, but the way iterator_adaptors is implemented, it wants a negative distance. Not hard to workaround, but it seemed odd that the default case was inverted, and I wondered if that was really intentional.

2 5

Serialization #18
by Alexey Nikitin 13 Apr '04

13 Apr '04

In files boost/archive/detail/iserializer.hpp and boost/archive/detail/oserializer.hpp use the instruction using namespace boost::serialization; As result in my code including <boost/archive/..._Xarchive.hpp> arised many next errors: ... zmr\fill_region.cpp(53) : error C2872: 'detail' : ambiguous symbol could be 'zmr::detail' or 'boost::serialization::detail' ... I think it is not good idea to use "using namespace ...;" in header files. Regards, Alexey.

1 0

como-win32 configuration change
by David Abrahams 13 Apr '04

13 Apr '04

I note in comeau.hpp: # if defined(_MSC_VER) && _MSC_VER <= 1300 # define BOOST_NO_STDC_NAMESPACE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # if _MSC_VER > 100 // only set this in non-strict mode: # define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP # endif # endif The indicated line seems completely out-of-place here - it's a library thing, not a compiler thing, and it breaks builds with my compiler. I'm deleting it and checking in. Please let me know if you disagree with this move. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Boost.Lambda question
by Arkadiy Vertleyb 13 Apr '04

13 Apr '04

Hi all, I am wonderring if there is an easy way to determine the type of a lambda functor, kind of lambda-specific typeof facility. I do realize that the primary purpose of lambda is to create temporary functors to pass to STL algorithms. On the other hand, there are contexts where functors need to be stored, such as in std::set, etc. One might want to use Lambda to generate such a functor, but without knowing its type it would be of limited use (of course one can directly specify the type of such functor, but this would be rather tedious). Has anything been done by anybody in this regard? Thanks, Arkadiy

5 6

passing temporaries to mutating algorithms
by Thorsten Ottosen 13 Apr '04

13 Apr '04

Dear All, I think I have found a safe way to bind a temporary to a const reference and cast away the constness. This means that a temporary can be passed (relatively) safely to an algorithm with a prototype like void foo( T& t ) { // do something with t, but don't store the reference. } for example, we might want to call foo() like vector<int> make_vec(); foo( make_vec() ); but we cannot. Using a little macro, we can say foo( BOOST_LVALUE( make_vec() ) ); assuming these prototypes const vector<int> make_cvec(); const vector<int>& make_crvec(); these uses will fail at ct foo( BOOST_LVALUE( make_cvec() ) ); foo( BOOST_LVALUE( make_crvec() ) ); Comments are welcome. br Thorsten begin 666 lvalue_cast.cpp M#0HC:6YC;'5D92 \:6]S=')E86T^#0HC:6YC;'5D92 \=F5C=&]R/@T*(VEN M8VQU9&4@/&%L9V]R:71H;3X-"@T*=7-I;F<@;F%M97-P86-E('-T9#L-"G5S M:6YG(&YA;65S<&%C92!B;V]S=#L-"@T*+R\@;75S="!N;W0@8F4@<F5J96-T M960-"G9E8W1O<CQI;G0^('9E8R@I#0I[#0H@(" @=F5C=&]R/&EN=#X@=B@@ M,3 L(#$P("D[#0H@(" @<F5T=7)N('8[#0I]#0H-"B\O(&UU<W0@8F4@<F5J M96-T960-"F-O;G-T('9E8W1O<CQI;G0^(&-V96,H*0T*>PT*(" @('9E8W1O M<CQI;G0^('8H(#$P+" Q," I.PT*(" @(')E='5R;B!V.PT*?0T*#0HO+R!M M=7-T(&)E(')E:F5C=&5D#0IC;VYS="!V96-T;W(\:6YT/B8@8W)V96,H*0T* M>PT*(" @('-T871I8R!V96-T;W(\:6YT/B!V*" Q,"P@,3 @*3L-"B @("!R M971U<FX@=CL-"GT-"@T*=&5M<&QA=&4\(&-L87-S(%0@/@T*5"8@;'9A;'5E M7V-A<W0H(&-O;G-T(%0F(')V86QU92 I#0I[#0H@(" @<F5T=7)N(&-O;G-T M7V-A<W0\5"8^*"!R=F%L=64@*3L-"GT-"@T*=&5M<&QA=&4\(&-L87-S(%0@ M/@T*=F]I9"!I<U]L=F%L=65?8V%S=%]S869E*"!4("D@#0I[#0H@(" O+PT* M(" @+R\@5V%R;FEN9SH@4F5A9&UE(0T*(" @+R\@:68@>6]U(&=E="!A;B!E M<G)O<B!H97)E+"!I="!M96%N<R!Y;W4G<F4@=')Y:6YG('1O(&-A<W0@87=A M>2!C;VYS="UN97-S(&9R;VT@80T*(" @+R\@8V]N<W0@;V)J96-T+B!9;W4@ M<VEM<&QY(&-A;FYO="!U<V4@0D]/4U1?3%9!3%5%7T-!4U0H*2!S869E;'D@ M=VET:"!T:&4@<')O=FED960G#0H@(" O+R!A<F=U;65N= T*(" @+R\-"GT- M"@T*=&5M<&QA=&4\(&-L87-S(%0@/@T*=F]I9"!I<U]L=F%L=65?8V%S=%]S M869E*"!4)B I#0I[#0H@(" O+PT*(" @+R\@5V%R;FEN9SH@4F5A9&UE(0T* M(" @+R\@:68@>6]U(&=E="!A;B!E<G)O<B!H97)E+"!I="!M96%N<R!Y;W4G M<F4@=')Y:6YG('1O(&-A<W0@87=A>2!C;VYS="UN97-S(&9R;VT@80T*(" @ M+R\@8V]N<W0@;V)J96-T+B!9;W4@<VEM<&QY(&-A;FYO="!U<V4@0D]/4U1? M3%9!3%5%7T-!4U0H*2!S869E;'D@=VET:"!T:&4@<')O=FED960G#0H@(" O M+R!A<F=U;65N= T*(" @+R\@(" @#0I]#0H-"B-D969I;F4@0D]/4U1?3%9! M3%5%*"!E>'!R("D@7 T**&ES7VQV86QU95]C87-T7W-A9F4H(&5X<'(@*2P@ M;'9A;'5E7V-A<W0H(&5X<'(@*2D@#0H-"@T*=&5M<&QA=&4\(&-L87-S($,@ M/@T*=F]I9"!S;W)T*"!#)B!C("D-"GL-"B @("!S;W)T*"!C+F)E9VEN*"DL M(&,N96YD*"D@*3L-"B @("!C;W5T(#P\(")S;W)T960B.PT*?0T*#0II;G0@ M;6%I;B@@:6YT+"!C:&%R*BH@*0T*>PT*(" @('-O<G0H($)/3U-47TQ604Q5 M12@@=F5C*"D@*2 I.PT*(" @("\O(&-T+65R<F]R.@T*(" @("\O<V]R="@@ M0D]/4U1?3%9!3%5%*"!C=F5C*"D@*2 I.PT*(" @("\O<V]R="@@0D]/4U1? H3%9!3%5%*"!C<G9E8R@I("D@*3L-"B @("!R971U<FX@,#L-"GT-"@`` ` end

5 12

Ok to commit?
by Gennaro Prota 13 Apr '04

13 Apr '04

Sort of administrative question :) I'm going to commit an improved version of dynamic_bitset, in the next days. The version, which is in the sandbox, has finally had Jeremy's approval. My question is: to implement find_first and find_next, two new functions I have added, I use a simple lowest_bit<T> template, which in turn requires integer_log2<T>; so there are two new header files: a) http://tinyurl.com/36zsj b) http://tinyurl.com/2lb26 I think they provide two useful facilities in themselves. Would it be ok to commit them in the boost/ folder? Or should they belong to boost/detail/? Or maybe boost/pending/? -- Genny.

4 5

Serialization #16-18
by Alexey Nikitin 13 Apr '04

13 Apr '04

In file boost/archive/add_facet.hpp from line 23: // does STLport uses native STL for locales? #if (defined _STLPORT_VERSION) && !(defined _STLP_USE_NO_IOSTREAMS) // and this native STL lib is old Dinkumware (has not defined _CPPLIB_VER) # if (defined _YVALS) && !(defined __IBMCPP__) # define BOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT # endif #endif IMHO, this incorrect because in new dinkumware library defined _YVALS and not defined __IBMCPP__. Result of that is error when compile with VC7.1 and STLPort with iostreams. Removing negation before "(defined __IBMCPP__)" is eliminate this problem. Regards, Alexey.

2 1

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 13 Apr '04

13 Apr '04

> > Actually, now that I look at the code, should it simply be > > > > < if(((m_match_flags & match_not_null) == 0) && (m_presult->length() == 0)) > > --- > > > if(((m_match_flags & match_not_null) == 0) && (m_result.length() == 0)) > > > > just below the original patch? That _seems_ to work. > > I've no time now, but I'll look into it, thanks, > > John. Thanks. BTW, meanwhile I noticed that it's not as simple as that. Above change helps with consecutive matches, but breaks empty matches, i.e. grepping "a*" over "---" gets stuck in an infinite loop. Ralph

2 3

RTL enhancements
by Arkadiy Vertleyb 13 Apr '04

13 Apr '04

Hi all, I just uploaded an enhanced version of RTL (the relational template library). First addition is a simple indexed set-based table implementation (I am using the old name, and our code is based on the reviewed version of the library. Once Joaquin comes up with the post-review version, we'll modify and upload our code). So far this implementation does not fully utilize all the indexed set capabilities that RTL can benefit from, but we will continue working on this subject. To use the indexed set implementation BY DEFAULT one can define the BOOST_RTL_USE_SET macro. Or the implementation type can be supplied explicitly, as a 4th parameter to the table_info class template, like: #define BOOST_RTL_USE_SET table<table_info< mpl::vector<id, name>, mpl::vector<id> > > t1; // indexed set based table table<table_info< mpl::vector<id, name>, mpl::vector<id>, mpl::vector<mpl::vector<id> >, sorted_strategy> > t2; // sorted vector based table The other additions are mainly based on our discussions with Pavel Vozenilek, and include: Fully redesigned/reimplemented join. ------------------------------------ We decided to get rid of our generic join, and replaced it with a simpler, range join, operator which can be used to join each outer tuple with a range in the inner relation, something like this: equal_join<mpl::vector<c1> >(t1, t2); range_join(t1, t2, lower_bound<mpl::vector<c1> >(), end()); Lambda enabled for the selection operator. ------------------------------------------- Something like this can be specified: selection(t, _1[c1()]==5 && _1[c2()] >=20);// SELECT * FROM t1 WHERE c1=5 AND c2>=20 A couple of things were renamed: BOOST_RTL_COLUMN(name, type); became BOOST_RTL_DEFINE_COLUMN(type, name); // looks more like C++ and rel::tuple became rel::row to avoid collisions with the Boost.Tuple library, that showed up once we started using the indexed set :( (now I am even more against the idea of putting stuff under the boost namespace) The other enhancements to the library and to the documentation to follow. These will include better assertions, serialization, performance estimates, etc. Here is the link: http://groups.yahoo.com/group/boost/files/tables.zip As always, any feedback is most welcome. Best regards, Arkadiy

1 0

Re: [boost] Re: Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

Hi Rob, ----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 12, 2004 8:58 pm Asunto: Re: [boost] Re: Re: [indexed_set] revised naming proposal > > > Why not just "index::list?" > > > > "list" seems too terse to me. It could lead the reader > > to think it is some sort of container (which is not). Take into > > account the namespace can be populated in the future > > with other containers derived from the main one. > > I suppose in a given use case, a "using boost::index" (or "using > boost::multi_index") may be in force, so it would boil down to > just "list." > > However, neither "index_list" nor "list" really says the right > thing. How about turning it around: list_index? I don't get how list_index is more meaningful than index_list. I mean, index_list is a list (a typelist, actually) of indices (index specifiers, actually). Would you care to ellaborate? (thanx!) [...] > I agree with Thorsten's proposal. "multi_index_container" is > much clearer. I'm recording your opinion (and Thorsten's) My intention is to reach a final decision during this week. > > > from my part here. There's still the pending issue of whether > > to move into boost::container. > > I think the argument that "a" container library has to be the > first one is valid, but was there sufficient consensus that such > a namespace was warranted? If there is consensus, your library > is a perfect candidate. If there isn't, it would be painful to > put your library in the "container" namespace only to rip it out > later. If you don't do it and folks agree it is worthwhile, then > yours would be just one more library to move into the namespace > at that time. > Well, it's all about not wasting effort. Hopefully, some other boosters (and the authors of container libraries in Boost) will jump in and express themselves for a tie-break. Jeff thinks more or less how you do about not going down that road if no one else will follow. On a more philosophical level, I don't quite like the idea of 1st level namespaces per se. IMHO, these are the most plausible justifications for this kind of namespaces: 1. Help avoid pollution of boost namespace. 2. Group libraries semantically affine. 3. Group libraries that will be likely used in cooperation in many programs. As for 1, I don't see any danger of namespace pollution in Boost since libraries are accepted one by one and these things are carefully checked before. As for 3, I don't really think that a program using an indexed_set will get a greater chance of using also multi_array, for instance (on the contraty, I guess the probability will be actually less.) 2 is an aesthetical issue. I don't see any practical benefit from having this kind of grouping. One does not discover new libraries by way of exploring the "sourrounding" namespaces, so to say. If anything, the categorized lib index in Boost serves this purpose well. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Lunes, Abril 12, 2004 9:13 pm Asunto: Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection > Joaqumn M Lspez Muqoz wrote: > > > push_back() can also throw from the allocator if it runs out of > memory,> so you really need some proper clenaup regardless of the > guarantees> made by copying ops. Dave's suggestion of using RAII > is probably the > > most elegant way to deal with the situation: in my experience, > however,> this sort of scope guards perform worse than a > try{}catch(...){}. Your > > mileage may vary. > > Anything wrong with the following? > [code rewritten using new stack_construct facility] It looks fine to me. Also, please ignore my previous statement about the relative merits of try{}catch(...){} wrt to RAII. The performance gain of the former shows only, it seems to me, when using scope guards. In your case, in which destruction *always* takes place, I doubt anything can beat what you've just written. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection
by Robert Ramey 12 Apr '04

12 Apr '04

Joaqumn M Lspez Muqoz wrote: > push_back() can also throw from the allocator if it runs out of memory, > so you really need some proper clenaup regardless of the guarantees > made by copying ops. Dave's suggestion of using RAII is probably the > most elegant way to deal with the situation: in my experience, however, > this sort of scope guards perform worse than a try{}catch(...){}. Your > mileage may vary. Anything wrong with the following? // reserve space on stack for an object of type T without actually // construction such an object template< typename T > struct stack_allocate { T * address() { return static_cast<T*>(storage_.address()); } T & reference() { return * address(); } private: aligned_storage< sizeof(T), alignment_of<T>::value > storage_; }; // construct element on the stack template<class Archive, class T> struct stack_construct : public stack_allocate<T> { stack_construct(Archive & ar){ load_construct_data(ar, address(), 0U); } ~stack_construct(){ address()->~T(); // undo load_construct_data above } }; // sequential container input template<class Archive, class Container> struct archive_input_seq { // archive_input_seq(){} inline void operator()(Archive &ar, Container &s) { typedef BOOST_DEDUCED_TYPENAME Container::value_type type; stack_construct<Archive, type> t(ar); ar >> make_nvp("item", t.reference()); s.push_back(t.reference()); } };

1 0

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

Hi Pavel, ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Sábado, Abril 10, 2004 11:50 pm Asunto: [boost] Re: [indexed_set] revised naming proposal > > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote > > > This is my 2nd proprosal for naming of the library > > formerly known as Boost.IndexedSet. > > > It may be helpful to add examples for each > suggested name, for easier orientation. > With pleasure: NAMESPACE+CONTAINER NAME Current: namespace boost{ namespace indexed_sets{ template<...> class indexed_set; } using indexed_sets::indexed_set; } Proposed: namespace boost{ namespace multi_index{ template<...> class indexed_container; } using multi_index::indexed_container; } INDEX NAMING Current: typedef indexed_set< employee, index_list< unique<identity<employee> >, non_unique<member<employee,int,&employee:age> >, sequenced<> > > employee_set; Proposed: typedef indexed_container< employee, index_list< ordered_unique<identity<employee> >, ordered_non_unique<member<employee,int,&employee:age> >, sequenced<> > > employee_set; NTH_INDEX_TYPE AND FAMILIY Current: typedef index_type<indexed_t,some_tag>::type index_t; typedef nth_index_type<indexed_t,n>::type index_t2; typedef indexed_t::index_type<some_tag>::type index_t3; typedef indexed_t::nth_index_type<n>::type index_t4; typedef iterator_type<indexed_t,some_tag>::type iterator_t; typedef nth_iterator_type<indexed_t,n>::type iterator_t2; etc. Proposed: typedef index<indexed_t,some_tag>::type index_t; typedef nth_index<indexed_t,n>::type index_t2; typedef indexed_t::index<some_tag>::type index_t3; typedef indexed_t::nth_index<n>::type index_t4; typedef index_iterator<indexed_t,some_tag>::type iterator_t; typedef nth_index_iterator<indexed_t,n>::type iterator_t2; etc. UPDATE MEMFUN Current: employee_set es; es.update(it,new_value); Proposed: employee_set es; es.replace(it,new_value); Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

Re:[boost] Re: Seriialzation library draft # 18 uploaded to files section
by Robert Ramey 12 Apr '04

12 Apr '04

Joaquin Munoz wrote: > I think I detected a minor bug in collections_load_imp.hpp. > The operator() code for archive_input_seq reads: > inline void operator()(Archive &ar, Container &s) > { > typedef BOOST_DEDUCED_TYPENAME Container::value_type type; > stack_allocate<type> t; > load_construct_data(ar, t.address(), 0U); > ar >> make_nvp("item", t.reference()); > s.push_back(t.reference()); > t.address()->~type(); // undo load_construct_data above > } > This is AFAICS not exception-safe: if say s.push_back() > throws, the dtor for the stack-allocated variable t won't > be called. The same problem in similar code snippets > through this file. Apologies if my perception is wrong. Hmmm - An interesting point I never considered. Push_back from the standard library has a strong guarantee so the problem should boil down to one of the constructors (copy or inplace) throwing. Try/catch block could be added but it could be a little expensive for large collections and would be unnecessary in the most common case where inplace and copy constructors don't throw. I would like to use has_nothrow_constructor and has_trhow copy to address this but the language in the type_traits document suggests that this wouldn't be effective. Anyone is free to chime in here. Robert Ramey

3 3

Different kinds of line endings in CVS?
by Daryle Walker 12 Apr '04

12 Apr '04

I saw this in <http://boost.org/more/getting_started.html>: //========================================================================= Text file line endings in the .zip file are as supplied by each library developer. This works fine for Windows, but not for Unix/Linux. The tar.gz and .tar.bz2 files supply Unix/Linux friendly line endings. //========================================================================= I'm challenging the assertion that text-file line-endings should be developer-chosen. The archives are generated from a CVS export, right? I thought that CVS regulates all text files to have Unix-style line endings, and a CVS client will change a text file's line-endings upon check-in or -out from/to the appropriate character(s) for the client's platform. The developer would not have a choice. The only way around that would be if a text file was accidentally added to CVS in binary mode. However, storing a text file in binary mode unnecessarily has a large storage penalty. Check-outs and -ins also get messed up if a text file is in binary mode but the text editor is "smart" enough to clean up the difference (i.e. add extra line-break characters). If we have messed up text files like this, shouldn't we fix them up in the CVS repository? (Is that even possible?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 3

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

Hi Jeff, ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 11, 2004 8:31 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal > On Sun, 11 Apr 2004 19:38:29 +0200, JOAQUIN LOPEZ MU?Z wrote > > I'm good with everything in the proposal, except I think the > library should > still be called multi-index containers. I think if you leave that > out people > are likely to miss the fact that the library provides replacement > containers. > You've got a valid point here. But I cannot turn your suggestion into a reasonably short name in the spirit of Boost.MultiIndex. Boost Multi-index Containers Library? This is too long to be scattered through the docs the way Boost.IndexedSet appears now. Shortened for easier reference to BMCL or BMICL? Maybe we should retain Boost.MultiIndex and use the fuller "Boost Multi-index Containers Library" at the header and preliminary paragraphs? I'm really lost here, naming issues are so nasty. Looking fwd to knowing your ideas. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

Boost socket library
by Shridhar Daithankar 12 Apr '04

12 Apr '04

Hello All, While browsing various boost resources, I ran into http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket Can anybody point me to latest updates? I am very interested in such a library. Regards Shridhar

2 1

Seriialzation library draft # 18 uploaded to files section
by Robert Ramey 12 Apr '04

12 Apr '04

Fellow boosters, I just uploaded version #18 of the proposed boost serialization library to the files section. It can also be downloaded at www.rrsd.com It contains improvements in code/file/namespace organization, better documentation on how its implemented, and a number of arcane bug fixes. This is the version I will refer to during the upcoming review. Robert Ramey

5 4

[BGL] property default constructor
by Vladimir Prus 12 Apr '04

12 Apr '04

The default constructor of boost::property is defined as: template <class Tag, class T, class Base = no_property> struct property : public Base { .... property() { } So, for the case where T = builtin type or a pointer, it's simply not initialized, per rules in 12.6.2/4. Is this desired behaviour? I was bitted by this twice, because I have: typedef boost::property< semantics_tag, Semantic*, boost::property< boost::edge_weight_t, unsigned > > EdgeProperties; and neither of properties is initialized when I do: add_edge(v1, v2, g); Maybe, the ctor should be: property() : m_value() {} ? - Volodya

1 0

[indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

Hi, This is my 2nd proprosal for naming of the library formerly known as Boost.IndexedSet. I've changed my mind with respect to some of the decisions stated at my first proposal (rationale is given.) There is also a minor clashing issue that I'd want to publicize before the final commit. I list here only the points that have changed with respect to my first proposal, that you can find at: http://lists.boost.org/MailArchives/boost/msg62611.php If no one complains about this 2nd proposal I'll apply the necessary changes by the end of the following week. NAMESPACE * Proposal: boost::multi_index. This differs from the previous proposal in which boost::container is not used; rationale: resulting qualified ids would be too long, which would force most users to use namespace aliases (not a good thing, this has been discused before in connection with Boost.Filesystem) or apply using directives. Another reason is that a good deal of preexisting Boost containers don't live in boost::container and it does not seem such a migration will ever take place. CONTAINER NAME Proposal: indexed_container. Rationale: composite_container sounded too vague; indexed_container is reminiscent of the previous name indexed_set, so in a sense it won't break the (admittedly shallow) familiarity with the library that boosters might have built up so far. LIBRARY NAME: Proposal: Boost.MultiIndex. Rationale: In sync with the namespace. REST OF NAMING ISSUES: Like in the 1st proposal. NAME CLASHING ISSUE: The renaming of nth_index_type & familiy to nth_index etc. uncovered a name clashing issue in GCC (and only in this compiler AFAIK): using namespace boost::multiindex; typedef index<indexed_t,some_tag>::type index_t; //clash! The index<> class template clashes with the non-standard C-runtime function index() living in <string.h>. Unfortunately, most std headers (even C++ ones) seem to implicitly include <string.h> as well, so the clash is likely to occur. In my opinion, this clash is not important enough, for the following reason. index<...> is provided mainly as a workaround for MSVC 6.5, which has well-known problems with nested templates. In GCC one can write instead: using namespace boost::multiindex; typedef indexed_t::index<some_tag>::type index_t; using the nested index<...> variant. This is always preferrable, and does not clash in any manner with global index() in <string.h>. Of course, there are other obvious resolutions to this clashing issue. For this reason, my proposal is to effectively change index_type<...> to index<...>, and similarly with the other related template classes as previously proposed, even in the presence of this clashing issue. If someone thinks differently, please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

cref(_1)
by David Abrahams 12 Apr '04

12 Apr '04

Hi, I have this code that isn't compiling because of the "forwarding problem" limitation of boost::bind: std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, _1)); The problem is that an implicit conversion is required between the reference type of the difference_iterator and the argument type of writeVInt. It seems to me that, since I know that binding to an rvalue is required, we ought to have a way to say "force this to be a const ref". I thought of something like std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, boost::cref(_1))); ^^^^^^^^^^^^ ^ I know it's not pretty, but it sorta does what we want. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 7

Signals documentation error
by Edward Diener 12 Apr '04

12 Apr '04

The documentation for the Signals library shows an Allocator type as the second template parameter to the signal template class when one looks in the Reference section. In the header file and in other references to the usage of the signal template class, no such template parameter exists, and the second parameter is the Combiner. I believe the Allocator type may have been in an early version of the signal template class and the doc was never corrected to take it out.

2 1

Formal Review: Assignment Library
by Tom Brinkman 11 Apr '04

11 Apr '04

The review of Assignment Library library, written by Thorsten Ottosen 2003 (nesotto(a)cs.auc.dk) starts today(April 1, 2004)and runs for 10 days. Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/assignment/ (204 kB) or in the sandbox. What it is? The purpose of this library is to make it easy to fill containers with data by overloading operator the comma, () and operator()(). Example: To fill a vector with values you write: #include <boost/assign/stl.hpp// for operator+=() #include <vector> using namespace std; using namespace boost::assignment; vector<intvalues; values += 1,2,3,4,5,6,7,8,9; values += foo1(), foo2(), foo3(); History of the project: The idea for an initialization library is not new . The functionality of this library resembles Leor Zolman's STL Container Initialization Library a great deal, but it does not rely on string passing to achieve its goals. The library is non-intrusive and puts only a minimum of requirements on its supported classes. (change classes to types) The Initialization Library overloads the comma operator in a safe manner by letting free standing functions return an object that is responsible for the initialization. Therefore it takes explicit action from the programmer to begin using the overloaded operator,(). The operator comma is never overloaded for user-defined types. Portability: Library has been successfully compiled and tested with MVC++ 6.0, MVC++ 7.0, MVC++ 7.1, GCC 3.2 (under Cygwin) Comeau 4.3.0.1, Intel ICC 7.1 and Intel ICC 8.0. There are known limitation on platforms not supporting partial template specialization. Review Comments: Your review comments are welcomed. Found problems and suggestions for documentation are highly sought. Requests for new features requests will shape the way this library will evolve in future. 1. Where should the main libraries header files be placed. This is header only library and should be fairly easy to manage.Should it be placed in the utilty folder or its own folder? 2. Should the headers be broken up? This library has extensions to boost::array, boost::ublas and boost::graph. Should those headers be placed in their respective folder or kept together with the headers associated with the main Assignment library headers. Or, should the boost library extensions remain just as examples of how to extend the library. 3. Should the fixed_size_asssigner only throw on out_of_bounds exception or should it default initialize the remainning elements? Two classes can throw an exception in their destructor. This is done when detecting eg. a boost::array has not been initialized with enough elements. Should this be replaced by default initializing the remaining elements? 4. This library needs to use the boost test framework. Review Manager Tom Brinkman reportbase(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

8 21

BOOST_PP_IDENTITY
by David Abrahams 11 Apr '04

11 Apr '04

How come I can't find it in the documentation index? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

BCC weirdness
by Andreas Huber 11 Apr '04

11 Apr '04

Hi there While trying to port my fsm proposal to BCC5.6.4, I encountered the following compiler error: "simple_state.hpp": E2188 Expression syntax at line 389 The error is in the following code: // ... typedef typename context_type::outermost_context_type outermost_context_type; typedef typename context_type::inner_context_ptr_type context_ptr_type; typedef typename context_type::state_list_type state_list_type; // *** error on the following line *** typedef intrusive_ptr< inner_context_type > inner_context_ptr_type; typedef typename detail::make_list< InnerInitial >::type inner_initial_list; BOOST_STATIC_CONSTANT( detail::orthogonal_position_type, no_of_orthogonal_regions = mpl::size< inner_initial_list >::value ); typedef typename mpl::push_front< typename context_type::context_type_list, context_type >::type context_type_list; // ... I don't have a clue what BCC's problem is here, for the following reasons: - This code compiles just fine on MSVC7.1, GCC3.2 and Intel8.0 - The line on which the error is reported looks completely harmless to me - No amount of commenting out code following the problem line changes anything in BCC's diagnosis Does anyone have any hints on how to resolve this? Thanks & Regards, Andreas P.S. The full code can be found at http://boost-sandbox.sf.net/fsm.zip or in the sandbox CVS. The error appears while trying to compile the StopWatch example.

2 2

RE: [boost] Re: Assignment library: review
by Glen Knowles 11 Apr '04

11 Apr '04

From: Keith Burton [mailto:kb@xtramax.co.uk] >I trust that you are aware of the following quoted, from >MSDN for all Microsoft C++ compilers <snip> >See Knowledge Base article Q242192 for more information. The article says that it applies to MSVC 6, not "all". Glen Knowles Centor Software Corporation

1 0

test lib bugs
by David Abrahams 11 Apr '04

11 Apr '04

I am seeing these errors when compiling with como-win32: "c:\boost\libs/test/src/execution_monitor.cpp", line 42: error #735: using-declaration of function "strlen(const char *) C" conflicts with function "std::strlen(const char *)" (declared at line 30 of "c:/tools/como433\libcomo\cnames/cstring") namespace std { using ::strlen; using ::strncat; } ^ "c:/tools/como433\libcomo\cnames/cstring", line 30: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Placeholder in boost.lambda/boost.function
by Stefan Slapeta 10 Apr '04

10 Apr '04

Sorry it this has been asked yet, I didn't find anything. Currently placeholders are ambigous if you include boost/bind.hpp and boost/lambda/bind.hpp in the same translation unit. The compiler finds the _1 of the function library and the one of the lambda library. Could this be resolved (without specifying an explicit namespace for the placeholder?) Stefan

1 0

Generic non-derivable base class
by Matthew Vogt 10 Apr '04

10 Apr '04

Is there any interest in creating a generic base class to encapsulate the non-derivable class idiom, as recently discussed wrt Reece Dunn's error check component? Since the the idiom is on a similar complexity level to that of noncopyable, I feel it would be appropriate to encapsulate it, if a general solution is possible. The following simple base class implements the mechanism as dicussed on Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the class can be non-virtually inherited, removing the most obvious chance of implementation error. Will this code work on multiple platforms? I have only tested on gcc 3.2... //------------------------------- namespace boost { template <typename T> struct nonderivable; namespace detail { template <typename T> class nonderivable_base { private: template <typename X> struct identity { typedef X type; }; friend typename identity<T>::type; friend class nonderivable<T>; nonderivable_base() {} nonderivable_base(const nonderivable_base&) {} }; } //namespace detail template <typename T> struct nonderivable : public virtual detail::nonderivable_base<T> { }; } // namespace boost // ------------------------ struct A : public boost::nonderivable<A> {}; struct B : public A {}; A a; // Ok B b; // Error - cannot be instantiated // ------------------------ Matt

3 4

RE: [boost] Re: Formal Review: Assignment Library
by Powell, Gary 10 Apr '04

10 Apr '04

Finally I have some more time to look at this library. My first complaint is that by default it links in the world. I think for something like this, we need to not link in every standard container and graph and tuple etc include file. I'm glad that the library handles it but the dependency graph is ridiculous. And yes I know that I can link in just the necessary sub include files, but my complaint is that it will trap the unwary user by default. I think if the basic file boost/assign.hpp only linked the minimum necessary I'd be much happier. Of course who is to say what is the minimum? So how about changing the name to boost/assign_to_anything.hpp (blech!) or something similar with the name being more of a warning. The file boost/assign/stl.hpp also unnecessarily includes every std container. At a minimum the use of BOOST_NO_FUNCTION_TEMPLATE_ORDERING shows that only <queue>, and <stack> are required. The define should also be around the unnecessary include files. There also appear to be two useless files in the distribution, make.hpp and template.hpp that should be removed. (minor cleanup) I did a cursory look at the docs, and will try and get back to them. I ran the tests with gcc 3.2 and they all compiled fine and ran fine. I vote for acceptance with the qualification that the stl.hpp header be reorganized into sub headers. I may come back with more stuff about the docs but it won't be to change my vote. (Dang standard for not splitting out <vector_fwd> et.al. ) Yours, -Gary- powellg(a)amazon.com

2 1

spirit docs (was regex ease-of-use)
by Dave Gomboc 10 Apr '04

10 Apr '04

> Subject: Re: [boost] Re: Regex ease-of-use ideas > > Hmmph. I have to say that while I love what Spirit is > doing, actually > > using it with confidence requires way too much use of the source, > > Luke. Reference docs are annoying to write, but neccessary. > > Point well taken. Formal documentation is high on the TODO list. It'd also be great to have documentation on what would need to be changed to Spirit to enable full backtracking and cut points. Dave

3 2

Spirit Documentation
by Stephan T. Lavavej 10 Apr '04

10 Apr '04

The background on the Spirit doc pages makes text difficult to read on the right hand side. It would be better if the background were changed to be smooth, rather than interrupted by horizontal lines. Example of the mischief the current background causes: http://stl.nuwen.net/spirit.png Stephan T. Lavavej http://nuwen.net

4 3

Errors compiling a boost-based app using VC7.1
by Steve Dussinger 09 Apr '04

09 Apr '04

HELP!!!! I'm trying to compile an application which contains boost threads and I can't seem to get it to work. Whenever I try to compile, I get the following two types of messages from the compiler: warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' or warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' Obviously, these have something to do with the mixing of DLL and non-DLL classes, but since Windows is not my preferred OS I have no clue about what to do to get this to compile. I used boost (v 1.28) on a prior project (using VC6) with no problems, but I'm just stumped here.... Can anyone give me a clue? Thanx, Steve

2 2

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 09 Apr '04

09 Apr '04

Actually, now that I look at the code, should it simply be < if(((m_match_flags & match_not_null) == 0) && (m_presult->length() == 0)) --- > if(((m_match_flags & match_not_null) == 0) && (m_result.length() == 0)) just below the original patch? That _seems_ to work. Ralph

2 2

RE: [boost] regex lib: non-greedy repeats w/ match_posix
by Benzinger, Ralph 09 Apr '04

09 Apr '04

> > I noticed that the newest regex version no longer supports > > non-greedy repeats "+?" in match_posix mode. What was the > > rationale for this? > > It is deliberate, non-greedy repeats don't really fit into the POSIX > matching philosophy, where repeats are neither greedy not > non-greedy, rather it's parenthesis that determine what the best match > is. John, I'm not sure I understand what you're saying. A regular expression either (completely) matches a given text, or it doesn't; if we ignore parentheses for a moment, then there's no room for different "matching strategies" (like, say, POSIX or not). When searching for (i.e., grepping) a regular expression, POSIX states "left-most longest", so it shouldn't be ambiguous to determine the left-most longest match among all possible matches (with parenthesis indices breaking ties), even if the RE contains a non-greedy repeat. Do you have a specific example at hand why you think non-greedy repeats are inappropriate for POSIX-style greps? Personally, I find it very convenient to write REs like "<b>.*?</b>", especially in POSIX mode. Ralph

2 1

Some FC++ comments
by Vladimir Prus 09 Apr '04

09 Apr '04

I've just made a first attempt to read through FC++ docs, and have some comments. I haven't read all of the posts in the recent review, so apologies if some of the issues are already known. The docs I used are those at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/fcpp.html First, a motivating example: I wanted to find a vertex in BGL graph which has in degree of zero. This should be something as simple as (using lambda): find(vertices(g).first, vertices(g).end(), bind(in_degree, _1, g) == 0); but in_degree happens to have several overloads, all of which are templates, so just 'in_degree' won't work, and selecting the right variant via cast has it's own problems. So, I though FC++ would allow me to declare 'in_degree_f' object that will work for all kinds of graph. The documentation starts with: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order[1] polymorphic[2] functions, The issues with this are: 1. When this is in context of proposed Boost.FC++ docs, one immediately wonders how this is different from Boost.Lambda. 2. The footnotes always break the regular flow of reading, so it's better not use them in the first sentence new user is likely to see. 3. higher-order polymorphic functions exists even without FC++. I think boost::bind is such a function: it takes function as argument and returns a function. So, this statement does not indicate what new FC++ brings (btw, I agree it brings something new). 4. If you think that average reader will think that 'polymorphic' == 'with virtual functions' you might want to use the word 'generic'. Later, you define 'functiod' and the definition applies just nice to functional objects everybody was using for quite some time. Again, you don't explain what FC++ brings. Later, you describe changes made during boostification. I really don't think new user would be interested in that. The above comments might sound like nit-picking, but what I try to say is: the instroduction does not say absolutely anything about why FC++ is worth looking at. The only new term there is 'lazy_list' and if reader doesn't know what's that already, he might not get even that. In section 2, you say: Programming in this pure style ensures referential transparency. and I don't know what "transparency" here means. Now, to section 4, "Overview". What I'd expect in this section is a bunch of examples, showing what I can do with FC++ which is not easily done using other tools. What I see, though, is: We could define a polymorphic functoid add_self(), which adds an argument to itself: // add_self( x ) means x + x If we can define such thing, I'd really like to see the definition, not commented out code. The you talk about lazy list, again for someone who has no idea what they are, it's hard to understand usefullness. I think you should either explain this with an example, or at worst give some link. E.g. "Why functional programming matters" makes some use of lazy lists, IIRC. The overview does on in largely the same style. You list supported functoids but don't give any explanations or example. Last comment on this section: plus(3,4) // 3+4 also minus, multiplies, etc. This does not look impressive. Can't I do "std::plus<int>(3,4)". I think one of the points of FC++ is that you don't need to specify the exact type. If so, you need to explicitly state that fact (and preferrable, even in the introduction). Now to the Section 5. Direct functoids enable the creation of functions Hmm.. is it precisely "enable". I suspect that "direct functoid" *is* the function. Or is direct functoid is some device which produces functions? I think the example with 'map' is not really good. First you say map takes a list and function. Then you give Haskell syntax and describe that syntax. After that you explain what's high-order and what's polymorhic. IMO, the Haskell syntax is just not necessary here. Later you say: Representing such a function in C++ is non-trivial Then, what about std::transform? If we forget that it works on iterators, not sequences (which is just detail) then it does exactly what you're after. I think it would be better if you write down properties of the function you want to create (polymorphic, can be passed as argument *itself*, allows to inter return type) and then immediately give an example. And example could be more reabably you use split the definition of 'result_type' like this: template <class F, class L> struct sig { typedef F::template sig<typename L::value_type>::result_type function_return typedef list< function_return > result_type; }; It might be better to use 'type' instead of 'result_type' since MPL uses 'type'. When you talk about monomorphic direct functoids, I wonder why you need 'c_fun_type'. Is it possible to make std::unary_function work? The section 6, "Indirect Functoids", makes me wonder if they are usefull at all. boost::function works very nice with me, and it also works with boost:bind. The secton 7, "Full Functoids" looks ok to me, though some examples would be good. At this point I've stopped reading documentatation, tried to write some code and got my 'in_degree_f' in a short time. There are some additional questions: 1. Maybe it makes sense to provide a helper base class for a case where return type is fixed, but argument types are not. Something like: class xxx_in_degree : public ret_type2<unsigned> { ... } ; 2. Do we need intermediate typedef? Won't boost::fcpp::full2<xxx_in_degree> in_degree_f; work just fine? 3. I have std::find_if(vertices(g).first, vertices(g).second, in_degree_f(_, g)); but I want to compare the return from 'in_degree_f' with zero, as in thes example: find(vertices(g).first, vertices(g).end(), bind(in_degree, _1, g) == 0); How do I do that? When I try: std::find_if(vertices(g).first, vertices(g).second, lambda(X)[ in_degree_f[X, g] %equal% 0]); I get a lots of errors, starting with: fcpp/signature.hpp:114: error: invalid use of undefined type `struct boost::fcpp::impl::XEqual::sig<size_t, int>' The complete example is at http://zigzag.cs.msu.su:7813/bgl.cpp if needed. Also, it would be *really* nice if lambda syntax in FC++ and Boost.Lambda was compatible. I'll print and read your paper on syntax today, but no matter how big semantic differences are, learning/using two different syntaxes is a bad idea. These are all comments for now. Hope they make sense. - Volodya

1 0

Lambda regression with GCC-3.4
by Michael Stevens 09 Apr '04

09 Apr '04

Hi All, (particularly Jaakko!) While working on using BLL's operator return type mechanism in uBLAS I stumbled on the problem the recent (snapshot) GCC-3.4 has with BLL. I noticed Jaakoo checked in the following patch a few days ago as a workaround. #if BOOST_WORKAROUND(__GNUC__, == 3) && __GNUC_MINOR__ >=4 #include <vector> #else namespace std { template <class T, class Allocator> class vector; } #endif >From my own research the problem is not just restricted to 'std::vector'. It certainly also occurs with 'std::map'. I assume (have not verified) that the problem is related to hidden template parameters in the gcc-3.4 implementations of the std containers. OR is the problem simply a bug (an regression) in gcc 3.4 Too late for gcc 3.4 but I will submit a bug report if no one else has already done so. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

3 2

Re: [boost] Formal Review: Assignment Library
by Vladimir Prus 09 Apr '04

09 Apr '04

Tom Brinkman wrote: > The review of Assignment Library library, written by > Thorsten Ottosen 2003 (nesotto(a)cs.auc.dk) starts > today(April 1, 2004)and runs for 10 days. I think the library should be accepted, though I have some suggestions. The review below is based on reading the documentation for about an hour. First off, I think such a library is usefull. Besides stl container initialization, it would be usefull for other libraries which want to provide convenient initialization syntax. Now, to the suggestions 1. The library expects the user to overload 'make_insertion' for his types. Now suppose I have 'class Email' which list of 'to' and 'cc' addresses.I want to initialize both using the assign library, e.g Email e; e.add_to("Winnie-the-Pooh")("Ia"); e.add_cc("Story writer"); The problem is that I can have only one 'make_insertion' for the 'Email' class. Exposing the real containers used for storing addresses is not good idea. And there might be 'add_to_address' function which does additional handling of argument, before pushing it into the container. So, it would be nice if the library allowed to specify a *function* which will do the actual insertion. 2. The library examples contain using namespace assignment; which is likely to burn users in a subtle way. Suppose: // some header namespace email { class Email {}; std::ostream& operator<<(std::ostream& os, const Email& e); } // some source #include "some header" namespace email { using namespace assignment; void internal_function() { vector<int> v; .... v << 1, 2, 3; } } The operator<< declared in the namespace will hide the one from "using namespace", and unless user is aware about this problem he might spend a lot of time trying to understand why the right operator<< is not selected. I know it costed me about 1 hour some time ago. 3. While the += operator is fine with me, I don't like the << operator. I cannot associate the conventional meaning of the operator with 'assign all' semantic, so I suggest that this operator is dropped completely. You can provide alternative syntax for assign_all: assign(v) = 1, 2, 3, 4, 5; if assignl(v)(1)(2)(3)(4)(5) has too many paranthethis. (Since comma has lower predecence than =, the first syntax will really work). 4. The operator() and other operators in insert_assigner are declared inline. Suppose vector<some_type> v; assign(v)("first", "")("second", ""); This involves call to constructor of 'some_type' and possible calls to additional constructors needed to converted char* into types that 'some_type' excepts. If operator() is inline, those calls will be inlined as well, increasing code size. Similiar problem exists because single-argument operator() accepts a fixed type, possible requiring convertion on the caller's side. I'd suggest the declare the operators outside of class declaration. This will give the compiler more freedom -- e.g. inlining only if maximum optimization level is requested. 4. Just like other revievers, I'm not comfortable with monolitic stl.hpp 5. Operator += which is declared for all possible types makes me nervous. IIRC, stl formatiing library by Terje Sletteb used some trick to avoid exposing all those operators. Something like template<template<class T, class Alloc> sequence> class helper { friend std::ostream& operator<<(std::ostream&, const Sequence& s) { ... } } // in vector.hpp template helper<std::vector>; Terje said the explicit instantination bring the friend declaration into namespace. I'm somewhat rusty on friend lookup rules, so further investigation is needed. Documentation issues 1. The example for maps uses: map<const char*, int> month; which is a bit strange, even for example, given that comparison for "const char*" does not compare string values 2. In the graph example, I'm not sure how you add edge between vertices 4 and 6, in a graph with only 5 vertices. If new vertices are automatically added, this should be documented. And BTW, what about graph which don't use ints for vertex_descriptor? 3. I did not really understoon 'tuple_insert_assigner' role. Why is it needed? - Volodya

2 6

RE: [boost] Re: FC++ -- Formal Review Result
by Jon Kalb 09 Apr '04

09 Apr '04

I would like to thank Brian, Mat, and all of the FC++ library reviewers for their work on this submission. It is clear that C++ has some form of functional programming in its future and I'm glad we have people of this caliber working on it. Whatever we end up with in Boost and eventually in the Standard, whether it is a future submission of FC++ or some other approach, it will be better for the work that Brian has done in this version and I think we are indebted to him, Mat, and the library reviewers for their effort. Thank you. -- Jon Kalb

7 17

A new GUI library
by Mohammed Iqbal 09 Apr '04

09 Apr '04

Hi... I have written a GUI for WIndows XP only (this library will not work on Win 2000 and/or 98) in C++. Of course this library doesn't conform to the guidelines to post it here. This library works only with gcc 3.3.3 and Visual C++ 7.1 only. It is based on ideas inspired by the work of Alexandrescu "Modern C++ Design" and Czarnecki and Eisenecker "Generatie Programming" and by following a new technique called Context-Oriented Programming. Boost has a nice small libraries that I rewrote to fullfil my needs. This library is not complete yet because it will cover every thing for WinXP only. Of course, this means it can't be posted to this discussion list nor the CVS. Mohammed

4 5

[BGL] Tarjan's offline LCA algorithm.
by Cromwell Enage 09 Apr '04

09 Apr '04

I know this was a couple of days overdue, but I'm still learning my way through CVS. If there's still an urgent need for the LCA algorithm, here it is: <http://groups.yahoo.com/group/boost/files/bgl_algo/tarjan_offline_lca.zip> The example program provides a straightforward way of using it. Known issues: * The graph needs to be directed or bidirectional, it must be a tree, and the user must provide the root. * I forgot to discuss what type of output was desired. As a "quick and dirty" approach I used a Boost.uBLAS matrix; if you have any ideas that could lead to better efficiency and genericity, please let me know. The documentation covers my approach in greater detail. * The disjoint sets parameter is available in the kitchen-sink version of the function but not in the default version; the object is strictly for utility purposes. The bgl_named_params class doesn't appear to provide the ability to include custom named parameters; for this reason, I haven't included a named-parameter variant. If you disagree, please let me know. * I tried implementing Tarjan's LCA using the builtin depth-first-search function and event visitor lists. The major stumbling block was my inability to execute any code during post-traversal of an edge. (The on_tree_edge event fires during pre-traversal, and neither the on_back_edge event nor the on_forward_or_cross_edge event would fire using DFS on the example graph.) So, in the future, I'd like to see an on_post_traversal event filter and a corresponding vis.post_traversal(edge,graph) function implemented, and I'm pretty sure other graph algorithms could use this feature, too. For the moment, the LCA algorithm runs its own recursive DFS, and the event visitor list parameter in the kitchen-sink function variant does nothing. BTW, one of the Java source files (the one with the Graph class) was missing, so it was necessary to restart from scratch. HTH Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

4 3

Regex ease-of-use ideas
by David Abrahams 09 Apr '04

09 Apr '04

I was just writing up a simple tutorial example; finding the subject in a set of email headers. Here's what I got: std::string line; boost::regex pat("^Subject: (Re: )?(.*)"); boost::smatch matches; while (std::cin) { std::getline(std::cin, line); if (boost::regex_match(line,matches, pat)) std::cout << matches[2]; } 1. There's no way to search a stream for a match because a regex requires bidirectional iterators, so I have to do this totally frustrating line-by-line search. I think Spirit has some kind of iterator that turns an input iterator into something forward by holding a cache of the data starting with the earliest copy of the original iterator. Could something like that be added? 2. Seems to me that if match objects could be converted to bool, we might be able to: std::string line; boost::regex pat("^Subject: (Re: )?(.*)"); while (std::cin) { std::getline(std::cin, line); if (boost::smatch m = boost::regex_match(line, pat)) std::cout << m[2]; } which would be much smoother to the touch. Are match objects expensive to construct? -- Dave Abrahams Boost Consulting www.boost-consulting.com

9 27

[boost-sandbox] [BGL] Random path and Tarjan's Offline LCA algorithms.
by Cromwell Enage 08 Apr '04

08 Apr '04

They're now in the Boost Sandbox CVS, hooray! Accordingly, I've deleted the corresponding archives from the Yahoogroups file vault. The loop_erased_random_paths function has been changed to take in a boost::random_number_generator (or equivalent class) rather than a random number generating engine. Unfortunately, the following bug prevents the example and test programs from working correctly: <http://sourceforge.net/tracker/index.php?func=detail&aid=911758&group_id=75…> In the meantime, I'll be studying an all-pairs LCA algorithm that I've recently stumbled upon for which matrix output may be better suited. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

RE: [boost] Re: FC++ -- Formal Review Result
by Powell, Gary 08 Apr '04

08 Apr '04

>> Do you think there would be merit in starting over from scratch? >> With a new language, I mean. >Of course. But adoption and interoperability are difficult issues, >then. http://felix.sf.net has one interesting strategy. This is of course a similar approach that C++ did to usurp "C". Generate code in a language that the machine is likely to have a compiler for. Without doing this, the chances of a new language being adopted by businesses which have bizillions of euros invested an existing code base and trained engineers is nil, nada, squat. By doing this a small test project can be done on the side by a team and if the results are good, integrated into the rest of the company. (If poor those left on the project when its cancelled will be terminated and forced to look for employment under assumed names.) The key is having both a "compiler" and a "debugger" that understands both languages at the source level. The quotes are to indicate that an interpreted language is not ruled out. Anyone who tried to debug CFront with adb, understands what I'm referring to. Yours-who-nearly-started-programming-"C"-when-it-was-"B", -Gary-

1 0

[boost] [Boost-bugs] [ boost-Bugs-931852 ] in the config.hpp system, problem with macos.hpp
by SourceForge.net 08 Apr '04

08 Apr '04

Bugs item #931852, was opened at 2004-04-08 10:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=931852&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: in the config.hpp system, problem with macos.hpp Initial Comment: on MacOSX with a ProjectBuilder, the line # ifndef TARGET_CARBON # include <boost/config/posix_features.hpp> # endif does not work, because the posix_features are always activated, even with carbon targets. the guy probably wanted to do something like # ifndef __MACHO__ # include <boost/config/posix_features.hpp> # endif or something like that. that bug prevents the boost library to be used with ProjectBuilder's projects that uses Carbon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=931852&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Auto_link and BOOST_DYN_LINK
by Edward Diener 08 Apr '04

08 Apr '04

I know it is late to suggest a change but I think that the default when one links to the dynamic RTL should be that a dynamic link library is created, not a static library. My own experience is that creating a dynamic link library is the norm when linking to the dynamic RTL, creating a static library is the norm when linking to the static lib version of the RTL, and that following any other mixed setup seems to lead to problems at run-time, particularly when memory management is involved. Now I know that auto-link specifies it is an #error if one tries to create a dynamic link library, using BOOST_DYN_LINK, when one is using the static version of the RTL. I am wondering why this is any less of a problem than if one attempts to create a static library using the DLL version of the RTL. Despite the fact that I don't like either mixture, I would welcome an explanation of why one is allowable, and safe, and the other is not. But given that the latter is considered allowable and the former not, I would suggest, along with my beginning suggestion, that BOOST_DYN_LINK be removed and that BOOST_STATIC_LINK be added to coerce the creation of a static library when linking to the DLL version of the RTL.

3 4

regex lib: non-greedy repeats w/ match_posix
by Benzinger, Ralph 08 Apr '04

08 Apr '04

I noticed that the newest regex version no longer supports non-greedy repeats "+?" in match_posix mode. What was the rationale for this? Is it possible to re-enable non-greedy repeats? As far as I could test, it's not sufficient to modify the syntax check around regex_compile.hpp:1794; regex "a+?" would be valid but matches "aaa" on string "-aaa-" instead of "a". Ralph

2 1

Documentation improvement for boost::bind
by Edward Diener 07 Apr '04

07 Apr '04

In the first line of the next to last paragraph of the boost::bind deocumentation under the heading of "Using nested binds for function composition", it is stated: "Sometimes it is necessary not to evaluate the first argument, but not to evaluate some of the other arguments, even when they are nested bind subexpressions. " I believe this is confusing and that a much clearer explanation of what is meant would be: "Although the first argument is, by default, not evaluated, all other arguments are. Sometimes it is necessary not to evaluate arguments subsequent to the first, even when they are nested bind subexpressions."

2 3

Date-Time documentation link
by Edward Diener 07 Apr '04

07 Apr '04

In the Date-Time library documentation for 1.31, the link from Class day_clock takes me to the Construction From Clock section of the class Date. Is that correct ? I was expecting to be taken to documentation for class day_clock's constructors and member functions. Is this a way of saying that day_clock has only a default constructor and the member functions local_day() and universal_day() ?

2 3

Re: Tokenizer doc problems/confusion (?)
by David Abrahams 07 Apr '04

07 Apr '04

"John R. Bandela" <jbandela(a)ufl.edu> writes: > Thanks for the e-mail. > > The problem the char_separators not giving you the correct words and > counts is a bug. It was caused by the latest changes to > token_functions to speed up tokenizing non-input iterators. The > version in the boost 1.31 should work (it is the one prior to the > changes). I have also just fixed it in the CVS. Thanks! All the docs still show char_delimiters_separator as the default, though. > Having char_delimiters_separator as the default tokenizing function > was unintentional (ie it never got changed). OK. > As to simplifying the interface, I would really like to hear your ideas. 1. Allow "boost::use_default" for any of the template parameters 2. Supply a templated 1-argument ctor that constructs the start iterator from the argument and default constructs the end iterator then I could write: boost::tokenizer< boost::use_default, std::istreambuf_iterator<char> > t(std::cin); > As to why char_delimiters_separator was deprecated, char_delimiters ^^^^^^^^^^^^^^^ What's that? It's not in the doc. Do you mean char_separator? > was supposed to be a replacement for it, doing everything it did, > but providing the user with more control in dealing with empty > tokens. However, as you have brought up, it also has the unfortunate > problem that in its default construction of returning punctuation as > well as words and thus is not as simple to use. Why not just change that. > Perhaps the solution would be making a separate words_delimiter that > is hard-wired to return only words (ie characters separated by > either a space or a punctuation mark) and making that the default. That'd be OK with me. > As to why the mention of std::isspace and ispunct, I needed a default > behavior when the user does not want to provide all the space and > punctuation (it can be a somewhat long string). I also did not what to > hard-code it as a string so I used those functions instead. That doesn't demystify things for me. If you have an internal way to use functions to determine kept and dropped, why don't you give me a way to supply functions, too? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

Problem with integer_traits and gcc on Mac OS X
by Marshall Clow 07 Apr '04

07 Apr '04

One of the regression tests for MacOS X is failing - in particular, it is reporting that boost::integer_traits<wchar_t>::min = -2147483648 boost::integer_traits<wchar_t>::max = 2147483647 but boost::integer_traits<wchar_t>:: const_min = 0 boost::integer_traits<wchar_t>:: const_max = 2147483647 [ FWIW, this is gcc 3.3 ] Nothing in the code is jumping out at me. Any suggestions for fixing this? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> I want a machine that thinks I'm more important than it is, and acts like it. -- Eric Herrmann

1 0

RE: [boost] Generic non-derivable base class
by Reece Dunn 07 Apr '04

07 Apr '04

Matthew Vogt wrote: >The following simple base class implements the mechanism as dicussed on >Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the >class can be non-virtually inherited, removing the most obvious chance of >implementation error. >Will this code work on multiple platforms? I have only tested on gcc 3.2... >[snip] Why can't you do: namespace boost { template< class T > struct nonderivable; namespace detail { template< class T > class nonderivable_base { friend T; friend class nonderivable< T >; nonderivable_base() { } nonderivable_base( const nonderivable_base & ) { } }; } template< class T > struct nonderivable: public virtual detail::nonderivable_base< T > { }; } This *will* work with MS VC 6-7.1 and Borland 5.5.1. I haven't tested on GCC or other compilers, but it should work. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

Unicode string
by Vladimir Prus 07 Apr '04

07 Apr '04

Miro Jurisic wrote: > On the other hand, in order to manipulate a Unicode string without > violating constraints on well-formedness, you have to consider the string > as a sequence of abstract characters (unless, of course, you constrain > yourself to string transformations which operate on code point sequences > yet guarantee that strings remain well-formed; there are few such > transformations -- concatenation is one of them under certain constraints). [snip] > capital letter C; combining caron; lowercase letter e > > it contains two abstract characters, but three UCS4 code points; therefore, > removing the first character from that string means removing the first two > code points of three. Removing just the first code point would leave you > with a combining caron followed by a lowercase letter e, which is not a > well-formed Unicode string. Hi Miro, so the point is that when using string-as-code-point-container, even searching and removing a character/substring might get invalid string? E.g. even looking for string 'foo' you theoretically can find string 'foo' followed by composing character, and removing just 'foo' will be invalid? > basic_string is not the abstraction you are looking for, but it's also the > only one that is readily available in STL/boost today. It may serve as a > good starting point (questionable, IMNSHO), but it should most definitely > not be treated as the right thing to use for Unicode in the long term. I wonder what's the right abstraction then? Is it necessary to have a class to represent abstract character, with all composing characters? - Volodya

3 5

RE: [boost] Re: Numeric conversions lib comments
by Rozental, Gennadiy 07 Apr '04

07 Apr '04

> > In most part proposed design looks reasonable. I have only > one major > > IMO concern. > > > > Issue: (Major) Why traits are template parameter of > converter? I've > > expressed my opinion in the matter before: Traits - as name suggest > > could not be policy. IOW should not be template parameters. > Traits are > > type specific and an ability to supply them independently to the > > primary type in most cases leads to invalid/too complicated design. > > Traits are not only template parameters of public > converter class > > but many other classes. IMO all of them should use S and T > as template > > parameters instead. > > > I have to disagree. > Traits are used as policies in too many designs, including > the STL itself, and I don't see a problem with that. I agree I don't say I like it either. Major issue with basic_string design IMO is that char_traits is template parameter > that traits classes are type specific, but they are used as > policies precisely because of that: if the user of a > parametrized facility wants a different treatment for a given > type, she can't change *the* traits for the type, all she can > do is pass in a different traits as a policy. Here is how I see it. Trait is something type specific, IOW specific to type, IOW uniquely defined by type. If you could provide trait along with the type as a template parameter, that mean you could change it independently from the type, IOW you could define different value for trait still using the same type. For example if you have component C defined like: template<typename T, typename Trait> struct C { ... }; You could instantiate it like C<MyT,TraitValue1> or C<MyT,TraitValue2>. So as you could see trait value is not uniquely defined by the type. Proper design would be to have trait stand alone class, like this: template<typename T> struct Trait { value = ... }; template<typename T> struct C { here we are using Trait<T>::value, where we used to use Trait. }; Now if the user needs to define trait value (or change from using default value provided by most traits designs), she just need to define explicit/partial specialization for this type or types family. On the other hand policy is something that is orthogonal to the primary type (actually in policy based design there may not be any primary type, but just an orthogonal policies), IOW you could use different policies in conjunction with the same type. And natural place for the policy is along with type in component definition among the template parameters. > If this were > not a policy, users would be stuck with the definition of the > default traits class. I agree that this opens a window to all > sort of problems in case a user plugs in an invalid traits, > but I think that should not constitute a reason for fixing > the traits into the converter. As always, "trust the programmer" So again Trait is not a Policy and let's not mix them > > 4. converter<>::convert converts only rvalue. Why? > > IMO we need second operation that works with lvalues. > What if I want > > to convert int& into char&? > This requires the target lvalue as a parameter instead of a > return value. It could be done yes, but I don't see the > reason. Why would want to do that? For example for [de]serialization solutions. What is in your opinion is problem domain for numeric conversion? Gennadiy.

11 50

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 07 Apr '04

07 Apr '04

> > Is it just me or does regex_grep return overlapping matches > > when using the match_posix flag? More specifically, grepping regex > > "a+" over text "-aaa-" will find matches "aaa", "aa", and "a" at > > offsets 1, 2, and 3, respectively. > > Yep, there's a fix going into cvs now, the patch is: > > Index: perl_matcher_common.hpp > < search_base = position = (*m_presult)[0].second; > > search_base = position = m_result[0].second; John, Thanks for the quick response. This works almost :-), but now the regex_grep misses consecutive matches: grepping regex "aaa" over "-aaaaaa-" will find only one match "aaa" at offset 1, but not the one at offset 4. Grepping over "-aaa-aaa-" works, though. Ralph

1 0

Re: [boost] [BGL] Tarjan's offline LCA algorithm.
by Cromwell Enage 07 Apr '04

07 Apr '04

No, my brother reclaimed the old computer :~ Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 07 Apr '04

07 Apr '04

Hello, Is it just me or does regex_grep return overlapping matches when using the match_posix flag? More specifically, grepping regex "a+" over text "-aaa-" will find matches "aaa", "aa", and "a" at offsets 1, 2, and 3, respectively. This does not happen using the match_perl flag. I've confirmed this on NT and Linux platforms. The problem seems to be somewhere near perl_matcher::match_all_states(), where the inner if(!(this->*proc)()) statement is entered multiple times and thus indirectly sets (*m_presult)[0].second to an incorrect value, leading to an incorrect restart point. I know that regex_grep is deprecated, but I still prefer it over the iterator approach. Any ideas or comments? Thanks, Ralph

2 1

regex doc issue
by David Abrahams 07 Apr '04

07 Apr '04

On the match_results doc page, there's a broken link to #m12. Should be #m13? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

RE: [boost] RE: [program_options] Unicode support
by Ferdinand Prantl 07 Apr '04

07 Apr '04

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > I would make program_options support an imbue() function > that allows a > > locale to be specified (otherwise use the default locale) > > Why bother? As I've indicated, internal processing will work > just fine with UTF-8, and no interface of the library will > expose a UTF-8 encoded string. Yes - that's it. There can be a locale en_US.UTF-8, and then the application must accept it. If it does not, it has conversion support, imbuable or not. Application should not require the library to have a unified encoding of char * on all environments; that's not STL style. > imbue() is a good thing for specifying what encoding char** > input has, but it's orthogonal to the rest of the library -- > it's used only on interface boundary. Yes, that's also my opinion. > > This provides much more flexibility than just supporting UTF-8. > > UTF-8 is a really impractical encoding for almost any > locale where the > > majority of text is not ASCII like and the user may well prefer to > > encode text is Shift-JIS or other encodings. > > Again, in my case the user does not use UTF-8 string, so why > would he care how the strings are encoded internally? Yes again, now it seems to me we try to persuade each other about the same thing :-) Ferda > - Volodya

2 1

RE: [boost] RE: Re: [program_options] Re: Unicode support
by Ferdinand Prantl 07 Apr '04

07 Apr '04

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > UCS-2 held all characters in Unicode 1.1, There was a need for more > > unique numbers and UCS-4 was introduced in Unicode 2.0. > Unfortunately > > there is no 4-byte character specialization for > basic_string<> in STL yet. > > Or, to be exact, there's no agreement if wchar_t should be > 32-bit or 16-bit. > Linux (or gcc specifically) uses 32 bits, and Windows 16, > which means wstring only suitable for UCS-2. Wow, I did not know that about gcc, what a smart compiler... ;-) MSVC does it usually because Win32 API id ANSI/UCS-2, so the usage is straightforward then. > Besides, UCS-2 > has a mechanism to represent characters outside of 16-bit > space with two elements, which, I suspect, won't work if > wchar_t is 16 bit. Actually, not UCS-2, but another variable-sized character encoding was introduced in Unicode 2.0 - UTF-16. It serves for the 16-bit characters similarly like UTF-8 for the 8-bit ones. Using numbers from the unused (and forbidden) space it allows to encode characters in more than one element and so break the constraint of the 16-bits. It works with wchar_t, if only UCS-2 characters are stored in it; because the special characters are forbidden in UCS-2 anyway. However, UTF-16 brings the inconvenience of variable-sized character and those, who used UCS-2 and "enjoyed" the fixed character size should switch to UCS-4 to carry on... Not all applications need it, indeed, UCS-2 is enough, usually. > > Generally speaking UTF encodings (e.g. UTF-8 or UTF-16) are not > > suitable for the fast in-memory usage because some operations, for > > example at(int) and length() have not O(1) but O(n) to give > a result. > > I believe UTF-8 is popular party because such operations are > believed to be rare. Really? string.length() ? You must have been joking... :-) UTF-8 is popular because the vast amount of texts contains much more ASCII characters than the accented ones. It saves space to store them in this encoding. It was with the UTF-7 encoding also the first one, thus the oldest. It can be also comfortable for the application not to perform any conversion and work with the text in its native encoding - here can help the stringized interface working with UTF-8. Not for all applications, however. For example, XML parsers tend to work in UTF-16 internally, because UCS-4 eats much memory and UTF-8 as well for East Asian encodings. I also feel, that the applications, which parse texts and extracts string parameters to be used in some structures or as user input are processed usually with fixed-size strings, because the string operations are easier. > > They (UTF, > > T=Transformation) are better for storing texts as they save > place by > > using variable number of bytes for a character. However UCS (e.g. > > UCS-2 or > > UCS-4) are fast for memory operations because they use > fixed character > > size. > > What about representing values with two 16-bit values (that's > what I've mentioned above)? You mean UTF-16. Yes, it is also a possiblity, but having wchar_t not fixed sized, you would have to provide basic_string<char16_t>... I see it pretty the same like your UTF-8 option, because both encodings use variable-sized character, being so incompatible with the shared implementation of basic_string<> for char and wchar_t. Moreover, if basic_string<char> from the API would produce UTF-8 string, that it would be only consistent, if basic_string<wchar_t> produced UTF-16 and not UCS-2. To say nothing of support of 4-byte wchar_t and UTF-32 :-) > (BTW, for reference to those interested, > http://www.cl.cam.ac.uk/~mgk25/unicode.html#ucsutf > talks about different encodings). > > > That is why I would not like to use basic_string<utf8char> > in memory, > > rather basic_string<ucs4char> instead, but I would not > generalize it > > for all possible applications. > > In case of program options, I suspect that everything will > work for UTF-8 strings. IOW, the library does not care that > any given 'char' might be part of some Unicode character. > That's why it's attractive for me. It depends on the way of usage of basic_string<> inside and outside of the program_options. The implemenation of basic_string<> is done for fixed-size characters. It does not do searching/iterating/length counting with regards to the character size, which can vary from 1 to 6 bytes in UTF-8. For example string.find() would produce unexpected results if in haystack was stored UTF-8 and a needle was in ANSI, where all 255 numbers are allowed. Not only the library must be aware of it, but also the users, that for example basic_string<char>.size() does not deliver the count of characters but the count of bytes in a string then. That is why I do not like usage of basic_string<> for variable sized characters; basic_string<char> would not have consistent behavior for different encodings; as long as it is used for different ANSI encodings, the only misunderstanding is when two different characters in two local alphabets share the same character above ASCII. For other methods is basic_string<char> consistent. > > You can expect initialization from (const char * argv []) on all > > platforms or (const wchar_t * argv []) on Windows in UCS-2. > With the > > basic_string<> you already have support for the parameters from the > > current locale (char) and for parameters in UCS-2. > > What do you mean by 'parameters from the current locale'? If you set LC_CTYPE to something like "cs_CZ.iso8859-2" on UN*Xes or choose "Czech" in Windows Control Panel, command line shell (well, not only it) will start to accept and deliver in (char * argv []) also characters from a local alphabet (here Czech, for example). Such string you would have convert into UTF-8, if you wanted to have an UTF-8 interface. It means, you would have to do more than basic_string<char>(argv[x])... > I > am not sure that ctype::widen is required to care about > user-selected character encoding. > Not do I think it's requires from default codecvt facet. AFAIK it must care; the method widen() needs locale to provide an extension from char to a templated char_type. STL in MSVC uses correctly mbcstowc() to perform the conversion from the local alphabet to the UCS-2. I hope that no-one simply casts to wchar_t, being so reliable only for 7-bit characters. Anyway, it is always possible to write an own converting facet and force its usage for widen by with imbue. > If my locale on Linux is ru_RU.KOI8-R I don't think standard > requires codecvt<wchar_t, char> facet in default instance of > 'locale' to do meaningfull conversion from KOI8-R into unicode. Hmm, I am not sure about the ISO/C++ definition. If the standard implementation were something like "return (wchar_t) x" then it would be useless for anything except 7-bit ASCII. MSVC works with locale and it should be according to the standard, hopefully. Yet delivers the shell the variable "char * argv []" in ru_RU.KOI8-R to you. > > If we take an option to read parameters into > basic_string<wchar_t> or > > basic_string<ucs4char_t>, where the character size or > encoding is not > > the same as the native encoding on the command line, there is an > > affinity to streams. Some shells allow usage of UTF-8 encoded > > parameters or, generally, usage of characters out of the current > > locale. It means, that a program can choose the way, how to > encode all > > characters from Unicode to char. UTF-7/8, etc. I would like > to have a solution similar to streams: > > imbue(). Having this, you could convert internally every > argv[x] using > > imbue(y) applied to a stringstream, where the facet y > provides the caller. > > That's right. There should be some mechanism to convert from > current 8-bit encoding and source code encoding into unicode. > At least at linux there's a mechanism to do the first thing, > but I'm not aware about Windows. There are such methods in stdlib.h, which produce a wide character or a string of wide characters: int mbtowc(wchar_t *pwc, const char *s, size_t n); size_t mbstowcs(wchar_t *pwcs, const char *s, size_t n); These methods work with the locale supported in the operating system and thus you can always get a wchar_t from a char. And these should be used in the default facet in STL. > > On the other hand, such a conversion can be performed also > by a user. > > The parameters sent to main() are char* or wchar_t* and thus > > program_options can give them back just as they are in > > basic_string<char> and basic_string<wchar_t>. The client > can use his > > facet to imbue a basic_stringstream<> initialized with the > parameter from program_options. > > Or a conversion library could be used to perform the conversion, > > something like lexical_cast<> does for type converions. It > is a matter > > of convenience only - separate converions library (no support for > > encoding in > > program_options) or imbue(), performing the conversion inside the > > program_options. However, the conversion should not be > implemented for > > program_options only, that is why I suggested an existing > interface - > > facets. > > I agree with basing the mechanism on facets. OTOH, it's > really can be made orthogonal to program options. So > initially program_options can support only ascii (strict > 7-bit) and unicode, for which conversion is trivial. Hmm, if it was orthogonal to program options, like facets are to streams, then there is no need to declare support of encodings. char * and basic_string<char> are simply in the local encoding and wchar_t * and basic_string<wchar_t> are wide according to the understanding of "wideness" on a platform (Unicode). It will also support the input, which you can expect for program_options from main(): char * in the current locale encoding. If someone wants something else, he can use facet and streams to convert it (which could be hidden in program_options with imbue, but not necessarily). I think the point is not to support UTF-8 or UCS-2 but to support encodings explicitely declared or not. I would not implicitely return UTF-8 or UTF-16 basic_string<>s, not only because STL handles their chars implicitely according to the current locale, but also because basic_string<char>(argv[x]) does not behave this way. Having the encoding independent on program_options using some external conversions, possibly imbuable into program_options, make the library thinner and more concentrated on the problem: parse the command line. Like the streams - read characters from input. Those, who say "we need full Unicode, UTF-8 or UCS-4" have the same option as if working with streams - imbue or convert. Otherwise they have currebnt locale char from istream or wchar_t from wistream. > > You can find come converting facets for UTF-8 raedy for > imbue() to a > > stream in the files section on yahoo. Unfortunately not finished or > > not reviewed... > > Yea, I can find some facets, including one written by myself > ;-( And yea, unfortunately they are not in Boost yet. Great! You can probly prepare it for review, if your time allows it... :-) Ferda > > - Volodya > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Uploaded/checked in Wave V 1.1.4
by hartmutkaiser＠t-online.de 07 Apr '04

07 Apr '04

Hi all, I've just uploaded a new version of the Wave preprocesor library (V1.1.4) to the yahoo files section here: http://tinyurl.com/yul67. The same version is checked into the boost-sandbox CVS. There were a lot of changes recently: - Adjusted to use the new version of the program_options library. - Fixed a bunch of minor bugs in the expression evaluation engine. - Made a lot of other rather unrelated bug fixes (see in the ChangeLog file contained inside the distribution). Besides passing its own test suite Wave now passes 98% of the preprocessor validation suite published here: http://tinyurl.com/yul67. The remaining open issues are in the field of wide character and multibyte character handling, which are implementation depended anyway. But I'm still working hard on fixing the remaining issues. Regards Hartmut

2 2

Tokenizer doc problems/confusion (?)
by David Abrahams 07 Apr '04

07 Apr '04

1. http://www.boost.org/libs/tokenizer/tokenizer.htm says: template < class TokenizerFunc = char_delimiters_separator<char>, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ class Iterator = std::string::const_iterator, class Type = std::string > class tokenizer Yet char_delimiters_separator is officially deprecated. Is that really intentional? Wow, it appears to be using the deprecated class template for the default! Now, I wanted to tokenize an input stream, without putting it in a string first. It seems to be much harder than neccessary: #include <map> #include <string> #include <iostream> #include <boost/tokenizer.hpp> #include <boost/lambda/lambda.hpp> #include <iterator> int main() { typedef std::map<std::string, unsigned> fmap; // Seems awfully complicated boost::tokenizer< boost::char_delimiters_separator<char>, std::istreambuf_iterator<char> > t( (std::istreambuf_iterator<char>(std::cin)) , std::istreambuf_iterator<char>() ); fmap f; std::string s; using namespace boost::lambda; std::for_each(t.begin(), t.end(), ++var(f)[_1]); for (fmap::iterator p = f.begin(), e = f.end(); p != e; ++p) std::cout << p->second << ": " << p->first << "\n"; } I can think of lots of ways to simplify the interface, most of which center on eliminating redundant mentions of istreambuf_iterator<char>. When I throw the following text at it: ------ how much wood could a woodchuck chuck, if a woodchuck could chuck wood? ------ I get: 2: a 2: chuck 2: could 1: how 1: if 1: much 2: wood 2: woodchuck as desired. But if I replace char_delimiters_separator with char_separator, I get: 15: What's up with that?? Even if char_separator did what it was advertised to (and it's not clear that it does), it wouldn't give me the simple "find the words functionality" of char_delimiters_separator... so I'm baffled by the deprecation. 2. http://www.boost.org/libs/tokenizer/char_separator.htm says: explicit char_separator() The function std::isspace() is used to identify dropped delimiters and std::ispunct() is used to identify kept delimiters. In addition, empty tokens are dropped. which seems strange in light of the fact that there's no ctor taking _functions_ to be used to determine kept/dropped delimiters, and nowhere in the text do you indicate that functions are called internally. Help? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

RE: [boost] Generic non-derivable base class
by Reece Dunn 06 Apr '04

06 Apr '04

Matthew Vogt wrote: >The following simple base class implements the mechanism as dicussed on >Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the >class can be non-virtually inherited, removing the most obvious chance of >implementation error. >Will this code work on multiple platforms? I have only tested on gcc >3.2... >[snip] I have tested on MS VC 6.0 sp5, 7.0 and 7.1 without any problems. On Borland 5.5.1 however, I am getting the following errors (tested in my errorcheck component): [log] Error E2404 d:\devel\adl++\include\boost/errorcheck.hpp 23: Dependent type qualifier 'boost::detail::nonderivable_base<boost::errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage> >' has no member type named 'identity' in function main() Error E2061 d:\devel\adl++\include\boost/errorcheck.hpp 23: Friends must be functions or classes in function main() Error E2029 d:\devel\adl++\include\boost/errorcheck.hpp 33: 'boost::detail::nonderivable_base<boost::errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage> >' must be a previously defined class or struct in function main() Error E2029 d:\devel\adl++\include\boost/errorcheck.hpp 136: 'boost::nonderivable<boost::errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage> >' must be a previously defined class or struct in function main() [/log] I don't have any workarounds at present. Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

1 0

Re:[boost] Re: FC++ -- Formal Review Result
by Robert Ramey 06 Apr '04

06 Apr '04

David Abrahams wrote >> Andy Little wrote >> > Whether anyone has the guts to employ you I have no idea, but I >> > wish you all the best for the future. > Condescension and insult. FWIW - I read that as a complement. IMO many employers ARE reluctant to hire out of the box thinkers. Of course my view may be skewed as I've been a freelancer for 35 years. Robert Ramey

1 0

RE: [boost] Formal Review: Assignment Library
by Powell, Gary 06 Apr '04

06 Apr '04

Either I missed it or, I'm confused, why is the make_insert functions for set & map using the "hint" of c.end() for the insert? Is there any advantage to this? -Gary-

2 1

FC++ -- Formal Review Result
by Mat Marcus 06 Apr '04

06 Apr '04

The formal review for FC++ has completed. I am sorry to say that FC++ is not accepted into boost at this time. It may be possible for the library to be accepted in the future, but not without changes substantial enough to warrant an additional review. I will describe some possible strategies for later acceptance together with the rationale for my decision. Note that while the library is not accepted, the author has successfully established some of the merits of the functional programming paradigm and we should not require him to re-establish those same points in a future review. For that matter, I'm not convinced that we should have asked him to establish these points in the first place. * Rationale This was a very difficult decision, and I spent a long time sitting on the fence. I believe that the functional programming paradigm is important for C++ programmers, and that there are many interesting features available in FC++ such as lazy lists and the standard prelude functionality. In addition, though there was not a consensus amongst reviewers to accept (see Opinions of the Reviewers below), several boost library authors offered positive reviews of FC++. I finally managed to gather my thoughts and come to a decision -- thanks to all for your patience. In formulating my decision, I realized that one of the important questions to ask of a candidate boost library is: "Can I in good faith recommend to any C++ programmer with interest in domain X that they spend the time and effort to learn library Y and consider using it in relevant projects?" For FC++ I can not yet in good faith answer yes. I do think that it is worthwhile for *some* programmers to look at and would certainly consider pointing to FC++ in its present form from the boost web site as an "interesting third party library" if we maintained such links. But as I said I am not yet ready to put the boost "brand" on FC++. Why not? My evaluation was based on two main criteria, practicality and educational value, of which detailed accounts follow. ** Evaluation of Practicality Today FC++ is a largely monolithic library with a fair degree of overlap with other boost components. This led to a good deal of confusion/discussion during the review period. Such a state of affairs (monolith with substantial overlap) could conceivably be acceptable if there were clear problems for which FC++ was a uniquely suited practical solution. Exact Reals (see footnote *** below) notwithstanding, I don't believe that the *practical* value of FC++ as a *monolithic* embedded DSL in C++ supporting mixed paradigm programming has been satisfactorily established. [footnote ***: The existence of clients such as the Exact Real lib help demonstrate some degree of practicality. During the review I briefly examined the Exact Real site. This looked like an interesting application though I could not yet say how much practicality was demonstrated since, for example, the performance characteristics of lazy lists and constructive reals were not immediately clear to me. If FC++ is to be accepted on practical grounds potential users may want to be able to understand performance characteristics.] If the authors were to break FC++ into smaller pieces and should they participate in a future lambda, phoenix, FC++ merger then the above concerns would be addressed. It surely doesn't hurt that the authors of those other libraries expressed strong interest in the above direction. And as was pointed out in the review some of the ideas from FC++ might successfully be applied to other boost libraries such as function and/or bind. If FC++ was part of a single consistent set of FP components within boost then there would be good odds of achieving consensus to accept. The changes to bring this about would be of significant enough magnitude however that I would not be comfortable with provisional acceptance today -- a future review (or reviews of pieces are submitted independently) would be required. ** Evaluation of Educational Value Since boost is not necessarily restricted to purely practical libraries I also considered accepting FC++ into boost on the grounds that it provides an environment in which C++ programmers can learn more about and experiment with FP. FC++ enjoys some degree of success in this area. However I found it disturbing that during the review a number of traditional/imperative-style C++ programmers were just not "getting it" about FP. Perhaps a case could be made for accepting FC++ in its entirety on educational grounds after some of the improvements suggested by reviewers were implemented, e.g. improvements to the documentation and naming (useful in any case), the completion of some additional features such as Monads, or deeper documentation of the useful implementation techniques. But I must admit that I find this strategy less attractive, and I would urge you to try to break things up instead. One of the difficulties in finding acceptance on purely educational grounds might be characterized like this: if I was to recommend a way for an imperative programmer to learn more about functional programming today I would probably suggest a jump into an (OCa)ml, Haskell, or even a Lisp/Scheme environment. I am not sure that this I would recommend the FC++ environment for this purpose even with the changes suggested above. That is, I am not entirely convinced of the *purely educational value* of working with a functional programming DSL within C++. I really would prefer to see the FC++ ideas used in a practical mixed paradigm setting. * Opinions of the reviewers I was a bit concerned about the dearth of reviews during the first week so I decided to extend the review. The final number of reviews was still lower than I would have liked, but in the end I received approximately 4 no votes and 7 yes votes, with varying amounts of effort spent. Of the no votes, there was some support for acceptance after a later review, pending certain improvements. At the same time a number of the yes votes urged acceptance only after similar concerns were addressed. From this one could argue that there was near consensus that the community would be interested in accepting FC++ after these issues were addressed. The issues include the state of the documentation, the monolithic nature of the lib, and the incomplete nature of some components of the lib, e.g. monads. So I view some of the yes votes and no votes as differing mainly on whether to accept now with the above provisions or whether to require a second review after the above concerns were addressed. I spent some time vacillating between those options before finally settling on my decision to require a second review before acceptance. Given the significant nature of the requested changes I was only comfortable choosing the latter option. * Conclusion Though I am sorry not to be able to accept FC++ into boost today I would like to acknowledge its authors for the influence this library has had on other boost components. I strongly encourage you to keep working to bring the innovations from FC++ into boost in the future. I would also like to acknowledge Brian for his many creative contributions to the boost community and his thoughtful and professional posts. I am sure that I am not alone in saying thanks for all your efforts and I look forward to hearing more from you in the future. - Mat

9 14

RE: [boost] Re: [program_options] Re: Unicode support
by Ferdinand Prantl 06 Apr '04

06 Apr '04

Hello, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > glib did a very good > > implementation of UTF-8 handling and Glibmm is a well done > C++ wrapper > > but it lacks the "standardness". Something like > boost::ustring COULD > > bring a widely accepted UTF-8 aware unicode string to C++ > programmers. > > A somewhat relieving thought. > > I am not exactly sure if UTF-8 or UCS-4 is better as > universal solution, but some solution is surely needed. I am afraid there is no universal solution for all users. The easiest solution is based on the native basic_string<>, which is specialized for char (8-bit) to support ASCII/ANSI encodings and for wchar_t (16-bit) usually used for UCS-2 encoded strings. UCS-4 (32-bit) encoding would require another basic_string<> specialization. UCS-2 held all characters in Unicode 1.1, There was a need for more unique numbers and UCS-4 was introduced in Unicode 2.0. Unfortunately there is no 4-byte character specialization for basic_string<> in STL yet. Generally speaking UTF encodings (e.g. UTF-8 or UTF-16) are not suitable for the fast in-memory usage because some operations, for example at(int) and length() have not O(1) but O(n) to give a result. They (UTF, T=Transformation) are better for storing texts as they save place by using variable number of bytes for a character. However UCS (e.g. UCS-2 or UCS-4) are fast for memory operations because they use fixed character size. That is why I would not like to use basic_string<utf8char> in memory, rather basic_string<ucs4char> instead, but I would not generalize it for all possible applications. You can expect initialization from (const char * argv []) on all platforms or (const wchar_t * argv []) on Windows in UCS-2. With the basic_string<> you already have support for the parameters from the current locale (char) and for parameters in UCS-2. If we take an option to read parameters into basic_string<wchar_t> or basic_string<ucs4char_t>, where the character size or encoding is not the same as the native encoding on the command line, there is an affinity to streams. Some shells allow usage of UTF-8 encoded parameters or, generally, usage of characters out of the current locale. It means, that a program can choose the way, how to encode all characters from Unicode to char. UTF-7/8, etc. I would like to have a solution similar to streams: imbue(). Having this, you could convert internally every argv[x] using imbue(y) applied to a stringstream, where the facet y provides the caller. The target character capabilities could choose the caller by providing a basic_string<> specialization. On the other hand, such a conversion can be performed also by a user. The parameters sent to main() are char* or wchar_t* and thus program_options can give them back just as they are in basic_string<char> and basic_string<wchar_t>. The client can use his facet to imbue a basic_stringstream<> initialized with the parameter from program_options. Or a conversion library could be used to perform the conversion, something like lexical_cast<> does for type converions. It is a matter of convenience only - separate converions library (no support for encoding in program_options) or imbue(), performing the conversion inside the program_options. However, the conversion should not be implemented for program_options only, that is why I suggested an existing interface - facets. > > Or did I miss something? Is something like this part of > boost already? > > Nope :-( Even UTF-8 encoder is not in boost yet. You can find come converting facets for UTF-8 raedy for imbue() to a stream in the files section on yahoo. Unfortunately not finished or not reviewed... Ferda > > - Volodya

4 3

Planning Next Release
by Aleksey Gurtovoy 06 Apr '04

06 Apr '04

Hi all, I'd like to test the waters for the last week of June -- let's say Monday, June 28 -- being the target date for the next major release, which I am volunteering to manage. Correspondingly, June 21 or so would be a branch-for-release date, by which everything should be in CVS and in the releasable shape. What is a "releasable shape" is a separate question I'd like to postpone for now, but basically the proposed target date implies that the for all the new stuff to get into release it'd have to be in the CVS by the middle of June -- which gives us about two months to prepare/finish things up. How does this sound for everybody? Any objections/adjustments to the dates? -- Aleksey Gurtovoy MetaCommunications Engineering

6 7

How to get an unique identifier for an edge
by Lodewijk Smit 06 Apr '04

06 Apr '04

Hi, I tried to get an unique identifier for a node and an edge. The node is possible e.g.: adjacency_list<> someGraph; std::pair<adjacency_list<>::vertex_iterator,adjacency_list<>::vertex_iterator> p; ed = add_edge(0,1, someGraph); property_map< adjacency_list<> , vertex_index_t>::type in; in = get(vertex_index_t(), someGraph); for (p = vertices(processGraph); p.first != p.second ; ++p.first) { cout << *p.first << "\n"; cout << "index: " << in[*p.first] << " \n"; } However, the same idee does not work for an edge: std::pair<adjacency_list<>::edge_iterator,adjacency_list<>::edge_iterator> pe; property_map< adjacency_list<> , edge_index_t>::type inedge; inedge = get(edge_index_t(), processGraph); for (pe = edges(someGraph); pe.first != pe.second; ++pe.first) { cout << *pe.first << " "; cout << "index: " << inedge[*pe.first] << " \n"; } I can not figure out how to get an unique id for an edge and I can not understand how the property maps works from the documentation nor I can find how such a edge_index_t property is defined. Can somebody provide some help. With kind regards, Lodewijk __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

3 2

RE: [boost] Re: [program_options] Unicode support
by Ferdinand Prantl 06 Apr '04

06 Apr '04

Hi, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > I understand, that stl support unicode for unicode is not the best, > > but there are facilities, that can provide required > functionality if > > properly extended/configured. > > Let's break the question in two parts. > > 1. Should 'unicode support' mean that there are two versions > of each interface, one using string and the other using > wstring? I think this kind of Unicode support is not good. It > means that each library which accepts or returns strings must > ultimately have double interface and be either entirely in > headers, or use instantinate two variants in sources -- which > doubles the size of the library. Not all libraries must have doubled interface or templated interface for any basic_string<C, T, A>. Different libraries have different string on their interface and one must convert among them. Typical is for example ANSI <-> UCS-2 on Windows. It is only convenient to be able to avoid such conversions when working with standard or widely used libraries, for example boost_regex, which provide templated interface and one can choose 8-bit or 16-bit character space (in future probly 32-bit with a new basic_string<> ;-). I think program_options, being also such a widely used and quite small library, shoud be also templated (no offence, meant just the size, not the importance ;-). > 2. Should program_options library use UTF-8 or wstring. As > I've said, neither is clear leader, but UTF-8 seems better. Here I disagree. Command-line shells work with all characters in the current locale (the whole 255 characters space of 8 bits is used). You would give the user a character array in UTF-8 encoding, which is not typical case today, one processes the parameters by basic_string<char>(argv[x]) in the current locale. I think you should simply use basic_string<> as a template and the encoding let on the caller providing its specialization or perform the conversion himself. Or support the encoding internally by providing an interface to set it, not to do it with a fixed encoding support, even if I like UTF-8 because it suppors full Unicode character range, not like UCS-2. Thinking more, you can expect rather short strings coming to program_options, not megabytes of text. For this usage is more suitable to use fixed-size character encodings because they are faster and easier to work with, having direct support in basic_string<>. Does anybody know, if there are plans to add something like basic_string<ucs2char_t> into the next C++ standard? > > I think, that there is no big reason to try to reinvent a wheel and > > provide all encopasing solution in the library like program_options. > > It should be enough if it will be unicode-enabled so it can > be used in > > the any specific scenario, provided that all necessary > facilities are > > on place. > > It's *far* from all encopassing solution. In fact, the > changes in program_options will include: > > 1. Adding ascii -> UTF-8 conversion in parsers 2. Adding > UTF-8 -> ascii conversion in value parsers 3. Adding unicode > parsers with UCS-4 -> UTF-8 conversion 4. Adding unicode > value parsers and UTF8 -> UCS-4 conversion > > That's all, and given that there's at least two UTF-8 codecs > announced on the mailing list, not a lof of work. And this > will add Unicode support without changing interface a bit. Yes, you are right; there is not much work to add the conversion code into the internals of program_options. I also wrote my own UCS-2 <-> UTF-8 encoding routines to use them for basic_string<char> <-> basic_string<wchar_t> conversion. However, I think, that we should reuse as much as possible and not to rewrite similar code in every library, which works with strings coming from a real user input. Your solution to support UTF-8 invisibly changes the interface anyway - not the text of prototypes directly but the behavior of the interface (encoding of strings). Nevertheless, you could support this encoding conversion not only by providing your own conversion routines, but rather by accepting existgin facets, which help streams similarly (as I wrote in the former e-mail). Then one could simply write a conversion facet once and use it for a stream input and also for a cmdline input, sharing the implementation. Ferda > - Volodya

2 1

Re: [boost] Re: Planning Next Release
by Aleksey Gurtovoy 06 Apr '04

06 Apr '04

Giovanni Bajo writes: > Aleksey Gurtovoy wrote: > > > I'd like to test the waters for the last week of June -- let's > > say Monday, June 28 -- being the target date for the next major > > release, which I am volunteering to manage. Correspondingly, > > June 21 or so would be a branch-for-release date, by which > > everything should be in CVS and in the releasable shape. > > I think we should try and allow a larger period of time to fix the > regression tests. It's definitely going to be more than one week, and the above wasn't meant to suggest otherwise (note "the releasable shape"). I did imply a different branch creation pattern than you suggest below, though. > I suggest we branch for instance 1 month before the release, and then > we restrict the branch only to the patches which stabilize the > regression tests (no new features allowed there). Plus, the trunk is > free for new features, and development is not stalled. Early branching would definitely give us more freedom for main trunk evolvement, and might even improve our release cycle in terms of predictability (although it's been my impression that in past almost all destabilizing checkins were due to "judgment errors" rather than accidental mistakes). On the other hand, any major development should be led in a separate branch anyway, so stalling is more a theoretical problem, IMO. The downside of branching early, is, of course, that the developers making fixes would have to do more work incorporating those both in the branch and the main trunk. I guess it's worth trying. What do others think? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

BCP suggestion
by Edward Diener 06 Apr '04

06 Apr '04

First off, BCP is excellent. Here is a suggestion which might make it even more excellent, but it might not be deemed doable or important enough considering the extra parsing that needs to be done. I would like to see BCP be able to take a compiler-version/operating system/standard library, or some combination of these possibilities, and produce its file list with these extra narrowing possibilities. This would largely mean being able to look at the config files and eliminate the files which don't pertain to a particular compiler/os/standard library, but it might also affect other files among Boost's headers and libraries. My idea is that one may want to only distribute certain Boost files and libraries for a particular implementation, whereas BCP gives all related files for a particular file without considering specific implementations. I realize that such an undertaking may be a considerable amount of work and I am not trying to saddle John Maddock with it, especially as manually eliminating files which do not pertain to a particular implementation may be fairly easy. Ideally, however, it would be nice if one could do this programatically.

3 3

Segfault in token_functions.hpp
by Joshua Moore-Oliva 05 Apr '04

05 Apr '04

It appears that there is a problem in token_functions.hpp with probably the *next iterator. It appears to read out of previously freed memory. I recompiled boost with debugging information, and here is the backtrace of boosts invalid memory access's. ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x80537C6: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:305) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AD is 57 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x8053825: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:314) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x805388D: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:319) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x80538B2: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:319) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x80538D7: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:320) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so)

2 2

Re: [boost] Review Result: Indexed Set
by JOAQUIN LOPEZ MU?Z 05 Apr '04

05 Apr '04

----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Lunes, Abril 5, 2004 0:05 am Asunto: [boost] Review Result: Indexed Set > Indexed set library by Joaquín Mª López Muñoz > has been accepted into Boost. > First of all I'd like thank Pavel, without whose encouragement over many months the library wouldn't have reached the review stage. Thanks also to all the people who participated in the review: it's been a lot of fun and a number of interesting issues have been raised. I plan to deliver a post-review version during April, addressing all of the minor pending requests. As for the new features (ranked indices, bimap, etc.) I guess I'll wait till the first official Boost release in order to gain some feedback first. It is my understanding that noone opposed to new features being postponed until a first official version has been released. A couple of features will probably make it before, though: utilities for composition of key extractors (which are now in the examples only) and serialization support. The naming issues are still not closed, as I'm growing more doubtful that we should embed the library into boost::container. I'll probably post a revised naming scheme during this week or the following. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[BGL] forced client complexity
by Provisional Dissonance 05 Apr '04

05 Apr '04

If one accepts the axiom that "a picture is worth a thousand words," then it naturally follows that discussion of graphs is always overly prolix. Sadly, the same reasoning is also applicable to the code of graph libraries. Boost.Graph seems to expose and require an unnecessarily large amount of complexity, though. Whereas libraries like Spirit go to great lengths to make hard things easy, BGL seems to try only to make hard things possible. The amount of scaffolding required to use BGL for even the simplest of projects often dwarfs the code size of a naive, yet functional, special-purpose implementation. While I understand that the BGL is deeply entrenched in boost culture, certain academic circles, and even publications, I nonetheless suggest that BGL lacks the ease of use necessary for widespread adoption. Even knowing that ease-of-use is not a criterion for acceptance into boost, looking at what is required of the client to use the BGL always leaves me feeling perplexed. Is there any particular reason that a simplified interface is not made available? Perhaps a container adapter could be packaged with the library allowing a compromise of functionality and flexibility for simplicity? If a graphing problem is trivial, shouldn't BGL provide a trivial solution? Why are the simplest useful examples several hundred lines of code? I apologize for all of my vague criticisms - my intention is not to flame but rather to test the waters. It is difficult for me to assess whether the simplicity I yearn for isn't present for stylistic reasons or whether it would rather necessitate a sacrifice of flexibility, functionality or implementation clarity. Nor is it clear to me to what extent these criteria can be compromised to promote clarity of client code. For what it is worth, the kind of ease-of-use I'm imagining might look like: #include <less_than_10_graph_headers> ... digraph<some_node_type,some_edge_context_type> g; g << "vertex" << make_pair("vertex", "implicit_vertex"); g.add_edge("brother", "sister", "sibling"); if(g.find(make_pair("brother", "sister"))) related = true; Could someone please elucidate on why it is impossible/impractical/unnecessary/whatever for a graph library to have such an interface? Should I accept that the BGL is not the magic bullet graph library and move on, or can this kind of simplicity be somehow found within? Thanks in advance, prs __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

3 7

Re: Re: Re: C++ subranges
by Brian Martin 05 Apr '04

05 Apr '04

Maciej - I need to think deeply about some of the things that have been pointed out. At the moment (this week) there's a project I want to progress a bit so won't be able to do that just yet. One thing I might do immmediately is to do something about that conversion operator. I think it's causing some problems with the stream operators, just for starters. You sometimes get ambiguities in certain contexts and, as you said, these operators can do that. I have a fix, but am not totally satisfied. I've attached the "fixed" version. The comment at the top has also been corrected. Nice to have comments that don't tell porkies.

1 0

Traits and Policies
by Malcolm Smith 05 Apr '04

05 Apr '04

Hi, I am new to this list and saw the messages related to traits and policies. I am an experienced C++ developer but have a limited knowledge of the STL and even less of boost - I've joined this list in an effort to become more familiar. I understand policy classes but am not very familiar with traits. Can someone recommend a link for me to follow so I can better understand what they are as well as when, why and how to use them. TIA. Malcolm Smith MJ Freelancing http://www.mjfreelancing.com Borland Technology Partner

4 4

1.31.1?
by Stephan T. Lavavej 05 Apr '04

05 Apr '04

I remember hearing shortly after its release that 1.31.0 had some serious problems and that 1.31.1 was in the works. Whatever happened to that? Stephan T. Lavavej http://nuwen.net

3 2

Re: C++ subranges
by Brian Martin 05 Apr '04

05 Apr '04

Brian Martin wrote: >I'll have another think about some of the compile time check issues. I have and have done the following: 1) Compile time checks would be nice but are basically impossible. At least the ones that count. Such as: subrange<int, 1, 20> sub_20(30); or sub_20 = 300; Pascal traps this kind of thing but C++ can't, as far as I can see. Runtime only, I'm afraid. I am of the opinion that the compile time checks that were given in Maciej's example code are of limited use since the real benefit of subranges is runtime (in my humble opinion). In the example code, it was possible to assign/copy different subrange types, provided the source had a range inside the destination. For now, my subrange doesn't allow different subrange types to mix. 2) Agonised over whether or not to remove the typename T (I call it a "base type" a la Pascal terminology) from the template. In my previous post I said that it allows any type to be stored in the subrange, forgetting of course that you can't have doubles, classes and C strings as non-type template parameters. Doh! Actually, this is what I want since subranges of classes is a bit odd. Floating point subranges would have been nice, but Pascal doesn't allow them either. There is a way of doing it, but it messes up the syntax. I've kept the base type because you waste storage if you're storing anything smaller than a long. There's no class overhead (on my compiler) so this doesn't make the wastage trivial. The waste is ok if you're only using a few subranges but in one project I'm storing potentially large numbers of subranges (of shorts) in STL containers and then reading/writing them in binary from/to files. Didn't like the files being 2 times bigger than they should be. So, reluctantly, I've kept the base type. 3) I've used a conversion operator. I usually avoid these but in this case it integrates subranges nicely into the type system so that built in types and subranges can mix freely in expressions. The template is, after all, supposed to be a (restricted) integral type. 4) Removed operator~(). It always fails since the value gets its upper bits set to 1 which will exceed the subrange unless you've set the upper limit to the maximum the type can store. There are obvious problems with signed types too. 6) Have attached some code - the subrange class itself and a test program for anyone who wants to give it a go.

3 2

Re:Re: [boost] Serialization: versioning and XML.
by Robert Ramey 05 Apr '04

05 Apr '04

Anatoli Tubman wrote: >Robert Ramey wrote: >> I briefly considered this approach. I imagined that upon archive >> creation the XML input could be parsed into a node tree. (insert plug >> for spirit >> here) The load_override function would be altered to search the >> correct part of the tree. So this would work and be pretty clean. >> I'm sure other approaches such as using SAX or DOM to parse the tree would work as well. >> Maybe there's another way I never thought of. >> >> The main reason I rejected the idea was that I didn't see it working >> with arbitrarily size streams. I envision serialization being used with stream >> much larger then available memory. This suggested to me an "on the fly" >> loader rather than a "pre-loaded". >Loading the entire archive is not necessary. The other approach is to >acquire a *description* of the data structure being deserialized, and >process the XML stream sequentially. That is, operator<< does not do >deserialization by itself, but inserts a member *descriptor* into a map. >When all data members are collected in this fashion, they are deserialized >as corresponding tags come in. >IOW one needs random access to *either* the data stream *or* to the data >structure being deserialized. Data streams are too big, so we should choose >data structures instead. >One doesn't need the entire tree of data structures either, only the node >currently being processed, because descendants changing parent nodes are >not supported. I don't see how to do this while keeping archive and serialization descriptions independent. >This works because a typical class is much smaller than a typical data >stream, which usually contains many instances of the same class. >I have some experience with one (pre-XML, pre-C++) serialization library >that does (approximately) just that. It uses a custom tagged format, but >there's no reason why it shouldn't work with XML and C++. My focus was finding the most expedient and efficient way to use XML format with the rest of the serialization library. In the course of investigating my options, I had occasion to look more deeply into XML. One thing that occurred to me was the possibility of making an archive implementation which generated an XML schema rather than the XML data. This would generate and XML data schema either in parallel with the XML data archive or as a separate operation. An XML tagged input implementation might make use this as well. I would guess others might find a use for such a schema that would automatically be in sync with the program code that generated the data. Robert Ramey

2 1

Re: Re: [BGL] forced client complexity
by Johnny Yune 05 Apr '04

05 Apr '04

"Vladimir Prus" <ghost(a)cs.msu.su> wrote: > Hi, > (btw, if possible, it would be nice to > know your real name, so that I could > write "Hi <your real name>") Ah, excuse me. It would please me for you to call me Johnny Yune. <snip> > In fact, something like > > typedef graph<City, Road> Road_map; > > looks quite reasonable to me. > > > If the node's "index" is > > related to the object, why would it not be a natural > > member of the node-type's class? > > I don't think "index" should be type of 'City' class. Nor does it seem a logical candidate for a member. In fact, as a client, you shouldn�t and needn�t know anything about it. > > If, instead, it is a > > synthesized construct for communication between a > > graph and the algorithm operating over it, why should > > the client be responsible for its maintenance instead > > of the framework? What are the advantages of this > > approach? What are the disadvantages of simplifying > > things for the client? This is the type of design > > issue that I intended to question with my initial > > post. > > I think the biggest problem is: It seems like you�re looking at this from the framework side instead of the client side. That�s fine, but it still isn�t clear to me why adding another layer of abstraction should affect the internal workings so heavily. I�ll try to address your questions with respect to how I would probably do it, though. >how do you identify vertices? If you use > "City&" you'd have some problems: > > 1. How vertices are really identified? Using operator==? Really identified by whom and for what purpose? >Is it possible to > insert two 'City' objects which are equal? I think that should probably depend on the underlying graph type. > If not, how to insure uniqueness? I guess you would want to make sure to not insert duplicate vertices. > Do we really want 0(log n) lookup on each 'add_vertex'. Huh? I admit to not being intimate with BGL�s internals, but it seems like a hashed set of Cities to indexes or whatever the underlying graph structure wants to use to identify nodes would be reasonable and speedy. > > 2. Even if 'City' objects in a graph are unique, how will add_edge be > implemented? Do you need O(log n) lookup to find internal adjacency >lists? Again, using a City as a node-type shouldn�t affect the runtime. If you can think of a way to define a vertex that allows o(1) lookup, I can probably give you a city->your_vertex_type hashmap that allows you to maintain that speed. > > 3. What's edge, and how it is identified? I would leave that up to the underlying container. You�ll notice that in my original post, my scratchy pseudocode declared a graph as g<vertex_type, edge_context_type>. I kind of imagined edge_context as being some sort of arbitrary meta-data about the link, generally useful only to the client. Maybe the edge context could be a simple member of the graph-managed property map? >For example, 'Road' might not > contain source/target vertices, but still we need to be able to find > source/target vertices. The whole point of the abstraction is to free the client from trying to figure out how to fit cities into roads. The underlying container could certainly keep a mapping from one to another. > > One possible solution that I see is the make > vertex_descriptor be always > pointer type. It will point at some > internal structure but also provide > operator* which will return 'City'. Would that simplify things for the client? >Or, maybe, it should be possible to > iterate over values of 'City', not only over values of >vertex_descriptor. Iterating over cities sounds absolutely reasonable to me. Much more so than iterating over some arbitrary vertex_descriptors, even. > > I still don't know if using City to identifiy vertices is feasible. I have no reason to think otherwise and I do think it sounds simpler from a client-side perspective. Food for thought. Thanks, prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Spirit skip parser questions.
by Jia Pu 05 Apr '04

05 Apr '04

I am trying to write a parser which skipps white space and C, Java style comments. To get familiar with spirit, I did some experiments, here is a question. First, I write a simple grammar to accept some non-white space chars. //////////////////////////////////////////////////////////////////////////////// struct FOO_GRAMMAR : public grammar<FOO_GRAMMAR> { template <typename ScannerT> struct definition { typedef rule<ScannerT> rule_t; definition(ABNF_GRAMMAR const & self) { r_LETTER = range_p('a','z') | range_p('A','Z') | '.'; r = (+r_LETTER); } rule_t r, r_LETTER; rule_t const& start() const { return r; } }; }; //////////////////////////////////////////////////////////////////////////////// I used FOO_GRAMMAR with space_p as skip parser: ////////////////////////////////////////////////////////////////////////////// FOO_GRAMMAR g; std::string line = "This is a test parser."; parse_info<> info = parse(line.begin(),line.end(), g, space_p); //////////////////////////////////////////////////////////////////////////////// This works perfectly. Then, I tried to wrap the skip parser in a skip grammar, since eventually I need a more complicated parser. So I wrote the skip grammar as: /////////////////////////////////////////////////////////////////////////////// struct SKIP_GRAMMAR : public grammar<SKIP_GRAMMAR> { template <typename ScannerT> struct definition { typedef rule<ScannerT> rule_t; definition(SKIP_GRAMMAR const & self) { rule_t r_SKIP = space_p; } rule_t r_SKIP; rule_t const& start() const { return r_SKIP; } }; }; ///////////////////////////////////////////////////////////////////////// I tried to parse the same sentence as before: /////////////////////////////////////////////////////////////////////////// FOO_GRAMMAR g; SKIP_GRAMMAR skip; std::string line = "This is a test parser."; parse_info<> info = parse(line.begin(),line.end(), g, skip); ////////////////////////////////////////////////////////////////////////// This time the parsing failed. Can anyone tell me why? I thought grammars are just like rules. And any suggestion on building a parser skipping certain pattern? I just can figure it out by reading the doc. Thank you. _________________________________________________________________ Persistent heartburn? Check out Digestive Health & Wellness for information and advice. http://gerd.msn.com/default.asp

2 1

lexical_cast<wstring>(string)
by Jared McIntyre 05 Apr '04

05 Apr '04

Some time ago I read a discussion about possibly adding the ability to perform a lexical_cast of a regular to a wide string, and vice-versa. There was also discussion of possibly adding similar functionality to string_algo (though I tend to like the lexical_cast better for this). Has anyone looked more deeply into solving this problem? I've found these operations to be extremely common in my work on applications that are written in unicode, but may have to talk with non-unicode network protocols, libraries, etc. Jared

1 0

Review Result: Indexed Set
by Pavel Vozenilek 04 Apr '04

04 Apr '04

Indexed set library by Joaquín Mª López Muñoz has been accepted into Boost. Thanks Joaquín for innovative and professional work and for keeping up during moments when feedback was rather low. Review of the library was very positive. Thanks to all people who spent time contributing. Several points to improve had been identified during review. Consistent names for the library were discussed and hopefully identified. Some points Joaquín did or plans to address: _________________________________________ FUNCTIONAL REQUESTS 1. Issue BOOST_STATIC_ERROR if duplicate tags. This I've already done in my local version. Works OK. 2. Extend operator== and familiy to support indices over elements of different types (Gary Powell). I've done it in my local version, no problems arose. 3. Improve efficiency of equal_range (Arkadiy). 4. Include bimap in the roadmap. 5. Include ranked indices in the roadmap. 6. Include serialization support in the roadmap (it's already there.) 8. compose_key and lex_compare promoted to the library (they are implemented in examples now.) No problem from my part. 9. Include a concepts section for multi-indexed containers. David accepted that this be delayed. STYLISTIC REQUESTS 1. Navigation bar in the docs. 2. Limit source code to 80 chars per row (already done.) 3. Limit source code in the docs to 80 chars per row. 4. Rename "far pointer" to "chained pointer". I don't like this. 5. Other stylistic improvements that I've already applied. As for header organization, I'll move to a fine-grained policy. _________________________________________ New features and usage techniques are identified and will likely be implemented and documented. Care is taken keep the library easy to use. /Pavel PS: could someone try to run test "test_all_main.cpp" with VC 6.5 or 6.6. and report result exit code, please?

1 0

boost/graph/push_relabel_max_flow::is_flow() bug?
by Arun Bhalla 04 Apr '04

04 Apr '04

Hi, I'm not really a user of Boost, but I've been referring to the Boost Graph Library code for another project. In particular, I've been looking at push_relabel_max_flow.hpp. I was writing a unit test which followed the same ideas of the is_flow() test, and it was failing on what should be a flow network with a valid maximum flow. The code in question: // a is an edge_descriptor if (capacity[a] > 0) if ((residual_capacity[a] + residual_capacity[reverse_edge[a]] != capacity[a]) || (residual_capacity[a] < 0) || (residual_capacity[reverse_edge[a]] < 0)) return false; I contend the test should actually be: // a is an edge_descriptor if (capacity[a] > 0) if ((residual_capacity[a] + residual_capacity[reverse_edge[a]] ! != capacity[a] + capacity[reverse_edge[a]]) || (residual_capacity[a] < 0) || (residual_capacity[reverse_edge[a]] < 0)) return false; I refer to an example network in CLR (1st ed.), p.589. There are several vertices, but I focus on vertices v1 and v2. In this graph, we have capacities c(v1,v2) = 10 c(v2,v1) = 4 and residual capacities cf(v1,v2) = 11 cf(v2,v1) = 3 With the above (original) test, it would fail because 11 + 3 (the sum of residual capacities) != the capacity of either edge. This would hold true if the sum of residual capacities were compared with the sum of capacities. Ordinarily this test would work if reverse_edge[a] has a capacity of 0, which would be the case if the edge (a) is in the flow network, but its reverse is not. I'm not a graph theory expert, though, so I defer to anyone who is. :) Thanks, Arun

2 1

License oddity
by David Abrahams 04 Apr '04

04 Apr '04

I just noticed something strange about the license. It seems to require that derivative works and copies don't use the "by reference" technique we're using to refer to the license in our own sources: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software... I'm beginning to wonder if the current "by reference" technique is really compatible with the license. Will the intrigue never end? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Re:Re: [boost] Serialization: versioning and XML.
by Robert Ramey 04 Apr '04

04 Apr '04

Anatoli Tubman wrote: >It absolutely certainly will be a new archive class. Sorry if it wasn't >clear from the start. >I just think such an archive/serialization library is (a) useful enough >to bea part of boost and (b) similar enough to the existing boost >library to share the namespace with it. I've got no problem with this. >I understand fully that this idea works only with tagged formats (not >necessary just XML), that's why I'm saying that it should probably >use a different syntax or maybe a sub-namespace under boost::serialization. Within the boost::archive namespace I've got things like: basic_xml_iarchive xml_iarchive xml_wiarchive etc. I would think there is plenty of room for something like: basic_tagged_iarchive basic_tagged_xml_iarchive tagged_xml_iarchive tagged_xml_wiarchive etc. >I'm staying within program-structure-drives-data-format school of >thought. As long as you can stick with this, I think you can be successful. I briefly considered this approach. I imagined that upon archive creation the XML input could be parsed into a node tree. (insert plug for spirit here) The load_override function would be altered to search the correct part of the tree. So this would work and be pretty clean. I'm sure other approaches such as using SAX or DOM to parse the tree would work as well. Maybe there's another way I never thought of. The main reason I rejected the idea was that I didn't see it working with arbitrarily size streams. I envision serialization being used with stream much larger then available memory. This suggested to me an "on the fly" loader rather than a "pre-loaded". My implementation does require that tags remain in sequence and are all anticipated. Your proposal wouldn't have this restriction and might be preferred in certain applications. So I'm happy to encourage your efforts. I also hope that other users will be inspired to address more particular needs by creating their own archives class variations. In the long run, I'm trying to get out of the archive creation business in the same way I'm trying to get out of the class serialization business. >I don't precisely understand how going in the other direction >is ever useful. Okay, given a DTD, you can generate a program that could >read and write a bunch of data structures; but what will it *do* with >them? I can see the need for and utility of this. It's just that it's a whole different problem than what serialization addresses. Good Luck with this. Robert Ramey

2 1

Bug fix for BCP
by Edward Diener 04 Apr '04

04 Apr '04

Evidently I either don't have access to the Boost CVS repository on SourceForge or I still can't figure out how to use CVS, so here is a fix to a serious problem with John Maddock's BCP program, and someone else can make the fix. In bcp_imp.cpp, line 17 needs to be changed from: : m_list_mode(false), m_cvs_mode(false), m_unix_lines(false), m_scan_mode(false) to : m_list_mode(false), m_licence_mode(false), m_cvs_mode(false), m_unix_lines(false), m_scan_mode(false)

2 1

Re: [boost] Re: Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 04 Apr '04

04 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Jueves, Abril 1, 2004 8:35 pm Asunto: Re: [boost] Re: Formal Review: Indexed Set > I believe you should leave in the support for multiple tags per index. > Possible use cases include: > > - Including the key type as an index tag. > > - Using tags to flag various fields for some other algorithm -- in > this case, different fields could be flagged for use by various > different algorithms. If I'm understanding you, the case use you propose could be illegal. Do you mean something like: indexed_set< int, index_list< unique<tag<first,marked>,...>, non_unique<tag<second>,...>, non_unique<tag<third,marked>,...> > > So that "marked" can be taken advantage of by some algorithm? If so, this clashes with a request by Brian McNamara that duplicate tags be not allowed. If you mean something else, I'd appreciate if you could ellaborate. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-929094 ] patch for boost::filesystem
by SourceForge.net 04 Apr '04

04 Apr '04

Bugs item #929094, was opened at 2004-04-04 04:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=929094&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: patch for boost::filesystem Initial Comment: /usr/local/include/unit++.h: In member function `virtual void unitpp::exception_test<E>::operator()()': /usr/local/include/unit++.h:163: error: there are no arguments to `fail' that depend on a template parameter, so a declaration of `fail' must be available /usr/local/include/unit++.h:163: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=929094&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Proposed change to license references
by David Abrahams 03 Apr '04

03 Apr '04

Given recent advice from Diane Cabell, director of Harvard's Berkman Center for Internet and Society, I propose we change the way that boost source files refer to the bost license from: // Use, modification, and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy // at http://www.boost.org/LICENSE_1_0.txt) to: // Distributed under the Boost // Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) The earlier license reference, by referring explicitly to "use, modification, and distribution", legally excludes important issues like "display", which are covered by the license itself and are intended to apply to source files. I'm posting this now to give people a chance to come up with any other issues -- **with the license reference comment**, not the license itself -- that may need to be addressed before we make a change. If there are no new issues within a week or so, we'll make it official. -- Dave Abrahams Boost Consulting www.boost-consulting.com

8 13

Suggestion: link to the libraries page not easy to find
by Marcello Pietrobon 03 Apr '04

03 Apr '04

Hi Boost team, I don't know where to put this suggestion. Even if boost is now well known, I think in the boost's home page there should be a well visible, easy to find, link to http://www.boost.org/libs/libraries.htm because this is exactly what boost is about, I think. Best Regards, Marcello

5 12

Another mailing list description?
by Daryle Walker 03 Apr '04

03 Apr '04

Would anyone that runs the mailing list at <Boost-langbinding(a)lists.sourceforge.net> like to give a description about what that list is about so you (or me if you don't have CVS-write access) can add it to "BOOST_ROOT/more/mailing_lists.htm"? I was going to add it myself, but I can't gleam enough information for a description blurb. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Re: Re: [BGL] forced client complexity
by Johnny Yune 03 Apr '04

03 Apr '04

Jeremy Siek" <jsiek(a)osl.iu.edu> wrote in message news: > So I think your question can be boiled down to two > questions, why does the BGL use vertex descriptors? > and why does the BGL use property maps? That probably restates my question more succinctly than I would be able to. > The BGL graph interface was designed so that many different > graph data structures could be uniformly manipulated. > It sounds like the data structure that you are most familiar > with is where each node is an object, and the connecting > structure of the graph is represented with pointers. For my na�ve endeavors, I most often use adjacency matrices. >However, > another important graph data structure is the adjacency list > representation, where there are no node objects. Instead there > is just an array of lists of integers. An integer n is associated > with each node, and the out-edge list for a node is at offset > n in the array. That seems like an intuitive way for the back-end to work. Why should I, as a client, need to concern myself with those details, though? I�m sorry if I sound critical, but I just don�t understand. To me, it feels like using some sort of balanced tree container and having to concern myself with whether a node is red or black � why do I need to know? > The vertex_descriptor abstraction provides an opaque handle > to a "vertex", whatever that may be for the data structure. > For one graph type that may be node*, for another int. > The purpose of the property map interface is to provide a > uniform way for an algorithm to access data that is associated > with a node or edge. Again, there are many ways that such > an association can be implemented, with various time, space, > and convenience tradeoffs. Here are some examples: > > 1. Associated data is a member of a struct > 2. Data is in an array, organized by vertex index offset > 3. Data is in a hash table, somehow keyed on the vertex. > > Now, the problem you're pointing out is that the extra > level of indirection of the property map makes the > syntax rather unwieldy for accessing data. For > example, instead of: > > v->color > > one must write: > > get(color_map, v) > Actually, what I really wanted clarification on was why the task of managing this mapping was left to the client instead of the underlying graph structure. The differences in syntax, above, are only indications of my confusion about the semantics. To wit, given your examples, I wouldn�t necessarily expect v->color to have anything to do with the color_map. v->color looks like a property of a vertex, while get(color_map, v) looks like a property of a graph. > (not to mention the trouble of setting up the color_map > to begin with) Well, this does make things a lot more complex. The need for such mappings is quite clear to me � the need for the client to �set them up� as opposed to the graph is unclear to me, though. If I were to ask an algorithm to generate a chromatic number over a graph, I could envision having a property map of some possible coloring returned to me. Why I would have to set one up or pass one in, though, I am unclear on. In reviewing my post, I am realizing just how astute you were to identify the property map as a major source of confusion for me � I am only beginning to be able to articulate why it �feels� unnatural for me. I guess the big question, then, is �why use property maps instead of functors?� Would not functors also allow communication between arbitrary user-defined vertex types, the graphs that store them (even if only by lookup mapping to some arbitrary internal data type), and the algorithms that operate over them? My gut tells me that it is so. It also seems like using functors would be a natural way to help preserve clarity � if an algorithm requires that every vertex have an index or a name or a color et cetera, mightn�t it be natural to pass in a functor that can extract, generate, or synthesize the required property? Such functors may also be good candidates for being defaulted, which could significantly help to simplify client code. Isn�t that, after all, the model that our beloved standard library follows with its generics? Thanks, again, for entertaining my questions. I am highly pleased to be soliciting rationale and intent instead of the rabid defensiveness or dismissal that I probably deserve. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Re: [BGL] forced client complexity
by Johnny Yune 03 Apr '04

03 Apr '04

"Vesa Karvonen" <vesa_karvonen(a)hotmail.com> wrote: {snipped throughout} > The design employed by BGL makes it > possible to provide faster lookups > than what is possible with hash > tables. The cost is, as you have noticed, > tougher requirements for the client. That is the conclusion that I am drawing, also. > >If, instead, it is a synthesized construct > >for communication between a > >graph and the algorithm operating > >over it, why should the client be > >responsible for its maintenance > >instead of the framework? What are the > >advantages of this approach? > > The advantage is that the client > can choose how nodes are mapped to > indices. The client can, in particular, > provide a significantly faster > mapping method. For example, the color > of a node could be stored in the > node itself, which would mean that > accessing the color property would be a > very fast O(1) operation. It could easily > be an order of magnitude faster > than a hash table lookup. We�re using the word �color� in an ill-defined context here, but I am assuming that we�re talking about an attribute used to tag a node in calculating chromatic numbers. That said, why would a coloring algorithm operating over the graph need to utilize the mapping of internal indexes to user-defined nodes? Again, this seems parallel to a red-black BST requiring that its value_type know about its color. If I had to write set<propertymap<int,color>> instead of set<int>, I�d feel the same distress. Of course, for things that are natural attributes of a node, like data from which a weight attribute can be generated, there would be no escaping the lookup cost. > It should also be possible for a > graph algorithm to internally convert a > graph to an isomorphic copy that > allows essentially optimal accesses (it > should be doable in O(V+E) time and > space in most cases). However, the > time and space required by the conversion > would probably make such a > conversion useless except for graph > algorithms whose complexity is > significantly higher than O(V+E). That sounds reasonable. I don�t see how it is applicable, though. How does maintaining a mapping between internal and external structures for a public interface hinder internal manipulation? > The disadvantage of requiring only > hashing and equality comparison from > the client is that sometimes there > are significantly more efficient ways > to associate information with nodes > and the opportunity to take advantage > of those more efficient ways is lost. Uncompromising performance at the expense of clarity or usability is a common feature of C/C++ code. It may be ample justification for the complexity of BGL use � especially since measures of clarity and usability are probably more subjective than measures of performance. > >This is the type of design issue that I intended to question with my > >initial post. > > Does this answer your question? I think that it may. Thank you for helping me to reveal some differences between possible approaches. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

RE: [boost] Re: Policy or Trait?
by Rozental, Gennadiy 03 Apr '04

03 Apr '04

> I thought I'd try an example to see what happens. > whether this is best example I dont know....whatever > Many more variants of course possible. > operator()() could be moved into multiply_traits etc > which would give user yet more control. > Perhaps that is the difference. Move all the implementation > out of the class gives the user more flexibility. But is it > the flexibility that se wants. (Sorry boost pros uses she > above, but men users, women developers, viceversa...just a > personal thing) > > First observation from below ....Obviously the application > has a great deal to do with it.! :-) Many more experiments to > do ... but ... Interesting debate. > > regards > Andy Little > > ----------- > > #include <iostream> > template< typename A , typename B > > struct multiply_traits; > > // use traits > template< typename A , typename B > > struct multiply1{ > > typedef multiply_traits<A,B> traits; > typename traits::result_type operator () > (typename traits::first_argument_type a, > typename traits::second_argument_type b) > { > return a * b; > } > > }; > //use policy > template< typename A , typename B, typename Policy> > struct multiply2{ > > typename Policy::result_type operator () > (typename Policy::first_argument_type a, > typename Policy::second_argument_type b) > { > return a * b; > } > > // or Policy ()(a,b); etc if ---> policy > > }; And give me single example where second design is preferable to first? Actually I think the best design would look like this: namespace { struct multiply_t { template< typename A , typename B > struct sig : multiply_traits<A,B> {}; template< typename A , typename B > typename sig<A,B>::result_type operator ()( typename sig<A,B>::first_argument_type a, typename sig<A,B>::second_argument_type b ) { return a * b; } } multiply; } int main() { std::cout << multiply( 10, 1.5 ) <<'\n'; MyInt i( 10 ) std::cout << multiply( i, 10 ) <<'\n'; } Gennadiy.

3 2

RE: [boost] Re: Policy or Trait?
by Rozental, Gennadiy 03 Apr '04

03 Apr '04

> > both for that type. A trait class is never passed as a template > > parameter; it's name is ubiquitous. > > Whoops, can't agree there. The boost type traits are passed > as template parameters all the time: > > mpl::apply_if< > is_pointer<X>, remove_pointer<X>, add_reference<X> > > What he meant, I think, is "never passed as a template parameter together with primary type" > > A traits class never has state. > > > > Policy - A class template passed to other templates for the > purpose of > > providing a named grouping of metainformation, > > I think a Policy might be a non-templated class. True. > I think your definitions are mostly on target, but I think > where you go wrong is that traits/policies has less to do > with how a template is defined than how it's used. Could you please rephrase. It's a bit unclear. Gennadiy.

6 17

Re: Re: [BGL] forced client complexity
by Johnny Yune 03 Apr '04

03 Apr '04

"Cromwell Enage" <sponage(a)yahoo.com> wrote: (much snipping throughout) > > Boost.Graph seems to expose and require an > > unnecessarily large amount of complexity, > > though. > > If by "exposure" you mean lots of source code, I'll > take that complexity any day of the week and twice on > Sundays. :) Yes, I should�ve mentioned in my original post that I am unaware of another c++ graph library as powerful and flexible as BGL. It seems peerless at present. I was worried that my queries would be abrasive and am pleased to get such well-written responses. > The library does have a rather steep learning curve, > especially if you're somewhat unfamiliar with graph > theory and/or template programming. Perhaps my unrest is an extension of my naivety. We seem to be in agreement about BGL�s complexity, though. I guess the question is whether or not that complexity is absolutely necessary. > > The amount of scaffolding required > > to use BGL for even the simplest of projects > > often dwarfs the code size of a naive, > > yet functional, special-purpose implementation. > > Special-purpose implementation of a graph library? Or > the project? Special-purpose implementation of the graph related functions that would otherwise have been provided by a graph library. > Furthermore, while most STL > algorithms confine themselves to handling just those > STL container elements, most graph algorithms also > need the properties of vertices and/or edges as input. Unquestionably. > BGL delegates some of the responsibility of property > storage to the Boost Property Map Library. My confusion is as to why managing those properties are left to the client instead of the underlying container. In the case of properties that are intrinsic to the (user-defined) object being stored in the graph, I feel like they should be accessed as attributes of the object and �connected� to algorithms by generally trivial functors. What advantage is had by forcing the client to manage a property map of properties to vertices when they could instead provide a functor to reveal the same information? What about the cases where the needed properties are only relevant to the underlying graph structure and the algorithm, like indices? Wouldn�t it be more elegant to have graph container manage those properties than the client? > Having dwelt in the academic circle known as the > University of Central Florida, and thus familiar with > the theoretical uses of a graph library (plus I've > studied some game development apps on the side), I'd > like to learn more about how the Real World would want > to use BGL. I can�t speak for the �Real World� at large, but I can give you an example of the kinds of problems I would typically use a graph library for. When evaluating new programming languages (and often just for fun), I download problem sets from old top-coder and ACM programming contests. In almost every set of problems, there is at least one challenge which would benefit from a standard library graph extension. Usually, they center on things like building conversion equations from a series of ratios, walking a family tree, choosing a good path, scheduling planes, etc � the kind of stuff in an undergrad discreet math class. These problems will almost solve themselves in certain programming languages, but in C++, they require a bit more work (as you know). Doing a few of these problem sets always drives home, to me, the fact that C++ really needs standard facilities for graphs and regular expressions. > > Even knowing that ease-of-use is not a criterion > > for acceptance into boost, looking at what is > > required of the client to use the BGL always leaves > > me feeling perplexed. Is there any particular reason > > that a simplified interface is not made available? > > Again, I don't know a simple graph problem that > requires a simplified graph interface. Simplicity is rarely a requirement as such. Perhaps it is just ignorance on my part, but riddle me this: I can describe a graph in visgraph�s format in a very small number of simple statements, render it, hand it to a person and ask them to answer questions like �is there any path from A to Z?� What fundamental functionality would this kind of simplicity preclude if applied to BGL? > > Perhaps a container adapter could be packaged with > > the library allowing a compromise of functionality > > and flexibility for simplicity? > > I thought the boost::vector_as_graph class template > served that purpose. Wrap it around a > std::vector<EdgeList>, with EdgeList = > std::list<unsigned int> (or an edge list container of > your choice, so long as the value type is usable as an > index in the vector), and you should be good to go. This may be an option, although it doesn�t really seem to offer the generational leap in simplicity that I would like. Maybe I am simply needing one more layer of abstraction? Perhaps, I need something that removes the seemingly awkward distinction between the �thing you want to store in the graph� and �the attributes of the thing you want to store in the graph but are not a part of the thing and are instead part of this other thing.� Confusing, isn�t it? > > If a graphing problem is trivial, shouldn't BGL > > provide a trivial solution? Why are the simplest > > useful examples several hundred lines of code? > > The examples don't seem that big and hard to > understand. Of course, quite a few of them have > #ifdefs that I could do without since I don't use the > compilers in question, but I can live with them. For reference, this is from the Kevin Bacon example: typedef property_map < typedef adjacency_list < vecS, vecS, undirectedS, property < vertex_name_t, std::string >, property < edge_name_t, std::string > >, vertex_name_t >::type actor_name_map_t; I, personally, would find it much more natural to define an actor type with appropriate members than to manage such declerations. While my views are probably shaped by my limited understanding of the stylistic model, that is one UGLY typedef. It doesn�t really come trippingly off the tongue, does it? The amount of scaffolding required for BGL use is generally large and complex enough that I would find myself writing wrappers for the BGL so that I could use it without constant need for a reference manual. That would generally be a bad situation for me (more work), for other developers (unfamiliar framework dependency), and for end-users (greater risk of bugs via unproven code). > > I apologize for all of my vague criticisms - my > > intention is not to flame but rather to test the > > waters. > > Your criticisms seem healthy, and I hope my responses > are helpful. Thanks ever so much. I guess that all I have to worry about now is making a fool of myself. > > It is difficult for me to assess whether the > > simplicity I yearn for isn't present for stylistic > > reasons or whether it would rather necessitate a > > sacrifice of flexibility, functionality or > > implementation clarity. Nor is it clear to me to > > what extent these criteria can be compromised to > > promote clarity of client code. For what it is > > worth, the kind of ease-of-use I'm imagining might > > look like: > > #include <less_than_10_graph_headers> > ... > digraph<some_node_type,some_edge_context_type> g; > g << "vertex" << make_pair("vertex", > "implicit_vertex"); > g.add_edge("brother", "sister", "sibling"); > if(g.find(make_pair("brother", "sister"))) > related = true; > > > Could someone please elucidate on why it is > > impossible/impractical/unnecessary/whatever for a > > graph library to have such an interface? > > I believe the potential for ambiguity would hinder > this syntax the most. In this case, you'd have to > overload operator<< to input both edges and vertices, You are absolutely correct. I should�ve been more careful in presentation. Using operator<< in this case was probably a poor choice, anyway. Using add_* would�ve conveyed more information. > and what if some_node_type turned out to be std::pair? > You couldn't pass in make_pair(vertex,vertex) as an > edge then. I believe that would be ambiguous only if a vertex was somehow illegally defined to be a pair of vertices. Regardless, g.add_edge(x,x,x) is just as simple to type. > The same goes for g.find(); is it supposed > to find a vertex, an edge, or both? find would�ve been much more descriptive written as std::find(g.dfs_begin(�brother�), g.dfs_end(), �sister�) or some such. These are just ideas, of course, not proven interfaces. And my illustration wasn�t really intended so much as an example of syntax as an example of what I considered to be a �friendly� api. > Also, it seems you want to be able to use non-built-in > or custom types as vertex IDs. Actually, I would prefer to use non-built-in types as the vertex. If additional meta-data is needed for internal maintenance, then I don�t generally want to be bothered/privileged with it as a client. > You'll have to build > your own custom-type-to-vertex map and bind it to the > graph; It seems like that would be better left to the framework. > BGL won't do it for you, to retain its > genericity. It seems like adding another layer of abstraction should decrease coupling instead of adding it. I don�t really see how specifying that I want a graph of file dependencies, for example, is any less generic than saying that I want a graph of property maps where the id is a filename. Regards, prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

RE: [boost] problem with global mutex object on windows
by Darryl Green 02 Apr '04

02 Apr '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld > Sent: Friday, 2 April 2004 4:59 AM > To: boost(a)lists.boost.org > Subject: [boost] problem with global mutex object on windows > > > hi there, > > we'v run into a problem with the boost_thread mutex class, > when used as a global object. > > Imagine a singleton class as > > class Singleton > { > public: > static Singleton *GetInstance(); > static void Destroy(); > private: > > struct Guard > { > ~Guard() { Singleton::Destroy();} > }; > static Singleton *instance; > static Guard guard; > static boost::mutex mutex; > }; > > where the internal access to 'instance' is serialized by means of the > mutex (inside methods GetInstance() and Destroy()). > > It is the Singleton::Guard destructor that is responsible to free > the instance (if it isn't destructed already). It, too, uses the > mutex to protect access. > > In a specific context on windows xp it happened that the mutex > variable was destructed before the guard, leading to a global 3.6.2 Objects with static storage duration .. shall be initialized in the order in which their definition appears in the translation unit. 3.6.3 ... These objects are destroyed in the reverse order of the completion of their constructor or of the completion of their dynamic initialization. So as long as the Singleton::Guard definition is before the definition of the mutex it should work. I assume that despite having the definitions in that order it doesn't work? Does that make it a compiler bug or am I missing something? In any case, I'm not convinced that this is sufficient to make your singleton useful. Do you know that GetInstance isn't called by the constructor of a static object? Do you know that no other threads (which might call GetInstance) are started prior to the mutex being constructed? I haven't tried to get a truly thread-safe singleton working - I remember several discussions about it here - but I'm not sure that any of them resulted in an efficient working solution? Sorry - perhaps not an altogether helpful response. Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

2 1

Nightly CVS not using current BoostBook L&F
by Reece Dunn 02 Apr '04

02 Apr '04

A while back, Doug Gregor mentioned that the metacomm Nightly CVS did not use the new BoostBook L&F. This has since been updated, and the problem has persisted -- the Nightly CVS does not reflect the latest XSL:T. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

4 8

Virtual member functions cause exception in get_derived_class_object
by David Rostowsky 02 Apr '04

02 Apr '04

I have a couple of really simple classes: class MyBase { public: int x; virtual int foo(int new_x) { }; // our derived classes may or may not override this function. Coders choice. }; class MyDerived: public MyBase { public: int y; MyDerived() { y = 0; }; int Get(void) { return y; }; void Set(int val) { y = val; }; }; My main goal in life is to create an instance of MyDerived class in C++: MyDerived my_derived = new MyDerived(); and then pass the pointer to a Python script where the Python script can call any of the public member functions. Yes, I am careful to keep the pointer around in the C++ code while the Python script uses it. So I expose the class (this may or may not be the source of my problems, need help): BOOST_PYTHON_MODULE(test) { using namespace boost::python; class_<MyDerived>("MyDerived") .def("Get", &MyDerived::Get) .def("Set", &MyDerived::Set) ; } /* test*/ My impasse is that the virtual function seems to really give Boost hell when Im trying to pass the pointer to the class over to the python script. Heres the code snippet for that. Its the conversion thats just KILLING me. If I comment out the virtual function, everything works perfectly! I can pass the pointer over to my script, it calls the public member functions, and Im happy. HOWEVER, if I put the virtual function back in, the following line of code just EXPLODES! // It crashes and burns in make_ptr_instance.cpp, function get_derived_class_object() boost::python::object my_arg(boost::ref(my_derived)); // pass the pointer over to the script now. int rval = callPython("myTestFunc", "Test String argument from c++", my_arg); Im completely frustrated by this. I need some psychological help! Thanks in advance! Dave

4 9

RE: [boost] Re: Policy or Trait?
by Hurd, Matthew 02 Apr '04

02 Apr '04

From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > > Rob Stewart <stewart(a)sig.com> writes: > > I think your definitions are mostly on target, but I think where you > go wrong is that traits/policies has less to do with how a template > is defined than how it's used. Can a method call be part of a trait class? I don't think traits should have anything to do with enacting behaviour (they may describe it). If it is not clear and I see a method I think of it as policy-like. A collection of types and static constants and I think of it as trait-like. I think it gets confusing with the overloading of the English word policy. A policy on how to do something could be passed by value as a polymorphic object or as a simple Boolean flag for that matter... which is not the common intended meaning that MCD brought into common focus. I'll try to add something... Traits are used to get information at compile time. Policies are used to modify behaviour. Traits could be used by a client to modify behaviour which makes them feel like a policy class, but they aren't in what we normally think of as a policy. If a trait is used to direct the modification of behaviour, is it a policy from the client classes point of view I guess... which points to the terminology confusion. Policies can be chained, multiply inherited from or just be ordinary template classes with static methods, maybe such different styles should have different names... a chain aspect, a base aspect (MCD-like), a static aspect... You could then say aspects and traits could be used as policies perhaps... A policy is then something that maybe used to modify behaviour. A trait carries information for use such as for behaviour modification. An aspect extends the definition of trait to also encapsulate behaviour. An aspect and a trait may be used as a policy. Does that work? It would be nice if something new like "aspect class" or some such could be defined and used commonly to avoid the mess, but I suspect it is too late. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ 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.

7 18