October 2007 - Boost - lists.preview.boost.org

[sunpro][patch] execution_monitor.ipp
by Simon Atanasyan 23 Oct '07

23 Oct '07

Sun C++ cannot compile execution_monitor.cpp on Solaris (Linux is ok). % CC -library=stlport4 -fast -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_DYN_LINK=1 -DNDEBUG -I. -c libs/test/src/execution_monitor.cpp "./boost/test/impl/execution_monitor.ipp", line 177: Error: va_list is not defined. "./boost/test/impl/execution_monitor.ipp", line 178: Error: Cannot assign void* to int. "./boost/test/impl/execution_monitor.ipp", line 180: Error: The function "vsnprintf" must have a prototype. 3 Error(s) detected. There are two problems: 1. va_list is in the std namespace and do not introduced into the global namespace by default. 2. On Solaris vsnprintf is declared in the stdio.h only. Patch fixes that bug is attached to this mail. -- Simon Atanasyan

1 0

[test] --output_format parameter doesn't work?
by David Abrahams 23 Oct '07

23 Oct '07

setting BOOST_TEST_OUTPUT_FORMAT=XML gives me XML output. passing --output_format=XML on the command line doesn't. Gennadiy, can you explain? Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 2

[Test] Build failures on Mac OS X
by Doug Gregor 23 Oct '07

23 Oct '07

The Test library is failing to build on the Subversion trunk with the following error: darwin.compile.c++ ../../../../bin.v2/libs/test/build/darwin/debug/ link-static/execution_monitor.o ../../../../boost/test/impl/execution_monitor.ipp: In member function 'void boost::detail::system_signal_exception::report() const': ../../../../boost/test/impl/execution_monitor.ipp:426: error: 'SIGPOLL' was not declared in this scope ../../../../boost/test/impl/execution_monitor.ipp: In constructor 'boost::detail::signal_action::signal_action(int, bool, bool, char*)': ../../../../boost/test/impl/execution_monitor.ipp:527: error: expected id-expression before '(' token ../../../../boost/test/impl/execution_monitor.ipp: In constructor 'boost::detail::signal_handler::signal_handler(bool, int, bool, char*)': ../../../../boost/test/impl/execution_monitor.ipp:608: error: 'SIGPOLL' was not declared in this scope The definition of SIGPOLL in Mac OS X's signal.h is conditional: #if defined(_POSIX_C_SOURCE) #define SIGPOLL 7 /* pollable event ([XSR] generated, not supported) */ #else /* !_POSIX_C_SOURCE */ #define SIGIOT SIGABRT /* compatibility */ #define SIGEMT 7 /* EMT instruction */ #endif /* !_POSIX_C_SOURCE */ I'll be happy to test fixes, if that would help, but I'm too confused about the handling of SIGPOLL in execution_monitor.ipp to come up with my own patch. In one place, the use of SIGPOLL is guarded by ! defined(__CYGWIN__), in other places there doesn't seem to be such a guard. A little Googling notes that SIGPOLL is also missing on Cygwin, so I assume the Test library is broken on that platform, too. - Doug

2 2

borland failure
by Gennadiy Rozental 23 Oct '07

23 Oct '07

Does any one can help me to find workaround for borland, so this unit test http://tinyurl.com/2kxobo will work? Genandiy

1 0

Boost Logging Lib v2 - added documentation
by John Torjo 22 Oct '07

22 Oct '07

Hi all, I've added documentation for the Logging Lib v2 : http://torjo.com/log2/ (Logging homepage) http://torjo.com/log2/doc/html/ (documentation) Just to make sure, the Boost Log Library has these features: * A simple and clear separation of concepts o concepts are also easily separated into namespaces * A very flexible interface * You don't pay for what you don't use. * Fits a lot of scenarios: from very simple (dumping all to one log) to very complex (multiple logs, some enabled/some not, levels, etc). * Allows you to choose how you use logs in your code (by defining your own LOG_ macros, suiting your application) * Allows you to use Log levels (debug, error, fatal, etc). However this is an orthogonal concept - the library will work whether you use levels, categories or whatever , or not. * Efficient filtering of log messages - that is, if a log is turned off, the message is not processed at all * Thread-safe - the library allows you several degrees of thread-safety, as you'll see * Allows for formatters and destinations o formatters format the message (like, prepending extra information - an index, the time, thread is, etc) o destinations specify where the message is to be written o Formatters and Destinations are orthogonal to the rest of the library - if you want you can use them, otherwise you can define your own writing mechanism * Easy manipulation of the logs (turning on/off, setting formatters, destinations, etc) Feedback is most welcome - I'm sure there's lot to improve on the docs ;) Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

4 6

[logging] Boost Log v2 - with scenarios. What's your scenario?
by John Torjo 22 Oct '07

22 Oct '07

Hi all, I've added scenarios to the documentation - that is, a few of the many ways you can use the lib: - http://torjo.com/log2/doc/html/index.html - http://torjo.com/log2/doc/html/common_scenarios.html Basically I know the lib is very flexible, and should allow most scenarios - so I'd like more suggestions - for other scenarios someone might think of. If time permits, I'll add them. One thing for sure - I'll let you know if it's possible or not. P.S. Kudos to the doxygen makers! (http://torjo.blogspot.com/2007/10/doxygen-rules.html) Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

1 0

Should auto-props svn:need-lock be used for some file types?
by Henrik Sundberg 22 Oct '07

22 Oct '07

Looking at http://svn.boost.org/trac/boost/wiki/BoostSubversion MIME Types and End-Of-Line Styles, I realized that svn:need-lock wasn't used at all. I've read http://blogs.open.collab.net/svn/2007/07/from-the-questi.html but am not sure if I think it should be used anywhere anyway. What is the reason for Boost not to use svn:need-lock for eg image files? /$

4 3

[thread] Questions/concerns about recent thread lib changes
by Sean Huang 22 Oct '07

22 Oct '07

The thread lib has recently gone through drastic changes. These much needed changes are very welcome and I really appreciate Anthony's work and efforts. We use boost::thread heavily in our mission/performance critical application and the quality and stability of the boost::thread code is paramount to us. With the recent changes and what happened in that process, I felt that it is necessary to raise my concerns to the community. If these concerns have already been addressed and managed, I sincerely apologize for generating this noise and being paranoid. Specifically, my questions are: 1. Do changes in this magnitude warrant a mini-review? 2. Is it a good idea that the new implementation be reviewed by other boost threading experts such as Peter and/or Howard? Take it to the next level, does it make sense to have a peer review process for at least significant changes? Regards, Sean

10 27

[rfc] Gui library
by Tom Brinkman 22 Oct '07

22 Oct '07

If you can get a cross platform gui into boost, that meets the standards of boost developers, youll be famous. Many have started and quit after decieding it was to daunting of a task. A modern c++ GUI is probably #1 on the most wanted/needed libraries, IMO,

8 7

C++0x question
by Marco Costalba 22 Oct '07

22 Oct '07

Starting to hack with boost libraries I found myself more and more stumbling across a big brick of C++ language, i.e. SFINAE works on types only, not on expressions. If an expression is ill formed there's no SFINAE around that will avoid you a barfing compiler. Looking at C++0x I failed to see a future improvement in that direction, also 'concepts' that will be quite new, apart from helping in decoding error messages (and this is a BIG help I would add), does not immediately seem to extend the language in that direction. For what I have understood 'refinements' are more or less similar to tag dispatching so does not seem to open completely new gates (of course this is just a first look opinion, it means that is not immediately visible to me how to use concepts to add to what you already can do using a more verbose approach, not that for sure it does not exist a way). I would like to ask you if someone has never dreamed of something like try well_formed { .... your code here... } catch { .... fall back code in case former is not compilable... }; I would think this would be an extension that greatly will open new gates to C++. Just to be clear, I'm not advocating to introduce something like the above, just to ask if a discussion around the above lines have never occurred in the C++ community. Thanks Marco

10 20