- Boost - lists.preview.boost.org

Re: [boost] [serialization] Must the objects being serialized outlive the archive?
by Chris Yuen 18 Sep '10

18 Sep '10

Jeff Flinn wrote: > IIUC, tracked objects have their addresses place in a map, so that > subsequent serialized pointers of the same value are serialized as a > reference to the original object at that address, rather than > serializing another copy of the object. That was spot on! I did a couple of tests and I think I've confirmed this is indeed the behavior and the reason why data gets corrupt. On my platform (MSVC), new data gets allocated to the last free pointer's address and that confuses boost::serialization. >From your understanding, doesn't that basically means the "objects being serialized must outlive the archive"? Since there's no way to tell "new" to not allocate objects at an older address unless I keep objects there. So basically I must keep all data in memory until the serialization process is complete. I tried to think hard about this. Do you see any workaround to this issue so that I don't have to effectively double the memory usage? (Maybe have boost::serialization write things out immediately and clear the internal cached pointers)? Maybe boost::serialization should provide that command or some kind of "flush" command? Best regards, Chris Yuen

3 2

[function] Question on semantics of boost::function
by David Sankel 18 Sep '10

18 Sep '10

Is a boost::function<void (int)> semantically different from a boost::function<void (int &)> or a boost::function<void (const int)>? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

3 2

Re: [boost] [serialization] Must the objects being serialized outlive the archive?
by Brian Wood 17 Sep '10

17 Sep '10

Robert Ramey: > This would work. What won't work is > > { > boost::scoped_ptr<Strings> s; > const Strings * s = new Strings("Hello", "World")); > const * x = s; > oa << s; > delete s; > oa << x; > ... > } Be sure to add the --automagically flag to get that to build. > Your making this way too hard, just look at the examples and tests to see > that all you have to do is serialize though a base class pointer. You are being sloppy. But thanks for stopping the top posting. Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

Re: [boost] [serialization] Must the objects being serialized outlive the archive?
by Chris Yuen 17 Sep '10

17 Sep '10

Robert, > It is a fundamental concept that saving data to an archive should > not alter the data. In many cases this is detected at compile time > and a warning is issued. As noted in another post, you might > snooker the system by suppressing tracking, I don't really understand. Why does the tracking has something to do with the object's lifetime? Doesn't boost::serialization has all the information it needs (tracking info, data, etc.) when I call "oa << base_ptr"? Isn't it possible to just write out everything to the stream? > But I'm intrigued why you want to do this? Why don't you just use > { > std::ofstream stream(kFilename, std::ios::binary); > boost::archive::text_oarchive oa(stream); > > { > const Strings s("Hello", "World")); > oa << s > } > ... > } As you can see from the code example, I want to be able to deserialize a list of these "commands" from the base pointer, because I actually have hundreds of these polymorphic commands and they need to each have a virtual "Execute()" method so that they know how to apply themselve to an "Actioner." (Instead of using a giant switch-case in the Actioner to identify each command) I figured it's better than using a magic number, opcode approach since boost::serialization already provides tracking. I was under the impression that if I want to deserialize using a base pointer, I must also serialize via the base pointer, is that correct? So I guess the below won't work with the original deserialization code? > { > boost::scoped_ptr<Strings> s; > const Strings * s = new Strings("Hello", "World")); > oa << s; > .... // same for all the other stuff > // s deleted as it goes out of scope > } Best regards, Chris Yuen

3 2

developer guidelines
by Lorenzo Caminiti 17 Sep '10

17 Sep '10

Hello all, This question might be trivial but I would like to confirm: What are the best/latest documents to read in order to develop a Boost library? I would be interested on how to: 1) Write code compliant to Boost coding guidelines. 2) Write documentation. 3) Write tests. 4) Write examples. 5) Integrate code within Boost files structure. 6) Integrate code within Boost build system. Thank you very much. -- Lorenzo

2 1

[local_function] any interest in a LocalFunction library?
by Lorenzo Caminiti 17 Sep '10

17 Sep '10

Hello all, Is there interest in a library that implement local functions for C++? Boost.LocalFunction (PROPOSAL DRAFT) This library allows to define and invoke a function locally within a code block. In addition to the parameters that can be passed to the function as usual upon its invocation, any variable within scope can be /binded/ to the local function declaration and used by the local function definition code. MOTIVATING EXAMPLE Consider the following example: #include <boost/local_function.hpp> class c { public: c(double const& x): x_(x) {} void f(double& x) { double y = x * 10.0; bool r; { double z = x * 100.0; // Local function definition. BOOST_LOCAL_FUNCTION( (bool) (l)( (char* const)(a) // Usual non-binded param. (bool)(b) // Another usual non-binded param. (binded)( (&x) // Binded param by reference. (const& x_) // Binded param by const reference. (y) // Binded param by value (copy). (const z) // Binded param by const value (copy) (const this) // Binded const object (by pointer). // (this) // Or, binded non-const object. ) ) ) { // Use `this_` here (not `this`) to access binded object. assert( this_->eq(x_) ); ... // Local function definition code. } BOOST_LOCAL_FUNCTION_END // Local function call only specifies non-binded params. bool r1 = BOOST_LOCAL_FUNCTION_CALL(l)("hello", true); bool r2 = BOOST_LOCAL_FUNCTION_CALL(l)("bye", false); r = r1 || r2; } // Local function goes out of scope here. ... } bool eq(double const& x) const { return x_ == x; } private: double x_; }; Note the following: 1) The local function `l` is only defined locally within a code block of the function `f`. 2) The parameter `x` of the function `f`, the member variable `x_`, the local variables `y` and `z`, and the object `this` are binded to the declaration of the local function. Therefore, they can all be used by the local function definition code even if they are not explicitly passed to the local function when it is invoked. (Also note that the binding syntax conveniently does not require the user to specify the types of the binded parameters but just their /binding-qualified/ names.) 3) The local function can be invoked (multiple times) from within the scope of its declaration. As usual, each invocation specifies the non-binded parameters and, for non-void functions, it returns the function result value. BACKGROUND I have not yet implemented Boost.LocalFunction. I will be implementing local-function features as part of Boost.Contract development (in order to support constant-correct block invariants and loop variants). I am probing for interest to understand how much effort I shall invest in making the local-function features a standalone library like Boost.LocalFunction separated from Boost.Contract. On Thu, Apr 15, 2010 at 7:02 PM, Alexander Nasonov <alnsn(a)yandex.ru> wrote: > vicente.botet wrote: >> VBE> Boost.ScopeExit showed a technique that can be used to >> emulate local functions. Alexander proposed long time ago to provide >> it independently from ScopeExit but to my knowledge this has not >> been done. > > Sorry for the late reply, I'm not following every boost thread, I got > this message via google alerts. > > Yes, this has not been done. Local function can borrow argument > binding syntax from ScopeExit but there are other things I need to think > of. For instance, in > > int BOOST_LOCAL_FUNCTION(f, > (BOOST_LOCAL_FUNCTION_BIND( (a)(&b) ), int c)) { > // ... > } BOOST_LOCAL_FUNCTION_END > > syntax, is there any way to shorten BOOST_LOCAL_FUNCTION_BIND to "bind"? > > The syntax doesn't have to be exactly as above. If someone could > take a lead on this it would be great. I don't have time for this, > I'm afraid. The Boost.LocalFunction implementation will largely rely on parameter binding techniques similar to the ones currently used by Boost.ScopeExit as suggested to me by Steven Watanable, Vicente Botet, and Alexander Nasonov. Thank you. -- Lorenzo

9 35

Any interest in dynamic dispatching mechanism from "interface" to template functions ?
by Raffi Enficiaud 16 Sep '10

16 Sep '10

Hello all, The idea behind is not new and consists in dispatching a call of an interface function to the correct template instance, depending on the runtime or compile time parameters. The field of application is (to me) the release of static/dynamic libraries including functions with a predefined set of types combination. This way, the library (compiled once) can easily be plugged to another framework or a script program (I personally use it with boost.python). An example of use could be (general idea, not a real code of course): // -------------- template <class real_type> int template_function(real_type const& r_class1, double param_d, int& param_out) { // ... return 0; } int interface_function(MyInterface const* i_class1, variant const& param, variant& out) { // return value int return_value; // constructs the dispatcher object with a reference to the values passed to interface_function dispatcher<int, MyInterface const*, variant const&, variant&> dispatch_object(return_value, i_class1, param, out); bool res = dispatch_object.calls_first( fusion::vector_tie( template_function < class_t1 >, template_function < class_t2 > //... ) ); if(res) return return_value; return -1; } // -------------- The dispatch_object tests for the convertibility of each instance ui of the arguments Ui of the interface function, with the corresponding argument Ti of the template function. The type of matching is defined by external objects, with a simple interface providing two methods: a convertibility test and a conversion. The types are "cleaned" in order to have a limited number of conversion structures. Currently this mechanism is used in a generic image processing library. The images have all the same virtual interface and the dispatch calls the correct template function based on the concrete type of the image. It also includes a "back conversion" for Ui's that are non-const reference or pointers. The dispatch mainly makes use of boost.fusion, boost.mpl and boost.function_types. I have checked a little bit the Boost.Vault but, correct me if I am wrong, the current dispatching mechanisms do not address exactly this issue. The code is already open-source released under the boost license. I can put some samples in the Vault if there is any interest. Your comments are very welcome ! Kind regards, Raffi Enficiaud

4 11

[serialization] Must the objects being serialized outlive the archive?
by Chris Yuen 15 Sep '10

15 Sep '10

Hi, I am using boost::serialization along with the eos::portable_archive (on Boost Vault). All the data that I serialize are polymorphic types, i.e. pointers. By experiment and days of frustration, I found out that the objects being serialized must "outlive" the archive or the serialization process -- otherwise I'd get segfault and corrupt data. I hope that was clear. To demonstrate this, I wrote a small example at http://boost.codepad.org/mqX5dUf6 (I'm a noob and I don't know the tradition to paste code -- should I just paste it in the message body or something?) The program will crash when you run it. However, if you comment out both the "delete" statements (leading to memory leaks, but at least the objects will outlive the archives), then everything works fine. Is there a way so that I can "flush" the serialization process so that it gets written immediately? The way that it is now, I must keep in memory all the things that I want to serialize. Thanks! Chris Yuen

3 3

[thread] tss_null.cpp missing namespace boost
by David Deakins 14 Sep '10

14 Sep '10

When the changes were made a few months ago to move all the tss hook functions from the global namespace to the boost namespace, it looks like tss_null.cpp got left out. It's tss_cleanup_implemented stub function (used for the regression tests) is still over in the global namespace. I opened up ticket 4650 with a patch that fixes this issue. Let me know if there are questions, -Dave

1 0

Boost container similar to Judy arrays?
by Achilleas Margaritis 14 Sep '10

14 Sep '10

Hi all. Does boost have a container with similar properties to Judy arrays? I searched the documentation but I did not find anything similar. Here is the Judy arrays home page: http://judy.sourceforge.net/index.html __________ Information from ESET Smart Security, version of virus signature database 4486 (20091007) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4486 (20091007) __________ The message was checked by ESET Smart Security. http://www.eset.com

3 2

Re: [boost] Scalpel: a Spirit&Wave-powered C++ source code analysis library
by Brian Wood 14 Sep '10

14 Sep '10

Doug Gregor: >I want to see great, new ideas in C++ parsing and development tools, >but I strongly feel that those ideas could be far better disseminated >through extending/adapting/changing existing the large-scale, >industry-backed projects (GCC or Clang/LLVM) than by bringing up a >third large-scale competitor. Years ago I looked at GCC and considered using it as a basis for what I'm working on, but after spending a few months working with the code, concluded it wouldn't make a good basis for my project. Perhaps you are being generous about it here, but I can't recommend anyone join that project. I certainly hope Clang is superior to GCC in many ways. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384 "If you can't join 'em, beat em."

4 5

Link error in Boost Exception MSVC tests
by Emil Dotchevski 13 Sep '10

13 Sep '10

Does anyone have an idea why I'm getting this error: http://tinyurl.com/392vnmk (this works when I run the tests on my own system.) Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

application for the "Who's Using Boost?" list
by Roni Simonian 13 Sep '10

13 Sep '10

# The name of the product: Maze (TM) # The name of the company: Ariadne LLC # A paragraph describing the product: Maze (TM) is a professional tool for parallel programming. It provides a deterministic environment for testing and debugging multiprocess and multithreaded applications on X86 and X86-64 Linux platforms. # Parts of Boost you used: Bind, Enable_If, Exception, Filesystem, Function, StaticAssert, TypeTraits, Utility # URL: www.ariadne-soft.com

1 0

[Proto][Phoenix] Use default transform with SFINAE for expressions?
by Mathias Gaunard 13 Sep '10

13 Sep '10

I would quite like it if polymorphic function objects created by Phoenix could restrict overload resolution to types for which their function body is valid, using SFINAE for expressions. Basically, this would allow something like this: struct foo {}; void dummy_function(...) { std::cout << "[not streamable]"; } make_overload( std::cout << arg1, dummy_function ) (foo()); (with make_overload what you'd expect) The dummy function would be called if the first one doesn't match, instead of resulting in a hard error. (surely it would also be nice to add a module to create "..." functions in Phoenix, but that should be easy) Now I looked a bit at how Phoenix v3 and Proto work, and it seems the main problem to do that is in the default transform. Albeit it uses decltype for its return type, this is not done in a template deduction context, which prevents it from doing its SFINAE magic. I tried to do that, but then a transform is assumed everywhere to be monomorphic, so SFINAE doesn't "propagate" out of default_TAG. Before I go ahead and try to convert all result_type to result with templates, which could affect compile-time, I'd like to have some feedback on the whole idea, and whether this is the right way to do it.

3 7

[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

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