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

date_time test questions
by John Maddock 30 Aug '05

30 Aug '05

Jeff, I've been playing with date_time to try and get it to do the right thing with VC++ when /Zc:wchar_t is *not* specified, and I've come up with a list of questions for you if you don't mind :-) 1) What's the meaning of USE_DATE_TIME_PRE_1_33_FACET_IO? Without it the testtime_wstream.cpp test case fails even with /Zc:wchar_t, this is a source of confusion if you're building the building the tests in your IDE for whatever reason. 2) Without USE_DATE_TIME_PRE_1_33_FACET_IO the testgrep_wstream.cpp test doesn't compile irrespective of the /Zc:wchar_t option: testgreg_wstream.cpp c:\data\boost\develop\boost\boost\date_time\date_facet.hpp(640) : error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const char [35]' (or there is no acceptable conversion) c:\data\boost\develop\boost\boost\date_time\date_facet.hpp(606) : while compiling class-template member function 'std::istreambuf_iterator<_Elem,_Traits> boost::date_time::date_input_facet<date_type,CharT>::get(InItrT &,InItrT &,std::ios_base &,boost::date_time::date_input_facet<date_type,CharT>::duration_type &) const' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, date_type=boost::gregorian::date, CharT=wchar_t, InItrT=std::istreambuf_iterator<wchar_t,std::char_traits<wchar_t>> ] c:\data\boost\develop\boost\boost\date_time\gregorian\gregorian_io.hpp(78) : see reference to class template instantiation 'boost::date_time::date_input_facet<date_type,CharT>' being compiled with [ date_type=boost::gregorian::date, CharT=wchar_t ] c:\data\boost\develop\boost\libs\date_time\test\gregorian\testgreg_wstream.cpp(50) : see reference to function template instantiation 'std::basic_istream<_Elem,_Traits> &boost::gregorian::operator >><wchar_t,std::char_traits<wchar_t>>(std::basic_istream<_Elem,_Traits> &,boost::gregorian::date &)' being compiled with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t> ] 3) Finally there are a lot of places where an unsigned short is written to or read from a stream: unfortunately the dinkumware lib treats these "as if" they were a wide character value, rather than an integer. Casting to unsigned int in these cases would fix that, but it's a horrid cludge, and I don't know what you might think about that! Thanks, John.

3 5

Questions on Serialization
by Daryle Walker 30 Aug '05

30 Aug '05

I just looked over this library (since Robert Ramey mentioned part of it as a solution to a different problem). I'm wondering how (future) Boost library code should implement serialization. Right now, the Serialization library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code? If the latter is the answer, then does: class my_type { friend class ::boost::serialization::access; //... }; need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]? Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info". And I think some of the demo programs could use a sprinkling of "std::auto_ptr". [1] I know there's at least one wacky friend combination that'll interpret a template function as a non-template function instead if you don't take proper precautions. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

7 11

secure asio using ssl
by Dirk Griffioen 30 Aug '05

30 Aug '05

Hi All, We would like to make the remark we created a first version of a secure (ssl/tls) extension to ASIO. It's use should be regarded as an extension to ASIO and configurable with the type of ssl a user has. From the test code (the server): #define HAS_OPENSSL #include <asio.hpp> When the server accepts a connection it then calls handle_accept to secure the socket: void handle_accept(const asio::error& error) { if (!error) { std::cout << "server connected..." << std::endl; // Secure the connection socket_.async_secure( boost::bind(&impl::handle_secure, this, asio::arg::error) ); After that it's a matter of async_recv/send - but the connection now is secure. the variable needed is: asio::tls_socket socket_; Additions to ASIO are: basic_secure_socket.hpp detail/openssl_crypto_initializer.hpp detail/openssl_secure_service.hpp detail/openssl_secure_session.hpp (And (to a lesser extent) the same for GnuTls.) Our question is, can we donate this to (boost::)asio? And if so, how do we approach this? Cheers, Dirk

2 1

[thread library rework] Ready to start
by Ion Gaztañaga 30 Aug '05

30 Aug '05

Hi to all, As previously discussed here, I'm trying to organize a boost thread rework in order to help C++ thread standarization. In this moment, Kevlin Henney is working on a paper to be presented int the next ISO meeting based in his C++ thread work which is available here, in this presentation-paper: http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf This approach proposes futures approach to C++ threads, and also defines lock mechanisms similar to boost::mutex and boost::condition with some changes. I've contacted with Kevlin and he is ready to help as much as he can with the Boost community to develop a good thread proposal. The idea is that we could have a working implementation of the proposal above boost threads. The presentation-paper does not currently cover all the functionality we have, like thread specific storage, barriers and read-write locks neither proposed message-queue, so there is a lot of work to do. There is an active discussion on futures that can be added to this effort since it proposes future-operations that are not incompatible with the proposal, but an extension. We need to keep the thread discussion constructive and effective, although any of us has strong opinions on threading. It would be nice if we could first concentrate in "basic" functionality that does not forbid future proposals. For example, thread cancellation is a hard issue, but it can be added later if the proposal allows to do that. I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions, so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading. There are many areas to cover, but in this post I would like to say that the reworking effort is alive and we need to do some serious work. Like always, ideas are good but work is better, so let's try to avoid extremely long discussions so that we can have C++ threads in the following standard. I'm ready to try to organize a bit the effort and Michael Glassford, mantainer of boost threads, is ready to help, although he has no much time. Anyway, we know there are some good thread implementations out there, and we can take some ideas. And let's try to create a basic, simple, working thread tools but without forbidding extensions in the future. For the moment I've implemented the thread-launching mechanism (threader and joiner classes) described in Kevlin's paper above boost threads. It's in Boost Vault, in thread_ex directory. I plan to add more features detailed in the paper soon (mutexes, conditions, etc...) above boost threads, because it provides a good portable framework. Currently there is no other documentation that Kevlin's presentation, but I will start making some boost documentation in this library, once we start defining more elements. I will try to write some posts regarding concrete issues, like barriers, read-write mutexes or message-queues so that we can focus the work. Obviously if anyone wants to join this effort with ideas, code, organization etc... we can split the work on several issues. Regards, Ion P.D.: I plan to continue Shmem development although, I will have less time to work on it because of this threading work. I plan to upload a new snapshot soon.

4 9

serialization support for std::complex and boost::ublas::vector
by Neal Becker 29 Aug '05

29 Aug '05

Here are a couple of useful additions for serialization. std::complex is pretty trivial, and a no-brainer IMHO. I implemented support for ublas::vector unbounded_array only. Would be nice to do more, but that's all I need at the moment. #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/split_free.hpp> template<typename Archive, typename T> inline void save (Archive &ar, const std::complex<T>& z, const unsigned int) { ar << real (z); ar << imag (z); } template<typename Archive, typename T> inline void load (Archive &ar, std::complex<T>& z, const unsigned int) { T i, r; ar >> r; ar >> i; z = std::complex<T> (r, i); } namespace boost { namespace serialization { template<class Archive, class T> inline void serialize (Archive &ar, std::complex<T>& z, const unsigned int file_version) { boost::serialization::split_free (ar, z, file_version); } } } template<class Archive, class U> inline void save (Archive &ar, const vector &v, const unsigned int) { unsigned int count = v.size(); ar << count; typename vector::const_iterator it = v.begin(); while (count-- > 0) { ar << *it++; } } template<class Archive, class U> inline void load (Archive &ar, vector &v, const unsigned int) { unsigned int count; ar >> count; v.resize (count); typename vector::iterator it = v.begin(); while (count-- > 0) { ar >> *it++; } } namespace boost { namespace serialization { template<class Archive, class U> inline void serialize (Archive &ar, vector& v, const unsigned int file_version) { boost::serialization::split_free (ar, v, file_version); } } }

7 23

Boost regression notification (2005-08-29)
by Douglas Gregor 29 Aug '05

29 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-29T15:06:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 69 failures in 7 libraries: foreach (28) graph (3) iostreams (1) parameter (4) python (2) serialization (30) wave (1) |foreach| array_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin pair_byref: vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: vc-6_5 vc-6_5-stlport vc-7_0 stl_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos 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 |wave| testwave: gcc-3.3.6-linux

1 0

Re: [boost] [regex] missing header inclusion
by François Dumont 29 Aug '05

29 Aug '05

I don't really agree that the patches for the missing headers are fixes for STLport support. They are rather fixes to make boost less Standard library implementation dependant. There are of course not many available Standard library implementations on the market but it is not a reason to make this kind of shortcut :-) Thanks for applying those, I hope I will have soon a final fix for the bjam STLport toolset as for the moment they are not correctly handling: 1. The fact STLport do not support the wrapper mode anymore 2. The modification in the library naming convention. The last issue will then be the lexical_cast problem if you remember. lexical_cast used to not handle correctly configuration with no wchar_t intrinsic support but with wstring granted by the Standard lib. Have anything change lately ? If no shouldn't this kind of config be officially not supported anymore by boost ? I can do a fix to the stlport.hpp file for that if you need it. Bests

2 2

Boost regression notification (2005-08-28)
by Douglas Gregor 28 Aug '05

28 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-28T14:52:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 87 failures in 8 libraries: foreach (37) functional/hash (1) graph (7) iostreams (1) parameter (4) python (6) serialization (30) wave (1) |foreach| array_byref: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin call_once: cw-8_3 cstr_byref: cw-8_3 cstr_byval: cw-8_3 dependent_type: cw-8_3 pair_byref: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 rvalue_const: cw-8_3 rvalue_nonconst: cw-8_3 stl_byref: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos 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 |wave| testwave: gcc-3.3.6-linux

1 0

[date_time] typo in gregorian.html
by Yuval Ronen 28 Aug '05

28 Aug '05

"proleptic" was misspelled as "propleptic". (I'm practicing for "The shortest Boost bug/doc report" competition ;-) )

2 1

RFE 1274707 (Re: [Boost.Thread]: consider removing catch(...)fromthread_proxy)
by Matt Gruenke 28 Aug '05

28 Aug '05

Coincidentally, I just filed an RFE on this very topic (something I'd been meaning to do for a while, but forgot about until I upgraded to 1.33.0). It was suggested to me that I mention it here. Actually, I'd have posted here, in the first place, but it seems I misunderstood the prerequisites for joining this list (I thought it was for code contributors, only). From the archive, I can see this thread has covered most, if not all, of my points. Still, my RFE is probably more cohesive than any single message, on this topic, I've come across in the archives: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7… BTW, I really don't understand this continual talk of a user-supplied/overridable handler function. It still compromises debugging, and without managing to provide anything the user can't already do in the user-supplied threadfunc. (I'm only mentioning this because it's a proposal not addressed in my RFE.) Thanks for considering my views. Matt Gruenke Software Engineer IntelliVid Corp.

1 0