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


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

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

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 what's available for C# and Java. Libraries - nah. With no ABI, C++ is dead in 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++

missing?


 
 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
 
 

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

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 without const - such as Java, Python, C#, etc.
 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++?

is known in D as luck of struct ctor/dtor.

The following: auto Foo f = new Foo(); has ctor/dtor semantics. It isn't allocated on the stack at the moment, but there is no semantic reason why it couldn't be. Allocating it on the heap is an artifact of dmd, and not of the language.

This is not only about stack allocation but also about the whole thing: "- Definable assignment/copy semantics for structs. " / Oskar Linde There is no way currently in D to implement "guarded variable": something s = ....; I cannot write code which will allow to catch assignment to the variable (concrete memory region if you wish). Just nothing for that in D at all - variables are naked.
 2) C++/C both have const.

 These two are corner stones in C++ (among others).
 The whole std:: namespace without them is just impossible.

 I cannot imagine serious *library* design without 'const' for example.
 Library here means design of robust code used by millions.
 Phobos imho will never be considered as something rock-solid without
 'const'.

I don't really understand this, as many languages have serious libraries without const - such as Java, Python, C#, etc.

1) All these have builtin immutability. For example strings there are immutable objects. D has no strings so it must have some features in the language allowing to implement such objects as a library. 2) D has raw pointers - D is comparable with C/C++ but not with Java. D will not replace Java in most of cases. Completely different execution model. D in this respect is wery close to C/C++. So D competes with C/C++ but not with Java, Python or C#. And this would be extremely cool if D can win C++. At least as language for GUI. GUI is most OOP task known. If you can do something in C/C++ you must be able to do it in D. This is it. Postulate: D must include all features C++ has now.
 E.g. I have tried three or four different approaches
 to reproduce string value type in D. Just no way.
 Everything what I've seen so far is non-comparable
 with even std:string and I am yet silent about .NET and Java.

I don't understand what you mean.

Immutable yet effective strings and ranges.
 Big picture: templates (at some extent) and
 definitely delegates are superior in D than in C++.
 Other features are more or less elegantly reproducible in C++.

Try doing nested functions elegantly in C++ <g>.

Agree, they are useful. But if used with care. As soon as you can get address of such inner function then you are in trouble - result of later call of such function is non-deterministic. It is not like in JavaScript where function frames are valid if referenced somewhere. Following: var tt; function test() { var s0 = "Hello"; function testtest() { stdout << s0; } tt = testtest; } test(); tt(); stdout << " World!"; will print in JS (my TIScript here) :
Hello World!

D will GPF on something like this I guess.
 D used to have clean,consistent and simple syntax and execution model
 (e.g. GC "from the shelf") but holes 1) and 2) on the bottom of this ship
 are just shining.

I'm not sure why (1) and (2) didn't exist in the way D used to be.

Sorry, two different sentences here: 1) D used to have clean,consistent and simple syntax and execution model (e.g. GC "from the shelf") - not anymore, IMO. D inner classes for example - strange halfly implemented Java feature. Scope guards are generally good but without clear and strict definition of execution model - almost useless - syntactic noise. "auto zoo" there too. Over-qualified 'static' All that private/protected stuff is just not finished yet - I was fighting with it in Harmonia - never win. 2) holes 1) and 2) on the bottom of this ship are just shining. These are the only features of C++ which D cannot handle at all. OT: I was proposing readonly ranges and pointers as a simple alternative / palliative of problem #1. At least they allow to have lightweight and fast strings as in Java/C#/Python. Andrew.
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 
 without const - such as Java, Python, C#, etc.

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

As soon as you can get address of such inner function then you are in trouble - result of later call of such function is non-deterministic.

True, one can get into trouble doing that wrong, but it isn't conceptually any different from the following C++ code: int *p; void foo() { int i; p = &i; } void test() { ... = *p; } So I would not argue that it is a defect *in comparison to C++*.
 D inner classes for example - strange halfly implemented Java feature.

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

I strongly disagree there. I thought I had answered your questions about that in the scope guard thread.
 "auto zoo" there too.  Over-qualified 'static' All that private/protected 
 stuff
 is just not finished yet - I was fighting with it in Harmonia - never win.

The private/protected stuff works like it does in C++.
 OT: I was proposing readonly ranges and pointers as a simple alternative / 
 palliative
 of problem #1. At least they allow to have lightweight and fast strings as 
 in Java/C#/Python.

Java/C#/Python do not have lightweight and fast strings. There are some layers of complexity there that are hidden, but are there.
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 
 without const - such as Java, Python, C#, etc.

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? Go for C# - it has faster GC so this joy-of-GC will not be so critical.
 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>.

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
 of problem #1. At least they allow to have lightweight and fast strings 
 as in Java/C#/Python.

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

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.


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. .NET (or C# at any rate) has the same basic behavior, though it may be 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
 */
 ??=include <stdio.h> // #
 
 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?


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

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


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.

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

In article <duaqm9$25at$1 digitaldaemon.com>, Walter Bright says...
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:duajvt$1re3$1 digitaldaemon.com...
 What does D have to do to have more power than C++?

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...)
That said, I wanted to make a few points about Andrew's item #1...

In article <duaqm9$25at$1 digitaldaemon.com>, Walter Bright says...


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

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

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.

has gc and on_scope.

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

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

Hey, D is in #21, ahead of Ruby and Fortran! It's almost achieved 'B' 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++

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

Hey, D is in #21, ahead of Ruby and Fortran! It's almost achieved 'B' 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. :-)" Basic #5? What the...? -- 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
 ...

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

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

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


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

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.


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

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.


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.


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?

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?

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?

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. 

"ineffective".


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

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

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.

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 thinking of comparing D with modern languages (Java, C#, and others), and not just with C++! -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 04 2006
next sibling 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 to find out. out and inout are required at the call site in C# (or rather, 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 "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: # int(x); # # x = 10; ironically, if you use an alias, you can't do it # alias int t; # # t(x1); # x1 = 10;
Mar 05 2006
prev sibling parent 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
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: 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