- Boost - lists.boost.org

[announce][flyweight] Boost.Flyweight added to the trunk
by JOAQUIN M. LOPEZ MUÑOZ 02 Dec '08

02 Dec '08

Hello, I'm happy to announce that Boost.Flyweight has been just commited to the SVN trunk, far too many months later than initially planned (but better later than never). The goal is to have the lib included in Boost 1.38, if its stability and the release manager permit. If you're interested in the Boost.Flyweight please update your SVN copy, play with the lib and report your comments/complaints. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir.Batov＠wrsa.com.au 02 Dec '08

02 Dec '08

Andy, >> ... > > The first thing that comes to mind is size. A uuid class that holds the > data at text ... > As a much more minor note, ... I thought you might jump on my mikki-mouse string-based UUID... and in fact it was a trap of a sort. :-) I had a strong impression that the discussion in this thread revolved too much about actual implementation (MAC retrieval springs to mind) and too little about the interface. Yes, the implementation is important but it is the interface that makes it or breaks it as far as user's acceptance is concerned. That (acceptance) buys you time to improve the implementation hidden behind the interface. My concern with the proposal is that IMHO the interface has not been given enough consideration from the user perspectives. > I agree that many users do not care about the algorithm used. If they > really don't care, is it an issue to use the > boost::uuids::uuid_generator > since they don't really care what it does anyway? I feel that "do not care" is an oversimplification. The user does care -- he wants the "best available" without getting bogged down investigating what that "best available" exactly is. That is what Linux uuid_generate() gives the user right out of the box. To be successful boost::uuid just has to match that offer. > I believe they would > just use this function and assume all is well. I have to disagree. As a user I do not want to *assume*. I want to *know* that my application uses the available infrastructure to the fullest. That way if/when something goes wrong, it'll the OS to blame and not my application. > Those who care will look > at what boost::uuids::uuid_generator does and decide for themselves. Unfortunately, the reality begs for correction. I do care. However, with dead-lines approaching and the boss breathing down my neck I simply have no resources to look at every damn thing to decide for myself. In fact, I do not want to as I expect much-smarter-than-me people to have taken care of that for me. Exactly as I do not try reinventing std::map (even though I am aware of other than red-black-tree algorithms available). > They will likely be happy as long as there are the options that they > want. Giving options is merely part of the deal -- people often hate choice/options as they have to stop/think/evaluate/decide -- that process in time-consuming and draining, it distracts people from their main task. The only option pretty much guaranteed to succeed IMHO is the "best available" option. > I do want boost::uuid to provide algorithms to create uuids. I don't > want platforms that don't provide an algorithm to not be able to easily > create a uuid. Thus I don't want boost::uuid to be just a wrapper > around > OS functionality. I do not think I said I wanted to see boost::uuid to be just a wrapper. In a nut-shell I'd like to see boost::uuid providing the user with the "best available" option. If that means Linux uuid_generate() or your own algorithm under the hood, then it's fine by me. > > Does boost::uuid provide superior support and a upgrade path? >> ... > > I would agree, that boost::uuid will never have the support of > industrial/commercial scale. I now think that boost::uuid should > provide > a windows_uuid_generator (that uses UuidCreate), a linux_uuid_generator > (that uses uuid_generate), plus possibility others platform specific > ones, > plus some of it's own. Then a boost::uuids::uuid_generator could use > one of these if available and if not, use it's own generator. This > would > give users the support and upgrade paths that you are talking about. Makes a lot of sense to me. Saying to the user -- Dear user, I've done the hard yards for you and I've come up with the best option available on your platform -- is a lot. I believe the overwhelming majority will be very happy. The curious ones (or with too much time :-) on their hands) will still be able to play with explicit uuid generators via "uuid id(some-generator);" > ... > I do believe that a null uuid is a valid uuid, but regardless, if the > common use case really is as you say, then sure lets have the default > constructor call a function to generate a unique uuid. And still > provide a way to create a null uuid. Please do not take my word for it. Just look around at your own usage pattern of the default constructor beyond the UUID domain. > My work also heavily relies on uuids, but we almost never create one > ourselves in code. We get almost all our uuids from the database > that our program uses. Understood. Our usage is pretty much the same. Still, if my component does not create UUIDs, then IMHO it has to state that with Foo() : uuid_(boost::uuid::null()) // initially invalid {} That way the other poor soul coming after me won't be getting any wrong ideas/interpretations what the code is actually doing. > I would be surprised if there aren't many > others that use uuids in the same way, they receive them, they don't > generate them. Understood. I do not believe you should be providing the default constructor for that usage pattern -- it feels like the copy constructor is in order here. All in all my impression of the *current* situation with the proposal is that at *present* we have many useful and promising bits and pieces lying around. I see good ideas. I see good suggestions. I fail to see the product. It surely is a good start but to me we have not reached the destination yet. I'd be more comfortable after I see those bits and pieces taking shape. For me that shape primarily would be the interface and the documentation -- the initial pieces of the contract between the user and the implementor. Once both parties are happy with the contract, you'll beaver away providing the content/implementation. Thanks, Vladimir.

2 1

Re: [boost] Boost CMake status?
by raindog＠macrohmasheen.com 02 Dec '08

02 Dec '08

There is a separate mailing list for the cmake effort that should answer your question. ------Original Message------ From: JOAQUIN M. LOPEZ MUÑOZ Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Dec 2, 2008 11:50 AM Subject: [boost] Boost CMake status? Hi, I've discovered that the libs at the trunk are populated by files by the name CMakeLists.txt and module.cmake and I assume these belong to the once annonced effort to create a build infrastructure for Boost with CMake. I'd have several questions in this regard: 1. Is this effort active and supported? 2. If so, is it the responsibility of authors to update the existing CMake-related files and/or create them when commiting a new lib? 3. If so, are there any guidelines to do this? Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

Boost CMake status?
by JOAQUIN M. LOPEZ MUÑOZ 02 Dec '08

02 Dec '08

Hi, I've discovered that the libs at the trunk are populated by files by the name CMakeLists.txt and module.cmake and I assume these belong to the once annonced effort to create a build infrastructure for Boost with CMake. I'd have several questions in this regard: 1. Is this effort active and supported? 2. If so, is it the responsibility of authors to update the existing CMake-related files and/or create them when commiting a new lib? 3. If so, are there any guidelines to do this? Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[interprocess] map of vectors
by Jan Stetka 02 Dec '08

02 Dec '08

Hi, Is something like this likely to work? typedef interprocess::vector<int, ShmemAllocator> MyVector typedef std::pair<const long, MyVector> ValueType; typedef allocator<ValueType, managed_shared_memory::segment_manager> ShmemAllocator; typedef interprocess::map<long, MyVector, std::less<long>, ShmemAllocator> MyMap;

3 6

boost 1.37.0 and intel-linux-10.0
by frederic.bron＠alcan.com 02 Dec '08

02 Dec '08

I built boost 1.37.0 with intel-linux-10.0. I obtained the following output : "icpc" -c -xc++ -O3 -Ob2 -w1 -mp -march=pentium4 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/has_long_double_support.test/intel-linux/release/address-model-64/link-static/threading-multi/has_long_double_support> icpc: command line remark #10010: option '-Ob' is deprecated and will be removed in a future release. See '-help deprecated' I have also seen this: libs/math/build/has_long_double_support.cpp(9): catastrophic error: #error directive: "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built." #error "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built." ^ compilation aborted for libs/math/build/has_long_double_support.cpp (code 4) ...failed intel-linux.compile.c++ bin.v2/libs/math/build/has_long_double_support.test/intel-linux/release/address-model-64/link-static/threading-multi/has_long_double_support.o... Any risks using boost 1.37.0 with intel 10.0? Regards, F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

2 1

[graph] Bundled properties, listS, listS, write_graphml
by remi.chateauneu＠gmx.de 02 Dec '08

02 Dec '08

Hi, I try to use boost::graph with two bundled properties, listS for vertices and edges, and serialize with write_graphml, and it does not compile: Boost 1.35 and 1.36, Windows Visual C++ 8.0 Here are the most important details of the code: class Host { int idx ; }; class SocketPair { int xxx ; }; typedef boost::adjacency_list< boost::listS, /// Needs stability of iterators. boost::listS, /// Needs stability of iterators. boost::directedS, Host, SocketPair > Graph; Graph gblGrf ; boost::dynamic_properties tmpDP ; boost::write_graphml( std::ofstream("xxx.xml"), boost::vertex_index_map( boost::get( &Host::idx,_gblGrf ) ), gblGrf, tmpDP ); Here is the beginning of the compile errors. Any idea, please ?? Thanks in advance 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2039: 'vertex_descriptor' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graphml.hpp(225) : see reference to class template instantiation 'boost::graph_traits<G>' being compiled 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> i:\remi\graph\graph\graph.cpp(435) : see reference to function template instantiation 'void boost::write_graphml<boost::bgl_named_params<T,Tag,Base>,Netstat::Graph> (std::ostream &,const Graph &,VertexIndexMap,const boost::dynamic_properties &,bool)' being compiled 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property, 1> Graph=boost::bgl_named_params<boost::bundle_property_map<boost::adjacenc y_list<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property>, 1> VertexIndexMap=Netstat::Graph 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2146: syntax error : missing ';' before identifier 'vertex_descriptor' 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2602: 'boost::graph_traits<G>::vertex_descriptor' is not a member of a base class of 'boost::graph_traits<G>' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : see declaration of 'boost::graph_traits<G>::vertex_descriptor' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2868: 'boost::graph_traits<G>::vertex_descriptor' : illegal syntax for using-declaration; expected qualified-name 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2039: 'edge_descriptor' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2146: syntax error : missing ';' before identifier 'edge_descriptor' 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2602: 'boost::graph_traits<G>::edge_descriptor' is not a member of a base class of 'boost::graph_traits<G>' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : see declaration of 'boost::graph_traits<G>::edge_descriptor' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2868: 'boost::graph_traits<G>::edge_descriptor' : illegal syntax for using-declaration; expected qualified-name 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(28) : error C2039: 'adjacency_iterator' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(29) : error C2039: 'out_edge_iterator' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ]

2 1

Reflexion in boost.
by Alejandro J. 02 Dec '08

02 Dec '08

I think push reflexion into the boost library, i need the new branch.this process i try doing in the next mount., sorry for my english. Alejandro jaime. _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…

1 0

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir Batov 02 Dec '08

02 Dec '08

Andy, Thank you for taking the criticism the right way and my apologies if some of my comments sound(ed) somewhat harsh. It is never my intention. I won't be addressing the points below directly as some issues I raised are petty (and I somewhat wish I did not raise them). I admit I felt uneasy with the proposal but could not pin-point what it was. I'll try again. Background: We are in our project currently using uuid facility heavily and very dependent on it. The version we use (from memory) is something like (it's not necessarily exactly what we use and I'll omit some scaffolding and stick with the basics): struct uuid : public std::string { typedef std::string base; uuid() : base(generate()) {} explicit uuid(string const& s) : base(s) {} static uuid null() { return uuid(std::string()); } private: std::string generate(); }; On Linux the generate() function calls uuid_generate(). No one (in our project anyway) can be bothered choosing between uuid_generate_random() or uuid_generate_time() -- uuid_generate() takes care of the guess work and picks the best available. The same on Windows -- it'll probably be UuidCreate()&UuidToString(). Given that uuid above is merely a wrapper over OS facilities, we get known behavior, we are guaranteed "support" and an automatic "upgrade" if/when the standard changes or a new better algorithm becomes available. For me (a collective nebulous "me") to switch to your boost::uuid it has to provide something to win me over. Let's see what that might be. Does boost::uuid provide superior implementation? Maybe. If it is, that was not spelt out sufficiently visibly for me to pick up in the documentation. Therefore, as it is now the answer regretfully has to be 'no'. Does boost::uuid provide superior interface? That issue might get very subjective and personal. Therefore, I'll re-focus on if boost::uuid is user-friendlier. Maybe but I doubt it as an ordinary user does not want to be bothered choosing between algorithms. If uuid_generate() and UuidCreate() can make that choice for me, it is good enough for the overwhelming majority of uuid applications. Therefore, the answer seems again 'no'. Does boost::uuid provide superior support and a upgrade path? With all due respect I have to say 'no' again as your support (no matter how enthusiastic it is) cannot compete (on industrial/commercial scale) with vendor-backed support. uuid_generate(), UuidCreate() as printf() come with the system. One has to have really serious reasons to use something else instead. Does boost::uuid provide superior documentation? Well, my impression is that it is 'no' again. What boost::uuid does immediately entice an ordinary user with then it is Boost reputation. However, in all honesty it's not boost::uuid property per se but the reputation for quality of the Boost libraries built over those many years. In this thread I hear some people say "it's OK to ship". I disagree. Every new library has Boost reputation to uphold. It takes time to build such a reputation. It does not take long to lose it -- a couple of just "OK to ship" libraries will probably do. I'd probably be more comfortable if boost::uuid took the approach of boost::thread of providing consistent interface across many platforms via re-use of the functionality provided by the OS (when available) rather than duplicating it. Then though I'd expect the interface to be given considerably more thought. As for the interface I'll express my view to one of your comments below. > I would not want the default constructor to generate a uuid. I don't > want users to pay for that if they don't want it. Some use cases will > not require generating uuids, only using them. I have to disagree. I believe that the overwhelming majority of cases falls into the following category -- "I introduce something when/because I need that something". That is, by Foo foo; std::string str1; std::string str2(params); uuid id1; uuid id2(param); I create valid instances. Say, 'str1' is empty but it is still a valid string. I create 'id1' because I need an uuid. You on the other hand use uuid id2(param); // valid instance uuid id1; // invalid instance where #1 creates a valid instance but #2 creates an invalid instance (it lacks its identifying property -- it's NOT unique). Therefore, you use the same (visually and behaviorally) creation mechanism to achieve *different* results. From the user perspective it is inconsistent and likely unexpected. The case you are catering for with uuid() is not mainstream but quite the opposite -- the user introduces something that he does *not* want. Such case should be handled explicitly with the user actually spelling out what he means like Foo::Foo() : uuid_(boost::uuid::null()) // initially invalid {} Best, Vladimir.

4 3

Boost namespace abreviations
by edam 01 Dec '08

01 Dec '08

Hi there, I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. According to Boost's library naming conventions (http://www.boost.org/development/requirements.html#Naming_consistency) this is strongly discouraged, and with good reason -- having clearly (and consistently) named namespaces is a good thing! Having used boost for a (mere) couple of years now, though, I've started to find its namespaces a bit unwieldy. I try to avoid going "using namespace" (for a few reasons, nicely summarised here: http://dev.lsstcorp.org/trac/wiki/DiscussCodeStandards) and I can't bring myself to go down the route of announcing to the compiler that I will be "using ..." specific symbols from whichever namespace either. So I am left with having to explicitly specify the namespace of each symbol, like this: std::cout << std::setw( 2 ) << std::setfill( '0' ) << hours; While this requires more typing, I prefer it to the alternatives. As a boost user though, I find this becomes a bit more of a pain. Boost's namespaces, whilst well named, are a lot to keep typing out! Here's a quick example: boost::posix_time::time_duration foo = boost::posix_time::hours(2); Multiply this by a thousand lines of boost-using code and you've got a lot of typing! I wondered if there would be any interest in a boost abbreviations header that, if included, would provide abbreviated names for boost's namespaces. Something along the lines of a boost/abrv.hpp: // this is an incomplete example namespace bst = boost; namespace boost { namespace gd = gregorian; namespace pt = posix_time; namespace dt = date_time; } This would allow the developer to shorten the above example code to bst::pt::time_duration foo = bst::pt::hours(2); in this case saving a full 18 characters! Multiply this by 1000 lines of code and you may save some finger-ache. What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o) Regards, Tim. -- edam - www.waxworlds.org/edam

5 4