www.digitalmars.com         C & C++   DMDScript  

D - About "D vs. C/C##/C#/Java"

reply Matthias Becker <Matthias_member pathlink.com> writes:
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:





And than I miss some points in your table:
under Features:
Documentation in the sourcecode:
D: 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

Java: Yes (strictfp)

don't know where, maybe arrays, as there are your strong typedefs:
unsigned types:
D: Yes
C: Yes
C++: Yes

Java: No

under Arrays:
Covariant arrays:
D: No
C: No
C++: No

Java: No

under OOP:
Reflection:
D: VERY limited (if this stays a yes/no-table No)
C: No
C++: No

Java: Yes

under Performance (below Templates <- sould be called generic types)
Automatic type deduction:
D: No
C: No
C++: Yes

Java: No

under Other:
Container/Collections:
D: No
C: No
C++: Yes

Java: Yes

under Other:
GUI, Grafic routines, Internet (sokets, ...)
D: No
C: No
C++: No

Java: Yes

under Other:
Object serialising:
D: No
C: No
C++: No

Java: Yes

under Other:
Remote Procedure Call:
D: No
C: No
C++: No

Java: Yes


These points might help to choose, which language is the right one for the task
you have to do.
Dec 21 2003
next sibling parent "Charles" <sanders-consulting comcast.net> writes:
This assesment sounds very Java biased, I disagree with alot of these ,

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


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:





 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: 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

 Java: Yes (strictfp)

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes

 Java: No

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No

 Java: No

 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No

 Java: Yes

 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes

 Java: No

 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes

 Java: Yes

 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No

 Java: Yes

 under Other:
 Object serialising:
 D: No
 C: No
 C++: No

 Java: Yes

 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No

 Java: Yes


 These points might help to choose, which language is the right one for the


task

 you have to do.
Dec 21 2003
prev sibling next sibling parent reply "Charles" <sanders-consulting comcast.net> writes:
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


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:





 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: 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

 Java: Yes (strictfp)

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes

 Java: No

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No

 Java: No

 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No

 Java: Yes

 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes

 Java: No

 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes

 Java: Yes

 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No

 Java: Yes

 under Other:
 Object serialising:
 D: No
 C: No
 C++: No

 Java: Yes

 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No

 Java: Yes


 These points might help to choose, which language is the right one for the


task

 you have to do.
Dec 21 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
parent reply "Charles" <sanders-consulting comcast.net> writes:
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




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
parent John Reimer <John_member pathlink.com> writes:
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




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
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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
prev sibling parent "Phill" <phill pacific.net.au> writes:
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


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

 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:





code?

 And than I miss some points in your table:
 under Features:
 Documentation in the sourcecode:
 D: 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

 Java: Yes (strictfp)

 don't know where, maybe arrays, as there are your strong typedefs:
 unsigned types:
 D: Yes
 C: Yes
 C++: Yes

 Java: No

 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No

 Java: No

 under OOP:
 Reflection:
 D: VERY limited (if this stays a yes/no-table No)
 C: No
 C++: No

 Java: Yes

 under Performance (below Templates <- sould be called generic types)
 Automatic type deduction:
 D: No
 C: No
 C++: Yes

 Java: No

 under Other:
 Container/Collections:
 D: No
 C: No
 C++: Yes

 Java: Yes

 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: No
 C: No
 C++: No

 Java: Yes

 under Other:
 Object serialising:
 D: No
 C: No
 C++: No

 Java: Yes

 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No

 Java: Yes


 These points might help to choose, which language is the right one for




the

 task

 you have to do.
Dec 24 2003
prev sibling next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
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

 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

 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

 Java: Yes


Just.. eh?


 under Other:
 GUI, Grafic routines, Internet (sokets, ...)
 D: 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 



 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No

 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
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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:



e?


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

 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

 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

 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

 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

 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

 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

 Java: Yes


may come. But again, library features.


 under Other:
 Object serialising:
 D: 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

 Java: Yes


Also library features? I don't know.


 These points might help to choose, which language is the right one for =


the task

 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
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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.Vector


 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?


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


part of

 the language. But if the package java.lang.* is part of the language why


isn't

 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:



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

 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

 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

 Java: No


I missed that.


 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No

 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

 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

 Java: No


Do you mean for function templates?


 under Other:
 Container/Collections:
 D: No
 C: No
 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

 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

 Java: Yes


Library.


 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No

 Java: Yes


Library.


 These points might help to choose, which language is the right one for the


task

 you have to do.


Comparing libraries is important for determining suitability to task, but is
not the purpose of the table.
Dec 21 2003
next sibling parent reply Ian Johnston <Ian_member pathlink.com> writes:
In article <bs5el9$25qq$1 digitaldaemon.com>, Walter says...

[...]


 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No

 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

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
parent "Walter" <walter digitalmars.com> writes:
"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

 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);
 }
 }


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

 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.

A runtime check would be necessary.
Dec 22 2003
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
 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.Vector


 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?


 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


 part of

 the language. But if the package java.lang.* is part of the language why


 isn't

 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:





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

 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

 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

 Java: No


 I missed that.


 under Arrays:
 Covariant arrays:
 D: No
 C: No
 C++: No

 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

 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

 Java: No


 Do you mean for function templates?


 under Other:
 Container/Collections:
 D: No
 C: No
 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

 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

 Java: Yes


 Library.


 under Other:
 Remote Procedure Call:
 D: No
 C: No
 C++: No

 Java: Yes


 Library.


 These points might help to choose, which language is the right one for




the

 task

 you have to do.


 Comparing libraries is important for determining suitability to task, but


is

 not the purpose of the table.
Dec 24 2003
parent Andy Friesen <andy ikagames.com> writes:
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