What does Java tell about good C++ practices?

[tashirosgt]

Like all languages, Java was designed to fix certain problems in older languages. When I compare it to C++, I think the designers also wanted to make certain "best practices" in C++ mandatory. Examples would be that the file name that holds the code for the class must express the name of the class and that class files are in a sensible directory structure. Java also wants all the code for a class to be in one file. I suppose with modern editors that isn't such a burden to do in C++. What other "best practice" hints can a C++ programmer take from Java?

[adrianx]

I don't know so much if this is a standard best practice in Java, but it has certainly helped me a lot (with my own code). Class names *always* start with an upper case letter - SomeClass. Object names and methods (functions) *always* start with a lower case letter - someClass.someMethod().

[stevea]

I don't think imposing class names onto the files or a language imposing a directory structure is a "best practice" at all. It may be a reasonable choice for most cases but hardly a best practice. If you've worked on some very large C++ projects you'd see these rules as unnecessarily confining.

They didn't create a cpp C-preprocessor which is a good thing, but everyone knows that. The Cpp applied to C++ allows a lot of type hiding and bad practices. It's not some brilliant revelation.


The *CONVENTIONS* for capitalization and lower case objects etc is not enforced. I've had co-workers argue strenuously against CamelCase (tho' I like it personally). In any case the important thing is to have some consistent convention and use it consistently. It's perhaps a best practice for Java developers to follow the convention used in the Java libraries and predefines .. but those original choices don't represent "best practices" just good choices among many.



The lack of pointers in java is an artifact of it's architectural independence. You'd can find some very strong arguments that pointers are bad in structured code, and equally persuasive arguments that they are powerful and efficient. The lack of class inheritance is perhaps from a similar "limitation" origin or to reduce implementation complexity.

Nah - I can't agree. IMO Java is a good language clearly based on C++ with several self-imposed limitations to meet it's more limited environment. I think you are reading too much into the differences.

[sej7278]

Originally Posted by stevea

Nah - I can't agree. IMO Java is a good language clearly based on C++ with several self-imposed limitations to meet it's more limited environment. I think you are reading too much into the differences.

exactly, java is too confined as its designed to run on the jvm, instead of hardware.

i wouldn't mind so much if it were truly portable, but as "write once, run anywhere" is complete BS, i prefer C++ without the limitations.

[aleph]

Originally Posted by sej7278

exactly, java is too confined as its designed to run on the jvm, instead of hardware.

Actually some ARM processors can run some Java bytecode natively. That's one of the reasons why Java is prevailing on mobile phones.

[stevea]

Originally Posted by sej7278

exactly, java is too confined as its designed to run on the jvm, instead of hardware.

i wouldn't mind so much if it were truly portable, but as "write once, run anywhere" is complete BS, i prefer C++ without the limitations.

So why is it complete BS ? Could you explain your comment please. My impression was always that Java bytecode was pretty d*mned portable assuming you have a JVM running on the target and all the right versions. So why do you say this ?

Now until recently the boneheads (my opinion) at Sun have prevented anyone from porting a JVM beyond the PCs, Sparc and a very few others. The open source stuff and the GNU gjc have largely broken that bottleneck (I believe).

[richfell]

Originally Posted by stevea

So why is it complete BS ? Could you explain your comment please. My impression was always that Java bytecode was pretty d*mned portable assuming you have a JVM running on the target and all the right versions. So why do you say this ?

...

IMO, it's more like write once, debug everywhere. The issue is not the byte codes, its the varying behavior on different HW/SW platforms when running the code.

[stevea]

Originally Posted by richfell

IMO, it's more like write once, debug everywhere. The issue is not the byte codes, its the varying behavior on different HW/SW platforms when running the code.

Sorry it taken so long to get back to this ... but can you please explain in more detail. The whole point of the JVM was to prevent varying behavior on different platforms. I've written just a little Java (starting back circa 1995) and have never deployed anything serious cross-platform so maybe I'm missing the practical issue here.

Are the JVM models defective ?

[sej7278]

i think the problem lies in the different levels of quality or support of the jvm's, if your platform is not well supported then you'll only have a subset of the functionality.

i've almost never seen a .jar from one platform "just work" on another.

the same can't be said for other interpreted languages though - look at python, ruby, php or perl, you get almost 100% cross-platform capability.

[aleph]

Here's two links to some quite amusing, albeit somewhat inflammatory, quotes regarding Java and C++...

http://harmful.cat-v.org/software/java
http://harmful.cat-v.org/software/c++/

Well, just for your laugh... My personal favorate is "The last good thing written in C++ was the Pachelbel Canon."