I can compile C# for windows, android, and OSX. I can compile Java for windows, android and OSX.

*This is not an advantage of C++.*

Hell I can even take a DLL compiled on windows and run it in OSX. Good luck getting C++ binaries to do that.

C++ is a 3rd generation language.
Only generation 0 (opcodes) and generation 1 (assembly) are considered low-level.

Fortran, Pascal, & C are 2nd generation languages.
Objective-C, C++ is 3rd.
Java & C# are 4th.

You can't just lump languages into tiers like that.

What generation is LISP? By year, it should be generation 0 (it is after all, 20 years older than C). If we go by expressiveness, it's at least tier 5.

What generation is Erlang? Over 9,000?

And I strongly object to your lumping Objective-C in the same category as C++. How does dynamic message-passing land in the same category as a glorified C pre-processor?

C++ isn't as portable as C perhaps. But far more so than C#. It doesn't need a runtime VM for a start ;)

I trust you are joking?

If not, I'm going to hand you a .jar file and a .o file, both implementing the same functionality, both compiled on an undisclosed (but exotic) architecture, and you can come back when you have executed both.

And if you code your software correctly, you can get code that works on all without needing to rewrite your software in a new language each time.

Otherwise known as "significant porting effort". Whether you do this before or after you write your software, is largely irrelevant.

Hell I can even take a DLL compiled on windows and run it in OSX. Good luck getting C++ binaries to do that.

If I was to compile a .NET assembly "dll" with C++.NET (using the /clr:safe flag) it would run fine on a mono VM on OSX.
But I guess a native Windows DLL would run fine in wine on OSX anyway. Afterall, installing wine is just as much unnecessary faff for users as installing the mono runtime.

If not, I'm going to hand you a .jar file and a .o file, both implementing the same functionality, both compiled on an undisclosed (but exotic) architecture, and you can come back when you have executed both.

I doubt that exotic architecture even has a Java VM ported to it haha.

But good luck getting a .jar to run on an iPhone.

Otherwise known as "significant porting effort".

Yeah, because completely reimplementing in a whole new language is sooo much quicker... Or not.

And I strongly object to your lumping Objective-C in the same category as C++. How does dynamic message-passing land in the same category as a glorified C pre-processor?

Objective-C doesnt belong in the same category as C#/Java because not only does it not need a garbage collector but it also compiles out to native code rather than needing some hosted VM indie shite.
Not to mention that C#'s pre-processor has been completely crippled making it *even* less useful for cross platform development. (Then again.. Microsoft only really designed it for their platforms anyway...)

[quote name='swiftcoder' timestamp='1347666854' post='4980226']
If not, I'm going to hand you a .jar file and a .o file, both implementing the same functionality, both compiled on an undisclosed (but exotic) architecture, and you can come back when you have executed both.

I doubt that exotic architecture even has a Java VM ported to it haha.[/quote]
Oh, trust me, it does. You can take a university course on implementing the JVM entirely in hardware. There are even JVMs available for god-damn toasters.

But if you don't like that point, let's try a little exercise:

- As a language implementer, what are your choices when face with an entirely new platform? Either:
+ (a) port a compiler to the platform, or
+ (b) port a virtual machine to the platform.

- Now, programming languages like C, tend to take route (a).
+ But guess what language the JVM is written in? That's right, C.
+ So as soon as you have a working C compiler, you can have a working JVM.

- Ergo Java is at least as portable as C.

- Ergo Java is at least as portable as C.

By that logic, since almost everything is written in C, then everything is as portable. Ridiculous. The garbage collector alone that a JRE needs can't be ported to a large number of platforms for technical reasons.

FYI, almost all implementations of Java are written in C++, and this is proven to be much less portable than C. Your logic is so flawed. Afterall, platforms with no stack (e.i PIC), certainly wont take well to C++'s stack unwinding haha.

Not only that, but the development time required to build a JVM on the platform is certainly not going to be a good return (Unless of course a company wants to cash in on indie developers developing games for the platform such as the XBox360 .NET XNA stuff).

So chances are good that there will be no Java JVM on exotic platforms. Admittedly they will probably also not have an OpenGL implementation or 2D acceleration either so this isn't too relevant.

Not only that, but the development time required to build a JVM on the platform is certainly not going to be a good return (Unless of course the company wants to cash in on indie developers developing games for the platform such as the XBox360 .NET XNA stuff).

And here, my friend, you are hoist by your own petard

Because if, as you so vehemently argue, C is some sublime expression of portability, then, by the transitive property, being in and of itself a C program, the JVM must share in this magical ideal of portability, and 'porting' the JVM will be a matter simply of re-compiling.

And on that humorous note, I bid adieu and farewell to this (meaningless) discussion.

And this thread is closed. Congratulations!