- Boost - lists.boost.org

[test] Boost.Test partly broken with VC7.1?
by John Maddock 15 Oct '07

15 Oct '07

If the new Boost.thread is included before Boost.Test, then Boost.Test doesn't compile with: ..\boost\test\impl\execution_monitor.ipp(60) : fatal error C1021: invalid preprocessor command 'warning' See http://beta.boost.org/development/tests/trunk/developer/output/RudbekAssoci… Looks like that should be a #pragma message, since msvc has never supported the non-standard #warning (a gcc'ism). Can this be fixed in Trunk soonish? Many thanks, John Maddock

3 4

[ptr_container] cv-qualified containee?
by shunsuke 15 Oct '07

15 Oct '07

Hi, Can ptr_containers contain cv-qualified types? In other words, `ptr_vector<int const>` is allowed? Regards, -- Shunsuke Sogame

1 0

Boost Home page currently not passes XHTML1.0 Validation
by David Abrahams 15 Oct '07

15 Oct '07

See below -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[asio] order of initialization problem with boost::asio::error::system_category
by David Deakins 14 Oct '07

14 Oct '07

I am getting failures of the error.cpp regression test for asio that seem to be related to an order of initialization problem with the new boost::asio::error::system_category. It appears that asio::error::system_category is a const reference initialized by error::detail::get_system_category(), which simply returns boost::system::system_category. The problem seems to be that boost::system::system_category is itself a const reference to the actual system_category_const object created in Boost.System's error_code.cpp file. If it happens that the boost::asio::error::system_category reference is initialized before the boost::system::system_category reference, then boost::asio::error::system_category is a copy of the uninitialized boost::system::system_category reference rather than a reference to the system_category_const object. Attempting to use the category-related functions of an error_code created from the asio system_category enums then triggers an access violation. Of course, if boost::system::system_category is initialized first, then everything is fine. Hopefully that all made sense. Thanks, -Dave

3 2

problems with commit
by Gennadiy Rozental 14 Oct '07

14 Oct '07

I don't seem to be able to commit anything. Here is an error message: svn: Commit failed (details follow): svn: MKACTIVITY of '/svn/boost/!svn/act/3abe1370-7a2b-11dc-b854-c15c66b3799a': 403 Forbidden (http://svn.boost.org) Please advise, Gennadiy

7 10

[build]Library naming not consistent with autolink
by Sean Huang 14 Oct '07

14 Oct '07

This was posted to boost-build 2 weeks agao but I got no reply so I thought I would try the development list. I created a variant based on debug variant: Variant MyDebug : debug : $(MyDebugSettings) ; Unfortunately the names of the libraries generated by boost.build do not have the 'd' key. For example: libboost_python-vc80-mt-g-1_35.lib Autolink expects: libboost_python-vc80-mt-gd-1_35.lib I checked the boost.build code and it seems that the 'd' key is only added when 'debug' variant is specified. This is not consistent to the behavior documented in "Getting Started" and other boost building instructions. Is this a bug or I missing something obvious. Regards, Sean

2 2

[svn][math] dist_extreme_value_incl_test.cpp name too long?
by Nicola Musatti 14 Oct '07

14 Oct '07

Hallo, when I try to commit a merge of trunk onto my bcbboost branch I get an error message stating that dist_extreme_value_incl_test.cpp and tools_toms748_solve_inc_test.cpp are longer than 31 characters. I would think that either these files shouldn't be in trunk or the limit should be lifted. By the way, how did they get there in the first place? Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

2 1

Re: [boost] [GTL] - geometric template library - determininginterest
by Tom Brinkman 14 Oct '07

14 Oct '07

>> "It's time to abandon the traditional, but inaccurate, ideas of >> what it means to be object-oriented. Are you a true encapsulation >> believer? If so, I know you'll embrace non-friend non-member >> functions with the fervor they deserve." >> Think STL! Think STL algorithms! :-) Just for the record, I agree with Joel. Who is still writing old style OO "c++" libraries any more. I'm suprised that it is even being proposed here on boost. Please study boost::gil (from adobe) or boost::spirit to understand what a well written modern c++ library looks like.

1 0

[range] sub_range copy/assign workaround for msvc
by shunsuke 14 Oct '07

14 Oct '07

Hi, http://svn.boost.org/trac/boost/ticket/1284 can be resolved using the attached patch for sub_range.hpp. A similar bug has already been reported to Microsoft so that we can hope the next msvc will fix this bug. Regards, -- Shunsuke Sogame

1 0

Re: [boost] [GTL] - geometric template library - determininginterest
by Simonson, Lucanus J 14 Oct '07

14 Oct '07

>John Femiani wrote: >> Count me as interested in any attempt at a free generic geometry >> library. >> >> Is this purely 'rectilinear' -- I mean, when you say polygons do you >> mean any kind of polygon or only the kinds of polygons formed by the >> union of axis-aligned rectangles? Could I find the intersection of a >> star and a triangle? >> Gyuszi Suto wrote: >The polygons need to be formed by union of axis-aligned rectangles, yes. >In addition to that, GTL supports 45 degree polygons as well. >Can GTL intersect a star and a triangle? If both are limited to >rectilinear or 45 degreee edges, yes, >otherwise no. There is the strong possibility that I will be extending the GTL capabilities beyond 45 degree to allow arbitrary angles with the goal of providing best in class performance with a generic and productive interface. As we are all aware, this leads to the need to provide a mechanism to ensure numerical robustness at considerable cost in runtime. That mechanism would obviously include a generic interface for specifying the internal numerical data type to be used by the algorithm, with a default provided by the library. However, our intention is not to provide a comprehensive geometry library, which would be too broad in scope, but rather a starting point for generic geometry that the community can participate in and extend in the most useful directions. In looking at the recent submissions to boost related to geometry there is a fair amount of overlap with our library, particularly in what I call the basic types such as point2d. The ideal outcome from my point of view is that we all benefit from a synthesis of ideas and craft a boost geometry library together that goes beyond the code we will initially submit and will continue to be enhanced and extended with the participation of the community over time. Lucanus Simonson

17 97