www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++

reply David Medlock <noone nowhere.com> writes:
Its adherents rarely surprise me anymore.

Read my post on LTU and snk_kid's response:
http://lambda-the-ultimate.org/node/1583#comment-19266

I am not trying to single him out, but the responses are pretty common 
in my (arguably anectdotal) experience.

C++ is getting X in next version...
Using boost/somelib we can do X...
GC/Feature N will be great for C++ but for language Y its slow...

Sigh.

Its funny when people bring up libraries to make their points.
Templates in C++ are slow to compile and bloated in my exposure to them.
And even with all those libraries can you finally type:
string s = "Hello" + " World";

After using D for a while now, i almost _despise_ C++.
I think I would rather just use (python & C) instead of going back.

Walter you have your work cut out for you.
Like most things in IT, the human/political issues outweigh the 
technical ones.

Sorry for the rant.
-DavidM
Jun 29 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
David Medlock wrote:
 Its adherents rarely surprise me anymore.
 
 Read my post on LTU and snk_kid's response:
 http://lambda-the-ultimate.org/node/1583#comment-19266
 
 I am not trying to single him out, but the responses are pretty common 
 in my (arguably anectdotal) experience.
 
 C++ is getting X in next version...
 Using boost/somelib we can do X...
 GC/Feature N will be great for C++ but for language Y its slow...
 
 Sigh.
 
 Its funny when people bring up libraries to make their points.

Not for C++. For better or worse, a primary design goal of C++ was keep as much as possible out of the language definition by supporting user defined types that are indistinguishable from built-in types. So a valid comparison to C++ must necessarily include what can be done in library code. That said, I don't agree with many of snk_kid's observations. D *does* support implicit template instantiation, for example. The compiler implementation is just incomplete. As for concepts, I do think they would be useful in D but I think they're less necessary than in C++ because D has static if and static assert. Also, you can inherit from template type parameters as far as I know. As for boost::function--it's a horrible bit of code and is far more awkward to use than delegates (particularly anonymous delegates) but it works pretty well aside from all that. However, snk_kid doesn't address the idea that inner functions (ie. delegates) have access to local stack data, or that actually defining a new boost::function is nothing at all like defining a plain old function--it's obviously a class-based hack. Meta logic is much the same... it's possible in C++ but is far more awkward. And C++ obviously doesn't support strings or decimal numbers as template value parameters. Not to mention aliases. I think one problem is that some people just look at the spec to learn about the language, and the spec is quite sparse in places. I don't think it mentions implicit template instantiation, and mention of some other features is hard to find.
 Walter you have your work cut out for you.
 Like most things in IT, the human/political issues outweigh the 
 technical ones.

Always. But as long as D remains in development and isn't supplanted by some magic new language with all of D's features *and* a My Little Pony (tm) then it will have users. Particularly with GDC available for the non-Windows folks. Sean
Jun 29 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 David Medlock wrote:
 Its adherents rarely surprise me anymore.

 Read my post on LTU and snk_kid's response:
 http://lambda-the-ultimate.org/node/1583#comment-19266

 I am not trying to single him out, but the responses are pretty common 
 in my (arguably anectdotal) experience.


 I think one problem is that some people just look at the spec to learn 
 about the language, and the spec is quite sparse in places.  I don't 
 think it mentions implicit template instantiation, and mention of some 
 other features is hard to find.

On the "Comparison with other languages" page, it explicitly says that D doesn't have implicit function template instantiation. AND it's been removed from the 'future directions' page. When I first looked at D, the absence of IFTI was the #1 turn-off. It's only because I saw it in the 'future directions' page that I gave the language a chance.
 Walter you have your work cut out for you.
 Like most things in IT, the human/political issues outweigh the 
 technical ones.


True, but I'm going to stick up for snk_kid. Based on the spec, he's quite justified in thinking D doesn't have IFTI and probably never will; and the implications for library design are huge. He's justified in thinking that D template libraries will never be as powerful as C++. When you read the spec, you should get the impression that D templates are far more powerful than C++ templates.
Jun 29 2006
next sibling parent David Medlock <noone nowhere.com> writes:
Don Clugston wrote:
 Sean Kelly wrote:
 

 True, but I'm going to stick up for snk_kid. Based on the spec, he's 
 quite justified in thinking D doesn't have IFTI and probably never will; 
 and the implications for library design are huge. He's justified in 
 thinking that D template libraries will never be as powerful as C++.
 When you read the spec, you should get the impression that D templates 
 are far more powerful than C++ templates.

I would agree with you, but look at the first sentence of my post(above his).
Jun 30 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 On the "Comparison with other languages" page, it explicitly says that D 
 doesn't have implicit function template instantiation.

Fixed (How did I miss that!)
Jun 30 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 For better or worse, a primary design goal of C++ was keep 
 as much as possible out of the language definition by supporting user 
 defined types that are indistinguishable from built-in types.  So a 
 valid comparison to C++ must necessarily include what can be done in 
 library code.

For a language with minimal features as a primary design goal, C++ turned out to be, by far, the most complex core language ever to implement!
Jun 30 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"David Medlock" <noone nowhere.com> wrote in message 
news:e819r5$h8i$1 digitaldaemon.com...

 Read my post on LTU and snk_kid's response:

snk_kid is just another C++ fanboy. I'm dealing with him on gamedev.net too.
Jun 29 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Jarrett Billingsley wrote:
 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...
 
 Read my post on LTU and snk_kid's response:

snk_kid is just another C++ fanboy. I'm dealing with him on gamedev.net too.

link?
Jun 29 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
clayasaurus wrote:
 Jarrett Billingsley wrote:
 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...

 Read my post on LTU and snk_kid's response:

snk_kid is just another C++ fanboy. I'm dealing with him on gamedev.net too.

link?

Shame on you, Clay, for not keeping up with my blog! http://www.gamedev.net/community/forums/topic.asp?topic_id=400729
Jun 30 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Mike Parker wrote:
 clayasaurus wrote:
 
 Jarrett Billingsley wrote:

 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...

 Read my post on LTU and snk_kid's response:

snk_kid is just another C++ fanboy. I'm dealing with him on gamedev.net too.

link?

Shame on you, Clay, for not keeping up with my blog! http://www.gamedev.net/community/forums/topic.asp?topic_id=400729

Interesting, in both places snk_kid keeps harping on his claim that "D is a failed attempt to be truely better than C++ in *all aspects* which it isn't." Where did he get that impression???? I have never seen anyone else make the claim that D is trying to be better than anything in *all* respects. Walter doesn't claim this. And considering it is provable that it can't be done, It would be stupid for anyone to claim that. Also, in places he argues that D will not take over because it can't do something that C++ programmers do. This is only a problem if you try to wright C++ programs in D. The question shouldn't be: "Can the language generate this construct?", it should be: "How easy is it to solve this problem in this language?". D isn't a better C++. No programming language can be a better C++. D is trying to be a better *Programming Language*.
Jun 30 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:
 Interesting, in both places snk_kid keeps harping on his claim that "D 
 is a failed attempt to be truely better than C++ in *all aspects* which 
 it isn't."

I've seen similar claims, and what they are are excuses to not use D regardless. It doesn't matter to these people what D can do that is utterly impractical in C++. Another problem happens when people try to transliterate C++ code into D. That doesn't work very well - you have to rethink things a bit. Nevertheless, I still regard D as a better C++. Not in terms of being a true superset, but in terms of being a better solution to the same types of problems that C++ is targetted at. Note that C++ isn't a true superset of C, either, although it is billed as a "better C".
Jun 30 2006
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 Another problem happens when people try to transliterate C++ code into 
 D. That doesn't work very well - you have to rethink things a bit.

In my experience, transliterating C++ to D allows for a lot of code to simply be tossed out. It's issues like this that aren't obvious from simply reading a spec.
 Nevertheless, I still regard D as a better C++. Not in terms of being a 
 true superset, but in terms of being a better solution to the same types 
 of problems that C++ is targetted at. Note that C++ isn't a true 
 superset of C, either, although it is billed as a "better C".

I've yet to do the same level of work in D that I do in C++, but so far I'd have to agree. And I'm looking forward to some more ambitious projects once the framework is sorted out sufficiently. That said, I do think D's lack of any sort of const checking may be an issue for large projects (I haven't done this level of development in Java so I don't have a good non-C++ basis for comparison here). I know the issue has been beaten to death in the past, but perhaps we could do with a constructive discussion before 1.0 appears on the horizon? I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen? Sean
Jun 30 2006
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 if
 it's going to happen?
 
 
 Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.
Jun 30 2006
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Deewiant wrote:
 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
 there) that he thinks he should have made D like this from the start, but that
 it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
 late to break even every single line of D code out there.

And if it's going to be added post 1.0, there will be even more code that will have to be modified to use all the new cool features that D 2.0 will provide :> Walter, if you think that it's too late because it might break a lot of code, why not let the community decide whether it would be very bad or not ? -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 30 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 if
 it's going to happen?

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

And there's nothing wrong with making it a warning for N releases, or allocating a new flag for experimental features, assuming it really is the correct approach. Also, with discussion, we may even be able to prepare for upcoming changes or put off creating code-level hacks to mimic the same behavior. Sean
Jun 30 2006
prev sibling next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 
 if it's going to happen?
 
 Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17 In summary: Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a good reason - C compatibility." Walter responds: "I should have. Too much water under the bridge for that now." In the same post Walter also acknowledges that "There has been some talk in the D newsgroups of doing that, but it has the potential to be extremely disruptive."
Jun 30 2006
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Deewiant wrote:
 Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 
 if it's going to happen?

 Sean

there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17 In summary: Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a good reason - C compatibility." Walter responds: "I should have. Too much water under the bridge for that now." In the same post Walter also acknowledges that "There has been some talk in the D newsgroups of doing that, but it has the potential to be extremely disruptive."

Absolutely. we definitely need it. Walter, I hope you will reconsider. Many of us are more than willing to accept any of those potential disruptions. Success often comes only with risk. :) You've got this far with such an incredible language, why not take it all the way? -JJR
Jun 30 2006
next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:e841ch$169g$1 digitaldaemon.com...
 Deewiant wrote:
 Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method 
 seems ideal, but this seems like something that should really be done 
 before 1.0 if it's going to happen?

 Sean

was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17 In summary: Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a good reason - C compatibility." Walter responds: "I should have. Too much water under the bridge for that now." In the same post Walter also acknowledges that "There has been some talk in the D newsgroups of doing that, but it has the potential to be extremely disruptive."

Absolutely. we definitely need it. Walter, I hope you will reconsider. Many of us are more than willing to accept any of those potential disruptions. Success often comes only with risk. :) You've got this far with such an incredible language, why not take it all the way?

you shouldn't be surprised if a change breaks your code; I'm sure most if not all of us here know that, and if you don't by this time, well...
 -JJR 

Jun 30 2006
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
John Reimer wrote:
 Deewiant wrote:
 Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method 
 seems ideal, but this seems like something that should really be 
 done before 1.0 if it's going to happen?

 Sean

it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26# oc_3ff8dedacef55e17 In summary: Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a good reason - C compatibility." Walter responds: "I should have. Too much water under the bridge for that now." In the same post Walter also acknowledges that "There has been some talk in the D newsgroups of doing that, but it has the potential to be extremely disruptive."

Absolutely. we definitely need it. Walter, I hope you will reconsider. Many of us are more than willing to accept any of those potential disruptions. Success often comes only with risk. :) You've got this far with such an incredible language, why not take it all the way? -JJR

If it makes D better then add it. This goes for any feature. Of course discuss disrupting features on the NG first.
Jun 30 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 01 Jul 2006 05:47:51 +1000, Deewiant  
<deewiant.doesnotlike.spam gmail.com> wrote:

 Deewiant wrote:

 I found the post in question, BTW. Here's the Google Groups link:
 In summary:

 Andrei Alexandrescu says "Why, then, didn't D make const the default?  
 C++ had a
 good reason - C compatibility."

 Walter responds: "I should have. Too much water under the bridge for  
 that now."

 In the same post Walter also acknowledges that "There has been some talk  
 in the
 D newsgroups of doing that, but it has the potential to be extremely  
 disruptive."

This would be a welcomed disruption as it makes D a much better product. I have no problems about retrofitting this sort of change in all my D code. -- Derek Parnell Melbourne, Australia
Jun 30 2006
parent Dave <Dave_member pathlink.com> writes:
Derek Parnell wrote:
 On Sat, 01 Jul 2006 05:47:51 +1000, Deewiant 
 <deewiant.doesnotlike.spam gmail.com> wrote:
 
 Deewiant wrote:

 I found the post in question, BTW. Here's the Google Groups link:
 In summary:

 Andrei Alexandrescu says "Why, then, didn't D make const the default? 
 C++ had a
 good reason - C compatibility."

 Walter responds: "I should have. Too much water under the bridge for 
 that now."

 In the same post Walter also acknowledges that "There has been some 
 talk in the
 D newsgroups of doing that, but it has the potential to be extremely 
 disruptive."

This would be a welcomed disruption as it makes D a much better product. I have no problems about retrofitting this sort of change in all my D code.

I agree. People can always use the current version if they need to support code that this breaks.
 --Derek Parnell
 Melbourne, Australia

Jul 01 2006
prev sibling next sibling parent Juan Jose Comellas <jcomellas gmail.com> writes:
Well, I hope D gets const support somewhere in the near future, because it
is also needed to be able to pass parameters to threads efficiently (i.e.
without duplicating everything). There needs to be a way to specify that a
certain object is immutable when you pass it to a thread to avoid
unnecessary locking.

The lack of this feature is not much of a problem for small projects or when
you're only dealing with your own code, but once D takes off (as I believe
everybody here hopes it will) and we start using a lot of different D
libraries it will become an essential feature.


Deewiant wrote:

 Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method
 seems ideal, but this seems like something that should really be done
 before 1.0 if it's going to happen?
 
 Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link:

 
 In summary:
 
 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++
 had a good reason - C compatibility."
 
 Walter responds: "I should have. Too much water under the bridge for that
 now."
 
 In the same post Walter also acknowledges that "There has been some talk
 in the D newsgroups of doing that, but it has the potential to be
 extremely disruptive."

Jul 01 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Deewiant wrote:
 Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 
 if it's going to happen?

 Sean

there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I found the post in question, BTW. Here's the Google Groups link: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17 In summary: Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a good reason - C compatibility." Walter responds: "I should have. Too much water under the bridge for that now." In the same post Walter also acknowledges that "There has been some talk in the D newsgroups of doing that, but it has the potential to be extremely disruptive."

Good thread, I highly agree with what Andrei said in that segment. In summary, that a language supported read-only view of data is significantly beneficial. As for the backwards compatibility issue, I've said it before: D, as a language in development, should not be blocked by backwards compatibility issues in detriment of beneficial changes. Of course, such changes must be extensively thought about and discussed beforehand. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 03 2006
prev sibling parent Serg Kovrov <user domain.invalid> writes:
Deewiant wrote:
 
 I found the post in question, BTW. Here's the Google Groups link:
 
 http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
 
 In summary:
 
 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
 good reason - C compatibility."
 
 Walter responds: "I should have. Too much water under the bridge for that now."
 
 In the same post Walter also acknowledges that "There has been some talk in the
 D newsgroups of doing that, but it has the potential to be extremely
disruptive."

Subj. ps. Sorry for flood, but i just can't help it =) -- serg.
Jul 03 2006
prev sibling next sibling parent reply "Tony" <ignorethis nowhere.com> writes:
"Deewiant" <deewiant.doesnotlike.spam gmail.com> wrote in message 
news:e83rmr$vi5$1 digitaldaemon.com...
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems
 ideal, but this seems like something that should really be done before 
 1.0 if
 it's going to happen?


 Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I too agree. Making const the default and adding a mutable keyword would be wonderful. This would more than address what seems to be one of the primary (and I think quite justified) criticisms of D by the C++ community. This might also assist a future compiler in determining what operations could be done in parallel. I assumed that the version numbering scheme (i.e. not yet at 1.0) was an indication that the language was still in development and might change in fairly fundamental ways. Tony Melbourne, Australia
Jun 30 2006
parent BCS <BCS pathlink.com> writes:
Tony wrote:
 
 
 I too agree.  Making const the default and adding a mutable keyword would be 
 wonderful.  This would more than address what seems to be one of the primary 
 (and I think quite justified) criticisms of D by the C++ community.
 

This would only apply to reference types I assume. So, when giving away a reference, would one have to grant mutability privilege any time the recipient doesn't ensure non-mutation? If this is the case, I would advocate the use of an operator for this, something with a syntax like the address of (&) operator, maybe the " ". void func(mute char[] arg) { foreach(inout a;arg) a='\0'; } ... char[] foo; func( foo); // valid func(foo); // error: argument 1 of "func" is mutable ...
Jun 30 2006
prev sibling next sibling parent "Boris Wang" <nano.kago hotmail.com> writes:
Yes,before 1.0, any change is not too late, always.

"Deewiant" <deewiant.doesnotlike.spam gmail.com> 
??????:e83rmr$vi5$1 digitaldaemon.com...
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems
 ideal, but this seems like something that should really be done before 
 1.0 if
 it's going to happen?


 Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

Jul 01 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Deewiant wrote:
 Sean Kelly wrote:
 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 if
 it's going to happen?

 Sean

I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too late to break even every single line of D code out there.

I thought I've seen in this newsgroup a while back that Walter would make changes to the language that would break previous versions, because he didn't want it to end up like c++ (ugly patches instead of fixing things correctly and breaking compatibility)? To me that is a big plus in a language, that the author is willing to break things for the good of the language. And D hasn't even hit version 1.0 yet, so I don't see a problem at all. Also I did sort of agree with snk_kid on one point... I don't understand why D uses "~" for adding words together instead of "+". It seems like all the other languages I use all use + for adding words. Adding makes sense for words... I added on to what he said. I added some words to his sentence. If you add these two phrases together... Is there any benefit to having a separate symbol for adding (ok, concatenating)? If not feel free to break the language here too. Lucas
Jul 01 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lucas Goss wrote:
 Also I did sort of agree with snk_kid on one point... I don't understand 
 why D uses "~" for adding words together instead of "+". It seems like 
 all the other languages I use all use + for adding words. Adding makes 
 sense for words...
 
 I added on to what he said.
 I added some words to his sentence.
 If you add these two phrases together...
 
 Is there any benefit to having a separate symbol for adding (ok, 
 concatenating)? If not feel free to break the language here too.

Concatenation is quite different from addition: int[3] a = [1,2,3]; int[3] b = [4,5,6]; int[] c = a + b; // c[] = [5,7,9] int[] d = a ~ b; // d[] = [1,2,3,4,5,6] Two distinct operators are necessary.
Jul 01 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 Lucas Goss wrote:
 
 Also I did sort of agree with snk_kid on one point... I don't 
 understand why D uses "~" for adding words together instead of "+". It 
 seems like all the other languages I use all use + for adding words. 
 Adding makes sense for words...

 I added on to what he said.
 I added some words to his sentence.
 If you add these two phrases together...

 Is there any benefit to having a separate symbol for adding (ok, 
 concatenating)? If not feel free to break the language here too.

Concatenation is quite different from addition: int[3] a = [1,2,3]; int[3] b = [4,5,6]; int[] c = a + b; // c[] = [5,7,9] int[] d = a ~ b; // d[] = [1,2,3,4,5,6] Two distinct operators are necessary.

Amen. Disambiguation is a Good Thing(tm). Except for "Array operations not implemented" as yet. Any idea when this much-coveted, much-anticipated feature will come to life? I don't mean to push, but I've dreamt of array-ops nearly since I first got involved with D back in 2003. -- Chris Nicholson-Sauls
Jul 01 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:
 Except for "Array operations not implemented" as yet.  Any idea when 
 this much-coveted, much-anticipated feature will come to life?  I don't 
 mean to push, but I've dreamt of array-ops nearly since I first got 
 involved with D back in 2003.

It'll have to be a 2.0 thing.
Jul 02 2006
parent reply Fredrik Olsson <peylow gmail.com> writes:
Walter Bright skrev:
 Chris Nicholson-Sauls wrote:
 
 Except for "Array operations not implemented" as yet.  Any idea when 
 this much-coveted, much-anticipated feature will come to life?  I 
 don't mean to push, but I've dreamt of array-ops nearly since I first 
 got involved with D back in 2003.

It'll have to be a 2.0 thing.

guess there are a million reasons as to why not have them, but if I could choose this would be a nice syntax for both introducing operator overloads and properties to existing types: type int[] { int[] opAdd(int[] a) { assert(this.length == a.length); int[] r; r.length = this.length; foreach (i, v; this) { r[i] = v + a[i]; } return r; } int sum() { int r = 0; foreach(v; this) { r += v; } return v; } } // Making these work; int[] a = [1, 2, 3]; int[] b = [4, 5, 6]; int[] c = a + b; // [5, 7, 9]; int d = c.sum(); // 15 // Fredrik
Jul 07 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Fredrik Olsson wrote:
 Walter Bright skrev:
 
 Chris Nicholson-Sauls wrote:

 Except for "Array operations not implemented" as yet.  Any idea when 
 this much-coveted, much-anticipated feature will come to life?  I 
 don't mean to push, but I've dreamt of array-ops nearly since I first 
 got involved with D back in 2003.

It'll have to be a 2.0 thing.

Perhaps not part of core language, put thought operator overloads. I guess there are a million reasons as to why not have them, but if I could choose this would be a nice syntax for both introducing operator overloads and properties to existing types: type int[] { int[] opAdd(int[] a) { assert(this.length == a.length); int[] r; r.length = this.length; foreach (i, v; this) { r[i] = v + a[i]; } return r; } int sum() { int r = 0; foreach(v; this) { r += v; } return v; } } // Making these work; int[] a = [1, 2, 3]; int[] b = [4, 5, 6]; int[] c = a + b; // [5, 7, 9]; int d = c.sum(); // 15 // Fredrik

This gives me a thought. Currently we have the pseudo-member effect, which causes the following to be possible: # int sum (int[] arr) { # int result = 0 ; # # foreach (i; arr) # result += arr; # # return result; # } # # int[] foo = [1, 2, 3, 4] ; # int bar = foo.sum ; // bar == 1 + 2 + 3 + 4 == 10 Also, in D (theoretically at least) it seems all operators are rewritten as function calls. Such that the expression (a + b) becomes (a.opAdd(b)). So, perhaps we could do something like this: # int[] opAdd (int[] a, int[] b) # in { # assert( a.length == b.length, "Array-Ops only applicable to arrays of equal length" ); # } # body { # int[] result = new int[a.length] ; # # foreach (i, x; a) { # result[i] = x + b[i]; # } # return result.dup; # } # # int[] foo = [1, 2, 3] , # bar = [4, 5, 6] ; # # int[] xyz = foo + bar ; // (foo.opAdd(bar)) -> (.opAdd(foo, bar)) == [5, 7, 9] Just a crazy thought. -- Chris Nicholson-Sauls
Jul 08 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:
 Lucas Goss wrote:
 Is there any benefit to having a separate symbol for adding (ok, 
 concatenating)? If not feel free to break the language here too.

Concatenation is quite different from addition: int[3] a = [1,2,3]; int[3] b = [4,5,6]; int[] c = a + b; // c[] = [5,7,9] int[] d = a ~ b; // d[] = [1,2,3,4,5,6] Two distinct operators are necessary.

Ah, thanks! That makes sense. Lucas
Jul 01 2006
prev sibling parent reply kris <foo bar.com> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 
 Another problem happens when people try to transliterate C++ code into 
 D. That doesn't work very well - you have to rethink things a bit.

In my experience, transliterating C++ to D allows for a lot of code to simply be tossed out. It's issues like this that aren't obvious from simply reading a spec.
 Nevertheless, I still regard D as a better C++. Not in terms of being 
 a true superset, but in terms of being a better solution to the same 
 types of problems that C++ is targetted at. Note that C++ isn't a true 
 superset of C, either, although it is billed as a "better C".

I've yet to do the same level of work in D that I do in C++, but so far I'd have to agree. And I'm looking forward to some more ambitious projects once the framework is sorted out sufficiently. That said, I do think D's lack of any sort of const checking may be an issue for large projects (I haven't done this level of development in Java so I don't have a good non-C++ basis for comparison here). I know the issue has been beaten to death in the past, but perhaps we could do with a constructive discussion before 1.0 appears on the horizon? I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen? Sean

As someone with a substantial body of D code, I'd be happy to retrofit the whole darned thing to get const. I'd say "go for it" (as long as it supports returning an array as a const, without .dup being involved)
Jun 30 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
kris wrote:

 Sean Kelly wrote:
 Walter Bright wrote:
 
 Another problem happens when people try to transliterate C++ code into
 D. That doesn't work very well - you have to rethink things a bit.

In my experience, transliterating C++ to D allows for a lot of code to simply be tossed out. It's issues like this that aren't obvious from simply reading a spec.
 Nevertheless, I still regard D as a better C++. Not in terms of being
 a true superset, but in terms of being a better solution to the same
 types of problems that C++ is targetted at. Note that C++ isn't a true
 superset of C, either, although it is billed as a "better C".

I've yet to do the same level of work in D that I do in C++, but so far I'd have to agree. And I'm looking forward to some more ambitious projects once the framework is sorted out sufficiently. That said, I do think D's lack of any sort of const checking may be an issue for large projects (I haven't done this level of development in Java so I don't have a good non-C++ basis for comparison here). I know the issue has been beaten to death in the past, but perhaps we could do with a constructive discussion before 1.0 appears on the horizon? I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen? Sean

As someone with a substantial body of D code, I'd be happy to retrofit the whole darned thing to get const. I'd say "go for it" (as long as it supports returning an array as a const, without .dup being involved)

As someone without a substantial body of D code, I'd be happy to retrofit other's code if necessary. In all other respects (on this particular matter), I just agree with Kris :) -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jun 30 2006
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
Mike Parker wrote:
 clayasaurus wrote:
 Jarrett Billingsley wrote:
 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...

 Read my post on LTU and snk_kid's response:

snk_kid is just another C++ fanboy. I'm dealing with him on gamedev.net too.

link?

Shame on you, Clay, for not keeping up with my blog! http://www.gamedev.net/community/forums/topic.asp?topic_id=400729

aye, I've been busy lately :-P
Jun 30 2006