- Boost - lists.boost.org

[serialization] namespace boost
by Johan Råde 14 Feb '08

14 Feb '08

Hi Robert, I just tried compiling our app with Boost 1.35 on Visual Studio 7.1. I got a lot of errors (ambiguous symbols, conflicts between Boost and other 3rd party headers). The problem seems to be that the header text_iarchive.hpp (but none of the >40 other boost headers that I'm using) puts the content of namespace boost at global scope. Here is a simple example that reproduces the problem ----------------------------------- // Expected behavior: Should not compile // Observed behavior with Boost 1.34.1 and MSVC 7.1: Does not compile // Observed behavior with Boost 1.35 and MSVC 7.1: Does compile #include <boost/shared_ptr.hpp> #include <boost/archive/text_iarchive.hpp> shared_ptr<int> sp; ------------------------------------- --Johan Råde

4 9

Re: [boost] OSI logo?
by bwood 14 Feb '08

14 Feb '08

>> It's a privacy issue because, depending on my browser configuration, someone >> else might be able to retrace when and for how long I read the Boost >> documentation. Obviously that data is not as sensitive as my Google search >> history, but still I don't see why I need to leave behind a digital trail of my >> activity without a reason. > >I can't imagine using the web at all while being conscious of the source >URL of every embedded image, and I'm not sure it's practical to cater to >someone who tries to do it. Are you familiar with the lynx browser? It is a good one. The insist and ask bit sounds wrong to me. I suggest postponing the decision for six months. If their intentions are honorable, they will be fine with that. Brian Wood Ebenezer Enterprises

1 0

Re: [boost] [logging] Review of proposed logging library
by Tom Brinkman 13 Feb '08

13 Feb '08

>> With respect, I'm not sure there is *always* a better way than macros. For >> some applications macros provide a unique level of flexibility and >> efficiency. I'm the last person to advocate them, but when I constructed a >> logging library for our real-time scientific application, I was somewhat >> surprised to eventually figure out that logging macros *did* provide the >> best solution. So let's not discount John's effort on the grounds of >> anti-macro dogma alone, I'm sure we can find other problems ;). I'm not discounting his efforts because of macros. What I am doing is pointing that they should be de-emphaisized and are not forced on me. If I dont care about the compile-time optimizations that a macro may provide, I should'nt be forced to use them. Macros may provide some flexibility for some users, but others wont care about them and dont want to have to deal with them. The typicaly use-case of the pubic interface of a c++ logging library should not include macros. They should only be offered as optional optimizations.

6 5

Review of Logging library is in progress
by Gennadiy Rozental 13 Feb '08

13 Feb '08

Hi, To those who managed to miss this very exciting submission, I would like to encourage to find some time to invest into reviewing it. Admitedly this is very open-bound problem domain and many people have different opinions on design requirements and possible interfaces. It makes it even more important to get large number of reviewers representing wide spectrum of users base. Please let me know about any time constrains, I might try to arange for the review period extension. Here is a copy of an oroginal announcements: *Description/Motivation:* Applications today are becoming increasingly complex. Part of making them easier to develop/maintain is to do logging. Logging allows you to see what happened in your application. It can be a great help when debugging and/or testing it. The great thing about logging is that you can use it on systems in production and/or in use - if an error occurs, by examining the log, you can get a picture of where the problem is. Good logging is mandatory in support projects, you simply can't live without it. Used properly, logging is a very powerful tool. Besides aiding debugging/ testing, it can also show you how your application is used (which modules, etc.), how time-consuming certain parts of your program are, how much bandwidth your application consumes, etc. - it's up to you how much information you log, and where. *Online docs:* http://torjo.com/log2/doc/html *Download:* Package for download is available here: http://torjo.com/code/log2.zip (version v0.22.7 is targeted for review) or you can get the library from svn http://svn.boost.org/svn/boost/sandbox/logging/ *Compilation:* The Boost Logging Lib has been tested with the following compilers: VC 2005 VC 2003 gcc 3.4.2 gcc 4.1 Compiling using bjam is covered here: http://torjo.com/log2/doc/html/miscelaneous.html#misc_bjam What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * 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? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Gennadiy Rozental - Review Manager -

5 6

raw_ptr (determining interest)
by Matus Chochlik 13 Feb '08

13 Feb '08

Greetings, on second thoughts about my first post about the RawPtr I decided to do several improvements in the posted archive (now to be found in the Boost Vault in subdirectory Memory/RawPtr, file rawptr-draft.zip). Just to remind, the RawPtr library provides class raw_ptr that strives to be a safer, run-time typechecked replacement for void* (though not applicable to some uses of void*, mainly C legacy). A new cast type; raw_cast replaces static_cast when doing casts from untyped to typed pointers. As the first post has been misguiding in some points I updated the README to provide more insight into the purpose/usage, rationale, where applicable (and where not), etc. There are also two more examples that show one case where the raw_ptr can be used and one where it cannot be used. I would like to determine if there is (and also if there is not) any interest to include such library into Boost and will welcome any suggestions, hints, help or critique. Best regards, ________________ ::matus_chochlik

1 0

Trac open bugs - by assignee
by Marshall Clow 13 Feb '08

13 Feb '08

[ 209 open bugs today, 208 yesterday ] If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> and a mapping of user names to "real names" can be found at: <http://svn.boost.org/trac/boost/report/16> Bug summary 23 djowel 19 az_sw_dude 13 grafik 12 doug_gregor 12 dgregor 12 dave 11 vladimir_prus 11 agurtovoy 9 bemandawes 7 jsiek 7 anthonyw 6 no-maintainer 6 johnmaddock 5 witt 5 turkanis 5 None 4 pdimov 4 igaztanaga 3 ebf 3 danielw 2 urzuga 2 t_schwinger 2 shammah 2 rogeeff 2 pavol_droba 2 nasonov 2 kaalus 2 jmaurer 2 hkaiser 2 danieljames 2 aaron_windsor 1 speedsnail 1 samuel_krempp 1 ramey 1 nesotto 1 matias 1 marshall 1 hljin 1 garcia 1 eric_niebler 1 dlwalker None 1222 lambda::ret<T> should declare result_type. None 1493 SVN files making it through to install None 1515 [lambda] C4512 warnings from VC8.0 None 1572 [lambda] smart pointer const-ness affects its contents None 1573 Broken URL in copyright boiler-plate aaron_windsor 1622 Adjacency list needs to handle self-edges correctly aaron_windsor 778 top-level configure is broken agurtovoy 1001 gcc 4.1.2 segfaults on mpl/test/apply.cpp agurtovoy 1051 MPL header ordering triggers bug agurtovoy 1099 unable to iterate through a "non-explicitly-declared" mpl::set agurtovoy 1215 Boost 1.34.1_ mpl: Wrong workaround detection using MinGW32 (or.hpp_ line #33) agurtovoy 1317 has_xxx randomly broken in msvc agurtovoy 1469 [mpl] nested typedef of set has two different meanings agurtovoy 1476 always<> is not nullary. agurtovoy 1528 g++ 4.3.0 reports error because of redeclaration of next agurtovoy 1549 Boost.MPL: 'index_of' algorithm is not documented agurtovoy 1568 duplicate include guards agurtovoy 588 mpl::remove compile error with gcc 4.1.0 anthonyw 1154 tss destruction segfaults in conjunction with dlopen/dlclose anthonyw 1168 [thread] tss crashes randomly anthonyw 1268 xtime_cmp changes to deal with overflow were reverted anthonyw 1470 Boost.Thread: Compilation errors with non-__cdecl calling convention anthonyw 1547 [thread] error C2065: 'NULL' : undeclared identifier in thread_primitives.hpp anthonyw 876 xtime documentation incomplete anthonyw 881 errors when build with Apache stdcxx az_sw_dude 1028 typo in boost header: date_time/time_defs.hpp az_sw_dude 1078 from_iso_string cannot read the output from to_iso_string az_sw_dude 1098 Urgent libboost-date-time1.33.1 : bugs on ia64 ? az_sw_dude 1147 date_time library contains global #define ERROR az_sw_dude 1160 warning: month_format shadows a member of this az_sw_dude 1162 warning: ticks shadows a member of this az_sw_dude 1289 posix_time::time_facet forgets to pass a_ref argument to base class az_sw_dude 1299 change in typedef stringstream_type in format_date_parser.hpp causing compilation error az_sw_dude 1306 invalid docbook in date_period.xml az_sw_dude 1384 Linking problem with date_time library on Visual C++ 2008 Express az_sw_dude 1386 date_time documentation Jamfile breaks building of boost docs az_sw_dude 1524 format_date_parser.hpp(221) : cannot convert parameter 1 az_sw_dude 1574 operator<< for boost::posix_time::ptime ignores ostream flags az_sw_dude 287 wrong usage of ios_base::narrow az_sw_dude 316 date_time type conversion warning az_sw_dude 604 from_ftime incorrectly processes FILETIME filled with zeros az_sw_dude 642 operator<< for gregorian::date_duration not found az_sw_dude 889 Insane Dependencies az_sw_dude 890 date_time library supports only the current dst rule bemandawes 1378 filesystem path invalid name for hidden files (LINUX) bemandawes 1389 filesystem::ostream << boost::format generates operator ambigious error (in MSVC++) bemandawes 1458 Darwin Tiger throws std::runtime_error: locale::facet::_S_create_c_locale name not valid bemandawes 1578 bug in readdir_r_simulator() in a multi-threaded environment bemandawes 1583 Serious flaw in boost::filesystem filename handling (opensuse) bemandawes 1589 [filesystem] 'mbstate_t' : is not a member of 'std' bemandawes 1606 filesystem/src/exception.cpp doesn't build with gcc bemandawes 1613 Link Errors against file_system on OS X with Intel Version 10.1 C++ compilers bemandawes 752 directory_iterator doesn't work with catch danieljames 1554 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support new string types. danieljames 1555 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support boost::system::error_code danielw 1044 Argument pack inaccessable in a functions return type danielw 1054 Parameter takes an "infinite" amount of time to compile with the Intel compiler. danielw 1097 keyword.hpp generates many warnings C4180: qualifier applied to function type has no meaning; ignored dave 1010 linking boost.python on freebsd dave 1019 iterator_facade::pointer should be the return type of operator-> (DR 445) dave 1085 Python rules for compiling in Mac OS X dave 1179 [boost.python] can not export a union in VC2005sp1 dave 1181 [boost.python] can modify enum value dave 1387 Review / update docs to reflect changes dave 1460 Python classes with multiple bases are convertible only to the first class in the lists dave 1482 boost::python::throw_error_already_set should be marked noreturn dave 1516 [python] Failing VC9 regression tests dave 1599 [python] '_set_se_translator': identifier not found dave 865 Use of C++0x keyword as identifier dave 910 gcc strict-aliasing problems with python dgregor 1164 Floyd Warshall broken with unsigned edge weights dgregor 1192 [boostbook] problem when two files have the same name dgregor 1199 configure doesn't work with path containing whitespaces (MacOS X) dgregor 1310 [result_of] const-qualified function pointer doesn't work dgregor 1326 Unable to check graph isomorphism using LEDA adapter dgregor 1391 dominator_tree_test on Borland/CodeGear outputs overly long line dgregor 1394 Translate libs/graph/build/python/Jamfile to BBv2 dgregor 1395 Write Tests for Python Bindings dgregor 1630 gcc-4.3: adjacency_list.hpp includes deprecated header dgregor 556 Bundled graph properties dgregor 732 Johnson All-Pairs needs better "no path" information dgregor 736 Const correctness violation djowel 1170 Emit Warnings instead of # symbols in the syntax highlighter djowel 1171 Quickbook title output djowel 1172 non-utf djowel 1176 Space after inline code djowel 1206 Escaping from within code? djowel 1273 CR+LF newlines in position_iterator djowel 1276 spirit problem with _GLIBCXX_DEBUG djowel 1277 Closing section like [pre with } causes Quickbok to crash djowel 1280 sections in imported source files get put inside <para> elements in docbook output djowel 1281 Quickbook produces invalid BoostBook/DocBook XML djowel 1324 tuple should have a swap() that operates element-by-element djowel 1396 wrong result_of invocation around transform_view djowel 1436 [quickbook] inline code inside headings djowel 1484 Quickbook produces illegal docbook for some docinfo fields. djowel 1500 [Spirit/Phoenix] C4512 Compiler warnings from VC8 djowel 1570 Some boost headers aren't ready for gcc 4.3 djowel 1600 duplicate include guard djowel 1601 distane of boost::tuple djowel 1607 Tuple Library Documentation Changes djowel 1610 [MSVC/STLport] [tree/common.hpp] Standard library requirements violation(incomplete type as vector parameter) djowel 1614 vector workaround needed for MSVC9 djowel 1617 spirit gcc-4.3 fix djowel 1619 [Fusion] C4512 warnings from VC9 (Visual Studio 2008) dlwalker 613 boost/crc.hpp uses non-standard conforming syntax doug_gregor 1021 [Graph][reverse_graph] Problem using reverse_graph adapter with an adapted user defined graph doug_gregor 1076 compile error: disconnecting struct with operator()() doesn't work in VS2005 SP1 doug_gregor 375 LEDA graph adaptors do not handle hidden nodes properly doug_gregor 402 random_vertex/random_edge are unnecessarily inefficient doug_gregor 403 Document copy_component doug_gregor 447 reverse_graph and constness of property maps doug_gregor 708 Dijkstra no_init version should not require VertexListGraph doug_gregor 733 Numbered headers don't work with "preferred" syntax doug_gregor 735 Fruchterman-Reingold grid performance can be improved doug_gregor 738 Memory leaks with signal::connect? doug_gregor 829 Implicit graph not implement doug_gregor 852 Problem with Boost and GCC 4.1 ebf 1507 [variant] C4512 warnings from VC8.0 ebf 1548 [variant][docs]typo: formal arg_ operand_ should be v in times_two arglist ebf 993 Variant should use least common multiple of alignments_ rather than maximum eric_niebler 1631 [accumulators] compiler warnings with VC9 + warning level 4 garcia 1581 Boost.MultiArray: Resizing bug if the index is not 0-based grafik 1041 Cygwin requires PATH setting. grafik 1322 trac rejects patch attachment as spam grafik 1417 Regresson tests hang in Darwin (Tiger) grafik 1430 Regression fails under Cygwin grafik 1433 Trac's spam detection rejects too many valid messages grafik 1512 Broken link to vacpp in bjam docs. grafik 1513 Broken link to bcpp in bjam docs. grafik 1571 boost bugtracker displays a patch incorrectly grafik 1576 cannot read non-ASCII output messages grafik 1577 Some commands don't work because hStdInput == 0 grafik 616 Boost Jam_ and non english directorys grafik 959 linking fails when Boost is compiled with STLport 5.1.* on Linux (names mismatch) grafik 986 Problem building Python modules on boost 1.34.0 hkaiser 1079 boost-1.34.0 fails to compile. concept checks not satisfied. hkaiser 1603 Compile Error: cpp_expression_value.hpp - is_int_ is_bool_ is_uint undeclared hljin 1522 bit_range friend decl in bit_aligned_pixel_reference.hpp needs to be fully qualified for gcc 4.3 mainline igaztanaga 1080 boost::interprocess win32 global file mapping issue igaztanaga 1210 interprocess::barrier hangs during second use under linux (boost 1.33.1) igaztanaga 1390 Interpocess: managed shared memory failing completely under OS X igaztanaga 1634 boost::interprocess::vector cannot contain volatile int jmaurer 351 Diff in state of mersenne_twister gen between GCC3.41 & CW9 jmaurer 599 uniform_01 copies engine instead of using a reference johnmaddock 1081 Empty string rejected as perl-style regex johnmaddock 1314 Using SSE-intrinsics in VC8 causes static assert in type_with_alignment.hpp johnmaddock 1411 Fix BOOST_PARTIAL_SPECIALIZATION_EXPLICT_ARGS johnmaddock 1446 POSIX API doesn't use C locale johnmaddock 1451 error: use of C99 long long integer constant johnmaddock 1626 [type_traits] "bad_alloc is not a member of std" in has_virtual_destructor_test.cpp jsiek 1531 segfault in dynamic_bitset::reference assign operator jsiek 1540 Poisson distribution very slow for large mean (and may also overflow). jsiek 575 Calling subgraph::global_to_local on a root graph jsiek 636 strange compiling problem for transitive_closure jsiek 815 remove_edge core dumps on self-circle jsiek 875 No iterator based constructor for adjacency_matrix jsiek 900 graphml reader namespace handling is broken kaalus 1184 property_tree assignment (operator) bug kaalus 1604 property_tree xml parser doesn't compile with gcc marshall 1252 [pool] severe overhead with unaligned sizes. matias 1406 Understanding the Tables outdated nasonov 1220 lexical_cast requires RTTI nasonov 754 boost::any - typeid comparison across shared boundaries nesotto 1629 range/iterator_range.hpp bug no-maintainer 1068 Mersenne twister disables streaming for Visual C++ no-maintainer 1270 uniform_smallint doesn't compile with lagged_fibonacci random number generators no-maintainer 1544 uniform_01 w/ref template param causes ref to ref error no-maintainer 1546 Method boost::random::uniform_int::operator()(engine_ value) is missing no-maintainer 1632 Default Interval rounding policies incomplete no-maintainer 819 uniform_int<> with type's maximum availaible range error pavol_droba 1152 rle_example fails pavol_droba 1385 begin must be boost-qualified pdimov 1106 shared_ptr<T> should not convert to shared_ptr<U> when T* doesn't convert to U* pdimov 1444 scoped_ptr::operator== should be equivalent to a.get()==b.get()_ but is currently !!a==!!b pdimov 1590 shared_ptr documentation inconsistency pdimov 779 gcc-4.2 atomicity.h location ramey 1628 Lack of wide character support prevents boost.serialization from linking rogeeff 1383 signal.h features not found on Mac OS rogeeff 1542 [test] compiler errors when building with stdcxx library samuel_krempp 859 boost::format ignores a user defined locale shammah 290 perfomance: memory cleanup for pool takes too long shammah 386 boost::pool_allocator breaks with vector of vectors speedsnail 1138 Problems with TSS and static thread library t_schwinger 1100 Building boost.function_types fails cvs rev-1.1_ no chdir command in bash t_schwinger 1602 function_types Jamfile depends on the source tree being in a specific place. turkanis 1523 [iostreams] VC8/VC9 compiler warnings turkanis 1545 [boost/rational.hpp] 'noskipws' is not a member of 'std' turkanis 1579 gzip compressor should model DualUseFilter turkanis 1580 Add static assert to prohibit instantiating a chain with mode dual_use turkanis 1624 consider making chain/filtering_streambuf/filtering_stream closable urzuga 574 [boost::lambda] Compile error with libstdc++ debug mode urzuga 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile vladimir_prus 1165 more quoting problems vladimir_prus 1274 Useless error message vladimir_prus 1321 invalid docbook in tool documentation vladimir_prus 1527 [program_options] Second (and subsequent) lines in tabbed text not aligned correctly vladimir_prus 1530 Program options documentation - Overview - Syntactic Information example typo vladimir_prus 1537 no value given in 'mysql_password =' vladimir_prus 1584 cryptic bbv2 error building quickbook vladimir_prus 1587 [program_options] crashes if value part missing in external configuration file vladimir_prus 1588 [program_options] crashes if value part missing in external configuration file vladimir_prus 469 multitoken broken vladimir_prus 689 [program_options] Endless loop with long default arguments witt 1046 Boost.Python quickstart instructions mention nonexistent target witt 583 Fixes for build on IBM pSeries for AIX and Linux witt 834 Homepage regression links witt 957 The "Getting Started" page does not mention the stdlib option witt 973 zip_iterator has value_type == reference -- -- Marshall Marshall Clow Qualcomm, Inc. <mailto:mclow@qualcomm.com> The famous British scientist, Lord Kelvin, said: "When you measure what you are speaking about and express it in numbers, you know something about it, but when you cannot (or do not) measure it, when you cannot (or do not) express it in numbers, then your knowledge is of a meagre and unsatisfactory kind."

1 0

[logging] Review of proposed logging library
by Arnstein Ressem 13 Feb '08

13 Feb '08

I have reviewed the current logging library. Some of my functional requirements are: - different writers: stdout, file, rolling file [OK] - possibility to dynamically change log levels [OK] - logging from separate modules of the code with annotation [OK] - filtering based upon modules and levels [OK] - possibility to adjust log levels for modules separately [OK] - logging statements for non enabled levels should not be evaluated [OK] - thread safety when logging from different threads [OK] - configuration from configuration file(s) [NOT OK] - logger hierarchies with property/config propagation [NOT OK] - possibility to use printf syntax when logging [NOK OK] * What is your evaluation of the design? The logging library is very flexible and usable. It is possible to integrate the library by using different levels of detail. In it's simplest form it is very easy to use. When trying to use the more advanced parts of the library, the learning curve quickly becomes steeper (but manageable). The logging library also allows to trade off flexibility to performance. The flexibility allows the user of the library to write small pieces of code that can be used to implement application specific requirements. This is important because logging requirements will vary largely between applications. The major parts missing are logger hierarchies with support for configuration propagation and configuration of these hierarchies from config files. This is a feature supported by the C++ equivalents of log4j. The design in terms of classes and files seems fine by me. I like that the library is headers only. The use of macros will always be a discussion point, but it is convenient for a logging library. I do not have big issues with this. The separation of loggers, filters, formatters and writers appeal to me. Splitting the headers into forward declarations and definitions is very good to reduce compile time for big projects. * What is your evaluation of the implementation? I have only had a brief look at the internal implementation. Extensive use of templates and name spaces (too much?). The author seems very knowledgeable of C++ and the logging domain. * What is your evaluation of the documentation? Thorough documentation with a lot of examples and tutorials. I was able to find what I was looking for most of the time. Maybe a bit of reorganizing is needed because the front page seems a bit overwhelming at first. Formalization of some sentences and comments would be nice if the library gets accepted into boost. * What is your evaluation of the potential usefulness of the library? Very useful. A good standard logging library is needed. There are a lot of logging libraries out there, but their user bases and vitality differ greatly. Having boost::logging would make the decision of which logging library to use easier for a lot of developers. I would expect that the user base of this library would rapidly grow larger than a lot of other logging libraries. * Did you try to use the library? With what compiler? Did you have any problems? I compiled the tests on CentOS 5 x86_64 with gcc 4.1. Gcc issues some warnings about not having virtual destructors and sign mismatches. After scanning the review threads these seems to be fixed in the svn trunk. I had one test fail (testing.capture-output), but did not investigate this any further. I also did a quick spin with valgrind (3.3.0): valgrind --tool=memcheck --leak-check=full ./mul_levels_one_logger Valgrind reports a lot of conditional jumps/moves based upon uninitialized values and usage of uninitialized variables. This has to be fixed. I adapted one application to use the boost::logging. The library seems to work as advertised, but I had to write some filter code to adapt the logging to the functionality needed (module annotation with different log levels in each module). * How much effort did you put into your evaluation? I put about 6 hours into the evaluation. * Are you knowledgeable about the problem domain? I believe so. I have used different logging libraries and have written wrappers for applications. * Do you think the library should be accepted as a Boost library? Yes, but compiler and valgrind warnings has to be fixed before submission. Also all the tests must be verified to run without errors on all supported platforms. A big thanks to John for putting the effort into making a useful logging library. Regards, Arnstein

3 4

Proposed Logging Library review
by Amit 13 Feb '08

13 Feb '08

> * What is your evaluation of the design? I think the library is overdesigned, learning curve is too shallow & very difficult to comprehend for a casual user. Author has persevered with the notion of employing namespaces to encapsulate concepts - this leads to a profusion of unrelated names & types, apart from the arguable soundness of this approach. I reckon that the problem is that the author has designed the library to make complex tasks easy - e.g. if you wanted to use multiple filters controlling logging to mutiple destinations, this is probably the only library that would help you. But the cost of that power is that typical usage has become too complicated. > * What is your evaluation of the implementation? Unwieldy & too reliant on preprocessor macros. Namespaces are over-used. Some important considerations have been overlooked (e.g. output encoding, state of the log destination, automatically logging exception conditions). But I am using code from the library just for the ability to log on a dedicated thread (with some changes). This alone is worth persevering with the library. I am satisfied that the code itself is stable and largely error-free - it has been running on a live web-server for a week now, without any issues (fingers-crossed). > * What is your evaluation of the documentation? Comprehensive, but too informal. Ultimately insufficient to aid in understanding the implementation/usage details of the library. But my point is that the implementation is so scattered that any amount of documentation might be insufficient. > * What is your evaluation of the potential usefulness of the library? I think that with a simplified design, discarding of maybe 25 out of the 30+ namespaces used, automatic defaults for typical tasks, no reliance on macros, this would be a very useful library for almost all C++ developers. > * Did you try to use the library? With what compiler? Did you have any > problems? I did & do use it. ICL 10.1 on XP. I have interacted with the author to get some issues solved. I had to change the stream class to accept a flag that flushes on every write, when logging on a dedicated thread. Also, logging to file, cout etc are not possible with this library if the required code conversion is not supported by the locale. I attempted to create an object encapsulating the logger and the filter (since the library does not intend to provide one) but could not since the return type of the overloaded destination::<< is implicit - author did try to help but his suggestion did not work. > * How much effort did you put into your evaluation? A glance? A quick > reading? > In-depth study? All of the above, + 1 week integrating the library into my application. > * Are you knowledgeable about the problem domain? I am now :-) > > And finally, every review should answer this question: > > * Do you think the library should be accepted as a Boost library? > Be sure to say this explicitly so that your other comments > don't obscure your overall opinion. Not in its current form. Withsupport for output encoding, provision for objects so user can just include the library and start dumping messages with having to create irrelevant objects (like optimized string - optimized for what? how?), the lib would have my unqualified support. I look forward to the outcome of the review, and offer my services for testing any revised implementations. Best Amit

4 6

Re: [boost] [logging] Review of proposed logging library
by Tom Brinkman 13 Feb '08

13 Feb '08

I dont deny that macros could be useful in some circumstances in a logging library. However, lets not optimize the library with macros to soon until the c++ interface is correct. I cant tell -- this library forces macros on me from the very start.

1 0

[logging] Review of proposed logging library
by Tom Brinkman 13 Feb '08

13 Feb '08

>> possibility to use printf syntax when logging [NOK OK] Agree. >> The use of macros will always be a >> discussion point, but it is convenient for a >> logging library. I do not have big issues with this. I would like to see us push our selves harder here. This is "boost" after all, whose developers and users, fret for hours on the miniutia of the perfect interface. The logging library is no different than other libraries. All of us have though at one time or another having just this "one" macro wont make that much of a difference. A little more exploration and discussion of our interface goals always reveals a better way. Lets not settle. John is clearly motivatated to create a great logging library that useful for all c++ developers. Lets get behind this effort and help him get there between this review and the next one (if there is one). Tom Brinkman

4 3