- Boost - lists.boost.org

[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

Filesystem update breaks quickbook?
by John Maddock 20 Dec '05

20 Dec '05

Since the filesystem update I'm seeing: quickbook.quickbook-to-boostbook ../../../bin.v2/libs/math/doc/gcc/debug/math.xml Error: filesystem::default_name_check_writable when trying to build quickbook docs from cygwin. Looks like quickbook is calling a deprecated filesystem function? Thanks, John.

2 1

updating the references page
by Esther Schindler 20 Dec '05

20 Dec '05

>> Informit has several articles related to Boost, many of which are >> much newer than listed on the boost reference page. To whom should I >> send a list? > > You can send the list of references to this mailing list. How the Boost Bind Library Can Improve Your C++ Programs By Björn Karlsson. Aug 26, 2005. The existence of a generalized C++ binder is a tremendously useful tool when it comes to writing terse, coherent code. It reduces the number of small function objects created for adapting functions/ function objects, and combinations of functions. Although the Standard Library already offers a small part of the functionality found in Boost.Bind, significant improvements can make Boost.Bind the better choice. In this sample chapter from Beyond the C++ Standard Library, you'll learn about Boost.Bind's powerful functional composition features, which provide programmers with great power without negative effects on maintenance. http://www.informit.com/articles/article.asp?p=412354 Adding an Easy File Save and File Load Mechanism to Your C++ Program By Jeff Cogswell. Jul 1, 2005. Why waste your time figuring out an algorithm for storing things in a file? And why spend time debugging the code? Let the Boost library do it for you. Saving your data to your own custom-made file formats is easy with the help of the Boost serialization templates. Jeff Cogswell shows you how to save the data and read it back in with ease. http://www.informit.com/articles/article.asp?p=398702 An In-Depth Look at Metafunctions in C++ By Aleksey Gurtovoy, David Abrahams. From the Book -- C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond Apr 1, 2005. This chapter looks at a practical example from science and engineering that can find applications in almost any numerical code. Along the way, you'll learn some important new concepts and get a taste of metaprogramming at a high level using the MPL. http://www.informit.com/articles/article.asp?p=375705 --Esther P.S. I'm happy to assign articles about boost (or about anything to do with C++). And yes, I do pay for articles. :-) Contact me privately if you're interested.

2 1

Boost.Test: update 1
by Gennadiy Rozental 20 Dec '05

20 Dec '05

Hi everybody I finished the first update to the 1.33 release of Boost.Test. This update includes several bug fixes and series on new features. Once this updates settles for next update I will invest my efforts exclusively in documentation making it up to date and more convenient to use. The last update should finalize runtime parameter framework and testing by name feature. I don't think most of below modification require any (semi-)formal review, but I would really appreciate any comments and reviews for new features. Here is an itemized list of modifications/innovations included in update 1 (in no particular order): * Autolinking support is implemented To employ autolinking with Program Execution Monitor and Test Execution Monitor one need to include new headers test_exec_monitor.hpp and prg_exec_monitor.hpp * DLL support is implemented Now it's possible to build Boost.Test as DLL. In addition this allows to use Boost.Test from within dll. See separate post on this topic for more details. * Auto-registration test tree facilities integration Starting next release auto registration facilities becoming a natural part of primary Boost.Test interface. Header auto_unit_test is deprecated and unit_test.hpp is now includes everything. All examples for unit test framework are reworked to advertise these facilities as easiest way to facilitate testing. I will post a separate message giving a short introduction for all self-registration facilities including new ones: BOOST_FIXTURE_TEST_SUITE, BOOST_GLOBAL_FIXTURE. * Mix of auto registered and explicitly registered test cases allowed Now within the same test module one may have both auto registered and explicitly registered test cases. * Interaction based testing is introduced This branch of testing was not covered by Boost.Test before. See separate post with more detailed on the topic. * Exception safety testing is introduced Based on interaction based testing these facilities mostly useful for generic components testing. See separate post with more details on this topic. * Existing init API twicks In existing API init function for unit test usually look like this: test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* test = BOOST_TEST_SUITE( "abc" ); .... return test; } If this function returns NULL test tree treated as non initialized. With this update master test suite is now always exist and test tree treated as non initialized if it doesn't have any test cases. NULL is not treated as failure anymore. To report initialization failure with existent API one should use an exceptions (preferably std::logic_error). It's recommended for init function to look like this: test_suite init_unit_test_suite( int argc, char* argv[] ) { framework::master_test_suite().p_name.value = "abc"; .... return 0; } * Alternative init API introduced There several drawbacks in existent init API for unit test: - argc. argv soon there wouldn't be the only source for runtime parameters (config file, environment, and other source one would be able to use) - it's unsafe: if user doesn't allocate resulting test suite in heap coredump will occur - there is no way to indicate now initialization failure without exceptions. NULL results could mean that we failed to initialize or that we don't have any non-auto registered test cases I've introduced an alternative init API: bool init_unit_test(); Here false return value designate init failure. TO access runtime parameters one would use special (separate) API. To employ this alternative API one should define BOOST_TEST_ALTERNATIVE_INIT_API both during library and test compilation. This API is required for any user willing to use DLL build of the library. * framework::deregister_observer is introduced Now one could use temporary observers * observers priority is introduced Framework invokes a test observers callback in order of observer priority * unit_test_log API slightly simplified File and line of log entry passed as part of entry begin processing. * BOOST_MESSAGE and BOOST_CHECKPOINT are deprecated I found these names too generic for testing framework. New names are BOOST_TEST_MESSAGE and BOOST_TEST_CHECKPOINT. In addition I moved this faculties in their proper place: from Test Tools to Unit Test Log since they only responsible for logging. * BOOST_TEST_PASSPOINT() is introduced In addition to BOOST_TEST_CHECKPOINT which require a message to mark a check point this new facility mark a place test is passing through without any message (just file,line - being there). All Test Tools now invoke BOOST_TEST_PASSPOINT() before tool is started. This allows to detect the failure point in case if exception or crash more effectively (I would use the same name BOOST_TEST_CHECKPOIINT, but this would require variable num of args in macro) * BOOST_<level>_CLOSE_FRACTION This update introduce an ability to test on closeness based on either percentage driven tolerance or fraction driven one. This new tool will test on closeness based on fraction tolerance. (Note: The second request in the same domain: printing actual difference in fractions is not implemented. It's not clear what needs to be printed) * Test collector and Test reporter are modified to report proper number of test cases that gets aborted in cases of fatal failure * output_test_stream now allows matching in binary mode * framework::master_test_suite() interface is introduced for access to the test tree master test suite. * framework::test_unit_aborted() modified to include a test_unit that is being aborted Regards, Gennadiy

3 14

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

20 Dec '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein > Sent: den 19 december 2005 16:41 > To: boost(a)lists.boost.org; Gennadiy Rozental; John Torjo > Subject: Re: [boost] [Review] Boost.Logging: formal review > > I personally prefer the all-enclosed macro style for this > reason as well as others. But I think one of Gennadiy's > points is that the primary interface to the Log should not be > defined in terms of macros. A standard set of macros can be > provided by the Boost.Log implementation for the sake of > convenience and casual use. But there should be a well > documented public interface that users with more complex > requirements can use to write their own logging macros, in > whichever style they prefer. Yes, this is a must. The "basic" interface should be quite minimalistic and simple to use. The interface should not have any domain specific nor "too much preferred logging styles". For instance, I don't think that Gennadiy's entry keywords belong directly in this interface. There would always be a domain or user that wants specific details to be added, details that might not be a concern at all in my application. However, an entry keyword should still be very simple to "implement/use" on top of the basic interface. > I don't think it makes sense to require a user to have > separate loggers to handle e.g. DEBUG, WARNING, and ERROR > levels. I also don't think it makes sense to require > separate logs for different logging keywords (I think thats > the term Gennadiy used). The user may use separate loggers > for each of these separate logical channels, but it should > not be a requirement. I'm not saying that this is required. I'm saying that it should be possible. I guess what I am saying is (like my paragraph above) style should be left to programmers and not be enforced. Especially, a logger must be able to have zero, one, or several, sinks (appenders) attached to it, and I think that that is something that you have addressed later in your post. > IMO it is very important for an administrator/programmer of a > system to > > be able to enable/disable logs, know what loggers and > appenders exists > > and be able to configure said entities. > > > But if the programmer has to provide a separate logger for > each logging level and conceptual channel of log information, > each of which is configured independently, isn't this > management problem far worse? I suppose it could be a management nightmare and if this is the case, one would need to have fewer loggers (or one if you like), in which case a logger is not tied to a specific log level (e.g.). And in this case, the programmer would use whater log functions deemed necessary to make the job simple(r). However, I'm not sure such functions should be part of the logger interface, but could be functions/macros that depend on the loggers and not vice versa in order to minimize the logger's interface. > If filter is only done on a per log statement, how do you > even know as a > > administrator of a system what log filters exists? Which filter > > criteria should be enabled and which filter criteria should > be disabled? > > > > Can you expound a bit on what you mean by this? Well, with a development team of 20+ people I might want to tightly control what is being logged and that all "important" log messages are sent to a specific sink. If entry keywords are used, for instance, I'm quite sure that the number of keywords in use probably would explode. Which of these are important and which are not so important? Which are warnings, which messages should be filtered and so on. Perhaps I want to enable all log messages with a the specific entry keyword "my_special_condition", but what happens when a programer misspelled this keyword. This could also turn into a management nightmare IMO (unless I'm totally misunderstanding the concept). If a systems architect would like to send specific log message to specific sinks, wouldn't this be a management problem as well? I would still have to setup and configure loggers/filter/sink combinations. I'm not sure there is a "better" solution to this general problem. It's a difficult problem and should be treated as such. IMO, there must be several ways to solve the issue, chosen by programmers and teams that suits their specific "design" choice. This boils down to, IMO, to simplistic loggers and sinks, and a more "complex" extensible layer on top of this, perhaps provided by the library for common situations.. > I see the central concepts as: > > Entry (or Message): the set of information that makes up a > single message to log. Might include a "level" (e.g. debug, > info, warning, error), a "category" (e.g. arguments, > program_flow, etc), a "keyword" (e.g. "Network", "UI", "Disk > Cache", etc) and of course a text string. Could be more or it could be less in specific situations. But other than that I agree with you. > Filter: determines whether or not an Entry should be logged. > Probably implemented as a relatively simple functor. > Sink: ultimate destination for Entries. Implementations for > wirting to files, system log facilities, etc can be provided. > Log: provides logging methods. Implements the Filter concept > and contains zero or more Sinks which are the targets of > Entries for which the Filter returns true. I aggree with you on a conceptual level. However, the Filter concept shouldn't be part of, IMO, the logger. Or if it is, at least, there should be an alternative interface in the logger, or possibly, the filtering concept should be very simple if I don't want entry keywords and such. Fundementally, I think that writing log statements and filtering log statements are two different and orthogonal concepts. Filtering is an efficiency decision at the conceptual level. With that I mean if we had infinite computing power (which we don't) filtering wouldn't be necessary at all when sending log entries to sinks. Filtering is however something the target audience does when looking for, or at, log statements. That is, with infinite computing power, the filtering mechanism could be done at the time when administrators/programmers are looking/searching logs. But since we don't have infinite computing power, log entries need to be filter before sending them to sinks (I suppose one could argue that there are other reasons for filtering before sending entries to sinks; but I don't see a difference). So the interface for enabling/disabling log entries should be a fundemental concept to a logging library and obviously as well designed as the actual log entry interface. Especially, wether to send a log entry to a sink should incur minimal overhead, or else risk efficiency even if the log statement are not sent to the sinks. This is especially true if programers use many log statements. IMO at the most fundemental layer, a logger is either enabled or disabled. If it is enabled, log entries are sent to its attached sinks. Filtering should be implemented on top of loggers. The filtering concept determines wether to send the log entry to the logger or not. > I've been sketching up a very simple implementation of some > of these ideas in my spare time. Is there interest in > fleshing these ideas out more fully on or off-list? Cool! Yes, very interested (I have myself an implementation... who doesn't ;-)) /Richard 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.

4 3