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

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

[asio] + [test] problem with asio used together with boost.test program exec monitor
by Andreas Willich 20 Dec '05

20 Dec '05

Hi Boost- Devs I noticed a problem with the use of asio together with the test program exec monitor. If you include the prg_exec_monitor.hpp before the asio.hpp the boost.test lib includes winsock.h. In the next step asio includes the winsock2.h. The result is that there are many redefinition errors like these: d:\librarys\boost\include\boost-1_33\boost\asio\detail\socket_types.hpp(41) : warning C4005: 'FD_SETSIZE' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(51) : see previous definition of 'FD_SETSIZE' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(112) : error C2011: 'fd_set' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(54) : see declaration of 'fd_set' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(147) : warning C4005: 'FD_SET' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(88) : see previous definition of 'FD_SET' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(156) : error C2011: 'timeval' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(97) : see declaration of 'timeval' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(212) : error C2011: 'hostent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(153) : see declaration of 'hostent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(225) : error C2011: 'netent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(166) : see declaration of 'netent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(232) : error C2011: 'servent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(173) : see declaration of 'servent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(244) : error C2011: 'protoent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(185) : see declaration of 'protoent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(400) : error C2011: 'sockaddr_in' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(321) : see declaration of 'sockaddr_in' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(410) : error C2011: 'WSAData' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(331) : see declaration of 'WSAData' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(470) : warning C4005: 'SO_DONTLINGER' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(411) : see previous definition of 'SO_DONTLINGER' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(527) : warning C4005: 'AF_IPX' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(469) : see previous definition of 'AF_IPX' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(555) : warning C4005: 'AF_MAX' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(488) : see previous definition of 'AF_MAX' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(561) : error C2011: 'sockaddr' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(494) : see declaration of 'sockaddr' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(601) : error C2011: 'sockproto' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(503) : see declaration of 'sockproto' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(640) : error C2011: 'linger' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(540) : see declaration of 'linger' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(653) : warning C4005: 'SOMAXCONN' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(553) : see previous definition of 'SOMAXCONN' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(679) : warning C4005: 'FD_READ' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(571) : see previous definition of 'FD_READ' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(682) : warning C4005: 'FD_WRITE' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(572) : see previous definition of 'FD_WRITE' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(685) : warning C4005: 'FD_OOB' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(573) : see previous definition of 'FD_OOB' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(688) : warning C4005: 'FD_ACCEPT' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(574) : see previous definition of 'FD_ACCEPT' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(691) : warning C4005: 'FD_CONNECT' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(575) : see previous definition of 'FD_CONNECT' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(694) : warning C4005: 'FD_CLOSE' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(576) : see previous definition of 'FD_CLOSE' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1626) : error C2375: 'accept' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(744) : see declaration of 'accept' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1647) : error C2375: 'bind' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(749) : see declaration of 'bind' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1666) : error C2375: 'closesocket' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(754) : see declaration of 'closesocket' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1685) : error C2375: 'connect' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(756) : see declaration of 'connect' ... Perhaps someone can add a notice about this situation to the docs. Andreas

3 4

typeof tests hanging tru64cxx71-006
by Arkadiy Vertleyb 20 Dec '05

20 Dec '05

Rene Rivera wrote: > Markus Schöpflin wrote: > > Hello, > > > > is it possible to disable specific tests for certain compiler/platform > > combinations? > > Yes. Add a <build>no to the requirements of the test. > > > I have the problem that currently the typeof tests are hanging CXX 6.5 on > > Tru64, the compiler just compiles forever. > > For the HP TestDrive toolset it would be "<tru64cxx71-006><*><build>no". > If you need to do some more complicated matching logic to determine when > to add the no-build option you'll need to use a requirement rule. See > the serialization test Jamfiles for an example. Sorry for the late response. Is this still a problem? Should I disable the typeof tests for this tool? Regards, Arkadiy

2 3

[QNX6] [1.33.1] Provisional "unofficial branch site" up for approval
by Jim Douglas 20 Dec '05

20 Dec '05

My website for QNX6 programmers wishing to use Boost is now up for approval at: http://www.dramatec.co.uk/boost-qnx6/ Comments, criticisms (constructive), corrections or congratulations ;-) are welcome. Jim Douglas

3 4