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 >
class X
{
foo( map<T> );
foo( set<T> );
};
?
>
> > > I mean the user
> > > will have a problem if he does something like (contrived so you know
what
> > > 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
list
> > > 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
"fraud."
> > > I used initializer() because that was the name of the library.
Assigner
> > > 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
initialization?
When a container is given values for the first time, it's very normal to
call that initialization.
regards
Thorsten