- Boost - lists.boost.org

Re: [boost] GUI coordinate units (Was: GUI foundations)
by Schrom, Brian T 04 Oct '05

04 Oct '05

>> Of course, this requires a completely vector-graphics-based GUI, which >> is still the exception. > > And that is one area I'd love to work on! This will require a new way of thinking > and quite a bit of work but I think it's the right way to go. [snip] ... > are implemented on the basis of Anti-Grain Geometry, so that, all the rendering > infrastructure is multi-platform. That's my definition of beautiful! I am also interested in pursuing this type of GUI. This would meet my needs more completely than current widgetlike toolkits.

1 0

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

04 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-04T05:00:22Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 120 failures in 9 libraries: concept_check (12) graph (2) mpl (1) parameter (11) serialization (30) spirit (8) thread (4) tuple (1) typeof (51) |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 vc-7_1 |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 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 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 |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 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 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 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

1 0

Re: [boost] [mpl] sequence_wrapper change to handle enums
by Aleksey Gurtovoy 04 Oct '05

04 Oct '05

Larry Evans writes: > OTOH, I was thinking that maybe preprocess.cmd could just contain: > > gcc -E -C -P -I%(boost_root) "-D > BOOST_USER_CONFIG=<%(boost_root)/libs/mpl/preprocessed/include/%(mode)/u > ser.hpp>" > -D BOOST_MPL_CFG_NO_OWN_PP_PRIMITIVES %(file) >%(file_path) > > which could be read into a variable, compile_cmd, which would then be > used as: > > os.system( compile_cmd % { 'boost_root':boost_root, 'mode':mode, > 'file':file, 'file_path':file_path } ) > > does that sound OK? It would have to be '... -I%(boost_root)s' and similarly for other arguments, but otherwise that's an excellent idea! It eliminates the need for having two different 'preprocess' files. OK, the above is in the CVS now. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

[typeof] More strange failures on como
by Arkadiy Vertleyb 04 Oct '05

04 Oct '05

A typeof test case defined as: [ run odr1.cpp odr2.cpp : : : <define>BOOST_TYPEOF_COMPLIANT : odr_emulation ] is failing in a way that looks like como didn't even start to compile odr1.cpp: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output/ Bronek-bin-boost-libs-typeof-test-odr_emulation-test-como-4_3_3-vc7_1-debug. html There is the compiler output for odr2.cpp only, and then linker output that claims there is no odr1.obj. GCC, VC7.1 appear to be fine with this test... Any insights on the cause of the problem? Thanks, Arkadiy

1 0

[multi_array] range-checked element access
by Adrian Sheppard 04 Oct '05

04 Oct '05

Is there a good reason why multi_array, and perhaps other boost containers with an unchecked operator [], don't provide a range-checked element access function, like std::vector::at()? Perhaps I'm missing something obvious?. regards adrian sheppard

1 0

Serialization
by Stefan 04 Oct '05

04 Oct '05

Hi folks, I just tested the boost serialization library. I have a question: I need to serialize my objects and then transfer them via tcp connection. Right now I write them into a file like in the examples and then open this file again read it with getc into an array, then send it. Is there an easier way without writing to a file, since this would be a problem with my performance. This is what I do right now: const GPSData g(10,10,10.0); std::ostream teststream; std::ofstream ofs("filename"); boost::archive::text_oarchive oa(teststream); oa << g; ofs.close(); char serializedobj[100], c; FILE * fp; fp=fopen("filename", "rw"); int cnt=0; while((c=getc(fp)) !=EOF) { serializedobj[cnt]=c; cnt++; } serializedobj[cnt]='\0'; tcpclient->send(serializedobj); Thanks in advance, Stefan ___________________________________________________________ Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx

2 1

Re: [boost] [mpl] bug in mpl::at?
by Aleksey Gurtovoy 04 Oct '05

04 Oct '05

Geoffrey Romer writes: > Along the same lines, I'm now having similar trouble with the > 2-argument version of insert. Is this a known issue? Unlikely, but it's hard to say without seeing the code and the error. > > Fortunately, there's a pretty trivial workaround for this one... Given that a test case for the two-argument 'insert' form is present in both 'map' and 'set' tests (http://tinyurl.com/cuqjl) I suspect that you are doing something wrong. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[mpl] bug in mpl::at?
by Geoffrey Romer 04 Oct '05

04 Oct '05

I asked this on boost-users with no luck, so I figured I'd kick it up to the experts: I'm trying to use the 3-argument version of the mpl::at metafunction, as described in the on-line manual, but I'm getting a compile error (using gcc 4.0.2): --- error: wrong number of template arguments (3, should be 2) /usr/include/boost/mpl/at_fwd.hpp:20: error: provided for 'template<class Sequence, class N> struct boost::mpl::at' --- Looking at at.hpp, at_fwd.hpp, and aux_/at_fwd.hpp, I don't see any sign of a 3-argument version of at; everything seems to be defined in terms of a 2-argument template. Am I doing something wrong, or is this a bug?

4 6

[asio] init acceptor to reuse_address?
by BRIDGES Dick 03 Oct '05

03 Oct '05

I submitted this question to boost-users Friday but it occurred to me that it should have been posted here. Apologies if I've erred. <original> I created a server something like this: handle_accept(){ do_the_right_thing(); } Class Foo { socket_acceptor acceptor_; Public: Foo(demuxer& d) : acceptor_( d, ipv4::tcp::endpoint(2525)){} Example(demuxer& d) { stream_socket* p = new stream_socket(d); acceptor_.async_accept(p, handle_accept); } } Everything works fine except when I (1) connect a client; (2) ^C the server; (3) try to restart the server - which, as expected, yields "Address already in use". Mumbling something about defaulting modern socket libraries to SO_REUSEADDR, I started trying to figure out where to call set_option(stream_socket::reuse_address(true)) - and can't work it out. I've set_option() on sockets and the acceptor but can't make the acceptor reuse the address as long as the connection that was established is still in TIME_WAIT. Do you have an example that shows how this can be done? </original> Regards, Dick Bridges

2 3

[Solved]:Serialization
by Stefan 03 Oct '05

03 Oct '05

Sorry guys, forget my earlier posting. I just looked at the c++ reference and saw, that there is a ostringstream, which is what I needed, I haven't done to much c++ yet, didn't know there was such a stream class :-( Cheers Stefan ___________________________________________________________ Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx

1 0