- Boost - lists.boost.org

[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

Re: [boost] [graph] out_edges sort
by fabien.castan＠free.fr 09 Sep '10

09 Sep '10

> There is no way to do a sort in place ? >> Not using the "official" interfaces, AFAIK. What are you trying to do? >> Maybe there's a different algorithm in BGL that might do what you want. I compute some values on each node, depending on connected vertices, etc. Next I need to visit my graph in a dfs but going first into out_edges with the biggest precomputed value.

2 1

Re: [boost] As a side note about source control
by Eric Hopper 09 Sep '10

09 Sep '10

Christoph Heindl wrote: > > As a side note, and I'm sure I'm opening a can of worms by even saying > > this... I find working on projects that do not use distributed source > > control to be really irritating nowadays. > > Could you explain why? What kind of projects (organizational structure). Well, the organizational structure of the project doesn't matter at all in my answer to the question. I will describe to you what I did with the Boost library in order to explain. I wanted to generate a whole ton of small random numbers quickly and found the smallint distribution. When I looked at the code, I was certain I could make something a lot faster that was very specific to my need, so I did, tested it and discovered that it was indeed much faster. Then I realized that by carefully using templates I could make it work for a much more general case. Now I want to make something that's a library module. I morph my special case into a more general case as a proof of concept. When that works, I then consider how to integrate the library module into Boost because that's where it belongs. There are lots of different versions of Boost that have been released and are installed on the various systems I work on. Not only that, but regardless of whether or not Boost ever accepts my changes I want to keep them locally so I will always be able to have a version of Boost with my changes. If I simply check out one of the tags for a version of Boost I have, I can certainly make my changes there, but I can never check them in or effectively track them against Boost itself as it moves forward. I could check out trunk, but trunk does not correspond to any version of Boost installed on my system and means I would be testing all kinds of changes that may or may not be ready for use. I'm not interested in being a Boost tester. And again, I really couldn't check my changes in or effectively integrate them with later versions of Boost. I eventually settle on doing an svn export of several successive versions of Boost and checking each into Mercurial. This is complicated by the need to undo Subversion's keyword replacement with a small perl script. And actually converting the Boost Subversion tree to Mercurial isn't very feasible because Subversion's idea of branching is so dissimilar. For example, there are a few cases of a tag being removed and replaced with a fresh copy of trunk, and this is very hard to model in any other source control system. Once I've done this conversion, things are pretty smooth. I can check in all my changes to my local Mercurial clone. I can play around with things, do code cleanup and various other things while still being able to track my source. I can also do development on my desktop and laptop and move changes smoothly between them even though the changes are checked in when the laptop may not be connected to the Internet. Later I discover Boost 1.44 has been released, so I repeat the process I used before to convert 1.44.0.beta1 and 1.44.0 to Mercurial revisions. Then I use Mercurial's merge feature to merge my changes back in. Poof, I have a version of Boost that has my changes, and I can publish a patch against Boost 1.44 as opposed to 1.43 if need be. If Boost had used a distributed version control system from the very beginning, that previous 6 paragraphs could've been condensed down to a couple of paragraphs. And future merges with Boost would generally be pretty trivial unless the random library changed significantly. This is true of any project I want to make a change to. I do not want to have to interact especially with the community for a one off change to a project I'm not really interested in becoming a regular contributor to. A centralized source system makes it hard to make changes except on active branches which frequently contain changes I'm not interested in testing. It makes it hard to track my changes locally regardless of the decisions of the community running the project. And it makes it hard to contribute a change back to the community when I don't want to become a full member, which in turn raises a barrier to entry to me being inexorably sucked into a community I didn't think I was going to participate in. All of these are regardless of the organizational structure of a project. They have everything to do with my ability to control and use the source code I download. Simply put, distributed source control is what fits the Open Source development model. I do not consider this an opinion so much as a flat statement of fact. The ability to fork is absolutely central to Open Source. It's harder to fork when you lose the history and ability to track changes against the original because a project's history and ability to track your changes to it is as important as a dump of the source code at a moment in time, if not more so. Distributed source control avoids these problems and makes forking easier, almost trivial. Distributed source control therefor fits the Open Source model better. In my opinion, distributed source control is the best fit for almost any development. But that's just my opinion, and I don't have nearly as much in the way of hard logical argument to back that up. I just know that I've used source control for nearly (and I'm rather embarassed that the word 'nearly' is there, but a 17 yr old in 1988 isn't likely to have heard of source control) as long as I've been a professional programmer. And distributed source control systems are the first source control systems I've used where I didn't feel like I was spending a lot of time fighting the source control system because it didn't work the way I needed it to. Discipline does not always require pain. -- A word is nothing more or less than the series of historical connotations given to it. That's HOW we derive meaning, and to claim that there is an arbitrary meaning of words above and beyond the way people use them is a blatant misunderstanding of the nature of language. -- Anonymous blogger -- Eric Hopper (hopper(a)omnifarious.org http://www.omnifarious.org/~hopper)--

5 4