I think you’re missing my point somewhat - I’m perfectly happy with the myrad of options that C++ presents, but rather miffed that providing similar safety in Java involves a large amount of tedious leg work 
You presented generally poor C++ code and asked why it wouldn’t be done that way, I answered.
Adding C++ style const to Java wouldn’t be a simple addition, and it’s debatable how useful it’d even be considering how the rest of Java works.
C++ compilers do it all the time, they aren’t involved in the runtime process at all.
Most of the snippits are examples that i’ve seen in other C++ libs, mainly MFC, I’ll be the first to admit that my C++ knowledge is not as complete as i’d like.
As for compile time const checking, C++ compilers don’t have to deal with dynamically loaded classes.
(and I think we’re officially off topic now 
)
I don’t see what dynamically loading the classes has to do with compile time const checking. For one most C++ implementations have support for dynamically loaded classes/libraries, it’s just not universal like Java’s is.
I’d imagine it’s a matter of adding an additional flag to the symbol table, and checking the flag at each assignment operation. Or there’s probably a better way as that’d likely be expensive.
But if all classes come from the same compiler, then I don’t see how the fact that they’re dynamically loaded matters.
C++'s const checking is far from perfect. Like I said earlier, you can explicitally cast away constness (something the compiler’s aware of and is ok with) or it’s also possible to sneak constness off in ways the compiler doesn’t realize. In the end the developer still has to have a head on his shoulders All these things like const are just there to help, not be absolute.
Well, as an example: I’m using an imaginary lib that has Vector2f, which has a .angleTo(Vector2f) call. Now in a function i’m using what is supposed to be a const vector, and since the angle function returns the angle and leaves the vector alone all is good.
But then on another system the program is run, and the same lib is using a different version which (for reasons unknown) normalises the vectors while calculating the angle - the const object has been changed and theres no way for the compiler to pick up on it.
The interface to his method needs to declare that. He either accepts a const vector or a nonconst vector, and that generally indicates if the object could or won’t change. If his interface declares a nonconst argument, it’s an error to send a const argument to that method, either runtime or compile depending on when it could be caught.
It’s sort of like using say java.awt.Color.RED in Java 1.3. That field doesn’t exist, it’s a compile time error. But if you took a 1.4 class that uses Color.RED in a 1.3 JVM, it becomes a runtime error and the jvm properly catches it. It’d (I assume) do the same for const.
But again, const is just the language/compiler trying to help out, it’s not absolute. If you’re working with some unknown library that accepts a const vector, for all you know he had to write in some kind of kludge in that method which removes the constness and changes your vector. Maybe he did that to fit his own needs and didn’t consider other users. That’s really terrible programming, but it happens.
What would a const system do to reflection, jni and final?
[quote]But then on another system the program is run, and the same lib is using a different version which (for reasons unknown) normalises the vectors while calculating the angle - the const object has been changed and theres no way for the compiler to pick up on it.
[/quote]
Couldn’t you make the const-ness of the arguments and return types an integral part of the method signature? Also, allow subclasses to offer the same or a more strict version of method args, and the same or less strict return values?
Hrm, actually I’m not sure that would be so useful. Needs some thought…
[quote]Yes, but then again… so it goto… :o
[/quote]
Yeah, can’t wait for that to be added! :
That’s very well known, a specific case, and any confusion created is totally outweighed by its usefulness. I disagree with user-generated operator overloading because people start creating things like:
boolean result = "Lesser" < "or Greater?" ;
Socket s = socket1 + socket2 ;
HostName host ; PortNumber port ; URL url = host + port + "/index.html" ;
Texture multiTexture = texture1 & texture2 ;
You give people an utterly misusuable tool, and they’ll misuse it utterly! You know they do!
And operator overloading can be used very elegantly, and improve efficiency to boot. It’s a double edged sword, no doubt.
On http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html the same question like here as been asked (and answered by a SUN engineer) :
[quote]Q: Is there any plan to support the const keyword in the future, as in C++? If not, is there a reason?
Josh Bloch: We do not have plans to add support for the const keyword to the Java language. It was a mixed blessing in C++; as you know, it’s merely advisory, and can cast on or off. Gosling hated it, and did final instead. What you really want is “immutable,” but it’s a research problem to make this work properly.
[/quote]
Yes, my recent C++ years in mid sized dev teams proved that. This is why I think Java is such a great and (more) “clean” language. I really like it. Very good work @ Gosling and all other contributors at SUN !
[quote]http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html
[/quote]
My word, that is some good reading! I didn’t realise the full extent of the changes being included in Java 1.5.
Generics, Static Import and Enumerations get all the attention, but there’s also Autoboxing, Foreach, Metadata, Concurrency Utilities API, StringBuilder (unsynchronised StringBuffer), Varargs, C-style printf-type library, and use of generics in things like Comparable. Wow!
My personal favorite that I can’t wait for (though it isn’t as important construct-wise) is the foreach statement.
That thing just rocks.
But I guess the most important significant change is either autoboxing or generics; I have not yet decided which is most important to me. Probably both.
I know. Every time they release another version spec, I start thinking about all the places I could use the new features in whatever project I’m working on. It gets really depressing.
I think generics are going to rock. A compile time error as opposed to a ClassCastException? Especially if eclipse will be able to pick up the error on the fly? Oh hell yeah
When 1.5 is available it’s going to take me a while to get used to not doing things the old way
[quote]When 1.5 is available it’s going to take me a while to get used to not doing things the old way
[/quote]
This reminds me of your other comment about not using switch and using polymorphism instead.
I tell you, I think generics are going to rock, but I think they’re going to be a PITA to remember to USE them.
Any news on what’s going to happen to container classes when generics turn up? We going to get a bunch on new version in util.generic which support generics?
Kev
[quote]Any news on what’s going to happen to container classes when generics turn up? We going to get a bunch on new version in util.generic which support generics?
Kev
[/quote]
The affected classes (=many will be these:
http://jcp.org/aboutJava/communityprocess/review/jsr014/
Had a quick read, does this mean all old code that uses collections will be broken if compiled against 1.5?
Kev