- Boost - lists.preview.boost.org

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

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > Actually the point of my remark is that would we be able to > write meta > > programs in imperative style instead of FP style > compilation would be > > much faster. > > The slowness of metaprogram compilation has almost *nothing* > to do with the FP style of metaprogramming, and almost > everything to do with the accidental nature of the > metaprogram evaluation engine (using template instantiation). And why do we have so many template to instantiate? Exactly my point: because we couldn't change type definition we could only create new one. How many helper templates gets instantiated to remove const types from the type-list? Should be none. So you are right: it has everything to do with nature of metaprogram evaluation engine, which is FP based one. > In fact, you *can* write metaprograms in an imperative > style, given an appropriate framework designed to interpret > them correctly. It'll be much slower than what we use today. You have any grounds for this statement? > > And Spirit framework would benefit from it the most. > > I doubt that. Parsing in particular has little to gain from > the use of mutable data. I meant from compilation time standpoint. Gennadiy.

2 1