Mind you, no one said that missing C++ features are easy to use or that they can't lead to disaster, and given the scope of Java, is understandable why they aren't available.

It's just things I've noticed I could do with in certain frequent situations, but it's not frequent enough, or I'd just code in C++.

Headers are not a 'feature', they're a side effect of the first C compilers being one-pass compilers and therefore requiring all functions/etc. being declared up front. Splitting code into header and source files then just becomes a convention as it's the most sane way to not duplicate declarations everywhere.

They should have been ditched ages ago, but by then they were being (ab)used for all kinds of evil so they've kind of stuck around despite being a horrible temporary hack.

I only miss functions as first class citizens and a better native interface.

I'm doing a lot of C++ work at the moment, and it's incredible how compile times can make your mood super bad. I hate compile times. Any language that doesn't have that "feature" wins for me. My productivity is more important than 10% more execution speed.

Meh, I still like prototyping, even within the same source file. I usually manage through interfaces or abstract base classes, though. Guess it's just how I mentally organize code.

I also like templating like mad, and in C++ use namespaces like you'd use interfaces in Java (and I use interfaces in java to define constant structs like you'd use structs or enums), so it could also be that I'm mentally imbalanced.

One thing I do hate with a passion from C++ (just because I love it so much in Java) is the inability to interpret code, so you can refactor, look for references, or even decompile easily.

I don't like Oracle and Google, I don't want the former to kill Java with a crappy business model and I don't want to the latter to do the same by fragmenting it (imagine what will happen when Android DVM is fully supported on x86, people might have 2 Javas on desktop environments :s).

JNA is a good stab at this (though not the only one). Android support is there (though a bit experimental atm)!

JNA is nice, but as with all automagic pproaches it has quiet a few drawbacks. I want them to unf**k JNI and leverage VM internals. JNA is just a fancy wrapper around JNI as far as i am concerned. Still cool.

Roquen was suggesting that since it's *currently* not possible to use both abstract and final together, the Java devs *should* add that possibility for a different behavior: true uninstantiable classes. I disagree because the naming itself is weird. Using a private constructor is good enough

Roquen was suggesting that since it's *currently* not possible to use both abstract and final together, the Java devs *should* add that possibility for a different behavior: true uninstantiable classes. I disagree because the naming itself is weird. Using a private constructor is good enough

Nah, I'm suggesting it should have been that way from the start. As is created extra implementation work for compilers and VMs that add nothing to the language. Changing it now would make very little sense. abstract & final together seem weird because that choice wasn't made. abstract = can't instantiate. final = can't extend. Perfectly describes static utility classes. It's illogical to create a private constructor which is never called.

Ew... operator overloading might be too much of a stretch. It has to be one of the most abused and misused aspects of C/C++. Java doesn't need to add that layer of confusion to its process. [/offtopic]

Though having pointer access for primitives is something I miss from C/C++.

Implementing operator overloading is certainly not a hard problem in general, no. But as it stands now, operators are not method calls, so there's likely to be more compatibility issues doing it than are immediately obvious. Still, I think the main objection to operator overloading is, shall we say, theological rather than technical.

What about all the junk objects that would create? '+' for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.

c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code. Jumping around that much just to get some information from another person's code that could have been written using a more consistent and fairly self documenting language is dizzying and takes time away from real programming. That's why C++ is so hazardous to your health, as well as any other language with an include directive.

What about all the junk objects that would create? '+' for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.

c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code. Jumping around that much just to get some information from another person's code that could have been written using a more consistent and fairly self documenting language is dizzying and takes time away from real programming. That's why C++ is so hazardous to your health, as well as any other language with an include directive.

Well if you know the types of 'a', 'b', and 'c', it would be easy to decipher what a '+' would mean regarding their types and the outcome. It's just like calling the 'add' method, but less verbose.

Implementing operator overloading is certainly not a hard problem in general, no. But as it stands now, operators are not method calls, so there's likely to be more compatibility issues doing it than are immediately obvious. Still, I think the main objection to operator overloading is, shall we say, theological rather than technical.

Actually one operator is a method call in some contexts: +. Well, actually it can be a bit more than a method call. I think the use of + for string concatenation is the compatibility reason which prevents adding operator overloading to the language now. If it had been in the language from the start, they'd have done something different for string concatenation, or even eliminated it entirely in favour of using String.format.

And I would categorise the main objection as psychological rather than theological: its essence is "We know the horrors that people will perpetrate with it".

What about all the junk objects that would create? '+' for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.

c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time.

I think you're making some unwarranted assumptions about how it would be implemented. The most Java way of doing it would be a special interface which defines the methods into which the operators are translated, so c = a + b would be no harder to decipher than c = a.add(b) currently is. Having various interfaces would allow for things like varargs add operators. The technical side of things isn't the problem.

Indeed the real problem is the ability C++ operator overloading gives to programmers to practically redefine the syntax. This makes for syntax that is almost impossible to glance at and understand without all manner of crossreferencing. It gets even more hilarious when two C++ programmers start overloading the same operator in the same project to do different things. And then they bring in some libraries that do it a third way. The theological argument is actually relatively practical for a change.

It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code.

I have heard this exact argument numerous times, verbatim, in opposition to Object-Oriented Programming.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org