Re: RE : VC++6.0 and 7.0 are not supported anymore from ROOT4-04-2 or newer

Dear Rooters

It seems that I did start quite some discussion. People who know me, know that I am never afraid to express my personal opinions
(even if they might be wrong).

Although I cannot answer all replies, I will try to comment on some of them. But first, here are some more personal opinions:

Bjarne Stroustrup:
Today, BS mentions on his homepage many libraries and applications written in C++, including ROOT, see:
http://www.research.att.com/~bs/applications.html However, when I visited his homepage a couple of years ago he did only mention TWO frameworks as examples of what could be achieved with C++, namely ROOT (w/o any template use) and POOMA (a collection of templated C++ classes)!
Interestingly, with respect to POOMA, BS adds a note of caution: "Note that the POOMA project maintains a page listing compilers that are standards conforming enough for their advanced uses.", see: http://www.research.att.com/~bs/C++.html My interpretation is, that even BS is aware that there are still problems with the use of templates.

Fortran vs C++:
Like most physicists, I started programming with Fortran (in my case this was FORTRAN II on an IBM 1130 mainframe with 16kb core memory). Most of my progams were written in FORTRAN IV which later became the FORTRAN 66 standard, which was replaced by FORTRAN 77. Probably most of the available Fortran programs are written in FORTRAN 77, and can be compiled on most Fortran compilers. I do not know whether there exist many Fortran programs which use the NEW features implemented in the FORTRAN 90 or FORTRAN 99 standards. (As far as I can see even the cernlib libraries can be built with g77.)
Today, I consider Fortran to be dead: Even Cern is moving from Fortran to C++. Maybe, continuously adding new features to ANSI C++ may result in C++ sharing the fate of Fortran. P.S.: I agree with the response of Nick van Eijndhoven to give more weight to the platform portability.

C++ vc Objective-C:
Since C++ was designed primarily as "a better C", and not necessarily as a full-featured object-oriented language, it lacks some of the possibilities for object-oriented design that dynamic typing and dynamic binding bring to Objective-C. Late-binding and garbage-collection are some features, which Java shares with Obj-C. Although I have never used Obj-C, I have heard from NeXT and MacOS X programmers that it is much easier to write programs in Obj-C than in C++.

C++ as better C:
Although many C++ programmers are eager to use recent C++ additions, it seems that they still do not follow the most simple rules, described e.g. in "Taligent´s Guide to Designing Programs":

p.49: "Though the C preprocessor is one of the most powerful features of C and C++, avoid using it." In contrast, many people still do:
#define kGreen 1 instead of: const int kGreen = 1; #define SQUARE(x) ((x)*(x)) instead of using an inline function!

p.41-42: "Type casting, though dangerous and uncontrolled, is occasionally necessary in C and C++. ... Finally, although casts from a base class pointer to a derived class pointer are conversions
(known as type narrowing), avoid them. ... Templates in C++ ...
obviate the need for most such casts."
In my program I must often cast to a derived class, since I am not willing to add methods to my base classes where they are not understandable.
To me this seems to be a design flaw in C++, and I am not willing to use templates because of an inherent design flaw.

Namespaces:
Eddy made a really convincing statement, that using namespace TMath allows to use "Sqrt()" instead of "TMath::Sqrt()", which makes the code more readable. Sorrowly, many programers do it the other way around, they now write e.g. "std::cout" instead of simply "cout".

Subset of C++:
Maybe, I should restate this as follows: It would be great if the ROOT source code could be compiled on most modern platforms
(which is still the case), and more importantly, if all ROOT
classes could be used in CINT.
In the past I have often mentioned that I consider ROOT/CINT an ingenious combination. The possibility to write macros, test my code interactively, and compile it on the fly, has changed the way I am developing programs. Sorrowly, since some time I am no longer able to test my GUI code using CINT, I have to compile it with ACLiC in order to run it as macro. Furthermore, I am not able to use some classes on the Mac, such as the TMLP classes.

Best regards
Christian Received on Sat May 14 2005 - 01:12:06 MEST