August 2010 - Boost - lists.boost.org

Towards a Warning free code policy proposal
by vicente.botet 03 Sep '10

03 Sep '10

Hi all, Last year there where two long threads about Boost Warning policy. If I'm not wrong nothing was concluded. I think that we can have two warning policies: one respect to the Boost users and one internal for Boost developement. We can consider that Boost headers can be used by the users as system headers, so no warning is reported for these files. The main advantage I see is that it allows the users to don't mix the warnings comming from Boost and their own warnings. Next follows a way to disable completly warnings for 3 compilers: Any Boost header file could be surrounded by #if defined __GNUC__ #pragma GCC system_header #elif defined __SUNPRO_CC #pragma disable_warn #elif defined _MSC_VER #pragma warning(push, 1) #endif and #if defined __SUNPRO_CC #pragma enable_warn #elif defined _MSC_VER #pragma warning(pop) #endif As we want the developer to be able to catch and eliminate as many warning as possible we need some conditional compilation that allows us to enable the warning reporting internally. These could also be useful for users that prefer to see the Boost warnings. Boost.Exception uses already this policy, sourronding some of its files with #if defined(__GNUC__) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma GCC system_header #endif #if defined(_MSC_VER) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma warning(push,1) #endif and #if defined(_MSC_VER) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma warning(pop) #endif I propose to extend this to a 2-level enabling warning system BOOST_ENABLE_WARNINGS: If defined, enable warnings for all the Boost libraries BOOST_<LIB>_ENABLE_WARNINGS: If defined, enable warnings for a specific library <LIB> Regression testers should run with BOOST_WARNING_ENABLED defined. Developers of a library should run with BOOST_<LIB>_WARNING_ENABLED defined at least. Users could enable warnings at any level just by defining the appropriated macro. With this 2-level enabling policy, the preceding surrounding code becomes: #if !defined(BOOST_ENABLE_WARNINGS) && !defined(BOOST_LIB_ENABLE_WARNINGS) #if defined __GNUC__ #pragma GCC system_header #elif defined __SUNPRO_CC #pragma disable_warn #elif defined _MSC_VER #pragma warning(push, 1) #endif #endif and #if !defined(BOOST_ENABLE_WARNINGS) && !defined(BOOST_LIB_ENABLE_WARNINGS) #if defined __SUNPRO_CC #pragma enable_warn #elif defined _MSC_VER #pragma warning(pop) #endif #endif Due to the nature of the GCC solution, this does not work directly within the source (.cpp) file, only within a header (.hpp) file. So if we want to remove the warnings also from the .cpp files we need to move the code to a .hpp file. // a.cpp #include "warning_free_wrapper/a.hpp" Of course this policy don't mean that the developer should not take care of the warnings. Please, let me know if this policy could satisfy the needs of the Boost users and the developers. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

24 64

[quickbook] QUICKBOOK_CYGWIN_1_5 undefined
by vicente.botet 02 Sep '10

02 Sep '10

Hi, I have moved to v1.44, and while I try to build quickbook on cygwin-1.5 I get the following error $ bjam ...patience... ...found 1304 targets... ...updating 5 targets... gcc.compile.c++ ../../../bin.v2/tools/quickbook/gcc-3.4.4/debug/link-static/deta il/input_path.o C:\cygwin\boost\v44\tools\quickbook\detail\input_path.cpp: In function `void qui ckbook::detail::validate(boost::any&, const std::vector<std::string, std::alloca tor<std::string> >&, quickbook::detail::input_path*, int)': C:\cygwin\boost\v44\tools\quickbook\detail\input_path.cpp:80: error: `cygwin_con v_path_t' undeclared (first use this function) C:\cygwin\boost\v44\tools\quickbook\detail\input_path.cpp:80: error: (Each undec lared identifier is reported only once for each function it appears in.) C:\cygwin\boost\v44\tools\quickbook\detail\input_path.cpp:80: error: expected `; ' before "flags" C:\cygwin\boost\v44\tools\quickbook\detail\input_path.cpp:87: error: `flags' und eclared (first use this function) C:\cygwin\boost\v44\tools\quickbook\detail\input_path.cpp:87: error: `cygwin_con v_path' undeclared (first use this function) "g++" -ftemplate-depth-300 -O0 -fno-inline -Wall -g -g0 -DBOOST_ALL_NO_LIB= 1 -DBOOST_SYSTEM_STATIC_LINK=1 -I"../../.." -c -o "C:\cygwin\boost\v44\bin.v2\t ools\quickbook\gcc-3.4.4\debug\link-static\detail\input_path.o" "C:\cygwin\boost \v44\tools\quickbook\detail\input_path.cpp" ...failed gcc.compile.c++ ../../../bin.v2/tools/quickbook/gcc-3.4.4/debug/link-s tatic/detail/input_path.o... ...skipped <p../../../bin.v2/tools/quickbook/gcc-3.4.4/debug/link-static>quickbo ok.exe for lack of <p../../../bin.v2/tools/quickbook/gcc-3.4.4/debug/link-static >detail/input_path.o... See on the code I see that there is a test on QUICKBOOK_CYGWIN_1_5 which is not defined in any file. When I define it everything works as before. Should the user define QUICKBOOK_CYGWIN_1_5 when working on cygwin-1.5 ? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 3

Re: [boost] [gsoc] Boost.Process done
by Adam Merz 01 Sep '10

01 Sep '10

Boris Schaeling <boris <at> highscore.de> writes: <snip> > If there are other ideas how to generate a unique name I can update the code > (Windows provides an API to generate UUIDs but unfortunately it requires COM; > on POSIX systems I'm not aware of any system function which could generate > UUIDs). > > Boris For Windows, Neither UuidCreate nor UuidCreateSequential require COM. Are these not generally suitable for your needs?

3 5

[msm] Boost MPL vector limit size exceeded
by Michael.Herchel＠rohde-schwarz.com 01 Sep '10

01 Sep '10

Hi, while building a state machine that also includes submachines, we exceeded the possible max number of MPL vector entries (which is to 50 to my knowledge) for transition tables. Is there an easy way to solve that? How to increase the max possible number of MPL vector entries? Do I have to manually create vector60.hpp and vector60_c.hpp? Or is there something that generates all those files (also for larger vectors)? I also tried the define "BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS" with and without specifing the define "FUSION_MAX_VECTOR_SIZE". I tried the "favor_compile_time" vs "favor_runtime_speed" as well. In both cases the MPL vector size was to small. Does it actually mean, in case we use submachines, that MSM generates a flat transition table including everything in one MPL vector? Example: Main state machine consiting of 10 transitions + 1 submachine consiting of 5 transitions. Do we than have a transition table with around 15 entries that are stored somehow in an MPL vector of size 15? Thanks for your help, Michi

4 3

[Boost] [Log] Problem with Release mode build
by Sivaram Kannan 31 Aug '10

31 Aug '10

Hi, I have been using boost log with two of my projects, one an VC++ 2008 exe and another a VC++ DLL. Boost log was working as expected in the Debug mode. But when I compiled the projects in release mode, the boost log with the exe is not logging anything on the file and the dll is creating an access violation. Following is the call stack which is throwing the error. cnbc.dll!boost::log_mt_nt5::sources::basic_logger<wchar_t,boost::log_mt_nt5::sources::wseverity_logger_mt<int>,boost::log_mt_nt5::sources::multi_thread_model<boost::shared_mutex> >::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > >(const boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > & args={...}) Line 269 + 0x15 bytes C++ cnbc.dll!boost::log_mt_nt5::sources::basic_severity_logger<boost::log_mt_nt5::sources::basic_logger<wchar_t,boost::log_mt_nt5::sources::wseverity_logger_mt<int>,boost::log_mt_nt5::sources::multi_thread_model<boost::shared_mutex> >,int>::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > >(const boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > & args={...}) Line 226 + 0xc bytes C++ cnbc.dll!boost::log_mt_nt5::sources::basic_composite_logger<wchar_t,boost::log_mt_nt5::sources::wseverity_logger_mt<int>,boost::log_mt_nt5::sources::multi_thread_model<boost::shared_mutex>,boost::mpl::vector1<boost::log_mt_nt5::sources::severity<int> > >::open_record<boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > >(const boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > & args={...}) Line 509 + 0x14 bytes C++ I have compiled the boost in release mode and as shared. Following is the command I used. , .\bjam.exe --with-log --with-filesystem --with-system --with-date_time --with-thread --with-regex define=BOOST_ALL_DYN_LINK variant=release link=shared stage What am i doing wrong here?? Thanks, Siva. .

2 5

Re: [boost] Some modifications to the Boost random library
by Eric Hopper 31 Aug '10

31 Aug '10

Steven Watanabe wrote: > Eric Hopper wrote: >> I have written a new class for small random integers... >> >> Would there be interest in these modifications? > >Can you post the code here? Sure. I've attach the patch file against Boost 1.43. -- "It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg." --- Thomas Jefferson "Go to Heaven for the climate, Hell for the company." -- Mark Twain -- Eric Hopper (http://www.omnifarious.org/~hopper) --

3 3

[website] documentation page shows 1.43.0 as current
by Michael Caisse 31 Aug '10

31 Aug '10

<http://www.boost.org/doc/> indicates 1.43.0 is the current release and no link exists for 1.44.0 michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

boost.lockfree update
by Tim Blechmann 31 Aug '10

31 Aug '10

hi all, i've did some updates to boost.lockfree the biggest difference to earlier snapshots is, that it includes a fixed-size single-producer/single-consumer ringbuffer. besides, the documentation is based on doxygen now. snapshots are available from [1], docs from [2] and my git repository can be found at [3] and cloned from [4]... cheers, tim [1] http://tim.klingt.org/code/projects/boost-lockfree/files [2] http://tim.klingt.org/boost_lockfree/ [3] http://tim.klingt.org/git?p=boost_lockfree.git [4] git://tim.klingt.org/boost_lockfree.git -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

11 29

https://svn.boost.org/trac/boost/ticket/4515 Nasty naming conundrum? (Or does C++ need a 'not using ...; ' statement?)
by Paul A. Bristow 31 Aug '10

31 Aug '10

https://svn.boost.org/trac/boost/ticket/4515 has uncovered a nasty example of name ambiguity caused by the addition of <random> to the Standard Library. As the Standard Library expands, it may not be the last:-( http://tinyurl.com/2blmq3l gives an example of details of the ambiguity of the name 'binomial_distribution'. "error: reference to ???binomial_distribution??? is ambiguous" Random library defines 'binomial_distribution' and so 'using namespace std;' brings this name into std scope implicitly because it is a library item name (explicitly if random is included or perhaps implicitly by some '#include <std>;' declaration). But Boost.Math also defines the name 'binomial_distribution' but in the namespace boost::math. So this implies that it may be necessary to fully qualify boost::math::binomial_distribution at all uses. Ugh! We don't want to add namespace qualifiers everywhere because it messes up the simplicity of the example, but without them the code *might not* compile on C++0x compilers depending upon whether <random> happens to get included or not. To my ignorant surprise, 'using boost::math::binomial_distribution;' does not trump 'using namespace std;', despite being explicit *if it is at global scope ()*. But 'using boost::math::binomial_distribution;' works as I expected only at *local* scope. (Is this right language gurus? It feels too complicated?) Solution are: 1 Always fully qualify names like "boost:math::binomial_distribution<> my_bd;' This is hideously verbose. 2 Use " std::cout;" etc (instead of "using namespace std;" and "cout <<..." , but it gets tediously verbose. 3 Use "using std::cout;" etc instead of "using namespace std;", so we can still write cout << .. << endl; I have always favoured this solution because it documents clearly which functions are being used, and avoids the tedium of writing 'std::cout;'. (And from habit - because "using namespace std;" seemed to cause trouble using early MSVC). But it does add some clutter and *must not be done at global scope in .hpp files* - because it would quietly commit all those who #include to this definition (which may not be what they want/expect). 4 Use "using boost:math::binomial_distribution;" at local scope (but NOT at global scope). (Include files could be used to make this less verbose if there a lots of functions?) 5 Use a namespace alias for boost::math:: to reduce the verbosity of Richards proposed fix with ticket/4515. This feels like a sticking plaster solution? and is still nearly as ugly is 'bm::binomial_distribution'. Overall, John Maddock and I having pondered the least worst solution and are inclined to recommend: a Avoid using global "using namespace anything;" b For each include like <iostream>, use "using std::cout;" statements at local scope for included .hpp files, and at global (or local) scope for source .cpp files (or always write the fully qualified "std::cout << ... "). c For each boost::math include, like "#include <boost:math::binomial_distribution>", provide a "using boost:math::binomial_distribution;" statements (at local scope for included .hpp files and at global (or local) scope for source .cpp files). This may seem an obscure problem, but are there likely to be increasing number of name clashes like this as libraries increase in number? Views? Paul PS My proposal for adding a "not using ... " statement to C++ has so far got a less than warm reception ;-) Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 1

[thread] Any way to avoid creating the .tls section on Windows
by Rush Manbert 31 Aug '10

31 Aug '10

Yet another bizarre question... (the easy ones have all been answered by now) This is a Windows-specific question. We build a dll that is loaded with the LoadLibrary function. Indirectly (through a third-party library), that dll links against the boost thread library. For reasons that I won't go into, the existence of the .tls section in the resulting binary is problematic for us. I looked at the code and found this comment inside the file tss_pe.cpp: //The following line has an important side effect: //if the TLS directory is not already there, it will //be created by the linker. In other words, it forces a tls //directory to be generated by the linker even when static tls //(i.e. __declspec(thread)) is not used. //The volatile should prevent the optimizer //from removing the reference. I'm not much of a Windows guy and I currently don't understand what is going on in tss_pe.cpp. I did a search of the boost sources and I don't find __declspec(thread) used anywhere, which was encouraging. I'm wondering two things: 1) Why does the code force a .tls section to be created, even when static tls is not being used? 2) If we know that static tls is not used in any of the code, is it safe to remove the .tls section from the PE file? (We know a lot about manipulating PE files, so definitely know how to do this.) We have experimented with removing the .tls section by hand and running the dll, and everything seems to work, but I'm really hoping that Anthony Williams might take pity on me and provide some information. Thanks, Rush

2 1