- Boost - lists.boost.org

[type_traits][V1.41] is_base_of<void, void> gives different results for gcc and vc
by Hartmut Kaiser 20 Nov '09

20 Nov '09

Hey, I just realized that is_base_of<void, void> gives different (inconsistent) results at least for gcc 4.3.2 (which evaluates this to false) and vc2005sp1 (evaluates to true, as earlier versions of boost did consistently, btw). This is truly a border case, but should expose consistent behavior anyways. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

3 5

[Release Mgt] Vladimir Prus joins release management team
by Beman Dawes 20 Nov '09

20 Nov '09

Vladimir Prus, aka Volodya, has been a big help in getting out timely, high-quality releases for a long time, and has now become an official release manager. Please welcome Volodya to the release team! --Beman --Daniel --Eric --Rene

1 0

Re: [boost] [Boost C++ Libraries] #3644: Getting starting simplified build from source should use a log file.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Thursday, November 19, 2009 8:44 PM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3644: Getting starting simplified build from source > should use a log file. > > #3644: Getting starting simplified build from source should use a log file. > --------------------------------------+------------------------------------- > Reporter: pbristow | Owner: > Type: Bugs | Status: new > Milestone: Boost 1.42.0 | Component: Building Boost > Version: Boost 1.41.0 | Severity: Problem > Keywords: simplified library build | > --------------------------------------+------------------------------------- > > Comment(by vladimir_prus): > > Would printing this information at the end of the build address your > concerns? Well yes it would, but surely it is always better to have a log file so you can check it went OK? Or will checking %errorlevel% tell the user that? But checking %errorlevel% doesn't tell you what libraries you have just built. (If you are using the simple 'default' build, you may not care?) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could be silenced.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Friday, November 20, 2009 3:24 AM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could > be silenced. > > #3646: Boost.test build of libraries - warnings ttat could be silenced. > ---------------------------+------------------------------------------------ > Reporter: pbristow | Owner: rogeeff > Type: Patches | Status: new > Milestone: Boost 1.42.0 | Component: test > Version: Boost 1.41.0 | Severity: Cosmetic > Keywords: test warnings | > ---------------------------+------------------------------------------------ > > Comment(by steven_watanabe): > > These should probably be disabled in the source, since Boost.Test can be > used with direct #include instead of a library. Yes - but I was trying to be realistic and not over-flagellate ;-) Paul

1 0

Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 20 Nov '09

20 Nov '09

Vladimir Batov wrote >> Yes, it sounds very uplifting and inspiring... and I would agree with that >> whole-heartedly... if I considered Boost merely the place of purely academic >> exercise. For many "average" programmers though the Boost libs is first and >> foremost a product that they want to *use* uniformly throughout a project, many >> projects. In that light from the commercial deployment and project management >> points of view having 2 (or worse -- plethora of) functionally-similar >> facilities readily available is a nightmare as some will end up using one >> facility and some others will prefer another facility. Shared knowledge is >> fragmented (people rarely have time and capacity to know all), code reviews, >> maintenance are difficult, the ultimate product looks unprofessional due to >> inconsistencies (in case of logging configurations, formats, destinations will >> be different). It's not an imaginary situation -- our project for various >> reasons ended up using 3 logging facilities with the very real problems >> described above. Rectifying the problem now is an expensive and tiring exercise. >> Do not get me wrong. I am all for creativity, innovation and healthy competition >> of ideas. However, all that does not have to be dumped onto the user to decide >> -- users often have no time, capacity, qualifications, freedom to make an >> educated choice. More so, users often *want* the gurus (and the level of the >> Boost community is most certainly considerably higher than the average) to make >> that educated choice for them. It's like one going to a financial planner for >> help and the planner dumping all the options on to that poor soul. Now that poor >> customer/user has to be a financial planner himself to make an educated choice. It seems to me that you are trying to make boost into something its not. Boost has never been in the business of picking the best library in a particular domain. Its a place where promising libraries can live for a while, get used, and inspire new ideas and approaches. Some of these might make into the c++ standard. I do however agree with your larger point that boost does not SCALE well. Ten years from now, its highly likely that boost will become too large to manage. People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries. For boost to remain popular and successful, this issue will eventually have to be addressed. Fortunately, it probably does not need to be addressed for a few years.

3 2

Re: [boost] [python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Solved it mistake on my side sorry

1 0

[python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Using MSVC 2008 on windows server 2003, Python 2.6.2 Importing python extension modules fails. As an example I compiled the tutorial hello world example; char const* greet() { return "hello, world"; } #include <boost/python.hpp> BOOST_PYTHON_MODULE(hello_ext) { using namespace boost::python; def("greet", greet); in to a dll named hello_ext.pyd. When I try to import the extension I get; >>> import hello_ext Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. In the debugger I see that hello_ext.pyd is loaded and unloaded; 'python': Loaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' 'python': Unloaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' Digging in to it. Can anyone confirm this?

1 0

Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 19 Nov '09

19 Nov '09

I was the review manager of the two futures libraries and a former review wizard. Two issues that I see: 1) Should we review two or more libraries at the same time No. Because of time commitments and lack of review managers, coordinating two reviews at the same time is too difficult. It has not worked. 2) Should we approve libraries that have significant duplication with another library already in boost? Yes. Each library should be reviewed independently, and approved if it meets the boost community standards. Boost libraries already has lots of overlap, no reason to change at this point. What we should do is encourage the authors to work together submit a combined library. Unfortunately, that has not worked either. The trend is probably going to be more and more library duplication, but this does not concern me. I would find it perfectly acceptable if another "command line" parser was approved, or even if another text parser was approved. The more the better. It shows that boost is still interesting place to come and see what talented c++ developers are up too. There are many ways to abstract a solution and build an interface around it. Boost should encourage a diversity of approaches.

2 1

[thread] 1.41.0 MSVC warning
by Okko Willeboordse 19 Nov '09

19 Nov '09

Building 1.41.0 went fine. Compiling my code failed because of a compiler warning. I had to modify ..\thread\future.hpp like below to silence MSVC 2008 SP1 on windows server 2003; 409 #pragma warning(push) 410 #pragma warning(disable: 4267) 411 all_futures_lock(std::vector<registered_waiter>& futures): 412 count(futures.size()),locks(new boost::unique_lock<boost::mutex>[count]) 413 { 414 for(unsigned i=0;i<count;++i) 415 { 416 locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); 417 } 418 } 419 #pragma warning(pop)

1 0

Fix graph_parallel compilation
by Vladimir Prus 19 Nov '09

19 Nov '09

Current trunk does not compile for me as follows: ./boost/graph/distributed/detail/mpi_process_group.ipp: In function ‘int boost::graph::distributed::receive(const boost::graph::distributed::mpi_process_group&, int, int, T&)’: ./boost/graph/distributed/detail/mpi_process_group.ipp:722: error: ‘stderr’ was not declared in this scope ./boost/graph/distributed/detail/mpi_process_group.ipp:724: error: there are no arguments to ‘fprintf’ that depend on a template parameter, so a declaration of ‘fprintf’ must be available ./boost/graph/distributed/detail/mpi_process_group.ipp:724: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated) ./boost/graph/distributed/detail/mpi_process_group.ipp: In function ‘typename boost::enable_if<boost::mpi::is_mpi_datatype<T>, std::pair<int, unsigned int> >::type boost::graph::distributed::receive(const boost::graph::distributed::mpi_process_group&, int, int, T*, size_t)’: OK to apply the attached? - Volodya

2 2