October 2005 - Boost - lists.preview.boost.org

Boost regression notification (2005-10-05 [HEAD])
by Douglas Gregor 05 Oct '05

05 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-05T05:00:23Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. utility/enable_if Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 137 failures in 13 libraries: concept_check (13) config (2) foreach (1) functional/hash (1) graph (2) mpl (1) parameter (13) serialization (36) spirit (8) thread (4) tuple (1) typeof (54) utility/enable_if (1) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 |config| config_test: vc-7_1 limits_test: vc-7_1 |foreach| user_defined: msvc |functional/hash| container_fwd_test: msvc |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 msvc function_ptr_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ref_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 lvalue_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 msvc member_function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 noncopyable_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 odr_native: intel-win32-9_0 std_emulation: cw-9_4 std_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_dependent_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_enum_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_multiword_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_tpl_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 msvc template_type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 |utility/enable_if| namespace_disambiguation: vc-7_1

1 0

graphviz
by Reed Kotler 05 Oct '05

05 Oct '05

I am working on getting a new compiler to work with BOOST. I'm getting an error compilng graphviz_graph_parser.cppI am getting that "free" is undefined and the error seems legitmate but there are apparently other compilers failing due to this same problem so maybe there is something tricky here.free is wrapped so it's in std but it is not visible at the point in the code.

2 1

Fwd from ms.p.vc.l: Boost with VC6
by Jeff Flinn 05 Oct '05

05 Oct '05

Just an FYI related to first time boost users efforts at installation. I'm forwarding this from microsoft.public.vc.language. I've answered this to the best of my abilities in that thread, and suggested that the OP join the boost.user list. Jeff "andré m.a" <a.m.a(a)videotron.ca> wrote in message news:%2%_e.4643$f_3.44986@weber.videotron.net... > hi there. > > It's been suggested my many that i use Boost libraries. > So i went to boost.org and downloaded the win32 files. > Unziped the boost folder into : > C:\Program Files\Microsoft Visual Studio\VC98\Include\ > > even added the boost directory in the IDE using : > tools>options>directories... > > I read the docs at boost and it says that for VC6 the files > (hpp) should work as is, but every time i try to compile > something im missing static libraries like : > libboost_program_options-vc6-sgd-1_33.lib is missing. > > Wich even google in its vast DB entries is unable to > produce a single hit for. > > Then again MSDN is discouraging using VC6 and suggest > i spend a lot of money for a .Net :-} > ( very amusing ) > > Any tips would be gigantically helpfull.

2 1

Re: [boost] GUI coordinate units (Was: GUI foundations)
by Martin Bonner 05 Oct '05

05 Oct '05

----Original Message---- From: Stefan Seefeld [mailto:seefeld@sympatico.ca] Sent: 04 October 2005 14:35 To: boost(a)lists.boost.org Subject: Re: [boost] GUI coordinate units (Was: GUI foundations) > Sizes are usually given in resolution-dependent coordinates (i.e. > pixels). If you change resolution, you typically don't do that to > expose more detail, but to make your desktop 'bigger' (by making > text, widgets, etc. smaller). This seems to be a common view among developers. I can only assume they are all still young with excellent eyesight. When I moved from 800x600 to 1024x768 what I really wanted was less fuzzy letters (not more letters). I moved from 1024x768 to 1280x1024 because I got given a 17" LCD monitor. Windows-XP doesn't make a bad fist of scaling everything back again to a reasonable size, but a lot of GUIs get a bit messed up because people have done everything in pixels rather than scalable graphics. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

5 6

[Boost-bugs] [ boost-Bugs-1313543 ] range, VC 7.1, compile error.
by SourceForge.net 05 Oct '05

05 Oct '05

Bugs item #1313543, was opened at 2005-10-05 16:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1313543&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Shandar (sergey_shandar) Assigned to: Nobody/Anonymous (nobody) Summary: range, VC 7.1, compile error. Initial Comment: Compiler: VC 7.1 Example: --------- #include <boost/range/iterator.hpp> template<class Container> typename boost::range_iterator<const Container>::type begin(const Container &X) { return 0; } int main() { char a[3]; int b = begin(a); return 0; } --------- The compile-time error message is --------- c:\Boost\include\boost-1_33\boost\range\iterator.hpp(37) : error C2825: 'C::iterator': cannot form a qualified name main.cpp(12) : see reference to class template instantiation 'boost::range_iterator<C>' being compiled with [ C=char [3] ] --------- It's a VC 7.1 bug but there is possibility to work around. Instead of using C::iterator by default (existing code shown below): --------- namespace boost { namespace detail { template< typename C > struct range_iterator { typedef BOOST_DEDUCED_TYPENAME C::iterator type; }; } } --------- Use C::iterator only if C is a class. Code showing the possible implementation is shown below --------- namespace boost { namespace detail { template< typename C, bool IsClass> struct range_iterator { typedef void type; }; template< typename C> struct range_iterator<C, true> { typedef BOOST_DEDUCED_TYPENAME C::iterator type; }; } } --------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1313543&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Feature Requests-1313447 ] Socket C++ library
by SourceForge.net 05 Oct '05

05 Oct '05

Feature Requests item #1313447, was opened at 2005-10-04 20:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1313447&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Socket C++ library Initial Comment: Without a socket library, C++ can't be on the net. Hope boost can do something ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1313447&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

gui - previous discussions
by rasmus ekman 05 Oct '05

05 Oct '05

Hi, Some time ago I collected a pageful of links to the discussions on gui design in the mail archives. I just uploaded the page as is to the wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostDevelGu… - also I very impolitely linked to it at the *top* of the wiki BoostGUI page. I thought it might be one resource for future discussions - it feels some of the threads cover a lot of the same ground. Uh, rephrase to a more positive note: There's quite a bit there to learn or at least consider if you're thinking about the design of a modern gui toolkit! Regards, re

1 0

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 04 Oct '05

04 Oct '05

In-Reply-To: <200509282055.j8SKtbXI017230(a)shannonhoon.balstatdev.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > if (!e) > { > BOOST_ASSERT(false); > __assume(false); > } > > The optimizer can't elide the entire else clause because > BOOST_ASSERT(false) is in it. Do you agree that if the code was: int x = 0; if (!e) { ++x; __assume(false); } cout << x; then the compiler can elide the increment? At this stage I am trying to convince myself that you understand the point I was making, whether or not you agree with how it applies to BOOST_ASSERT. __assume(false) can have retrospective effects. -- Dave Harris, Nottingham, UK.

5 9

Re: [boost] Are there any interest in a pimpl library?
by Martin Bonner 04 Oct '05

04 Oct '05

----Original Message---- From: Asger Mangaard [mailto:tmb@tmbproductions.com] Sent: 27 September 2005 16:13 To: boost(a)lists.boost.org Subject: Re: [boost] Are there any interest in a pimpl library? >> Could you be more specific as to what functionality such a library >> would supply? If you already have an implementation then an example >> of it's use would be interesting. That was my immediate reaction too. >> It is my understanding that the pimpl idiom is fairly simple yet >> also class specific. I currently implement it like this: [snip classic pimpl idiom] > The only thing my library does is to initialize the forward declared > class, using heap or static memory through policies. Also, provides an > easy way of accessing the data. > > Eg. > > .hpp > > boost::pimpl<struct CMyData> m_MyData; > > .cpp > > struct CMyData > { > CMyData() > : m_Integer(0) > { > } > int m_Integer; > }; > > /// Data access > m_MyData->m_Integer = 2341; > > The CMyData will be initialized the first time its data members are > accessed. That means each use of m_MyData operator ->() has got to check whether the structure is initialized or not, and initialize it if so. Isn't it much easier to initialize the pimpl struct in the constructor of the outer class? I also don't see how much easier it can get to access the data than to write: pimpl->m_Integer -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

7 27

Re: [boost] [asio] init acceptor to reuse_address?
by BRIDGES Dick 04 Oct '05

04 Oct '05

Hi Chris. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of > Christopher Kohlhoff > Sent: Monday, October 03, 2005 3:01 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [asio] init acceptor to reuse_address? > > > Hi Dick, > > --- BRIDGES Dick <Dick.Bridges(a)us.thalesgroup.com> wrote: [snip] > > Mumbling something about defaulting modern socket libraries > > to SO_REUSEADDR, > > Do you think I should change the default to set SO_REUSEADDR to true? > At the moment I leave all options to default to whatever the OS > provides. Is there a good reason why all OSes (that I know of) have it > default to false I wonder? Or is it just historical? No. SO_REUSEADDR does increase the attack surface. Not a lot and less now than in the past but IMHO there's no point in helping the bad guys even a little bit if it's not required. Besides, I doubt all that many people would find it useful. My mumbling was aimed more toward myself than anything else - I have written a fair amount of "server" code and should have developed better habits by now. ;) [snip] > > asio::ipv4::tcp::endpoint endpoint(port); > acceptor_.open(endpoint.protocol()); > acceptor_.set_option(asio::socket_acceptor::reuse_address(true)); > acceptor_.bind(endpoint); > acceptor_.listen(); > acceptor_.async_accept(new_connection_->socket(), > boost::bind(&server::handle_accept, this, > asio::placeholders::error)); > > (From the new http example I've written: > http://cvs.sourceforge.net/viewcvs.py/asio/asio/src/examples/ > http/server/server.cpp?rev=1.1&view=markup). Hmmm. The copy of the library I downloaded on 14 September doesn't have socket_acceptor::reuse_address and linux.softpedia.com says the last update was 5 September. I used stream_socket::reuse_address instead and that worked. Is there a newer version of the library somewhere else? Other than that one substitution, this fixed the problem. I would like to see this initialization code pushed back down into the acceptor. Maybe something along the lines of an "option_policy", but I can't come up with anything to suggest that isn't more trouble than it's worth. Thanks - *AGAIN* - for the help. Regards, Dick

2 1