Re: Future of C++
On Aug 15, 7:55 am, Pavel <dot_com_yahoo@paultolk_reverse.yourself>
wrote:
James Kanze wrote:
On Aug 12, 8:06 am, Pavel <dot_com_yahoo@paultolk_reverse.yourself>
wrote:
[...]
Second, with regards to the function "increment":
-- Even in the case of Percentage, the way C++ spells it is
Percentage::operator++()
Does it? Did you solve my puzzle
#include <iostream>
#include <string>
using namespace std;
int main(void) {
string a = "35" + 1;
cout << a << endl;
return 0;
}
?
What does that have to do with the increment() function? You
seem to be mixing subthreads.
Perl would give one of intuitively expected answers -- see
perl -e 'print "35" + 1'
and Java would give the second one (you can certainly come up
with the code itself).
The "intuitively expected" answer will obviously depend on the
overall philosophy of the language: for untyped languages, such
as Perl, AWK, etc., the intuitively expected response is "36";
for typed languages, such as C++ and Java, the only intuitively
expected response is a compiler error. Which neither Java nor
C++ get right (for different reasons).
Bad enough (Python reports the error in clear language
(TypeError: cannot concatenate 'str' and 'int' objects) -- one
of the reasons it is my favorite from syntactic viewpoint),
but none of these goes as far as C++. Now tell me honestly C++
is most expressive here -- and I only used overloads The
Standard Library offers.
I'm afraid that I don't see any real difference between Java and
C++ here. Not that it's really relevant; neither language is
perfect, and no reasonable person would pretend the contrary.
Both have their flaws. The basic question concerns the
totality, which depends on the application domain, but
doubtlessly favors C++ over Java most of the time.
Of course your "C++ way" goes much further:
To inter-operate between your Percentage class and other
"glorified" numbers (say, to multiply percentage to some
quantity or whatever) you will have to overload helluva lot of
operators and/or allow same amount of conversions.
And? Designing a good interface does require a bit of typing.
And I'm not sure that you'd need that many overloads for
percentage. Not every operation makes sense on a percentage.
:-) (but that's really neither here
nor there---there are definitely functions which modify
state, for which there is no pre-defined operator).
-- Functions which modify state are normally members. You
don't write increment( object ), but rather
object.increment(). At least in principle: there are times
when, for various reasons, it's not possible, but it does
mean that the number of times the question comes up is
greatly reduced.
No, you are confusing the number of times you would *use* the
non-const reference as a parameter and the number of times I
had to review the code using such references written by
someone (who was not you).
No. You're confusing your personal experience in poorly run
shops (where any language would fail) with absolute truths.
Until there is no such sanction as disbarment in C++ as opposed to
legalese (even though the former might not be much simpler than the
latter), the easiness with which such mines are planted keeps and will
keep a lot of practitioners and managers away of C++. Not that I would
support such kind of regulation..
-- A function named "increment" increments, i.e. it modifies
state. Otherwise, it would have a different name, e.g.
"incrementedValue", or borrowing from Pascal "successor"
(which is better depends on the semantics of the object).
If for some reason it is not a member, it takes a non-const
reference as parameter. Period. You don't have to look
further.
Then why to look at all? Just assume (as you just did) and put
your signature?
Exactly. Why look further.
-- A function which modifies state is not used in more
complicated expressions: if it returns a value, it is the
old value, to allow client code to restore it. In the case
of increment, this is silly, of course, because if you know
the new value, you know the old. But in the case of things
like std::ios_base::setf(), etc., it's very useful. In the
case of member functions of objects with identity, it's
sometimes useful to return *this, to allow chaining, but
that's about the only case I can conceive of where you'd
return the "new" value.
And so you would just assume the person who wrote the code you
are reviewing conceived same way as you and write your name on
the dotted line?
I would assume that any code which passed code review was
conform to the conventions in use in the company.
For the rest, expressivity is there for you to use, when
appropriate. It can obviously be abused, but that's not the
point.
That exactly is my point that you are trying to avoid by all
means. I already agreed with all your points that C++ has a
lot of powerful and "cool" features (you can call them
expressive but I would be more comfortable if you used this
term consistently with some definition preliminary agreed on
between us.
Which is, after all, exactly what software engineering is all
about. If you don't do that, you might as well pack it up and
go home; no language is going to work for you.
If you want to discuss specific problems in C++, fine.
There's certainly no lack of subject matter. But too much
expressivity is NOT a defect, it's a definite advantage.
No, seriously, let's define "expressivity".
The ability to say exactly what you want, clearly and concisely.
And for the most
part, the points you've raised are points where C++ has a
definite advantage. (You can't write your increment() function
at all in Java, for a built in type. So if even discussing the
function has any relevance, Java is at a disadvantage.)
Again, your definition of "advantage" seems to be different
from mine and close to "having more useful features" (please
correct me if I am wrong).
My definition of "advantage" is, in the end, something that
reduces the cost of software development. Expressing exactly
what you want, clearly and concisely, definitely reduces the
cost of software development, and so is an advantage.
Java has less (syntactic) features than C++, no doubts here;
however this is one of its properties that makes it attractive
to project managers (who need to hire people, maintain old
code, all at fixed costs, etc).
There are two things which make Java attractive to project
managers: the first is simply that it is more or less
"in"---it's not a good reason, but it's probably the most wide
spread one. The second is the support structure which is
available for certain types of applications.
BTW It can still express all the same programs except for
system-level ones (the latter is not due to the lack of
features).
Sure. It's Turing complete. You just can't express them as
clearly and concisely.
(One last comment, with respect to using forward declarations in
C. Been there, done that. While they're obviously the way to
go for entity objects, you can't implement true value semantics
using forward declarations. Which is a major drawback if you
want or need value semantics.)
Certainly not. If I need *pure* value semantics I can simply use
structures.
A structure doesn't necessarily have the semantics you want in
your pure value.
And for "hybrids" (say, structures with integral and
variable-length strings data members) it is always safer and
often more efficient to honestly treat them as "entities" (I
am not sure this is a common term, I would use "objects" but
let it be) which they are -- in any language.
And that's simply wrong. A value is a value, and has entirely
different characteristics than an entity. Look at
java.lang.String, for example, for an example of a well designed
value in Java. (Note that it is final, has no mutable members
and... has overloaded operators.)
--
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