From: David Abrahams (dave_at_[hidden])
Date: 2004-08-11 14:25:31
"Robert Ramey" <ramey_at_[hidden]> writes:
> David Abrahams wrote:
>
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>>> Now that I do, I'm strongly convinced that
>>> it's a really bad idea.
>
>>Give it a chance to sink in.
>
> Looks like I don't have much choice.
>
>> It's a good idea even if you ignore
>> export because it reduces the chance that a template's meaning will
>> change based on definitions that follow it, allows syntax checking
>> before instantiation, and adds rigor.
>
> That's the problem with it in my view. Before, I could keep things in my
> head by extending the "macro" concept to include types. Now I can't. Now
> the meaning of something depends upon the order it is included in the
> program
It already did depend on order:
// a.hpp
inline int f(int x) { return x + 1; }
// b.hpp
inline long g(long x) { return f(x); }
// c.hpp
inline long f(long x) { return x; }
// d.cpp
#include "a.hpp"
#include "b.hpp"
#include "c.hpp"
int main()
{
return g(0);
}
There are lots more examples.
> - an incredibly subtle side-effect.
I agree, but order dependency is already there. Let's get rid of the
inclusion model if you want to kill it.
FWIW I think ADL (which is *not* order dependent in templates) is a
much worse source of subtlety. See
http://www.boost-consulting.com/writing/qn.html for more.
> Worse, the meaning of a template now can vary quite a bit depending
> upon the argument used to instantiate it.
But less-so with 2-phase lookup and proper use of typename. At least
a type can't become an object and utterly change the meaning of the
template.
> The whole thing reminds me of trying to write a memo with
> Microsoft word. It constantly "helps you out" without telling you so you
> can't really see what's going on without keeping the whole global
> environment in your head. So it diminishes transparency, verifiability, and
> opportunity to enforce rigor in coding requires increased dependence on
> testing to gain confidence on program correctness.
I'd like to see an example where that happens. In my experience,
2-phase lookup does the opposite.
> Sorry, I know we're going off topic, but I couldn't let the above
> pass without comment.
Likewise. Maybe you should take up the claim that 2-phase lookup
should be removed on the comp.std.c++ newsgroup?
>>> CW < 8
>>>
>>> I believe that these versions will pass 100 %
>
>>I wouldn't count on it. CW 7.x couldn't handle the "sizeof() trick",
>>so *lots* of basic TMP things (like is_convertible) fail there. Of
>>course, maybe you're sure that none of these things are used...?
>
> Good thing you didn't tell me that before - its now passing 100%
Are you really testing CW 7.x?
> It feels like I've used everything in mpl (of course I didn't - it
> just feels like I did). I use is_convertible in many places as well
> as just about all the type_traits.
>
> On the other hand, maybe its just that I don't have enough tests to
> make it fail.
If you really count on the result of is_convertible being true when
it should be, then no, you don't have enough tests.
FWIW, I dropped CW 7.x support in Boost.Python and the iterators
library when CW 9 came out and have not received a single complaint.
I think VC6 is arguably the only 2-version-old compiler that might
warrant continued support.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com