- Boost - lists.boost.org

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

Re: [boost] asio review
by Martin Bonner 21 Dec '05

21 Dec '05

----Original Message---- From: Dirk Moermans [mailto:dirkmoermans@gmail.com] Sent: 20 December 2005 21:27 To: boost(a)lists.boost.org Subject: [boost] asio review > 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. Hmm. I think I disagree. It makes it very clear when a name is part of the library under discussion, and when it is from some other source (such as the sample application, or the standard library). I find that distinction useful. (It's a minor point anyway.) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Patch for mingw-tools.jam
by Janusz Piwowarski 21 Dec '05

21 Dec '05

Hello I'm attaching the patch for mingw-tools.jam. With current version bjam produces code like: g++ ... -L"" first.obj second.obj etc. and linker ends with "undefined reference to `WinMain@16'" message. -- Regards, Janusz

1 0

Re: [boost] [Review] Boost.Logging: formal review
by Richard Glanmark 21 Dec '05

21 Dec '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein > Sent: den 20 december 2005 19:11 > To: boost(a)lists.boost.org > Subject: Re: [boost] [Review] Boost.Logging: formal review > > On 12/20/05, nitin motgi <nitin.motgi(a)gmail.com> wrote: > > > > Question: > > Should the logger concept be able support multi-threaded > environment > > logging. > > > Definitely. What might be a better question however is > should the logger be thread aware by default? > There is probably projects with time constraints who want to optimize for everything, so I think that it should be possible to have loggers/sinks/etc without synhronization in them. But personally, I wouldn't mind if it was aware by default. The content of this e-mail is intended only for the confidential use of the person(s) to whom it is addressed. If the reader of this message is not such a person, you are hereby notified that you have received this communication in error and that reading it, copying it, or in any way disseminating its content to any other person, is strictly prohibited. If you have received this message in error, please notify the author by replying to the e-mail immediately. NeoNet AB and its subsidiaries (NeoNet Securities AB, NeoNet Securities Inc. and NeoNet Technology AB) are unable to exercise control over the content of information contained in transmissions made via the Internet and hereby excludes any warranty as to the quality or accuracy of any information contained in this message and any liability of any kind for the information contained in it, or for its transmission, reception, storage or use in any way whatsoever.

1 0