Re:[boost] Re: serialization and cwpro status

David Abrahams wrote: "Robert Ramey" <ramey@rrsd.com> 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 - an incredibly subtle side-effect. Worse, the meaning of a template now can vary quite a bit depending upon the argument used to instantiate it. 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. Sorry, I know we're going off topic, but I couldn't let the above pass without comment.
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% 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. Robert Ramey

"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> 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

In article <u1xidpjdg.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> wrote:
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.
CW8 is the first useful CW for Mac OS X, so almost everyone upgraded to CW8 very quickly; that makes CW8 a reasonable cutoff. meeroh
participants (3)
-
David Abrahams
-
Miro Jurisic
-
Robert Ramey