CB>LR>Will C++ become the Cobol of yesteryear?
CB>Hopefully.  Or better yet, like Forth, Lisp, etc.
I just felt like clarifying that statement.
I don't have anything against the concepts C++ was conceived under, but
I don't like the direction it's taking, and some of the choices that
have been made.
1) It's becoming a much bigger, more bloated language.  That makes the
compiler bigger and more bug prone.
2) the C++ committee is doing a lot of inventing without ever considering
how those new ideas are going to work together.  They have taken a
reasonably clean idea and have piled so much stuff on it that it's a
whole different language now.
3) C++ was original designed and promoted as a solution to some problems
in programming, but now they are trying to make it the THE solution to
ALL programming problems.  Its become a lead plated butterfly the size
of an elephant.
4) They deliberately decided to confuse the programmer by requiring the
compiler to guess anytime there is some conflict in data types,
overloading, etc.  This was done just to keep the programmer from having
to add the occasional obvious typecast or other specifier when there
would otherwise be some non-obvious resolution.  It would have been much
cleaner to just have the compiler generate an occasional warning and
then the programmer could add some clarifying specifier.  But instead,
C++ is required to perform guessing games, and it probably isn't going
to guess the way you do, which is why there are so many of the "Betcha
can't tell what this does" code snippets.
(C++ hasn't gotten quite as bad as PL/I, where you could have:
  IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF
and a statement such as IF 1 THEN ... _fails_ because the 1 is treated
is a one digit real fixed constant, and then to make a boolean test, it
converts it to the string 0001, and then tests the leading digit, the 0,
causing the test to be false.
But C++ is getting there.)
--- QScan/PCB v1.19b / 01-0162
---------------