Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

You'd be surprised how having one thread dedicated to code optimization (speculative execution, caching of frequent objects and stuff like that) can help the performance of your code During a project for university, a friend of mine has tested C vs Java for dynamic function calls, memory allocation (and access) and native function calls. C only got the best results for native function calls.I'm not a hardcore fan of Java, but I've been using C++ for work for the last year and a half, and I have already regretted quite a few times not having selected Java for the project.

Java might have a garbage collector, but its major disadvantage is that you just can't collect garbage yourself, so it tends to memory hogs of a quite notable amount.

That does not mean that you can't write "efficient and fast code" in Java, it just means that it may use more memory. On the other hand, the JVM can do stuff like copy-on-write, which may even cause a lower memory usage than a C++ program.

Hmm, since Java *may* use less memory than C++, and *may* run faster than C++, does that mean C++ is also an inefficient and slow language?Or better yet, as Assembly is always faster and uses less memory than both C++ or Java, does it make both languages inefficient and slow?

Is it that important if the program takes more or less memory? Or if it is a few percent faster or slower? Of course there are fields where this matters (scientific research and even there, they use Matlab, Python, OCaml etc. even though they are slower -> why?) but for a daily code, I do not think it really matters.

My primary decision point is how easy is to code and how I enjoy it (first order functions, pattern matching...). How the language helps you to parallelize the code, how to protect your code against bugs (units of measure, strong typing, immutability...), how to easily extend the language, how to debug (immediate scripting) it etc. And I really do not enjoy to code in C++. Java is better / simpler and and any modern functional language like F# or Scala goes even further.

PS: I do not say that C++ does not have its place but I do not understand why everybody uses it just to gain a little in memory and speed. I wonder why you do not code in assembler to gain even more speed

Hm, the whole programming language discussion is, as always, very interesting, but imho it boils down to the simple paradigm: "Crap in, Crap out".If one is trying to write a C style program in Java, or a huge project in i386 assembly, you should really not be surprised the end-result is not what you had hoped for.The managed environments like the JVM and .NET advertise that they will cleanup after you leave an object-scope, but it sure makes a lot of difference in what state you leave your 'trash' behind. Setting objects to null when no longer needed in your Java or C# programs is just as effective as freeing allocated memory in your C programs, regarding the memory use.

Not every programming language is fit for every job, even if some are fit for more jobs than others. I wouldn't be writing a device driver in Java any day soon, but I would not even consider writing a GUI app in assembly language, or C (the closest thing to assembly language, imo).

For every project, there should be a clear and motivated choice for the language and libraries/frameworks used, and not try to 'fix' things later by adding other languages/libraries if the first choice happens to be 'sub-optimal'. In that case: Redo from start.

Tux: I have to ask, you have been quite vocal about your preferences of what is/isn't a programming language and the particulars of each. Do you have any examples of your work? Perhaps a sample application you can show?

On the idea of different languages being suited for different tasks, that was the appeal that got me into COM. Then the .NET promised mixing and matching to do different parts of a task in the suitable language. Now we also have to contend with 32 bit vs. 64 bit loadable libraries or assemblies or in process servers or whatever.

Maybe what we need is JITE instead of JIT? Just In Time Encrypted compiler. That way you can distribute the code as compilable source without "giving it away." The host machine knows if it is 32 bit or 64 bit and a bunch of other things about itself. It should compile the loadable libraries and the main executables with the same Bitness and calling conventions. No more thunks. The program and associated libraries could be "compiled" as part of the install process. I dunno', I'm not that far into my coffee yet so strange ideas are to be expected.

Still I prefer them hidden just like what James Gosling preferred... you seem to be a C++ expert... can you give us an important use of pointers

One use would be implementing the language with the hidden pointers. In the beginning many of the OOP languages were just front ends that spit out C source code since C compilers were most likely to exist for the target platform.

The C++ virtual functions themselves are just a jump table of function pointers with some type checking. And of course COM takes that to another level.