Why doesn't C++ have comprehensive API like Java? (Cont'd.)

[Ioannis Vranos]

Who said you can't? What I have been saying all along? My .NET
applications have garbage collection, all objects inheriting from a base
class Object and thus I can do:


int x= 7;

String *p= x.ToString();


run-time generics (in .NET 2), templates, etc. However not all of these
are suitable or feasible for systems programming, that's why Standard
C++ comes with what is suitable and feasible on its own (and that's why
Java is not suitable for systems programming).

To bring it in the Java context, a C++ compiler for the JVM would have the same access to
all JVM features, that Java the language (the syntax) currently has. However JVM is
proprietary and its company does not let anyone make a C++ (or Fortran or whatever)
compiler for it.

 

[Justin Naidl]

I thought you could do socket programming in C++ you just have to use C
syntax and libraries for it.

~Justin

 

[Ioannis Vranos]

I thought you could do socket programming in C++ you just have to use C
syntax and libraries for it.

These days I am studying .NET networking, TCP/IP stream-socket based, and UDP
connectionless datagrams. Both with .NET classes and not "C syntax and libraries".

In other words it depends on the platform and you can find OO APIs and libraries to work with.

 

[Phlip]

I thought you could do socket programming in C++ you just have to use C
syntax and libraries for it.

The OP doesn't seem to understand we are discussing two distinct things: The
C++ Standard, and your C++ implementation.

The Standard only contains the most common things that must work everywhere,
such as file handles.

You describe Berkeley Sockets, which are probably part of POSIX. That's
_another_ Standard, which your C++ implementation _might_ provide.

Note that a real language lawyer could nail down all those specifics better
than me. The point remains, C++ _has_ comprehensive libraries, just like
Java.

 

[Ed Jensen]

To bring it in the Java context, a C++ compiler for the JVM would have the same access to
all JVM features, that Java the language (the syntax) currently has. However JVM is
proprietary and its company does not let anyone make a C++ (or Fortran or whatever)
compiler for it.

Nonsense.

Anyone is free to write a compiler that emits Java bytescodes which
will run on the Java virtual machine. Sun even documents the
bytecodes openly and freely. Many such compilers already exist, such
as Jython, which is a Python compiler that emits Java bytecodes.

 

[Ed Jensen]

If JVM was not closed to other languages (it is a proprietary, closed virtual machine),
all languages would be able to target it including C++.

Nonsense.

The JVM is not "closed to other languages". There are compilers
available that target the JVM but don't require you to use Java, such
as Jython, a Python compiler that emits Java bytecodes.

The Sun implementation of the JVM is closed and proprietary, but there
are also open implementations, such as GNU's classpath.

Lastly, there's no non-trivial C++ program that would compile and run
unchanged on Microsoft's .NET CLR. You have to use a limited and
bastardized version of C++.

 

[Andrew McDonagh]

Nonsense.

Anyone is free to write a compiler that emits Java bytescodes which
will run on the Java virtual machine. Sun even documents the
bytecodes openly and freely. Many such compilers already exist, such
as Jython, which is a Python compiler that emits Java bytecodes.

even further nonsense...

the JVM spec is public too, so anyone can write their own JVM (as lots
have - IBM, SmallTalk, etc..)

http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

 

[Ioannis Vranos]

Nonsense.

The JVM is not "closed to other languages". There are compilers
available that target the JVM but don't require you to use Java, such
as Jython, a Python compiler that emits Java bytecodes.

OK, then there has been no interest of a C++ compiler vendor to produce a JVM compiler. In
any case, we should not confuse between Java the syntax and the facilities of the JVM.

The Sun implementation of the JVM is closed and proprietary, but there
are also open implementations, such as GNU's classpath.

Lastly, there's no non-trivial C++ program that would compile and run
unchanged on Microsoft's .NET CLR. You have to use a limited and
bastardized version of C++.

*Any* ISO C++ program can compile and run unchanged under .NET, as native code of course.

Naturally, all .NET features are accessible as system extensions. That is, ISO C++ is one
thing (the same as with any platform, *unmanaged* and source portable), and .NET features
are another thing (intermediate bytecode, garbage collection, .NET types, etc).

If you want to have a pure managed program, you can stick with .NET features only.


This is not a "limited version of C++", any limits are .NET limits (no multiple
inheritance but interfaces only, etc). ISO C++ code under .NET has not such limits of
course (because it is unmanaged, native code). When using .NET facilities, you get .NET
limitations in them (only), when you do not use them you do not get any limitations.

 

[Ioannis Vranos]

even further nonsense...

the JVM spec is public too, so anyone can write their own JVM (as lots
have - IBM, SmallTalk, etc..)

http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

OK, then there has been no interest of any C++ compiler vendor to produce a JVM compiler.

In any case, we should not confuse between Java the syntax and the facilities of the JVM.

 

[Ed Jensen]

*Any* ISO C++ program can compile and run unchanged under .NET, as native code of course.

Which is of dubious value, in my opinion. C++ users don't need .NET,
because C++ compilers are available for just about any platform you
choose to target.

Naturally, all .NET features are accessible as system extensions. That is, ISO C++ is one
thing (the same as with any platform, *unmanaged* and source portable), and .NET features
are another thing (intermediate bytecode, garbage collection, .NET types, etc).

If you want to have a pure managed program, you can stick with .NET features only.

That's when you start using a bastardized version of C++, which isn't
really C++.

 

[Ioannis Vranos]

Which is of dubious value, in my opinion. C++ users don't need .NET,
because C++ compilers are available for just about any platform you
choose to target.

I am not sure I can understand your point. .NET is a platform. If you want to write .NET
applications you use .NET facilities, if you want to write QT GNU/Linux applications you
use QT, etc.

That's when you start using a bastardized version of C++, which isn't
really C++.

More accurately we can say that when you stick with .NET features only, you are writing
non-portable code to other(non-CLI) environments.

As is the case of non-portable code if you stick with Win32 API only features, QT, MFC, etc.

In my .NET applications I am using ISO C++ extensively, like string, vector, etc.