- Boost - lists.boost.org

Indexed Set: design/naming thoughts
by Darren Cook 03 Mar '04

03 Mar '04

Hi, Some thoughts on design/naming after reading docs of indexed_set (version 9). I've not tried compiling anything yet. 1. The naming here seems redundant: employee_set::nth_index_type<1>::type employee_set::index_type<name>::type Can't the "::type" bit be dropped"? Or the _type, e.g. employee_set::nth_index<1>::type employee_set::index<name>::type 2. Do tags have to be structs? struct name{}; ... non_unique<tag<name>,member<employee,std::string,&employee::name> ... employee_set::index_type<name>::type While it looks okay in tutorial examples, I can see not wanting that in the main namespace in a real program. But then having to use a namespace each time I use the tag will be make it a bit ugly: non_unique<tag<tags::name>,member<employee,std::string,&employee::name> ... employee_set::index_type<tags::name>::type If it was a string instead is it less efficient (or maybe it does not compile)? non_unique<tag<"name">,member<employee,std::string,&employee::name> ... employee_set::index_type<"name">::type 3. I think the compose_key example will be needed enough that it should be part of the main library. 4. I think some macros would be useful to enhance readability (rather than just to handle compiler incompatibilities as currently). I'll see what I come up with as I try to use the library. Darren

2 3

Re: [boost] serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Jeff Garland wrote >Just so you know, the compile blows up with the CVS as of about a day ago. >I'm sure not your fault, but so you know... Well, as you can imagine, I'm happy to know that. At times during this development I used the development tree and other times I used the latest release. Basically I use the latest release rather until I need something that is only in the development tree. This happened with new iterators and mpl. When the release candidated 1.31 came out I switched back to that. My motivation for preferring the latest release is that I would like to upload something that I can expect to work and other people can test with a minimum amount of hassle. I'm mean I have enough problems with my own flakey ( er.. experimental) code with out adding in everyone else's. So as things stand now I'm inclined to work to the 1.31.0 . Having said that, it seems to me the development tree is considered "experimental" where as I would prefer that it be considered "Candidate for Release" That is, I think code is uploaded without out being fully tested in one's local environment. I think this creates a chain reaction at release time. Its not that I think anyone is really wrong, just that I think things would be better if developer's were a little more conservative. (But then, I'm getting old, I think that about everybody) In this case presumable something in new iterators has changed and caught me with my pants down (for the second time !). Oh well. I'll worry about it if we ever get to incorporating the library in a release. Robert Ramey

3 2

serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Fellow boosters, I have just uploaded serialization17.zip to the boost files section at Yahoo.com. A copy can also be found at www.rrsd.com This is the latest version of my serialization library. It has been built and tested in debug and release mode with VC++ 6.0, VC++ 7.0, VC++ 7.1, GCC 3.2, and GCC 3.3. It requires boost 1.31 to function. It has no known bugs. Compared to previous versions, documentation, examples, tests and portability have all been enhanced. I would like this library to be placed in the review queue. Robert Ramey

4 6

Re: [boost] Re: [Threads] Simple active object wrapper, take 2
by Mark Blewett 03 Mar '04

03 Mar '04

At 01:02 28/02/2004, you wrote: >scott <scottw <at> qbik.com> writes: > > ps: > > the sample code from mark blewett looks very promising? > > > >Yes. Although from my point of view, it has the same drawback with switching >on messages that you have. I wonder if the queue of messages in the servant >class could be a queue of fully-bound function calls, I'm halfway there, in that the queue holds callbacks, eg in Servant::dispatch the "do something with m" simply executes the callback. To give a usage example class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler) {} void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.post_call(new CallbackVAA<MyServant,int,int>(&my_servant, &MyServant::do_fn, 1, 2)); scheduler.stop(); return 0; } will result in the output "1 2" via one of the schedulers worker threads >generated by proxy >objects which describe interfaces? (Yes, I am quite enamoured of that >idea :)) Interesting idea... assuming I'm understanding correctly.. in that the callback is created by an object in the servant class, the above becomes; class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler), fn(this, &MyServant::do_fn) {} MethodProxy<MyServant, int, int> fn; private: void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.fn(1, 2); // certainly a lot easier to understand than previous example! scheduler.stop(); return 0; } Regards Mark --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.573 / Virus Database: 363 - Release Date: 28/01/2004

3 3

RE: [boost] Container Traits
by Powell, Gary 03 Mar '04

03 Mar '04

This library is an interesting concept but when I looked in it, it didn't have what I would have thought were "container traits" the way I think of "iterator traits". From the VTL library I wanted to be able to query the container to see if it was an associative container, or a sequence container or a random access container, i.e. had an operator[]() etc. Can one of the authors explain the purpose of this library? Yours, -Gary-

4 3

potential problem with indirect_iterator (GCC 3.3.2)
by Shannon Stewman 03 Mar '04

03 Mar '04

I sent this a couple days ago, but I think it became lost in the ether when the list moved machines.... apologies if it didn't. I noticed a small potential problem with indirect_iterator. I've been using it with raw pointers, and the default constructor appears broken in this case (gcc-3.3.2): #include <boost/iterator/indirect_iterator.hpp> #include <iostream> struct MyType {}; typedef MyType* MyTypeList; typedef boost::indirect_iterator< MyTypeList, MyType > Iter; int main( int argc, char** argv ) { std::cout << "Iter() == Iter() ? " << ( Iter() == Iter() ) << std::endl << "Iter(NULL) == Iter(NULL) ? " << ( Iter(NULL) == Iter(NULL) ) << std::endl; } The output is: Iter() == Iter() ? 0 Iter(NULL) == Iter(NULL) ? 1 Is this an actual bug, or am I misusing the code? If I'm misusing the code, is there some reason for this? It's inconvenient that the default constructor doesn't initialize pointers to some consistent value; the problem goes away when I change the indirect_iterator default constructor: 94c94,96 < indirect_iterator() {} --- > indirect_iterator() > : super_t( Iterator() ) > {} Best, -- Shannon Stewman | Let us walk through the waning night, Caught in a whirlpool, | As dawn-rays tickle our toes, the dew soothes A quartering act: | Our blistered soles, and damp bones stir Solitude or society? | As crimson cracks under the blue-grey sky.

3 5

RE: [boost] Assignment Library
by Powell, Gary 02 Mar '04

02 Mar '04

After a quick look at the Assignment library, it would appear that this library would benefit from a "container traits" library that it could query for things like whether to use "insert" or "push" to call for make_insertion() rather than specify each std::stl container. It just doesn't seem to be very extensible. Rather wouldn't it be better if a user could define the traits class for your container and then the assignment would pick the right one? Yours, -Gary-

2 1

RE: [boost] [Threads] Simple active object wrapper, take 2
by scott 02 Mar '04

02 Mar '04

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt nice! only one item of feedback really. think that i follow your machinery and can envisage the "model of execution" - its pretty slick. its also somewhat different to the pattern :-| so i would wonder at the use of "active object"? is your model of execution the one that everyone is expecting of the previously, unimplemented class? this does seem to be a class/framework for (very convenient) arrangement of concurrent method execution. which piece of the ActiveObject pattern does this map to? other than the "claiming of the name", it looks like its got legs! ps: i s'pose anything declared in the private scope of "object" is thread safe? > > // test_active_object.cpp > -------------------------------------------------- > > > #include "active_object.hpp" > > using std::cin; > using std::endl; > <big snip>

3 20

minor min/max regression
by John Maddock 02 Mar '04

02 Mar '04

The recent min max changes have caused breakages with vc7.1 + STLPort, the problem is that this configuration defines BOOST_NO_STDC_NAMESPACE (because STLPort doesn't quite manage to import everything into it's "fake" std namespace), which causes the following code: template< typename T > inline T const & std_max( T const & a, T const & b ) { #if defined(__COMO__) || defined(BOOST_INTEL) || defined(BOOST_NO_STD_MIN_MAX) using std::max; #elif defined(BOOST_NO_STDC_NAMESPACE) using ::max; // <- error here #else using std::max; #endif return max BOOST_PREVENT_MACRO_SUBSTITUTION ( a, b ); } to fail, because min and max *are* in namespace std. Now the thing is, BOOST_NO_STDC_NAMESPACE was only really designed to check for C lib functions, it was assumed that std lib functions like min and max are always in namespace std, are there any situations where that is not the case? If not we can just ditch the #elif defined(BOOST_NO_STDC_NAMESPACE) clause altogether. John.

5 5

Question regarding usage of scoped_ptr and PIMPL
by Robert Ramey 02 Mar '04

02 Mar '04

The follow little example illustrates an issue I have with scoped_ptr. I would like to use this to automatically manage destruction of a pointer to and undefined class. It seems that scope_ptr is instantiating its destructor "too early" and complaining about incomplete type for b; In my view, this should not occur as ~a() isn't defined yet. The following example fails on vc 7.1 and gcc 3.2 Note that shared_ptr works as one would hope in this context. Is there anyway to adjust scoped_ptr to work here? Robert Ramey // in my opinion this should not fail to compile under any circumstances. // however it seems that that the inline destructor of scoped_ptr // requires a complete type even though the destructor is not defined. // note: changing scoped_ptr to shared_ptr works as one would hope // note:: changing to auto_ptr still fails in with the same problem #include <boost/scoped_ptr.hpp> struct b; struct a { boost::scoped_ptr<b> pimpl; ~a(); }; int main() { a a_instance; }

3 2