D - About "D vs. C/C##/C#/Java"
- Matthias Becker <Matthias_member pathlink.com> Dec 21 2003
- "Charles" <sanders-consulting comcast.net> Dec 21 2003
- "Charles" <sanders-consulting comcast.net> Dec 21 2003
- Ant <Ant_member pathlink.com> Dec 21 2003
- "Charles" <sanders-consulting comcast.net> Dec 21 2003
- John Reimer <John_member pathlink.com> Dec 21 2003
- Ilya Minkov <minkov cs.tum.edu> Dec 21 2003
- "Phill" <phill pacific.net.au> Dec 24 2003
- "C. Sauls" <ibisbasenji yahoo.com> Dec 21 2003
- Ilya Minkov <minkov cs.tum.edu> Dec 21 2003
- "Matthew" <matthew.hat stlsoft.dot.org> Dec 21 2003
- "Walter" <walter digitalmars.com> Dec 21 2003
- Ian Johnston <Ian_member pathlink.com> Dec 22 2003
- "Walter" <walter digitalmars.com> Dec 22 2003
- "Phill" <phill pacific.net.au> Dec 24 2003
- Andy Friesen <andy ikagames.com> Dec 24 2003
About the compairison table: especialy about Java: Resizeable arrays: Java has resizeable arrays in java.util.* you have one. Now you could say it's part of the library not of the language, but where do you draw the line between language and library in Java? Is java.lang.Object Part of the language or part of the library? All classes implicitly inherit from it, so I guess it is part of the language. But if the package java.lang.* is part of the language why isn't java.util.*? At least there should be a note, but I would prefer a "Yes". Associative arrays: Same as above. Templates: Make a note about Java, that 1.5 will have generic types. Compatibility -> direct access to C: What about JNI? This should become a Yes. Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C# code? And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp) don't know where, maybe arrays, as there are your strong typedefs: unsigned types: D: Yes C: Yes C++: Yes C#: Yes Java: No under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes These points might help to choose, which language is the right one for the task you have to do.
Dec 21 2003
"Charles" <sanders-consulting comcast.net> This assesment sounds very Java biased, I disagree with alot of these , especially Java and C# have RPC ?!?!?! RPC has been on unix with C forever.. , and we have graphic and internet routrines, have you seen the socket and opengl modules ? no , no , no ... nothing about this adds up at all! C "Matthias Becker" <Matthias_member pathlink.com> wrote in message news:bs4jkq$rv4$1 digitaldaemon.com...About the compairison table: especialy about Java: Resizeable arrays: Java has resizeable arrays in java.util.* you have one. Now you could say
part of the library not of the language, but where do you draw the line
language and library in Java? Is java.lang.Object Part of the language or
of the library? All classes implicitly inherit from it, so I guess it is
the language. But if the package java.lang.* is part of the language why
java.util.*? At least there should be a note, but I would prefer a "Yes". Associative arrays: Same as above. Templates: Make a note about Java, that 1.5 will have generic types. Compatibility -> direct access to C: What about JNI? This should become a Yes. Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C# code? And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp) don't know where, maybe arrays, as there are your strong typedefs: unsigned types: D: Yes C: Yes C++: Yes C#: Yes Java: No under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes These points might help to choose, which language is the right one for the
you have to do.
Dec 21 2003
Actually I cant help myself I have to flame here. Java sucks. Almost all applications that use Java on my machine are un-bearably slow. They often lock my machine, and Im on a 2.4 mhz / 600+ RAM! No other application runs that slowly , not even games. And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits on a floppy ). What is it about Java that you like ? C "Matthias Becker" <Matthias_member pathlink.com> wrote in message news:bs4jkq$rv4$1 digitaldaemon.com...About the compairison table: especialy about Java: Resizeable arrays: Java has resizeable arrays in java.util.* you have one. Now you could say
part of the library not of the language, but where do you draw the line
language and library in Java? Is java.lang.Object Part of the language or
of the library? All classes implicitly inherit from it, so I guess it is
the language. But if the package java.lang.* is part of the language why
java.util.*? At least there should be a note, but I would prefer a "Yes". Associative arrays: Same as above. Templates: Make a note about Java, that 1.5 will have generic types. Compatibility -> direct access to C: What about JNI? This should become a Yes. Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C# code? And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp) don't know where, maybe arrays, as there are your strong typedefs: unsigned types: D: Yes C: Yes C++: Yes C#: Yes Java: No under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes These points might help to choose, which language is the right one for the
you have to do.
Dec 21 2003
In article <bs4m1m$vmh$1 digitaldaemon.com>, Charles says...Actually I cant help myself I have to flame here. Java sucks. Almost all applications that use Java on my machine are un-bearably slow. They often lock my machine, and Im on a 2.4 mhz / 600+ RAM! No other application runs that slowly , not even games. And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits on a floppy ).
I have to agree. That's why I started leds instead of an eclipse pluggin. Ant PS wait for the jokes on the mhz thing...
Dec 21 2003
hehe, sorry Mhz :P C "Ant" <Ant_member pathlink.com> wrote in message news:bs4o9o$1320$1 digitaldaemon.com...In article <bs4m1m$vmh$1 digitaldaemon.com>, Charles says...Actually I cant help myself I have to flame here. Java sucks. Almost all applications that use Java on my machine are un-bearably slow. They often lock my machine, and Im on a 2.4 mhz / 600+ RAM! No other application runs that slowly , not even games. And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits
a floppy ).
I have to agree. That's why I started leds instead of an eclipse pluggin. Ant PS wait for the jokes on the mhz thing...
Dec 21 2003
JOKE: I can see java running slow on either 2.4 mHz or 2.4 MHz. ;-) In article <bs4tcr$1ahc$1 digitaldaemon.com>, Charles says...hehe, sorry Mhz :P C "Ant" <Ant_member pathlink.com> wrote in message news:bs4o9o$1320$1 digitaldaemon.com...In article <bs4m1m$vmh$1 digitaldaemon.com>, Charles says...Actually I cant help myself I have to flame here. Java sucks. Almost all applications that use Java on my machine are un-bearably slow. They often lock my machine, and Im on a 2.4 mhz / 600+ RAM! No other application runs that slowly , not even games. And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits
a floppy ).
I have to agree. That's why I started leds instead of an eclipse pluggin. Ant PS wait for the jokes on the mhz thing...
Dec 21 2003
Charles wrote:Java sucks. Almost all applications that use Java on my machine are un-bearably slow. They often lock my machine, and Im on a 2.4 mhz / 600+ RAM! No other application runs that slowly , not even games.
Hmmmm..... I think you have too much RAM. Thus it takes it too long between collection phases, which then last too long. Wanna share some? I think 128 Kilobytes RAM would be a more than generous match for a 2,4 _MHz_ can ;>>>>>>> And i think my 233 and 600 MHz computers would manage it much better. That's what i would call social equality. ;> Also, be sure to use either IBM Java 1.3.1, or SUN Java 1.4.2 - these are much faster than the others.And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits on a floppy ).
Cubistic minimalistic. Floppyistic.What is it about Java that you like ?
Well, everyone has a VM installed anyway. ;) Compiling foereign applications for one or another platform was never my favorite job. OTOH, i with my slow computers am pretty happy when i don't need to run any of these monsters. -eye
Dec 21 2003
I admit Java does lag a bit but: I think it depends who writes the Java program as to how it performs. I know that I have written an Email application(not a small one) in Java which can appear as fast as outlook express, and never "locks the system". I have 256 megs of ram and a Athlon 2100(not that that matters because they are both on the same machine.) One of Java's greatest advantages is that it is very very easy to find info and tutorials when you are learning, and everyone is pleased to help. Finding a decent tutorial on MFC for example, is like trying to find a virgin over the age of twelve. Phill. "Charles" <sanders-consulting comcast.net> wrote in message news:bs4m1m$vmh$1 digitaldaemon.com...Actually I cant help myself I have to flame here. Java sucks. Almost all applications that use Java on my machine are un-bearably slow. They often lock my machine, and Im on a 2.4 mhz / 600+ RAM! No other application runs that slowly , not even games. And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits
a floppy ). What is it about Java that you like ? C "Matthias Becker" <Matthias_member pathlink.com> wrote in message news:bs4jkq$rv4$1 digitaldaemon.com...About the compairison table: especialy about Java: Resizeable arrays: Java has resizeable arrays in java.util.* you have one. Now you could
it'spart of the library not of the language, but where do you draw the line
language and library in Java? Is java.lang.Object Part of the language
partof the library? All classes implicitly inherit from it, so I guess it is
the language. But if the package java.lang.* is part of the language why
java.util.*? At least there should be a note, but I would prefer a "Yes". Associative arrays: Same as above. Templates: Make a note about Java, that 1.5 will have generic types. Compatibility -> direct access to C: What about JNI? This should become a Yes. Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C#
And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp) don't know where, maybe arrays, as there are your strong typedefs: unsigned types: D: Yes C: Yes C++: Yes C#: Yes Java: No under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes These points might help to choose, which language is the right one for
taskyou have to do.
Dec 24 2003
Disclaimer -- I have worked, and still work, with Java for some purposes/projects, so I'm not anti-Java biased, although I do have a few issues with it. But... Sun maintains in the specs that 'java.lang.*' is part of the language, as well as its subpackages, but everything else is strictly libraries and subject at any second of the day to complete change. I wouldn't call JNI direct access to C. I've used JNI a couple of times, but I don't call having to write my own C wrapper, create and include header (thank goodness there's a tool for that!), etc as direct access. D's direct access is just that. I import std.c.*, or etc.c.*, or c.* and I'm done. Naturally we don't really have a .* yet. I want one, personally. However I do agree it could be Yes with a note. As to debuggers... I wouldn't want to either, but some people will. Just because its listed in the comparison does not mean we're pushing it, its just something that one of us thought of / requested.under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes
I'm not 100% sure in what sense you mean "documentation in the source code" here.under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No
That's being worked on. And actually, I believe there is a way of doing it in Java, but if I remember right its more of a hassle than its worth, hardly something that could be called 'automatic'. I'd have to double-check my claim though.under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes
Just.. eh?under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes
I think this goes back to what is or isn't part of the language. If you go by the standard (as I know it) then Java doesn't have any of this either. If you consider standard and readily-available libraries to be part of the language, then D, C#, and to an extent C++ are all Yes's.under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes
I'm not sure it would really make sense as a language feature in a platform like D. Although, it wouldn't be /too/ difficult to implement using socket libs and delegates (maybe referenced via an assoc-array).These points might help to choose, which language is the right one for the task you have to do.
Hmm. -- C. Sauls -- Invironz
Dec 21 2003
Matthias Becker wrote:About the compairison table: especialy about Java:
I can't see what you so particularly like about Java. That is, there are = one or two good points, but it's definately not the answer when looking=20 for an environment allowing to write fast, lightweight applications=20 conveniently. And hey, don't forget, th=EDs table is for advertising D, not Java! If yo= u=20 want to make Java the center of your world, don't tamper with our table. = Make your own.Resizeable arrays: Java has resizeable arrays in java.util.* you have one.=20
It's a complicated question. :(Associative arrays: Same as above.
Then you should say that about C++ as well.Templates: Make a note about Java, that 1.5 will have generic types.
We all know that. But they are not there yet. Besides, they are purely=20 syntactic, that is they only free of casts in Java. In static languages=20 like C++, D, and Sather, generics also vastly improve execution=20 efficiency. Because these all have value-semantics UDT.Compatibility -> direct access to C: What about JNI? This should become a Yes.
No, this is not direct. It requieres C stubs. As opposed to that, you=20 can directly call C code from lanuguages like C++, Delphi and D. And=20 even Sather. This goes along with having constructs in the language=20 which correspond to those of C.Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C# cod=
Valid point. You could also say that debuggers for Java and C# exist,=20 and are in fact commonly available, so you can use existing debuggers. ;)=And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes
I'm sorry, but it's not in the language. Compliler doesn't do anything=20 with documentation. It's just that there is a standard tool for=20 documenting Java in source. We will also have one.don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp)
That's unfair. Normal floating point is catastrophically different on all platforms in=20 Java. And consider that in D and C++, you can roll your own strict FP=20 implementation, and it will have a native syntax.under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No
Why "no"? What is it anyway? Given an array of class objects, they can=20 be covatiant... I think i misunderstand something.under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes
Under a yes/no table, it stays YES. ;) 1. You can determine fields. 2. You can determine implemented interfaces. Then cast and use. what do you think you need more? Steal other peoples code? Sorry, we're=20 in a compiled world. And that for a reason.under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No
Why is this relevant to performance? And the way it is in C++ is too limited... hardly much different than in = D. I was proposing the type interence type or operator. ;)under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes
Why "no" for D? It will be a standard library feature. For now, library=20 features don't count in this table.under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes
may come. But again, library features.under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes
We had it in DLI. It might make it back into official D. But again: this = is a pure library feature.under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes
Also library features? I don't know.These points might help to choose, which language is the right one for =
you have to do.
You cannot choose a right language by using a checklist. Else OCaml=20 would beat it all. Yes, it is a good language, but... So, i'd say better let this table help choose the language which we feel = is right. ;) -eye
Dec 21 2003
Templates: Make a note about Java, that 1.5 will have generic types.
Not true. It will have partial generics, as will .NET, neither of which will support any type of generic programming other than type-safe containers. No TMP for either of these lumbering technologies ... :(Compatibility -> direct access to C: What about JNI? This should become a Yes.
Quite wrong. JNI makes Java about the furthest removed C-family language from the underlying architecture. Even Sun's own books concede that JNI is an inefficienct technology, and advise large quantisation of functionality in implementing JNI calls.
Dec 21 2003
Some interesting points! "Matthias Becker" <Matthias_member pathlink.com> wrote in message news:bs4jkq$rv4$1 digitaldaemon.com...Resizeable arrays: Java has resizeable arrays in java.util.* you have one.
java.util.VectorNow you could say it's part of the library not of the language, but where do you draw the line
language and library in Java?
Vector is a container class, and has nothing to do with the [] array syntax of Java. [] arrays in Java are not resizeable. Vectors can only contain Objects, not ints, longs, etc. Where I drew the line is if a feature is part of the so-called core language or not, i.e. if it is built in to the semantics of the compiler. The reason for this is that one can build libraries that do just about anything, as Microsoft's COM libraries for doing virtual function calls in C demonstrate. But few would argue that virtual function polymorphism is a feature of C, even though those C COM techniques *do* work.Is java.lang.Object Part of the language or part of the library? All classes implicitly inherit from it, so I guess it is
the language. But if the package java.lang.* is part of the language why
java.util.*?
If the compiler translated [] syntax into references to java.lang.Vector (as it does specially for java.lang.String) I would give it a "yes".Associative arrays: Same as above.
Same as above <g>.Templates: Make a note about Java, that 1.5 will have generic types.
There have been proposals for templates for Java for years. When it ships officially, please remind me and I'll amend the page.Compatibility -> direct access to C: What about JNI? This should become a Yes.
JNI gives C access to Java, not the other way around. JNI cannot call existing C code that has not been rewritten to work with JNI. Try calling printf() from Java <g>, or any C function that has parameters that are pointers, structs, chars, or returns such types. Furthermore, any JNI functions have to be turned into a separate DLL to be callable from Java, they cannot be linked in.Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C# code?
Because some vendors specialize in making debuggers or specialized products that work with the debug output, different debuggers have different strengths and weaknesses, and being free to choose among them is better.And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes
I don't agree. Java's convention of putting documentation in the source code is just that, a convention, not a language feature. Similar things have been done with C, C++, Matthew has done it with D.don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp)
In my opinion and in the opinion of people who write serious numerics code, Java's requirement that intermediate results get truncated to 64 bits is a bug, not a feature. I suspect that is why no other language does it <g>.don't know where, maybe arrays, as there are your strong typedefs: unsigned types: D: Yes C: Yes C++: Yes C#: Yes Java: No
I missed that.under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No
Not sure what covariant arrays are.under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes
I intend to improve this in D, but as yet it is, as you say, very limited.under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No
Do you mean for function templates?under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes
This is a library issue, not a core language issue. Note also that D has strong core arrays and core associative arrays which render many of the container/collection classes in other language libraries irrelevant.under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes
Library routines. I agree that Java, for example, has a very strong and extensive library.under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes
Library.under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes
Library.These points might help to choose, which language is the right one for the
you have to do.
Comparing libraries is important for determining suitability to task, but is not the purpose of the table.
Dec 21 2003
In article <bs5el9$25qq$1 digitaldaemon.com>, Walter says... [...]under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No
Not sure what covariant arrays are.
As far as I know, this means the ability to treat an array of subclasses as if it were an array of superclasses: class B { /* ... */ } class D : B { /* ... */ } class X { void f(B[] ba) { /* ... */ } void g() { D[] d = new D[]; d.length = 1; d[0] = new D; f(d); } } I believe that Java does in fact support this. The difficulty is that it can open a hole in the type system; imagine for example, that f() above added a new B onto the end of the array. Then in g(), the assumption that each element of the array is a D (or subclass of D) is broken. This is explicitly banned in C++ - you would get a syntax error. C# gets around this by checking in array element assignment that the assigned object is indeed a subclass of the actual type of array elements. I am not sure how Java treats this problem, if such a check is made in the element assignment. Ian
Dec 22 2003
"Ian Johnston" <Ian_member pathlink.com> wrote in message news:bs779c$2cto$1 digitaldaemon.com...In article <bs5el9$25qq$1 digitaldaemon.com>, Walter says... [...]under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No
Not sure what covariant arrays are.
As far as I know, this means the ability to treat an array of subclasses
if it were an array of superclasses: class B { /* ... */ } class D : B { /* ... */ } class X { void f(B[] ba) { /* ... */ } void g() { D[] d = new D[]; d.length = 1; d[0] = new D; f(d); } }
Ok, I see.I believe that Java does in fact support this. The difficulty is that it can open a hole in the type system; imagine for example, that f() above added a new B onto the end of the array. Then in g(), the assumption that each element of the array is a D (or subclass of D) is broken.
Yes. I had it implemented in D for a while, and took it out for just that reason.This is explicitly banned in C++ - you would get a syntax error. C# gets around this by checking in array element assignment that the assigned
is indeed a subclass of the actual type of array elements. I am not sure how Java treats this problem, if such a check is made in the element
A runtime check would be necessary.
Dec 22 2003
java.util.ArrayList is resizable. However it cant contain primitives. Although you can use the wrapper classes(Integer, Double, Float etc) Phill. "Walter" <walter digitalmars.com> wrote in message news:bs5el9$25qq$1 digitaldaemon.com...Some interesting points! "Matthias Becker" <Matthias_member pathlink.com> wrote in message news:bs4jkq$rv4$1 digitaldaemon.com...Resizeable arrays: Java has resizeable arrays in java.util.* you have one.
java.util.VectorNow you could say it's part of the library not of the language, but where do you draw the line
language and library in Java?
Vector is a container class, and has nothing to do with the [] array
of Java. [] arrays in Java are not resizeable. Vectors can only contain Objects, not ints, longs, etc. Where I drew the line is if a feature is
of the so-called core language or not, i.e. if it is built in to the semantics of the compiler. The reason for this is that one can build libraries that do just about anything, as Microsoft's COM libraries for doing virtual function calls in C demonstrate. But few would argue that virtual function polymorphism is a feature of C, even though those C COM techniques *do* work.Is java.lang.Object Part of the language or part of the library? All classes implicitly inherit from it, so I guess it is
the language. But if the package java.lang.* is part of the language why
java.util.*?
If the compiler translated [] syntax into references to java.lang.Vector
it does specially for java.lang.String) I would give it a "yes".Associative arrays: Same as above.
Same as above <g>.Templates: Make a note about Java, that 1.5 will have generic types.
There have been proposals for templates for Java for years. When it ships officially, please remind me and I'll amend the page.Compatibility -> direct access to C: What about JNI? This should become a Yes.
JNI gives C access to Java, not the other way around. JNI cannot call existing C code that has not been rewritten to work with JNI. Try calling printf() from Java <g>, or any C function that has parameters that are pointers, structs, chars, or returns such types. Furthermore, any JNI functions have to be turned into a separate DLL to be callable from Java, they cannot be linked in.Compatiblity -> Use existing debuggers: Why should I want to use "existing" debuggers to debug Java oder C#
Because some vendors specialize in making debuggers or specialized
that work with the debug output, different debuggers have different strengths and weaknesses, and being free to choose among them is better.And than I miss some points in your table: under Features: Documentation in the sourcecode: D: No C: No C++: No C#: No Java: Yes
I don't agree. Java's convention of putting documentation in the source
is just that, a convention, not a language feature. Similar things have
done with C, C++, Matthew has done it with D.don't know where, maybe arrays, as there are your strong typedefs: system independet floatinpoint arithmetic: D: No C: No C++: No C#: No Java: Yes (strictfp)
In my opinion and in the opinion of people who write serious numerics
Java's requirement that intermediate results get truncated to 64 bits is a bug, not a feature. I suspect that is why no other language does it <g>.don't know where, maybe arrays, as there are your strong typedefs: unsigned types: D: Yes C: Yes C++: Yes C#: Yes Java: No
I missed that.under Arrays: Covariant arrays: D: No C: No C++: No C#: Yes Java: No
Not sure what covariant arrays are.under OOP: Reflection: D: VERY limited (if this stays a yes/no-table No) C: No C++: No C#: Yes Java: Yes
I intend to improve this in D, but as yet it is, as you say, very limited.under Performance (below Templates <- sould be called generic types) Automatic type deduction: D: No C: No C++: Yes C#: No Java: No
Do you mean for function templates?under Other: Container/Collections: D: No C: No C++: Yes C#: Yes Java: Yes
This is a library issue, not a core language issue. Note also that D has strong core arrays and core associative arrays which render many of the container/collection classes in other language libraries irrelevant.under Other: GUI, Grafic routines, Internet (sokets, ...) D: No C: No C++: No C#: No Java: Yes
Library routines. I agree that Java, for example, has a very strong and extensive library.under Other: Object serialising: D: No C: No C++: No C#: No Java: Yes
Library.under Other: Remote Procedure Call: D: No C: No C++: No C#: Yes Java: Yes
Library.These points might help to choose, which language is the right one for
taskyou have to do.
Comparing libraries is important for determining suitability to task, but
not the purpose of the table.
Dec 24 2003
Phill wrote:java.util.ArrayList is resizable. However it cant contain primitives. Although you can use the wrapper classes(Integer, Double, Float etc) Phill.
Right, but doing so is about as convenient as using multiple inheritance from C. :) -- andy
Dec 24 2003