- Boost - lists.boost.org

[log] Comments
by Vladimir Prus 17 Mar '10

17 Mar '10

Hello, I have a few comments and questions about the Boost.Log library currently being reviewed. This email is not actually a review as such. It will help if I explain where I'm coming from. I am most familiar with two logging mechanism. One is from KDE libraries. There, you have severities and component ids -- which are just integers. So, source code might have kDebug(9012) << "doing something"; There's GUI to configure which components have logging enabled, and there's a way to omit explict component id. Another logging mechanism is from Eclipse. There, you specify severity and component id -- this time a string. In KDE, output goes to a console. In Eclipse -- to a log file. I would those mechanism to be sufficient for all my needs. Looking at the proposed libraries, I see two major issues: * There's no default setup that is comparable with the two mechanisms above. BOOST_LOG_TRIVIAL has only severity and it appears adding component information is complicated. In a sense, it looks like the library provides building blocks, but not a solution I can immediately use. * I think the library elegantly uses various facilities like Boost.Parameter and lambda expressions to provide an easy interface. Unfortunately, it seems like it's failing to provide any other interface for folks who might be unhappy with lambdas and named parameters. There's a more detailed explanation of those major issues: * It appears that out of the box, the proposed library does not address this component/severity style of logging that I've explained above. The proposed solutions at: http://permalink.gmane.org/gmane.comp.lib.boost.devel/200793 sound relatively complex. * The example of specifying filter without lambda functions given in http://permalink.gmane.org/gmane.comp.lib.boost.devel/200793 is frankly scary. I believe that in most languages and environments I worked with, lambda functions are just convenient alternative to defining the same function explicitly. Why is in Boost.Log, lambda expressions are blessed with extra convenience? * Why can't I use the library without named parameters? Surely, there are low-tech ways to specify things. * Why does channel_logger has a *single* parameter, and still requires that you pass it via named parameter. That is: src::channel_logger<> cl("foobar"); produces incomprehensible error message. Other concerns: * The library went too far with namespaces. Why are *six* nested namespaces necessary? This appears to be just asking for extra typing for no good reason. * Why is trivial logging printing the sequental number of each log message? I don't think this helps anything. Also, it prints the thread "number", on my system a hex string. I am not sure thread id should be part of trivial logging. Finally, I think by default, everybody things of logging as glorified std::cout, so trivial logging better print messages to console, not to a file. * Why does the library have light_rw_mutex? I would really prefer if everything thread-related be located inside Boost.Thread, so that at least the code can be readily audited. * It appears that the default behaviour of fmt::attr is to throw is the attribute with such name is not found. This seems like a bad choice to me. A logging library should never fail -- it is the last resort at diagnosing a problem in the field, and if it throws by default, it's useless. * I have used the attached script to measure code size impact. The script basically creates a test file with a single function calling BOOST_LOG_TRIVIAL and measures the size of that function depending on the number of calls. I've got 139 bytes per call for 'g++ -Os' and 174 per call for 'g++ -O3', which seems nice. This is function code only. When counting file size I get 324 and 514 respectively. For reference, kDebug gives 136 and 328 of file_size_bytes per call. I guess these results are OK. * I see lots of warnings in slim_string.cpp, e.g: ../../../../libs/log/src/slim_string.cpp:237: warning: control reaches end of non-void function I'd recommend working with maintainer of boost/throw_exception.hpp to add noreturn attributes on gcc, and silence the warning in other ways on other compilers. * Building the library with threading=single results in unresolved references to pthread functions. I belive that library should not use any sync mechanisms in this case. Thanks, Volodya

10 70

[log] Formal review
by Alexander Arhipenko 17 Mar '10

17 Mar '10

Boost.Log library formal review. > Please explicitly state in your review whether the library should be accepted. Yes, library should be accepted. Some explanation here. What means 'boost library' to me? It's very reliable, portable, efficient, sexy (in sense of code style) component that could satisfy from 90 to 95 % of regular user cases. Even if someone has an issue with such component - this issue could be resolved quickly (up to 1 hour). This quickness usually explained by clean library design and also by rich community support (the last sentence I've made based on my own experience with boost). IMHO, Boost.Log nicely fits into all the written above. Andrey spent many months (I've put an eye on Boost.Log in August 2008) polishing library's design, implementation, improving documentation. It would be nice to see the result of such huge efforts in Boost distribution. - What is your evaluation of the design? The overall design seems to be very orthogonal and does not mix different things together. - What is your evaluation of the implementation? I didn't dig deeply (except some functionality related to log rotation). At first glance, it's high quality, modern c++ code. It doesn't take too much time to understand it and make modifications. - What is your evaluation of the documentation? The first thing I except from any documentation - it's a "quick jumps" scenarios, i.e. workable small code snippets that compiles, works and give the user brief explanation on how to perform usual tasks using the library. I've found it in the latest docs and that was nice. Tutorial section is organized in 'from simple to complex things' form. This is very nice. Overall quality of the documentation is fine to me. - What is your evaluation of the potential usefulness of the library? Every application could really benefit from using logging. Especially server ones, that are running 24/7 without frequent human interaction. But I'm saying banal things now. In short, potential usefulness of such library is very high. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I've tried it. gcc 4.1.2 (RHEL 5 x86_64, RHEL 5 i686). msvc 9 (Windows i686). The only problem I had it was warnings on gcc. But that was RC3 of the library, I guess Andrey addressed those issues in the latest version. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? We've integrated Boost.Log RC3 into our server application (in the end of January 2008). Now it's running in several production environments. I've spent several days writing tiny wrapper for Boost.Log. This wrapper was required due to reasons above: 1) I was not sure about the future: whether we would like to switch to the different logging library etc., nowadays answer to this question is categorical NO 2) All the components of application should have common logging formatting, logging levels, also some 'shortcuts' were needed (such as namespace aliases etc) Also, we did some Boost.Log profiling with valgrind (memcheck tool). As far as I remember, none issues were found. - Are you knowledgeable about the problem domain? Knowledgeable from the end-user point of view. I know, what I want to have from logging (e.g., various severities, filtering, log files rotation, thread-safety). - Questions I have one question in regards to log rotation. (I guess, I was asking it last year when RC3 was presented). Is it possible to setup log rotation in a following way: file.log - earlies log file (today) file1.log - older log file (yesterday) file2.log - oldest log file (the day before yesterday). This way Apache, Samba etc. performs rotation. Also, this rotation behavior is default in Python logging module. Also, this behavior is default in my wolrd ;). Many thanks to Andrey for Boost.Log contribution. Many thanks to Volodya for being a review manager. Regards

2 1

[log] How to set/reset a channel-specific filter
by Andreas Huber 17 Mar '10

17 Mar '10

Hi We're currently reviewing Boost.Log and are wondering what is the best way to implement channel-specific filters. More precisiely, we are currently using the following "objects": - 2 sinks (one to debug output window, one to file) - several severity_channel_logger_mt objects, all declared with BOOST_LOG_DECLARE_GLOBAL_LOGGER, each of these is guaranteed to have a unique channel name For each of the channels, we would like to set a filter that only applies to records logged through the given channel. Since we can't seem to set a filter on the logger itself, we're wondering what is the best way to accomplish this? It seems as though both the core as well as the sinks only accept one filter. So, it seems we would have to a) assemble a filter expression that includes all the channels we'd like to filter on. *Or*, we could b) add exactly two sinks per logger object and set the desired filter on both sinks. Of course, we'd still want to only log to one file, so the question arises whether it is safe to have multiple sinks write to one file. If we go with method a), we'd need a way to enumerate all global loggers. If we go with b), we'd need a method to enumerate all the sinks in the system. We have not found a way to accomplish any of these tasks, how do we do this? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 7

[python]missing file
by K. Noel Belcourt 17 Mar '10

17 Mar '10

Hi, Trunk tests are dying with this error. error: Unable to find file or target named error: 'builtin_converters_ext' error: referred from project at error: '../libs/python/test' -- Noel

1 0

[exception] Unreachable returns (was [log] Comments)
by Daniel James 17 Mar '10

17 Mar '10

On 15 March 2010 10:45, Vladimir Prus <ghost(a)cs.msu.su> wrote: > > * I see lots of warnings in slim_string.cpp, e.g: > > ../../../../libs/log/src/slim_string.cpp:237: warning: control reaches end of non-void function > > I'd recommend working with maintainer of boost/throw_exception.hpp to add noreturn attributes on > gcc, and silence the warning in other ways on other compilers. I think Boost.Exception already does that (http://www.boost.org/boost/exception/detail/attribute_noreturn.hpp) but this is something I've been meaning to ask about, as I had to deal with it for iostreams. Our normal solution is to use BOOST_UNREACHABLE_RETURN (http://tinyurl.com/yjjdzsh) but that doesn't work for compilers that don't understand a 'noreturn' attribute. I hacked together my own version (http://www.boost.org/boost/iostreams/detail/config/unreachable_return.hpp) but it's only a short term solution and could break if throw_exception changes. It would be nice to have a proper solution in Boost.Exception, or maybe there already is one and I missed it? Daniel

2 2

[statechart] Undefined type
by s_a_white＠email.com 16 Mar '10

16 Mar '10

Hi, I've inherited some code that currently compiles and runs under Linux (gcc 4.2.1) and am looking to switch to Windows using the vs 2003 with SP1. Unfortunately the code fails to compile with undefined symbols. An example of the code is as follows: #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> #include <iostream> namespace sc = boost::statechart; struct EvStartStop : sc::event< EvStartStop > {}; struct EvReset : sc::event< EvReset > {}; struct Active; struct Stopped; struct Running; struct StopWatch : sc::state_machine< StopWatch, Active > {}; struct Active : sc::simple_state< Active, StopWatch, Stopped > { typedef sc::transition< EvReset, Active > reactions; }; struct Stopped : sc::simple_state< Stopped, Active > { typedef sc::transition< EvStartStop, Running > reactions; }; int main() { return 0; } I'm aware that the code is incomplete as Running is only forward declared. It is provided this way since the real model under Linux is broken up across multiple headers rather than all being in one header. Under Linux the above code compiles without an issue but vs 2003 complains about Running being undefined. Removing sc::transition< EvStartStop, Running > makes the compilation problem disappear. A similiar issue exists for Windows if Running was defined but uses an inner state that was only foward declared. Again Linux seems to have no problems. For vs 2003 wrapping the reactions or inner state with mpl::list<> does not fix the problem. Can anyone suggest if what is being done here is broken under vs 2003, or should not be allowed under gcc? Are there workarounds for the boost headers for vs 2003 or recommendations to allow splitting the state machine across multiple headers? Best Regards, Simon

2 8

[sandbox] need Apache/.htaccess/rsync help
by Eric Niebler 16 Mar '10

16 Mar '10

A bit off-topic, but I don't know who the maintainer of the boost-sandbox project on sourceforge.net is. I use this project to post updated documentation for my boost libraries. (For instance, see <http://boost-sandbox.sourceforge.net/libs/xpressive>.) Today, I tried to update Proto's docs using a script I wrote for this purpose eons ago: #!/bin/sh rsync --delete --rsh=ssh --recursive html/* eric_niebler,boost-sandbox@web.sourceforge.net:/home/groups/b/bo/boost-sandbox/htdocs/libs/proto/doc/html For ages, this has Just Worked, but for some reason, it has recently stopped working. I thought I'd check here before requesting support from SF.net. The behavior I'm now seeing is that I get 403 error for any page in Proto's docs. See: http://boost-sandbox.sourceforge.net/libs/proto/doc/html/index.html The error says: "3. Error notes: Server unable to read htaccess file, denying access to be safe" Wha'? Any help? FYI, here's sf.net's docs on rsync over ssh. From what I can tell, I'm doing everything right: http://sourceforge.net/apps/trac/sourceforge/wiki/Rsync%20over%20SSH#Projec… -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 4

Re: [boost] suggestion on assertion macros
by DE 16 Mar '10

16 Mar '10

hi all on 14.03.2010 at 18:15 Roland Bock wrote : > Hmm. I use gcc (4.2.4) and I get the warning (-Wall -Wextra). That's why > I proposed that code in the other part of this discussion (with great > help from Peter and Steven): > #include <cassert> > #ifdef NDEBUG > #ifdef assert > #undef assert > #define assert(cond) static_cast<void>(sizeof(cond? 0: 0)); > #endif > #endif > int main() { > int i = 0; > assert(i); > } > This way, I get no warning about variable i being unused, it is even > being made sure that the condition for the assertion is verifiable and > still the code results in nothing if NDEBUG is defined. > I plan on using that myself. I think it would be useful for others, too. i came to the same thing this solution works perfect with msvc80 and i feel like going to adopt it for my personal use but i think you missed the order of macro directives if i get it right it should be #ifdef NDEBUG #ifdef assert #undef assert #endif //swapped this and the following lines #define assert(cond) static_cast<void>(sizeof(cond? 0: 0)); #endif and i agree that defining an "advanced" project-specific macro is really a better solution than redefinition of 'assert()' on improving assertions: my only concern was to propose a solution to the warning issue while NDEBUG is defined (and similar situations) i picked 'assert()' only for illustration purposes of course any other assert-like system may (or may not?? i believe it does) be improved in this specific sense my opinion is that specific assertions (like contract statements mentioned) are defined the way the author prefer, i.e. there is no typical restrictions on that so the discussion on "improving assertions" or "contract programming implementation" is not my concern for now and i leave it up to you guys -- Pavel

5 11

invalid null pointer error in serialization with MSVC2008
by h yh 16 Mar '10

16 Mar '10

Hi, I am getting a very strange runtime error using boost serialization library with MSVC2008. I called the following template in my program. template <class T> void loadData(std::string fileName, T &t) { std::ifstream ifs(fileName.c_str()); boost::archive::text_iarchive ia(ifs); t.clear(); ia >> t; ifs.close(); } it gets an assertion failed when running into boost::archive::text_iarchive ia(ifs); Debug Assertion failed: invalid null pointer Here is the stack frame: msvcr90d.dll!memcpy_s(void * dst=0x00000000, unsigned int sizeInBytes=4294967295, const void * src=0x07953f63, unsigned int count=22) Line 55 + 0x2f bytes msvcp90d.dll!std::char_traits<char>::_Copy_s(char * _First1=0x00000000, unsigned int _Size_in_bytes=4294967295, const char * _First2=0x07953f63, unsigned int _Count=22) Line 582 + 0x16 bytes msvcp90d.dll!std::_Traits_helper::copy_s<std::char_traits<char> >(char * _First1=0x00000000, unsigned int _Size=4294967295, const char * _First2=0x07953f63, unsigned int _Count=22, std::_Secure_char_traits_tag __formal={...}) Line 714 + 0x15 bytes msvcp90d.dll!std::_Traits_helper::copy_s<std::char_traits<char> >(char * _First1=0x00000000, unsigned int _Size=4294967295, const char * _First2=0x07953f63, unsigned int _Count=22) Line 706 + 0x22 bytes msvcp90d.dll!std::basic_streambuf<char,std::char_traits<char> >::_Xsgetn_s(char * _Ptr=0x00000000, unsigned int _Ptr_size=4294967295, int _Count=22) Line 342 + 0x1a bytes msvcp90d.dll!std::basic_streambuf<unsigned short,std::char_traits<unsigned short> >::_Sgetn_s(unsigned short * _Ptr=0x00000000, unsigned int _Ptr_size=4294967295, int _Count=22) Line 118 msvcp90d.dll!std::basic_istream<char,std::char_traits<char> >::_Read_s(char * _Str=0x00000000, unsigned int _Str_size=4294967295, int _Count=22) Line 698 + 0x27 bytes msvcp90d.dll!std::basic_istream<char,std::char_traits<char> >::read(char * _Str=0x00000000, int _Count=22) Line 712 MyProject.exe!boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::load() + 0xad bytes MyProject.exe!loadData<std::set<GamingNote,GamingNote,std::allocator<GamingNote> > >(std::basic_string<char,std::char_traits<char>,std::allocator<char> > fileName="nocturne.gnt", std::set<GamingNote,GamingNote,std::allocator<GamingNote> > & t=[0]()) Line 14 + 0x14 bytes It happens when the text_iarchive class constructs, so I am sure it's nothing to do with the serialize function of T, but something between boost and std::ifstream. The wierd thing is I didn't come across this program at the first time. It appears suddenly during development. If I separate the serialization code to a single cpp file, it doesn't have any problem at all. By the way, I am intergrating Qt and Ogre with boost by the way, but that seems not to be quite helpful to identify this problem. Any ideas about that? Yuheng Huang

1 0

boost::log review (printf style api)
by Tom Brinkman 16 Mar '10

16 Mar '10

>> It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful >> (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them >> to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in >> order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library? >> My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people >> who happen to be used to that "glue language," even for their C++ development. I still think it is a valid >> discussion to have. Well said. Good summary, although as noted, I disagree with your conclusion. The larger question is -- what has gone wrong with boost? Why do so many libraries languish in the review queue. Why has the the C++ standard taken so long to get enough momentum to pass through committee. In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical". Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development. The experience of those of us that have developed with this style over the years has been mixed. Like anything, somethings are nice, somethings are more trouble than there worth. Fortunately, for those of us that have an appreciation for functional programming will still be highly relevent in the future. The reason has primarily has to do with parralel programming which lends its self very nicely to functional programming, which is what boost is all about. The way I explain it, functional programming is just a variation of procedural programming with a different way of passing around state. Unfortunately, this advanced programming style is often abused in hideous ways. Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development. I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional. This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api. Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most develpers will look at the api without a printf and go, HUH?

7 10