"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4408E84D.3020801@nospam.org...
> Walter Bright wrote:
>> "Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote
>>
>>>>What does D have to do to have more power than C++?
>>>
>>>3) compiler
>>>C++ is available on how many architectures and OSs right now?
>>
>> That's a great characteristic to have, but it isn't a power feature.
>
> Depends on who you ask. Define "power feature".

A feature that is part of the language. Not part of the library, the environment, a third party tool, or an extension.

Mike Capp wrote:
> In article <duab09$1arn$1@digitaldaemon.com>, Walter Bright says...
>> I started a new thread for this:
>>
>> "Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>>> 7. D has all (well, most of) the power of C++
>> I see this often and am a bit perplexed by it. What power do you feel is missing?
> 
<snip>
> 
> Drifting off-topic: in my not-very-original opinion, the killer app for the Next
> Big Systems Programming Language will be the ability to take advantage of
> multi-core hardware. (Almost certainly through some sort of functional approach
> with compiler-verifiable restrictions.) C++ at this point is constitutionally
> incapable of making that leap. It'll be interesting to see whether D can.
> 
> cheers,
> Mike
> 
> 

Some links about multi-core systems.

http://news.com.com/For+Intel,+the+future+has+two+cores/2100-1006_3-5349121.html

http://domino.research.ibm.com/comm/research_projects.nsf/pages/cellcompiler.index.html
http://www.research.ibm.com/journal/sj/451/eichenberger.html

~ Clay

Walter Bright wrote:
> "Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:duak88$1rmh$1@digitaldaemon.com...
> 
>>- Definable assignment/copy semantics for structs.
>>
>>This (combined with end of scope destruction) allows automatic reference
>>counted resource handles, ownership-transferals, and more.
> 
> 
> True, but the need for these are relatively insignificant in D, since D has gc and on_scope. 

Hmm, are there any major use cases for assignment/copy semantics for structs, other than smart pointers? If not, the solution may be to support those explicitly, and be done with it?

Having weak references/pointers would be useful in itself (where weak means it does not prevent GC; of course it should be detectable whether the object is still there). Those, GC, auto and added support for something like shared_ptr and auto_ptr would cover most needs, I think?

As for the original question, I think D is way better.


xs0

"Walter Bright" <newshound@digitalmars.com> wrote in message news:duaqm9$25at$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:duajvt$1re3$1@digitaldaemon.com...
>>> What does D have to do to have more power than C++?
>> 1) C++ has ctors/dtors for stack allocated objects. This problem is known in D as luck of struct ctor/dtor.
>
> The following:
>    auto Foo f = new Foo();
> has ctor/dtor semantics. It isn't allocated on the stack at the moment,
> but there is no semantic reason why it couldn't be. Allocating it on the
> heap is an artifact of dmd, and not of the language.

This is not only about stack allocation but also about the whole
thing:  "- Definable assignment/copy semantics for structs. " / Oskar Linde

There is no way currently in D to implement "guarded variable":

something s = ....;

I cannot write code which will allow to catch
assignment to the variable (concrete memory region if you wish).
Just nothing for that in D at all - variables are naked.

>
>> 2) C++/C both have const.
>>
>> These two are corner stones in C++ (among others).
>> The whole std:: namespace without them is just impossible.
>>
>> I cannot imagine serious *library* design without 'const' for example.
>> Library here means design of robust code used by millions.
>> Phobos imho will never be considered as something rock-solid without
>> 'const'.
>
> I don't really understand this, as many languages have serious libraries without const - such as Java, Python, C#, etc.


1) All these have builtin immutability. For example strings there
are immutable objects. D has no strings so it must have
some features in the language allowing to implement such
objects as a library.

2) D has raw pointers - D is comparable with C/C++ but not with Java.
D will not replace Java in most of cases.  Completely different execution
model.
D in this respect is wery close to C/C++. So D competes with C/C++
but not with Java, Python or C#. And this would be extremely cool if
D can win C++. At least as language for GUI. GUI is most OOP task known.

If you can do something in C/C++ you must
be able to do it in D. This is it.

Postulate: D must include all features C++ has now.

>
>> E.g. I have tried three or four different approaches
>> to reproduce string value type in D. Just no way.
>> Everything what I've seen so far is non-comparable
>> with even std:string and I am yet silent about .NET and Java.
>
> I don't understand what you mean.

Immutable yet effective strings and ranges.

>
>> Big picture: templates (at some extent) and
>> definitely delegates are superior in D than in C++.
>> Other features are more or less elegantly reproducible in C++.
>
> Try doing nested functions elegantly in C++ <g>.

Agree, they are useful. But if used with care.
As soon as you can get address of such inner function
then you are in trouble - result of later call of such function
is non-deterministic.
It is not like in JavaScript where function frames are
valid if referenced somewhere.

Following:

var tt;
function test()
{
  var s0 = "Hello";
  function testtest()
  {
    stdout << s0;
  }
  tt = testtest;
}

test();
tt();

stdout << " World!";

will print in JS (my TIScript here) :

>Hello World!

D will GPF on something like this I guess.


>
>> D used to have clean,consistent and simple syntax and execution model
>> (e.g. GC "from the shelf") but holes 1) and 2) on the bottom of this ship
>> are just shining.
>
> I'm not sure why (1) and (2) didn't exist in the way D used to be.
>

Sorry, two different sentences here:
1) D used to have clean,consistent and simple syntax and execution model
(e.g. GC "from the shelf") - not anymore, IMO. D inner classes for example -
strange halfly implemented Java feature. Scope guards are generally good
but without clear and strict definition of execution model - almost
useless - syntactic
noise. "auto zoo" there too.  Over-qualified 'static' All that
private/protected stuff
is just not finished yet - I was fighting with it in Harmonia - never win.

2)  holes 1) and 2) on the bottom of this ship are just shining.
These are the only features of C++ which D cannot handle at all.

OT: I was proposing readonly ranges and pointers as a simple alternative /
palliative
of problem #1. At least they allow to have lightweight and fast strings as
in Java/C#/Python.

Andrew.

D is better than C++, it just needs some good marketing and a stable (v1.0) compiler.

~ Clay

Walter Bright wrote:
> I started a new thread for this:
> 
> "Mike Capp" <mike.capp@gmail.com> wrote in message news:dua67i$12cr$1@digitaldaemon.com...
>> 7. D has all (well, most of) the power of C++
> 
> I see this often and am a bit perplexed by it. What power do you feel is missing?
> 
> And what about the missing power in C++ - inline assembler, nested functions, contract programming, unit testing, automatic documentation generation, static if, delegates, dynamic closures, inner classes, modules, garbage collection, scope guard?
> 
> What does D have to do to have more power than C++? 
> 

First, let me say, that on balance, D is more powerful than C++ in many ways, and moreso when implicit template etc gets here.  But there are things C++ can do that D can't.  C++ templates and macros can do lots of things.  I agree with not putting C style macros in D; but to be fair, its still powerful, if ugly and unsymmetric.

That said, I wanted to make a few points about Andrew's item #1...

In article <duaqm9$25at$1@digitaldaemon.com>, Walter Bright says...
>
>"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:duajvt$1re3$1@digitaldaemon.com...
>>> What does D have to do to have more power than C++?
>> 1) C++ has ctors/dtors for stack allocated objects. This problem is known in D as luck of struct ctor/dtor.
>
>The following:
>    auto Foo f = new Foo();
>has ctor/dtor semantics. It isn't allocated on the stack at the moment, but there is no semantic reason why it couldn't be. Allocating it on the heap is an artifact of dmd, and not of the language.

Constructors and destructors in C++ have become something much larger than memory cleanup.  They provide a syntactic tool that plays almost the same role as (and complements well with) assertions and contract programming.

For instance, in C++ I can write a mutex class like this (I'll use D notation):

class Mutex {
,  void Lock();
,  void Unlock();
,  bool is_Locked();
};

,class MutexHolder {
,   this(Mutex x);
,
,   void Lock()   { assert(! am_locked); x.Lock();   am_locked = true; }
,   void Unlock() { assert(am_locked);   x.Unlock(); am_locked = false; }
,
,   ~this()
,   {
,       if (am_locked) {
,         assert(my_x.isLocked());
,         my_x.Unlock();
,       }
,   }
,}

If you insert enough assert() tests, you can virtually guarantee that you either
have perfect locking, or die (or hang) at the point of the first usage error.

But the ability to check for correct state, or unlock things, in the destructor is CRUCIAL to this kind of testing.  I worked for a few years in C language file system code that did not have these guarantees.  We were constantly hunting down mysterious hangs.  Doing locking via object lifetime is an excellent way to enforce a kind of whole-system behavior -- that is what's powerful.

But D can't do this kind of thing, AFAIK.  The RIIA works for a class, but I can't nest classes this way.  I can't tell class Foo that it owns Bar in "auto" mode.  I suspect that this would interact badly with "dup" if it was implemented.  I'm not sure what to do about that, unless there is an "opDup()" method (I like this idea, but its another been-discussed idea.).


I think "auto" RIIA is a good start but to get the kind of RIIA that C++ designers want, you would need a minimum of these things too:

1. classes that can own others with an "auto" reference.
2. constructors / destructors for struct.

The second one is not really a requirement, but it almost is, because C++ designers use "lightweight" classes like nuts, particularly for this kind of validity checking.  In C++ adding a class, and using it, costs almost nothing, and in some cases, nothing at all.  D classes are just too heavy for this tiny stuff, and D structs don't have quite enough features.

C++ programmers hate to have to buy the big package - the "Java" like class with all the fixins.  If you write a class in C++ to wrap an integer for some reason, its only 4 bytes.

You can replace a set of integers (this is usually done if you have at least a pair of ints) with "managed" ints or int-pairs, that guarantee some property. If the guarantee is done via debug-mode-only testing, the class really does turn into primitive types in release mode.

Unfortunately, if I have a container of D structs, getting one out and calling a method, copies the value out - I can't set fields via "container[i].x = 5;" the last time I checked.

The frustrating thing (for me) is that D "struct" seems like it can almost do all this now.  Add the constructor / destructor and you have 95% of the "light struct" coverage.

I know this is not a new idea, so I apologize if I'm just repeating complaints.


If these destructors are too hard to do - that's okay.  But I've never been able to figure out where the difficulty is, except that "dup / auto" interaction thing.  I would think its just a matter of patching up the existing destructors for classes containing MutexHolder and Mutex to call delete foo, and adding similar code to function blocks.


I'm also thinking there is one restriction that may make this easier - if the auto class could only be owned by a function scope (as currently) OR another auto class - this would fix the unknown-delete-order issue for auto classes, because it would mean that every auto class knew it was not garbage (and inductively, its children arent garbage) at destruct time.


Lastly - it doesn't have to call "delete" or be a real destructor!  Just some way for the compiler to say "I think this is going out of scope now".  If I had something like auto that called a "cleanUp" method on all sub objects (but especially structs, since other classes may have been collected first) when a scope ends or a class is collected, that would be 99% of the cases.

Kevin

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dub0rk$2eje$1@digitaldaemon.com...
> There is no way currently in D to implement "guarded variable":
>
> something s = ....;
>
> I cannot write code which will allow to catch
> assignment to the variable (concrete memory region if you wish).
> Just nothing for that in D at all - variables are naked.

There are assign-at-compile-time and assign-once variables. What major niche does a guarded variable serve?

>> I don't really understand this, as many languages have serious libraries without const - such as Java, Python, C#, etc.
> 1) All these have builtin immutability. For example strings there
> are immutable objects. D has no strings so it must have
> some features in the language allowing to implement such
> objects as a library.

You can do so by only allowing private functions access to the underlying data. There is no notion of "const-correctness" or const as a type modifier in any of those languages.


> If you can do something in C/C++ you must
> be able to do it in D. This is it.
>
> Postulate: D must include all features C++ has now.

Are you suggesting D must have a preprocessor, too?


>> Try doing nested functions elegantly in C++ <g>.
> Agree, they are useful. But if used with care.
> As soon as you can get address of such inner function
> then you are in trouble - result of later call of such function
> is non-deterministic.

True, one can get into trouble doing that wrong, but it isn't conceptually any different from the following C++ code:

    int *p;
    void foo()
    {    int i;
        p = &i;
    }

    void test()
    {
        ... = *p;
    }

So I would not argue that it is a defect *in comparison to C++*.


> D inner classes for example - strange halfly implemented Java feature.

How so?

> Scope guards are generally good
> but without clear and strict definition of execution model - almost
> useless - syntactic noise.

I strongly disagree there. I thought I had answered your questions about that in the scope guard thread.

> "auto zoo" there too.  Over-qualified 'static' All that private/protected
> stuff
> is just not finished yet - I was fighting with it in Harmonia - never win.

The private/protected stuff works like it does in C++.

> OT: I was proposing readonly ranges and pointers as a simple alternative /
> palliative
> of problem #1. At least they allow to have lightweight and fast strings as
> in Java/C#/Python.

Java/C#/Python do not have lightweight and fast strings. There are some layers of complexity there that are hidden, but are there.

"xs0" <xs0@xs0.com> wrote in message news:duatsu$29vu$1@digitaldaemon.com...
> Walter Bright wrote:
>> "Oskar Linde" <olREM@OVEnada.kth.se> wrote in message news:duak88$1rmh$1@digitaldaemon.com...
>>>- Definable assignment/copy semantics for structs.
>>>
>>>This (combined with end of scope destruction) allows automatic reference counted resource handles, ownership-transferals, and more.
>> True, but the need for these are relatively insignificant in D, since D has gc and on_scope.
> Hmm, are there any major use cases for assignment/copy semantics for structs, other than smart pointers? If not, the solution may be to support those explicitly, and be done with it?

Once one has gc and on_scope, there simply isn't much left for assignment/copy semantics. Not enough to be worth bothering with.

> Having weak references/pointers would be useful in itself (where weak means it does not prevent GC; of course it should be detectable whether the object is still there). Those, GC, auto and added support for something like shared_ptr and auto_ptr would cover most needs, I think?

The on_scope takes care of the need for ***_ptr.

> As for the original question, I think D is way better.

So do I <g>.

Making two clarifications:

In article <dub5c4$2lo2$1@digitaldaemon.com>, Kevin Bealer says...
>
>
>First, let me say, that on balance, D is more powerful than C++ in many ways, and moreso when implicit template etc gets here.  But there are things C++ can do that D can't.  C++ templates and macros can do lots of things.  I agree with not putting C style macros in D; but to be fair, its still powerful, if ugly and unsymmetric.
>

(I was going to go one sentence further, and say "Some of these could probably be done in D with real language features instead of macros" but I couldn't think of anything right now...)

>That said, I wanted to make a few points about Andrew's item #1...
>
>In article <duaqm9$25at$1@digitaldaemon.com>, Walter Bright says...
>>
..
>
>Unfortunately, if I have a container of D structs, getting one out and calling a method, copies the value out - I can't set fields via "container[i].x = 5;" the last time I checked.


I'm remembering this from a long discussion here before.  Since I wrote this I figured out that you can write "foo * opIndex(int i) { return & foo; }" and get the functionality I wanted.

>Kevin

Walter Bright wrote:
> I see this often and am a bit perplexed by it. What power do you feel is missing?

I hardly post anything to the NG, most of the time I just read to see
how D is maturing... but I would like to leave my opinion on this subject:

1. const parameters and member functions

Countless times this saved me. I just can't imagine references being passed in and out of functions without something explicitly saying that the function is expected or not to modify it.

2. implicit function template instantiation

D templates are great, but I miss just this one feature. Perhaps because that I'm too used to C++...

3. array literals and initialization

Don't know how D still don't support this, while we see things like regexes and scope guard comming in... (not that I didn't like those features, but I think that array literals should have came first).

4. library

This is a really weak point in D. STL is not that great, and I can't imagine someone programming in C++ without using some additional library like boost, CC++, Qt, MFC or (that Borland one that I just forgot the name)... But Phobos is simply out-of-question, it was created without project (I'm not a Software Engeneering fan, but at least I understand the importance to design and document before coding).

Also, the standard library should rely on the operating system, not on libc.


Now a bit off-topic, I'm also one of the guys that would like to see true, pure booleans in the language. I don't know why D should inherit such stupid behavior from C/C++, and the excuse that "D should be a sucessor to C" does not get at all... I believe that, before being a sucessor to C, D is a completely *new* language, no one will code in D with just C knowledge. So, if we are going to make things again, lets make them right.

Best regards,
Miles.