On Wednesday 15 September 2004 11:05, Jerry Feldman wrote:

Without including the quotes, let me answer a few things. First, Java is an entirely new language where C++ is specifically a derivative of C, that includes the power of C. On the same page, C++ also inherits some of the ugly features of C.

I can't speak with unquestionable authority on this, but I believe you might find Java has it's own hidden legacies. Namely Small Talk and Lisp (spelled Emacs).

Threads. I consider this a plus for Java since the programmer does not need to consider different threading models.

Until very recently, I was of the opinion that C++ was better off without standardizing threading. That allows for other threading 'standards', models, or whatever you want to call them to be created to suite specific needs, or simply to allow for more innovation. Sure with Java you pretty much know what you are dealing with in all cases. But that doesn't allow for much flexibility. The reason I say 'until recently' is because I found this: http://people.redhat.com/drepper/tls.pdf

Graphics. This is a debatable issue.

Some other things I personally prefer in Java over C++: primitive type standards, such as integer sizes. These are all defined by the Java specification so that you are guaranteed an int is 32 bits, a long is 64 bits. In C and C++, an int may be as small as 16 bits and as large as a long (although most 64 bit implementations use a 32 bit int). Longs on a 32 bit system are normally 32 bit and 64 bits on a 64 bit system, and could be 128 bits on a 128 bit system.

My understanding is that the latest C standard actually provides similar definitions. I brought this up on comp.std.c++, but can't say there were any conclusive commitments from anybody.

Character data types in Java are full unicode where they are simply a very short int (eg. 8 bits) in C and C++.

There is the wchar_t, and there are some pretty comprehensive libraries out there for C++. I've looked that this in the past: http://oss.software.ibm.com/icu/

Another debatable issues is inheritance. Java uses a single inheritance model where C++ uses multiple inheritance.

For the most part, I believe C++ has the better model in this respect. Sure there's the evil diamond, but I haven't encountered it that much. There are some costs to using pure virtual classes as interfaces which might be mitigated. I really haven't been able to evaluate this, but I do find it interesting: http://www.heron-centric.com/2004/08/c-with-interfaces-article-addendum.html

C++ also supports templates. Templates are very powerful, and allow C++ to use a single container model to contain just about anything. But, there are ways to do similar types of things in Java.

Yes. Java 1.5-beta has something called generics, but I can't say much about them other than they are advertised as being like C++ templates. Templates are significantly different from the Java brown-paper-container model. C++ templates are 'compiled away', whereas Java containers, as I understand it, are pretty much a runtime entity that doesn't lend itself to the same kinds of optimization that templates provide. I'll grant that Java's containers were much easier for me to learn. I always had a level of dislike for the requirement to pack and unpack things with pervasive castings, which templates don't require. While the portability of Java may I find some uses of the CPP utterly distasteful. I sincerely believe that many of the common uses of macros make it very difficult to create the same level of tools (IDEs) you can find with Java, and the notion of #including multiple levels of source files is simply offensive.

mitigate this, the conditional compilation in C++ allows for an implementation to comply with different standards and different platform dependent features. In a complex product, I generally use this to add debugging code that I do not want in production code.

I've noticed that C/C++ programmers moving to Java tend to take that kind of approach until they discover that exceptions work better in most cases when handling error trapping in Java.

Performance: In most cases, a C++ application will significantly outperform a Java application. However, some C++ features make optimization very difficult where a good Java compiler with a good JIT can cause a Java application to perform well.

From what I understand, the door has only been opened on what can be done with C++ regarding optimization in some situations. These mostly have to do with sophisticated mathematics.

There are many IDEs that make both C++ and Java reasonably easy to use in a graphical environment, simplifying the code.

My experience it that Java IDEs are better than C++ IDEs in providing the features I benefit most from. C++ tends to be too unstructured and unpredictable to provide the same level of error detection, resource location, and code completion that I found with JBuilder. -- Regards, Steven

On Saturday 25 September 2004 14:34, Jerry Feldman wrote:

On Sat, 25 Sep 2004 06:38:56 -0400

"Steven T. Hatton" wrote:

...

I can't speak with unquestionable authority on this, but I believe you might find Java has it's own hidden legacies. Namely Small Talk and Lisp (spelled Emacs).

It certainly has some history. The Java language is very C-ish by design. A few things were changed: integer sizes are explicit floating point size is explicit. char is not an integer. Dynamic memory allocation is controlled in that you can only allocate an object, and there is no explicit free as this is done automatically. The language is object oriented by design. I see absolutely no Lisp in this at all.

Garbage collection, byte compiling, running on a VM, no explicit pointers, and I'm confident other features have their origins in Emacs Lisp. If you look closely you may even discover that an object is pretty much just a specialized list.

The problem with this approach is that the per-thread context must be globally visible to all other threads, and a misbehaving thread can cause problems. Normally I create an array (or other data structure) containing the thread id, thread number (locally defined), and possibly some other information used by the thread.

I was under the impression that that's pretty much what's going on with the TLS model discussed in Drepper's paper. There is a global set of indexes mapped to the running threads. The only thing preventing threads from stepping on eachother's storage is good behavior. I believe the main emphasis of the TLS model is to provide a way to maintaining per-thread 'static' storage for each function that uses static variables.

--- standards issues The problem that a language has by specifying a paradigm like threads, is that there is an independent standards committee working on threads. C++ has the additional problem in that there needs to be a certain amount of C compatibility, and they need to coordinate with the C committee also to some extent. By Java stating its own thread paradigm, it forces its threading standard to be implemented on all platforms. Whether it uses the POSIX or other model underneath is not really an issue. You are also guaranteed that the standard classes are threadsafe.

Not everything in Java is thread safe. I know some of the collection objects need to be wrapped in some kind of thready synchronizing class in order for them to be used safely in concurrent programming. -- Regards, Steven

On Sun, 26 Sep 2004 01:11:56 -0400 "Steven T. Hatton" wrote:

Garbage collection, byte compiling, running on a VM, no explicit pointers, and I'm confident other features have their origins in Emacs Lisp. If you look closely you may even discover that an object is pretty much just a specialized list. First, running in a VM is shared by nearly every interpretive language. Lisp, of course, is one of the oldest computer languages with its origin going back to the 1930s. One also must remember that Gosling was the author of the Gosling, or Carnegie-Mellon Emacs. Compiling to an intermediate language has been around for a while also. We can also look at Algol and see some Algol in Java. But, the basic language is essentially C with some fixes. Similar to C++, Java has constructors and overloading, but also lacks destructors, which are somewhat unnecessary.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

I don't disagree that it superficially is very much like C with much in common with C++ as well. It is blatantly clear that the Java designers were looking at C++'s object model when they created their own. Even where they deviated from C++, it was often a conscious departure from the model they were following. They also took some things from Small Talk. Since I know far less about ST than C++, I cannot say much here other than that, I believe they took the concept of a universal base class (UBC) from Small Talk. This is most likely true. C++ was essentially built upon legacy C where

On Sun, 26 Sep 2004 13:15:54 -0400 "Steven T. Hatton" wrote: the designers of Java had no legacy language to support. They decided to enforce a strict OO environment. they also decided to avoid multiple inheritances as well as operator overloading. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Sun, 26 Sep 2004 14:44:07 -0400 "Steven T. Hatton" wrote:

I believe a better way of putting that last sentence would be, "They also resigned themselves to forego multiple inheritances as well as operator overloading." I believe the latter has always been a regret of Gosling. The reason the former was not doable is because if you have a UBC, you have a diamond DAG at every node in your inheritance diagraph other than the root.

It's unfortunate that C++ programmers don't fully understand the merits of pure virtual interface classes. Many good aspects of Java's design come from a solid understanding a appreciation of Stroustrup's design philosophies. In many cases Java programs do a better job of realizing Stroustrup's intentions than comperable C++ programs. Much of this is not due to the language differences, per se. It's due to a lack of understanding on the part of C++ programmers...And the fact that C++ can get a bit unwieldy with all its #include directives in conjunction with the use of pure virtual functions and MI.

This is an interesting animal: http://digitalmars.com/d/index.html Interesting. We are essentially on the same page. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9