Hi Wim, Rene and others,
Here some viewpoint of a bit older person :).
The danger is (and has always been) that when one introduces new
language features, one may clash with older compiler versions
which don't (yet) support the new features.
I grew up with Fortran (even with paper tapes and punch cards)
in the bubble chamber era at CERN and I am still happy that we
decided to use only standard Fortran features as they were outlined
in the ANSI standard which were seen to be supported on all platforms
in the various collaborations at the time when setting up the code.
Lateron of course several language extensions appeared, but most
of them were not really needed, so we decided to prefer the platform
portability above these new sexy language features and stick
with our standard. The result was that we could always run our
programs without any problems.
To my opinion I see now history repeating itself. As far as I can judge from the various mails, the main reason why one would like to allow the new C++ features is the possibility to implement things like the boost libs etc... into ROOT. Well, I think it is generally known that the boost code started off from using non-standard C++ features and now some of the "boost people" try to sell these new features to the C++ ISO committee. My opinion would be to give more weight to the platform portability of ROOT than to introducing this new (e.g. boost) stuff. In case people would like to have additional packages available, I would say, let them then take care of updating their compiler and create the corresponding libs themselves. If one sticks with the ROOT code to the current C++ standard, it will also compile on newer compiler versions, whereas the reverse will in general not be the case and will introduce enormous problems for large collaborations in which one wants to have a stable analysis environment.
Just my 5 cents,
Nick.
> Hello,
>
> > I understand some of your points. Myself, I am not a fan
> > of the "modern" cast syntax because, as you say, it makes
> > the code opaque to most readers and the pretext that you have
> > more type safety is just an illusion.
>
> If D derives from B, and Func() returns a B*, then:
>
> D* d = (D*)Func();
>
> will translate into a reinterpret_cast (i.e. no pointer offsets) if both
> B and D are forward declared, but in a static_cast if D is defined. The
> former case will lead to memory corruption if B has data members.
>
> Instead,
>
> D* d = static_cast< D* >( Func() );
>
> will result in an error if D is only known by forward declaration. I.e.,
> no chance of memory corruption. Seen it happen in code I had to maintain.
>
> > We have started using templates internally where we believe that we have
> > more to gain than to loose.
>
> Even Java has turned around with generics in Java 1.5.
>
> > We are not in 1992! [..] Young programers could not understand!
>
> Well, I was in high school in 1992. :) The point I'd like to make, is that
> it is very hard to know what can, and what can not be used if you picked up
> C++ later than in, say, 1992. People who've been dealing with C++ since that
> time know what is generally supported by most versions of compilers. People
> who joined later learn the standard, pick up the latest of the greatest, and
> simply do not have the working knowledge of which parts to shy away from to
> get maximum portability across outmoded compilers they have no acccess to (it
> is not as if MS is still selling VC++6, or that installing and using gcc2.7
> on a modern Linux distro is hassle free).
>
> > Anyhow, we welcome comments like yours. It would be good if
> > more people could express their opinion.
>
> Well, I think static type safety is overvalued. However, the problem with
> C++ is that its dynamic type safety is epsilon. New-style casts and templates
> do help static type safety, and since that is all the type safety that C++
> has to offer, might as well use it.
>
> Best regards,
> Wim
> --
> Wim.Lavrijsen_at_cern.ch -- WLavrijsen_at_lbl.gov -- www.lavrijsen.net
>
> "Stop making excuses for your software." --first step towards quality
>
Received on Fri May 13 2005 - 09:52:10 MEST
This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:07 MET