- Boost-users - lists.boost.org

mpl, apply, placeholders
by Kiuhnm 09 May '06

09 May '06

I am just a beginner so my question could be very stupid. Please be patient. What is wrong with the following code? It should be clear enough what I am trying to do. >>> #include <iostream> #include <boost/mpl/int.hpp> #include <boost/mpl/apply.hpp> #include <boost/mpl/plus.hpp> int main() { using namespace boost::mpl; // ... typedef apply< plus< _, int_<10> >, int_<1> >::type t; std::cout << typeid(t).name() << std::endl; typedef apply< plus< _, int_<10> >, _ > t2; typedef apply< t2, int_<1> >::type res; // ??? std::cout << typeid(res).name() << std::endl; } <<< Kiuhnm -- View this message in context: http://www.nabble.com/mpl%2C-apply%2C-placeholders-t1379886.html#a3705111 Sent from the Boost - Users forum at Nabble.com.

4 7

Re: [Boost-users] [statechart] Event handlers and state reusage
by Oliver.Kowalke＠qimonda.com 09 May '06

09 May '06

>Tim Milward wrote: >> Johan Nilsson wrote: >>> 1. For a state, is it possible to specify a method that will be >>> called when an event with no defined handlers is received? >> >> Interesting question. Can all events inherit from a common base class, >> to which a state could define a (default) reaction, and override this >> with reactions to specific event sub-classes? > >Should be possible from my point of view. Not sure how the framework would >handle that even though it sounds reasonable. It's a bit limiting though, >and should be possible have support for in the library. By default statechart ignores a event with no handlers in the statemachine. Statechart allows to catch the event by adding following function to your state_machine class: void unconsumed_event( sc::event_base const& ev) { ... } Oliver

2 1

How to pass memory range to functions?
by Olaf van der Spek 09 May '06

09 May '06

Hi, I've got a lot of functions (compression, encryption, hashing, encoding, etc) that work on a memory range. I wrote my own class that has constructors for void*, void* void*, size_t std::string& and that automatically reinterpret_cast to unsigned char*. But I'm wondering, is there a better way to do this? Boost.Range looked appriopriate but it seemed it didn't support this scenario.

1 0

documentation for bjam sub-variants
by Russell Hind 09 May '06

09 May '06

Can some one point me to the page that details the sub-variants (such as <runtime-link> and <threading>) etc that are available to pass to bjam when building boost. I have found the main bjam page that gives a few examples but it doesn't list all the options and their meanings. Thanks Russell

2 2

[operators] loss of performance
by Brian Budge 09 May '06

09 May '06

Hi all - I just tried out the operators library for the first time today. I was quite happy with how easily it helped me implement my test class. Unfortunately, I'm running into some performance issues, in particular with operator +. The interesting thing is that the new operator += is actually faster than my old += by about a factor of 2, but my operator + is slower than my old + by a factor of nearly 10! I'm new here, and not really sure how much code is appropriate to post to the list, so here's a minimal rundown: -------------------------------------------------------------------------- Old code: template<typename real> Vector3<real> operator + (const Vector3<real> &a, const Vector3<real> &b); template<typename real> class Vector3 { protected: real m_v[3]; . . friend Vector3 operator +<> (const Vector3 &a, const Vector3 &b); }; template<typename real> inline Vector3<real> operator + (const Vector3<real> &a, const Vector3<real> &b){ Vector3<real> t; t[0] = a[0] + b[0]; t[1] = a[1] + b[1]; t[2] = a[2] + b[2]; return t; } ------------------------------------------------------------------------------------------------- New code (note that the new code is templatized on size, and that my instantiations were of size 3 to match the above code): template<typename T, unsigned int S> class vec : boost::additive< vec<T, S> , boost::multiplicative< vec<T, S>, T > > { private: typedef unsigned int uint; typedef const T &const_reference; typedef T &reference; private: boost::array<T,S> m_v; template<typename U> vec &operator += (const vec<U,S> &t){ for(uint i = 0; i < S; ++i){ m_v[i] += t.m_v[i]; } return *this; } }; Any ideas how to increase the performance of the new code here? A factor of 10 makes it seem like I am just missing something important. Thanks, Brian

5 6

[boost][test] - BOOST_FIXTURE_TEST_SUITE, BOOST_FIXTURE_TEST_CASE clarification
by Ed Johnson 09 May '06

09 May '06

In 1.33.1 release, is the following true? BOOST_FIXTURE_TEST_SUITE( suite_name, F ); //not supported BOOST_FIXTURE_TEST_CASE( test_name, F ); //not supported Thanks, Ed

2 6

Building boost on Mac OS 10.4
by Zokirov, Umed 08 May '06

08 May '06

Hi there, Has anyone successfully built Boot 1.33.1 on Moac OS X 10.4? In my case it fails to build test - related libs. I fugured out the issue with two-level namespacing, however waas not successful with specific linker settings to solve them Perhaps, boost-build mailing list is better to ask, nevertheless, I would suppose some of the users actually built boost. Umed

2 1

Inconsistency between boost::bind and boost::lambda::bind
by Gerardo Lamastra 08 May '06

08 May '06

Hello everybody, I've started to use the functional programming facilities offered by boost, and they're really impressive. To begin with, I've started using both; I've seen however, that when I #include both <boost/bind.hpp> and <boost/lambda/bind.hpp> I must use full namespace names to address lambda placeholders. In other words, instead of writing for_each(container.begin(), container.end(), cout << _1 << constant('\n')); I've to write for_each(container.begin(), container.end(), cout << boost::lambda::_1 << boost::lambda::constant('\n')); also if I've written a using boost::lambda declaration; I know, I can simplify this using a namespace alias, but I was trying to keep the code less clobber as I can, because it has to be used for teaching/example purposes. So, my first question would be: where could I find an exhaustive comparison between these two facilities? And, is there any indication on what to prefer, also related to future development and/or inclusion in C++ standards (If I remember well, boost::lambda has been proposed in tr1?) The second question points at a small inconsistency that I believe I've found while doing some experiments: boost::bind and boost::lambda::bind offer similar construct, but the former works while the latter fails in the example included below. I'm using boost_1_33_1, with g++ -v (provided below) Target: i586-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-languages=c,c++,ada,f95,objc,java --host=i586-mandriva-linux-gnu --with-system-zlib --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib Thread model: posix gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0) The situation is the following: if I try to create a nullary lamnda function with boost::lambda::bind() like this: generate_n(inserter(v, v.begin()), 10, boost::lambda::bind<Slave*>( boost::lambda::new_ptr<Slave>(),*this) ); the compiler fails to compile: it tries to pass the this pointer as a const reference somehow, and then it fails claiming that a Slave(const Master& m) cannot be found; If I try to add one, it fails with a similar error. If I substitute the boost::lambda::bind() with a boost::bind(), it compiles & works perfectly. Thanks for the attention, -Gerardo Lamastra ------------------------------------------------------------------------- #include <set> #include <algorithm> #include <iterator> #include <iostream> #include <boost/lambda/lambda.hpp> #include <boost/lambda/construct.hpp> #include <boost/lambda/bind.hpp> #include <boost/bind.hpp> using namespace std; using namespace boost::lambda; class Master; struct Slave { static int globalId; Master& master; int id; Slave(Master& m) : master(m), id(++globalId) {}; }; int Slave::globalId = 0; class Master { struct Builder { typedef Slave* result_type; Slave* operator()(Master& master) { return new Slave(master); }; }; static Slave* build(Master& master) { return new Slave(master); } public: void print(set<Slave*> s) { for_each(s.begin(), s.end(), (cout << constant("S: ") << (boost::lambda::_1) ->* &Slave::id) << '\n' ); } void f1() { /* This is the most trivial thing I've tried, but I need to write builder explicitely; */ set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::bind(Builder(),*this) ); print(v); } void f2() { /* A more compact, but substantially identical form */ set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::bind(&Master::build,*this) ); print(v); } void f3() { /* Does not work; it seems that the object passed to the compiler is a const Master& instead of just a Master&, it is like that the boost::lambda::bind() adds a const where that is not required... I tried to substitute the Master& in the Slave() constructor with a const Master& but it does not work either */ /* set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::lambda::bind(&Master::build,*this) ); print(v); */ } void f4() { /* The same issue applies here... * This has been my original experiment, which * motivated all this trouble... */ /* set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::lambda::bind<Slave*>( boost::lambda::new_ptr<Slave>(),*this) ); print(v); */ } void f5() { /* A work-around that I come up with, * mixing boost::bind && boost::lambda::new_ptr */ set <Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::bind<Slave*>(boost::lambda::new_ptr<Slave>(),*this) ); print(v); } }; int main() { Master m; cout << "F1: " << endl; m.f1(); cout << "F2: " << endl; m.f2(); cout << "F5: " << endl; m.f5(); } -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster(a)telecomitalia.it. Thank you www.telecomitalia.it --------------------------------------------------------------------

3 2

[date_time] What's the proper way to convert local to UTC?
by Scott 08 May '06

08 May '06

Note: Reposting in hopes of getting an answer. c_local_adjustor has the static method "utc_to_local" to easily convert to local time based on the machine TZ setting. So I figured it had a utc_from_local or local_to_utc method as well. Neither compiled, so I looked at the header file c_local_time_adjustor.hpp: //! Adjust to / from utc using the C API Yet there is only that one method in the class. Is the missing ability to convert from local to UTC an oversight or is it implemented somewhere else? What's the correct way to do it? Thanks, Scott

1 0

Re: [Boost-users] [shmem] New bugfix version in Boost Vault and sandbox cvs
by bwood 08 May '06

08 May '06

Ion Gaztañaga wrote: >Jan Stetka(e)k dio: >> Yes I understand that I can't use shmem::map and std::map if they are >> both on the global namespace. I've looked at the implementation of the >> std::map header from the STL implementation that is included in vc++ 7.2 >> and that doesn't forward declare std::list in <map>. This is a design >> issue rather than a bug. Why forward declare shmem::list by including it >> in map.hpp when it isn't used? > > >All classes in Shmem include shmem_fwd.hpp or container_fwd.hpp where >Shmem defines default arguments (for example default Less, or Allocator >template parameter). That's why you get the predeclaration of list >including map. Another alternative would be to declare a *_fwd.hpp for >each class defined in Shmem, but you would get a lot of extra headers, >and I would have a lot of work to maintain. > > >Even if I don't include list predeclaration with map, I'm free to use >any Shmem container in any Shmem class (for example, I can implement a >pooled allocator using a list container), so it's likely that a Shmem >class include will include more Shmem classes (predeclarations, or full >declarations). I don't consider it a design error, but a design choice. >What I see dangerous is pushing two namespaces, std, and shmem to the >same context because they have similar classes. An alternative would be >to rename shmem classes like "vector" to "shmem_vector", .... But >weren't namespaces born to allow that? I think this is their intended purpose, but I don't like using them that way. It gets confusing and brevity isn't attained as you have to qualify things. Namespaces support a "let's just agree to disagree" approach that isn't a resolution, but is the best that can be done at times. Do you think this shmem functionality should be integrated with the std containers? In the meantime, I think shmem_vector is better. Does shmem support multi_index_containers? Or, depending on how shmem fits into the picture, should B.MI take the lead in supporting shmem functionality internally? Y'all have more flexibility in the B.MI case as it isn't part of the standard. Brian www.webEbenezer.net

4 4