- Boost - lists.boost.org

[chrono][ratio][boost_1_52_0_beta1] warning in user code
by Jeff Flinn 31 Oct '12

31 Oct '12

I've just downloaded boost_1_52_0_beta1 and get the warning below in my user code on VC11(I'm using thread which evidently brings in the above libs). I didn't see mention of this in trac. I'm moving forward from 1.47 and from VC8 so I'm not sure if this is an indication of some project setting[s] of mine, or if it should be corrected in the lib? Thanks, Jeff 6>D:\boost_1_52_0_beta1\boost/ratio/detail/overflow_helpers.hpp(136): warning C4293: '<<' : shift count negative or too big, undefined behavior 6> D:\boost_1_52_0_beta1\boost/ratio/detail/overflow_helpers.hpp(282) : see reference to class template instantiation 'boost::ratio_detail::br_mul<X,Y>' being compiled 6> with 6> [ 6> X=0x01, 6> Y=0x01 6> ] 6> D:\boost_1_52_0_beta1\boost/ratio/ratio.hpp(155) : see reference to class template instantiation 'boost::ratio_detail::ratio_divide<R1,R2>' being compiled 6> with 6> [ 6> R1=boost::ratio<0x01,0x0989680>, 6> R2=boost::ratio<0x01,0x03e8> 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/duration.hpp(305) : see reference to class template instantiation 'boost::ratio_divide<R1,R2>' being compiled 6> with 6> [ 6> R1=boost::ratio<0x01,0x0989680>, 6> R2=boost::ratio<0x01,0x03e8> 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/duration.hpp(784) : see reference to class template instantiation 'boost::chrono::detail::duration_cast<FromDuration,ToDuration>' being compiled 6> with 6> [ 6> FromDuration=boost::chrono::duration<int_least64_t,boost::ratio<0x01,0x0989680>>, 6> ToDuration=boost::chrono::milliseconds 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/ceil.hpp(27) : see reference to function template instantiation 'boost::chrono::duration<Rep,Period> boost::chrono::duration_cast<To,int_least64_t,boost::ratio<N,D>>(const boost::chrono::duration<Rep,boost::ratio<N,D>> &)' being compiled 6> with 6> [ 6> Rep=int_least64_t, 6> Period=boost::milli, 6> To=boost::chrono::milliseconds, 6> N=0x01, 6> D=0x0989680 6> ] 6> D:\boost_1_52_0_beta1\boost/thread/win32/basic_timed_mutex.hpp(199) : see reference to function template instantiation 'To boost::chrono::ceil<boost::chrono::milliseconds,int_least64_t,boost::ratio<N,D>>(const boost::chrono::duration<Rep,Period> &)' being compiled 6> with 6> [ 6> To=boost::chrono::milliseconds, 6> N=0x01, 6> D=0x0989680, 6> Rep=int_least64_t, 6> Period=boost::ratio<0x01,0x0989680> 6> ]

4 8

[Move] Documentation Notes/Questions
by Dave Abrahams 31 Oct '12

31 Oct '12

1. In the docs, "comes in handful" => "comes in handy" 2. IMO, it's almost irresponsible to advertise move_iterator without saying that it's really *only* safe to use when you know implementation details of the algorithm or function to which you're passing it. In particular, it must not attempt to copy from any given position in the sequence more than once. 3. Why doesn't test_move_inserter use std::copy? 4. This sentence doesn't make any sense to me; it needs clarification. I would make a suggestion, but, well, I don't understand what you're trying to say The last one has the same behaviour as std::uninitialized_copy but since several standand library implementations don't play very well with move_iterators, this version is a portable version for those willing to use move iterators. 5. The section on constructor forwarding seems to imply that constructors are the only thing that will be forwarded, when of course that's not the case. 6. These sentences don't make sense to me together. They have no obvious connection to one another. To which limitations are you referring? Fortunately, most constructors take arguments by value, by const-reference or by rvalue reference. If these limitations are accepted, the forwarding emulation of a N-argument case requires just N overloads. This library makes this emulation easy with the help of BOOST_FWD_REF and boost::forward As far as I can tell from the implementation, BOOST_FWD_REF just generates a const& in emulation mode, which isn't much of an emulation at all. 7. "David Abrahams suggested the use of class rv class": too much class :-) -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 7

problem adding new toolset
by Pavel Heimlich, a.k.a. hajma 30 Oct '12

30 Oct '12

Hi, I'm trying to add support for building Boost on Solaris 11 with Solaris Studio and the Apache stdcxx4 library. While building it manually works well, I have problems with running the regression testsuite, it fails when trying to build process_jam_log. I'm quite lost in the Boost build system so I don't even know how to start debugging this. TIA for any hints hajma my patch: http://pastebin.com/BbuDv5PB build log: http://pastebin.com/h6wBL6ub

2 3

[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