Re: [boost] Re: Re: TR2 and C++0x heads up

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-04-24 13:41:16

On Sun, 24 Apr 2005 18:43:31 +0200, Thorsten Ottosen wrote
> | Agree on this too.
> |
> | Should we be considering some of the new collection types: 
> circular_buffer, | mutli_array, multi_index, ptr_containers?
> 
> I asked abuot ptr_containers and the answer was "not yet".

Hmm, not sure what to make of that.  I guess one of the interesting questions
moving forward is 'when being in boost is enough'.  Practically speaking it's
clear that some things in boost will probably never make it into the standard,
but it doesn't matter that much because they are available for all. 
Boost.graph appears to be in that category -- widely used, but probably
doesn't need to be in the standard.  For example, maybe there's no real
advantage in trying to get standardized xml processing capabilities -- it's
too big and there plenty of them out there for free. So the market is already
saturated and adding the stamp of the standard isn't helpful.
 
> | Or are the uses too esoteric for
> | standarization?
> 
> probably. I wouldn't write any proposal before hearing what the 
> committee thinks; In Lillehammer we rejected a policy-based smart 
> pointer and it should never have gotten that far; I mean, David H. 
> spent a lot of time writing the proposal and that time could have 
> been saved.

That's too bad.  I really hope this doesn't mean that David is going to stop
working on the library....
 
> | What about serialization -- it's a big library, but really
> | important.
> 
> people are working on a proposal about reflection for C++0x which 
> would give automatic serialization; so we'd better wait with this.

I doubt this.  What would the format of the serialization take - xml, ascii,
binary?  There is no doubt that reflection could simplify the the
implementation of serialization for many common cases, but a library extension
is clearly needed because the application needs control of the output format
as well as the serialization details on a class by class basise. There are
nasty problems like when I don't want to actually serialize all the data
members of something -- a pure reflection solution can't easily cover these cases.

> | --> number types (unlimited / fixed point)
> 
> unlimited types where also rejected on the grouns it serves too few people
> compared to how hard it is to implement.

What a shame.  Anyone that wants to do any kind of financial numerics is
basically out of luck with C++ due to a lack of these types.  Every scripting
language (and JAVA of course) has these types -- someone must find them
useful.  It's these sort of deficiencies that get C++ rejected as an
application development langauage. And actually I thought Beman had indicated
earlier that there is a proposal for some new numeric types based on IEEE work?

Jeff