Diez said:
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";
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.
Where is your money, and where your mouth?
I'm not discussing for money
That is a matter of taste - but in the same way, we could argue
about C++ and C, can't we?
ACK.
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"
.
So what? Since when is compiler optimization a bad thing?
I don't offense compiler optimization, but the clunkiness of
those "special rules for String only" additions.
What do you think happens all the time when mixing types in C++?
Mh, surely no convenience substitution in the sources for one class
only.
And I know of some very elaborated schemes called "common base
class idiom" for e.g. template-based vector classes to introduce
allocation optimization to arithmetic expressions in C++.
I don't
Too high for me.
The code _generated_ by the java compiler, and the C++ compiler,
is not the issue here.
Full ACK. (perhaps we were misunderstanding each other)
and in C++, you can do:
char *a = "1";
char *b = "2";
char *c = a + b;
But with a totally different, unexpected outcome.. I know where
*I* start laughing here.
Mh, in other languages you also *can* do stupid things. I'm thinking
about weird Python class designs. But Python's lack of private
variables isn't bad just because of this, is it?
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.
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.
Regards,
Björn