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

asio review
by Jody Hagins 22 Dec '05

22 Dec '05

I know it was started at 2 weeks. Any chance on an extension?

2 1

[review] asio review
by Brock Peabody 22 Dec '05

22 Dec '05

What is your evaluation of the design? I think the design is good. Asio has an easy to use, modern interface that doesn't compromise on portability or performance. What is your evaluation of the implementation? I haven't inspected the code but it sounds pretty impressive that it selects the optimal library for your platform while maintaining a consistent interface. What is your evaluation of the documentation? I found the tutorial easy enough to follow, but I haven't actually implemented anything with the library yet so I can't comment much on the reference section. What is your evaluation of the potential usefulness of the library? Highly. Everyone wants a cross-platform networking library for C++. Did you try to use the library? With what compiler? Did you have any problems? I compiled and ran some of the examples in the tutorial under VC 7.1 with no problems. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've been following discussions from other reviews. I read the tutorial and glanced through some of the rest of the documentation. Are you knowledgeable about the problem domain? I've written my own cross platform synchronous networking library. I've written countless client and server applications mostly under windows, all synchronous. I have no experience actually doing asynchronous IO. I vote to accept asio. Christopher has done a great job, thanks a lot! I'm excited to start using asynchronous IO. I've got server applications that will be pushing the limit on the number of threads soon. I will happily throw out all of my own networking code in favor of this library if it is accepted. My one small concern is that asio rewrites part of Boost.Thread. In the last couple of versions boost has become so easy to install and link against that I don't see the benefit of a header only implementation. Brock

1 0

who's using boost page
by Max Khesin 22 Dec '05

22 Dec '05

Just a style note: the "who's using" page is not (yet ;) big enough to justify a page with just categories (open source, shrink-wrap, etc). If the categorization is really desired it could be done with anchors within a page. Right now it just adds an extra click, and fragments the list that is more impressive as a single entity. 2c. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Interest in a function object to sort strings more naturally?
by Andy Tompkins 22 Dec '05

22 Dec '05

I have written a function object to sort string alpha-numerically. If a string contains a number, that part is converted to an int and compared as ints. Thus "2" comes before "10". For example the list {a1, a10, a11, a2} would be sorted as {a1, a2, a10, a11} Example use code: { vector<string> my_list; //populate list sort(my_list.begin(), my_list.end(), lt_alphanum<char>()); } The class lt_alphanum splits the strings into sections containing digits, and non-digits. It then compares successive sections such that if two sections both contain digits, they are converted to ints and compared. Otherwise the sections are compared normally. I hope I am being clear. Andy Tompkins

1 0

[MPL.Math] compile-time double macro and printing
by Chris Weed 22 Dec '05

22 Dec '05

Hi, I am trying to simply print a compile-time double using gcc 4.0.0 on Sun. The following prints out : 1.9036e+185 #include <boost/metamath/double.hpp> #include <boost/metamath/double_macros.hpp> #include <iostream> int main() { typedef BOOST_DOUBLE(3.3) D; D d; std::cout << (double)d << std::endl; return 0; } Am I doing something wrong? Chris

4 5

Serious fix needed for the new Boost.Test
by Daryle Walker 22 Dec '05

22 Dec '05

[Maybe I just messed up my XCode #include directories and/or order, or maybe my CVS is fried.... (After writing the post--) please ignore the first sentence and excuse any anger instead.] I've been trying out the auto-test items in Boost.Test, re-doing them when the recent changes were uploaded to CVS. I decided to template-ize a test case I had, going from BOOST_AUTO_TEST_CASE to BOOST_AUTO_TEST_CASE_TEMPLATE with a MPL list of the types I wanted. The complier spit out 10 errors. (I think that's a lot, but for some posters here that's a little.) After using the preprocessor to copy & paste the expansion of BOOST_AUTO_TEST_CASE_TEMPLATE directly into my test file, I narrowed down the errors to two actual problems: 1. The compiler never heard of boost::type 2. And it never heard of boost::unit_test::ut_detail:: template_test_case_gen These can be found in the <boost/type.hpp> (after 10 minutes of searching) and <boost/test/test_case_template.hpp> (after 30 minutes of searching) headers, respectively. Directly #including them in my test file got my testing to work. The simple solution is to make sure to _directly_ include the headers for the items you need to compile.... [Does some checking of the auto-test examples.] The example for BOOST_AUTO_TEST_CASE_TEMPLATE shows that <boost/test/test_case_template.hpp> needs to be manually #included. This is similar to me having to #include <boost/test/floating_point_comparison.hpp> in order to make BOOST_CHECK_CLOSE work. (Is it just me, or does anyone else find the need to manually add #includes to avoid "missing-item" compiler errors within the main testing headers _extremely_ annoying?! I figure that it saves compiling time if the specialized macro is never used, and therefore the auxiliary types aren't needed, but is it worth it?) Well, it seems that I can only complain about the main problem only for <boost/type.hpp>. It seems like the author counted on that header being indirectly #included, and that hope evaporated whenever some other author purged that header (and boost::type) from his/her library. So please directly #include <boost/type.hpp> in <boost/test/unit_test_suite.hpp>. (And if possible, end the "batteries not #included" scenario for the other testing macros & headers.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

asio review
by Dirk Moermans 22 Dec '05

22 Dec '05

Hi, I vote to accept asio into boost. It will still require a lot of work and is by no means finished. My impression is that most issues can be solved incrementally though. The supported features are sufficient (number of platforms + IPV4) to prove that the concepts will work. The documentation is insufficient to understand the interface. I had to read the implementation and the examples. I have spent 8 hours on the review (reading documentation and reading code, I have not written any code using asio). I have experience with ACE, MFC and socket.h (mostly synchronous though, so asio has been an eye-opener for me). This is my first boost-review. -- design: I like the acceptor-connector pattern as used in ACE. It seems that you do use an acceptor class, but did not implement connector classes. It would be nice to have separate classes for connection-establishment and for connection-handling, for both client- and server-side (separation of concerns). I dislike the use of the "services pattern". It might make sense to put the service classes in the details section but they do not belong in the public interface. Such a design would not be appropriate for standardization. I wonder if you can reach the same goals by using concept-checks and some socket_traits classes instead of duplicating every interface. I did read the description in the design section and I am still not convinced that they are a good solution for the stated problems. I think the following code-snippet in the tutorial could be written more elegantly, through an interface change of the deadline_timer: { boost::asio::deadline_timer t; ... t.expires_at(t.expires_at() + boost::posix_time::seconds(1)); } by giving direct access to the time member. t.expiry_date()+=boost::posix_time::seconds(1); For more complex cases or error-checking, some proxy classes could be used. You might want to add swap member-functions implemented in e.g. the address class. You could overload more functions that take a const std::string& parameter with a const char* parameter (e.g. the host constructor). You seem to return a std::string in the some member functions of host and address classes, where you could return a const std::string&. e.g. in host.hpp std::string host::name() const -- implementation Why do you catch exceptions by reference instead of const reference :-) ? Why do you roll out your own threads-implementation and don't rely on boost.threads . It would improve consistency among boost-libraries? The basic demuxer-work class is copy-constructable so that it may be used as a data member in a handler class. It is not assignable. I have never seen this idiom in a correctly designed class, so it would be nice to elaborate a bit on it. Documentation: I would like to see a clear distinction between what is considered a public and private class. A split between basic and advanced topics would ease understanding as well. it would improve readability if you would omit the boost::asio namespace throughout the tutorial. Everybody knows the library-name when reading the tutorial. adding a line "use namespace::boost::asio" in the beginning is sufficient. I did not have time to look in detail into the scatter-gather mechanism, nor the demuxer classes, nor the ssl implementation ... so I am only scratching the surface here. I am impressed by the library and I would use it. Dirk

4 4

[filesystem][QNX6] New filesystem will not compile under QNX6
by Jim Douglas 21 Dec '05

21 Dec '05

This section in operations.cpp fails to compile - BOOST_FILESYSTEM_DECL boost::filesystem::system_error_type remove_api( const std::string & ph ) { # if defined(__QNXNTO__) || (defined(__MSL__) && (defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__))) // Some Metrowerks C library versions fail on directories because of a // known Metrowerks coding error in ::remove. Workaround is to call // rmdir() or unlink() as indicated. // Same bug also reported for QNX, with the same fix. if ( (is_directory( ph ) ? ::rmdir( ph.string().c_str() ) // **ERROR** : ::unlink( ph.string().c_str() )) != 0 ) // **ERROR** # else 'ph' is now std::string (it was a locally defined type 'path') and does not have a member function 'string()'. I suspect this is a hangover from the previous implementation. Should those lines perhaps now be - if ( (is_directory( ph ) ? ::rmdir( ph.c_str() ) : ::unlink( ph.c_str() )) != 0 ) ********************************************************************* This section near the end of operations.cpp completely defeats QNX6 as struct dirent does not have a member called d_type. # ifdef BOOST_FILESYSTEM_STATUS_CACHE ... if ( entry.d_type == DT_DIR ) sf = symlink_sf = fs::directory_flag; else if ( entry.d_type == DT_REG ) sf = symlink_sf = fs::file_flag; else if ( entry.d_type == DT_LNK ) { sf = 0; symlink_sf = fs::symlink_flag; } else sf = symlink_sf = fs::other_flag; # else QNX does embody tests to determine the file (hence directory) type but they are based on a call to "stat( const char *path, struct stat buf )" and inspecting buf.st_mode with pre-defined macros e.g "S_IFDIR( buf.st_mode )" returns 1 if 'path' is a directory. This may be more portable? ************************************************************************ I am experiencing a blizzard of "comparison between signed and unsigned" warnings originating from path.hpp. They start at line 768 and they occur each time "size" is compared against a constant value. Sorry, I am not sure how to get rid of these warnings (in a portable way), but it would be a relief if they were to disappear :-) HTH Jim Douglas

2 2

[filesystem] directory_iterator may cause buffer overflow
by Takeshi Mouri 21 Dec '05

21 Dec '05

Hello, On boost 1.33.0 or later, class directory_iterator is implemented by readdir_r() for some POSIX platform. readdir_r() require a memory buffer which is larger than offsetof(dirent,d_name) + pathconf(dirname,_PC_NAME_MAX) + 1. But in operations.cpp, the size is sizeof(dirent). On some platform such as Linux, FreeBSD and Cygwin, a size of d_name member is 256. This is a enough size in many cases. OTOH, the size on Solaris and BeOS is 1. Therefore directory_iterator always cause buffer overflow. See also: http://thread.gmane.org/gmane.comp.lib.boost.devel/115104 http://womble.decadentplace.org.uk/readdir_r-advisory.html In the article above, calling readdir_r() after pathconf() has race condition, so it is necessary to secure the size that seems to be perhaps enough. Possibly, this problem might cause http://thread.gmane.org/gmane.comp.lib.boost.devel/135820 Regards, Takeshi Mouri

2 3

serialization: class version
by Mikhail Kubzin 21 Dec '05

21 Dec '05

I use boost serialisation in my project and I need to serialise a vector of pointers (boost::shared_ptr) to a base class. The base class is declared in one dll in the following way: A.h: namespace boost { namespace serialization { class access; } } class A {... }; A.cpp #include <... boost serialization headers .. > BOOST_CLASS_VERSION(A, 1) .... In another dll I declare class B derived from A declared and implemented in the same manner ( .h files do not include boost serialization headers). The problem is that inside the sirialisation (save/load) function of the derived class I get correct file_version value while in the serialisation function of the base class file_version is 0. I call serialization function of the base class as advised in the documentation: ar & boost::serialization::base_object<A>(*this); However, if I insert BOOST_CLASS_VERSION(A, 1) into B.cpp then file_version in A's serialisation function is initialised properly. It is a pain to update the version of the base class in all derived classes from one side, it is also impractical to include all boost headers and class version information into .h files since the compilation time grows dramatically and the size of the executables increases several times. Any thoughts and suggestions are welcome! Thank you in advance, Mikhail

3 7