Bjoern Schliessmann schrieb:
Diez B. Roggisch wrote:
>Yes. You can for example create a constructor for object Foo,
which then is implicitly chosen when assigning an int to a
variable of that kind. So it acts as a casting operator. I call
that wicked, and subtle.
class Foo {
int _arg;
public:
Foo(int arg) {
_arg = arg;
}
};
int main() {
Foo f = 10;
}
Just looks like Java's
String spam = "eggs";
You don't seem to understand what is happening here. The fact that
string literals in java exist has nothing to do with an implicit type
casting as above example shows.
>Who cares for the reason - it is there, isn't it? You are the one
claiming that a new language should get rid of old concepts, btw.
Is C++ new? :) IIRC it's well 10 years older than Java, and that's
quite a lot in IT. Apart from this, Java is constantly evolving
(through Sun), where C++ is quite a standard since <= 1998.
C++ was new, nobody forced them to keep pointers around.
If I'd like to write a class that is interface compatible to Java's
String, so e.g. that I can use it with "+" operator or the
simplified construction (String a = "b";).
That isn't possible with python, too. It _is_ possible with C++, yes, as
my own example above shows, but at the cost of complex semantics.
And the +-operator can be used when you have a toString-method.
I don't offense compiler optimization, but the clunkiness of
those "special rules for String only" additions.
Python has those clunky rules as well as C++ - or don't you write
character literals like
"abcd"
in C++ as well? Where exactly is that clunky?
>The way is not awkward, it is called auto-boxing/unboxing and
works very well.
But it looks weird. Why not use classes for basic types? Is
performance really the reason? It kind of splits the language
style.
For the same reason ints and floats aren't objects _internally_ in C++
as well - optimization. C++ did go a better way here by treating ints as
objects syntactically, but the distinction is most of the times removed
from java as well since 1.5.
And this is more than matched by the subtle differences between
>>
Foo a;
Foo &a;
Foo *a;
I don't think that's too subtle. But, perhaps, just because I'm used
to C++. It has a little bit too many compatibility features.
But I'd rather like to have several options than being forced in one
way.
But choices let you make more errors - which was my point from the
beginning: java is a limited language, and I don't like it too much. But
it makes it hard to do things wrong. C++ makes it hard to make them right.
Diez
