Re: Future of C++
On Aug 8, 10:32 am, kwikius <a...@servocomm.freeserve.co.uk> wrote:
Pavel wrote:
<...>
int i = 0;
f(i);
myprint(i);
If it is written in Java (or C, for that matter), I can tell
with some certainty that myprint() receives 0 as an
argument. But to tell something about it in C++ I have to
know whether f() takes a reference or a value and, to make
things even more fun, I never know which of possible
overloaded f's is called, -- not until I pre-process the
code and line up all possible fs.
That's not preprocessing. Preprocessing is something else
entirely (which C++ inherits from C). And preprocessing is a
problem: if myprint (or f, for that matter) is a macro, who
knows what the above means.
One of the evolutions of C++ with respect to C is to reduce the
need for macros---good C++ makes very, very limited use of
macros. So you should have less problems with the above in C++
than in C.
Deducing automatically which function to call based on its
arguments is certainly an important feature in making C++ what
I would call "expressive".
Like everything which increases expressivity, it can be abused.
I'm tempted to say that if myprint is overloaded, and it matters
which instance of myprint is called, overloading has been
abused.
Of course, Pavel is right about one thing: the last line in the
above could be the declaration of a variable (which would be a
duplicate declaration, but if i were in some different scope, it
would be a legal declaration). IMHO, this goes beyond
"expressivity", and is frankly a defect. But it's one we
inherited from C, and the same ambiguity exists in C. (All
that's needed, in both cases, is that myprint is defined by a
typedef somewhere. And that's one ambiguity that isn't present
in Java.)
Its obviously not available in C.
(I cant remember if there is an overloading scheme available
in Java, but even if it is it would be of limited use because
Java is OOP and function overloading is actually about
expressions which are not part of the OOP vocabulary.
Never the less, Java's overloading is almost identical to that
of C++. If it's less of an issue, it's only because Java
doesn't support as many implicit conversions (another thing C++
has mainly because of C compatibility).
Note that Fortress Suns next generation language incorporates
overloading based on various constructs as well as many other
familiar general constructs that have been available in C++
for a long time)
I would prefer if the algorithm regarding which function is
actually called was more rigorously and concisely expressed
itself. In general in C++ you kind of hope that the expected
version of a function will be used, and thats arguably far
from ideal (You can't blame C++ for its complex and loose
approach to overloading. C++ is essentially quite a nice
expressive language mixed up with C. The fact that its mixed
with C is AFAIK a major reason for its success, but also the
source of many of its problems (I think this is said somewhere
by Bjarne Stroustrup)
I don't know if Stroustrup said it, but it's certainly true.
The biggest single problem in C++ is the declaration syntax,
which is inherited from C. To many implicit conversions
(especially lossy conversions) would be another inherited
problem. (And it's too many implicit conversions which makes
overload resolution so complicated.)
BTW. Note that in the example you gave, because the argument
is an int IOW an inbuilt type there are only a few functions
that can be called (unless you have brought in other
namespaces!).
Or you have classes which have non-explicit constructors which
take a single integral type.
If the argument is a class (a user defined type or UDT) then
the list grows large and if the class involves templates the
list grows even larger.
<...>
because "smart guys" like inserting templates
and meta-programming wherever they don't need them or at
least they will include a couple of "cool" headers -- so a
change/compile/debug iteration in C is much shorter than in
C++).
On the other hand, because of C++'s better type checking and
encapsulation, you normally need a lot less change/compile/debug
cycles than you would with C. Globally, development times in a
well run project are significantly less in C++ than in C (or in
Java, for that matter).
Not sure how to break this vicious cycle -- it seems the
more powerful a language is the more it gets abused and the
more it hurts the productivity.
That's why you need a development process, and to pay attention
to software engineering issues. Good code review can do wonders
in this regard. Greater expressivity does allow more ways of
screwing things up, but it also allows more effective solutions.
The trick is to manage things so you get the benefits without
the costs.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34