www.digitalmars.com         C & C++   DMDScript  

D - D vs C/C++/C#/Java

reply "Walter" <walter digitalmars.com> writes:
I finally was inspired by Christof's comparison chart, and did one comparing
D with various other languages.

www.digitalmars.com/d/comparison.html
Feb 24 2003
next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
What C types does C++ not support?

And C++ doesn't have modules (unless you count namespaces as modules)

Use Existing Debuggers is misleading.  Until you write out .PDB files you
can't watch locals with, say, Visual Studio, and the name mangling doesn't
get decoded.

Sean


"Walter" <walter digitalmars.com> wrote in message
news:b3csi8$28uo$1 digitaldaemon.com...
 I finally was inspired by Christof's comparison chart, and did one

 D with various other languages.

 www.digitalmars.com/d/comparison.html

Feb 24 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b3dneb$3u0$1 digitaldaemon.com...
 What C types does C++ not support?

Complex and imaginary. I know that very few C compilers support these types (Digital Mars C does!), but still, they are in the C99 standard.
 And C++ doesn't have modules (unless you count namespaces as modules)

C++ and C# have namespaces. I thought a lot about whether they really were modules, as they both missed the boat on what a module was for, but in the end decided they were for the purposes of the comparison. Java has the 'package' concept for modules.
 Use Existing Debuggers is misleading.  Until you write out .PDB files you
 can't watch locals with, say, Visual Studio, and the name mangling doesn't
 get decoded.

True, but it's also true that any debugger that can handle .exe files with cv, line number, global symbol, etc., info in it can debug D programs. I use them myself. None of those debuggers will work with C# or Java even at a primitive level.
Feb 24 2003
parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
 And C++ doesn't have modules (unless you count namespaces as modules)

C++ and C# have namespaces. I thought a lot about whether they really were modules, as they both missed the boat on what a module was for, but in the end decided they were for the purposes of the comparison. Java has the 'package' concept for modules.

IMO neither packages nor namespaces are modules. To me a module is a runtime component that you can deploy/install and undeploy dynamically. Very few languages support this concept natively (mine does :) Java .jar/.war/.ear files come close, but they're only indirectly supported by the language (in terms of library functions/classes to create and read them). Usually you need some kind of external tool (jar or make) to build modules
Feb 25 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b3f86t$i3h$1 digitaldaemon.com...
 And C++ doesn't have modules (unless you count namespaces as modules)



 modules, as they both missed the boat on what a module was for, but in


 end decided they were for the purposes of the comparison. Java has the
 'package' concept for modules.


 component that you can deploy/install and undeploy dynamically. Very few
 languages support this concept natively (mine does :) Java .jar/.war/.ear
 files come close, but they're only indirectly supported by the language

 terms of library functions/classes to create and read them). Usually you
 need some kind of external tool (jar or make) to build modules

That sounds like a DLL.
Feb 25 2003
parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b3fdlp$kp1$2 digitaldaemon.com...
 "Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
 news:b3f86t$i3h$1 digitaldaemon.com...
 And C++ doesn't have modules (unless you count namespaces as




 C++ and C# have namespaces. I thought a lot about whether they really


 modules, as they both missed the boat on what a module was for, but in


 end decided they were for the purposes of the comparison. Java has the
 'package' concept for modules.


 component that you can deploy/install and undeploy dynamically. Very few
 languages support this concept natively (mine does :) Java


 files come close, but they're only indirectly supported by the language

 terms of library functions/classes to create and read them). Usually you
 need some kind of external tool (jar or make) to build modules

That sounds like a DLL.

classes to put in the DLL is not made by the C++ compiler, but usually by some makefile. I develop more in Java and regularly find myself defining classes, packages, and a separate deployment descriptor for my .wars and .ears. Yes I know there are tools for that too, but my point is that it's not built into the compiler. It could be
Feb 25 2003
parent "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b3gtjc$1iqr$1 digitaldaemon.com...
 That sounds like a DLL.

classes to put in the DLL is not made by the C++ compiler, but usually by some makefile. I develop more in Java and regularly find myself defining classes, packages, and a separate deployment descriptor for my .wars and .ears. Yes I know there are tools for that too, but my point is that it's not built into the compiler. It could be

The 'export' attribute in D is used to control what is visible outside of a DLL. I know that's not what you're driving at, but it is a step in that direction.
Feb 25 2003
prev sibling next sibling parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b3csi8$28uo$1 digitaldaemon.com...
 I finally was inspired by Christof's comparison chart, and did one

 D with various other languages.

 www.digitalmars.com/d/comparison.html

In all fairness, there are some remarks to make here: - "standard .obj format" is rather arbitrary, Java generates standard .class format - "Independent of VM" is somewhat related to this ".obj" format - How about "independent of OS"? "Available for all platforms"? - One could argue that having all these features makes D harder to port to a new environment, so "Portable implementation"? - "inline assembler" and "direct access to hardware" sound similar - "inner classes"? - "XXX" { your favorite missing Java/C# feature here ) - large developer community ? - standard ? - ...
Feb 24 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b3dptk$85e$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:b3csi8$28uo$1 digitaldaemon.com...
 I finally was inspired by Christof's comparison chart, and did one

 D with various other languages.
 www.digitalmars.com/d/comparison.html


Absolutely right! <g> I also wanted to make it sort of a quick feature guide, the yes's for D are hyperlinks to the particular feature in the documentation. Interestingly, doing that pointed out some areas of the documentation that badly need improvement (sigh).
 In all fairness, there are some remarks to make here:
 - "standard .obj format" is rather arbitrary, Java generates standard

 format

Inventing a unique format and then declaring it a standard is not quite what I meant by standard .obj formats <g>. While it's true that some non-Java languages have managed to produce .class files, it is insignificant compared with the number of lanugages that generate standard object modules, and hence are linkable together. You're never going to see a C compiler generating .class files. Also, the usual tools (and there are lots of them) that work on .obj files will happilly work on the output of a D compiler.
 - "Independent of VM" is somewhat related to this ".obj" format

Yes, but as you say, only somewhat. There are a lot of interrelated features on that list.
 - How about "independent of OS"?

I think all those languages are independent of the OS (at least in source form).
 "Available for all platforms"?

Ouch <g>.
 - One could argue that having all these features makes D harder to port to

 new environment, so "Portable implementation"?

I don't think it's any harder than any other language to port. For example, porting Java requires porting the VM, which is a massive undertaking. Porting a C++ compiler is a lot of work, even if the output is portable C. (Look at Comeau C++ for an example.) I'd like to get it hooked up to the gcc back end so that D will be available on every platform gcc is.
 - "inline assembler" and "direct access to hardware" sound similar

Inline assembler of course provides direct access to hardware (at least as much as the OS will allow), but D has intrinsic functions for I/O port access, and of course supporting pointers means one can read/write to any memory address. Handy for memory-mapped I/O.
 - "inner classes"?

All the languages support some form of nested classes.
 - "XXX" { your favorite missing Java/C# feature here )

Of course <g>.
 - large developer community ?

Touche.
 - standard ?

True, there won't be a blessing from a standards organization for D for a while.
Feb 24 2003
parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <b3du5t$1s12$1 digitaldaemon.com>, Walter says...

 - "inner classes"?

All the languages support some form of nested classes.

Have to disagree with this one. Java inner classes are not the same as C++ nested classes.
Feb 24 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:b3dv95$1t3i$1 digitaldaemon.com...
 In article <b3du5t$1s12$1 digitaldaemon.com>, Walter says...
 - "inner classes"?


not the same as C++ nested classes.

I never quite understood what problem inner classes solved.
Feb 24 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b3e1tl$sia$1 digitaldaemon.com...
 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:b3dv95$1t3i$1 digitaldaemon.com...
 In article <b3du5t$1s12$1 digitaldaemon.com>, Walter says...
 - "inner classes"?


not the same as C++ nested classes.

I never quite understood what problem inner classes solved.

are non static inner classes {static inner classes are the same [almost] as C++ nested classes}) you return a class that implements a given interface and can access the instance you create it within, this can also be used as a substitue for closures and anon functions one thing this also gives is basically a delegate with state. in C++ you can have delegates its just a struct with a Object pointer and a pointer to member function but delegates in the language make the programmers life easier, and the program less verbose and potentially more robust. inner classes although they can be written in long hand (and with the Java 1.0.2 I used to use classes as func pointers) with innerclasses and anon classes its a lot easier to write. they are also handy within container classes where you want to have object "contained" by some class and allow access to member of the containing instance. although nested classes allow this, you can not use the new in the same way and inherited classes have to explicitly call super and pass the parent in; D: class Container { class Item { private Container parent; // private so its a *final* ref/object in the java sense, this ( Container parent0 ) { if ( (parent = parent0 ) === null ) throw Exception(); } Parent getParent() { return parent; } } protected int someFunc() { ... } } class MyItem : Container.Item { this( Container parent0 ) { super( parent0 ); } int aFunc() { return getParent().someFunc(); } } Container c = new Container(); MyItem foo = new MyItem( c ); Java: public class Container { public class Item { } protected int someFunc() { .... } } public class MyItem extends Container.Item { int aFunc() { return someFunc(); } } Container c = new Container(); MyItem foo = c.new MyItem(); like 80% of highlevel lang features they're syntactic sugar, but that's the point.
Feb 24 2003
parent reply "Walter" <walter digitalmars.com> writes:
I think delegates are a much better approach than inner classes. And sure,
you can emulate them in C++ with a pair, but that gives no type safety.

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b3e6ec$3b9$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:b3e1tl$sia$1 digitaldaemon.com...
 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:b3dv95$1t3i$1 digitaldaemon.com...
 In article <b3du5t$1s12$1 digitaldaemon.com>, Walter says...
 - "inner classes"?


not the same as C++ nested classes.

I never quite understood what problem inner classes solved.


 are non static inner classes {static inner classes are the same [almost]

 C++ nested classes})
 you return a class that implements a given interface and can access the
 instance you create it within,
 this can also be used as a substitue for closures and anon functions

 one thing this also gives is basically a delegate with state.

 in C++ you can have delegates its just a struct with a Object pointer and

 pointer to member function
 but delegates in the language make the programmers life easier, and the
 program less verbose and potentially more robust.

 inner classes although they can be written in long hand (and with the Java
 1.0.2 I used to use classes as func pointers) with innerclasses and anon
 classes its a lot easier to write.

 they are also handy within container classes where you want to have object
 "contained" by some class and allow access to member of the containing
 instance.
 although nested classes allow this, you can not use the new in the same

 and inherited classes have to explicitly call super and pass the parent

 D:
 class Container
 {
      class Item {
         private Container parent; // private so its a *final* ref/object

 the java sense,
         this ( Container parent0 ) { if ( (parent = parent0 ) === null )
 throw Exception(); }
         Parent getParent() { return parent; }
     }
     protected int someFunc() { ... }
 }
 class MyItem : Container.Item {
     this( Container parent0 ) { super( parent0 ); }
     int aFunc() { return getParent().someFunc(); }
 }

 Container c = new Container();
 MyItem foo = new MyItem( c );

 Java:

 public class Container {
     public class Item {
     }
     protected int someFunc() { .... }
 }

 public class MyItem extends Container.Item {
     int aFunc() { return someFunc(); }
 }

 Container c = new Container();
 MyItem foo = c.new MyItem();

 like 80% of highlevel lang features they're syntactic sugar, but that's

 point.

Feb 24 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b3eild$5kb$1 digitaldaemon.com...
 I think delegates are a much better approach than inner classes. And sure,
 you can emulate them in C++ with a pair, but that gives no type safety.

yes and that's exactly why inner classes are great, as I tried to show (with some incorrect Java), and why I mentioned delegates. in Java anon classes are use to replace delegate, closures and func pointer (although that can also be done via the reflections api) but that's only one use or anon classes and inner classes. the java code was crap, an extension to an inner class must be declared within an enclosing class than extends its parent. which is a pain at times consider: public class Container{ public class Item { } } public class Container2 extends Container{ public class Item2 extends Item { } } public class Test { public static void main( String[] args ) { Container c = new Container(); Container2 c2 = new Container2(); c.new Item(); // valid // c.new Item2(); // invalid Item2 must be created with an instance of Container2 c2.new Item(); // valid Container2 isa Container c2.new Item2(); // valid } } due to Java's rules its not valid to write public class MyItem extends Container.Item { ... } if you want a new type of item you have to have a new container too.
Feb 24 2003
parent Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b3eplb$9gd$1 digitaldaemon.com>, Mike Wynn says...
"Walter" <walter digitalmars.com> wrote in message
news:b3eild$5kb$1 digitaldaemon.com...
 I think delegates are a much better approach than inner classes. And sure,
 you can emulate them in C++ with a pair, but that gives no type safety.

yes and that's exactly why inner classes are great, as I tried to show (with some incorrect Java), and why I mentioned delegates. in Java anon classes are use to replace delegate, closures and func pointer (although that can also be done via the reflections api) but that's only one use or anon classes and inner classes. the java code was crap, an extension to an inner class must be declared within an enclosing class than extends its parent. which is a pain at times consider: public class Container{ public class Item { } } public class Container2 extends Container{ public class Item2 extends Item { } } public class Test { public static void main( String[] args ) { Container c = new Container(); Container2 c2 = new Container2(); c.new Item(); // valid // c.new Item2(); // invalid Item2 must be created with an instance of Container2 c2.new Item(); // valid Container2 isa Container c2.new Item2(); // valid } } due to Java's rules its not valid to write public class MyItem extends Container.Item { ... } if you want a new type of item you have to have a new container too.

If your inner class access something specific to an instance of the outer class you need to write "new Outer().new Inner()", because the 'this' reference must be initialized. But if the inner class doesn't access anything of the outer class, you can make it static, like: class Outer { static class Inner { } } And use "new Outer.Inner();".
Feb 25 2003
prev sibling parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
 I think delegates are a much better approach than inner classes. And sure,
 you can emulate them in C++ with a pair, but that gives no type safety.

Both approaches have their use, they are not identical. I thought about this issue some while ago, in terms of function pointers vs. interface implementations. Suppose you have a timer class: interface TimerEvent { void onEvent( Timer& t ); } class Timer { void createTimer( timerCallBack cb, int time ); // some function ptr type void createTimer( TimerEvent& cb, int time ); // interface } when the timer fires, you would either do: a) cb( this ) b) cb.onEvent( this ) The difference is, that the second call passes not only the event but also a context (the instance object implementing 'TimerEvent'). You could achieve the same effect by passing an additional parameter to the function callback, like so: cb( this, context ) In any case, interfaces allow you to specify more than 1 function. So in cases where it makes sense to have a group of related callback functions, an interface is better than a set of otherwise unrelated callback function pointers. But like I said, both can be useful
Feb 25 2003
parent "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b3f8o8$icn$1 digitaldaemon.com...
 The difference is, that the second call passes not only the event but also

 context (the instance object implementing 'TimerEvent'). You could achieve
 the same effect by passing an additional parameter to the function

 like so: cb( this, context )

Essentially two context pointers.
Feb 25 2003
prev sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
Sure, D has all these features that C++ and Java don't have (C is not in
competition for me, it is a lower level language). But are these features so
important ? I have never had big trouble with either C++ or Java. In other
words, D is maybe the best, but it is only 10% better than Java and C++. For
me, it does not make any difference.

Let's not forget that D comes after C++ and Java...most of the OOP theory is
already out there before D. And let's not forget ADA 95: it has all these
features and maybe more.

"Walter" <walter digitalmars.com> wrote in message
news:b3csi8$28uo$1 digitaldaemon.com...
 I finally was inspired by Christof's comparison chart, and did one

 D with various other languages.

 www.digitalmars.com/d/comparison.html

Feb 25 2003
next sibling parent "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:
Excellent point!  The "best" language is not always successful: as D shows,
there are several ways to improve C++; yet the chances of D overtaking C++
are quite remote.

From my point of view; D would be a lot more popular if it integrated with
.NET and Visual Studio .NET.  Look how fast C# has taken off; and a lot of
"legacy" languages are getting a new lease on life by being "ported" to the
CLR.  Microsoft's extensions to C++ (Managed C++) show that you can (almost)
have your cake and eat it too: compile to object code for performance, or to
MSIL for .NET.

   Dan

"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:b3fhat$miu$1 digitaldaemon.com...
 Sure, D has all these features that C++ and Java don't have (C is not in
 competition for me, it is a lower level language). But are these features

 important ? I have never had big trouble with either C++ or Java. In other
 words, D is maybe the best, but it is only 10% better than Java and C++.

 me, it does not make any difference.

 Let's not forget that D comes after C++ and Java...most of the OOP theory

 already out there before D. And let's not forget ADA 95: it has all these
 features and maybe more.

 "Walter" <walter digitalmars.com> wrote in message
 news:b3csi8$28uo$1 digitaldaemon.com...
 I finally was inspired by Christof's comparison chart, and did one

 D with various other languages.

 www.digitalmars.com/d/comparison.html


Feb 25 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:b3fhat$miu$1 digitaldaemon.com...
 Sure, D has all these features that C++ and Java don't have (C is not in
 competition for me, it is a lower level language). But are these features

 important ? I have never had big trouble with either C++ or Java. In other
 words, D is maybe the best, but it is only 10% better than Java and C++.

 me, it does not make any difference.

Improving your productivity by 10% is actually quite a big deal. That's over an extra month a year. If you make $100,000 a year, that's an extra $10,000 in your pocket.
 Let's not forget that D comes after C++ and Java...most of the OOP theory

 already out there before D. And let's not forget ADA 95: it has all these
 features and maybe more.

You're right about OOP theory. D doesn't add much there, where D adds is in things that go beyond OOP like design by contract, closures, etc.
Feb 25 2003