March 2008 - Boost - lists.boost.org

[serialization][1.36] ktmap contains extended_type_info with m_key == 0
by Felipe Magno de Almeida 01 Apr '08

01 Apr '08

Hi Robert, I'm hitting a assertion with m_key == 0. With my debugger I can find lots and lots of items with m_key == 0. None are one of my types, there are shared_ptr_1_32 with m_key == 0 and others. Do you have a newer 1.36 version? Am I doing something wrong? I'm using the 1.36 version for use with DLLs (export in a DLL and serialize/deserialize in another). Thanks, -- Felipe Magno de Almeida

3 18

[GSoC 2008] Deadline for student applications extended
by Hartmut Kaiser 01 Apr '08

01 Apr '08

FYI... > Hello everyone, > > This year, we experimented with the program timeline providing one > week for students to discuss project ideas with their mentors and then > a single week to submit applications. We have heard feedback from the > community that it would be beneficial to provide more time for > students to submit their applications, so we've done just that. > > > The new deadline for student applications is Monday, April 7, 2008. > > > For full details, you can check out the program timeline. Please note > that our engineers are working on the required updates to both > http://code.google.com/soc/2008/ and the FAQs to reflect the extended > deadline, and we will post to this list when the changes have gone > live. > > > In the meantime, get those applications in and nag your friends to > apply. :) > > > Cheers, > LH > > > Leslie Hawthorn > Program Manager - Open Source > Google Inc. > > > http://code.google.com/opensource/

1 0

Re: [boost] Review Request: Generalization of the Pimpl idiom
by Vladimir.Batov＠wrsa.com.au 01 Apr '08

01 Apr '08

"Mathias Gaunard" <mathias.gaunard(a)ens-lyon.org> wrote in message news:<fsptpe$peo$1(a)ger.gmane.org>... > > I have only quickly gone through your documentation on DDJ, so my > comments may be off. Feel free to correct me if I misunderstood something. > > Personally, I fail to see the advantage over a shared_ptr member. > The only differences I could notice are > - implementation class is not user-declared but rather is a > specialization of a template. Well, the pimpl idiom is certainly not a shared_ptr.as pimpl's main purpose is separation of interface and implementation and imlemetation hiding. shared_ptr does not provide the latter. I was hoping I covered all that in the article. > - the null pointer is called null (by the way, I think we shouldn't > allow a null value, the private implementation should always be > initialized somehow, if lazily) The private implementation is always initialized by default. Nowever, null() is certainly needed for many things. And Foo::null() is certainly not a pointer but a proper (but invalid :-)) Foo instance. > There doesn't seem to be any useful help for allocating the private > implementation. What exactly are your expectations? If you'd like private implementation to be allocated for you, then it's simply not possible as ity is called private for a reason. > Such potentially interesting allocation schemes, like stack allocation, > seem also to be impossible. I have not seen one single implementation of pimpl allocating private implementation on the stack and I do not believe it is possible as in order to allocate on the stack we/compiler have to know the size of the class (private implementation class) which is again private. > Being able to replace the private implementation of a base with the > private implementation of a derived class certainly is a necessity. > I have to admit, though, I do not understand your solution. > You're passing a null<Widget>() to the Widget constructor, but the > constructor wasn't written to take any kind of special argument. null<Widget>() is an instance of Widget. Therefore, the copy constructor is called. > I'm not really sure of the point (and validity) of having pointer > semantics. Do you really want your implementation details to be shared > by some of your different instances? (maybe there is a point in sharing > implementation details with all instances or all equivalent instances, > but some?) I am not sure about your usage patterns but my usage of pimpl::pointer_semantics vs. pimpl::value_semantics is 100:1. What is the point (and validity) of having shared_ptr<Foo>? Same is applicable to pimpl::pointer_semantics. > It seems more logical to me to have the same semantics for the object > and its private implementation. If the object itself has pointer > semantics, then you won't copy it. Using one or the other for the > implementation makes no difference, then. You might as well use the > value semantics, which would even be more lightweight in that case. I personally do not see logic the same semantics for the object and its private implementation because the object is the interface and its private implementation is implementation detail (which is private as well). They serve different purpose, have different visibilities et al. What is the advantage of them having the same semantics? Thanks, Vladimir.

1 0

Re: [boost] Review Request: Generalization of the Pimpl idiom
by Vladimir.Batov＠wrsa.com.au 31 Mar '08

31 Mar '08

"Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> wrote in message news:<47F12E07.4060205(a)aaronwl.com>... > Vladimir.Batov(a)wrsa.com.au wrote: > > The code is in the Boost Vault called Pimpl.zip > > I haven't looked at your library, but one thing you need to do to get > buy-in for this library is provide a comparison with the pimpl_ptr > library that was proposed and rejected. > > My perception of the primary reason the library failed is that, despite > being a basically sound library, it didn't work in the ways people > wanted it to. Yes, I looked at that proposed implementation. Unfortunately, the major deficiency of it IMHO was that it was sacrificing implementation hiding (the main pimpl property) for the sake of generalization. I think I cover that in the docs at http://www.ddj.com/cpp/205918714. > It would be useful if you could summarize the vital details of your > library, along with a comparison to the previous proposal, and other > similar libraries, in your announcement message. I hope I cover that at http://www.ddj.com/cpp/205918714 Thanks, Vladimir.

1 0

[gsoc2008] YAML archives for Boost.serialization
by Esteve Fernandez 31 Mar '08

31 Mar '08

Hi all, it seems that the period for student applications has been extended to April the 7th. Although I briefly discussed the idea for YAML archives following a message by Sohail, I would like to explain it in more detail, discuss some concerns and see if there's interest. We already talked about YAML not being a superset of JSON, however given the recent great news of the relicensing of TinyJSON, it still can be used as a basis to build YAML parser. My main concern is that YAML is sensitive to indentation, actually it uses indentation as a substitute for { block }. One can write YAML to look like JSON, use TinyJSON and everything will be fine, but it will not be able to parse documents that use spaces/tabs to delimit blocks, only those that use curly brackets. I guess it will have to be implemented at the scanner level in Boost.Spirit, but it becomes more complicated. Anyway, with more complications, comes more fun :-) I might be mistaken about where to implement this stuff so feel free to correct me, but I think it's the way to go, as I took a look at the source code for the Python interpreter and for LibYAML, and they implemented the indentation stuff in their scanner, not in the parser. The good thing about doing YAML instead of JSON is that all the concerns about object tracking and class versioning disappear, as they're already implemented in the official spec. JSPON might or not be added to the official JSON spec, although there are good chances that it will be, but it's still not officially accepted and may change in the future. Also, a parser needs to implement JSONPath (an XPath-like language for querying JSON documents), since a reference to the root object can be written as "$ref" : "$[0].child" A side advantage of implementing the YAML archives is that a C++ parser for YAML would be available for those who don't want to use the official LibYAML C parser. Anyway, what do you think? Is there interest for this project? Cheers.

1 0

No PropertyTree in 1.35.0; when will it be in an official release?
by Ryan Gallagher 31 Mar '08

31 Mar '08

Congrats on getting the 1.35.0 release out the door and the new website design. I especially like the docs for the old releases being easy to find. However, looking at the announcement and the docs I noticed that PropertyTree is again not in the official release. A quick search on gmane didn't provide me with the reason for this. Whatever the reason, will it be in the next release? What needs to be done to ensure this? There were a couple patches submitted by myself and others in the bugtracker. Any updates on the status of applying these? Thanks, -Ryan PS -- I also noticed a directory "boost/pending" in the distribution. Just curious as to what this is.

3 3

[serialization] boost 1.35.0 / gcc 4.3.0 / 64-bit problem
by bernd.speiser＠t-online.de 31 Mar '08

31 Mar '08

Dear all, I apologize for cross-posting (part of this was already reported on boost-users), but maybe this list is better suited for the problem. I also have some additional information from some more experimentation. Here are the facts: (1) We use several machines for development, all under openSuSE 10.2, some of them 32-, some 64-bit systems. Recently, we have installed gcc 4.3.0. We employ several boost libraries, most notably serialization. (2) boost 1.35.0 (RC2) compiles and installs fine on 32-bit with gcc 4.3.0. Serialization code works fine, as far as we use it. (3) On the 64-bit system, however, version 1.35.0 does not compile with gcc 4.3.0: MkDir1 bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/polymorphic_iarchive.o In file included from libs/serialization/src/polymorphic_iarchive.cpp:18: ./boost/archive/polymorphic_iarchive.hpp:88: error: ‘virtual void boost::archive::polymorphic_iarchive_impl::load(int64_t&)’ cannot be overloaded ./boost/archive/polymorphic_iarchive.hpp:84: error: with ‘virtual void boost::archive::polymorphic_iarchive_impl::load(long int&)’ ./boost/archive/polymorphic_iarchive.hpp:89: error: ‘virtual void boost::archive::polymorphic_iarchive_impl::load(uint64_t&)’ cannot be overloaded ./boost/archive/polymorphic_iarchive.hpp:85: error: with ‘virtual void boost::archive::polymorphic_iarchive_impl::load(long unsigned int&)’ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -I"." -c -o "bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/polymorphic_iarchive.o" "libs/serialization/src/polymorphic_iarchive.cpp" ...failed gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/polymorphic_iarchive.o... gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/polymorphic_oarchive.o In file included from libs/serialization/src/polymorphic_oarchive.cpp:18: ./boost/archive/polymorphic_oarchive.hpp:86: error: ‘virtual void boost::archive::polymorphic_oarchive_impl::save(int64_t)’ cannot be overloaded ./boost/archive/polymorphic_oarchive.hpp:83: error: with ‘virtual void boost::archive::polymorphic_oarchive_impl::save(long int)’ ./boost/archive/polymorphic_oarchive.hpp:87: error: ‘virtual void boost::archive::polymorphic_oarchive_impl::save(uint64_t)’ cannot be overloaded ./boost/archive/polymorphic_oarchive.hpp:84: error: with ‘virtual void boost::archive::polymorphic_oarchive_impl::save(long unsigned int)’ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -I"." -c -o "bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/polymorphic_oarchive.o" "libs/serialization/src/polymorphic_oarchive.cpp" ...failed gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/polymorphic_oarchive.o... gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/stl_port.o gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/text_iarchive.o gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/text_oarchive.o gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.0/debug/threading-multi/void_cast.o (4) Moreover, when compiling (on a 64-bit machine; on 32-bit this is ok) our application code with boost 1.34.1 and gcc 4.3.0, as soon as we #include "boost/serialization/vector.hpp" (even without using any serialization functionality) we receive error messages: /usr/local/include/boost-1_34_1/boost/serialization/vector.hpp:126: error: redefinition of 'struct boost::serialization::implementation_level<std::vector<long int, std::allocator<long int> > >' /usr/local/include/boost-1_34_1/boost/serialization/vector.hpp:126: error: previous definition of 'struct boost::serialization::implementation_level<std::vector<long int, std::allocator<long int> > >' /usr/local/include/boost-1_34_1/boost/serialization/vector.hpp:126: error: redefinition of 'struct boost::serialization::implementation_level<std::vector<long unsigned int, std::allocator<long unsigned int> > >' /usr/local/include/boost-1_34_1/boost/serialization/vector.hpp:126: error: previous definition of 'struct boost::serialization::implementation_level<std::vector<long unsigned int, std::allocator<long unsigned int> > >' On the same machine the code compiles well with boost 1.33.1. Note that 1.34.1 was compiled with an earlier gcc version. Best regards Bernd -- ======================================================================= Bernd Speiser Institut für Organische Chemie Auf der Morgenstelle 18 temporary address: Auf der Morgenstelle 15 D-72076 Tübingen Germany phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory) +49-7071-2972098 (secretary) fax: +49-7071-295518 e-mail: bernd.speiser(a)uni-tuebingen.de Internet: http://www.uni-tuebingen.de/speiser =======================================================================

4 6

[date_time] compilation errors
by Aleksey Midenkov 31 Mar '08

31 Mar '08

The included patch fixes these compile errors: boost/date_time/time.hpp:64: error: expected `)' before 'sv' boost/date_time/local_time/local_time_io.hpp:72: error: 'not_a_date_time' was not declared in this scope

1 0

Boost 1.35: No unordered_map? :(
by Robert Dailey 31 Mar '08

31 Mar '08

I'm really sad to see that unordered_map didn't make it into 1.35. What was the reason for this? When will it be released? When is this next release scheduled? Thanks.

2 1

New website, and bugs.
by Rene Rivera 31 Mar '08

31 Mar '08

I know people love their email. But I would really appreciate it if people would add trac issues for bugs they find on the new web site. I get thousands of emails a day, and have 7 IRC channels open, so the likelihood that I'll forget to add issues for the emails and IM messages is very high. Thanks :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0