From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-10-08 16:10:48
On Tue, 8 Oct 2002, Thorsten Ottosen wrote:
> ----- Original Message -----
> From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
> > It would also be worthwhile for you to make your interface compile with
> > Visual C++ 6 (and probably other compilers). For example, the policies
> > classes are partially specialized, and VC 6.5 and others don't accept
> > partially specialized classes. In your case, I think you could use
> > function template overloading to provide a solution to this. (Also take
> > note of the point list example later on).
> year, that's a real pain. People with experience in this area are welcome
> with their
> support. I fear that this could really produce some irritating compiler
> error messages
> when something goes wrong. Anyway, a little example would be appreciated...
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.
> > > [thor]
> > > at first speed wasn't an issue. but my test (see other mail) that there
> > > no overhead in my approach.
> > > I don't think it is unthinkable that a loop could contain
> > >
> > > set_cont( v ) += x,y,z;
> > I either think that they'd be better as a list of explicit push_back()s,
> > or that a std::copy(block.begin(), block.end(), std::back_inserter(v));
> > would be better.
Because either x,y,z have something in common in which case it's more
readable to call them by name and then add them as a group, or they don't,
in which case it's most readable to add them one by one. I can't really
think of examples where you'd need more than that inside a loop.
> > 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.
> > > to a compile time error, then maybe the compile time list is better.
> > > However,
> > > its more complicated usage would be much worse than waiting for a
> > > initilization error.
> > Compile time errors are always preferable. But very simply, I can't
> > compile your code because it uses template specialization that is not
> > supported by my compiler.
> That depends. If the error msg is 1000 lines of STL unreadable, a runtime
> might be considered ok. It is a tradeof.
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.
> > How about assigner(), a function that returns an assigner object
> > to its parameter?
> good candidate.
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...
m += 2, 3, 4, 5;
m -= 4, 5;
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.
> > > [thor]
> > > I don't agree. With your syntax above it's not clear what is the key and
> > > what is data. Production code
> > > would be
> > >
> > > set_map(addresses) = address("Washington St.", 30), "Johnson";
> > It's not clear with your syntax, because the user gives a comma delimited
> > list, that delimits both the keys and the data by commas. Instead of
> > using this example, about about a list of pairs.
> > typedef std::pair<int, int> point;
> > std::list<point> point_list;
> > set_cont(point_list) += ....
> > Would this work?
> Unfortunately, it will work both as
> set_cont( point_list ) += 3,3,4,5,6,67;
[corrected in later mail to say it won't work]
You could solve this by identifying the fact that a pair is being used for
value_type, and then expecting only value_type::first_type as the rhs of
the operator+=. Then return this as a reader object that looks for
operator, for the second_type of the pair.
> > I really don't think my format is that complex to understand (especially
> > with proper documentation), and neither that expensive for use. Your
> > format is nice for its use of the comma operator. I'm not against it, but
> > I asked why not also, and then realized it wasn't that hard to implement
> > (at least what I did yesterday wasn't that hard).
> and I appreciate your advices. If I can see some small examples of the
> template overloading you talked about, I might do something in the weekend
> so the vc6 people can enjoy it.
I gave you the general ideas earlier. How about if you add the
necessary typename keywords to make Comeau (and the other compilers
you have access to) happy with my iterator (the most recent version that I
posted), and I will try to do what's necessary to make yours compile with
VC6.5? Contact me in private email if you wish to do this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk