Boost logo

Boost :

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 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at