[boost] Re: serialization and cwpro status

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