www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D - more or less power than C++?

reply "Walter Bright" <newshound digitalmars.com> writes:
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++?
Mar 03 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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?


Something with templates :)
You know the thing that starts with implicit ...

Another power that is missing is the power of standard library.


 
 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?


I agree, all these things are missing from C++.


 
 What does D have to do to have more power than C++? 
 


Fix isues, better std library, added std template library.
Mar 03 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Ivan Senji wrote:

 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?


 
 Something with templates :)
 You know the thing that starts with implicit ...
 
 Another power that is missing is the power of standard library.
 

 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?


 
 I agree, all these things are missing from C++.
 

 What does D have to do to have more power than C++?


 
 Fix isues, better std library, added std template library.
 


Walter, how technologically complex is implicit template instantiation? I think
the consensus
  here is that that is the next feature that everyone wants. I guess my
question is, why did you go through the regex debacle, 
instead of working on ITI.
Mar 03 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Kyle Furlong wrote:

 
 Walter, how technologically complex is implicit template instantiation? 
 I think the consensus
  here is that that is the next feature that everyone wants. I guess my 
 question is, why did you go through the regex debacle, instead of 
 working on ITI.


I doubt it's the next feature /everyone/ wants, and I pretty sure it's 
not the next *task done* that everyone wants.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 04 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Bruno Medeiros wrote:


 Kyle Furlong wrote:

 
 Walter, how technologically complex is implicit template instantiation?
 I think the consensus
  here is that that is the next feature that everyone wants. I guess my
 question is, why did you go through the regex debacle, instead of
 working on ITI.


 
 I doubt it's the next feature /everyone/ wants, and I pretty sure it's
 not the next *task done* that everyone wants.


ITI is important because its absence blocks library development.

/Oskar
Mar 04 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Oskar Linde wrote:

 Bruno Medeiros wrote:
 
 

Kyle Furlong wrote:


Walter, how technologically complex is implicit template instantiation?
I think the consensus
 here is that that is the next feature that everyone wants. I guess my
question is, why did you go through the regex debacle, instead of
working on ITI.


I doubt it's the next feature /everyone/ wants, and I pretty sure it's
not the next *task done* that everyone wants.


 
 
 ITI is important because its absence blocks library development.
 
 /Oskar


libraries don't neet ITI, java has a great library and for long time it 
didn't have anything remotely resembling templates (it does now, but 
that's besides the point).
Mar 04 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Ivan Senji wrote:

 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?


 
 Something with templates :)
 You know the thing that starts with implicit ...


Oh, forgot about that one :-)  But as that seems to be a feature due by 
1.0 I won't count it.


 Another power that is missing is the power of standard library.


That's not a language issue though.  To me, when comparing the relative 
'power' of languages I'd rather just focus on what's possible in the 
language rather than what's been done.


Sean
Mar 03 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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?


C++ has marginal inline asm support, even though no one supports the 
official syntax :-)  Much of the rest I'd consider unimportant as it 
doesn't impact what's possible in D so much as how easy it is to 
accomplish a task or how easy it is to verify that the solution is 
correct.  Some language advantages I think D has over C++ are:

- delegates
- dynamic closures
- scope guard
- volatile (and therefore some support for concurrency)
- synchronized (syntactic sugar but for its implications on language 
support for concurrency, much like volatile)
- inner classes (don't use them, but they are something C++ doesn't do)
- modules
- garbage collection (arguably an advantage as this can be accomplished 
in C++ by overriding global operators new/delete)


 What does D have to do to have more power than C++? 


Better RTTI might be nice perhaps.  But frankly, I think the power is 
already there.  What D needs to do now is prove itself.


Sean
Mar 03 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:

 What does D have to do to have more power than C++? 


 
 Better RTTI might be nice perhaps.


Dynamic module/class loading would be nice as well.  This is one of the 
few features of Java that I wish was present in other languages.  DDL is 
getting there, but that's not quite the same as 'official' support.


Sean
Mar 03 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:duad1t$1ehi$1 digitaldaemon.com...

 C++ has marginal inline asm support, even though no one supports the 
 official syntax :-)


C++ has no inline asm, and there is no official syntax. There's only an 
"asm" keyword. That's it. You can have an official, standards compliant C++ 
compiler which launches all out nuclear assault upon seeing the asm keyword.

Many, but by no means all, C++ compilers implement an inline asm as an 
extension.


 What does D have to do to have more power than C++?


 Better RTTI might be nice perhaps.


D already has better RTTI than C++.
Mar 03 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-03-03:

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


0)
Stockpiles of projects / code - just like C++.

1) standard
A standard instead of a "blah, blah, blah" documentation.
(-> http://www.digitalmars.com/d/float.html)
Enumerating statements in the documentation might be a start.

2) lib
A decent standard lib. Decent isn't necessarily large, but useful,
structured, documented and working.

std.string.tolower/toupper corrupts input:
toupper(tolower("a\u1000B"))

3) compiler
C++ is available on how many architectures and OSs right now?

4) IDE support / tool chain
<no comment>

Granted there are some rough corners in the D feature collection, but I
don't think that they are THE problem.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFECMx03w+/yD4P9tIRAt5rAKCxQtPIdWle0ldbRV/RnDWOujc3xQCfZnYY
PcvX0TnIZCjq5vcYgH1qZwM=
=9HfT
-----END PGP SIGNATURE-----
Mar 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
news:atumd3-ig8.ln1 birke.kuehne.cn...

 What does D have to do to have more power than C++?


 0)
 Stockpiles of projects / code - just like C++.


It can certainly use that, but that isn't a power language feature.


 1) standard
 A standard instead of a "blah, blah, blah" documentation.
 (-> http://www.digitalmars.com/d/float.html)
 Enumerating statements in the documentation might be a start.


I agree that the D documentation is deficient. But that's not a power 
feature, either.


 2) lib
 A decent standard lib. Decent isn't necessarily large, but useful,
 structured, documented and working.


D has many standard library capabilities that C++ doesn't have - like regex, 
for one. Better formatted I/O, for another. The only thing C++ has is STL.


 std.string.tolower/toupper corrupts input:
 toupper(tolower("a\u1000B"))


Bugs are a problem.


 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.


 4) IDE support / tool chain
 <no comment>


Ancilliary support tools are important, but they aren't a power language 
feature, either. None of them are mentioned in the C++ standard.


 Granted there are some rough corners in the D feature collection, but I
 don't think that they are THE problem.


I agree.
Mar 03 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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".
Mar 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Mar 03 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
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.
Mar 04 2006
prev sibling next sibling parent reply AgentOrange <AgentOrange_member pathlink.com> writes:
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++? 


compile time reflection/metaprotocol suport for the win.
Mar 03 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
AgentOrange 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?

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


 
 compile time reflection/metaprotocol suport for the win. 
 
 
 
 
 


Agent, are you a WoW'er?
Mar 03 2006
prev sibling next sibling parent reply Mike Capp <mike.capp gmail.com> writes:
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?


Clean, composable, deterministic resource management. I know C++ is a horrific
Frankenstein's monster of a language, but it allows you to encapsulate resource
management better than anything I've ever seen. I find this frustrating, because
it's not as if D is far off. It might be that auto class members are all that's
needed. But I've ranted this rant many times before on this NG, and nobody else
seems particularly interested, so I won't repeat it here.

Oddly, I don't really agree with most of the other replies. Standard library -
meh. I'm not that impressed by the C++ standard library. It's terribly terribly
clever, but not actually all that useful relative to the price you pay for using
it. IDEs/toolchains - as I just said in another post, none of these offer much
more than a decent text editor, and they're downright embarrassing compared to

the water as a modular programming language. Personally I don't use any C++ libs
that don't come wrapped in C APIs.


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?


Oh, I don't dispute any of that. Nested functions are great. The contract stuff
is pretty good. The unit testing isn't quite the way I'd want it, but I've had a
peek at the Phobos guts and it wouldn't take much to get there. Delegates and
scopeguard are both very nice. Modules and static if, hallelujah. GC, fine as
far as it goes. (The current GC is severely suboptimal, and making it better
will break other stuff. And I still get very annoyed by the claim that GC is
'optional' in D.)

I'm happy to grant that on balance, maturity issues aside, D is more powerful
than C++.

But that's not really the point. If you're trying to convince someone with a
substantial investment in C++ to switch to D, one of the most important
questions you want them to be asking is "What do I have to lose?". The
conclusion you want them to come to is "Nothing". If instead the immediate and
vehement answer is "Well, THIS!", you've suddenly lost a lot of momentum. That's
all I was getting at.

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
Mar 03 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message 
news:duaj45$1pni$1 digitaldaemon.com...

 But that's not really the point. If you're trying to convince someone with 
 a
 substantial investment in C++ to switch to D, one of the most important
 questions you want them to be asking is "What do I have to lose?". The
 conclusion you want them to come to is "Nothing". If instead the immediate 
 and
 vehement answer is "Well, THIS!", you've suddenly lost a lot of momentum. 
 That's
 all I was getting at.


Ok, I understand that point. From one perspective, D makes for a lousy C++ 
compiler. If you try to transliterate traditional style C++ code in D, it 
isn't going to work too well. For example, if you try to use smart pointers, 
D will stymie such efforts. The benefits of D don't become apparent until 
one is willing to write things in a D style.
Mar 03 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
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
Mar 03 2006
prev sibling next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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
Mar 04 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <duaj45$1pni$1 digitaldaemon.com>, Mike Capp says...

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?


Clean, composable, deterministic resource management. I know C++ is a horrific
Frankenstein's monster of a language, but it allows you to encapsulate resource
management better than anything I've ever seen. I find this frustrating, because
it's not as if D is far off. It might be that auto class members are all that's
needed. But I've ranted this rant many times before on this NG, and nobody else
seems particularly interested, so I won't repeat it here.


I'm not sure what you mean by 'auto class members', but if you meant 'classes
instantiated on the stack for which the dtor is automatically called when they
go out of scope', then I agree.


far as it goes. (The current GC is severely suboptimal, and making it better
will break other stuff. And I still get very annoyed by the claim that GC is
'optional' in D.)


I agree that the current GC has performance issues (compared to the mature GC's
of most Java implementations and .NET), but I don't agree that it can't be
improved w/o breaking things. For example, you can have non-moving generational
GC's. Just making the change to some form of partial collection scheme would
make D's GC competitive for most things, I think. And stack-allocated classes
and struct ctors for D would take care of the rest.


But that's not really the point. If you're trying to convince someone with a
substantial investment in C++ to switch to D, one of the most important
questions you want them to be asking is "What do I have to lose?". The
conclusion you want them to come to is "Nothing". If instead the immediate and
vehement answer is "Well, THIS!", you've suddenly lost a lot of momentum. That's
all I was getting at.


They will always have years of (painful) C++ experience to lose ;) So IMHO D
needs to be exceptional in all areas, most importantly great all-around
performance (and this includes the v1.0 reference compiler). As others have
stated (paraphrasing), "the primary reason C++ is still used for so many
projects is because of it's exceptional OOP performance."

I think D is about 95% to the tipping point though.

- Dave
Mar 04 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:duci1c$22ao$1 digitaldaemon.com...

 I'm not sure what you mean by 'auto class members', but if you meant 
 'classes
 instantiated on the stack for which the dtor is automatically called when 
 they
 go out of scope', then I agree.


I think he means "class reference members whose lifetime is determined by 
the lifetime of the object that refers to them.  i.e.

class A
{
    auto B b;

    this()
    {
        b = new B();
    }

    ~this()
    {
        writefln("A dtor");
    }
}

class B
{
    ~this()
    {
        writefln("B dtor");
    }
}

void main()
{
    {
        auto A a = new A()
    }
    writefln("Done");
}

Would print

A dtor
B dtor
Done

(Or maybe the order of the dtors would be different, but the point is that 
the instance of B's lifetime is dependent upon the instance of A's.)
Mar 04 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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++?


1) C++ has ctors/dtors for stack allocated objects. This problem
is known in D as luck of struct ctor/dtor.

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

You can add as many features (really nice ones, btw) on top of
C syntax but these two are so principal and widely used
that without them C++ crowd will not even think about D.
Tons of existing code around them.

For me personally D is definitely more suitable than C++ for e.g.
UI programming in many areas. But not in all.

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.

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

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.

IMHO.

Andrew.
http://terrainformatica.com
Mar 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.


 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 



 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.


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


 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.
Mar 03 2006
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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 




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

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



Andrew.
Mar 03 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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 



 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





layers of complexity there that are hidden, but are there.
Mar 03 2006
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dub64a$2n07$1 digitaldaemon.com...

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

GC as a memory managment is only one from others
possible management technics. refcounting has it own
pluses (as minuses).

To be able to combine both is just good thing -
key to effective technically correct solutions.

C++ gives ref counting and stack allocations (with ctors/dtors),
D gives only GC and stack allocations are not currently implemented there.

Ideal system should have all three. In this case requirement
to effectiveness of GC could be lowered.


 I don't really understand this, as many languages have serious libraries 



 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.


True. This is why they are so uneffective.
String s = somestring.substring(1,4);
will allocate new String object.

You can implement the same approach in D of course
but you will give up ranges ( s[2..$] ) in almost all cases.
To return substring from immutable string you will
always allocate new object. So what is a big reason in D then?



 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?


Don't understand this. Strictly speaking preprocessor
is not a part of C++.  This way D has also preprocessor - build.exe


 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++*.


I am not speaking about defects or something like this here.
I just want to mention that D is a low level language and cannot
be compared with Java or the like.
D - fast but flammable.
Java - fireproof but slow.

Completely different roles and use cases.


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


 How so?


This is again about problems

And last time I've checked: I couldn't reference explicitly members
of outer class like in java:

Outer.this.member = ...;

and there is no restriction on final's in outer function (Java is not 
allocating
function frames, D does the same but not safe)



 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.


Key-point is "without clear and strict definition of execution model".

1) Again, what will happen if on_scope_success will throw?

If it is not safe in principle and there is complex handling required then
you will end up with following:

on_scope_success try { ... } catch(object er) {...}

2) As I said before, implementation of on_scope_success
seems like artificial  to D. In syntax and in implementation.

IMO, it makes real sense to provide facilities to
do things like on_scope_*** by others.

D as a language shall just provide generic mechanisms to do this:
There are mixins already. So why not to extend them?

mixin can mix code in at point of definition. Add another
optional "parameter" to denote where to mix it and
allow anonymous mixins.

mixin atexit { .... }
mixin atfailure { .... }

But I would think more in this direction.



 "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++.


Negative. D has concept of packages and there are problems there.

As far as I recall classes sitting in inner folders of some package have
very strange rules of accessibility to package objects. Classes and their 
members
in particular.


 OT: I was proposing readonly ranges and pointers as a simple alternative 
 / palliative





 layers of complexity there that are hidden, but are there.


Sorry  not "fast as" but "faster than".

Andrew.
Mar 03 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
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
Mar 04 2006
prev sibling next sibling parent reply Ben Phillips <Ben_member pathlink.com> writes:
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.
Mar 04 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
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
Mar 04 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:

 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


Hum, yes!, ideally we could two pairs of operators, each for 
setting/testing the reference/instance_data

=	Assign the reference to an object (currently: = )
==	Test for identity, aka same reference (currently: is )
:=	Copy the object. (nothing similar)
:==	Test for equality, aka same instance data ( currently: == )

This is just the structural idea, the name/symbols of these operators 
could be something other and better (and I think this choice would be a 
very important aspect of this feature).


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 04 2006
parent =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Bruno Medeiros wrote:

 Derek Parnell wrote:

 <Ben_member pathlink.com> wrote:

 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.


 
 Hum, yes!, ideally we could two pairs of operators, each for
 setting/testing the reference/instance_data
 
 =    Assign the reference to an object (currently: = )
 ==    Test for identity, aka same reference (currently: is )
 :=    Copy the object. (nothing similar)
 :==    Test for equality, aka same instance data ( currently: == )
 
 This is just the structural idea, the name/symbols of these operators
 could be something other and better (and I think this choice would be a
 very important aspect of this feature).
 
 


I think these have been proposed few times before. The existence of a
"standardized" dup or clone that can be overridden is extremely
important now that we aren't (thank God) able to overload standard
assignment operator '='. How else would it be possible to 'deep clone'
classes clearly?

I like the ':=' as a copy/assign operator. However currently '==' is
semantically closer to '==' with basic types (ints, chars, ...) because
it compares the contents and not references. I think 'is' and '==' both
should stay and not introduce a new ':==' - it doesn't look very cute on
all editors either.

-- 
Jari-Matti
Mar 05 2006
prev sibling parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Ben Phillips 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.


My suggestion is not to provide opAssign for classes. It is providing
opAssign for structs.

/Oskar
Mar 04 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 My suggestion is not to provide opAssign for classes. It is providing
 opAssign for structs.

 /Oskar


Exactly!
Classes and structures are conceptually different despite
of the fact that they share common notation.

I would suggest also to disable following:

struct mystruct {
   int myfield;
}

mystruct *pms = new mystruct;
mystruct ms;

pms.myfield = 1; // this must be an ERROR!
(*pms).myfield = 1; // this is OK
ms.myfield = 1; // this is OK
Mar 04 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:dubfs7$95p$1 digitaldaemon.com...

 I am not exactly sure what this means: assign-at-compile-time, 
 assign-once.
 Could you provide some examples?


const int a = 3;        // compile time
const int b;            // assign only in constructor


 I mean something like

 struct cow_string {
   ref_counted_buffer data;
   void opAssign(cow_string s)
   {
       release(data);
       data = s.data;
       addref(data);
   }
 }

 GC as a memory managment is only one from others
 possible management technics. refcounting has it own
 pluses (as minuses).

 To be able to combine both is just good thing -
 key to effective technically correct solutions.


You can do refcounting in D - just not by overloading =. To assign, you'd 
call a function rather than using =. Sure, that isn't as slick as 
overloading =, but with gc being available, I doubt there's much use for ref 
counting. Syntactic sugar is a good idea for things that are used a lot, 
it's not as good an idea for things that are rarely used.



 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.


 True. This is why they are so uneffective.
 String s = somestring.substring(1,4);
 will allocate new String object.

 You can implement the same approach in D of course
 but you will give up ranges ( s[2..$] ) in almost all cases.


How so? Why does overloading opSlice not work?



 To return substring from immutable string you will
 always allocate new object.


I don't see why:

struct String
{
    private char[] data;

    ...overload operators here...
}


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


 Are you suggesting D must have a preprocessor, too?


 Don't understand this. Strictly speaking preprocessor
 is not a part of C++.


I could argue the point, but instead I'll toss out trigraphs. Should D 
support trigraphs?



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


 How so?


 This is again about problems

 And last time I've checked: I couldn't reference explicitly members
 of outer class like in java:

 Outer.this.member = ...;

 and there is no restriction on final's in outer function (Java is not 
 allocating
 function frames, D does the same but not safe)


I must have overlooked this, can you point me to a test case?



 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.


 Key-point is "without clear and strict definition of execution model".

 1) Again, what will happen if on_scope_success will throw?


I believe I answered that. Throwing in on_scope is like throwing in a 
destructor or in a finally block. It's a very bad idea, and will probably 
produce a double fault exception. The same issue exists with C++.



 2) As I said before, implementation of on_scope_success
 seems like artificial  to D. In syntax and in implementation.


If by that you mean it is unique to D, then yes, it is. But it is based on 
work done by experts in the field who have attempted to bash C++ into doing 
it, and those experts have reviewed on_scope. They've helped me understand 
what the issues are, and what the solution should look like, and I've 
implemented that solution. So I have a lot of confidence that it is the 
right solution.

I know that it's unfamiliar, and it took me a while to get it.
Mar 04 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:dubfs7$95p$1 digitaldaemon.com...

 1) Again, what will happen if on_scope_success will throw?


 
 I believe I answered that. Throwing in on_scope is like throwing in a 
 destructor or in a finally block. It's a very bad idea, and will probably 
 produce a double fault exception. The same issue exists with C++.


DMD will throw the new exception and the old one will be discarded. 

the the original exception that is retained in .NET, I can't remember 
offhand.  I think the current approach is arguably better than a call to 
terminate, as the C++ approach reduces the general utility of RAII.


 2) As I said before, implementation of on_scope_success
 seems like artificial  to D. In syntax and in implementation.


 
 If by that you mean it is unique to D, then yes, it is. But it is based on 
 work done by experts in the field who have attempted to bash C++ into doing 
 it, and those experts have reviewed on_scope. They've helped me understand 
 what the issues are, and what the solution should look like, and I've 
 implemented that solution. So I have a lot of confidence that it is the 
 right solution.
 
 I know that it's unfamiliar, and it took me a while to get it. 


For what it's worth, Andrei has put all of his articles online at 
http://erdani.org/publications/  His original article on ScopeGuard is 
well worth reading.  A direct link is here: 
http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm


Sean
Mar 04 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:


 Should D support trigraphs?



No. Period!



A language that is 32-bit only (meaning no 16-bit processors), just does 
not need them.

32-bit development is done on 32-bit systems. And today all such systems 
use character sets large enough to _at_least_ support the full USASCII 
character set, if not even Unicode as such.

Trigraphs were [thought to be] needed on 7-bit character set systems in 
"Foreign Countries". But that's history there too by now.

Take it from the trenches! :-)

----

There's another issue that some might start arguing. That's keyboard 
layouts.

On exotic layouts some of the main trigraph "target" characters are 
either impossible or just awkward to type. But in those cases it is 
usual to switch between a "native" and the "us" character layout for 
programming. Single click keyboard layout switching is becoming standard 
issue even outside Linux/Windows/Mac.

The C-family of languages is famous for its choice of several source 
code characters being based on their location on the keyboard. The 
people who'd like trigraphs for layout reasons, are likely to have other 
problems too: where are '* "$&` and some others?

Same problem, but no trigraphs for them.

----

A historical note: They never were more than a make-believe solution for 
"other peoples' problem". In the good Old Days, when we would have 
needed trigraphs, we still didn't use them.


 /*
   A std C program that includes all the defined trigraphs,
   Copied from Wikipedia
 */

 
 int main(void)
 ??< // {
         char n??(5??); // [ and ]
 
         n??(4??) = 'a';
         printf("%c??/n", n??(4??)); // ??/ = \
         
         return ??- 0 ??' 1 ??! 2; // ~, ^ and |
 ??> // }


Now, here's how we used to write the same code, at the time. Granted, 
it's not nice looking to the untrained eye, but using trigraphs (as 
above) would have made the code simply useless.


 /*
   The same as above.
 */
 Łinclude <stdio.h>
 
 int main(void)
 ä
         char Ä5Ĺ;
 
         nÄ4Ĺ = 'a';
         printf("%cÖn", nÄ4Ĺ);
         
         return Ü 0 ü 1 ö 2;
 ĺ


Incidentally, this same technique was usable (and was used) in all of 
the countries where non-US versions of ASCII were in use. It's based on 
the fact that any replacement of a US character was both typeable and 
printable. :-)

----

Last, but not least: the problem trigraphs seek to remedy, is such 
pre-ancient history that it should not even be mentioned with a modern 
programming language.
Mar 05 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:440B99E1.6090000 nospam.org...

 Walter Bright wrote:

 Should D support trigraphs?


 No. Period!


I agree <g>. No danger of that happening.


 A historical note: They never were more than a make-believe solution for 
 "other peoples' problem". In the good Old Days, when we would have needed 
 trigraphs, we still didn't use them.


I know. Trigraphs are a fine example of a solution that was so awful that 
people preferred the problem.


 Last, but not least: the problem trigraphs seek to remedy, is such 
 pre-ancient history that it should not even be mentioned with a modern 
 programming language.


Yup. Trigraphs are not the solution, UTF is.
Mar 06 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:

 A historical note: They never were more than a make-believe solution for 
 "other peoples' problem". In the good Old Days, when we would have 
 needed trigraphs, we still didn't use them.



 Łinclude <stdio.h>

 int main(void)
 ä
         char Ä5Ĺ;

         nÄ4Ĺ = 'a';
         printf("%cÖn", nÄ4Ĺ);
                 return Ü 0 ü 1 ö 2;
 ĺ


 
 Incidentally, this same technique was usable (and was used) in all of 
 the countries where non-US versions of ASCII were in use. It's based on 
 the fact that any replacement of a US character was both typeable and 
 printable. :-)


That's amazing! Thanks for that.

Now that I'm regularly using non-English keyboards regularly, I'm 
realizing how annoyingly English-centric the programming world is.
Example: ctrl-Z for undo. Great for US keyboard, really annoying on a 
German one, where the Z key is in the middle of the keyboard.
And [] {}, backslash and ~ are so hard to type...

I use a US keyboard with a custom layout -- I've defined AltGr to do
Ü etc, but without the stupidity of making "a = ä, which is the default 
"US international" setting. No C programmers involved with that 
decision, I reckon. I find it simply unbelievable that on Windows, the 
default US keyboard layout still had no € key, last time I checked.
Mar 06 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
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
Mar 04 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
Walter,
I know you are a busy person and this might have been missed, so I repeat  
the question for you.

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
Mar 04 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <op.s5wvjbrq6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

Walter,
I know you are a busy person and this might have been missed, so I repeat  
the question for you.

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


Has this been reported as a bug over in D.bugs?

- Dave
Mar 04 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb am 2006-03-05:

 In article <op.s5wvjbrq6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

Walter,
I know you are a busy person and this might have been missed, so I repeat  
the question for you.

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


 Has this been reported as a bug over in D.bugs?


http://dstress.kuehne.cn/www/dstress.html#private_12_B

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFECpUf3w+/yD4P9tIRAsRUAJ9V1GJH/jywtb2qYecacqsJO7zP2QCeJGJ/
7qzapVal6/Jdtkbg/siH8og=
=Ccdp
-----END PGP SIGNATURE-----
Mar 04 2006
next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Dave schrieb am 2006-03-05:

 In article <op.s5wvjbrq6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

 Walter,
 I know you are a busy person and this might have been missed, so I repeat  
 the question for you.

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


 Has this been reported as a bug over in D.bugs?


 
 http://dstress.kuehne.cn/www/dstress.html#private_12_B
 
 Thomas
 
 
 -----BEGIN PGP SIGNATURE-----
 
 iD8DBQFECpUf3w+/yD4P9tIRAsRUAJ9V1GJH/jywtb2qYecacqsJO7zP2QCeJGJ/
 7qzapVal6/Jdtkbg/siH8og=
 =Ccdp
 -----END PGP SIGNATURE-----


Oops, this means I reported the bug twice. :/ Maybe it is time to look 
in that bugzilla.
But anyway, does you assigning it a test case make it an officially 
recognized bug?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 05 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Medeiros schrieb am 2006-03-05:

 Thomas Kuehne wrote:

 
 Dave schrieb am 2006-03-05:

 In article <op.s5wvjbrq6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
 Has this been reported as a bug over in D.bugs?


 
 http://dstress.kuehne.cn/www/dstress.html#private_12_B
 


 Oops, this means I reported the bug twice. :/ Maybe it is time to look 
 in that bugzilla.
 But anyway, does you assigning it a test case make it an officially 
 recognized bug?


Officialy recognized by me :P

DStress isn't associated with Walter, Digitalmars or David.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFECxq93w+/yD4P9tIRApsIAJ0QZtBngNQK8rPAAwecdeP0Nec7lwCaA1bF
pn0PAZb7EOPyzm9kz0EKHPk=
=KbiB
-----END PGP SIGNATURE-----
Mar 05 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <i2hqd3-397.ln1 birke.kuehne.cn>, Thomas Kuehne says...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb am 2006-03-05:

 Has this been reported as a bug over in D.bugs?


http://dstress.kuehne.cn/www/dstress.html#private_12_B

Thomas


Thanks Thomas.

- Dave
Mar 05 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Mar 04 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 D will GPF on something like this I guess.


 In my book, this is a Feature of D.


Are you saying in your book that:
"D will GPF" is a Feature of D?

It is not for book then - it is something to be graffited
on the wall I guess.
Mar 04 2006
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <duckkp$25nc$1 digitaldaemon.com>, Andrew Fedoniouk says...

 D will GPF on something like this I guess.


 In my book, this is a Feature of D.


Are you saying in your book that:
"D will GPF" is a Feature of D?

It is not for book then - it is something to be graffited
on the wall I guess.


In your example, s0 is in a stack frame.  This stack frame is gone when test()
exits.  If you want to fix this, you have to allocate stack frames on the heap.

Allocation of stack frames on the heap incurs a massive performance hit.  This
feature isn't beneficial enough to offset that performance hit.

An alternative would be to allocate stack frames on the heap only if this
behavior is used.  This would probably make things very complex when returning
from / jumping to such functions, which implies another (maybe smaller, maybe
not) performance hit.

Languages like javascript, ruby, take the low performance route.  In D you can
accomplish an equivalent thing by putting the field in question in a class and
calling new.  Then the performance hit is only for this one instance.

Kevin
Mar 04 2006
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
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.



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
Mar 03 2006
next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
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...)




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





 Mar 03 2006



prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:dub5c4$2lo2$1 digitaldaemon.com...

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


Is it really necessary to tell the compiler you own a class member, rather 
than doing it by convention?



 If you write a class in C++ to wrap an integer for some reason,
 its only 4 bytes.


So it is with a D struct.


 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.


debug
{    struct myint
    {
        ... management code ...
    }
}
else
{
    alias int myint;
}


 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.


Can you post an example of this?


 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.


I'll have to think about that.



 Mar 03 2006



 next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


Here is the real life example:

This is C++ wrapper of  DOM element
from my HTMLayout SDK:

It wraps HELEMENT which is in fact reference counted
handler of HTML DOM object.

namespace dom
{
    class element
    {
    protected:
      HELEMENT he;

      void use(HELEMENT h) { he = (HTMLayout_UseElement(h) == HLDOM_OK)? h: 
0; }
      void unuse() { if(he) HTMLayout_UnuseElement(he); he = 0; }
      void set(HELEMENT h) { unuse(); use(h); }

    public:

      element(): he(0) { }
      element(HELEMENT h)    { use(h); }
      element(const element& e) { use(e.he); }
      operator HELEMENT() const { return he; }
      ~element()                { unuse(); }

      element& operator = (HELEMENT h) { set(h); return *this; }
      element& operator = (const element& e) { set(e.he); return *this; }

     ....
  }
}

Usage of this in C++ (code of DOM element event handler, aka "behavior"):

virtual BOOL on_mouse(HELEMENT he, HELEMENT target,
     UINT event_type, POINT pt, UINT mouseButtons, UINT keyboardStates )
    {
        dom::element el = he;
            // 'use' handler - add_ref it to prevent from deletion
        if(!el.is_valid())
             return false;

       dom::element root = el.root(); // get root element (<html>)
       dom::element editbox = root.find_first("input[type='text']");
           // get first edit box using CSS selector
       editbox.text("Hello world!"); // set text to it
       .....
    }

As you may see it is mission critical here to have ctor/dtors/assignment in 
structs.
It is simply not feasible (realisticly) to call manually each time use/unuse 
methods for all objects
in the function. Dead corner.

I really don't know how to design lightweight wrapper for HTMLayout for D. 
<g>

Any real advices?

Andrew.



 Mar 04 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:dubi73$fgh$1 digitaldaemon.com...

 Any real advices?


You can use an auto class, and use a function named "assign()" to do 
assignments. 



 Mar 04 2006



prev sibling  parent reply Kevin Bealer <Kevin_member pathlink.com>  writes:


In article <dubckj$1e4$1 digitaldaemon.com>, Walter Bright says...

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:dub5c4$2lo2$1 digitaldaemon.com...

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


Is it really necessary to tell the compiler you own a class member, rather 
than doing it by convention?


Maybe not necessary... particularly with on_scope_exit() etc.  It's so useful in
C++ relative to C.  That said, it maybe partly just due to my expectations.

I think it boils down to this - in C++ the lifetime of objects can be
influenced by other objects, and as part of algorithms.  And
algorithms and code can be influenced by the lifetime of objects.  In
D the lifetime of objects is influenced by code, but not the other way
around.

Maybe this is just the cost of GC.  It seems like both methods could coexist,
but if enough features are added to D it will weigh as much as C++.  I'll have
to think about whether there are other cases that auto/on_scope can't do.


 If you write a class in C++ to wrap an integer for some reason,
 its only 4 bytes.


So it is with a D struct.


 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.


debug
{    struct myint
    {
        ... management code ...
    }
}
else
{
    alias int myint;
}


I guess what I'm saying is that in C++ you have incremental power over the
functionality.  If you want a virtual table but no operators, you can have it.
Operators but no virtual table, okay.  Each feature is turned on seperately.  In
D there is struct, which has some stuff, and class, which has everything and a
very different personality.

This is starting to sound like a complaint, but actually I like D's way.  All
that syntax is why C++ is so treacherous for anyone who doesn't have a law
degree in it.  The first ten times you write operator=(), you need to look at
the book.  But C++'s a-la carte is powerful, if you want to spend time crafting
the classes.  It's a tradeoff.  D makes a lot of common sense tradeoffs.  In C++
you can build uncopyable classes, inherit from classes that have no code (i.e.
traits programming) etc.  D tosses a lot of semi-obscure flexibility and lets
some of it in through other doors.  Again, good decision, but there are small
ramifications here and there.

I'll just force myself to stop typing now. ;)


 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.


Can you post an example of this?


Yes.  As I mentioned elsewhere, "foo * opIndex(int i)" fixes this.

struct foo {
|    int x = 0;
|    int y = 0;
|    
|    int set_x(int q)
|    {
|        x = q;
|        return x;
|    }
};

struct holds_foo {
|    foo[] foos;
|    
|    // this one fails.
|    foo opIndex(int i)
|    {
|        return foos[i];
|    }
|
|    /+ This one works here.
|    foo * opIndex(int i)
|    {
|        return & foos[i];
|    }+/
};

int floo()
{
|    holds_foo hoho;
|    hoho.foos.length = 10;
|    
|    hoho[0].set_x(11);
|    
|    printf("ho ho %d.\n", hoho[0].x);
|    
|    return 0;
}

int main(char[][] args)
{
|    printf("okay then\n");
|    
|    floo();
|    
|    printf("okay now\n");
|    
|    return 0;
}



 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.


I'll have to think about that.





 Mar 04 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:dubrg5$111g$1 digitaldaemon.com...

 I think it boils down to this - in C++ the lifetime of objects can be
 influenced by other objects, and as part of algorithms.  And
 algorithms and code can be influenced by the lifetime of objects.  In
 D the lifetime of objects is influenced by code, but not the other way
 around.

 Maybe this is just the cost of GC.  It seems like both methods could 
 coexist,
 but if enough features are added to D it will weigh as much as C++.  I'll 
 have
 to think about whether there are other cases that auto/on_scope can't do.


I've thought many times that a great deal of the complexity of C++ comes 
from overloaded assignment, copy ctors, etc. Every class you build 
essentially has to overload these. It winds up adding lots of bloat and 
obfuscation to every class. There's a reason why Java classes always look so 
simple, and C++ ones you have to wade through a lot of stuff just to figure 
out what the point of the class is.


 I guess what I'm saying is that in C++ you have incremental power over the
 functionality.  If you want a virtual table but no operators, you can have 
 it.
 Operators but no virtual table, okay.  Each feature is turned on 
 seperately.  In
 D there is struct, which has some stuff, and class, which has everything 
 and a
 very different personality.


Right. And the argument with C++ is that the incrementalism gives the max 
efficiency possible with each situation. That argument is theoretically 
correct, but in practice, I find it rarely works out that way.


 This is starting to sound like a complaint, but actually I like D's way. 
 All
 that syntax is why C++ is so treacherous for anyone who doesn't have a law
 degree in it.  The first ten times you write operator=(), you need to look 
 at
 the book.


Yes.


 But C++'s a-la carte is powerful, if you want to spend time crafting
 the classes.  It's a tradeoff.  D makes a lot of common sense tradeoffs. 
 In C++
 you can build uncopyable classes, inherit from classes that have no code 
 (i.e.
 traits programming) etc.  D tosses a lot of semi-obscure flexibility and 
 lets
 some of it in through other doors.  Again, good decision, but there are 
 small
 ramifications here and there.

 I'll just force myself to stop typing now. ;)


You're right, and that was a deliberate D design decision. And I'll add to 
that my opinion that all those "small ramifications" do not add up to much 
of anything in real programs. An illustration of that is DMDScript in C++ vs 
D. The D one is faster, even though the C++ was carefully tuned with all 
those small ramifications. They didn't amount to squat in the end because 
the C++ version turned out to be brittle as a result (i.e. resistant to 
change). The D version was much easier to modify to try out different 
approaches, which resulted in it being faster. 



 Mar 04 2006



prev sibling  parent  Carlos Santander <csantander619 gmail.com>  writes:


Kevin Bealer escribió:

 ...
 2. constructors / destructors for struct.


There was some sort of agreement a while ago where Walter asked if the
community 
wanted struct constructors so badly to have them without having destructors.
The 
general position was yes. It hasn't come to life, but that was the agreement 
then. I don't remember Walter's rationale behind not having struct destructors.


 ...
 Kevin
 
 



-- 
Carlos Santander Bernal



 Mar 04 2006



prev sibling next sibling parent reply Oskar Linde <olREM OVEnada.kth.se>  writes:


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?


- Definable assignment/copy semantics for structs.

This (combined with end of scope destruction) allows automatic reference
counted resource handles, ownership-transferals, and more.

- And of course, implicit function template instantiation, but I trust we
will get that soon. :)

/Oskar



 Mar 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


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



 Mar 03 2006



  parent reply xs0 <xs0 xs0.com>  writes:


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



 Mar 03 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


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



 Mar 03 2006



prev sibling next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Walter Bright wrote:


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


Some features that C++ has on the Mac OS X platform are:
- C programming model for SIMD / vectorization (Vec / SSE)
- 64-bit code generation (well, not for x86 yet but anyway)
- access to "Carbon" system headers, loads of old C macros
- the ability to co-exist with "Cocoa", using Objective-C++

Automatic documentation generation and inline assembler
are covered by Doxygen and by GCC, so I won't count those.
(C/C++ has inline assembler for PowerPC, while D doesn't.
I still prefer the output from Doxygen, while Ddoc matures)


Things that *are* possible in D, but needs some more work:
GDB - debugger support for code mangling and data structures
Xcode - full integration with system developer tools and IDE

So besides that templates are broken on "old" Mac OS X 10.3,
it works mostly the same as what C/C++ does on the platform.
(Some of the features requires patching both of GCC and GDB)

One thing that I *do* miss are the array literals, though.
The rest are more of implementation issues, not language.
As a language, I do like D a lot more than what I do C++...

--anders



 Mar 03 2006



prev sibling next sibling parent reply Jeremy <Jeremy_member pathlink.com>  writes:


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


I'm not a power programmer, so I can't talk much about what their needs are --
it sounds like you've already gotten some good input on what could make it more
powerful. However, I think D is already powerful enough to be a big hit.

I'm going to go out on a limb and say Java isn't nearly as powerful as C/C++ is,
but Java is more popular than C++ (according to http://www.tiobe.com/tpci.htm).
It isn't so much about power as it is usability. With Java, you can just grab a
single SDK, and you have just about everything you need -- and it just works.
Comes with a nice IDE with all those cool completion features, and everything is
just rather intuitive. It is easy to find and add external modules, and they are
all auto-loaded. Java is a memory hog, and performance is generally much slower
than C/C++... but Java is so damn usable, they don't mind giving up memory/CPU
time. D is more powerful than Java already, and if it became as usable (or
more), who would need Java? D takes first place... and you have millions of
people writing libraries (in a nice, official format with a great and complete
standard D library) to help push that 'powerful' bar up over even naive C++
programmers. :)

Jeremy



 Mar 03 2006



  parent reply Don Clugston <dac nospam.com.au>  writes:


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

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


 
 I'm not a power programmer, so I can't talk much about what their needs are --
 it sounds like you've already gotten some good input on what could make it more
 powerful. However, I think D is already powerful enough to be a big hit.
 
 I'm going to go out on a limb and say Java isn't nearly as powerful as C/C++
is,
 but Java is more popular than C++ (according to http://www.tiobe.com/tpci.htm).



status. Although I doubt that index is very reliable. :-)

Once D gets IFTI it will be more powerful than C++0x in most respects.
The ability to make lightweight classes is the only other area where I 
think C++ could claim a significant advantage.

I think we'll soon reach the point where D is completely limited by 
libraries and IDE-type issues. Walter will probably get a bit frustrated 
at that point, because he won't be able to do much about it...



 Mar 06 2006



  parent  Sebastián E. Peyrott <as7cf yahoo.com>  writes:


In article <duhcek$d8f$1 digitaldaemon.com>, Don Clugston says...

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

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


 
 I'm not a power programmer, so I can't talk much about what their needs are --
 it sounds like you've already gotten some good input on what could make it more
 powerful. However, I think D is already powerful enough to be a big hit.
 
 I'm going to go out on a limb and say Java isn't nearly as powerful as C/C++
is,
 but Java is more popular than C++ (according to http://www.tiobe.com/tpci.htm).



status. Although I doubt that index is very reliable. :-)

Once D gets IFTI it will be more powerful than C++0x in most respects.
The ability to make lightweight classes is the only other area where I 
think C++ could claim a significant advantage.

I think we'll soon reach the point where D is completely limited by 
libraries and IDE-type issues. Walter will probably get a bit frustrated 
at that point, because he won't be able to do much about it...


"Although I doubt that index is very reliable. :-)"


--
Sebastián.



 Mar 06 2006



prev sibling next sibling parent  clayasaurus <clayasaurus gmail.com>  writes:


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





 Mar 03 2006



prev sibling next sibling parent reply Miles <_______ _______.____>  writes:


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.



 Mar 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Miles" <_______ _______.____> wrote in message 
news:dub8id$2rn3$1 digitaldaemon.com...

 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:


It's good to hear the opinions now and then of the lurkers, too, as they are 
just as important as the prolific posters.


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


They're coming.


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


C++ doesn't have array literals either <g>.


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


I don't find the STL compelling, either, and that's the only library thing 
standard C++ has over libc. Furthermore, large chunks of STL are simply 
irrelevant in D because D has core arrays, strings, and associative arrays.


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


D is meant to be compatible with the C ABI, and that means supporting libc. 
Beyond that, it doesn't make a whole lot of sense to, for example, duplicate 
printf's ability to format floating point numbers. That code is complicated 
but well tested, why not take advantage of it? The libc stuff that isn't 
good is ignored.


 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. 





 Mar 03 2006



  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Walter Bright wrote:

 "Miles" <_______ _______.____> wrote in message 
 news:dub8id$2rn3$1 digitaldaemon.com...

 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:


 
 It's good to hear the opinions now and then of the lurkers, too, as they are 
 just as important as the prolific posters.


In that case here is another lurker opinion.


 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.




You did not answer the above statement and i have seen this repeated all 
over this thread along with destructors in structs. I will not repeat 
all the arguments but to me this is important issues.
If i should rank the most showstoping things in D (from my perspective) 
it would be
1. bugs
2. as far as I know no way of inporting somthing in a parent directory 
(as C++ #include "../myheader.hpp")
3. read only sematics that work as a strong reminder that one is not 
suposed to modify somthing (but can bee subverted by a cast)
4. overlodable assignment and copy constructors.
5. library and other minor issues


 4. library
 ...


 I don't find the STL compelling, either, and that's the only library thing 
 standard C++ has over libc. Furthermore, large chunks of STL are simply 
 irrelevant in D because D has core arrays, strings, and associative arrays.


I agree on this one. So wath is your plan for the D standard library?



 Mar 04 2006



 next sibling parent reply Lars Ivar Igesund <larsivar igesund.net>  writes:


Johan Granberg wrote:

 
 You did not answer the above statement and i have seen this repeated all
 over this thread along with destructors in structs. I will not repeat
 all the arguments but to me this is important issues.
 If i should rank the most showstoping things in D (from my perspective)
 it would be
 1. bugs
 2. as far as I know no way of inporting somthing in a parent directory
 (as C++ #include "../myheader.hpp")


If you have a package hierarchy:

foo/
foo/bar/

and the files
foo/a.d
foo/bar/b.d

you can in your foo/bar/b.d do

import foo.a;

For good measures, name your modules accordingly with the module statemnt:

module foo.a;
----------
module foo.bar.b;
-------------


 3. read only sematics that work as a strong reminder that one is not
 suposed to modify somthing (but can bee subverted by a cast)


Walter has answered on this very many times earlier, and he thinks const
ain't the correct solution. Whether he'll find some other is still an open
question.


 4. overlodable assignment and copy constructors.


Also discussed very many times in the past, Walter's opinion is that they're
bad for you ;)


 5. library and other minor issues


Library is IMHO a community issue, nothing to do with the language, which
was the question here.


 

 4. library
 ...


 I don't find the STL compelling, either, and that's the only library
 thing standard C++ has over libc. Furthermore, large chunks of STL are
 simply irrelevant in D because D has core arrays, strings, and
 associative arrays.


 
 I agree on this one. So wath is your plan for the D standard library?


I do agree that phobos is not the most compelling std library out there,
which is why I encourage helping out with Ares.



 Mar 04 2006



  parent  Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Lars Ivar Igesund wrote:


 3. read only sematics that work as a strong reminder that one is not
 suposed to modify somthing (but can bee subverted by a cast)


 
 Walter has answered on this very many times earlier, and he thinks const
 ain't the correct solution. Whether he'll find some other is still an open
 question.


I know that and try to influence him. :)


 4. overlodable assignment and copy constructors.


 
 Also discussed very many times in the past, Walter's opinion is that they're
 bad for you ;)


:)


 5. library and other minor issues


 
 Library is IMHO a community issue, nothing to do with the language, which
 was the question here.


yers that's why it is a minor issue.


 4. library
 ...


 I don't find the STL compelling, either, and that's the only library
 thing standard C++ has over libc. Furthermore, large chunks of STL are
 simply irrelevant in D because D has core arrays, strings, and
 associative arrays.


 I agree on this one. So wath is your plan for the D standard library?


 
 I do agree that phobos is not the most compelling std library out there,
 which is why I encourage helping out with Ares.


actualy I was asking for Walters plans I think it would bee nice to the 
comunity if he let us know wath to expect from his side.



 Mar 04 2006



prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward>  writes:


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



 Mar 04 2006



  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Derek Parnell 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.
 


Yes it can bee worked around but it's frustrating to have to add a lot 
of -I by hand to the compiler. It realy complicates keeping a simple 
makefile.

An example.

foo/bar/ff.d
foo/gg.d
rr.d

gg.d imports ff.d with the command import bar.ff;
rr.d imports gg.d using import foo.d; but now you cant just compile rr.d 
because the compiler does not find ff.d.

I realise that my orgina formulation was not so clear. actualy it is not 
specificaly import from parent dir I want but import relative to the 
source files dir instead of the dir where the compiler is invoked.

consider the diference of thees c++ includes

#include "foo.h" // includes relative to the sourcefiles dir and if that 
fails in the current path

#include <foo.h> //includes from path

and D's import

import foo; // imports from the search path with the compiler flag -I. added

wath I want is somthing like the first c++ statement ie an include 
relative to the sourcefiles location.



 Mar 04 2006



  parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Johan Granberg wrote:

 Derek Parnell 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.


 
 Yes it can bee worked around but it's frustrating to have to add a lot 
 of -I by hand to the compiler. It realy complicates keeping a simple 
 makefile.
 
 An example.
 
 foo/bar/ff.d
 foo/gg.d
 rr.d
 
 gg.d imports ff.d with the command import bar.ff;
 rr.d imports gg.d using import foo.d; but now you cant just compile rr.d 
 because the compiler does not find ff.d.
 
 I realise that my orgina formulation was not so clear. actualy it is not 
 specificaly import from parent dir I want but import relative to the 
 source files dir instead of the dir where the compiler is invoked.
 
 consider the diference of thees c++ includes
 
 #include "foo.h" // includes relative to the sourcefiles dir and if that 
 fails in the current path
 
 #include <foo.h> //includes from path
 
 and D's import
 
 import foo; // imports from the search path with the compiler flag -I. 
 added
 
 wath I want is somthing like the first c++ statement ie an include 
 relative to the sourcefiles location.



The *correct* way of doing it is naming your modules according to the 
directory structure.


----- foo/bar/ff.d ----
module foo.bar.ff;
//rest of file

----- foo/gg.d --------
module foo.gg;
//test of file

----- rr.d ------------
module rr;
//rest of file

now if you want to import rr.d from foo.bar.ff

-----foo/bar/ff.d----
module foo.bar.ff;
import rr;
//rest of file

I think this should work!
When you compile, you have to make sure that the working directory is 
where rr.d resides.



 Mar 04 2006



  parent reply Sebastián E. Peyrott <as7cf yahoo.com>  writes:


In article <dudpqv$1otp$1 digitaldaemon.com>, Hasan Aljudy says...

The *correct* way of doing it is naming your modules according to the 
directory structure.


----- foo/bar/ff.d ----
module foo.bar.ff;
//rest of file

----- foo/gg.d --------
module foo.gg;
//test of file

----- rr.d ------------
module rr;
//rest of file

now if you want to import rr.d from foo.bar.ff

-----foo/bar/ff.d----
module foo.bar.ff;
import rr;
//rest of file

I think this should work!
When you compile, you have to make sure that the working directory is 
where rr.d resides.


I agree. I think there's no compelling reason to allow referencing files
according to the relative path of the current module. In fact, I think the
current behaviour enforces a more organized development structure.

--
Sebastián.



 Mar 04 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Sebastián E. Peyrott" <as7cf yahoo.com> wrote in message 
news:dudqs0$1qkh$1 digitaldaemon.com...

 I agree. I think there's no compelling reason to allow referencing files
 according to the relative path of the current module. In fact, I think the
 current behaviour enforces a more organized development structure.


I agree as well. For example, in Phobos, the std.* modules, when they import 
other std modules, use:

    import std.foo;

as opposed to:

    import foo;

which is what it would be if relative imports were done. 



 Mar 05 2006



prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Johan Granberg" <lijat.meREM OVEgmail.com> wrote in message 
news:dubpge$u3r$1 digitaldaemon.com...

 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.




 You did not answer the above statement and i have seen this repeated all 
 over this thread along with destructors in structs.


Because the const thing has been endlessly thrashed about in other threads.


 I will not repeat all the arguments but to me this is important issues.
 If i should rank the most showstoping things in D (from my perspective) it 
 would be
 1. bugs
 2. as far as I know no way of inporting somthing in a parent directory (as 
 C++ #include "../myheader.hpp")


The -I compiler switch can specify the "root" from whence all the packages 
derive.


 3. read only sematics that work as a strong reminder that one is not 
 suposed to modify somthing (but can bee subverted by a cast)
 4. overlodable assignment and copy constructors.
 5. library and other minor issues


 4. library
 ...


 I don't find the STL compelling, either, and that's the only library 
 thing standard C++ has over libc. Furthermore, large chunks of STL are 
 simply irrelevant in D because D has core arrays, strings, and 
 associative arrays.


 I agree on this one. So wath is your plan for the D standard library?


Keep incrementally improving it. Is there anything in particular you feel is 
missing? 



 Mar 04 2006



  parent reply Kevin Bealer <Kevin_member pathlink.com>  writes:


In article <ducnmj$rv$2 digitaldaemon.com>, Walter Bright says...

"Johan Granberg" <lijat.meREM OVEgmail.com> wrote in message 
news:dubpge$u3r$1 digitaldaemon.com...

 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.




 You did not answer the above statement and i have seen this repeated all 
 over this thread along with destructors in structs.


Because the const thing has been endlessly thrashed about in other threads.


 I will not repeat all the arguments but to me this is important issues.
 If i should rank the most showstoping things in D (from my perspective) it 
 would be
 1. bugs
 2. as far as I know no way of inporting somthing in a parent directory (as 
 C++ #include "../myheader.hpp")


The -I compiler switch can specify the "root" from whence all the packages 
derive.


 3. read only sematics that work as a strong reminder that one is not 
 suposed to modify somthing (but can bee subverted by a cast)
 4. overlodable assignment and copy constructors.
 5. library and other minor issues


 4. library
 ...


 I don't find the STL compelling, either, and that's the only library 
 thing standard C++ has over libc. Furthermore, large chunks of STL are 
 simply irrelevant in D because D has core arrays, strings, and 
 associative arrays.


 I agree on this one. So wath is your plan for the D standard library?


Keep incrementally improving it. Is there anything in particular you feel is 
missing? 


One thing I miss a little is continuously sorted collections, as with a tree or
similar.  The primary reason is to add elements, print them in order, keep
adding, etc.

It seems like this could be done in D fairly simply, since associative arrays
(as I understand) already include a binary tree if the hash value fails.  So by
defining a hash foo.toHash() that returns the same for all elements, int[foo]
could be used as a tree.

The main thing missing would seem to be access to this - i.e. finding ranges
without iterating the entire collection.  As in lower_bound / upper_bound in C++
or some variant of foreach-like functionality.

foo[char[]] x;
x.useHash = false; // disables hashing - only valid on an empty array

foreach(char[] k, foo v; x) {
// print all elements in order
}

// advanced version - associative array slicing

foreach(char[] k, foo v; x["allen".."burns") {
// print all elements from allen up to (but not including) burns, in order
}

x.least // lowest key
x.most // highest key

x.least_gt("abc"); // least element greater than "abc"

x[x.least] // element with lowest key

x[x.least_gt("abc")] // first element with key >= "abc"

Kevin



 Mar 04 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:ducrhk$6j3$1 digitaldaemon.com...

 foreach(char[] k, foo v; x) {
 // print all elements in order
 }


The wc example shows how to print the elements of an associative array in 
order. 



 Mar 04 2006



  parent reply Kevin Bealer <Kevin_member pathlink.com>  writes:


In article <dud1s8$idk$1 digitaldaemon.com>, Walter Bright says...

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:ducrhk$6j3$1 digitaldaemon.com...

 foreach(char[] k, foo v; x) {
 // print all elements in order
 }


The wc example shows how to print the elements of an associative array in 
order. 


Sometimes its good to be able to get the least element, greatest element, and so
on, quicker than O(N).  PQs can do one or the other, but it's hard to do lookups
by value.  This is a low priority for most people I suspect.

Kevin



 Mar 04 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:dud3g6$lm3$1 digitaldaemon.com...

 Sometimes its good to be able to get the least element, greatest element, 
 and so
 on, quicker than O(N).  PQs can do one or the other, but it's hard to do 
 lookups
 by value.  This is a low priority for most people I suspect.


Sometimes, yes. D's AA implementation, however, will work satisfactorilly 
for 98% of the cases. There's always some case that needs a special setup, 
and for that, one will need to use a custom user defined type. That's true 
of the STL as well. 



 Mar 04 2006



prev sibling next sibling parent reply Ben Phillips <Ben_member pathlink.com>  writes:


In article <dubpge$u3r$1 digitaldaemon.com>, Johan Granberg says...

 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.




You did not answer the above statement and i have seen this repeated all 
over this thread along with destructors in structs.


A method can explicitly say that it will modify a reference by using "out" and
"inout".

I've never cared much for const member methods, so I'm confused as to how a lack
of them can cause such a problem. Can you give an example?



 Mar 04 2006



  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Ben Phillips wrote:

 In article <dubpge$u3r$1 digitaldaemon.com>, Johan Granberg says...

 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.




 You did not answer the above statement and i have seen this repeated all 
 over this thread along with destructors in structs.


 
 A method can explicitly say that it will modify a reference by using "out" and
 "inout".
 
 I've never cared much for const member methods, so I'm confused as to how a
lack
 of them can cause such a problem. Can you give an example?
 
 


It is not const methods so much as const in parameters.

class A
{
  int bar=1;//bar should bee read only
}

void foo(in i a)//I want a to bee readonly
{
     i.bar=2;//here the value should not be writable but since a is
             //a reference it is
}

A a=new A;//bar is 1
foo(a);
print(a.bar);//prints 2

It is not so very usefull in smal examples but if you have a large 
program and do that by mistake it could cause a bug. Basicaly it is a 
message from the writer of a class to it's users of how member are to 
bee used, and aditionaly it has compiler suport to catch typos and 
mistakes, if a user realy want to change the data against the orginal 
authors recomendations he can use a explicit cast.



 Mar 04 2006



 next sibling parent reply Tyro <ridimz_at yahoo.dot.com>  writes:


Johan Granberg wrote:

 Ben Phillips wrote:
 

 In article <dubpge$u3r$1 digitaldaemon.com>, Johan Granberg says...


 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.




 You did not answer the above statement and i have seen this repeated 
 all over this thread along with destructors in structs.


 A method can explicitly say that it will modify a reference by using 
 "out" and
 "inout".

 I've never cared much for const member methods, so I'm confused as to 
 how a lack
 of them can cause such a problem. Can you give an example?


 It is not const methods so much as const in parameters.
 
 class A
 {
  int bar=1;//bar should bee read only
 }


And why exactly should this be read only again? Maybe my primitive brain 
is completely underdeveloped rendering me incapable of grasping the 
concept. Nonetheless, it strikes me as only natural that if one wants 
something to be read only one would simply identify it as such:

class A
{
   const int bar=1; // bar IS read only
}

but maybe I'm missing something here. Reading on!!!


 void foo(in i a)//I want a to bee readonly
 {
     i.bar=2;//here the value should not be writable but since a is
             //a reference it is
 }

 A a=new A;//bar is 1
 foo(a);
 print(a.bar);//prints 2


Oh, I see, you want the in parameter to treat it as if it were read 
only. Rightly so. One should not be able to modify an "in" parameter 
(reference or otherwise). It is the implied behavior when using the in 
keyword, there it is only reasonable to expected it. I do not think this 
is a problem with the implementation of const however, but rather a 
glaring defect in the implementation of "in".


 It is not so very usefull in smal examples but if you have a large 
 program and do that by mistake it could cause a bug. Basicaly it is a 
 message from the writer of a class to it's users of how member are to 
 bee used, and aditionaly it has compiler suport to catch typos and 
 mistakes, if a user realy want to change the data against the orginal 
 authors recomendations he can use a explicit cast.


Andrew



 Mar 04 2006



  parent  "Regan Heath" <regan netwin.co.nz>  writes:


On Sat, 04 Mar 2006 23:18:00 -0500, Tyro <ridimz_at yahoo.dot.com> wrote:

 Oh, I see, you want the in parameter to treat it as if it were read  
 only. Rightly so. One should not be able to modify an "in" parameter  
 (reference or otherwise). It is the implied behavior when using the in  
 keyword, there it is only reasonable to expected it. I do not think this  
 is a problem with the implementation of const however, but rather a  
 glaring defect in the implementation of "in".


One cannot modify an "in" parameter. All "in" parameters are copied in, in  
other words the parameter inside the function is always a copy of the  
variable passed. The 'key' issue here is realising what you're passing.  
When you pass a 'reference' the variable is the 'reference' itself, _not_  
the data to which it refers. Therefore the 'reference' is what is copied  
in and what is protected by "in". "in" makes no guarantee to protect the  
data to which that reference refers.

I think we can all agree that having some way to declare a function is not  
going to perform any sort of write operation using a passed reference and  
having the compiler protect this accidentally happening would be a good  
thing. The problem is how to achieve that, see the many previous "const"  
and "readonly" threads for a detailed discussion of why it's not so simple  
to solve.

Regan



 Mar 05 2006



prev sibling  parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Johan Granberg wrote:

 Ben Phillips wrote:
 

 In article <dubpge$u3r$1 digitaldaemon.com>, Johan Granberg says...


 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.




 You did not answer the above statement and i have seen this repeated 
 all over this thread along with destructors in structs.


 A method can explicitly say that it will modify a reference by using 
 "out" and
 "inout".

 I've never cared much for const member methods, so I'm confused as to 
 how a lack
 of them can cause such a problem. Can you give an example?


 It is not const methods so much as const in parameters.
 
 class A
 {
  int bar=1;//bar should bee read only
 }
 
 void foo(in i a)//I want a to bee readonly
 {
     i.bar=2;//here the value should not be writable but since a is
             //a reference it is
 }
 
 A a=new A;//bar is 1
 foo(a);
 print(a.bar);//prints 2
 
 It is not so very usefull in smal examples but if you have a large 
 program and do that by mistake it could cause a bug. Basicaly it is a 
 message from the writer of a class to it's users of how member are to 
 bee used, and aditionaly it has compiler suport to catch typos and 
 mistakes, if a user realy want to change the data against the orginal 
 authors recomendations he can use a explicit cast.


Maybe I'm missing something, but why don't you just mak A.bar private?



 Mar 05 2006



  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Hasan Aljudy wrote:

 It is not const methods so much as const in parameters.

 class A
 {
  int bar=1;//bar should bee read only
 }

 void foo(in i a)//I want a to bee readonly
 {
     i.bar=2;//here the value should not be writable but since a is
             //a reference it is
 }

 A a=new A;//bar is 1
 foo(a);
 print(a.bar);//prints 2

 It is not so very usefull in smal examples but if you have a large 
 program and do that by mistake it could cause a bug. Basicaly it is a 
 message from the writer of a class to it's users of how member are to 
 bee used, and aditionaly it has compiler suport to catch typos and 
 mistakes, if a user realy want to change the data against the orginal 
 authors recomendations he can use a explicit cast.


 
 Maybe I'm missing something, but why don't you just mak A.bar private?


Because then i would have to call a method to read bar and that would 
bee inefective. I know it is no big deal when bar is only an ont but 
when larger structures is copied the overhead can bee a significant 
slowdown. also privat does not protect from misstakes in the same class 
but if you do a cast you will think about why it is readonly in the 
first place.



 Mar 06 2006



  parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Johan Granberg wrote:

 Hasan Aljudy wrote:
 

 It is not const methods so much as const in parameters.

 class A
 {
  int bar=1;//bar should bee read only
 }

 void foo(in i a)//I want a to bee readonly
 {
     i.bar=2;//here the value should not be writable but since a is
             //a reference it is
 }

 A a=new A;//bar is 1
 foo(a);
 print(a.bar);//prints 2

 It is not so very usefull in smal examples but if you have a large 
 program and do that by mistake it could cause a bug. Basicaly it is a 
 message from the writer of a class to it's users of how member are to 
 bee used, and aditionaly it has compiler suport to catch typos and 
 mistakes, if a user realy want to change the data against the orginal 
 authors recomendations he can use a explicit cast.



 Maybe I'm missing something, but why don't you just mak A.bar private?


 
 
 Because then i would have to call a method to read bar and that would 
 bee inefective. 


You know, CPUs are fast now a days, a single function call is not 
"ineffective".


I know it is no big deal when bar is only an ont but 
 when larger structures is copied the overhead can bee a significant 
 slowdown. 


Objects don't get copied when they are passed to functions ..


 also privat does not protect from misstakes in the same class 
 but if you do a cast you will think about why it is readonly in the 
 first place.


I don't understand what you mean.



 Mar 06 2006



  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Hasan Aljudy wrote:

 Because then i would have to call a method to read bar and that would 
 bee inefective. 


 
 You know, CPUs are fast now a days, a single function call is not 
 "ineffective".


That argument does not hold if you are in a tight loop it will matter.


 I know it is no big deal when bar is only an ont but when larger 
 structures is copied the overhead can bee a significant slowdown. 


 
 Objects don't get copied when they are passed to functions ..


But large structs does and if you want an objects variabls to bee 
unchanged you muse use dup.


 also privat does not protect from misstakes in the same class but if 
 you do a cast you will think about why it is readonly in the first place.


 
 I don't understand what you mean.


That readonly is for both the occasions when you misspell somthing and 
refer to the wrong variable. (hard to find bug) and to present a user of 
your library with a contract of use.



 Mar 06 2006



 next sibling parent reply Tyler Knott <Tyler_member pathlink.com>  writes:


In article <dui6d5$2134$1 digitaldaemon.com>, Johan Granberg says...

Hasan Aljudy wrote:

 Because then i would have to call a method to read bar and that would 
 bee inefective. 


 
 You know, CPUs are fast now a days, a single function call is not 
 "ineffective".


That argument does not hold if you are in a tight loop it will matter.


Why not just use a method to return a pointer to the private member and use that
within your hypothetical tight loop, then use proper get/set methods when CPU
time is not important?  It shouldn't use any more CPU time than referencing the
member directly (because both the object reference and pointer need to be
deferenced before what they referenced can be used through them).  Or what about
copying the member to a temporary variable in the scope above the loop's, using
the temporary variable within the loop, then setting the member to the value of
the temporary var when the loop is finished?  (And even if there is an exception
thrown and you still want the member to be set to the same value as the temp
var, you could use on_scope_failure to call the set method in that event.)



 Mar 06 2006



  parent  Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Tyler Knott wrote:

 In article <dui6d5$2134$1 digitaldaemon.com>, Johan Granberg says...

 Hasan Aljudy wrote:

 Because then i would have to call a method to read bar and that would 
 bee inefective. 


 You know, CPUs are fast now a days, a single function call is not 
 "ineffective".


 That argument does not hold if you are in a tight loop it will matter.


 
 Why not just use a method to return a pointer to the private member and use
that
 within your hypothetical tight loop, then use proper get/set methods when CPU
 time is not important?  It shouldn't use any more CPU time than referencing the
 member directly (because both the object reference and pointer need to be
 deferenced before what they referenced can be used through them).  Or what
about
 copying the member to a temporary variable in the scope above the loop's, using
 the temporary variable within the loop, then setting the member to the value of
 the temporary var when the loop is finished?  (And even if there is an
exception
 thrown and you still want the member to be set to the same value as the temp
 var, you could use on_scope_failure to call the set method in that event.)
 
 


I'm avare you can do that but I see it as a ugly workaround rather than 
a solution.



 Mar 07 2006



prev sibling  parent  Ben Phillips <Ben_member pathlink.com>  writes:


In article <dui6d5$2134$1 digitaldaemon.com>, Johan Granberg says...

Hasan Aljudy wrote:

 Because then i would have to call a method to read bar and that would 
 bee inefective. 


 
 You know, CPUs are fast now a days, a single function call is not 
 "ineffective".


That argument does not hold if you are in a tight loop it will matter.


A one-line return method is going to get inlined by the compiler, so it is
unlikely you will see any performance difference at all.



 Mar 07 2006



prev sibling  parent reply Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Johan Granberg wrote:

 Walter Bright wrote:

 "Miles" <_______ _______.____> wrote in message 
 news:dub8id$2rn3$1 digitaldaemon.com...

 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:


 It's good to hear the opinions now and then of the lurkers, too, as 
 they are just as important as the prolific posters.


 
 In that case here is another lurker opinion.
 

 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.




 
 You did not answer the above statement and i have seen this repeated all 
 over this thread along with destructors in structs. I will not repeat 
 all the arguments but to me this is important issues.
 If i should rank the most showstoping things in D (from my perspective) 
 it would be
 1. bugs
 2. as far as I know no way of inporting somthing in a parent directory 
 (as C++ #include "../myheader.hpp")
 3. read only sematics that work as a strong reminder that one is not 
 suposed to modify somthing (but can bee subverted by a cast)
 4. overlodable assignment and copy constructors.
 5. library and other minor issues
 

 4. library
 ...


 I don't find the STL compelling, either, and that's the only library 
 thing standard C++ has over libc. Furthermore, large chunks of STL are 
 simply irrelevant in D because D has core arrays, strings, and 
 associative arrays.


 
 I agree on this one. So wath is your plan for the D standard library?


I remembered another thing that i would like as well. This probably is 
omited by design but I would realy like to write member funktion 
definitions outside of their class. This way i can get the class 
definition down to a single page and that helps when trying to read the 
code later on as you can easily see the properities of a class at a glance.



 Mar 06 2006



 next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Johan Granberg" <lijat.meREM OVEgmail.com> wrote in message 
news:duhntk$1a51$1 digitaldaemon.com...

 I remembered another thing that i would like as well. This probably is 
 omited by design but I would realy like to write member funktion 
 definitions outside of their class. This way i can get the class 
 definition down to a single page and that helps when trying to read the 
 code later on as you can easily see the properities of a class at a 
 glance.


You can do that now by creating a separate ".di" file which does not contain 
the function bodies. See the -H switch. 



 Mar 07 2006



  parent  Johan Granberg <lijat.meREM OVEgmail.com>  writes:


Walter Bright wrote:

 "Johan Granberg" <lijat.meREM OVEgmail.com> wrote in message 
 news:duhntk$1a51$1 digitaldaemon.com...

 I remembered another thing that i would like as well. This probably is 
 omited by design but I would realy like to write member funktion 
 definitions outside of their class. This way i can get the class 
 definition down to a single page and that helps when trying to read the 
 code later on as you can easily see the properities of a class at a 
 glance.


 
 You can do that now by creating a separate ".di" file which does not contain 
 the function bodies. See the -H switch. 
 
 


I knew of the -H switch but had not thought about using the di files 
that way. thanks :)



 Mar 07 2006



prev sibling  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


Johan Granberg wrote:


 3. read only sematics that work as a strong reminder that one is
 not suposed to modify somthing (but can be subverted by a cast) 




(Just a thought:)

I wonder if everybody here is thinking like this:

void foo(const int arg)
{
     // whatever
}

void main()
{
     int bar = 3;
     foo(bar);
}

Now, suppose we change the whole thing into:

void foo(int arg)
{
     // whatever
}

void main()
{
     int bar = 3;
     foo(const bar);
}

---

Comments? Ideas?

In non-release code the calling code could inclucde implicit tests for 
variable "sameness", i.e. check that the value is unchanged over the 
function call. That way the callee could simply be unaffected by this 
new twist. Right?

After all, it's the calling code that's interested in "constness", not 
the callee. Or have I missed something?



 Mar 07 2006



  parent  Kevin Bealer <Kevin_member pathlink.com>  writes:


In article <440E2E4C.6090902 nospam.org>, Georg Wrede says...

Johan Granberg wrote:


 3. read only sematics that work as a strong reminder that one is
 not suposed to modify somthing (but can be subverted by a cast) 




(Just a thought:)

I wonder if everybody here is thinking like this:

void foo(const int arg)
{
     // whatever
}

void main()
{
     int bar = 3;
     foo(bar);
}

Now, suppose we change the whole thing into:

void foo(int arg)
{
     // whatever
}

void main()
{
     int bar = 3;
     foo(const bar);
}

---

Comments? Ideas?

In non-release code the calling code could inclucde implicit tests for 
variable "sameness", i.e. check that the value is unchanged over the 
function call. That way the callee could simply be unaffected by this 
new twist. Right?

After all, it's the calling code that's interested in "constness", not 
the callee. Or have I missed something?


Other people have proposed this... its probably possible but would be costly.

You could do this and get nearly the same effect:

foo(bar.dup);

Of course, it would not work for int, but you don't need it for those.  It would
also not be "deep" constness, which would be hard to do in your method also.

I think the "deep" equality and "deep" const, and recursiveness of const (i.e.
const to sub-functions and sub-objects) is most of what makes it hard to
implement.

I've often found that const "catches" me in C++, but what it saves me from is
usually just "lack of const correctness".  I'm not sure how often it has
actually saved me from writing bad code.  In any case, Walter doesn't see a big
enough benefit from it.

I have an idea on const that I'll sketch up and post in a sec.

Kevin



 Mar 07 2006



prev sibling next sibling parent  =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com>  writes:


On Fri, 03 Mar 2006 13:03:34 -0800, 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++?


Well I think that D already have more programing power than C++.

What D need is more street respect ;-)

I think that most programmers won't switch to D before it 
have a magnitude more power than C++.

To get there I think you should just look at the top 
of the wish list at
http://all-technology.com/eigenpolls/dwishlist/story.php  

it says

84  array initialization/literals
  This feature witch everybody miss in C++ and D.  
56  Reflection API
  Many are missing this from Java
53  vectorization
  This will give D more calculating power than C++ and FORTRAN
50  Stack tracing
  There is a unofficial patch make it official
46  Faster GC 
  The judgement by the people ;-)
43  Short syntax for new
  The typing length to create a new object is one of the very ignoring
  things when coming from C++.



 Mar 04 2006



prev sibling next sibling parent  Tom <Tom_member pathlink.com>  writes:


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;



 Mar 04 2006



prev sibling next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


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 

and not just with C++!

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



 Mar 04 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:duc1g3$1936$1 digitaldaemon.com...

 But this question is a bit biased and misframed.


Of course, but that is the point of it. I wanted to hear what the biases and 
misframes are, so they can be dealt with. I want to know the source of the 
perception that "C++ is more powerful."


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


Right. I discovered this too. For the lack of an existing term, I called 
this "inspectability", which is defined as being able to tell what code is 
doing *without* needing to examine declarations or header files. For 
example, what are the various things that f(x) can mean in C++? (There are 
quite a few!) Code is not inspectable in C++. Any piece of code in C++, you 
have essentially no reliable touchstone as to what it is doing without 
examining all the header files.

(This is also one big reason why D does not have user definable tokens or 
syntax, it makes code completely uninspectable.)


 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.


You're quite right, and inspectability has been a big consideration. It's 
another reason why I dislike overloading assignment (as you mention).



 Mar 04 2006



  parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ducnmj$rv$3 digitaldaemon.com...

 Right. I discovered this too. For the lack of an existing term, I called 
 this "inspectability", which is defined as being able to tell what code is 
 doing *without* needing to examine declarations or header files. For 
 example, what are the various things that f(x) can mean in C++? (There are 
 quite a few!) Code is not inspectable in C++. Any piece of code in C++, 
 you have essentially no reliable touchstone as to what it is doing without 
 examining all the header files.


And in D, f(x) can be visually ambiguous as well - is the parameter in, out, 
or inout?

That's one of the minor niggles I have with out and inout params in D - it's 
never really obvious when you're using them, so you have to look at the docs 

out and "ref"), and it does look pretty and self-documenting. 



 Mar 04 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dudept$19qp$1 digitaldaemon.com...

 And in D, f(x) can be visually ambiguous as well - is the parameter in, 
 out, or inout?


At least you know it's a function call, rather than a declaration of x of 
type f! 



 Mar 04 2006



 next sibling parent reply Brad Roberts <braddr puremagic.com>  writes:


On Sat, 4 Mar 2006, Walter Bright wrote:


 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dudept$19qp$1 digitaldaemon.com...

 And in D, f(x) can be visually ambiguous as well - is the parameter in, 
 out, or inout?


 
 At least you know it's a function call, rather than a declaration of x of 
 type f! 


I've been trying to figure out when to say something on this topic since I 
fully understand just how difficult a topic const/immutability is and I 
know it's been thrashed around for years now.  That said, I think it's a 
seriously important feature for the safety and maintainability of code.

I view constness as one major aspect of contracts.  A function specifying 
that 'I will not alter the data you send me, and by implication neither 
will anything below me' give a major boost to the maintainability of a 
system.  A human writing that in a comment is totally insufficient.  The 
author could be wrong about a called function or a future change could 
invalidate the claim.  The language (and by implication the compiler) must 
support this guarantee.  As an asside, having such guarantees also gives 
the optimizer a boost in that it now has much more freedom to restructure 
code by knowing more.

I fully realize that C++'s const are incomplete.  I also don't personally 
have a full understanding of how to actually implement such protections.  
For now, let's not get caught up with the implementation specifics but 
rather defined semantics.

I want to be clear though, I'm not talking about const-ness of an 
instance, but of the barrier between callee and caller.

Make sense?

Later,
Brad



 Mar 05 2006



  parent  "Derek Parnell" <derek psych.ward>  writes:


On Sun, 05 Mar 2006 20:14:06 +1100, Brad Roberts <braddr puremagic.com>  
wrote:


 I want to be clear though, I'm not talking about const-ness of an
 instance, but of the barrier between callee and caller.

 Make sense?


Yes.


-- 
Derek Parnell
Melbourne, Australia



 Mar 05 2006



prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:due89q$2c2b$1 digitaldaemon.com...

 At least you know it's a function call, rather than a declaration of x of 
 type f!


And I still don't know if x is in, out, or inout.  You didn't really respond 
to my post, _as usual_. 



 Mar 05 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dufetm$r5v$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:due89q$2c2b$1 digitaldaemon.com...

 At least you know it's a function call, rather than a declaration of x of 
 type f!


 And I still don't know if x is in, out, or inout.  You didn't really 
 respond to my post, _as usual_.


Sure I did. My post was an aknowledgement that f(x) doesn't tell you if x is 
in, out, or inout. What exactly are you looking for? 



 Mar 05 2006



  parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message news:dufi31> > 
Sure I did. My post was an aknowledgement that f(x) doesn't tell you if x is

 in, out, or inout. What exactly are you looking for?


Your opinion on the matter, perhaps?  What you posted was kind of indirectly 
related to the subject, but didn't really tell me how you feel about 
out/inout at the call site.  To me, it came across as defensive, and a bit 
evasive.

Please reply with your feelings on the matter of out/inout at the call site, 
and if that would make code more readable/inspectible/self-documenting. 



 Mar 05 2006



 next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


I think Walter is really only describing things in terms of this topic; 
that is, as compared to C++ it is still much better.  He has avoided 
comparisons with other languages in this thread many other times.

I wouldn't say he's being evasive or defensive.  He's just not 
responding to your off-topic comment (which has been brought up before 
many times.)

Having lead public project development before, I completely understand 
his reluctance to publicly post his opinion on some matter, especially 
if he hasn't really given it enough thought yet.  Even if you "got 
something out of him", it would simply mean nothing or cause problems.

-[Unknown]



 "Walter Bright" <newshound digitalmars.com> wrote in message news:dufi31> > 
 Sure I did. My post was an aknowledgement that f(x) doesn't tell you if x is

 in, out, or inout. What exactly are you looking for?


 
 Your opinion on the matter, perhaps?  What you posted was kind of indirectly 
 related to the subject, but didn't really tell me how you feel about 
 out/inout at the call site.  To me, it came across as defensive, and a bit 
 evasive.
 
 Please reply with your feelings on the matter of out/inout at the call site, 
 and if that would make code more readable/inspectible/self-documenting. 
 
 





 Mar 05 2006



  parent reply "Derek Parnell" <derek psych.ward>  writes:


On Mon, 06 Mar 2006 07:54:22 +1100, Unknown W. Brackets  
<unknown simplemachines.org> wrote:


 I think Walter is really only describing things in terms of this topic;  
 that is, as compared to C++ it is still much better.  He has avoided  
 comparisons with other languages in this thread many other times.

 I wouldn't say he's being evasive or defensive.  He's just not  
 responding to your off-topic comment (which has been brought up before  
 many times.)


Walter is very generous with his limited time, considering the pressure we  
place him, and sometimes Walter doesn't respond to on-topic questions  
either. Hopefully that's because he's too busy and just misses than rather  
than deliberately ignoring them.


 Having lead public project development before, I completely understand  
 his reluctance to publicly post his opinion on some matter, especially  
 if he hasn't really given it enough thought yet.  Even if you "got  
 something out of him", it would simply mean nothing or cause problems.


But sometimes a simple "I'm still looking into that" would be nice.

-- 
Derek Parnell
Melbourne, Australia



 Mar 05 2006



  parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


With all due respect, in my experience this may be nice but can be just 
as detrimental.  As you and he said, he's going to miss some...

I was able to field 500 posts a day, but when 900 were being posted a 
day that just wasn't enough.  Most commonly, I would read a topic, give 
it to my subconscious, mark it back unread, and keep going.  If I said, 
"I'm thinking about it" (which I did try, by the way) I would be 
bombarded with personal messages from those I didn't make such responses 
to.  Because, then, they knew I wasn't even reading them.

It was much worse.  I'd rather leave it to mystery than make someone 
feel like I'm ignoring them when I'm just trying to get to everything I can.

I realize you want responses; I want responses.  I also know those who 
asked me questions wanted responses.  But in the end, it's patience 
that's the answer - not "I'm still looking into that."

Just my opinion, of course.

-[Unknown]


 But sometimes a simple "I'm still looking into that" would be nice.





 Mar 05 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:dufpnl$1ebk$1 digitaldaemon.com...

 Just my opinion, of course.


Sometimes, just my responding to a post generates a whole bunch of new posts 
that need responding too <g>. 



 Mar 05 2006



 next sibling parent  Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:dufpnl$1ebk$1 digitaldaemon.com...

 Just my opinion, of course.


 
 Sometimes, just my responding to a post generates a whole bunch of new posts 
 that need responding too <g>. 


Yup.  You're the metaphorical butterfly in these forums ;-)


Sean



 Mar 05 2006



prev sibling  parent  "Unknown W. Brackets" <unknown simplemachines.org>  writes:


I suppose that might indeed even happen with a response like, "I'm 
thinking about it" - if not as often.

-[Unknown]



 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:dufpnl$1ebk$1 digitaldaemon.com...

 Just my opinion, of course.


 
 Sometimes, just my responding to a post generates a whole bunch of new posts 
 that need responding too <g>. 
 
 





 Mar 05 2006



prev sibling  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dufiff$104d$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message news:dufi31> 
  > Sure I did. My post was an aknowledgement that f(x) doesn't tell you if 
 x is

 in, out, or inout. What exactly are you looking for?


 Your opinion on the matter, perhaps?  What you posted was kind of 
 indirectly related to the subject, but didn't really tell me how you feel 
 about out/inout at the call site.  To me, it came across as defensive, and 
 a bit evasive.

 Please reply with your feelings on the matter of out/inout at the call 
 site, and if that would make code more 
 readable/inspectible/self-documenting.


I don't really have any feelings on the matter. Note that f(x) also doesn't 
tell you the return type of f(), or the type of x, or if any implicit 
conversions happened to x as an effect of making a parameter out of it.

There are over 100 posts a day in these n.g's. It's simply impossible for me 
to give detailed, intelligent, solid responses to every point. It's not 
possible to give each the attention they deserve. The best I can do is try 
to deal with the most important topics, and I'm sure nobody will agree with 
me nor anyone else as to which are the most important ones. It's not even 
possible for *me* to determine which are the most important ones.

Important things get overlooked. Messages scroll off before being dealt 
with. I'm sorry about that.

Some things that do help *a lot* are:

1) Thomas' dstress
2) Brad's bugzilla
3) Helmut's wiki

because they serve as distillers of wheat from chaff, and things don't 
scroll off in them. They also each share a common characteristic - someone 
took the initiative and took charge of them. 



 Mar 05 2006



prev sibling next sibling parent  Dave <Dave_member pathlink.com>  writes:


In article <due89q$2c2b$1 digitaldaemon.com>, Walter Bright says...

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dudept$19qp$1 digitaldaemon.com...

 And in D, f(x) can be visually ambiguous as well - is the parameter in, 
 out, or inout?


At least you know it's a function call, rather than a declaration of x of 
type f! 


Is this the primary reason that implicit ctors for fundamental types have not
been implemented?

If so, I guess I don't see how 'double i = double(10.25);' would be seen as any
more ambiguous or make code any harder to read than ctors or static opCalls for
UDT's?

With implicit fundamental types ctor syntax, 'static if(is(...))' wouldn't be
needed as much to support UDT's for templates like this (and also make template
code easier to develop, read and maintain, IMO):

//import std.math;
//template circumference(T)
//{
//    T circumference(T radius)
//    {
//        static if(is(T : real))
//            return PI * radius * 2;
//        else
//            return T(PI) * radius * T(2);
//    }
//}

Thanks,

- Dave



 Mar 05 2006



prev sibling  parent  Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Walter Bright wrote:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dudept$19qp$1 digitaldaemon.com...
 

And in D, f(x) can be visually ambiguous as well - is the parameter in, 
out, or inout?


 
 
 At least you know it's a function call, rather than a declaration of x of 
 type f! 
 
 


You can declare basic datatypes like this:





ironically, if you use an alias, you can't do it








 Mar 05 2006



prev sibling next sibling parent  "Dave" <Dave_member pathlink.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:duab09$1arn$1 digitaldaemon.com...

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


- stack allocation for auto classes
- ITI for function templates
- implicit ctors for fundamental types, e.g.: int* i = new int(10);
- ctors for structs to get rid of having to use static opCall().
- Fix this issue: 
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/6036

The last 2 are for cases like:

template mypow(F) {
    F mypow(F x, int i) {
        if(i < 1) return F(1); // here
        if(i & 1) if(i == 1) return x; else return x * mypow(x,i-1);
        return sqr!(F)(mypow(x,i/2));
    }
}

- Dave



 Mar 04 2006



prev sibling next sibling parent reply Def <Def_member pathlink.com>  writes:


In article <duab09$1arn$1 digitaldaemon.com>, Walter Bright says...


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


Maybe you're simply looking at the wrong place. It might not be the language
itself - maybe D is missing a really good and comprehensive tutorial. Imagine
the C++ crowd that wants to migrate to D, and how they struggle to figure out
"the D way to do things". And then, when nothings works as expected, they tend
to say "if D only had [some C++ feature]". Not everyone has fun learning by
searching the web. ;-)
So with a good D tutorial and documentation that has been written with D in mind
from the beginning, D might seem as powerful as it actually is to the people who
are new to D.

As always, just my two cents.
Def



 Mar 04 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Def" <Def_member pathlink.com> wrote in message 
news:duct3u$atg$1 digitaldaemon.com...

 In article <duab09$1arn$1 digitaldaemon.com>, Walter Bright says...


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


 Maybe you're simply looking at the wrong place. It might not be the 
 language
 itself - maybe D is missing a really good and comprehensive tutorial. 
 Imagine
 the C++ crowd that wants to migrate to D, and how they struggle to figure 
 out
 "the D way to do things". And then, when nothings works as expected, they 
 tend
 to say "if D only had [some C++ feature]". Not everyone has fun learning 
 by
 searching the web. ;-)


It is my impression that C++ people who find D lacking are trying to compile 
essentially C++ code in D, instead of looking at D on its own merits.


 So with a good D tutorial and documentation that has been written with D 
 in mind
 from the beginning, D might seem as powerful as it actually is to the 
 people who
 are new to D.


The documentation certainly could be better. 



 Mar 04 2006



  parent  Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Walter Bright wrote:

 "Def" <Def_member pathlink.com> wrote in message 
 news:duct3u$atg$1 digitaldaemon.com...
 

In article <duab09$1arn$1 digitaldaemon.com>, Walter Bright says...



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


Maybe you're simply looking at the wrong place. It might not be the 
language
itself - maybe D is missing a really good and comprehensive tutorial. 
Imagine
the C++ crowd that wants to migrate to D, and how they struggle to figure 
out
"the D way to do things". And then, when nothings works as expected, they 
tend
to say "if D only had [some C++ feature]". Not everyone has fun learning 
by
searching the web. ;-)


 
 
 It is my impression that C++ people who find D lacking are trying to compile 
 essentially C++ code in D, instead of looking at D on its own merits.
 
 

So with a good D tutorial and documentation that has been written with D 
in mind
from the beginning, D might seem as powerful as it actually is to the 
people who
are new to D.


 
 
 The documentation certainly could be better. 
 
 


It took me a while to figure out how to code simple programs in D ..
Learning D isn't hard at all when you have C++/Java background, but 
finding good D tutorials is!



 Mar 04 2006



prev sibling next sibling parent reply Cris <central_p hotmail.com>  writes:


This is not directly related to the language but I think it is 
essential, it is actually more essential than a few more features:

1. The language needs a good modern multi platform IDE and a great 
compiler, that does a good error reporting, that can work from a 
different directory than the root c:\dmd

2. Good documentation (much better than the current one.

3. A good debugger (some people use and need one), it should be 
intergrated into the IDE.

4. A great library with lots of low level system independent functions 
(something like .NET class library) but that abstract some OS specific 
functionality to give a hint: like user information, home folders, etc.

5. Some sort of GUI library even if it is not part of the official 
specification or distribution.

6. Official support/management for bindings for the essential third 
party libraries: incl. multimedia, GUIs, etc.

7. Tutorials, samples, etc.

Is there any built in XML support?

If you have that you'll attract much wider audience, especially 
beginners, that could be turned down if they bump into the wall of 
information luck.

I know this is a huge task but perhaps you can start some sort of 
committee to overlook and develop such "standard" features?



 Mar 04 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Cris" <central_p hotmail.com> wrote in message 
news:dudk7f$1gj3$1 digitaldaemon.com...

 I know this is a huge task but perhaps you can start some sort of 
 committee to overlook and develop such "standard" features?


These are all good points, but there's just me at this end <g>. If there's 
anything you want to take charge of, even something as simple as writing a 
brief tutorial on some aspect of D, please do so! 



 Mar 05 2006



prev sibling next sibling parent  =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid>  writes:


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?


Nothing significant.


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


I think besides bugs and template/array-issues D is almost ready. One
major thing that's bugging me though is the role of interfaces in D.
I've always thought that D should use interfaces like Java does. Still D
(according to the BNF-syntax in the docs) introduces protection
attributes to class inheritance. OTOH a trivial test case shows that
(luckily) they are not implemented (at least not the way C++ uses them).
IMHO they're not welcome at all, if we are going to support accessing
classes via interface references:

 interface foo { (public) void abc() { ... } }
 class bar : private foo // something very wrong here
 {}

 void main() {
  foo obj = new bar();
  obj.abc();
 }


The private-protection forces C++ to do a runtime check on the 7. row
and prevent the use. This is complete insanity. Also .sort:ing and other
important operations don't really work currently with the arrays of
interface references to different derived classes of foo. As a
workaround abstract classes must be used as interfaces, but this
prevents the emulation of multiple inheritance. As far as I understand
these interface references aren't as efficient as class references but
they're still damn useful for many practical (non-time critical) purposes.

-- 
Jari-Matti



 Mar 05 2006



prev sibling  parent  bobef <bobef lessequal.com>  writes:


Walter Bright wrote:

 
 What does D have to do to have more power than C++? 
 
 


Real DLL support!



 Mar 08 2006