- Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-05-15)
by Douglas Gregor 15 May '07

15 May '07

Boost Regression test failures Report time: 2007-05-14T23:41:53Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… No failures! Yay!

1 0

[boost] [1.34.0] failed to build on VS2003
by 郭晨 15 May '07

15 May '07

Hi all: I catch a build error on build boost_1_34_0. I used bjam to build the libs: bjam -sTOOLS=vc-7_1 stage My PC si IBM ThinkPad R40e, and I install the window XP(SP2,englis version,I used the China PRC as the default Language) as OS.I used Microsoft Visual Studio .NET 2003 as the build environment. On my PC, I install the python 2.5. I copy the information follow when I get the error: ------------------------------------------------------------------------ D:\STLDIR\boost_1_34_0>bjam -sTOOLS=vc-7_1 stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). warning: No toolsets are configured. warning: Configuring default toolset "msvc". warning: If the default is wrong, you may not be able to build C++ programs. warning: Use the "--toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html ...patience... ...patience... ...found 5787 targets... ...updating 944 targets... compile-c-c++ bin.v2\libs\graph\build\msvc-7.1\debug\threading-multi\read_graphv iz_spirit.obj read_graphviz_spirit.cpp boost\config.hpp(0) : fatal error C1084: 无法读取包含文件:“d:\stldir\boost_1_34 _0\boost\config.hpp”: Invalid argument call "d:\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo @"bin.v2\libs\graph\build\msvc-7.1\debug\threading-multi\read_ graphviz_spirit.obj.rsp" ...failed compile-c-c++ bin.v2\libs\graph\build\msvc-7.1\debug\threading-multi\r ead_graphviz_spirit.obj... ...skipped <pbin.v2\libs\graph\build\msvc-7.1\debug\threading-multi>boost_graph- vc71-mt-gd-1_34.dll for lack of <pbin.v2\libs\graph\build\msvc-7.1\debug\threadi ng-multi>read_graphviz_spirit.obj... ...skipped <pstage\lib>boost_graph-vc71-mt-gd-1_34.dll for lack of <pbin.v2\libs \graph\build\msvc-7.1\debug\threading-multi>boost_graph-vc71-mt-gd-1_34.dll... ...skipped <pbin.v2\libs\graph\build\msvc-7.1\debug\threading-multi>boost_graph- vc71-mt-gd-1_34.lib for lack of <pbin.v2\libs\graph\build\msvc-7.1\debug\threadi ng-multi>read_graphviz_spirit.obj... ...skipped <pstage\lib>boost_graph-vc71-mt-gd-1_34.lib for lack of <pbin.v2\libs \graph\build\msvc-7.1\debug\threading-multi>boost_graph-vc71-mt-gd-1_34.lib... ...skipped <pstage\lib>boost_graph-vc71-mt-gd.lib for lack of <pstage\lib>boost_ graph-vc71-mt-gd-1_34.lib... compile-c-c++ bin.v2\libs\graph\build\msvc-7.1\release\threading-multi\read_grap hviz_spirit.obj ------------------------------------------------------------------------ Then a get a pop up message box: Microsoft Visual C++ Runtime Library Buffer overrun detected! Program:…crosoft Visual studio.NET 2003\VC7\BIN\cl.exe A buffer overrun has been detected which has corrupted the program’s internal state. The program cannot safely continue execution and must now be terminated. OK Iyou can see the picture with the url:http://p.blog.csdn.net/images/p_blog_csdn_net/nscboy/302890/o_boost_bui… nscboy (郭晨) E-mail: nscboy(a)tom.com

4 5

binomial distribution - not documented?
by Neal Becker 15 May '07

15 May '07

It looks like binomial_distribution is missing documentation: http://boost.org/libs/random/random-distributions.html

3 4

[1.34.0] failed to build on cygwin
by Atry 15 May '07

15 May '07

I run "bjam install --toolset=gcc-3.4", and this is the output: Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p/usr/local/lib>exact.dll.a error: previous virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.compile.c++-trackable.o.OBJ { trackable.cpp.CPP } } { gcc%gcc.compile.c++-connection.o.OBJ { connection.cpp.CPP } } { gcc%gcc.compile.c++-named_slot_map.o.OBJ { named_slot_map.cpp.CPP } } { gcc%gcc.compile.c++-signal_base.o.OBJ { signal_base.cpp.CPP } } { gcc%gcc.compile.c++-slot.o.OBJ { slot.cpp.CPP } } } } } error: created from ./install-unversioned error: another virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_prg_exec_monitor-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_prg_exec_monitor-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.compile.c++-execution_monitor.o.OBJ { execution_monitor.cpp.CPP } } { gcc%gcc.compile.c++-cpp_main.o.OBJ { cpp_main.cpp.CPP } } } } } error: created from ./install-unversioned error: added properties: <define>BOOST_TEST_DYN_LINK=1 error: removed properties: <define>BOOST_SIGNALS_DYN_LINK=1 <define>BOOST_SIGNALS_NO_LIB=1 /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:459: in actualize-no-scanner from module object(file-target)@16511 /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:111: in object(file-target)(a)16511.actualize from module object(file-target)@16511 /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build-system.jam:476: in load from module build-system /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/kernel/modules.jam:261: in import from module modules /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module /cygdrive/c/My Documents/down_src/boost_1_34_0/boost-build.jam:9: in module scope from module

5 8

Why bjam is so great, or, [re] boost building with cmake
by Dirk Griffioen 15 May '07

15 May '07

Hi all, I just read (a bit of) the discussion on cmake - to me it's ominous boost is even considering this. For me there were 2 reasons to start using boost in 2001, the libs *and* the build system. NO more vc projects file, make files, generated makefiles etc. But an elegant tool with a simple syntax building all my plaforms. (And please know, at some point we wrote our own makefile generator, but I can admit, bjam is just a better tool). After that I started using bjam (bbv2) as my main buildtool and been happy with it ever since: * I used it for over 4 years in all my work/commercial/consulting and private projects * 'it just works' * it forces you to structure your code well, think 'mountpoint = project' * target definition is simple and elegant * it nicely intergrates in a buildsystem like cerberus (http://cerberus.rubyforge.org) on all platforms I use(d) (sun,hp,aix,as400,osx,windows,linux ... Some thing that worry me in the discussion: We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. This is marketing speak! (And has nothing to do with how things work in reality). And secondly, I believe tools like VC are not in the best interest of developers, so remarks like CMake is about integrating well with the way the user develops code. That might be makefiles, VC++ projects, XCode projects, whatever. Having used CMake, bjam, and autotools, I've found CMake to be by far the easiest system for *users* to get up and running with. may sound reasonable, they are in fact a corruption - I apologize if this sounds offending, but I have never seen anything good coming from have to wade through a sea of projectfiles,makefiles,makefile-alike-syntax,the code itself *and* a directory structure below it all: too many universes to juggle around. It's complex enough even if you have a 1-on-1 mapping between buildsystem, code and directory layout; so in my view there's nothing wrong with imposing structure on users, they might even benefit from it (I know Id did ...). To me it's feel backwards to try and get some 'old school' stuff like cmake into boost. Sure, bjam documentation isnt' all great and if there's only one guy doing the work, maybe that's the key to a solution then: write some docs, and get Mr Prus some help ... And I may offend people here, but everyone I ever heard or saw complaining about bjam's difficulty (on windows or ...), well, they're just lazy. It's not that hard to build and I think some of the remarks by Mr Caisse, Mr Rivera, Mr Rozental and others demonstrate this. Well, there you have it - Regards, Dirk

2 1

[gil] notorious C4675 warning
by Christian Henning 14 May '07

14 May '07

My compiler ( VC 7.1 SP1 ) is getting on my nerves with a C4675 warning. Taking the help file C4675 is only important when creating code that might be used by older compiler, as well, and then leading to different function calls. The warning looks like this: c:\boost\boost\gil\image.hpp(141) : warning C4675: 'void boost::gil::swap<boost::gil::rgb8_loc_t>(boost::gil::image_view<Loc> &,boost::gil::image_view<Loc> &)' : resolved overload was found by argument-dependent lookup with [ Loc=boost::gil::rgb8_loc_t ] [snip] "A function found by argument-dependent lookup (Koenig lookup) was eventually chosen by overload resolution. In Visual C++ .NET and earlier compilers, a different function would have been called. To pick the original function, use an explicitly qualified name." >From now on I would believe to ignore that warning. If someone else thinks differently, please let me know. I brought up this issue to have a hint for people searching for an answer. Regards, Christian

1 0

[BoostCon07][testing] Session reminder.
by Rene Rivera 14 May '07

14 May '07

Boost Community, The Boost Conference will be here in very short order! And I need to get feedback for the "Testing Boost" sprint we'll be doing <http://boostcon.com/program/sessions#rivera-testing-sprint>. If you have any ideas, concerns, off the wall comments, etc. at *minimum* send them directly to me at "rrivera/acm.org". Why that account? Well because that will be the one account I can guarantee I will access to during the conference, and hence people can send me stuff up to the last minute. Not that I'm encouraging lateness, but I know how busy we all are ;-) If you are going to send it to the Boost dev list you will also want to eventually send me a summary follow up, if needed, from the ensuing discussions. Looking forward to seeing some of you at Aspen! -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

20 90

[type_traits]interest in inclusion of aligned_types in type_traits?
by Larry Evans 14 May '07

14 May '07

Query: The code here: http://boost-consulting.com/vault/index.php?&directory=variadic_templates in: aligned_types.2.zip(tr1/aligned_types.hpp) would seem to fit best in boost's type_traits, in particular, with those templates described here: http://www.boost.org/doc/html/boost_typetraits/category.html#boost_typetrai… Is there any interest in adding the aligned_types code there? Brief Description: The aligned_types template declaration is: template<class Tag, typename... Types> struct aligned_types; where: Tag is the "layout tag". Currently the only such tags are: variant tuple packed Types is a sequence of types (much like the current variant and boost sequences) and where the resulting nested type: aligned_types<Tag,Types...>::type is simply an instance of aligned_storage with sufficient memory to accommodate Types... in a layout specificed by Tag. For example, with Tag==variant, the aligned_storage is the same as that for the aligned_union<0,Types...> of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2140.pdf The other tags are for regular structs(tag=tuple) and packed structs(tag=packed). WARNING-Needs Variadic Template Compiler: The code uses Gregor's variadic template compiler: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html hence, it can't be used with any other compiler. However, I'd think it could be converted to use the preprocessor methods used by much of boost::mpl and boost::fusion to approximate Gregor's variadic templates. Applications: Reuse in boost::variant: Around line 215 of: http://boost.cvs.sourceforge.net/boost/boost/boost/variant/variant.hpp?revi… there's make_storage whose nested type, is, AFAICT, the same as aligned_types<variant,Types...>::type. The one difference is that make_storage (from looking just at lines 233-235) calculates the alignment of the variant and the max of the individual alignements. However, as explained in: aligned_types.2.zip(libs/tr1/doc/aligned_struct_offsets.txt) least-common-multiple instead of max is needed to handle extended alignments. Thus, aligned_types<variant,Types...> could be used in place of the current variant's make_storage. Space efficient tuple without preprocessor: By using aligned_types<tuple,Types...>::type as a storage buffer for a tuple, and using the mpl::at_c specializations in aligned_types.2.zip(tr1/aligned_types.hpp) to access the subparts of this storage buffer corresponding to an element in Types..., a tuple implementation as space efficient as fusion's could be achieved without use of the boost preprocessor library.

1 0

confused about uniform_01
by Neal Becker 14 May '07

14 May '07

I'm confused. Usually I want to share the state of 1 underlying rng between many distributions, to ensure good independence. So, for example: boost::variate_generator<rng_t&, boost::uniform_real<> > gen; But uniform_01 holds a rng member: base_type _rng; which is not declared as a reference. But, I _can't_ make it a reference, by doing: boost::uniform_01<rng_t&> eng; Because uniform_01 says: base_type& base() { return _rng; } Which would then be && and won't compile. What am I not understanding?

1 0

[GIL] Loading a PNG from a stream
by Michael Marcin 14 May '07

14 May '07

Hello, I have the need to load a PNG from a generic input stream that has a similar interface (i.e. has a read, operator ! and fail with the same signature/semantics as std::istream). The png reading extensions don't appear to be able to load from anything other than a FILE*. In a library as modern as GIL I'm sort of suprised there is apparently no way to load from a generic stream. Anyone have an idea how to make this happen? Perhaps there is another PNG library written in C++ or a wrapper around the C libpng? Thanks, Michael Marcin

4 5