September 2010 - Boost - lists.preview.boost.org

[Locale] Preview of 3rd version
by Artyom 13 Sep '10

13 Sep '10

Hello All, Announcement ============ I want to announce a preview of the third version of Boost.Locale: Tutorial: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html Reference: http://cppcms.sourceforge.net/boost_locale/html/index.html Downloads: https://sourceforge.net/projects/cppcms/files/boost_locale/ There are following significant changes: - Implemented multiple localization backends: - icu - the default and recommended backend, based on ICU library - std - based on C++ standard library localizations support, - posix - based on POSIX 2008 API (newlocale, strftime_l,...) - winapi - based on Windows API functions - Significantly simplified locale generation. - Improvements in UTF-8 handling by ICU where possible - Thread safety fixes when using ICU library - Fixed std::codecvt facet support to handle UTF-16 instead of UCS-2 only. - Removed support of compilers missing wide character support, gcc-3.4 on windows is not supported any more, latest gcc-4.x required with support of wide streams and strings, for example gcc-4.5 Tested Platforms: - Compilers: GCC (3.4, 4.2, 4.3, 4.5, 4.5/c++0x), Intel 11.0, MSVC 2008, SunStudio/stlport - Operating Systems: Linux, FreeBSD, OpenSolaris, Windows XP, Cygwin 1.7, (TODO Mac OS X) - ICU version: 3.6 to 4.4 Request To Site managers ========================= Please, update download link Review ====== Is there anybody who wants to volunteer to be a review manager? Artyom

5 31

[local_function] passing local functions as template parameters
by Lorenzo Caminiti 13 Sep '10

13 Sep '10

Hello all, Can you please check if the following mechanism can be used to pass local functor classes as template parameters? PROBLEM If I understand the C++ standard right, local classes cannot be passed as template parameters. Because of that, if I am defining a functor to pass to `std::for_each` I have to define it outside the local scope, far from the `for_each` call, which is not ideal (from cplusplus.com) struct myclass { void operator() (int i) {cout << " " << i;} } myobject; int main () { // Ideally `myclass` would be defined here locally... vector<int> myvector; myvector.push_back(10); myvector.push_back(20); myvector.push_back(30); cout << "\nmyvector contains:"; for_each (myvector.begin(), myvector.end(), myobject); cout << endl; return 0; } The code above does not compile on GCC if `myclass` is defined locally within `main`'s scope (it still compiles on MSVC instead...). SOLUTION (?) The following mechanism allows to define the functor body locally (in a local function which also binds the in-scope parameter `x`) and then pass it as a template parameter (to `boost::bind()` and then to `std::for_each()`). The trick is for the local function to override the virtual body of a global class and then pass the local function as a pointer to the global class while dynamic binding will actually execute the locally overridden body code. #include <boost/function.hpp> #include <boost/bind.hpp> #include <iostream> #include <algorithm> #include <vector> template<typename F> struct lfn_global {}; template<typename A1> struct lfn_global<void (A1)> { virtual void body(A1) {} }; // Similarly define `lfn_global` for other function arities and return types. int main () { double x = 5.6; struct lfn_t: lfn_global<void (int)> { lfn_t(double const& bound_x): x(bound_x) {} void body(int i) { std::cout << " " << i + x; // Local func body. } private: double const& x; } lfn_obj(x); // x is const& bound from scope. boost::function<void (int)> lfn = boost::bind( &lfn_global<void (int)>::body, (lfn_global<void (int)>*)(&lfn_obj), _1); std::vector<int> v; v.push_back(10); v.push_back(20); v.push_back(30); std::cout << "v: "; std::for_each(v.begin(), v.end(), lfn); // I can pass the local functor! std::cout << std::endl; return 0; } This code compiles on both GCC and MSVC, it correctly prints "v: 15.6 25.6 35.6". If this indeed works, I can hide all the extra code it requires behind the `BOOST_LOCAL_FUNCTION...` macros. Can you please try this code on other compilers? Do you see any issue with this code? Thank you very much. -- Lorenzo

3 4

[local_function] inheriting local functions?
by Lorenzo Caminiti 13 Sep '10

13 Sep '10

Hello all, Local functions are essentially implemented as member functions of local classes. These member functions do not have to be static and they could be virtual allowing for a local function to override one another. However, I cannot understand if this overriding "feature" has any value at all... Have you ever used anything similar? Can you think of a use case for it? Consider the following example where the local function `lfn_deriv` is "derived" from the local function `lfn_base`: #include <iostream> void f(double x) { struct lfn_base { lfn_base(double const& bound_x): x(bound_x) {} virtual int operator()(int y) { return x + y; } private: double const& x; } base(x); struct lfn_deriv: lfn_base { // inherits from `lfn_base` lfn_deriv(double const& bound_x): lfn_base(bound_x), x(bound_x) {} virtual int operator()(int y) { if (y < 0) return x * y; return lfn_base::operator()(y); // Call the base implementation. } private: double const& x; } deriv(x); std::cout << base(10) << std::endl; // prints `12` std::cout << deriv(10) << std::endl; // prints `12` std::cout << deriv(-10) << std::endl; // prints `-20` } int main() { f(2); return 0; } Do you have any use for code like this where the local function body is virtual? The only reason I can think of to do something like this is to allow `lfn_deriv` to call `lfn_base`. But in that case I rather pass (or bind) the `lfn_base` functor to the definition of `lfn_deriv`... -- Lorenzo

2 1

[local_function] how bad is this `static_cast<>`?
by Lorenzo Caminiti 12 Sep '10

12 Sep '10

Hello all, How bad is the `static_cast<>` below? struct c { void g() {} void f() { struct l: c { // Local function class wrapper. void body() { g(); // Usual implicit `this` access. this->g(); // Usual explicit `this` access. } }; static_cast<l*>(this)->body(); // *** HOW BAD IS THIS `STATIC_CAST<>`? *** } }; Could Boost.LocalFunction internally use such a technique when a special configuration macro is #defined by the users? IMO, if this `static_cast<>` can really corrupt memory on some systems/compilers, maybe Boost.LocalFunction should *never* use it. Otherwise, what would the documentation say "WARNING: If you #define this configuration macro, memory could be corrupted in some unknown way on some unknown combination of systems/compilers..." -- it's like providing a self-destruction button with a random countdown sequence via the configuration macro! What do you think? BACKGROUND Boost.LocalFunction can internally use this `static_cast<>` to provide access to the bound `this` parameter using the usual C++ syntax instead of the special name `this_`: #define BOOST_LOCAL_FUNCTION_CONFIG_IMPLICIT_THIS_HACK #include <boost/local_function.hpp> struct c { c(): x_(0.0) {} // Non-const member can bind `this` as non-const-bound. void f(double x) { double y = x + 10.0; BOOST_LOCAL_FUNCTION( (double) (total)( (int)(offset) (const bound)((&x)) (bound)((this)(y)) ) ) { reset(); // (1) Implicit `this`. this->x_ = x; // (2) Explicit `this`. assert(this_->equal(x)); // Also `this_`. double tot = x + y + offset; return tot; } BOOST_LOCAL_FUNCTION_END(total) double tot = total(100.0); std::cout << tot << std::endl; } void reset() { x_ = 0.0; } bool equal(double x) const { return x_ == x; } private: double x_; }; But if `BOOST_LOCAL_FUNCTION_CONFIG_IMPLICIT_THIS_HACK` is left #undefined (default) then line (1) and (2) must use `this_`: this_->reset(); this_->x_ = x; REFERENCE This code was originally proposed to me by Anthony Williams in order to access the outer class `this` object from within the local function: On Jul 29, 11:05 am, Anthony Williams <anthony....(a)gmail.com> wrote: > Lorenzo Caminiti <lorcamin...(a)gmail.com> writes: > > However, ideally the code expression passed to `BLOCK_INVARIANT()` > > will looks the exactly the same as the code programmed within `f()`. > > Therefore, `this_->eq(x)` will ideally be `this->eq(x)`. Is there a > > way I can do this without inheriting `block_inv` from `c`? And that is > > what I need. > > No, you cannot do that. "this" refers to an instance of the currentclass. Inside member functions of a localclass, "this" refers to an > instance of that localclass. > > You can do it with a nasty (i.e. strictly undefined behaviour, but works > in practice) hack though: if your localclasshas no data members and no > virtual functions then you can derive the localclassfrom theouterclassand cast your "this" pointer to be an instance of the localclass: > > #include <iostream> > class X > { > private: > void g() const > { > std::cout<<"g(), this="<<this<<std::endl; > } > public: > void f() > { > std::cout<<"f(), this="<<this<<std::endl; > struct local:X > { > void foo() const > { > this->g(); > } > }; > > local const* p=static_cast<local const*>(const_cast<X > const*>(this)); > p->foo(); > } > > }; > > int main() > { > X x; > x.f(); > > } > > Anthony > -- > Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ > just::thread C++0x thread library http://www.stdthread.co.uk > Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk > 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976 > > [ Seehttp://www.gotw.ca/resources/clcm.htmfor info about ] > [ comp.lang.c++.moderated. First time posters: Do this! ] See: http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread… -- Lorenzo

3 4

[local_function] N-papers, use cases, etc
by Lorenzo Caminiti 11 Sep '10

11 Sep '10

Hello all, Do you know of any N-paper, use case, example, etc I should consider for local functions? Now I have a basic implementation of Boost.LocalFunction so I am looking for examples to implement to test if the library supports all necessary functionalities and use cases. 1) I have found this N2511 (and I will also check the N-papers it cites): http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2008/n2511.html 2) My original use case for local functions was a constant code block ("cb"): class c { void f(int x) { const int y = x; { BOOST_LOCAL_FUNCTION( (void) (cb0_code)( (const bound)((this)(&x)(&y)) ) ) { // Code compiled in const-correct context. assert(x == y); assert(x > 0); } BOOST_LOCAL_FUNCTION_END(cb0_code) cb0_code(); // Execute code now. } } }; 3) Also scope exit ("se") can be implemented using local functions and therefore considered as a use cases for local functions: class c { void f(int x) { const int y = x; BOOST_LOCAL_FUNCTION( (void) (se0_code)( (auto bound)((this)(&x)(&y)) ) ) { ... // Stuff to do at scope exit. } BOOST_LOCAL_FUNCTION_END(se0_code) // Destructor executes code when this object goes out of scope. struct se0_resource { void ~se0_resource() { se0_code(); } } se0_object; } }; Where `auto bound` binds the variables in scope keeping their original const-qualifiers (e.g., `y` is bound as `const&` while `x` is bound as non-const `&`). Instead, `const bound` forces a const bound and `bound` forces a non-cost bound (e.g., using `(bound)((&y))` would have given a compile-time error because `y` is of const type so it cannot be bound as non-const, while using `(const bound)((&x))` would have been OK because any type can be promoted to be const as usual in C++). -- Lorenzo

1 0

[spirit][qi] strange attribute composition when using expectation points
by Löw, Tobias (Evonik Energy Services GmbH) 11 Sep '10

11 Sep '10

Hi, I get a different attribute composition depending on the use of expectation points. Here is a small example: //////////////////////////////////////////////////////////////////////////////////////////////// // BOOST_FUSION_DEFINE_STRUCT( (client), input, (int, index1) (std::string, text) (int, index2) ) namespace client { namespace fusion = boost::fusion; namespace phoenix = boost::phoenix; namespace qi = boost::spirit::qi; namespace char_enc = boost::spirit::iso8859_1; template <typename Iterator, typename Skipper> struct line_grammar : qi::grammar<Iterator, input(), Skipper> { line_grammar() : line_grammar::base_type(line) { using qi::int_; using qi::omit; using char_enc::char_; using qi::lit; line = int_ >> lit(",") #ifdef USE_EXPECTATION_POINT > *(char_ - ( "," >> int_ ) ) #else >> *(char_ - ( "," >> int_ ) ) #endif >> lit(",") >> int_ ; } qi::rule<Iterator, input(), Skipper > line; }; bool read_line( ) { typedef line_grammar<std::string::const_iterator, char_enc::space_type> grammar; grammar gr; // Our grammar input line_read; std::string source = "1,x,2"; std::string::const_iterator iter = source.begin(); std::string::const_iterator end = source.end(); bool r = phrase_parse(iter, end, gr, char_enc::space, line_read); return r && iter == end; } } // ///////////////////////////////////////////////////////////////////////////////////////////////////////// If USE_EXPECTATION_POINT is not defined then parsing succeeds and line_read == {1, "x", 2 }. But if USE_EXPECTATION_POINT is defined then parsing also succeeds but line_read == {1, "x\0x2", 0 }. So, it seems that expectation points somehow break the semantics of attribute composition. Tobias

3 2

Scalpel: a Spirit&Wave-powered C++ source code analysis library
by Florian Goujeon 11 Sep '10

11 Sep '10

Dear Boosters, I'd like to introduce to you the Scalpel library, a project on which I've worked during the last two years. Scalpel is a C++ library. Its name stands for source code analysis, libre and portable library. It is still under development, but is a fairly advanced work in progress. The purpose of this library is to produce a data structure which corresponds to the meaning (or semantics) of a given C++ source code. It reveals notions such as namespaces, classes, functions, variables, types, etc.. Some source code analyzers, like those used by syntax coloring and autocomplete modules which need to be fast, perform a superficial analysis. Unlike them, Scalpel aims to accomplish a strict and exhaustive analysis so that it could even be used as a compiler front-end. Actually, Scalpel is a compiler front-end, since it goes through the phases of preprocessing, syntax analysis and semantic analysis, just like every C++ compiler does. Maybe one day there will be a Scalpel-powered C++ compiler! Besides, Scalpel's analysis depth will be adjustable in order to fit the needs of most programs. For example, it could be possible to disable the function body analysis for those who need to retrieve namespace and class members only. The labor of C++ source code analysis is extremely complex. This is why having a library wholly devoted to it is a good thing. Many programs could take advantage of such a library. Among them we can find modules for code editors, reverse-engineering tools, code audit software and many other CASE (Computer-Aided Software Engineering) tools that remain to be invented… For further information, visit the Scalpel project's website: http://42ndart.org/scalpel/ The reason why I post this message to the Boost's mailing list is that Scalpel exclusively uses Boost libraries, notably Boost.Wave (for the preprocessing part) and Boost.Spirit (for the syntax analysis part). I believe Scalpel could be a good candidate for inclusion in Boost in the future. But in the meantime, my project needs contributors: I simply cannot do all this work by myself. If I've caught your interest, please visit the Scalpel project's website. Feedback are welcome!

22 44

[interprocess][trunk][windows] named_mutex doesn't work whithin a DLL
by Joaquin M Lopez Munoz 10 Sep '10

10 Sep '10

Environment: MSVC++ 9.0. I create the following DLL: ***bip_dll.cpp*** include <boost/interprocess/sync/named_mutex.hpp> using namespace boost::interprocess; named_mutex mutex(open_or_create,"foo"); __declspec(dllexport) void foo(){} ***bip_dll.cpp*** and use it inside the following executable: ***test.cpp*** __declspec(dllimport) void foo(); int main() { foo(); } ***test.cpp*** The program hangs on DLL loading time when creation of mutex in bip_dll.cpp is attempted. In particular, hanging occurs inside the invocation of get_wmi_class_attribute(strValue, L"Win32_OperatingSystem", L"LastBootUpTime"); in line 1554 of boost/interprocess/detail/win32_api.hpp, when control hits lines 1479 and ff: if( 0 != pIWbemLocator->ConnectServer( bstrNamespace, // Namespace 0, // Userid 0, // PW 0, // Locale 0, // flags 0, // Authority 0, // Context &pWbemServices ) ) { ... This is related to ticket https://svn.boost.org/trac/boost/ticket/4606 . Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 15

Re: [boost] Thoughts for a GUI (Primitives) Library
by Germán Diago 09 Sep '10

09 Sep '10

I feel that http://stlab.adobe.com/ is a good place to start. Reasons. Style of programming is similar to boost's. It would be a good starting point to use a similar approach. I don't know wether the DSEL used is worth it, but the API looks quite good to me.

1 0

Re: [boost] [graph] dfs depending on VertexList container
by fabien.castan＠free.fr 09 Sep '10

09 Sep '10

> It also appears that you are not passing in your color map in main.cpp yes and in this case it should be created internally by the dfs function. > If your graph has a vertex_index_map property map (filled in appropriately) If I use bundle properties is there an automatic vertex_index_map ? > It's not just to initialize the color map, but to use it during the > algorithm as well. ok > Could you please send your full error trace? Exactly the same code works with vecS. In file included from /usr/include/c++/4.4/backward/hash_set:59, from .../extern/boost/boost/pending/container_traits.hpp:23, from .../extern/boost/boost/graph/detail/adjacency_list.hpp:31, from .../extern/boost/boost/graph/adjacency_list.hpp:324, from applications/testGraph/src/main.cpp:3: /usr/include/c++/4.4/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. In file included from .../extern/boost/boost/graph/named_function_params.hpp:23, from .../extern/boost/boost/graph/depth_first_search.hpp:22, from applications/testGraph/src/main.cpp:5: .../extern/boost/boost/property_map/shared_array_property_map.hpp: In member function 'T& boost::shared_array_property_map<T, IndexMap>::operator[](typename boost::property_traits<IndexMap>::key_type) const [with T = boost::default_color_type, IndexMap = boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>]': .../extern/boost/boost/property_map/property_map.hpp:325: instantiated from 'void boost::put(const boost::put_get_helper<Reference, PropertyMap>&, K, const V&) [with PropertyMap = boost::shared_array_property_map<boost::default_color_type, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >, Reference = boost::default_color_type&, K = void*, V = boost::default_color_type]' .../extern/boost/boost/graph/depth_first_search.hpp:197: instantiated from 'void boost::depth_first_search(const VertexListGraph&, DFSVisitor, ColorMap, typename boost::graph_traits<Graph>::vertex_descriptor) [with VertexListGraph = boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, DFSVisitor = CycleDetector, ColorMap = boost::shared_array_property_map<boost::default_color_type, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >]' .../extern/boost/boost/graph/depth_first_search.hpp:297: instantiated from 'void boost::depth_first_search(const VertexListGraph&, const boost::bgl_named_params<P, T, R>&) [with VertexListGraph = GraphContainer, P = CycleDetector, T = boost::graph_visitor_t, R = boost::no_property]' applications/testGraph/src/main.cpp:77: instantiated from here .../extern/boost/boost/property_map/shared_array_property_map.hpp:36: error: no match for 'operator[]' in '((const boost::shared_array_property_map<boost::default_color_type, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >*)this)->boost::shared_array_property_map<boost::default_color_type, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >::data[boost::get [with PropertyMap = boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t>, Reference = const boost::detail::error_property_not_found&, K = void*](((const boost::put_get_helper<const boost::detail::error_property_not_found&, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >&)((const boost::put_get_helper<const boost::detail::error_property_not_found&, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >*)(&((const boost::shared_array_property_map<boost::default_color_type, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >*)this)->boost::shared_array_property_map<boost::default_color_type, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, Vertex, Edge, boost::no_property, boost::listS>, boost::detail::error_property_not_found, const boost::detail::error_property_not_found&, boost::vertex_index_t> >::index))), ((void* const&)((void* const*)(& v))))]' .../extern/boost/boost/smart_ptr/shared_array.hpp:85: note: candidates are: T& boost::shared_array<T>::operator[](ptrdiff_t) const [with T = boost::default_color_type]

2 1