Subtle language semantic differences

[Kemp]

I was looking at some code written by a guy I know the other day and I noticed something that appeared to work wrongly. After a quick discussion we realised that I was thinking in terms of what things did in C++ whereas the code was in Java. It struck me that with languages that are so similar as to be able to compile a good portion of the same code (not neccessarily enough of one particular piece to be able to completely successfully compile of course) there are going to be some very subtle bugs introduced when someone switches over and slips for a moment.

For those interested, the code was akin to

Code: Select all

Class1 foo;
Class1 bar = foo;

If I am correct, under C++ that would invoke foo's copy constructor and give the resulting new object to bar [ie, would be equivalent to Class1 bar(foo)], whereas in Java it will simply set bar to point to the same object as foo.

Has anyone else encountered code like this that they'd like to share. I'm interested in this now, and I'm sure some people would find it useful to have a quick guide to what not to assume.

[Solar]

My Java is a bit rusty, but I would say you are correct.

Now try and explain this to someone who only ever learned Java, and learned by heart that Java has "no pointers".

It's actually easy to memorize: In Java, object identifiers are always references.

But oh, the horror if, in C++, I did

Code: Select all

typedef ClassX * Class1;

in some deeply hidden header... *evilchuckle*...

[Candy]

For those interested, the code was akin to

Code: Select all

Class1 foo;
Class1 bar = foo;

If I am correct, under C++ that would invoke foo's copy constructor and give the resulting new object to bar [ie, would be equivalent to Class1 bar(foo)], whereas in Java it will simply set bar to point to the same object as foo.

Are you sure that wouldn't invoke the assignment operator plus a blank constructor instead? So it would be functionally equivalent to Class1 bar(foo) but not entirely?

[JoeKayzA]

Are you sure that wouldn't invoke the assignment operator plus a blank constructor instead?

Just tested that. Result: In

Code: Select all

Class1 bar;
Class1 foo = bar;

the copy constructor gets called on foo with bar as argument. To get the assignment operator called, you'll have to do

Code: Select all

Class1 bar;
Class1 foo;
foo = bar;

Don't know if this is standard behaviour or compiler specific, but I think gcc sticks with mandatory standards.

cheers Joe

[ark]

Are you sure that wouldn't invoke the assignment operator plus a blank constructor instead? So it would be functionally equivalent to Class1 bar(foo) but not entirely?

No, I'm pretty sure it's defined to invoke the copy constructor when done in a declaration.

[Colonel Kernel]

What's really fun is going between Java and C#:

Code: Select all

Class1 foo = new Class1();
Class1 bar = foo;

In C#, if Class1 is not actually a class but a struct (i.e. -- value type), then bar is a separate copy of foo as it would be in C++. In the struct case, "new" doesn't allocate memory -- it merely invokes a constructor.

[Kemp]

Actually, that's something that can take people unawares (though it's not an issue between different languages).

Code: Select all

Class1 foo;
Class1 bar = foo;

has completely different results to

Code: Select all

Class1 foo;
Class1 bar;
bar = foo;

(In C++)

[Colonel Kernel]

I wouldn't say it has completely different results. The end result is probably the same (if the copy c-tor and assignment operator are consistent with each other). The only difference is in how you get to the end result.

[Solar]

If those two cases give you different results, fire the person who wrote the copy constructor and operator=()...

[ark]

If those two cases give you different results, fire the person who wrote the copy constructor and operator=()...

I'd have to agree, though you technically do get different results in that two different member functions are called. They should just both have the same end result, and very rare indeed is the case where it would make sense for them not to*.

* I'm only granting the possibility that the need might arise somewhere for some reason...in 99.99% of cases, the two should have the same end result.

[Kemp]

Heh, I guess that's very true, ignoring mess-ups and the inevitable exception to the norm those two should end with the same result, I always just found it wierd that code that is almost (visually) identical could (usually) generate identical results given two completely different control paths.