- Boost - lists.boost.org

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 05 Feb '13

05 Feb '13

Okay, I believe I need to provide a really good example that can show the need of static construction with no preliminary calls to initialization functions. The example if part of my work project: - I have two layers: presentation and model. - Each layer work in its own thread because presentation must remain responsive whatever happens in model. - Model itself is an abstract layer, the actual logic implementation is implemented in specific agents, so the model is not aware of the agents. - Agents are asynchronous tasks. - I have DatabaseFacade utility class, internal data of which require some preliminary initialization, like setting initial values, creating locks, filling hash maps, but not actual connection because it's a proxy to real database object. - All agents use the DatabaseFacade asynchronously. These are the possible scenarios of initialization of DatabaseFacade internal data: 1. Make a call to DatabaseFacade::initialize() from main (or other wiring code), thus making main aware about DatabaseFacade, i.e. introduce an unnecessary dependency. 2. Call DatabaseFacade::initialize() from model construction, again introducing an unnecessary dependency, because the abstract model doesn't care about some specific needs of some agents. 3. Call DatabaseFacade::initialize() during specific agent construction. But another agent can be inside a call to DatabaseFacade::initialize(). So, I'd need to wrap it in critical section. But the critical section itself has to be initialized before agents start. Should I introduce dependency on this specific critical section to the abstract model? Nop. Should I wrap DatabaseFacade::initialize() inside in a static critical section thus making assumptions about clients of the function? Nop again. And by introducing public method DatabaseFacade::initialize() I will open a possibility for double initialization. Of course I can insert checks, but the checks can reveal problems at run-time only. So it's more correct to allow a class to initialize its internal data itself on its own discretion, thus writing robust API that cannot be misused: "Anything that can go wrong will go wrong" - Murphy's Law ;) Thank you. ______________________________ With best regards, Alexander Stoyan

1 0

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 05 Feb '13

05 Feb '13

Hello everybody, Sorry for late response. To Mateusz. Thank you for a good point, I have updated my initial blogpost with with clear statement of the goal. And I also corrected naming and put some extra comments. To Mathias. >> What's the functional difference between putting it as a type list and >> putting it as code? Not sure that I understood your question correctly, but if you meant differences between dependencies in the static_dependencies list and dependencies caused by calling initialization from main, then the difference is clear: if we put dependencies B and C to static_dependencies list when declaring class A, then only class A declaration becomes dependent on B and C. But if we require a call to A::initialize, B::initialize and C::initialize from main, then main becomes dependent on A, B and C. This way your startup code will be dependent on everything like that, that's not right. >> If you want it to be initialized before main, then use global variables or static members. Ok, try to answer your question yourself: struct A { static A& instance() { ... } } struct B { static A& instance() { ... } } struct C { static A& instance() { ... } } ... static A& forceAConstr = A::instance(); static B& forceBConstr = A::instance(); static C& forceCConstr = A::instance(); ... int main() { ... } Can you guarantee the order of construction for A, B and C in this case when standard explicitly states that the order of initialization is not determined? >> But then you have to make sure no threads exist prior to entering main. >> Unlike for static variables in functions, global constructors are not thread-safe. Starting threads before main execution is a bad idea itself, so don't do it. >> I have no idea what you're talking about. The compiler cannot remove >> things if it changes observable behaviour, outside of a few situations >> where copy constructors can be elided. In my code you can find a declaration and initialization of bool static_constructible<T, Dependencies>::constructed. So, if this variable is not referenced in the code it never get initialized. At least this is how VS11 compiler works. So in order to refer this variable all data access functions have to make a call to static_constructible<T, Dependencies>::ensure_static_constructed. This way if you call a data access function from main, which calls ensure_static_constructed, then static_constructible::constructed becomes referenced! >> There is an "isinside" boolean. That's only made for cases if a derived class from singleton does not provide his own static constructor. If you remove B::static_construct() the code will work fine anyway. >> A given order can still be forced. Unless it's through compile configuration, provide an example please. Otherwise, having long lists of initialization orders for all supported compilers is error prone. The code itself has to describe itself as much as possible. I appreciate your attention. Thank you. ______________________________ With best regards, Alexander Stoyan

2 1

[gil] compiler error with clang in c++11 mode
by Christian Henning 05 Feb '13

05 Feb '13

Hi there, Can someone shed some light on the following compiler errors: c:\boost\boost\gil/channel_algorithm.hpp:54:85: error: non-type template argument evaluates to -1, which cannot be narrowed to type 'unsigned long long' [-Wc++11-narrowing] struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {}; ^ c:\boost\boost\gil/channel_algorithm.hpp:204:19: note: in instantiation of template class 'boost::gil::detail::unsigned_integral_max_value<unsigned long long>' requested here if (src > unsigned_integral_max_value<uintmax_t>::value - div2) I only get those in c++11 mode. The code to trigger them is: #include <boost\gil\gil_all.hpp> int main() { return 0; } I'm using clang 3.2 on Windows with CodeBlocks. Thanks, Christian

2 3

[type_traits] Request: is_iterable
by Nevin Liber 05 Feb '13

05 Feb '13

I'd like to make a request for an is_iterable<T> type trait, which detects if a type can be used in C++11 range-based for. I have a prototype which currently meets my needs (I can make it available; it detects if both std::begin(c) and std::end(c) can be called), but I'm wondering: a) What should the name be? (I'm not married to is_iterable) b) Should there be a second template parameter indicating the type returned by derefencing the iterator, defaulting to don't care. c) What should the C++03 behavior be? d) Is there someone with more expertise than I willing to implement a robust version of it? Does this sound like a good idea? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

4 4

Boost 1.53.0 released!
by Marshall Clow 04 Feb '13

04 Feb '13

Release 1.53.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains five new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries: * Atomic: C++11-style atomic<>, from Helge Bahmann, maintained by Tim Blechmann. * Coroutine: Coroutine library, from Oliver Kowalke. * Lockfree: Lockfree data structures, from Tim Blechmann. * Multiprecision: Extended precision arithmetic types for floating point, integer and rational arithmetic from John Maddock and Christopher Kormanyos. * Odeint: Solving ordinary differential equations, from Karsten Ahnert and Mario Mulansky. For details, including download links, see http://www.boost.org/users/news/version_1.53.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.53.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

6 7

[1.53] Too late for doc fixes?
by John Maddock 04 Feb '13

04 Feb '13

Am I correct in assuming that it's too late to fix typos in docs: https://svn.boost.org/trac/boost/ticket/7958 ? Thanks, John.

3 3

[function] Documentation suggestion (FAQ)
by Evan Driscoll 04 Feb '13

04 Feb '13

I just wrote up a longish email (excerpted below) that was basically asking for advice about how to work around the fact that I can't compare two function objects. However, I fortunately decided to take another look at the docs before sending, and realized that Boost actually supports what I *really* needed, which was to compare a function object to see if it points to a particular function so I could use a much faster implementation. In other words, I was doing void backing_func() {...} boost::function<void()> func(backing_func); void foo(function<void()> callback) { if (callback == func) { fast_foo(); } else { slow_foo(callback); } } but by changing the if statement condition to if (callback == &backing_func) everything is fine and dandy. My suggestion is that the FAQ entry at http://www.boost.org/doc/libs/1_52_0/doc/html/function/faq.html should be updated to point out that there IS a way to do this specific case. If everyone read the whole docs and remembered them perfectly this wouldn't be a problem, but of course those statements are probably true of exactly no one. :-) I stumbled across the FAQ entry, which I feel strongly suggests that what I want to do is impossible. Evan P.S. If you have suggestions for a better design, I'm open to suggestions. --------- I'd like input about how to handle a design. I'll describe what I'm doing; my question is what people would suggest. I have a class which stores a boost::function<> as a parameter so as to provide a hook to customize its behavior. I can give the actual code and description of what I'm doing if that will help, but I suspect it distract more than help, so I'll just make something up (untested): typedef boost::function<bool (int, int)> CallbackType; class MyClass { CallbackType callback; void foo() { ... if (callback(x, y)) { .... } } MyClass(CallbackType cb) : callback(cb) {} }; There are a couple generically useful behaviors, so the library predefines callbacks for those: bool behavior_a(int, int) {...} bool behavior_b(int, int) {...} bool behavior_c(int, int) {...} CallbackType behavior_a_callback(behavior_a), behavior_b_callback(behavior_b), behavior_c_callback(behavior_c); I have need to make 'foo' fairly general and support fairly general callbacks, but for one behavior (say behavior_a), I can use a substantially more efficient algorithm (log or constant time, instead of linear) inside foo(). What I WANTED to do was make the behavior_a(int,int) function just a dummy, then do void foo() { if (callback == behavior_a_callback) { fast_foo(); } else { slow_foo(); } } However, for reasons described at http://www.boost.org/doc/libs/1_52_0/doc/html/function/faq.html#id1617166, you can't compare functions with equality. Any thoughts as to how you'd do this? Evan

2 1

[Fusion] Some ideas
by TONGARI 03 Feb '13

03 Feb '13

Hi, Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::transform(a, b, some_void_return_ftor)) * Conversion function 'as_view' to make Container a view to reserve the mutability. What do you think? Are these already achieved in some way that I didn't aware of? BTW, I just implemented left_mapping/left_mapped_view, it's used like result = left_mapping(m1, m2, transform); For elements not mapped, fusion::void_ is passed to transform. Still mapping & full_mapping to do...

3 14

Re: [boost] (no subject)
by Gilbert Polo 03 Feb '13

03 Feb '13

Is boost version 1.48 portable to AIX version 6.1. xlC version 11.1

2 1

[thread] possible raise in future?
by Oliver Kowalke 03 Feb '13

03 Feb '13

Hello Vicente, after analyzing the code of future<> from boost.thread I think the code might contain raise condition. future.hpp:226: future_object_base defined 'bool done'. future_object_base::mark_finished_internal() sets 'done' tot true (line 308) and future_object_base::wait_internal() reads it (line 347). Shouldn't 'done' be of type atomic<bool >? I believe that the compiler can reorder the usage of 'done' and two threads (writer thread calling make_finished_internal() and reader calling wait_internal()) might see different values. At least I think it might be possible that some thread will always be waiting in waiters.wait() (line 349), because the write r thread sets done=true and call waiters.notify_all() and a reader thread calls later wait_internal() but does not see that done is true because of memory reordering etc. and will be blocked in waiters.wait()forever. What do you think? best regards, Oliver

2 3