- Boost - lists.preview.boost.org

[date_time] memory leak?
by Bartosz Marcinkiewicz 18 Mar '10

18 Mar '10

Hello, Code: #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> int main() { std::cout << boost::posix_time::microsec_clock::local_time() << std::endl; return 0; } Running through valgrind yields this: ==5963== ==5963== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 2) ==5963== malloc/free: in use at exit: 1,595 bytes in 27 blocks. ==5963== malloc/free: 63 allocs, 36 frees, 7,878 bytes allocated. ==5963== For counts of detected errors, rerun with: -v ==5963== searching for pointers to 27 not-freed blocks. ==5963== checked 173,784 bytes. ==5963== ==5963== 619 bytes in 20 blocks are possibly lost in loss record 7 of 7 ==5963== at 0x4A06FFC: operator new(unsigned long) (vg_replace_malloc.c:230) ==5963== by 0x352C0A0140: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.12) ==5963== by 0x352C0A0D64: (within /usr/lib64/libstdc++.so.6.0.12) ==5963== by 0x352C0A0F01: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.12) ==5963== by 0x408AD7: boost::date_time::date_generator_formatter<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::date_generator_formatter() (in /home/bma/c++/boost_dt) ==5963== by 0x407B20: boost::date_time::time_facet<boost::posix_time::ptime, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::time_facet(unsigned long) (in /home/bma/c++/boost_dt) ==5963== by 0x40494B: std::basic_ostream<char, std::char_traits<char> >& boost::posix_time::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::posix_time::ptime const&) (in /home/bma/c++/boost_dt) ==5963== by 0x402AA0: main (in /home/bma/c++/boost_dt) ==5963== ==5963== LEAK SUMMARY: ==5963== definitely lost: 0 bytes in 0 blocks. ==5963== possibly lost: 619 bytes in 20 blocks. ==5963== still reachable: 976 bytes in 7 blocks. ==5963== suppressed: 0 bytes in 0 blocks. ==5963== Reachable blocks (those to which a pointer was found) are not shown. ==5963== To see them, rerun with: --leak-check=full --show-reachable=yes This is boost-1.37.0-9.fc11 (fedora core 11), gcc 4.4.1, x86-64 platform. Is it memory leak? Best regards, bma. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wrocław, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext.36 fax (+48) 71 361 74 44 NIP PL 899-24-92-498 KRS 0000190187 REGON 932963731 Kapitał zakładowy: 500 000 PLN

3 3

Re: [boost] [unordered] unordered_set::erase() complexity bug?
by Christopher Crickmar 18 Mar '10

18 Mar '10

Given that the next iterator is meaningless for an unordered container and that cached_begin_bucket_ is always valid would it be bad manners to always return begin() ? Chris Crickmar

2 2

[multi_index] hashed_index erase(iterator) performance issue
by Brad Higgins 17 Mar '10

17 Mar '10

Hello, I have encountered a performance issue with multi_index's hashed_index erase(iterator) routine. The erase(iterator) call returns an iterator to the next element in the data structure. When using this routine in a sparsely populated, large sized hash, it takes a very long time to complete. For example, in my program, I have rehashed the hash table to 5 million buckets, and added 600,000 elements. Adding the elements takes a matter of seconds. Then, I delete the elements. Deleting the elements takes hours. I have profiled the code, and it looks to me like the performance hit is rooted in the increment of the iterator by the erase(iterator) call. Since the hash is sparsely populated, the increment must advance over many empty buckets for each erase(iterator) call, in order to advance to the next valid element. My question is, why does the erase(iterator) function return an iterator at all? (In comparison, sgi's stl::hash_map's erase() returns void.) The hash is unordered, so the returned iterator is a random value, which I think decreases its usefulness (I expect most clients will discard the returned iterator.) Additionally, the same behavior can be achieved by clients who desire this behavior if they post-increment their iterator argument themselves. That is: // After this line, cur_itr's initial element will be erased, // AND cur_itr will be updated to the next element in the hash table hash_table.erase(cur_itr++); Is there some way to remove elements from the hash without taking this iterator increment hit? Would it be possible to add an erase routine (of some other name) which accepts an iterator argument, but does not automatically increment the argument? Thanks, Brad

3 3

[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

Collection of Jamfiles for 3rd-parties?
by Mateusz Loskot 15 Mar '10

15 Mar '10

Hi, I'm wondering if would it make sense to have a directory in Sandbox or close where Jamfiles for various third-party programs and libraries could be maintained. I imagine it could make it easier to integrate various dependencies with Boost and Boost Sandbox libraries. For example, GIL makes use of libpng, libjpeg, libtiff, libz, gzip/bzip2 are used by others too. I found that HAIKU OS maintains collection of Boost Build enabled libraries: http://dev.haiku-os.org/browser/haiku/trunk/src/libs I'm not suggesting to do the same, but perhaps it would make sense to maintain Jamfiles only, so users can download them and refer to such libraries using symbolic targets. I'm curious of your comments? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 1

base class for boost::array
by Peter Myerscough-Jackopson 15 Mar '10

15 Mar '10

Dear all, In using boost::array I have felt the need to pass around boost::array's of an unknown size (unknown to the function receiving the array). I have therefore created an abstract base class for boost::array so that I can create a pointer to a common base class for arrays of different sizes. Essentially std::vector's of different sizes can be passed into a function with a fixed prototype, but because boost::array constructs a different type for each array size, a single fixed prototype cannot be described such that it can be called with different sizes of boost::array. In code I can write (toy functions) : double sumTotal(const std::vector<double>* values) { double result = 0 ; BOOST_FOREACH(double v, values) { result += v; } return result; } But I can't write: double sumTotal(const boost::array<double>* values) { double result = 0 ; BOOST_FOREACH(double v, values) { result += v; } return result; } Without the second function being a template function, i.e. I cannot provide a library that takes a boost::array<double>. With the attached base class, I could define a function that takes a boost::array_base<double>. Since, I think, the ability to allow boost::array to be used in this way is that it requires the use of virtual functions, I have written it so that the inheritance is optional. It is enabled with a #define before including array.hpp . Is this useful? (I am aware that I maybe could use a boost::range) Thanks for your time, Peter Ps. On my current compiler, swap and operator= could not be uncommented in the array_base class. PPs. This is my first post to boost dev, please be kind... J Dr Peter Myerscough-Jackopson - Senior Engineer Tel: +44 (0)23 8076 7808 Fax: +44 (0)23 8076 0602 Web: http://www.macltd.com/ <BLOCKED::http://www.macltd.com/> Email: peter.myerscough-jackopson(a)macltd.com <mailto:peter.myerscough-jackopson@macltd.com> MULTIPLE ACCESS COMMUNICATIONS LIMITED is a company registered in England at Delta House, The University of Southampton Science Park, Southampton, SO16 7NS, United Kingdom with Company Number 1979185 and VAT Number GB 411942866

5 4

[Boost.Locale] New Release
by Artyom 15 Mar '10

15 Mar '10

Hello Boost List! ================= I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework. I'm looking forward to formal review and general inputs from Boost.Community. Documentation: http://cppcms.sourceforge.net/boost_locale/html/index.html Download: From: https://sourceforge.net/projects/cppcms/files/ File: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale.zip… Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library giving: * Correct case conversion, case folding and normalization * Collation including support of 4 Unicode collation levels. * Date, time, timezone and calendar manipulations, formatting and parsing including transparent support of calendars other then Gregorian. * Boundary analysis for characters, words, sentences and line-breaks. * Number formatting, spelling and parsing. * Monetary formatting and parsing. * Powerful message formatting including support plural forms, using GNU catalogs. * Character set conversion. * Transparent support of 8-bit character sets like Latin1. * Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. New in this version: ==================== a. Fully redesigned break iterator interface b. Added date_time and calendar support that allow manipulating with dates over non-Gregorian calendars c. Implemented full set of unit-tests d. Added support of many platforms and compilers. e. Lots of bug fixes. f. Complete reference with Doxygen g. Many tutorial updates, thanks to Markus Raab inputs Tested compilers and platforms: =============================== - Compilers: - GCC 3.4, 4.1, 4.2, 4.3, 4.4 - Intel Compiler 11.0 - SunStudio 12 with STLPort - MSVC 2008 - Operating Systems: - Linux - FreeBSD - OpenSolaris - Windows XP - Windowns XP/Cygwin - ICU Versions: 3.6, 3.8, 4.2 Full list of tests: =================== - Linux: - Debian GNU/Linux 2.6.18, x86, GCC 4.1.2, ICU 3.6.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.3.2, ICU 3.8.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.4 -std=c++0x, ICU 3.8.1 (Some faults on char16_t/char32_t support) - Debian GNU/Linux 2.6.26, x86_64, Intel Compiler 11.0, ICU 3.8.1 - FreeBSD - FreeBSD 8.0, i386, GCC 4.2.1, ICU 3.8.1 - OpenSolaris: - SunOS OpenSolaris 5.11, i386; Sun Studio 12, with STLPort, ICU 4.2 - SunOS OpenSolaris 5.11, i386; GCC 3.4.3, ICU 4.2 - Windows XP/SP2 - Cygwin 1.5, GCC 3.4, ICU 3.8 - Cygwin 1.5, GCC 4.3, ICU 4.2 - Windows XP/SP2, Mingw/GCC 4.4, ICU 4.2 (Static build only) - Windows XP/SP2, MSVC9 (2008)

10 19

[iterator] Help needed understanding output_iterator requirements
by Thomas Klimpel 15 Mar '10

15 Mar '10

Dear iterator experts, Jesse Perla recently reported that boost::multi_array fails compilation for many basic tasks on MSVC 2010. I investigated the failures, because I had already investigated other failures on MSVC 2010 reported by Jesse Perla for boost::ublas. While I'm quite familiar with boost::ublas, I'm a complete novice with respect to boost::multi_array and boost::iterator. I could track the failures to a specific (intentional?) behavior of iterator_facade from Boost.Iterator (more specifically of facade_iterator_category.hpp): http://lists.boost.org/Archives/boost/2010/03/163039.php Thomas Klimpel wrote: > What effectively happens it that the iterator gets the category > "input_iterator", but std::copy wants to have an "output_iterator". I > think I understand why the iterator doesn't satisfies the requirement > of a "forward_iterator", but it's unclear to me why it didn't qualify > as an "output_iterator". There is an "input_output_iterator_tag" in > "boost/iterator/detail/facade_iterator_category.hpp", so it would have > been possible for the iterator to be both "input_iterator" and > "output_iterator". However, it seems to me that > "input_output_iterator_tag" is never used in the Boost.Iterator > library. I would have to read more about "output_iterator" to > understand whether Boost.Iterator is correct here. With my current > understanding of "output_iterator", I would say it's a bug in > "boost/iterator/detail/facade_iterator_category.hpp". > > Perhaps somebody with more knowledge about "output_iterator" and > Boost.Iterator can explain to me why an iterator using the > "boost::random_access_traversal_tag" for the "CategoryOrTraversal" > template parameter of "iterator_facade" will never get the category > "output_iterator" (or "input_output_iterator_tag"). Of course I could go on and read more about "output_iterator", or find out whether the Boost.Iterator documentation has to say something about this issue, but since I only came to this problem because I wanted to help Jesse Perla on a problem with boost::multi_array, I would much prefer if an "iterator expert" could "take over". Regards, Thomas

2 2

[log] Boost.Log formal review
by Vladimir Prus 15 Mar '10

15 Mar '10

Boosters, the formal review of the Boost.Log library, written by Andrey Semashev, starts now and will run through March 17, 2010. The documentation for the current version is available at: http://boost-log.sourceforge.net The downloads are at: http://sourceforge.net/projects/boost-log Here are the important points: 1. All comments are appreciated. Even if you don't have the time for in-depth study of everything, comments on parts of the library are welcome. In particular, if you are already using logging in your applications and have specialized requirements, you might want to directly check how the proposed library handles them. 2. The reviews and all comments should be submitted to the developers list, boost(a)lists.boost.org and the email should have "[log]" prefix in the subject to make sure it's not missed. The deadline for reviews is 23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK 3. Please explicitly state in your review whether the library should be accepted. 4. The general review checklist is provided below: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks, Volodya

16 52

Fwd: Re: [log] review part 1
by Andrey Semashev 15 Mar '10

15 Mar '10

Due to technical reasons this reply went off-list. For sake of keeping the conversation public, I'm reposting it. -------- Original Message -------- Subject: Re: [boost] [log] review part 1 Date: Sat, 13 Mar 2010 16:08:14 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: Steven Watanabe <watanabesj(a)gmail.com> On 03/12/2010 07:22 AM, Steven Watanabe wrote: > I mostly have documentation notes at this point. Andrey, since I have so > many, and they're mostly fairly minor, would it be better if I made > a patch for the documentation source? Yes, that would be great. I quickly reviewed your suggestions, and they all look reasonable (I always have a hard time with articles). Thanks! > I think newbies should probably be replace globally with new users, > since I kind of feel that the term newbie is somewhat derogatory. Ok. I didn't mean to offend anyone, of course. :) > http://boost-log.sourceforge.net/libs/log/doc/html/log/defs.html > ================================================================================ > > For Log record: > I don't like the expression "A single pack of information," although > I can't think of anything better off hand. A collection of data,...? > ================================================================================ > > Issues: > > Instead of compiling a narrow or wide library, why don't you use > libboost_log > and libboost_wlog? There are parts that would be the same in both these libraries. Most notably, singletons of file_collector repository and some constants. This might lead to linking problems if someone tries to use both versions of the library. > I agree with other comments that I saw about Attribute being > a poor choice for what it does. I would prefer that the term "Attribute" > should be used for what you call an "Attribute Value," and that > there should be a different term, like "Attribute Extractor" for > what you call an "Attribute." My understanding of the term "attribute" is that it's some kind of meta-information that defines the concrete values that will be attached to log records. I'm ready to agree that the word "attribute" doesn't bring my intention precisely, but the alternatives don't quite get closer. "Extractors" are reserved for another tool in the library.

5 6

static in_class constants
by Christian Henning 15 Mar '10

15 Mar '10

Hi there, I'm finishing up some linker problems I have with gcc. One area of problems seems to be static in_class constants that I have declared in my header file. MSVC doesn't have problem with it but gcc is complaining. I'm wondering how other libs in boost are dealing with these problems. For instance in my new gil::io lib I define some tags in pnm_tags.hpp as follows: /// Defines type for image type property. struct pnm_image_type : property_base< uint32_t > { BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); // Monochrome ASCII encoding BOOST_STATIC_CONSTANT( type, _gray_asc = 2 ); // Gray level ASCII encoding BOOST_STATIC_CONSTANT( type, _color_asc = 3 ); // sRGB color ASCII encoding BOOST_STATIC_CONSTANT( type, _mono_bin = 4 ); // Monochrome binary encoding BOOST_STATIC_CONSTANT( type, _gray_bin = 5 ); // Gray level binary encoding BOOST_STATIC_CONSTANT( type, _color_bin = 6 ); // sRGB color binary encoding }; Thanks, Christian

7 27

Review - boost::log
by Tom Brinkman 15 Mar '10

15 Mar '10

Should boost log be accepted into the boost library? My vote is no. This library will just reinforce boost's reputation as being a repository of needlessly complicated highly templatized libraries for relatively easy programming tasks. I don't mind this added complexity when it comes to genuinely difficult problem spaces. In my view, however, logging is not one of those problem spaces. Logging is one of those things that if it takes longer than 10 minutes to read the documentation and get up to speed, it will not get used. What is your evaluation of the design? Very much in the spirit of a typical boost library. However, it has very little attention to "C" interfaces and makes heavy use of templates. I suppose because this is boost, that that is acceptable. However, boost and the c++ community at large should start moving towards a more friendly attitude towards a "C" style api for utility libraries. Most non-boost c++ developers will dismiss this library out of hand, not because its a bad library, its not, it's just more of the same. Heavy handed use of templates. I guess I've spent too much time over the last 5 years ripping out poorly conceived heavily templated code. The thought of adding to this madness, with another utility library that is burdened by templates is hard to swallow. What is your evaluation of the documentation? Good What is your evaluation of the potential usefulness of the library? Logging is useful. Yes. Did you try to use the library? With what compiler? Did you have any problems? Yes. GCC++. No problems How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2 hours Are you knowledgeable about the problem domain? Yes. I was the review wizard for three years and have followed the progression of boost from the beginning, Tom Brinkman

10 23

Re: [boost] suggestion on assertion macros
by Andrzej Krzemienski 15 Mar '10

15 Mar '10

> there were a discussion recentrly about verifying arguments of > assertion macros while checks are turned off > i've got an idea of how to check the argument(s) and guarantee zero > code size and runtime overhead Hi, This is a good addition to assertions, but once we decide that we are improving assertions, there is much more that needs an improvement. Most of them are listed in the thread on Contract++ library (proposed for Boost) that you are already referring to. But let me list the potential improvements here. 1. If the expression in assertion throws an exxception, this should also be considered an assertion failure. Otherwise evaluating or not evaluating an assertion may render different program behavior. You can implement that by wrapping the expression with a try-catch block; but then assertion is a statement rather than an expression. Personally I think it is even better that an assert in a statement and it cannot be a subexpression of a bigger expression, but it no longer complies to assertion interface. Lambdas have the capability of changing statements into expressions, but we do not have them yet. 2. Be able to disable some assertions, but not all, e.g. I want the following assert in my code never to execute: assert<low_level>( is_sorted( v.begin(), v.end() ) ); find_logarithmic( v.begin(), v.end(), val ); Simply because it may be too slow even in debug. 3. I may want to disable even syntax checking in order for my compilation to run faster. I guess we should also consider user that prefer slower applications that compile faster 4. Make sure that the expression does not access any global variables. Well, we shouldn't really forbid that but give it as an option for the programmers that like "functional style" programming. I don't know how to do that now, but with lambdas, I believe it is posible with empty capture lists. 5. At least try to limit the possibility of the expression having any side effect. Contract++ ttries to do it by enforcing the const correctness of some inputs. Perhaps, even the old assert is left alone and some super-assert like the one from Concept++ should be incorporated into Boost and be the preferred way of veryfing user assumptions. Regards, &rzej

6 11

[iostreams] Add char_traits to the Device concept
by thomas weidner 14 Mar '10

14 Mar '10

Hi, i came across this issue when trying to use iostreams with a custom character class and custom character traits. The main problem is, that iostreams assumes std::streampos as the position type for all devices. Some parts of iostreams, like detail::indirect_streambuf honor the char traits' custom pos_type, but this will cause build failures as the underlying device (even code_converter) uses std::streampos as position type. My proposal is to add an associated character traits type to a Device. A Device type whould therefore not only provide information about the underlying character type, but also about the used pos_type, off_type and code conversion (not) done. I would even use traits different from std::char_traits<Ch>/iostreams::char_traits<Ch> as default character traits for most devices. Most devices like for example file_descriptor_sink don't do any code conversion, so a pos_type which contains a mbstate_t is useless and leaves the user with the impression, that code conversion *is* done. A simple integral type like C's off_t should do fine. Let's call those traits binary_char_traits for now. As an implication of this a iostreams::stream_buffer<file_descriptor_sink> should use the Device's char traits type, so should be a std::basic_streambuf<char, binary_char_traits<char> >. Especially it whould not be useable with std::iostream. This is IMO a nice and very clean result, as an iostream expects characters on which code conversion has been performed. You whould need to plug a code_converter in between. Some thoughts about iostreams::code_converter. Perhaps we should change the Codecvt template parameter to a second traits type. This traits type will become the code_converter's associated char traits type. the codecvt type could be an extra template parameter or is simply std::codecvt<code_converter_char_type, underlying_device_char_type, codecvt, code_converter_traits_state_type>. this whould be the same mechanism as code conversion in the stdlib works (using std::codecvt specialization). Comments to my thoughts are very welcome. --- Thomas

1 0

Re: [boost] [log] Boost.Log Review...
by Sean Chittenden 14 Mar '10

14 Mar '10

>> The above wasn't explicitly distilled in the documentation in a >> single place, but I think future developers would find it very useful >> to see that spelled out explicitly. Given the extremely modular >> design of the library, I understand why the docs are the way they are >> and know that some of this is touched on in the Design Overview, but >> until I became very competent with the library, the documentation >> seemed too abstract. Despite the importance of logging, becoming a >> logging expert was tangential to the problem I was trying to solve >> and I would have personally found the above summary very useful. > > Well, that summary may describe your use case very well, but it is by no > means complete with regard to Boost.Log as a whole. I would even say > it's misleading in some parts - in particular: "Loggers are collections > of Sinks" and "Think of channels as a Sink-level observer". Fair response. I think a more general way for me to classify my response/concern (instead of providing a loosely worded example) would be: "Which class does what and how do the classes relate to each other?" Right now answering that question results in a decent exploration of Boost.Log's code and documentation. It would have been useful to me, and likely future developers, to have the classes that comprise Boost.Log summarized so that conceptual map could have been more easily formed without having to dig in to the actual headers. Something similar to the contents of the Definitions page, but with architectural clues. http://boost-log.sourceforge.net/libs/log/doc/html/log/defs.html As an example, expanding on the Sinks definition from above: > Log Sink: A target, to which all log records are fed after being collected from user's application. It is sink's nature that defines where and how the log records are going to be stored. Maybe include something as brief as: > With a Log Sink, developers can modify the filtering and add additional backends. I consider myself a modestly competent user of boost, but still am getting parts of this wrong after over three months of using/digging in to Boost.Log. >> A hindsight 20/20 architecture and terminology for Boost.Log could be >> simplified in terms of: > > What is "20/20"? I'll continue my answers assuming that the following > was your understanding of the current Boost.Log architecture. Correct. The contents of this email has evolved from sometime around mid-January or whenever I learned that Boost.Log was going to be reviewed and accepted. It also crudely mirrors my understanding of the library as I went through the development process of utilizing the library. >> *) Log Record pre-conditions. Sinks control whether or not a Log >> Record is to be generated > > Looks like you're confusing sinks with filters. Also, don't forget about > the global filter. I became sloppy with my terminology. Filters are stored in Sinks and the Global core. Speaking of filters, yesterday I stumbled across a feature request: > Program received signal SIGABRT, Aborted. > 0x00007fff81de2fe6 in __kill () > (gdb) bt > #0 0x00007fff81de2fe6 in __kill () > #1 0x00007fff81e83e32 in abort () > #2 0x00007fff81e03de2 in _Unwind_Resume () > #3 0x00000001000a3b1c in main (argc=1, argv=0x7fff5fbff338) at /tmp/foo.cc:267 If I wrap everything in a boost exception, I get: > exception: /usr/local/include/boost/log/filters/attr.hpp(134): Throw in function (unknown) > Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_12log_mt_posix13missing_valueEEEEE > std::exception::what: Requested attribute value not found It'd be nice if the error message were able to somehow include the string representation of the value (attribute) it wasn't able to find. Turns out it was a type-o so I had an unregistered attribute, but the type-o would've been very easy to identify if it were included in the error message someplace (instead it took a fair amount of manual investigation and backtracking to figure out it was a filter searching for an attribute that didn't exist). [snip useful responses/corrections ] >> Observers could then be placed on Sinks that would stamp Log Records >> with Severities, or Channels, or in whatever hodge-podge >> configuration the developer wanted and such examples would be very >> cookbook. > > Now that you presented a code snippet, your suggestion makes more sense > to me. Let me express my thoughts on it in two parts: > > 1. Custom log records. Yes, the model of "mandatory" attributes look > promising. It could, at least, partially solve the problem of possible > library misconfiguration that was highlighted in another review. I > imagine that some kind of log record prototype (or factory) should be > defined by the user in order to be able to construct log records with > the specific set of attribute values. Filters and formatters could then > request these mandatory attribute values without having to worry about > their absence. Lookup performance may also be higher, but I doubt it > will be compile-time. The idea is quite vague now but after some > thinking over it might become a good addition to the library. > > 2. Designing sinks (and the core, I presume) after the log records. No, > that looks unacceptable to me, at least for what Boost.Log tries to > achieve. This would introduce too much coupling between the logging side > of the library (which tends to be exposed to many parts of the > application) and the consuming side (which tends to be configured in a > single place of the application). To my mind, these sides of the library > should be maximally decoupled. Also, it's not clear how to support > multiple log record types in such a design. >> *) Global loggers vs. per-object references to singletons > > Not sure I understand. Is it better to have global objects that reference singletons: > typedef boost::log::sources::severity_channel_logger_mt<levels::severity_level> logger_t; > > BOOST_LOG_DECLARE_GLOBAL_LOGGER(default_log, logger_t); > BOOST_LOG_DECLARE_GLOBAL_LOGGER_CTOR_ARGS(stats_log, logger_t, (boost::log::keywords::channel = "stats")); or per object references to logging singletons: > typedef boost::shared_ptr< boost::log::sinks::synchronous_sink< boost::log::sinks::text_ostream_backend > > console_sink_t; > typedef boost::shared_ptr< boost::log::core > logger_core_t; > > struct my_obj { > my_obj(logger_core_t& logger) : lg(logger) {} > void foo() { BOOST_LOG(lg) << "log msg"; } > logger_core_t& lg; > } > > int main() { > console_sink_t cerr_sink; > cerr_sink = boost::log::init_log_to_console( > std::cerr, > boost::log::keywords::filter = boost::log::filters::attr< int >("Severity") >= warning, > boost::log::keywords::format = "%TimeStamp%: %_%", > boost::log::keywords::auto_flush = true); > my_obj o(boost::log::core::get()); > o.foo(); > } ... I think that example's right. >> *) Channel severity loggers example > > That example wouldn't be much different from the ones in sections about > severity_logger or channel_logger. But I'll add a code sample. Where I spent time with this was figuring out how multiple chan severity loggers interacted with the core and how my app was supposed to interact with the distinct loggers, which were linked in to the core, behind the scenes. > typedef boost::log::sources::severity_channel_logger_mt<levels::severity_level> logger_t; > BOOST_LOG_DECLARE_GLOBAL_LOGGER(default_log, logger_t); > BOOST_LOG_DECLARE_GLOBAL_LOGGER_CTOR_ARGS(lg1, logger_t, (boost::log::keywords::channel = "chan1")); > BOOST_LOG_DECLARE_GLOBAL_LOGGER_CTOR_ARGS(lg2, logger_t, (boost::log::keywords::channel = "chan2")); > #define LG1_WARN BOOST_LOG_SEV(lg1::get(), log_severities::warn) > #define LG1_INFO BOOST_LOG_SEV(lg1::get(), log_severities::info) > ... > LG1_INFO << "info msg"; >> *) Setting up an initial console logger as >> line one in main() > > Hmm. Ok, I'll add something about that to the tutorial. Easy to do (see above), but I didn't see anything that said, "it would be wise to do this first and then remove your console sink after you setup your logging environment." Initially I disregarded the init_to_console() convenience functions while reading the docs, and it wasn't until I started dealing with error messages that weren't being logged to a file because my logging setup routines hadn't been completed (or had failed for some reason due to FS perms), that I suddenly took note of needing to get console logging working first. >> *) Changing a backend filter at a later date > > Just call set_filter on the backend, that's all. This was one of the areas where there were lots of ways that I could do it, but I couldn't tell which was the right way. libs/log didn't suggest a preferred mechanism or right way to do it. >> *) Using async logging for INFO level logs, but switching to sync for >> CRIT errors. > > You can register two sinks - one synchronous and one asynchronous, and > set their filters accordingly. Ah, clever way of handling that. >> *) Obtaining the severity of a particular logger > > You mean, the default severity? There's no public API for this, but > there's a protected function default_severity in the logger feature. Why > would you need it? Internally you're using spirit for log record filtering, so it's impossible from what I can tell to do that inside of Boost.Log. Having a way of poking at a sink to obtain information about its runtime status. Using the above console sink as an example: > typedef boost::shared_ptr< boost::log::sinks::synchronous_sink< boost::log::sinks::text_ostream_backend > > console_sink_t; > console_sink_t cerr_sink; > cerr_sink = boost::log::init_log_to_console( > std::cerr, > boost::log::keywords::filter = boost::log::filters::attr< int >("Severity") >= warning, > boost::log::keywords::format = "%TimeStamp%: %_%", > boost::log::keywords::auto_flush = true); > > std::cout << "Current Severity Level: " << /* or something like this */ cerr_sink->filter_severity() << std::endl; I ended up adding this to my application's surrounding code. >> *) How do you remove log events given a severity level at compile >> time. Currently this isn't explicit defined in the documentation >> like it is in Google's glog library: >> >> http://google-glog.googlecode.com/svn/trunk/doc/glog.html#strip > > The library has no direct means for that. Users can conditionally define > their logging macros, based on BOOST_LOG_SEV or pure C++ interface and > then enable or disable the particular logging statements from the source. *nods* I just didn't see anything in the docs to do this, which is why I ended up with the practice: > #ifdef RELEASE > # define LG1_WARN BOOST_LOG(null_log::get()) > #else > # define LG1_WARN BOOST_LOG_SEV(lg1::get(), log_severities::warn) > #endif null_log always filters everything sent to it. Probably less than ideal, but I couldn't think of a better way to handle this. >> *) Is there a way to set a bit in a Log Record that overrides a >> Sink's filter? For instance, there are certain events that I want to >> make sure go to the console 100% of the time without changing the >> severity of the log message. Do I just log twice? It'd be keen if >> Log Records could have a bit that could be set and would override a >> filter. >> >> bool log_to_console = true; BOOST_LOG_SEV_CONS(lg, warning, >> log_to_console)<< "my message"; > > You can set an attribute (say, "Emergency") for that record, and setup > filters so that whenever this attribute is present, the record is passed > on to the console backend. You mean a scope attribute? > boost::shared_ptr< attrs::mutable_constant< bool > > console_attr(new attrs::mutable_constant< bool >(false)); > lg.add_attribute("Console", console_attr); > BOOST_LOG(lg) << "Console is false by default"; > > { > BOOST_LOG_SCOPED_THREAD_ATTR(lg, "Console", true); > BOOST_LOG(lg) << "Console is true"; > } > > BOOST_LOG(lg) << "Console is false again"; Like that? >> *) It should be noted that the internal async log message queuing >> mechanism uses a vector and during very bursty logging activity that >> the vector can grow large in size and doesn't ever reduce in size. >> This is a known limitation and the use of a vector was chosen to >> facilitate atomic append operations for log records. Using a >> std::deque would be preferred for bursty applications that way space >> could be reclaimed easier, but as Andrey pointed out, it would >> require a full mutex which would reduce the performance of the >> library. > > There is no vector in the async frontends. The problem with the current > queuing mechanism is not the storage strategy but the lack of queue > boundaries. But I agree, I should have drawn attention to this aspect in > the docs. Will do. *nods* I brought this up in a private email w/ you and was satisfied with your answer, but thought it worth noting for others. As for the frontends having their own queue, with the way that async frontends work and their feed_records() call, I'd assumed the backend used a time-based mechanism to come by and pick up the log records stored in per-frontend TSS queues. Something where frontends atomically pushed records on, and the backend would atomically swap() the list of records off for sorting and processing by the backend. Just a point of confusion after reading: http://boost-log.sourceforge.net/libs/log/doc/html/log/detailed/sink_fronte… and I never dove in to the source to investigate further. >> *) I find the argument against Lazy Streaming of attributes to be >> weak. >> >> Current BOOST_LOG() expands to a for() loop where the contents of >> the for() loop aren't executed unless a Sink in a Logger accepts the >> record. >> >> So why can't Log Records have compile-time attributes that can be >> populated with typed attributes in a stream? >> >> And then be able to extract the compile-time attribute in a backend: > > Just as it is said in the rationale - the streaming expression is _not_ > executed until _after_ the filtering is done. And filtering already > involves attribute values, so there's no way to use these attribute > values you specified in the streaming expression. Besides, after the > view of attribute values is constructed, it is immutable, so nothing can > be added after the filtering is done. That's why I make the distinction between "log record preconditions," attributes that can be used in a filter, and "attributes," which is a catch-al term for data stored in a Log Record. I agree that it is impossible for streamed attributes to be used as preconditions, but streamed attributes act as an extremely convenient (from a syntax perspective) way of passing data to a backend for processing. >> *) Dovetailing on the above two points, a flush bit for a given Log >> Record would be very nice as well. 99.999% of the time async logging >> is desired, but in the 0.001% of the time when a Log Record must get >> out to disk, chances are that one Log Record every blue moon is >> disproportionally valuable compared to the normal Log Record. Having >> a flush() that doesn't return until the backend has fsync(2)'ed data >> would be really spiffy. >> >> BOOST_LOG_SEV(lg, warning)<< "My message"<< lg::flush; > > As I already noted, your mileage is too biased, at least. I, personally, > tend to use synchronous logging. But I do recognize that some kind of > flushing ability would be nice in case of async logging. I like the idea of using both async and sync sinks. It leaves me with a few questions, however: How does that work if they're both using the same text file backend? Will log entries still be ordered? > typedef boost::log::sinks::text_file_backend backend_t; > typedef boost::log::sinks::ordering_asynchronous_sink< backend_t > sink_t; > boost::shared_ptr<sink_t> sink(new sink_t( > boost::make_shared< backend_t >(), > keywords::order = logging::make_attr_ordering("LineId", std::less< unsigned int >()), > keywords::ordering_window = boost::posix_time::seconds(1))); Thanks again in advance. -sc -- Sean Chittenden sean(a)chittenden.org

2 1

[SoC] Summer of Code Project Ideas
by Andrew Sutton 13 Mar '10

13 Mar '10

I'm officially soliciting ideas for student projects for this year's 2010 Summer of Code. If you're maintaining or contributing to a library and have some non-trivial items on a TODO list, then suggesting that as a possible student project may be a viable idea. Unlike the previous years, I think that proposing work on sandbox libraries would also be a good idea. There is a substantial amount of work in the sandbox that might be well-suited for student projects and eventual (I hope) acceptance to Boost. In general student projects should be tightly focused with a clear set of goals to getting their work integrated into a mainline development branch (be that trunk or sandbox). In general, we've noticed that ground-up libraries almost always fail to be integrated or released independently since they require a commitment longer than the summer. There are, of course, notable exceptions to this rule. If you are going to propose a student project, please keep in mind the following things: 1. Students tend to go away in the fall. 2. If their work isn't tended after August, then it's largely forgotten 3. If the student is gone and their work is forgotten, then the project didn't really succeed. If you write down or submit a project, please include your expectations for that work. And try to keep it small. That said, if you're too precise in the specifications, we'll going to get a couple dozen proposals that simply reiterate your expectations. But that's the nature of the beast. Good ideas for projects might be: == Data Structures and Algorithms== Admittedly these have little impact on overall quality of Boost, but make a nice sandbox for students to work in and can result in surprisingly good code. Over the course of the summer 1 or 2 related data structures or a family of related generic algorithms seems to make a nicely packaged project. ==Extensions for Existing Libraries== There are a number of Boost libraries that are very amenable to extension (e.g., BGL, GIL, Math, etc.). Basically any library that doesn't have a finite feature space. Non-intrusive changes (i.e., those that don't require hacking on the existing bits) typically make good summer of code projects. == Infrastructure Projects== Projects that aren't part of Boost, but help us improve the quality of Boost might make decent projects, but we've never had one proposed or accepted that I'm aware of. Remember, we can't accept documentation projects so "Write my documents" will not be a good student project (unfortunately ;) ==Applications of Boost== This is a little different... It might be a good idea to have students build real (example?) applications that use the Boost C++ Libraries. There are a number of real benefits to having students work in this space. First, these applications are very obvious clients of Boost. They can provide immediate feedback on issues with the interface, usability, correctness, performance, documentation, etc. Second, they might make really good examples of best practice for using Boost. Third, they probably make nice student projects. If you have any ideas, let's hear them. And remember, funded projects need mentors. Andrew Sutton andrew.n.sutton(a)gmail.com

10 42