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


comparing

 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)



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

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)



 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)







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


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








modules)






 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


 That sounds like a DLL.


Yes, you can consider a DLL as a module. However, the decision of which
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.


 Yes, you can consider a DLL as a module. However, the decision of which
 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


comparing

 D with various other languages.

 www.digitalmars.com/d/comparison.html


... which is of course totally objective and not biased at all ;)

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"?

- 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


 comparing

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


 ... which is of course totally objective and not biased at all ;)


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


.class

 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


a

 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.





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"?


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.


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"?


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.


 I never quite understood what problem inner classes solved.


most of their use in Java code is as anon delegates (via anon classes, which
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"?


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.


 I never quite understood what problem inner classes solved.


 most of their use in Java code is as anon delegates (via anon classes,


which

 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
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


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 )


Essentially two context pointers.
Feb 25 2003
prev sibling next 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


comparing

 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

"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


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


 comparing

 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


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.


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


is

 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
prev sibling parent reply "robert" <robertgalp yahoo.com> writes:

Oriented languages and run on the top of .Net technology. The
syntaxes are very similar to Java and C++. If you know one, then
it takes very little time to learn the other. Here is the link to


http://csharp.net-informations.com

robert.
Apr 18 2012
parent reply "Wes" <ffhighwind hotmail.com> writes:
Agreed, but after looking at D, I see a lot of extremely useful 

Variadic templates, ranges/slices, mixins, here documents 
(wysiwyg strings), nested comments, and CTFE (Compile time 
function execution).

However, I do have to admit that D isn't going to take off very 
soon, for most of the reasons already mentioned.


web frameworks like Java's JSP/Apache.

2. It has Garbage Collection, which seems to turn off C/C++ 

agree that D isn't managed, but a GC gives me a feeling like my 
program will run slower and that the language feels I need some 
training wheels, even if this isn't the case.

3. The developer base is extremely light, as mentioned. My 

the side. I know of a few other languages, but I was never told 
about D other than it exists.

4. I imagine it would be a nightmare linking to OpenGL/DirectX 
without an example.
Jul 26 2012
parent "Wes" <ffhighwind hotmail.com> writes:
There's no edit button. Anyway, old post I realize... still 
applies.
Jul 26 2012