Rene Brun wrote:
> Hi Christian,
>
> 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.
The next few paragraphs are a diversion, but I'll go there anyway :-)
In my understanding, the modern cast syntax has less to do with type safety than with syntactically differentiating the different reasons for casting (removal of const versus dynamic upcasting, for instance), actually _clarifying_ of programmer intent ("Did he really mean to cast away const here, or only to declare this narrowing conversion as safe?"), and making the presence of casts more obvious (the syntax is intentionally "ugly" because casting itself is almost always an indication of a design error).
See for instance Stroustrup's "The C++ Programming Language, 3rd Edition", Section 6.2.7, where he has this to say:
"Explicit conversion ... is occasionally essential. However, traditionally it is seriously overused and a major source of errors. .... In C++, explicit type conversion is unnecessary in most cases when C needs it. .... In this book, explicit type conversion is used in realistic situations in [5 sections] only. ... [The] C-style cast is far more dangerous than the named conversion operators because the notation is harder to spot in a large program and the kind of conversion intended by the programmer is not explicit."
Additionally, the C-style cast does not provide an extensible framework for future casting enhancements. New style casts do precisely that. For instance, the boost libraries provide many types of checked casts/conversions within the new framework: any_cast<>, numeric_cast<>, polymorphic_cast<>, lexical_cast<>, etc.
> I also agree with you that exposing a templated interface
> to users is not good , or at least premature.
Here, I strongly disagree. The C++ Standard Library is almost entirely a templated interface library and has been around for a decade now ... the recently approved TR1 is even more template heavy, and most of its components are already in wide use (shared_ptr<>, bind, random, etc.). Any competent C++ programmer is well versed in the use of templates, and anyone who isn't is missing out on most of the power of the current libraries; they're probably reinventing the wheel on a daily basis in ways that are both error prone and suboptimally efficient. Many of the libraries with the most impact on the application programming field in the last few years have been heavily template based, with boost and Loki in particular coming to mind immediately. High performance C++ computing leans heavily on Expression Templates (MTL, POOMA, blitz, etc).
Templated interfaces are not the wave of the future ... they are the present in C++, and they make life for the application programmer much easier. Failure to actively embrace them in ROOT is, in my opinion, a huge mistake.
> However, I don't think that we can go away from the general trend
> with C++. We have started using templates internally where we
> believe that we have more to gain than to loose. We are not in
> 1992! compilers have evolved to support the current C++ standard.
> It would be a mistake to restrict ROOT to a subset of C++ in the
> future. Young programers could not understand!
Bravo! The only real remaining problem with compilers vis a vis templates are that they still generate horribly opaque (ie, nearly unparseable) error messages.
> In this move, it is not our intention to destroy what we have,
> even if sometime we have to make compromises with different
> cultures.
> I believe that the recent merge of SEAL with ROOT was essential.
> Users will see the benefits in the coming months.
> I am on the floor since long enough to be extremely cautious
> on all facets of software development. I was very pleased to
> see that our recent workshop between CINT and Reflex experts
> was very positive, a first step to improved products in the
> medium term.
>
> Anyhow, we welcome comments like yours. It would be good if
> more people could express their opinion.
>
The more modern C++ techniques and "best practices" that ROOT incorporates, the better. It can only lead to an easier to use, more robust, and more high performance system. I would also personally prefer to see ROOT more completely integrated with Standard Library and TR1 facilities, both in its interface and internals. Replacement of the random number generators with a TR1 compatible framework, for instance. Replacing the whole awful TH1 hierarchy with a redesigned, slimmer, templated TH1.
But then, I'm not the one doing the work, so I don't get to tell people what to do :-)
I don't mean any of this as a criticism of the people who have done such a great job with ROOT ... it's fantastically valuable and I use it regularly. But to remain relevant in the future, ROOT has to keep in touch with the best practices of the 2005 C++ community, not the 1995 C++ community....
> Rene Brun
>
Received on Thu May 12 2005 - 16:50:54 MEST
This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:07 MET