Re: Future of C++
On Aug 9, 8:23 pm, Pavel <dot_com_yahoo@paultolk_reverse.yourself>
James Kanze wrote:
On Aug 8, 10:32 am, kwikius <a...@servocomm.freeserve.co.uk> wrote:
int i = 0;
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.
I am afraid I was not clear enough. No macros was assumed to
be involved in the above (see "*some* certainty" cited above).
The actual point is that in C++ you cannot say whether
void f(int i);
void f(int &i);
is called, without looking elsewhere and getting distracted by
But that's a false problem. Which one is called depends on the
semantics of the function, and you have to know that in order to
understand the code. And even if you know which of the above
actually corresponds, you still don't know the semantics.
(on some platforms, the fastest way for me to say is to vi the
output of the preprocessor -- that's from where the reference
to the p).
"Expressive" to me means something close to the opposite to
having to go to the reference (header file, browser window
etc) to understand what the "expressive expression" really
does. You will probably agree that the syntactic meaning of
something as simple as " int i = 0; f(i);" is supposed to
become obvious without much effort -- if it is not, getting to
a comfortable level of understanding of a syntactic meaning of
a little bit less trivial piece of code is supposed to take
infinite amount of time by definition -- isn't it?
Yes and no. What should be obvious without any effort is the
effect of the statement. Which depends on the semantics of the
function, and not just minor syntactic details. In well written
code, the name of the function will give enough information, and
in poorly written code, you're stuck. But that's true in just
about any language; I don't see where C++ causes additional
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
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).
Apparently your mileage differs from mine. Java became quite
agile (somewhere after 2000-2001 when major bugs were
eliminated from implementations) but in my experience C++
projects blew by far more deadlines than FORTRAN, Assembler, C
or Java (after the latter matured with the adoption of 1.3.1
and 1.4) -- and some of the firms I worked for were really
well-run hardware/software shops.
Of course I mean the deadlines for commercial products, not
some semi-working prototypes.
That's interesting, because it is incredibly difficult to get
really robust Java. The language actually bans many of the
techniques which would help you here.
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.
Yes, I have heard above this free cheese before -- but have
never eaten one :-).
In other words, you've never actually worked in a place which
had a good software development process in place.
Don't blame the language when the problem is the environment.
James Kanze (GABI Software) email:firstname.lastname@example.org
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