- Boost - lists.boost.org

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

18 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 18 Feb '08

18 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 18 Feb '08

18 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 17 Feb '08

17 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 16 Feb '08

16 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 16 Feb '08

16 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 16 Feb '08

16 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