C++'s interface with the Real World

[Steven T. Hatton]

I'm forking this from a reply to John Nagle in the smart_ptr<> thread.

To address some of the problems handled by the runtime environments of C#
and Java, it may be necessary to look beyond the C++ Standard. I believe
Microsoft post-DOS OSs are capable of detecting a null pointer access, and
throwing an exception to the program that attempted it. I've raised this
issues on the GCC mailing list (or newsgroup - I don't recall which), and
believe there was some interest in addressing the problem for other
environments. This discussion may suggest a way of doing the same for
Linux.

http://netlab.ru.is/exception/LinuxCXX.shtml

This really is the domain of the C++ ABI, and not the language standard.
There may be room in the standard for improving the language side of the
interface. I don't know.

My personal opinion is that there is no need for two (or three) languages to
create the kinds of products written in Java or C#. There may be a real
role for managed C++ and the CRL, such as creating C++ 'applets' in the
spirit of Java applets. The Java code to produce these animated graphics
is quite minimal, and uses nothing beyond the basic Java libraries:

http://mathworld.wolfram.com/topics/LiveGraphics3DApplets.html

Using Java3D I have created more sophisticated 3D applications which I can
share over the Internet as long as the person on the other end cares to
install Java3D. Although Java3D does have a bit of platform specific code,
the JVM makes porting it far easier than it might otherwise be. I can
therefore share my applets with people using different platforms without
any consideration of their platform on my part.

Clearly, in order to accomplish the same with C++ there would be a need to
restrict the available language features to those which do not require
direct access to system resources. Unfortunately, as I understand things,
managed C++ also adds non-standard features to the language. These
additions probably enhance the usability of the language in the CLR
environment, but they also represent a fork potentially leading to two
similar, yet incompatible languages.

One last comment on garbage collection. It's not a panacea. Though I never
actually got to the point of needing to address the problem, the Java3D
literatue discusses approaches to managing discarded objects; something
that is forced on C++ programmers. Though I believe C++ could and should
do a far better job of facilitating memory management, the fact that a C++
programmer has to take resource management seriously makes a C++ programmer
a better programmer.

 

[Larry I Smith]

I'm forking this from a reply to John Nagle in the smart_ptr<> thread.

To address some of the problems handled by the runtime environments of C#
and Java, it may be necessary to look beyond the C++ Standard. I believe
Microsoft post-DOS OSs are capable of detecting a null pointer access, and
throwing an exception to the program that attempted it. I've raised this
issues on the GCC mailing list (or newsgroup - I don't recall which), and
believe there was some interest in addressing the problem for other
environments. This discussion may suggest a way of doing the same for
Linux.

http://netlab.ru.is/exception/LinuxCXX.shtml

This really is the domain of the C++ ABI, and not the language standard.
There may be room in the standard for improving the language side of the
interface. I don't know.

My personal opinion is that there is no need for two (or three) languages to
create the kinds of products written in Java or C#. There may be a real
role for managed C++ and the CRL, such as creating C++ 'applets' in the
spirit of Java applets. The Java code to produce these animated graphics
is quite minimal, and uses nothing beyond the basic Java libraries:

http://mathworld.wolfram.com/topics/LiveGraphics3DApplets.html

Using Java3D I have created more sophisticated 3D applications which I can
share over the Internet as long as the person on the other end cares to
install Java3D. Although Java3D does have a bit of platform specific code,
the JVM makes porting it far easier than it might otherwise be. I can
therefore share my applets with people using different platforms without
any consideration of their platform on my part.

Clearly, in order to accomplish the same with C++ there would be a need to
restrict the available language features to those which do not require
direct access to system resources. Unfortunately, as I understand things,
managed C++ also adds non-standard features to the language. These
additions probably enhance the usability of the language in the CLR
environment, but they also represent a fork potentially leading to two
similar, yet incompatible languages.

One last comment on garbage collection. It's not a panacea. Though I never
actually got to the point of needing to address the problem, the Java3D
literatue discusses approaches to managing discarded objects; something
that is forced on C++ programmers. Though I believe C++ could and should
do a far better job of facilitating memory management, the fact that a C++
programmer has to take resource management seriously makes a C++ programmer
a better programmer.

Try posting to comp.std.c++. They deal with standards issues.

Larry

 

[Steven T. Hatton]

Try posting to comp.std.c++. They deal with standards issues.

Larry

Actually, I had intended this to go to comp.std.c++, I didn't notice I had
changed focus when I started the message.

 

[Chris Theis]

[SNIP]

Using Java3D I have created more sophisticated 3D applications which I can
share over the Internet as long as the person on the other end cares to
install Java3D. Although Java3D does have a bit of platform specific
code,
the JVM makes porting it far easier than it might otherwise be. I can
therefore share my applets with people using different platforms without
any consideration of their platform on my part.

Clearly, in order to accomplish the same with C++ there would be a need to
restrict the available language features to those which do not require
direct access to system resources.

[SNIP]

Here you're mixing two different things - the language & an additional API
library. For the implementation of your 3D application you need your
customer/user to install Java3D because you're using its features. So far so
good, but in this case what is the difference to C++ using OpenGL. You'll
need your customer/user to have OpenGL on his system (which is standard
today for Windows and Linux anyway) and you're fine. Naturally, to keep
portability alife you'll have to restrict yourself to the standardized
language and not use any extensions, but in Java you'll have to do the same.
(Forgive my ignorance as my Java knowledge is quite shallow, however I
assume that there exists various types of extensions to the core-language
too).

Cheers
Chris

 

[Steven T. Hatton]

[SNIP]

Here you're mixing two different things - the language & an additional API
library. For the implementation of your 3D application you need your
customer/user to install Java3D because you're using its features. So far
so good, but in this case what is the difference to C++ using OpenGL.

I cannot simply send you the OpenGL app I compile here on my Linux box and
expect it to run on a Windows, Mac, or Solaris box. I _can_ send you a
jarfile containing my Java3D code, and it _will_ run on your box if you
install Java3D. I believe I could even bundle the Java3D stuff, but I'm
not sure. What I was originally talking about was running it as an applet
in a web browser. I know there are plugins written in C++, but you can't
simply write C++ code and have it execute on virtually every computer
likely to visit your site.

You'll need your customer/user to have OpenGL on his system (which is
standard today for Windows and Linux anyway) and you're fine. Naturally,
to keep portability alife you'll have to restrict yourself to the
standardized language and not use any extensions, but in Java you'll have
to do the same. (Forgive my ignorance as my Java knowledge is quite
shallow, however I assume that there exists various types of extensions to
the core-language too).

The variants of Java are few if any. Microsoft tried that, and got taken to
court. Basically, if it is non-conforming, you can't legally call it Java.

 

[Andre Kostur]

[SNIP]

Here you're mixing two different things - the language & an
additional API library. For the implementation of your 3D application
you need your customer/user to install Java3D because you're using
its features. So far so good, but in this case what is the difference
to C++ using OpenGL.

I cannot simply send you the OpenGL app I compile here on my Linux box
and expect it to run on a Windows, Mac, or Solaris box. I _can_ send
you a jarfile containing my Java3D code, and it _will_ run on your box
if you install Java3D.

Nitpick.... it may run on your box if you install Java3D _and_ a JRE,
potentially the "right" version of the JRE.