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

Besides the 2 or 3 items in the unoffical wishlist, "true IN parameters" (i.e. readonly parameters, aka const).

Tom;

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

Power is not an absolute measure. It is a collection of various aspects.
Saying that one thing is more powerful than the other can only be done if that thing is more powerful than the other in *all* aspects. As it currently stands D is more powerful than C++ in most aspects, but that doesn't mean that there are some things that C++ is more powerful.

But this question is a bit biased and misframed. Power is relative and subjective. "Power" can be good but can be bad too. Preprocessor offers more "power", but is it "better"? That's what I mean when I say the question "What does D have to do to have more power than C++?" is a bit tricky.
Even for less infamous features than say, the preprocessor, there is almost always a tradeoff in simplicity. Java is an extreme example of this, where plainness and "shepherdness" are taken to an extreme, and I hear people complain about it all the time (me inclusive), but I also recognize that there are some advantages to this plainness.
_I know_, when reading Java code, that the code isn't doing some weird, obscure, or just unclear thing, because Java is that plain. And that is something I didn't immediately realize after learning/working with Java, but only recently came to value and understand (and I think it might very well be one of the things that were responsible for Java's popularity).
Now, I'm not saying (nor I think) that D should be like Java in that regard, but I think it's something we should keep in mind when trying to shove every feature of other language, especially C++, into D.

Walter already got it right in many things, like designing D without preprocessor, multiple inheritance, or extensive operator overloading. (this last point being brought into discussion here)

There is not much more in C++ that I could think is worth putting in D. ITFI is already planned. struct constructors (and destructors?) perhaps would be good too. As for extensive operator overloading (such as overloading the assignment operator) I'm not so sure would be a good idea, but I'm not knowledgeable enough to make an definite opinion.

But now, and the most important point I want to make, is that if D wants to succeed as a modern language, all should start thinking about and thinking of comparing D with modern languages (Java, C#, and others), and not just with C++!

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote
>> Walter Bright wrote:
>>> "Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote
>>>> Walter Bright wrote:
>>>>
>>>>> What does D have to do to have more power than C++?
>>>>
>>>> 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. 

Defined like that, it's easy: ITI.

Apart from that, IMHO, D is pretty good right now.

Andrew Fedoniouk wrote:
>
> 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.

In my book, this is a Feature of D.

Mike Capp wrote:
> 
> 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
> 
> 
Ye, I'm starting to think that too. I recall Sweeny's article about the Unreal engine and Haskell (still gotta check in more detail how that "pure function" feature works), as well as the recent talk about Cell and the Octopiler. This is definitely something D/Walter should keep an eye on, if not downright start thinking about it.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Sat, 04 Mar 2006 15:02:35 +1100, Walter Bright <newshound@digitalmars.com> wrote:

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

I'm not a C++ person so excuse my ignorance please, but are you saying that fully qualified references in C++ will override private/protected attributes? It does this in D.

//--- foo.d --
private void Foo() { }

// --------------

//--- test.d --
import foo;
void main()
{
   foo.Foo(); // Compiles!
   Foo();  // Doesn't compile.
}

-- 
Derek Parnell
Melbourne, Australia

On Sat, 04 Mar 2006 18:33:29 +1100, Andrew Fedoniouk <news@terrainformatica.com> wrote:



>> Are you suggesting D must have a preprocessor, too?
>
> Don't understand this. Strictly speaking preprocessor
> is not a part of C++.  This way D has also preprocessor - build.exe

You haven't seen the half of it yet <g> There is more powerful macro facilities coming to Build...<watch this space>

-- 
Derek Parnell
Melbourne, Australia

On Sat, 04 Mar 2006 21:18:24 +1100, Johan Granberg <lijat.meREM@OVEgmail.com> wrote:



> 2. as far as I know no way of inporting somthing in a parent directory (as C++ #include "../myheader.hpp")

You can, only its not coded in the source file. Instead you do this via the compiler's "-I" switch.


   //---- test.d ---
   import myheader;

then compile it with ...

   dmd test ../myheader -I..

or
   build test -I..

-- 
Derek Parnell
Melbourne, Australia

In article <dubfs7$95p$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>I am not exactly sure what this means: assign-at-compile-time, assign-once. Could you provide some examples?
>
>I mean something like
>
>struct cow_string {
>   ref_counted_buffer data;
>   void opAssign(cow_string s)
>   {
>       release(data);
>       data = s.data;
>       addref(data);
>   }
>}
>

Since D uses references for all classes, providing opAssign is just way to dangerous to be worth the effort. Lets say you have a class like follows:

class Array
{
private int[] array;
public this()
{
array = new int[10];
}
void opAssign(Array a)
{
for (int i = 0; i < a.length; i++)
array[i] = a[i];
}
}

and lets say I write something like this:
Array a = new Array();
Array b = new Array();
a = b;

I expect a to refer to the same object as b, but no. The author of the Array class copies the data in the overloaded operator, so my code doesn't work for seemingly unknown reasons. This is a problem which would require more than just a "don't do it" warning.

Imho, we just need a standardized "clone" method (like .dup) that can be used
for assigning.

On Sun, 05 Mar 2006 00:25:16 +1100, Ben Phillips <Ben_member@pathlink.com> wrote:

> In article <dubfs7$95p$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>> I am not exactly sure what this means: assign-at-compile-time, assign-once.
>> Could you provide some examples?
>>
>> I mean something like
>>
>> struct cow_string {
>>   ref_counted_buffer data;
>>   void opAssign(cow_string s)
>>   {
>>       release(data);
>>       data = s.data;
>>       addref(data);
>>   }
>> }
>>
>
> Since D uses references for all classes, providing opAssign is just way to
> dangerous to be worth the effort. Lets say you have a class like follows:
>
> class Array
> {
> private int[] array;
> public this()
> {
> array = new int[10];
> }
> void opAssign(Array a)
> {
> for (int i = 0; i < a.length; i++)
> array[i] = a[i];
> }
> }
>
> and lets say I write something like this:
> Array a = new Array();
> Array b = new Array();
> a = b;
>
> I expect a to refer to the same object as b, but no. The author of the Array
> class copies the data in the overloaded operator, so my code doesn't work for
> seemingly unknown reasons. This is a problem which would require more than just
> a "don't do it" warning.
>
> Imho, we just need a standardized "clone" method (like .dup) that can be used
> for assigning.

YES! And a syntax to support opDup().  The "=" means assign, so why not have another operator to mean copy-the-data-not-just-the-reference? ":=" has been suggested but there could be other great ideas.


-- 
Derek Parnell
Melbourne, Australia