From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2002-10-09 02:50:24
----- Original Message -----
From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Tuesday, October 08, 2002 11:10 PM
Subject: Re: [boost] Re: Re: Re: new initialization lib, any interest?
> On Tue, 8 Oct 2002, Thorsten Ottosen wrote:
> VC6.5 cannot accept any class partial specialization. You can specialize
> class templates, or not specialize. But not partially specialize. You
> can have template member functions and classes. Using this you can turn
> some partial class specialization into legal code as far as VC6.5 is
> concerned. Function overloading of the type I mentioned regarding
> map/multimap for set_cont also works. Try to look up "Poor man's partial
> specialization" in google.
would this work
template< typename T >
foo( map<T> );
foo( set<T> );
> > > I mean the user
> > > will have a problem if he does something like (contrived so you know
> > > the values are supposed to be):
> > >
> > > std::map<int, int> prime_to_odd; // the nth odd for the nth prime
> > > set_cont(prime_to_square) += 2, 1, 3, 3, 5, 5, 7, 11, 9, 13, 11;
> > >
> > > There's a value missing, but he'd have to carefully work through the
> > > to find out which value is missing.
> > and a compile time solution would catch this? Enlighten me.
> If you forced the user to add them in pairs somehow, like I do, then the
> user wouldn't get into this problem. I can't really think of concise ways
> to force the user to do this.
no. some ideas which won't work were
set_map( map ) + = "ss" -> 2;
+ = [ "ss" = 2 ];
looking back there really ignorant :-).
> It's better to have 1000 lines of STL unreadable that tells you that
> something is wrong in the program, than for you to think the program is
> ok and release it to the customer. The earlier the error is caught,
> the better. Compile time is the earliest the error can be caught, after
> code review. Runtime is the latest, and could happen at the customer,
> which is not ideal.
but the situation here is initialization. That will always be run and if a
value is missing
while initializing a map, the stuff will trigger an error. This error will
never get beyond first rnu.
> I have another idea. Do away with assignment. Keep just appending
> operations (and possibly subtracting operations). Then overload
> global operator+=, and operator-= for maps and other containers...
> map_t m;
> m += 2, 3, 4, 5;
> m -= 4, 5;
Might be even more elegant. I don't know if its good to overload this
operator. Can't see why it shouldn't be. Nobody else overloaded it, right?
> For initialization purposes the user doesn't need clear(). If the user
> wants to clear the container, he can do so explicitly.
> > > So call your library an "assignment" library. It's not any more
> > > I used initializer() because that was the name of the library.
> > > would work just as well.
> > Perhaps. Initialization has more meanings than the C++ specific.
> But you're in C++. Users are going to expect the C++ meaning.
We don't quite speake the same language on this one :-). If you made a lib
that used syntax like this
vector<int> v = ...
then you would call it the "copy-initilization lib" since it's not proper
When a container is given values for the first time, it's very normal to
call that initialization.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk