October 2012 - Boost - lists.preview.boost.org

[serialization] how to retreive true_type from an archive ?
by nico 30 Oct '12

30 Oct '12

Hello. Context: ------- I use the boost serialization library to save and load objects of a system. I defined practices around this lib, and so I always serialize from a base class (every class serializable inherits from ISerializable). As a consequence, the true_type (i.e. the most derived type) is different from the this_type (i.e. ISerializable) and the true_type is stored in the archives. My question: ----------- How to retreive this true_type (as the string written in the archive), only from the archive object? I developp just a little bit: ---------------------------- Let's have this class tre: ISerializable <|-- B <|-- D If I do : B* b = new D(); b->SaveToFile(path); // <= this will do the serialization ar & this (this being a ISerializable*) I obtain an archive where it is written the true_type "D" (whatever the type of the archive : txt, bin or xml). With the b object and this code : const boost::serialization::extended_type_info & true_type = * boost::serialization::type_info_implementation<ISerializable>::type ::get_const_instance().get_derived_extended_type_info(*b); I have what I want in true_type.get_key(), i.e : "D". I can verify that "D" is written in every archive storing b. My question again : how, only with an archive object (construct from the archive file without error), car I retrieve this key? Tanks for any help. Nicolas.

2 3

[declval] non-ascii characters in declval.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Vicente, `utility/declval.hpp` contains a non-ascii character. I tried to fix this and make some improvements. Attached a patch that * removes a non-ascii character, * updates references to the C++11 standard, * fixes obvious oversights (e.g. `// common_type.hpp` --> `// declval.hpp`), * cleans up and reformats the comments (to the style you used in `add_rvalue_reference.hpp`), * renames the include guard macro (`BOOST_TYPE_TRAITS_EXT_...` --> `BOOST_UTILITY_`). May I commit it? Regards, Michel

2 2

[algorithm] non-ascii characters in boyer_moore.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Marshall, `boost/algorithm/searching/boyer_moore.hpp` contains a non-ascii character ("–", en dash) at line 37: 36: Explanations: boostinspect:noascii (test tool complains) 37: http://en.wikipedia.org/wiki/Boyer–Moore_string_search_algorithm Would it be better to URL-encode the dash as "%E2%80%93" rather than relying on `boostinspect:noascii`? Regards, Michel

1 0

Re: [boost] [variant] awkward recursion
by Balazs Arva 29 Oct '12

29 Oct '12

At this moment I'm developing a json library with similar approach. With variant I think the only way this: typedef boost::make_recursive_variant < int, unsigned int, long, unsigned long, float, double, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; typedef std::vector<value> array; typedef std::map<std::string, value> object; I did not find any better solution. However there is still one problem: I do not want to write down every numeric POD in tmpl parameter list. It is a major problem because value a=(unsigned int)5; could not compile. Do you have any advice? I would like do something like this: typedef boost::make_recursive_variant < any_pod_numeric_type, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; Balazs Arva

1 0

Boost.Process 0.5: Minor update
by Boris Schaeling 28 Oct '12

28 Oct '12

I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>: - search_path() added which was called find_executable_in_path() in previous versions (Windows implementation changed quite a lot) - shell_path() added which returns the absolute path to a shell executable - set_args() added which is an initializer to pass command line arguments as a collection (with automatic escaping) - Minor bug fixes There is one more update planned to somewhat mitigate remaining cross-platform differences. Please keep the feedback coming (here on the mailing list or by email)! Boris

1 0

Interesting article on stack-based TMP
by Julien Nitard 28 Oct '12

28 Oct '12

Hi All, That article came out of reddit C++ section: http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… It looks like TMP made easy (finally !). I am not that sure it is though and was wondering if anybody had any comments on it. Regards, Julien

9 20

[Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
by Matthew Chambers 27 Oct '12

27 Oct '12

I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list. How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build." How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC? Thanks, -Matt > (2012/10/17 0:09), Matthew Chambers wrote: >> On 10/15/2012 11:29 PM, Steven Watanabe wrote: >>> AMDG >>> >>> On 10/15/2012 07:54 PM, Kohei Takahashi wrote: >>>> Hi all, >>>> >>>> Can anyone handle following two issues? >>>> >>>> <runtime-debugging>on does nothing for libstdc++... >>>> https://svn.boost.org/trac/boost/ticket/4589 >>>> >>> >>> This is /not/ a trivial issue. It may be easy to do, but: > > I understood about this is not trivial issue and I changed the subject. > > >>> a) _GLIBCXX_DEBUG was broken last time I tried it a few years >>> ago. It won't work with all versions of gcc. >> >> I've used it with 4.1.2 and it helped a lot to track down some >> mysterious failures. > I don't know about old releases but recents seem to work well for me. > Indeed, expects to work well and should work with all versions of gcc > if define it by default. > >>> b) Anything the changes the ABI of the compiled libraries needs >>> careful consideration and must be documented. The libraries that >>> are built need to be ABI compatible with code that isn't >>> compiled using Boost.Build. >> >> Is it really that important that debug builds be ABI compatible >> between disparate builds? I think it's reasonable to EXPECT trouble >> when linking a debug build to precompiled libraries. That is >> certainly the case on Windows. > > <define> is not propagated feature, that means to trigger unexpected > link failure or ABI breaking. I think that using <runtime-debugging> > make safely rather than <define>. > I think it is better that provides propagated feature (as > <runtime-debugging> or another) for such purpose at least. > > >>> c) <runtime-debugging>on is part of <variant>debug, but I don't >>> think _GLIBCXX_DEBUG is a standard part of debug builds with >>> gcc. >> >> What is a "standard" debug build with gcc? Most people would >> probably say -g and -O0 but that doesn't provide any real debugging >> support. >> >> I agree it's not trivial, but having a no-op runtime-debugging >> feature is cringe-worthy. It's as good as admitting that GCC (or >> rather, libstdc++) doesn't provide any "official" runtime debugging >> support which is unfair. >> >> In the spirit of upcoming elections, count this as a vote for >> turning on _GLIBCXX_DEBUG. :)

5 4

Relationship of Boost libraries to TR1 and C++11
by Dave Abrahams 27 Oct '12

27 Oct '12

I don't suppose anyone has written up the specific differences between Boost libraries like regex, bind and shared_ptr and their TR1 and C++11 counterparts? It would be great if the maintainers of libraries that were accepted could add a FAQ about that. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

BoostCon old videos
by Fernando Pelliccioni 27 Oct '12

27 Oct '12

Does anyone know where I can get the videos of previous years BoostCon? In particular I am looking for the following: "Cross-platform development with Qt and Boost" http://blip.tv/boostcon/joao-p-r-abecasis-cross-platform-development-with-q… Thanks and regards, Fernando Pelliccioni.

5 5

Fwd: Re: [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 26 Oct '12

26 Oct '12

-------- Original Message -------- Subject: Re: [system] symbol visibility and GCC vs. Clang Date: Tue, 23 Oct 2012 10:40:42 -0700 From: James Walker <jamesw(a)frameforge3d.com> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org CC: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Newsgroups: gmane.comp.lib.boost.user References: <5085BABE.9030609(a)frameforge3d.com> <50868205.6070508(a)ens-lyon.org> On 10/23/2012 4:39 AM, Mathias Gaunard wrote: > On 22/10/12 23:29, James Walker wrote: >> When trying to link a bunch of libraries on OS X, I got this linker >> warning: >> >> ld: warning: direct access in >> boost::system::system_error::~system_error() to global weak symbol >> vtable for boost::system::system_error means the weak symbol cannot be >> overridden at runtime. This was likely caused by different translation >> units being compiled with different visibility settings. >> >> As far as I can tell, everything is compiled using the flags >> -fvisibility=hidden -fvisibility-inlines-hidden. >> >> I'm wondering whether the problem is that some of the libraries were >> built using gcc and some were built using Clang. In >> boost/system/system_error.hpp, the declaration of >> boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In >> boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be >> __attribute__((visibility("default"))), whereas >> boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. > > This looks like a significant bug, POSIX-style symbol visibility doesn't > work with Clang. > Please file a ticket. OK, thanks. <https://svn.boost.org/trac/boost/ticket/7559> -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/>

2 1