February 2008 - Boost - lists.preview.boost.org

Logging library review extension is at it final day
by Gennadiy Rozental 18 Feb '08

18 Feb '08

Welcome everyone to the last day of the official review of proposed Logging library. I would like to encourage anyone interested in this very important and complex problem domain to invest some time and give this submission a shot. Whether you are novice developer looking to use logging facility or experienced designer developed it once or twice already, your opinion is valuable. Here is the links to the online docs http://torjo.com/log2/doc/html and package for download http://torjo.com/code/log2.zip. This is the point when you shouldn't leave it for later. If you care to be heard, we need to hear your voice now. Gennadiy Rozental - Review Manager -

2 1

Logging Library Review
by Christian Holmquist 18 Feb '08

18 Feb '08

Logging library review This is my first boost review, so could be it lacks a lot of things.. * What is your evaluation of the design? IIUC, the library provides a flexible solution to compile-time definitions of different loggers. IMO, this is rarerly the case. What should be configured at compile time are the tags (or simplier, the message type). All the rest, destinations, formats, interval, caching, etc is not the responsibility of the programmer defining the log, this is the responsibility of some other programmer using the first programmers library, or the customer using the first programmers application. Destinations will be added at runtime (such when opening a telnet console, typing 'enable-log debug' or similar), configured at runtime, removed at runtime. These scenarious are not even discussed, which make me doubt the library. It seems that formatters are attached to the top level writer object, is this the only way? The formatted message may need to vary for different destinations. I would typically have the file logs to include more data (tags, if you will) then the console destination, making it easier to read the console for human eyes(no timestamps, codelines, etc). If there are some data missing while I look at the console, I would at runtime change the formatter to include some more. * What is your evaluation of the implementation? Didn't look much, but I'm strongly against configuration macros and small utility macros for things that could be written without them. * What is your evaluation of the documentation? I share the same opinion about the documentation as others have already said. It's confusing to read, and sometimes I think that the library is more useful than the documentation makes it, but I'm not convinced. * What is your evaluation of the potential usefulness of the library? A logging library is indeed very useful, I am not sure about this one though. I don't agree with other reviewers that boost must have a logging library for its own sake. With spirit, for instance, I can enable logging to std::cout perfectly for debugging my grammar, no need for very large frameworks for that. Talking about which, how would that work with the proposed library? * Did you try to use the library? With what compiler? Did you have any problems? Tried some of the samples with vc8, no problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Read the documentation a couple of hours and looked at the examples. * Are you knowledgeable about the problem domain? Yes. I've written and maintained a log library that's been running for many years. * Do you think the library should be accepted as a Boost library? No, sorry. Could be that the flexibility and customization I am looking for is in there already, but the documentation is written with other scenarios in mind than I have. It should be addressed how the logging library will be configured when used in: * an external header only library (ex, spirit). * an external compiled static library (ex, serialization.lib). * an external compiled dynamic library (ex, serialization.dll/so). * an application, that is shipped/sold to third party. * an application, where destinations are added/removed at runtime from multiple threads. To me a logging library plays a very important role in large software projects since it becomes a part of the interface of an application, note merely being a building block for the programmers behind the application (like std::vector<> for instance =). What is goal of the library? Regards, Christian

1 0

Logging Library Review
by Jamie Allsop 18 Feb '08

18 Feb '08

Before I give my review I want to point out that I have been using John's first logging library (with several key modifications) in production for a couple of years now. On the whole it has been quite a good library. Apart from allowing definition of logs in header files only I did not have too much difficulty massaging it to fit my needs. My approach to looking at this newer version of the library was to see if I could use it in a way that is similar to how I have used the first version. In addition I also wanted to see if it was possible to move past limitations I encountered in the first revision. Therefore with this review I'll point out what I tried to do with the library to put into context my later comments on it. Now for me I see logging as a very important library. There are plenty of options out there and many of us will have written our own at some point or other. With that in mind I feel that a logging library in boost is simply not about providing a library that allows logging. It is about tackling and solving the most critical aspects that any logging library will address, and providing a good interface on which to build more complex libraries related to logging. If a logging library is to be added to boost, then 'good enough' is simply not good enough. If I wanted 'good enough' I can write my own or choose from many of the libraries out there (including this one). So what are the minimum requirements? Well certainly there are a few and there is a good attempt at capturing them here <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Logging> For me though I wanted to be able to a couple of things and my efforts at using the library are focused on these. Essentially I wanted to be able to cheaply define logs in different scopes in what I would term library code. Therefore users of the library must be able to use the libraries without logging enabled and pay no cost. The fact that I have logging statements within my code should be transparent to them. At the log site I want to be able to write something like this (or even better, don't use a macro): BOOST_LOG(info) << "Some message" << std::endl; or perhaps BOOST_LOG(info,some_log_name) << "Some message" << std::endl; A number would also be sufficient instead of a level. This would be my default usage. Now I would like the client of the library to be able to enable and disable my logs in a simple fashion, for example using something like, boost::logging::enable_logs( "libraryx.*" ); Finally I'd like the client to specify what actually gets logged and in what format, things like, time level thread file line function That iwa my basic requirement. I tried to achieve this with this library. Now it is not actually possible to do that with this library in a convenient way because this version, unlike the last, does not support the notion of named logs in hierarchies. Having said that I had a go anyway to see how far I could get. I should also point out that I wanted as painless a way as possible of using logging (please see past my macro examples... that's what I started with in this library so it is hard move away from that) --- for adding log messages --- 1. #include <boost/logging/logging.hpp> 2. BOOST_DEFINE_LOG_IN_CURRENT_SCOPE or BOOST_DEFINE_NAMED_LOG_IN_CURRENT_SCOPE(some_name) 3. BOOST_LOG(level) << "message" << std::endl; --- for outputting logged messages --- 1. define a preferred format or simply take a good default 2. say where you want to log to 3. enable the logs you want --- I ended up writing a small file, <boost/logging/default.hpp> which basically provided wrapper macros for the ones that John has in his library. Here is what I put in it. ----------- #ifndef INCLUDED__boost__logging__default_HPP #define INCLUDED__boost__logging__default_HPP #include <boost/logging/format_fwd.hpp> #include <boost/logging/tag/high_precision_time.hpp> #include <boost/logging/format/formatter/tags.hpp> #include <boost/logging/format/formatter/high_precision_time.hpp> #include <boost/logging/format/formatter/named_spacer.hpp> namespace { typedef boost::logging::tag::holder < boost::logging::optimize::cache_string_one_str<>, boost::logging::tag::high_precision_utc_time, boost::logging::tag::level, boost::logging::tag::file_line, boost::logging::tag::function, boost::logging::tag::thread_id > default_tag_holder_string_t; } BOOST_LOG_FORMAT_MSG( default_tag_holder_string_t ) #define BOOST_LOG_DEFINE_LOGGER(name)\ BOOST_DEFINE_LOG(name,boost::logging::logger_format_write<>) #define BOOST_LOG_DEFINE_FILTER(name)\ BOOST_DEFINE_LOG_FILTER(name,boost::logging::level::holder) #define BOOST_LOG_ADD_DEFAULT_FORMAT_TO_SCOPE(logger_scope)\ logger_scope::logger()->writer().add_formatter\ ( boost::logging::formatter::named_spacer\ ("%time% %level% %file_line% {%function%} [%thread_id%] ")\ .add( "time",\ boost::logging::formatter::\ high_precision_utc_time\ ( "$yyyy-$MM-$dd $hh:$mm:$ss.$micro" ) )\ .add( "level",\ boost::logging::formatter::tag::level() )\ .add( "file_line",\ boost::logging::formatter::tag::file_line() )\ .add( "function",\ boost::logging::formatter::tag::function() )\ .add( "thread_id",\ boost::logging::formatter::thread_id() ) );\ logger_scope::logger()->writer().add_formatter\ ( boost::logging::formatter::append_newline_if_needed() ); #define BOOST_LOG_ADD_FILE_DESTINATION_TO_SCOPE(logger_scope,name)\ logger_scope::logger()->writer().add_destination\ ( boost::logging::destination::file( name ) );\ logger_scope::logger()->mark_as_initialized(); #define BOOST_LOG_ADD_DESTINATION_TO_SCOPE(logger_scope,type) \ logger_scope::logger()->writer().add_destination\ ( boost::logging::destination::type() );\ logger_scope::logger()->mark_as_initialized(); #define BOOST_LOG_DEFINE_LOG_IN_CURRENT_SCOPE\ static BOOST_LOG_DEFINE_LOGGER(logger)\ static BOOST_LOG_DEFINE_FILTER(filter) #define BOOST_LOG(the_level)\ BOOST_LOG_USE_LOG_IF_LEVEL\ ( logger(), filter(), the_level ) \ .set_tag( BOOST_LOG_TAG_LEVEL(the_level) ) \ .set_tag(BOOST_LOG_TAG_FILELINE) \ .set_tag(BOOST_LOG_TAG_FUNCTION) #endif // INCLUDED__boost__logging__default_HPP ----------- Ok, that's pretty hideous and I really don't like using macros, however it did allow me to add reasonable default logging. For example I can now write, --- #include <boost/logging/default.hpp> struct some_class { BOOST_LOG_DEFINE_LOG_IN_CURRENT_SCOPE inline void some_method() { BOOST_LOG(info) << "message" << std::endl; } }; --- To use the log I now write in some initialisation method elsewhere, --- void another_class:: initialise_logging() { boost::filesystem::path ExecutablePath( boost::filesystem::initial_path() ); boost::filesystem::path LogPath( ExecutablePath / "logfile.log" ); std::string LogFile( LogPath.string() ); BOOST_LOG_ADD_DEFAULT_FORMAT_TO_SCOPE (some_class) BOOST_LOG_ADD_FILE_DESTINATION_TO_SCOPE(some_class, LogFile); } --- For every log I want to use I have to add more entries, making this function very long for any remotely complex application. I am not advocating this. I'm merely pointing out that for the usage I was looking for, this library made it hard. In fact I wasn't able to use it as I had hoped and the only way I could get somewhat close was to write yet more macros. I believe this example is important because I see this as probably the most basic use of the logging library beyond simply writing to file directly (or std::cout or anywhere else for that matter). What I presented above is not acceptable, but I do believe the author has the ability to address these issues. In essence I think the above example should be very easy to write, with as few lines as possible and *only* use macros where absolutely necessary. It should be acceptable to use in library code with no impact on performance when logging is disabled. Advanced users with special requirements are then of course welcome to explore the customisation and extension points of the library. Some common customisations and extensions should be provided. Ok, with that context to my review behind us, I'll move onto the review proper. * What is your evaluation of the design? The design as it currently stands does not allow for the simple use case I outline. That does not mean I think it is failed but I do think it shows some important aspects of the design wanting. I do believe this can be addressed. --- As another reader noted concepts are not namespaces. I have no problem with grouping models of the same concept into the same namespace but that is not the same thing. Importantly concepts are named differently than namespaces. I encourage the author to look at how concepts are used in the standard and try to follow that convention. For example 'writer' is an ok name for a namespace but the concept is probably better named MessageWriter. I believe that the concepts used throughout the library could be better named to provide better clarity. I actually found the naming somewhat confusing at times. --- The omission of log hierarchies, or something that allowed the manipulation of several logs at one time, is an unfortunate omission and forced the library to be particularly heavyweight to use. --- Macros were relied on too much, and I realise the author has agreed to address this concern. --- I felt in general the organisation of the library was lacking and some of the defaults surprised me. If a library is to become part of boost one must expect it to work well with other parts of boost. - the default time handling should use the date_time library with easy selection between local time and UTC (which is often preferred) - threading should use the threading library, there should be no roll-your-own code in this important part of the library - the default path should be boost::filesystem::path --- Log Levels: Logging levels should be expressible as both numbers and names (maybe it is and I missed it). It should be possible to provide different name mappings easily (again maybe it is). The set of default levels should be more comprehensive to support a better out-of-box experience and the syslog levels should be part of that set. From <http://tools.ietf.org/html/rfc3164> Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages I'd suggest adding also, Fatal Severe Notable Verbose Detail Trace These could be ordered as: Fatal Emergency Alert Critical Severe Error Warning Notice Notable Informational Debug Verbose Detail Trace or some could simply be aliases for others. Regardless I shouldn't need to make modifications to use these common names. I'm not suggesting they all be used, simply that they are available. --- The rolling_log is not as I would expect. In most cases where I have used this I have a naming scheme that places the most recent log as the default log name and older logs should have numerically increasing names. Improving the rolling log behaviour should not pose any real difficulties. --- I got bitten by forgetting to use 'mark_as_initialised()'. This seemed symptomatic of the library as a whole. It was very easy to screw up. That implies to me that the interface was not clean enough, or more especially the default use relied on interfaces with too many variation points making it to easy to make a mistake. --- I am concerned about other aspects of the library, but most of these are covered in other reviews. Apologies for not recounting them here, but my time is short. I would say that I would like to see some co-operation between John and Andrey Semashev or at least some of the discussion from Andrey's review explored further particularly with regard to attributes. I am not saying I agree with Andrey, I am merely saying that it would be nice if some more concrete conclusion could be reached. I recognise also that there is likely no one best solution. * What is your evaluation of the implementation? The implementation needs tidied up. I realise this is a work in progress so that in itself is not a big criticism. The code is somewhat dense, hard to read, and the author seems averse to names which spell out what he means. I really see no need for short and cryptic names. Other reviewers have mentioned other things like line lengths and so on. As a side note I strongly encourage the author to install VirtualBox or similar on his Windows machine so he can install Linux as an alternative platform to try this on. * What is your evaluation of the documentation? The documentation has already been discussed at length regarding use of language structure and so on. I'd like to add my voice to those that wanted a clearer structure with more formal language. I'd also like to see that the documentation is easier to navigate. I saw no way to step through topics without having to go back to the main contents page. Some performance comparisons with other libraries may be in order. I am most interested in the case of disabled logging. Once I am actually logging something I am less concerned. At that time I care most about the information I log more than how quick it was (but of course quicker is better). One to three letter names in examples are not acceptable. What does g_l mean? I can *only* guess. * What is your evaluation of the potential usefulness of the library? This is a very important library of immense potential use. Moreover, if for some reason any future boost library itself was complex enough to warrant adding logging to, then this would be the library used. Of course that puts it into the same category as Boost.Test in terms of stability and core 'fit-for-purpose' needs. * Did you try to use the library? With what compiler? Did you have any problems? Yes, gcc 4.2.3, Debian Sid. I didn't encounter any real problems that haven't already been addressed in other reviews. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I added logging to a new project and used the log files produced to help track down a problem. I spent time trying to use the library and read the docs to help me with that. I spent a little time looking at the implementation to see if I could make small changes to enable capabilities I saw lacking. * Are you knowledgeable about the problem domain? Somewhat. * 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. I've been very encouraged by John's willingness to take on board suggestions and criticisms of his library. His clear enthusiasm to produce a great logging library is very evident. In many ways I'd like to vote yes and let John simply address all the concerns of the library (as he appears both capable of and willing to do). However I think this library is just too important for that to be acceptable. There are other efforts to produce a logging library for boost but so far only John has managed to get a library to review, twice. By and large both libraries have been good ones but both fell short for one reason and another. I think both John and the community has learned a lot from these reviews. I know I certainly learned of some use cases that I had never thought of. I do think John will be able to address most if not all of these with his library. What I would like to see, if possible, is for some of the current efforts on logging to learn from this review and either, join with John to help produce a better library, or get their library ready and into the review queue. As I said at the beginning I have been using John's previous library for some time now and with some success. This new library departed from the first revision perhaps too far for my liking, but once again John has encouraged a good discussion on the topic of a boost.logging library. This is all a very round-about way of saying that I vote Not To Accept this library into boost. But I would like to qualify that. I think the changes that John needs to make are too numerous to warrant a 'yes and tidy-up' vote. I believe there has to be another review. I would be very confident though in a positive outcome of such a review (from my perspective) if John succeeds in addressing the issues raised during review. This can only lead to a better library. I therefore encourage John not to wait too long before asking for his changes to be given a review. I'm sure it won't be a problem getting a review manager. Jamie

1 0

[flyweight] Review summary
by Ion Gaztañaga 17 Feb '08

17 Feb '08

Hi to all, I've just written a summary of the flyweight review that tries to point out the main requests, questions and comments from reviewers and Joaquin's replies to those. If someone thinks I've missed some important point, please let me know. Joaquín is already correcting the pointed issues and thinking about alternatives on the keyed_flyweight issue. I hope we can definitely solve them satisfactorily in a short period of time. Here we go: -------------------------- Beginning of summary -------------------------- ------------------------- *Tim Blechmann’s review:* ------------------------- Design: Good. Suggests using read-write locks to improve concurrency since most operations will be searches. Implementation: fine Documentation: good Usefulness: quite useful to reduce memory footprint. Try to use the library: no Effort: Read documentation and compare it with his own implementation Knowledgeable about the problem domain: yes Accept the library: yes This reviews starts a thread about the correct read-write lock implementation for flyweight: 1) Joaquín points out that the library is based on insert(x) so a good candidate can be: readwrite_lock l(mutex); l.read_lock(); if(h=find(x))return h; else{ l.unlock(); l.write_lock(); h=insert(x); } Unfortunately read-write locks were removed due to a bug so this issue will be put under Future Work section for now. 2) Alberto Ganesh Barbati: suggests using hinted insert to improve performance in cases where find(x) fails and try to get a O(1) insertion. He also suggests using promotion or/and upgradable mutexes. 3) Joaquín thinks promotion/upgradable mutexes are not necessary. Read-write locks/upgradability/hints will need more thinking to maintain current policy orthogonality and the issue needs time. As mentioned, the issue will be revised when rw locks are available in Boost. Review manager note: I think that using “hint” needs atomic convertibility, because the “hint” can be invalidated by an erasure between unlock_sharable() and lock_sharable() and hint insertion does not guard against invalidated hints, but only against non invalidated but non-optimal hints. ------------------------- *John Reid’s review:* ------------------------- Design: Very good. Suggests intermodule_holder as the default holder. Implementation: Ok. Documentation: Clearly written and well thought out. He would like to see more examples and the inclusion of test code. Usefulness: High Used the library: No Effort: A quick read through the tutorial and the examples Knowledgeable about the problem domain: Not a design patterns expert but using C++ for 15 years. Accept the library: yes 1) Joaquín replies that intermodule_holder performs a way more expensive static initialization process than static_holder (needs shared memory). Another reason for not including this is that Boost.Interprocess (on which intermodule_holder depends) is not universally supported. Agrees to improve examples. 2) John suggests documenting intermodule_holder limitations 3) Joaquín agrees documenting these limitations ------------------------- *Marcus Lindblom’s review* ------------------------- Design: Very nice. Comments: namespace should be boost::flyweight. Factory should be called store Implementation: Not looked at thoroughly. Documentation: Great! Comments: the reference page, the first header ("boost/flyweight.hpp") doesn't link to anything? flyweight.hpp page misses to mention the tag argument in the first list of parametrization. Usefulness: High. Used the library: Nope. Effort: Quick reading. (1h) Knowledgeable about the problem domain: Yes Accept the library: Yes 1) Joaquín says that namespace issues are related to compiler bugs and the namespace conforms Boost rules explained at "For those who are really interested in namespaces" at http://tinyurl.com/ywb9n7 Factory name was chosen because most descriptions of the flyweight design pattern use this same terminology: http://tinyurl.com/ys5k3q Agrees to fix documentation problems with Firefox. ------------------------- *Matias Capeletto’s review* ------------------------- Design: Great. Implementation: Quick look. Documentation: Good. Typo spotted. Usefulness: High Used the library: gcc 4.1.3, under Linux Effort: Followed the library progress from the beginning Knowledgeable about the problem domain: Yes Accept the library: Yes 1) Joaquín: Typo fixed David Sankel’s review Design: Very well designed. Suggests a configuration option for equality segmantics. Implementation: He hasn't looked at much code, so I have no opinion here Documentation: Good Usefulness: Good Used the library: No Effort: An in depth study of the documentation Knowledgeable about the problem domain: Not until this review Accept the library: Yes 1) Joaquín says it’s trivial to override the default equality on a per case basis: typedef flyweight<whatever,...> fw_t; inline bool operator==(const fw_t& x,const fw_t& y) { return &x.get()==&y.get(); } ------------------------- *Vicente Botet’s review* ------------------------- Design: Good. Issues: * The tests performed on example5 should be extended with a intermodule_holder specifier. Joaquín’s answer: there is no need for that since it’s only performed in the initialization. * On platforms on which static variables are unique inter DLL the intermodule_holder specifier type can be a static_holder_class. Joaquín’s answer: Ok. * Holder specifier renaming. Maybe static_holder by module_holder, and intermodule_holder by process_holder? Joaquín’s answer: Agrees to revise names but he’s not found good alternatives. * Add an exclusive core specifier Joaquín’s answer: Added to Future Work section. Implementation: Quite good * Minor correction The documentation states that the ..._specifier must be a ..._marker, but this is not needed for the ..._class Joaquín’s anwswer: This ability used to be documented at the reference, but I've just checked and it is no longer there, I'll restore that bit. * refcounted_value is a class that could be public. Why it is declared in the namespace detail. Joaquín’s answer: It is an implementation detail, the user won't ever be exposed to it. * could you explain why detail::recursive_lightweight_mutex is needed and boost::detail::lightweight_mutex is not used directly? Joaquín’s answer: Recursive mutexes are needed when constructing composite complexes with flyweight<>. Documentation: Good. Issues: * Some more elaborated examples suggested. Joaquín’s answer: I'll try to extend the examples section. * intermodule_holder specifier: A reference to a document explaining the problem with platforms not ensuring the unicity of static variables when DLL are used will be welcome. Joaquín’s answer: I'm no expert here, but I'd say that platforms without static var unicity across dynamic modules are the majority rather than the exception. * Reference section: The reference section was much more hard to follow. I think that the interactions between the different classes are very hard to describe using the current style. Joaquín’s answer: It tries to keep the level of formality you find at the C++ standard. The idea is you go to the reference for exact, authoritative information. * An implementation section will help to understand how all this works, describing the interactions between the core and the policies. Joaquín’s answer: I'd much prefer to concentrate on improving the part on extending the library without disclosing too much about how things are assembled internally. * Add performance section Joaquín’s answer: Ok. * Rational: Adding of the map versus set problem explanation.??? Usefulness: Good Used the library: No. Effort: In-depth reading of the docs and implementation Knowledgeable about the problem domain: Yes Accept the library: Yes ------------------------- *Neil Hunt’s review* ------------------------- Design: Good Implementation: Good Documentation: He didn't read it all closely. * Some performance indicators or at least discussion of the tradeoff of extra hashing vs reduced dynamic allocations would be useful. Joaquín’s answer: ok Usefulness: Useful Used the library: No Effort: A moderate investigation. Knowledgeable about the problem domain: Yes Accept the library: Yes ------------------------- *Alberto Ganesh Barbati’s review* ------------------------- Design: Very good. Issues: * It doesn't fully grasp the essence of the flyweight pattern because of a major flaw. The flaw is the fact that an object needs to be created in order to check whether an equivalent flyweight exists or not. Implementation: Well done. Issues: * I strongly disagree with the choice of the term "factory" for a component that actually only acts as a storage. Documentation: Very well written. Issues: * The policies are indeed properly described, but the bare description is not very helpful in showing how to write a new policy Usefulness: Useful if the flaw I described before could be addressed Used the library: gcc 3.4.5 (mingw) Effort: A couple of hours. Knowledgeable about the problem domain: Yes. Accept the library: Reluctantly, the answer is no. He encourages the maintainer to consider addressing the issues I raised here, in which case I am ready to change my opinion. 1) Joaquín’s answer: * Instantiating a flyweight<T> will always create a temporary T (and hopefully just one when we get rvalue refs and variadic templates). The purpose of the library is *not* to avoid constructing expensive objects, it is to reduce memory consumption through object sharing. Collateral benefits include increased performance in object passing around. * GoF introduces a key type K into the pattern that is used to retrieve the actual values of T. So, we have a one-to-one relation KT, i.e. there exists a stateless function f of the form “T f(const K&)”. My analysis led me to conclude that the right approach is to assume that K==T. * Joaquín will investigate the potencial of the LookupFactory (factories that, additionally to the insert memfun, provide a find memfun) pattern, described at http://lists.boost.org/Archives/boost/2008/01/132798.php * I decided to keep "factory" because this component is obviously * related to the element of the same name in GoF and oher descriptions * of the pattern. * I’ll refine the reference section to make it easier write custom policies. 2) Alberto’s answer: I have another case in an project I am working on: in a 3D application, I have heavyweight 3D mesh objects that might be shared among several actors. The key of a 3D mesh is just its filename. I don't want to load an entire mesh into memory just to find out that I have it already. 3) Joaquín proposes the keyed_flyweight: struct character { character(char c):c(c){} char c; }; int main() { // fw_t objects are constructed from chars // but are convertible // to character. typedef keyed_flyweight<char,character> fw_t; // creates an internal character('a') fw_t x1('a'); // same shared value as x1, zero temporary character's fw_t x2('a'); // creates an internal character('b') fw_t x3('b'); } 4) Alberto proposes unifying keyed and non-keyd with just one flyweight class template: * we have two types: key_type for keys and value_type for values. The two types can be coincident (non-keyed proposal) * the constructor of flyweight semantically takes keys, not values * keys (not values) are fed as-is to the factory insert() method: it's up to the factory to determine whether the key is already present and if it's not present to construct the corresponding value. * the insert() method returns a handle * the factory provides a way to extract values from handles * The rest of the design would more or less stays exactly the same. 5) Joaquín’s answer to Alberto’s unified flyweight: I'd rather factories remained dumber so that all this intelligence is implemented in the core because: * STL associative containers are either set-like * (key_type=value_type) or map-like (T != value_type != key_type, because T == mapped_type). * The container would have to deal with a more general notion of key extraction. Boost.MultiIndex can do that, but I don't want to tie flyweight to that lib. Review manager note: The discussion went a bit further but the essence is that Joaquín has proposed alternatives and is ready to further discuss the issue because flyweight won’t be ready until Boost 1.36. I encourage Joaquín, Alberto and other contributors to discuss the issue in the future again. ------------------------- *John Torjo’s review* ------------------------- Design: Ok. Implementation: Ok. http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/tutoria… I think there could be a simpler way to do this: http://www.entropygames.net/globals.htm Documentation: Very nice Usefulness: Very useful. Used the library: No. Effort: 1.5h Knowledgeable about the problem domain: Yes Accept the library: Yes. ------------------------- *Markus Werle's review* ------------------------- Design: Not reviewed Implementation: Not reviewed Documentation: Good Usefulness: Yes Used the library: No Effort: Moderate Knowledgeable about the problem domain: No Accept the library: Yes ------------------------- *Kevin Sopp’s review* ------------------------- Design: Good. A way to get usage statistics about the flyweights would be nice (Joaquín agrees) Implementation: Good Documentation: Good Usefulness: Good Used the library: Yes Effort: Moderate Knowledgeable about the problem domain: Yes Accept the library: Yes Other accepted suggestions coming from non-review posts: Add assertions to catch static variables destruction ordering problems with flyweight. The refcounted tracking policiy can detect such illegal situations (an entry is destroyed with a refcount!=0). -------------------------- End of summary -------------------------- Ion Gaztañaga - Review Manager -

1 0

Re: [boost] Boost.Tree status
by Felipe Magno de Almeida 17 Feb '08

17 Feb '08

I remember there was a boost.tree SoC proposal. Did it got through? What is the status of this library? I would like to use it as a concept for a GUI tree view control I'm creating. Regards, -- Felipe Magno de Almeida

2 1

[typeof] native decltype?
by shunsuke 17 Feb '08

17 Feb '08

Hi, Boost.Typeof seems to implement native typeof by using compiler bug or extension. Can decltype(reference sensitive) be implemented by using compiler bug or extension? Regards, -- Shunsuke Sogame

2 2

Logging library review
by Steven Watanabe 17 Feb '08

17 Feb '08

AMDG General: I notice that you are using the <stdlib.h> includes rather than <cstdlib> e.g.. Is there a good reason? I've noticed a couple of places that have a comment before the include guard saying "this is fixed". That's hardly an informative message unless I know what was wrong with it. Individual Files: defaults.hpp If you want to override any of the above, you should do the following: - before including anything from Boost Logging Library, <tt>\#include <boost/logging/defaults.hpp> </tt> - override the types - do <tt>\#include <boost/logging/logging.hpp> </tt> IMO, this is a very dangerous way to go. I would prefer something like: - create a header that defines the correct typedefs. - #define BOOST_LOGGING_CONFIG_HEADER path/to/override/header logging.hpp: No comments. format.hpp: use_cache::format: Can you change this to do the check and insertion in a single step? if(m_formats.insert( fmt).second) "@param lock_resource_type What class you use to do allow thread-safe access to an instance of this clas (used internally)." Missing an "s" in class format.hpp needs to #include <algorithm> del_fomatter/destination. Could you spell out delete? It's only three more letters. Alternately it could be erase_formatter msg_route::simple vs. msg_route::with_route. Why does simple ignore it's constructor arguments while with_route stores references to them? with_route::route_do_set/route_do_append. This is *evil*. Don't put anything that can throw in any destructor. profile.hpp: scoped_compute::~scoped_compute() If ::boost::posix_time::microsec_clock::local_time() throws this is bad. Also, for multithreaded programs, you don't want the elapsed time, you want the time spent executing the current thread. Is there a way to do this? Otherwise this weakness should be documented. detail/after_being_destroyed.hpp Why don't you delete this file? detail/cache_before_init.hpp You're using the thread id stuff in another place. Could you factor it out into the threading directory? You already have thread specific storage. Use it! detail/cache_before_init_macros.hpp I really like the idea of caching. I've had to deal with the problem of trying to figure out where to log to, when I might have to log before main and this solves the problem neatly. detail/error.hpp Why? detail/filter.hpp no comments. detail/find_format_write.hpp no comments. detail/find_gather.hpp no comments. detail/format_fwd_detail.hpp no comments. detail/format_msg_type.hpp no comments. detail/format_write_detail.hpp no comments. detail/forward_constructor.hpp BOOST_LOGGING_FORWARD_CONSTRUCTOR_WITH_NEW for msvc: Please rearrange this to use the constructor rather than using assignment. detail/fwd.hpp /* just in case you're doing a typo - "write" instead of "writer" */ namespace write = writer; I beg you're pardon!? using namespace destination; file f("out.txt", file_settings.initial_overwrite(true).do_append(false) ); Is file_settings actually a global variable? Oh. Should this be file_settings()? That looks better. flag_with_self_type::operator=(const self_type & other) I don't understand what this overload accomplishes. m_val is certainly not a member of file_settings for example. detail/level.hpp Am I allowed to make my own levels? static const int my_level = 221; If I did it would need to go in namespace boost::logging::level right? Is there anything else special about levels? holder_ts There is no reason to make the typedefs scoped_lock and mutex public. The mutex object is private anyway. detail/log_keeper.hpp: logger_holder: Since you're defining operator-> why don't you define operator* too. ensure_early_log_creation I can see the point of this class, but why all the mess in the implementation? I don't see at all how it helps. detail/logger.hpp gather_holder: I don't like the use of mutable. Is it necessary? Would the auto_ptr trick do? logger<gather_msg, default_ >::~logger(): turn_cache_off??? Can this throw? Should the messages be written to some unspecified location or discarded? Should the behavior be more configurable in this pathological case? forward_to_logger: // ... might be called for a specialization of logger - for logger<gather_msg,write_msg*> typedef typename boost::remove_pointer<write_msg>::type write_type; This isn't going to be surprising at all? detail/logger_base.hpp I notice that logger_base inherits from types in the detail namespace. This means the ADL will look in namespace detail for loggers. Is that a problem? detail/macros.hpp Why does BOOST_LOG_COMPILE_FAST cause the logger_holder to be returned by reference, while the otherwise the logger is returned by reference? manipulator.hpp Use #pragma warning push/pop line 513 Thus, usually generic manipulators have a templated operator=, and do the best to convert what's in, to what they need. Do you mean templated operator()? Going back to my criticism of manipulators, here is basically the interface I would like: concept Manipulator<class M, class StringType> { void operator()(const M&, const StringType&); bool operator==(const M&, const M&) { return(boost::is_empty<M>::value); } void configure(const hold_string_type&) {} } Detecting the presence or absence of operator== can be a pain and may not work in all cases. Detecting configure can be done easily and I would definitely go for it to make the interface simpler. Oh. named_spacer depends on the presence of the typedef convert_type, too. *Sigh* Does this mean that the example is wrong: template<class convert_dest = do_convert_destination > struct cout { template<class msg_type> void operator()(const msg_type & msg) const { convert_dest::write(msg, std::cout); } }; Also, if I understand correctly only the named_* stuff depends on configure. Since you have to create a pointer anyway for polymorphism it shouldn't cost any more to always treat manipulators as generic. detail/scenario.hpp no comments detail/scoped_log.hpp BOOST_SCOPED_LOG_CTX_IMPL Make sure the destructor can't ever throw. detail/tags.hpp no comments. detail/time_format_holder.hpp: the two versions of write_time pass different numbers of arguments to sprintf. There is no check to make sure that the format string is correct. If I use nanosecs with plain time the error will manifest itself in undefined behavior. Why don't you pad with 0's line 162: sprintf( buffer, m_format.c_str(), vals[1], vals[2], vals[3], vals[4], vals[5], vals[6], vals[7], 0, 0, 0 ); detail/logger_format_write.hpp no comments. detail/util.hpp would compute msg_type right now; however, we want the compiler to wait, until the user has actually set the msg_type, for example, using the BOOST_LOG_FORMAT_MSG macro. Thus, we do: This really bothers me. I don't think that you should rely on this kind of magic for non-dependent types. If you want to do it use template paramters for configuration. Otherwise use, preprocessor symbols to guarantee that the requisite specializations are available soon enough. format/array.hpp shared_ptr_holder::append: You should construct a shared_ptr outside the mutex so that you don't need to allocate any memory inside the critical section. format/named_write.hpp No comments format/named_write_fwd.hpp No comments format/op_equal.hpp I don't like the restriction that operator== needs to be a member function. I think I can see why you are doing it (To prevent infinite recursion, right?) but still, there ought to be a better way. optimize.hpp: I notice that cache_string_one_str grows linearly. I thought that the general way was to grow exponentially? The code is litered with explicit casts to int. Wouldn't it be better to use std::size_t and make sure it's safe? I'm not entirely convinced that cache_string_one_str will be faster than std::string at all. It can certainly be made quite a bit faster than it is. cache_one_str::to_stream seems to require that the stream be opened in binary mode? I'm confused about the relationship between cache_string_one_str and cache_string_several_str. They don't have the same interface. In addition, prepend_string behaves differently between the two. for cache_string_one_str prepend_string causes it's argument two be prepended. For cache_string_several_str it causes it's argument to be inserted at the end of the set of prepended strings. Is this difference intentional? Further, cache_string_one_str::set_string resets the entire string. cache_string_several_str::set_string only resets the message string--nothing that has been prepened or appended. format/destination/convert_destination.hpp 300 column lines is a bit excessive, don't you think? do_convert_destination? Is the name convert_destination already taken? I normally think of names like this as being implementation names rather than interface names. format/destination/defaults.hpp I'd like to see this broken up into separate files. #include <boost/logging/format/destination/iostream.hpp> #include <boost/logging/format/destination/ostream.hpp> #include <boost/logging/format/destination/dbg_window.hpp> why is file.hpp included? format/destination/file.hpp #pragma warning ( disable : 4355) Whatever happened to #pragma warning push/pop? Shouldn't you check for BOOST_MSVC instread of _MSC_VER. This should be /after/ the #includes. format/destination/named.hpp same comment as for file.hpp about #pragma warning destination::detail::named_context::add: What happens if I attempt to use the same name more than once? Is it simply not allowed? It looks like what actually happens is that the old destination will still be present but the name will now refer to the new destination. Is that your intent? comment before named_context::compute_write_steps: // recomputes the write steps - note taht this takes place after each operation s/taht/that/ named_t::named_t. Should this be explicit? named_t::string. I would like this better if it were called set_format. I would like named().add("cout", cout()) to have cout on by default. format/destination/rolling_file.hpp #pragma warning again. rolling_file_info::rolling_file_info. // so that we don't get exceptions fs::path::default_name_check( fs::no_check); I don't think you should change global filesystem settings. Especially since this is deprecated! rolling_file_info::recreate_file: Is it OK to open a file that you already have open, again? I'd like to be able to control the names of the individual files so that I can have file1.log file2.log &c. e.g. format/destination/shared_memory.hpp Since this is not working I'll leave it alone. format/destination/syslog.hpp No comments. format/formatter/convert_format.hpp string_finder< ::boost::logging::tag::holder<string,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10> >::get Shouldn't this invoke string_finder< string>::get rather than relying on an implicit conversion? In namespace modify: template<class string> void write(string_type & src, boost::logging::optimize::cache_string_one_str<string> & dest) { dest.set_string_swap(src); } First of all set_string_swap is a member of cache_string_several_str not of cache_string_one_str. Second, I think this is dangerous. Users will expect that write(src, dest) will behave the same if src is const vs. non-const provided that it works in both cases. Wait to rvalue references to make this optimization. do_convert_format: Is there a reason for the separate overloads of write for const char_type *? format/formatter/defaults.hpp You might break this up into separate headers. format/formatter/high_precision_time.hpp Is 64 guaranteed to be enough characters? Oh. I see the assertion in time_format_holder.hpp. Ever thought about using named constants? high_precision_time_t::write_high_precision_time::write_high_precision_time In the switch you might add an assertion case 0: assert(nanosecs == 0); break; // no high precision at all format/formatter/named_spacer.hpp named_spacer_context::write_with_convert(msg_type & msg, ...): Should this really use ::boost::logging::formatter::do_convert_format::append*? The use of context bothers me. Suppose that I stick a formatter that appends into a named_spacer that prepends? What happens? Is there any way to detect such a condition? I think the problem is that you are trying to mix two different abstractions, here. The formatters represent a generic modification to the string and that's fine. The named_spacer allows printf like formatting at runtime with function objects to fill in the placeholders. That's fine too. The problem is that formatters do not simply return some text which the named_spacer can insert in the correct position. also I'd like to be able to specify format strings like: "[%idx%] %time% %msg%\n" to control the message placement as well. named_spacer_context::compute_write_steps You might be helpful and give an error if there are unpaired %'s format/formatter/spacer.hpp I'm glad to see that convert_type is propogated correctly. format/formatter/tags.hpp uses_tag could use more specific documentation. In particular it needs to say that the derived class should have a member called write_tag and that uses_tag supplies the operator() format/formatter/thread_id.hpp no comments format/formatter/time.hpp no comments format/formatter/time_strf.hpp Is there any particular reason that this doesn't support runtime configuration? gather/ostream_like.hpp Doesn't need to #include <iostream> out_base won't be needed anymore, right? out_of_the_box/use_levels.hpp and out_of_the_box/use_levels.hpp I notice that these don't use ensure_early_log_creation. tag/defaults.hpp thread_id doesn't handle BOOST_HAS_MPTASKS although format/formatter/thread_id.hpp does. Is there a reason for the discrepency? needs to #include <ctime> Where is ::boost::logging::level::type defined. Ah detail/level.hpp This is the file that you need to #include. tag/high_precision_time.hpp Should this support configure()? writer/format_write.hpp No comments. writer/named_write.hpp lines 296-298 In this case you already know that (a) the string is not empty (b) the last character is a '%' (c) the first character is a '%' (invariant given a.) The only thing that could cause the test has_manipulator_name() to be false is if m_manipulator is "%", in this case the assignment does nothing. This test can be replaced with assert(has_manipulator_name() || m_manipulator == "%"); there are functions replace_formatter and replace_destination I don't see a way to add formatters or destinations. replace_formatter seems dangerous. The correctness depends on the (compile time known) convert_type of the new formatter matching the (runtime known) format string. Also, this (contrived) example won't work: writer.format("[%idx%] |\n"); writer.replace_formatter("time", high_precision_time("...")); writer.format("[%idx%] %time% |\n"); Not to mention that if I then change the format string again: writer.format("[%idx%] | %time%\n"); it will revert to the old version of time. In short, I think that you should either disallow the replacement entirely or make it general. on_dedicated_thread.hpp: on_dedicated_thread::pause(): what ever happened to condition variables? The inheritence from base_type worries me. If base_type only provides operator() then the inheritence is unnecessary. If base_type provides other functions then they probably shouldn't be called without locking. It's dangerous to expose a partly thread safe interface. writer/ts_write.hpp ts_write_context declares the mutex mutable. dedicated_thread_context does not. Which is right? Again I am worried by the inhertance only more so. on_dedicated_thread might be used in an otherwise single threaded program. ts_write probably wouldn't be. Whew. That being said I vote to accept the logging library. All the issues with destructors and exceptions absolutely must be fixed. In Christ, Steven Watanabe

1 0

[String algorithm] is_any_of has inefficient implementation
by Joe Gottman 16 Feb '08

16 Feb '08

I just discovered that the string algorithm predicate is_any_of has an inefficient implementation. Internally it uses a std::set. There are two problems with this. First, since the order of the characters does not matter, std::unordered_set is probably faster. Second, the contained set has to be copied each time the object is used in, for instance, a split() statement. Since split can reuse a predicate literally thousands of times when splitting a large string, this is a lot of unnecessary copying. Joe Gottman

10 15

Statechart: base class not initialized gcc warning patch
by euanbemail-boost＠yahoo.com 16 Feb '08

16 Feb '08

Compiling code from the Statechart tutorial on linux x86 with gcc 4.0.1 with the -Wextra flag results in the following warning: /usr/local/boost/1.34.0/x86/include/boost-1_34/boost/statechart/detail/counted_base.hpp: In copy constructor ‘boost::statechart::detail::counted_base<NeedsLocking>::counted_base(const boost::statechart::detail::counted_base<NeedsLocking>&) [with bool NeedsLocking = true]’:/usr/local/boost/1.34.0/x86/include/boost-1_34/boost/statechart/detail/rtti_policy.hpp:95: instantiated from here /usr/local/boost/1.34.0/x86/include/boost-1_34/boost/statechart/detail/counted_base.hpp:64: warning: base class ‘struct boost::statechart::detail::count_base<true>’ should be explicitly initialized in the copy constructor I've attached a patch to fix this. If a developer can pick this up, that would be great. Euan __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

2 1

Review request: Proto
by Eric Niebler 15 Feb '08

15 Feb '08

Proto, the library for defining expression template-based domain-specific languages, is ready for review. It's already actively being used by Boost.Xpressive and by Spirit-2, and is a key enabling technology in the long-planned unification of Phoenix and the Lambda Library. Documentation is here: http://boost-sandbox.sourceforge.net/libs/proto Download proto.zip from here: http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapr… -- Eric Niebler Boost Consulting www.boost-consulting.com

6 10

Re: [boost] [String algorithm] is_any_of has inefficient
by dpxguard-boost＠yahoo.gr 15 Feb '08

15 Feb '08

> > In each case, I've used the predicate with std::find_if. But if I > > instead use C's strcspn() to do the whole job, I see a relative > > performance for this example of 20. I find it depressing that the C++ > > code doesn't come close to that. > Well, it is not really a fair comparison, the 'C' function is likely > implemented in hand optimized assembler, (http://tinyurl.com/yv8s7g) > and for such a small function, humans are still better than compilers. > So it isn't really C++ versus C. Also the C version is not generic at > all. Personally, I feel that generic C++ code should at least avoid having inferior complexity, compared to the corresponding C code! And I am very happy to see that you are interested in these performance issues. I have done a relative research regarding the performance of the find_first_of algorithm [1] and my findings were rather similar to the findings of Phil Endecott. Fortunately, I have also found that using a (bit/byte) array for mapping, find_first_of can achieve the same complexity (of -course) and similar performance compared to the specialized C code. Of course, in order to achieve these performance gains, you have to implement specializations. Equivalently, I believe that using bit-arrays instead of sets in the is_any_of is a very good thing, as long as you are actually improving the time complexity. References 1. http://www.codeproject.com/KB/stl/find_first_of.aspx Best regards, Jim Xochellis ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

1 0

Support for Visual studio
by Loïc Joly 15 Feb '08

15 Feb '08

Hello, We are planning to move to VS2009 (VC+++9.0). I'd like to know if the next boost release will officially support visual studio 2008. If it is true, I'd also like to know if the ctp containing an implementation of the C++ part of TR1 will be supported too. Finally, I'd appreciate to know wether there is a web page that contain the expected content (even with a huge disclaimer that all that was expected might be missing) of next releases of boost : - Supported compilers / SL - New libraries included - Expected release date (I know this one can be fuzzy, but for boost users, havind a fuzzy date is better than not having any date) Regards, -- Loïc

2 1

Re: [boost] Trac open bugs - by assignee
by Daniel James 15 Feb '08

15 Feb '08

On 15/02/2008, Marshall Clow <marshall(a)idio.com> wrote: > Does anyone have a suggestion for who should take #1493 and/or #1573? > [snip] > None 1493 SVN files making it through to install > None 1573 Broken URL in copyright boiler-plate I'll take 1573.

1 0

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

15 Feb '08

[ 211 open bugs today, 211 yesterday ] Does anyone have a suggestion for who should take #1493 and/or #1573? (The two that are assigned to "None") 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 10 no-maintainer 9 bemandawes 7 jsiek 7 anthonyw 6 johnmaddock 5 witt 5 turkanis 5 igaztanaga 4 pdimov 3 ebf 3 danielw 2 t_schwinger 2 shammah 2 rogeeff 2 ramey 2 pavol_droba 2 nasonov 2 kaalus 2 jmaurer 2 hkaiser 2 danieljames 2 aaron_windsor 2 None 1 urzuga 1 speedsnail 1 samuel_krempp 1 nesotto 1 matias 1 marshall 1 hljin 1 garcia 1 eric_niebler 1 dlwalker None 1493 SVN files making it through to install 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 igaztanaga 1635 Incomplete include guard in boost/intrusive 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 1222 lambda::ret<T> should declare result_type. no-maintainer 1270 uniform_smallint doesn't compile with lagged_fibonacci random number generators no-maintainer 1515 [lambda] C4512 warnings from VC8.0 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 1572 [lambda] smart pointer const-ness affects its contents no-maintainer 1632 Default Interval rounding policies incomplete no-maintainer 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile 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 1285 [serialization] problem when including shared_ptr_132.hpp 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 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

[test] Using boost.test for GUI testing?
by Markus Schöpflin 15 Feb '08

15 Feb '08

Hello, did anybody ever use boost.test to test the UI behavior of classes, like for example instantiating a class implementing a dialog, sending some events to the resulting object, and checking that the object has the expected state. AFAICT this would require to somehow integrate the main event loop of the respective GUI framework with the main loop of boost test, but I'm at a loss how this could be accomplished. Has anybody any experience to share? Best regards, Markus

3 4

Boost Exception update
by Tom Brinkman 15 Feb '08

15 Feb '08

Well done. I like the way you grouped the error info tags into boost::tuple. Now, maybe, just maybe, after using your exception framework, I'll stop being lazy and start throwing more useful error messages in my applications.

1 0

A library for interfacing with legacy non-reentrant C and Fortran code
by Alcides Viamontes Esquivel 15 Feb '08

15 Feb '08

Hello all. I would like to know if there's a boost library for solving this problem, or if not, if it would be of general interest one. Suppose you have a function in an external library that you want to use, and it have this prototype: ... /* mad_library.h */ /* external library function prototype */ double qk15( double(*f)(double), double a, double b); (this example mimics QUADPACK, a great and wonderful library for numerical integration) If you want to have a (good) chance of using qk15 with a reentrant function, then the correct prototype would be, at least ... double qk15( double(*f)(double, void*), double a, double b, void* params); ... which is something that for example gsl (http://www.gnu.org/software/gsl/ ) does. But that's not the case and modifying qk15 is out of the question. So, the "solution" library I'm asking for should be a C++ header library that would, for example, bring this interface to the user: ... #include <mad_library.h> // Hypothetical library #include <boost/enable_reentrant.hpp> // client functor supplied by the user, to be used in some // way with 'qk15' struct any_functor{ ... double operator()(double x) ... }; ... // an instance of the functor any_functor cpp_f; ... // first parameter is the legacy function, following parameter // types are deduced from the prototype of qk15 (if // possible), being each one of the same original type that // qk15 requires but changing raw function pointers by generic // functors (automatic type replacement or user-guided). boost::enable_reentrant(qk15, cpp_f, a, b); // As a postcondition to this call, function qk15 should // be called once with a function pointer to something that // ensures that operator() on 'any_functor' instance get's // called with the corresponding 'this'. If I'm missing something terrible obvious please signal it to me. I think enable_reentrant can be implemented in at least one (almost) portable way, using a stack in thread local storage. Boost.Thread already give access to such feature in a satisfactory way. __________________________________________________________________ Servicio de Correos del Grupo de Redes. UCLV - Universidad 2008 del 11 al 15 de febrero del 2008. Palacio de Convenciones. La Habana. Cuba. http: //www.universidad2008.cu - II Taller internacional -Virtualización en la Educación Superior-, del 11 al 15 de febrero de 2008 Palacio de Convenciones. La Habana, Cuba. http://virtual-es.uclv.edu.cu

1 0

[Range] Feature Request: assign_from_range.
by Joe Gottman 15 Feb '08

15 Feb '08

When I use copy_range() to assign a range to an existing container an unnecessary temporary object is created then assigned to the target. This can be inefficient, especially if the target is a vector or string which may have a large enough capacity() that no reallocation is required for the assignment. Therefore, I’d like to request a new range algorithm, assign_from_range, that is defined as follows: template<class Sequence, class ForwardRange> inline Sequence &assign_from_range(Sequence &target, const ForwardRange &r) { return target.assign(begin(r), end(r)); } Joe Gottman

2 2

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

14 Feb '08

[ 211 open bugs today, 209 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 10 no-maintainer 9 bemandawes 7 jsiek 7 anthonyw 6 johnmaddock 5 witt 5 turkanis 4 pdimov 4 igaztanaga 3 ebf 3 danielw 3 None 2 t_schwinger 2 shammah 2 rogeeff 2 ramey 2 pavol_droba 2 nasonov 2 kaalus 2 jmaurer 2 hkaiser 2 danieljames 2 aaron_windsor 1 urzuga 1 speedsnail 1 samuel_krempp 1 nesotto 1 matias 1 marshall 1 hljin 1 garcia 1 eric_niebler 1 dlwalker None 1493 SVN files making it through to install None 1573 Broken URL in copyright boiler-plate None 1635 Incomplete include guard in boost/intrusive 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 1222 lambda::ret<T> should declare result_type. no-maintainer 1270 uniform_smallint doesn't compile with lagged_fibonacci random number generators no-maintainer 1515 [lambda] C4512 warnings from VC8.0 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 1572 [lambda] smart pointer const-ness affects its contents no-maintainer 1632 Default Interval rounding policies incomplete no-maintainer 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile 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 1285 [serialization] problem when including shared_ptr_132.hpp 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 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 library review is completed.
by Gennadiy Rozental 14 Feb '08

14 Feb '08

Hi, Thanks to everyone participating in the review of proposed logging library. I do believe this is one of the "must have" components to be included in boost libraries suite. Anyone who is interrested in sharing views on the subjust are still welcome (specifically I might be interrested in comparizon with other popular existing solutions). Nevertheless official tally is closed as of now and "jury is secluded for deliberations" ;). I'll try to compile the results within reasonable time frame. Genandiy Rozental - Review Manager -

3 4

[flyweight] extending flyweight
by Michael Marcin 14 Feb '08

14 Feb '08

Unfortunately I didn't have time to participate in the review of flyweight but I did follow it. Now that it has been accepted I'm looking into using it as a replacement for my homebrew mechanism. We currently have a Factory which we pass a hash id (which happens to be the hash of the lowercase filename using Bob Jenkin's lookup3 hash). The Factory then looks to the Cache to see if the object is already cached (i.e. exists in its collection which happens to be a boost::ptr_map of hash ids to the shared Resource). If its not in the Cache we pass the hash to the Repository which uses it to lookup and load the resource from an archive on disk. We then return the reference to the Cache's resource as a boost::cref<Resource>. Memory is very constrained and performance is important. We don't use reference counting but have designed the application so that there are places we can safely clear all the caches with no dangling references. I see that there is a no_tracking policy which allows us to skip reference counting. Is there a way to clear all Flyweight factories when using the no_tracking policy (the equivalent of our Caches IIUC)? A bonus would be to easily switch to the refcounted tracking policy and assert or throw when we try to clear all the factories if there are any outstanding references as a debugging aid. I tried to replace a simple part of the application that is using the homebrew mechanism with Boost.Flyweight and I ran into some problems. The current code looks like: std::auto_ptr<SoundInstance> CreateSound( unsigned int soundId ) { const Sound& sound = ResourceFactory::Instance()->Get<Sound>(soundId); return std::auto_ptr<SoundInstance>( new SoundInstance(sound) ); } I would think the new code would look like: std::auto_ptr<SoundInstance> CreateSound( unsigned int soundId ) { boost::flyweight<Sound> sound( soundId ); return std::auto_ptr<SoundInstance>( new SoundInstance(sound) ); } I need to create a factory that takes Resource hashes and loads resources which it caches in an unordered_ptr_set and then returns a reference to that cached resource. I then need to be able to clear the cached resources of the factory explicitly. I would like to store boost::flyweight<Resource> instead of const Resource& but I need to make sure that boost::flyweight<Resource> is the same size as a pointer to the Resource given proper policies (since the memory requirements are stringent). Is this possible with the current version? Is it a reasonable to apply flyweight in this manner? Thanks, Michael Marcin

2 2

[fusion] noncopyable types in sequences?
by Stjepan Rajko 14 Feb '08

14 Feb '08

Hello, In trying to use noncopyable types in a fusion vector I realized I can't - GCC 4.0.1 complained about, e.g.: fusion::vector<boost::signal<void()> > test; // error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable&)' is private A related question was asked before by Michael Marcin but I didn't find a response: http://lists.boost.org/Archives/boost/2007/10/128868.php Is there a way to make vector (or any other sequence container) hold noncopyable types, or do I need to implement a noncopyable_vector? Thanks for any suggestions! Stjepan

2 2

OSI logo?
by Beman Dawes 14 Feb '08

14 Feb '08

The Open Source Initiative provides "Open Source" and "OSI Certified" logos we could use on the Boost home page. See http://www.opensource.org/trademark for the HTML markup and conditions of use. See http://www.opensource.org/trademarks/opensource and http://www.opensource.org/trademarks/osi-certified for the logos themselves, in various formats and sizes. Should we include one of the OSI logos on the web site's home page? Which one? I vote "yes", and prefer the "OSI Certified" logo. What do others think? --Beman

11 17

Switch namespace
by Steven Watanabe 14 Feb '08

14 Feb '08

AMDG I'm not sure what namespace to use for switch. Since there will be more than just the single function template, switch_, I don't really want to put it directly in namespace boost. adding an 's' to make namespace switches sounds a little odd. Any suggestions? In Christ, Steven Watanabe

11 12

[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