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

[multi_index_container] Compiling the examples
by Robert Jones 09 Sep '08

09 Sep '08

Trying to multi_index_container I'm getting these compile errors. Apart from #include <string> and using namespace boost this lifted verbatim from the example documentation. #include <string> struct employee { int id; std::string name; employee(int id,const std::string& name):id(id),name(name){} bool operator<(const employee& e)const{return id<e.id;} }; #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/identity.hpp> #include <boost/multi_index/member.hpp> using namespace boost; // define a multiply indexed set with indices by id and name typedef multi_index_container< employee, indexed_by< // sort by employee::operator< ordered_unique<identity<employee> >, // sort by less<string> on name ordered_non_unique<member<employee,std::string,&employee::name> > > > employee_set; My error is multi.cpp:23: error: `indexed_by' was not declared in this scope multi.cpp:25: error: `ordered_unique' was not declared in this scope multi.cpp:25: error: `identity' was not declared in this scope multi.cpp:25: error: template argument 2 is invalid multi.cpp:25: error: expected unqualified-id before '>' token multi.cpp:25: error: expected `,' or `;' before '>' token I'm using Boost 1.36 and gcc 3.4.4 (maybe this too old?). Can anyone tell me what I'm doing wrong? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 3

[multi_index_container] push_back?
by Robert Jones 09 Sep '08

09 Sep '08

Still having a little teething trouble with multi_index_container. This code, #include <string> #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/identity.hpp> #include <boost/multi_index/member.hpp> using namespace boost; using namespace boost :: multi_index; struct Employee { int id; std :: string name; }; bool operator < ( Employee const & l, Employee const & r ) { return l.id < r.id; } int main( ) { typedef multi_index_container< Employee, indexed_by< ordered_unique<identity<Employee> >, ordered_non_unique<member<Employee, std :: string, & Employee :: name> > > > EmployeeSet; Employee employees[ ] = { { 1, "Adam" }, { 2, "Craig" }, { 3, "Brian" }, { 4, "Dave" }, }; // EmployeeSet eSet( employees, employees + sizeof( employees ) / sizeof( Employee ) ); EmployeeSet eSet; std :: copy( employees, employees + sizeof( employees ) / sizeof( Employee ), std :: back_inserter( eSet ) ); return 0; } Gives me an error stating there is no push_back method on the container. /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_iterator.h:364: error: 'class boost::multi_index::multi_index_con tainer<Employee, boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<Employee >, mpl_::na, mpl_::na>, boost::multi_index::ordered_non_unique<boost::multi_index::member<Employee, std::string, &Employ ee::name>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na , mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<Employee> >' has no member named 'push_back' is there something I'm missing out? Thanks, Rob.

1 0

[smart_ptr] release()
by Phil Bouchard 09 Sep '08

09 Sep '08

As it turns out I think a release() member function should be added to the smart pointer. Its purpose is to give away ownership of the object. See the following pseudo-code: template <typename T> class smart_ptr { ... smart_ptr(element_type *); value_type * get(); element_type * release() { element_type * __p = pointer_ref(); pointer_ref() = 0; if (-- counter_ref()) return 0; else return __p; } }; It follows the same idea of its predecessor auto_ptr<> but will return a null pointer if the object is still shared thus not ready to be deleted. This way the allocator will be much easier to support either by calling this function before deallocate(), inside it or by using a specialized wrapper class to handle it: template <typename T> class allocator { ... typedef smart_ptr<T> pointer; void deallocate(pointer & __p) { delete p.release(); } }; -Phil

6 15

[thread_safe_signals] changing the namespace used
by Stjepan Rajko 09 Sep '08

09 Sep '08

Hello, In trying to use thread_safe_signals with Dataflow.Signals, I did the following before including the headers to cause thread_safe_signals to use the boost::signals namespace instead of boost::signalslib (I needed this because Dataflow.Signals adds to the boost::signals namespace): #define signalslib signals #define signals signals The first line was to change the namespace used, and the second to prevent thread_safe_signals from aliasing boost::signals to itself. This worked for gcc on OS X, but I just found out that msvc 2005 express chokes on it (in some preprocessing file iteration loop). Is there a better solution for this? Thanks, Stjepan

2 2

[dataflow][review] loading Dataflow.Signals components from shared libraries
by Stjepan Rajko 09 Sep '08

09 Sep '08

In the Dataflow library / Dataflow.Signals layer review discussions, a few people have mentioned the potential usefulness of loading components at runtime (e.g., from a shared library). I put together a small example of how this could be done for Dataflow.Signals components using the (prototype) Dataflow.Blueprint layer and the Extension library: http://svn.boost.org/svn/boost/sandbox/SOC/2007/signals/libs/dataflow/examp… The component_add.cpp file contains the implementation of a component (that adds two numbers and outputs the result), and the code required to access it through an Extension factory_map. The extension_example.cpp file loads the shared library created from component_add.cpp, instantiates the provided component, and uses it to complete a network. The Blueprint layer is still under development (and has somewhat ugly syntax), but I hope this example can still demonstrate some future possibilities of the Dataflow library with regards to loading components at run-time. It has been tested to work with MSVC 2005. Regards, Stjepan

1 0

[asio] Support for raw sockets and ICMP in latest version
by Carlo Medas 08 Sep '08

08 Sep '08

Dear Asio developers, I've seen with some excitement the new release which announces raw sockets and ICMP support. Since I've not been able to find any new example showing usage of these features, I've tried to investigate the code but I still got the same question: is ICMP packet receive/sending supported? And moreover, are raw data (IP layer?) sockets supported and thus usable? Thanks in advance. Kind regards, Carlo Medas

1 0

Re: [boost] [boost numeric binding] patch
by Michael Gauckler 08 Sep '08

08 Sep '08

Hi Thomas, Under Linux gccxml is setting the __GNUC__ and everything works. Under Windows it is trying to emulate msvc (and therefore not setting __GNUC__), this is why it fails and why this additional check is necessary. Attached again the patch, which also indicates which files needs to be patched. Regards, Michael

1 0

Re: [boost] [boost numeric binding] patch
by Thomas Klimpel 08 Sep '08

08 Sep '08

Hello Michael, I could certainly apply your patch, but why doesn't GCCXML defines __GNUC__ in the first place, when it's effectively just a gcc? Or is it indeed different from gcc, so that I should test that it really works? Regards, Thomas

1 0

[RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
by Jurko Gospodnetić 08 Sep '08

08 Sep '08

Hi all. There have been requests to make Boost Build cleanly support Microsoft's 'secure STL'/'checked iterators' feature. Here's is one suggested implementation and how that will affect building Boost libraries on Windows: We add a new <msvc-checked-iterators> Boost Build feature with values 'off' and 'on' and 'off' being the default. The effect of the feature would be to define the SCL_SECURE preprocessor constant to 1 for feature value 'on' or to 0 for feature value off. This would affect only code compiled using MSVC compiler versions 8.0 & above. Libraries compiled with compilers affected by this setting would have their name mangling changed as follows: * If the setting is 'off' there would be no change. * If the setting is 'on' the name would get en extra letter 'c' added to its 'runtime tag' letter group (together with 's' for statically linked libraries, 'd' for debug, 'p' for the stlport standard library, etc.). Effects this would have on Boost libraries: * If we implement the proposed solution the default Boost library build behaviour will change. Boost libraries built by default will have Microsoft's secure STL (a.k.a. checking iterator) support disabled while currently, when we do nothing explicit about those settings, Microsoft compilers enable that support by default. * Making a complete Boost library build using the MSVC toolset will take twice as long as there may now be twice as many property combinations affecting the build. On the other hand user can always easily choose from the build command line which versions he wants in case he wants a subset. Selecting msvc-checked-iterators=on would get the current default behaviour. Some extra ideas to consider: * Add an additional 'default' feature value which would cause Boost Build to do nothing. This would on the other hand mess up library name mangling unless Boost Build were taught to know exactly what defaults each compiler or compiler version uses. Please give your comments on at least the following: * Feature name. * Any additional values that might be needed. * Any additional compiler flags/options/preprocessor constants that might be related to this. * Default value. * Library name mangling. * Any additional compilers this might affect, e.g. Comeau, Intel, etc. * Any additional runtime libraries this might affect, e.g. stlport. Many thanks for any feedback you can provide. Best regards, Jurko Gospodnetić

12 22

Mixed use of "include" directives with quoted vs. angle-bracketed params, causing havoc
by Victor Vojtech Terber 08 Sep '08

08 Sep '08

I have multiple Boost versions installed in different file locations. I occasionally ran into problems with mixed-up Boost headers. This was due to Boost's use of both quoted and bracketed syntax of the include directive to include its headers. The standard allows for different results for resolving the include directive depending on the chosen form. In particular the angle-bracketed form is narrower than the quoted one (see chapters 16.2.2 and 3). So the point in the file system from where the file will actually be included may legally differ, based on the form of the include directive. I don't mind which alternative Boost uses. But in my opinion it should be consistent inside Boost headers, shouldn't it? With some file system layouts it gets very inconvenient to pre-determine by simple set-up of compiler or environment variables which version will get used. I also fail to see any obvious downside of a unification.

8 15