March 2005 - Boost - lists.boost.org

Detecting static member constants on GCC
by David Abrahams 31 Mar '05

31 Mar '05

It seems GCC 3.3.3 doesn't like to do SFINAE based on the validity of T::value: int f(...); template <class T> int f(T, int(*)[T::value] = 0); int x = f(1); // error: `int' is not an aggregate type The same applies when eliminating partial specializations via SFINAE. Has anyone got an alternative approach? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[assign] MinGW list_of() set<string> problem
by Daniel Schlyder 31 Mar '05

31 Mar '05

The following used to compile: std::set<std::string> const virtual_control::s_unbindables_permanent = boost::assign::list_of("Escape")("PrintScreen"); I'm not sure why, as Boost.Assign's docs seem to say I should have had to use the to_adapter function. Anyway, I recently started getting the following error: E:/libs/boost/boost/assign/list_of.hpp: In member function `boost::assign_detail::generic_list<char[7]>::operator set<string>() const' : E:\code\cpp\dasc\wc2\lib\alex\src\virtual_control.cpp:413: instantiated from here E:/libs/boost/boost/assign/list_of.hpp:334: error: call of overloaded `set( const boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> > & )' is ambiguous After changing my code to std::set<std::string> const virtual_control::s_unbindables_permanent = boost::assign::list_of("Escape")("PrintScreen").to_adapter(); I now get the different error E:/libs/boost/boost/assign/list_of.hpp: In member function `set< string > boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> >::convert_to_adapter(const set<string> *) const': E:/libs/boost/boost/assign/list_of.hpp:200: instantiated from `boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> >::adapter_converter::operator set<string>() const' E:\code\cpp\dasc\wc2\lib\alex\src\virtual_control.cpp:413: instantiated from here E:/libs/boost/boost/assign/list_of.hpp:179: error: 'class set<string>' has no member named 'push' To me, this looks like an error in Boost.Assign. Am I doing something wrong? Thanks, -- Daniel Schlyder http://bitblaze.com/

2 9

[range] update on ADL hooks
by Thorsten Ottosen 31 Mar '05

31 Mar '05

Dear all, I'm going to change the ADL lookup hook of range functions. instead of the irritating void foo() { using namespace boost; begin(r); } we simply now say void foo() { boost::begin(r); } and get full ADL lookup. This changes the extension protocol to overiding these three functions: range_adl_begin() range_adl_end() range_adl_size() Any comments before I commit? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

6 56

uBLAS tests moved to test subdirectory (confused regression results)
by Michael Stevens 31 Mar '05

31 Mar '05

A couple of weeks ago I moved the uBLAS tests into 'libs/numeric/ublas/test' for consistency with the rest of Boost. Since then the regression test results are filled with a lot of confussing results. I assume this results from the combing of stale result and the new configuration. I assume (and hope) that the next time testers do a 'clean build' things will clear up. This is a lot of work for many testers and there test machines however. Any ideas how to better make such changes in the future to avoid such confussion? Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Re: Serialization issuses under MS VC++ 7.1 ....
by Klaus Gütter 31 Mar '05

31 Mar '05

Hello Jason, I get the same error message when trying to deserialize this class (MSVC 7.1): class TestVector { private: std::vector<int> v; friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(v); } public: TestVector() { } }; Klaus "Jason Earl" <jason(a)hybd.net> schrieb im Newsbeitrag news:<004001c533fc$48724270$861aa8c0@system2600>... > If you have look at my original code, it does use > BOOST_SERIALIZATION_SPLIT_MEMBER() inside the class (sorry the code doesn't > intend with tabs nicely). > > I also have tried including both... > > #include <boost/serialization/split_member.hpp> > #include <boost/serialization/split_free.hpp> > > but neither work. I assume that the split free is obviously used by > the list > data type as it's not intrusive, and the member one is what I should include > and have been including. > > I'll look running the tests later when I get round to figuring out how > to > run them etc. I'll need to RTFM first though. From the regression thingy, it > said MSVC++7.1 worked OK though. > > I think this could be a little bug in the library (I won't speak too > loudly > here as I'm still a C++ beginner, and therefore there's a good chance I'm > still doing something very dumb), maybe someone else could confirm they get > the same problem as me when trying to serialize an class member varaible > that is a list of objects using load / save methods that are class members > under VS.NET 2003, like in my example.... > > anotherwords I have class A with separate load/save members, and then > I have > class B which has a member inside it that is of type std::list<A*>. > > Sorry in advance if I break the threaded reply structure on this list. > I > didn't have the list mail me replies. I'm new to all this mailing list > stuff. > > Jason > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[Boost-bugs] [ boost-Bugs-1173937 ] Bad XML format outpout
by SourceForge.net 31 Mar '05

31 Mar '05

Bugs item #1173937, was opened at 2005-03-31 01:21 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=1173937&group_… Category: test Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Beman Dawes (beman_dawes) Summary: Bad XML format outpout Initial Comment: IN FILE : boost_1_32_0\libs\test\src\supplied_log_formatters.cpp IN FUNCTION : xml_log_formatter::track_test_case_scope Missing accodance in test void xml_log_formatter::track_test_case_scope( std::ostream& output, test_case const& tc, bool in_out ) { if( !in_out ) m_indent -= 2; print_indent( output ); output << (in_out ? "<" : "</") << ( tc.p_type ? "TestCase" : "TestSuite" ); // HERE MISSING ORIGINAL CODE : MISSING { !! //if( in_out ) // output << " name"; print_attr_value( output, tc.p_name ); // Patch if( in_out ) { output << " name"; print_attr_value( output, tc.p_name ); } output << ">"; if( in_out ) m_indent += 2; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1173937&group_… ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] [format] conversion to string
by Martin Bonner 31 Mar '05

31 Mar '05

> While it's generally considered a bad practice to provide implicit > conversions, I think it would be good to provide such a conversion > for the boost::format class. [snip] Having been bit far too many times by bad implicit conversions, I would vote against such a change. I don't see why one shouldn't pass in a format object to a function (possibly for the function to add one argument to the format object). I still think that providing a member function with(), rather than an operator % would have been better. Then one could write: string s = format("%1%").with(10).str(); which seems does seem neater than: string s = (format("%1%") % 10).str(); If we are to change boost::format, I would prefer to add such a member function than an implicit conversion. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 4

[date_time] MinGW no reentrant std functions patch
by Daniel Schlyder 31 Mar '05

31 Mar '05

MinGW doesn't seem to support reentrant std functions, so I think the attached patch should be applied. Best regards, -- Daniel Schlyder http://bitblaze.com/

2 4

Lock free shared_ptr on gcc, help needed
by Peter Dimov 31 Mar '05

31 Mar '05

So, shared_ptr is now lock-free on Windows, but not on the other platforms. We need a portable atomic primitive for that. The only alternative are the internal libstdc++ helpers __atomic_add and __exchange_and_add. But in order to use them correctly, we need to know what their exact semantics are with respect to memory synchronization. To the best of my knowledge, this is not documented anywhere. What do we do now? -- Peter Dimov http://www.pdimov.com

7 8

memory leak in iostreams library-zlib
by George M. Garner Jr. 31 Mar '05

31 Mar '05

Johnathan, I'm getting a memory leak when using the gzip_decompressor due to a failure to call inflateEnd/deflateEnd during object destruction. I have inserted the following line into zlib.cpp tp correct the problem: void zlib_base::reset(bool compress) { z_stream* s = static_cast<z_stream*>(stream_); zlib_error::check(compress ? deflateReset(s) : inflateReset(s)); zlib_error::check(compress ? deflateEnd(s) : inflateEnd(s)); // gmg cleanup stream->state and embedded pointers } There may be a better place for this, for example in the zlib destructor, since it may be desirable on occasion to reset a stream without destroying the state (??). Or perhaps there should be a new function to encapsulate the call to deflateEnd/inflateEnd which is called in the destructor. Regards, George.

2 1

typeof and Visual C++
by Arkadiy Vertleyb 31 Mar '05

31 Mar '05

HI all, God only knows what else can be found inside this compiler if one is willing to dig real deep. For example, Igor' Chesnokov from RSDN (Russian Software Development Network) has found a way to implement typeof() that does not require registration, and probably has compile-time performance of a native typeof. How? Apparently, some weird "feature" of Visual C++ allowed him to twick a template body at the moment of instantiation, when additional context is available, thus "registering" classes on the fly, at the moment of taking typeof(). Microsoft-specific "bugfeatures" are generally not in the area of my interests. However I do realize that, on the Microsoft compiler, this might look much more attractive then anything Peder and I have implemented. And even though I realize that this might be a serious competition, I would feel really bad not to mention this here: http://rsdn.ru/Forum/?mid=1094305 Thoughts? In particular, how do people feel about implementing someting for some particular compiler using specific "features" of this compiler? Should this be acceptable? Regards, Arkadiy -- Regards, Arkadiy

5 15

boost/threads/condition.hpp documentation patch
by Larry Lansing 30 Mar '05

30 Mar '05

Attached please find a patch for boost/libs/thread/doc/condition-ref.xml which re-adds a warning about spurious wakeups that appeared in older versions of the boost threads documentation. Compare and contrast: http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/libs/thre… vs. http://www.boost.org/doc/html/condition.html The newer boost.org version omits this paragraph: *** Danger: This version should always be used within a loop checking that the state logically associated with the condition has become true. Without the loop, race conditions can ensue due to possible "spurious wake ups". The second version encapsulates this loop idiom internally and is generally the preferred method. *** Unless there was an important reason that this warning was removed, it seems like the spurious wakeup issue should definitely be mentioned in the wait() and timed_wait() interfaces. Unless I've screwed it up, the attached patch should put this paragraph in the right places. Thank you for your time. -- Larry Lansing Index: condition-ref.xml =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/doc/condition-ref.xml,v retrieving revision 1.3 diff -d -u -r1.3 condition-ref.xml --- condition-ref.xml 17 Jul 2004 04:33:59 -0000 1.3 +++ condition-ref.xml 15 Mar 2005 19:18:42 -0000 @@ -97,6 +97,13 @@ lock.</simpara></effects> <throws><simpara><classname>lock_error</classname> if <code>!lock.locked()</code></simpara></throws> + <notes><simpara>This version should always be used within a + loop checking that the state logically associated with the + <classname>condition</classname> has become true. Without + the loop, race conditions can ensue due to possible + "spurious wake ups". The second version encapsulates this + loop idiom internally and is generally the preferred + method.</simpara></notes> </method> <method name="wait"> @@ -153,6 +160,13 @@ otherwise <code>true</code>.</simpara></returns> <throws><simpara><classname>lock_error</classname> if <code>!lock.locked()</code></simpara></throws> + <notes><simpara>This version should always be used within a + loop checking that the state logically associated with the + <classname>condition</classname> has become true. Without + the loop, race conditions can ensue due to possible + "spurious wake ups". The second version encapsulates this + loop idiom internally and is generally the preferred + method.</simpara></notes> </method> <method name="timed_wait">

2 2

IMPORTANT: yahoogroups admin rights problem
by Toon Knapen 30 Mar '05

30 Mar '05

Hello ALL, As many of you might know, currently we are unable to add new members to the ublas-ml. The problem is that only Joerg has the rights to add members to the list but Joerg does not respond anymore. Could some of you try to contact Joerg or give me his telephone number that I talk to him about this. If we do not have a solution by end of November I will create a new project on yahoogroups (and we all have to switch). Additionally we need to contact Joerg and Mathias (again!) about applying the Boost Software License. I currently have the impression that they are not willing to change ublas to the BSL. In that case IMO, we will have to rewrite uBLAS to not get thrown out of boost. Again his phone-number would be handy if you have it available. Please contact the ml or me asap about the above issues or we will need to take drastic actions. toon

4 4

MPL Question on crossing the compile \ runtime barrier with bind | adding to boost profiler abstracted file access
by Brian Braatz 30 Mar '05

30 Mar '05

I have been reading (ahem and re-reading) "C++ Template Metaprogramming" I have a problem I am trying to solve and was up late last night looking for the answer to jump out at me. If nothing else this helps me as I tend to re-read the same chapters over and over. Here is what I am trying to do In working on coded I am adding to the proposed Boost Profiler (started by Chris Diggings, inherited by yours truly). I am using RAII all "over" my program in the extensions I am adding to the profiler. This puts me in a spot where I have MACROs which stuff the profile points in the program. Now the problem is I would like to be able to add a template param to the TYPE of the profile points which gives it the initialization code for the STREAM it is using. The problem is since the objects themselves get created ALL OVER the program, I don't have a single point of construction (because I am using RAII to track the life cycles inside the functions themselves). I.e. I want to be able to use Boost.IOstreams or ofstream or whatever for these objects.I just need to , at the TYPE DEFINITION be able to define how to initialize this passed stream. I need to be able to do something like this Template <typename STREAMTYPE, typename INITFUNCTOR> Class MyClass { Public: STREAMTYPE outstream; MyClass() { INITFUNCTOR f(outstream); // open the file, init iostreams , or whatever } }; I can always pass in a functor, but what I really want for Christmas is to be able to Tyepdef MyClass<std::ofstream, bind(&std::ofstream::open,_1,"MyFile.txt") > MyNewClass; This doesn't work because bind returns an actual OBJECT instead of a type. (intuitively - it would be cool if I could say bind(...)::Type which would give me the TYPE of the generated functor) SO that led me to be up until 3 am reading about mpl::lambda. I am still trying to determine if THAT can be used in place, but the dots are not connecting for me yet. Any suggestions or directions pointed GREATLY appreciated. Is there a way to make this work with MPL::Lambda? Thanks Brian

2 1

[thread] condition::wait docs clarification
by Vladimir Prus 30 Mar '05

30 Mar '05

Hello, the docs for condition::wait say: blocks the current thread of execution until readied by a call to <code>this->notify_one()</code> or<code> this->notify_all()</code>, and then reacquires the lock. Shouldn't the docs also mention 'spurious wakeups', that is returns from wait without any notify_one or notify_all coll? I won't pretend to know why those wakeups can happen and on what systems, but at least is relevant to pthreads conditions. I'm asking because a colleague just read this, and though that a parent thread can launch child thread and wait for it to become ready with just condition.wait(); on parents side and condition.notify_one(); on child's side, while in fact return from condition.wait() only means that the predicate waited on must be reevaluated. - Volodya

3 2

Open watcom
by Charles Schwartz 30 Mar '05

30 Mar '05

Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation? Are there plans to test against this compiler in the future?

8 12

RE: [boost] Re: Lock free shared_ptr on gcc, help needed
by Brian Braatz 30 Mar '05

30 Mar '05

I talked to Andrei about this. It IS possible to do this as a std::allocator<> replacement, but I have been led to believe it is not a simple matter. The lock free algo (I have been studying this) is one that seems to be more tailored to specific implementation and less to a general library concept. The problem with the std containers is that they are "too power" and provide many conceptual ways to access the data. The model of how std containers work is very different from the "purposely" heavily constrained access provided with the lock free mechanism. I was thinking it might be useful to write a simple lock free container with a limited interface. With this pattern, one could do something in alignment with lock free, but I am not sure it would be palatable for people as the first thing folks would say is "Hey, that's not a std::vector<>". > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Wednesday, March 30, 2005 8:08 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Lock free shared_ptr on gcc, help needed > > Robert Zeh wrote: > > Could the primitives used by the lock-free shared_ptr be made > > available from boost threads? It would be helpful for other people > > writing lock-free code. > > Probably not, and even if they are made available, it wouldn't be helpful. > You can't write correct lock-free code with primitives that have > unspecified > memory synchronization properties. Well... maybe you can, but most of us > cannot. ;-) > > (Most of us can't write correct lock-free code at all, but that's a > different story.) > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: size of libboost_thread-gcc-mt.so
by Vladimir Prus 30 Mar '05

30 Mar '05

Alexander Nasonov wrote: > Amerio wrote: >> Hello, >> After compiling libboost_thread-gcc-mt.so on debian/gcc-2.95.4, this so >> weights 195kB, while libpthread weights only 100kB. >> Why such a huge difference ? Isn't boost::thread meant to be as >> lightweight as possible ? > > Try building it with Boost.Build v2 (bjam --v2 gcc release). It's only > 64K because read_write_mutex.o (223K in release) is excluded from link. > I don't know whether it's intentional or an oversight. I'm afraid it's an oversight -- that's a recently added feature. I'm surprised that it adds so much to the size though, let me try here. Without read_write_mutex the size of gcc/release/shared build is 46K. With read_write_mutex the size is 136K. Wow, that's a difference! When I comment out explicit template instantiations in that source file, the library is becomes 76K. The comment says explicit instantination are needed to detect syntax errors in templates but those instantination bloat the library. BTW, I'm not sure read_write_mutex should be a template, either. Maybe, we need class polymorphic_mutex; and template<class Mutex> class concrete_polymorphic_mutex : public polymorphic_mutex { }; and read_write_mutex_impl must be implemented in terms of polymorphic_mutex? - Volodya

3 4

Re: size of libboost_thread-gcc-mt.so
by Vladimir Prus 30 Mar '05

30 Mar '05

Alexander Nasonov wrote: > Amerio wrote: >> Hello, >> After compiling libboost_thread-gcc-mt.so on debian/gcc-2.95.4, this so >> weights 195kB, while libpthread weights only 100kB. >> Why such a huge difference ? Isn't boost::thread meant to be as >> lightweight as possible ? > > Try building it with Boost.Build v2 (bjam --v2 gcc release). It's only > 64K because read_write_mutex.o (223K in release) is excluded from link. > I don't know whether it's intentional or an oversight. I'm afraid it's an oversight -- that's a recently added feature. I'm surprised that it adds so much to the size though, let me try here. Without read_write_mutex the size of gcc/release/shared build is 46K. With read_write_mutex the size is 136K. Wow, that's a difference! When I comment out explicit template instantiations in that source file, the library is becomes 76K. The comment says explicit instantination are needed to detect syntax errors in templates but those instantination bloat the library. BTW, I'm not sure read_write_mutex should be a template, either. Maybe, we need class polymorphic_mutex; and template<class Mutex> class concrete_polymorphic_mutex : public polymorphic_mutex { }; and read_write_mutex_impl must be implemented in terms of polymorphic_mutex? - Volodya

1 0

[call_traits]split
by Gennadiy Rozental 30 Mar '05

30 Mar '05

Hi, Is there any plans to split call_traits? I really need only reference type trait. Shouldn't it be part of type traits lib? Is there an alternative already in there? Thanks, Gennadiy

4 7

Re: [BGL]edge connectivity code won't compile
by Vladimir Prus 30 Mar '05

30 Mar '05

> Hi, I ran into problems trying to compile the BGL example code, > edge_connectivity.cpp. (There are two codes, this is the short one with > underscore, the other is hyphen edge-connectivity.) I used VC7. I have > been running other codes without any problem. Hi, > Basically, I got two errors: > 1)C1076--I have changed from /Gm to /Zm1000, and it went way. > 2) C2039--it flagged error "reference is not a member of property map" and > points to boost/property_map.hpp in boost-1-29-0. I have no idea how to > fix this one. I think that in order for somebody to look into the problem, you should provide *exact* error messages. The property_map.hpp file is big, and guessing what line upsets VC7 is impossible. In first case, you did not even say where error occurs. BTW, could you also try with CVS version? - Volodya

1 0

RE: [boost] Call for Volunteers: the Synopsis project
by Stefan Seefeld 30 Mar '05

30 Mar '05

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > Sent: September 30, 2004 03:04 > Count me as interested. Are you going to base that parser on > OpenC++, which, > IIRC, was used by Synopsis some time ago? Last time a looked > at OpenC++, it > did not even distinguish between ordinary names and > typenames, which makes me > wonder if it's a good parser. You are right, there remains a lot of work to be done. The C++ parser backend of synopsis which we are talking about here is indeed based on OpenC++, but has already undergone lots of improvements. In its original design the parser didn't contain any form of semantic analysis such as symbol lookup to disambiguate certain expressions. For what it had been used so far it was good enough. I'm now working on the features that allow it to get closer to the standard, i.e. constant expression evaluation, symbol (type) lookup, etc. As I said, any help would be very appreciated ! Regards, Stefan

2 2

boost::tree advice?
by Dan Rosen 30 Mar '05

30 Mar '05

Hi all, Over the past few weeks I've been slowly working on (what I hope to be) a candidate for a boost::tree. I've reviewed the comments on previous submissions by Kasper Peeters (http://www.damtp.cam.ac.uk/user/kp229/tree) and Justin Gottschlich (http://nodeka.com/TreePart1.pdf) and I'm trying to put together a set of concepts to address some of the issues that were discussed here. Of the two "how to design a generic tree container" camps, I'm finding myself mostly in the one where individual nodes are not exposed to users, and the tree is an opaque structure. Also, nodes are not identical to iterators, and the iterator concept is not extended in any significant way from the standard. (Anybody who would like more detail, I'm happy to provide my draft of the concepts, but I don't want to get into that detail here -- it's not particularly relevant to my questions that follow.) I feel like I've been making decent progress so far, mostly working on paper, just documenting the concepts, and doing some coding exercises for proofs of concept. But I don't have anything I'd consider ready for primetime yet -- not even remotely -- and in fact as I progress more solidly into the coding phase, I'm finding myself getting somewhat mired in the details. So I thought I'd solicit opinions from experienced Boosters here on some of the issues I'm trying to work through. I'm primarily finding myself conflicted about what degree of flexibility the concepts and their concrete implementations need to offer. I thought it would be useful to allow clients of tree<> to be able to specify the container type for a node's children. In the code I'm currently playing with, I have a couple "selector" structs, basically identical to Boost Graph Library's vecS, listS, etc, and the tree<> class template takes one of these selectors as a template parameter. That much is all well and good, but I quickly run into trouble once I start dealing with nodes and iterators. First of all, I'd like to provide access to the children of a given node as a sequence of the type specified by the client. So if you have an iterator to an element in the tree (the structure of the tree being otherwise opaque), I want to be able to say something like: tree<foo, list_selector> t; tree<foo, list_selector>::some_kind_of_iterator i; // assume t contains something useful and i points to an element in t std::list<foo> children = t.children(i); At this point, I've got a problem: internal to the tree<>, the lists representing child sequences contain not instances of type "foo" but instances of something like node<foo>. So I can't simply provide access like this unless I can guarantee that my nodes are convertible in all contexts to their stored data. That seems like a rat hole. Another thing I'm stuck on is, even if I don't expose the container structure like this, I still have a problem with iterators. The above example omits the actual iterator type, but to get into some specifics, one type of iterator I'd like to provide is a pre-order traversal iterator. In my current code, this iterator is basically just a wrapper for iterators into the flat sequences I've been instructed to use, and some minimal code that knows how to jump between these sequences appropriately (for example: if a node has children, operator++ yields the first child of that node). It's easy to get an iterator into the sequence containing a node's children (internally, it's just something like node.children.begin()), but it's not so easy to get an iterator into the sequence containing a node's parent, unless a node contains not a pointer to its parent but an iterator instead. And that scheme breaks down for children of the root node, which is not in any sequence, as it has no siblings. I'm sure there are other options for how to implement the node structure and iterator relationships, but none jump out at me. In short, although I'd like my concepts for trees to allow users to specify and access the sequences representing the children of a node, my implementation of this is proving very clumsy. So I'm wondering two things: 1. Is this a good idea in the first place? Are there really any compelling use cases, where you'd want one tree to store its node structure in vectors and another in lists? Or is this a case where a policy-based approach is misplaced effort? 2. If this actually is a good idea (which I'm starting to get the feeling is not the case), my experience so far is that there's some significant overhead -- both in terms of the size of the structures, and in terms of speed (extra pointer traversals when doing anything with iterators). Does anybody have any brilliant ideas about how to minimize this overhead? If these questions are too vague, or lacking in context, I'm more than willing to provide the rough draft I've got of the structural concepts, and the very incomplete code (such as it is). Thanks in advance for your expert advice! dr

6 21

Re:[serialization] Private ctor again
by Vladimir Prus 30 Mar '05

30 Mar '05

Robert Ramey wrote: >> binary_oarchive oa(...); >> Data data(....); >> oa << data; > >>Now, how do I deserialize it? I can't write > >> Data data; >> ia >> data; > >>Since ctor is private. I would guess it's still possible to deserialize >>this class, but I don't know how. > > what's the matter with > > Data data(....); > ia >> data; The wrong is that when I create and serialize data, I have something to pass as ctor parameter. But when deserializing, I don't have that something. Let's be more specific: the ctor parameter includes parse tree. I can't serialize it because it requires *lots* of work. > I don't see how the fact you want to construct different ways is related > serialization. Unless its a pointer, serialization presumes the > instance has already been constructed. How this is done is > outside the influence of the serialization library. What I'm after it telling to serialization lib: "hey, I know this data was not serialized via pointer, but I want to restore it into pointer variable, so that serialization lib creates it itself". Specifically, I look at this code from collection_load_imp.hpp: stack_allocate<type> t;^M load_construct_data(ar, t.address(), 0U);^M ar >> make_nvp("item", t.reference());^M Can the same trick be use from user code? I'm not all all sure it's better than saving Data as pointer in the first place, but I'm exploring possibilities. - Volodya

1 0

Mailing list archive change and list downtime
by Beman Dawes 30 Mar '05

30 Mar '05

DongInn Kim, Jeff Squyres, and the other sysadmins at Indiana University are planning to switch all the Boost mailing list archives they host from MHonArc to Hypermail. They report "Hypermail seems to be much more stable, faster, and more efficient than MHonArc. We've been quite pleased with it, and have deployed it across most other lists on the listserver already (the boost lists were saved until last)." The old archives will still be available, and DongInn and Jeff have made various plans to minimize disruptions. All the listservers will be down during the transition, which is planned to start at 11 PM Saturday night (Eastern US time). Thanks to all the folks at IU for their help with Boost list hosting, --Beman

1 0