www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OOP

reply imr1984 <imr1984_member pathlink.com> writes:
is anyone else here using D in a C stlye way, ie billions of globals, almost no
classes etc?

D just appeals to me because of its much cleaner syntax and no header files, not
because of its great OOP capabilities. I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.
May 17 2004
next sibling parent reply Charlie <Charlie_member pathlink.com> writes:
In article <c8ac4b$2kt4$1 digitaldaemon.com>, imr1984 says...
is anyone else here using D in a C stlye way, ie billions of globals, almost no
classes etc?

D just appeals to me because of its much cleaner syntax and no header files, not
because of its great OOP capabilities. I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.

is anyone else here using D in a C stlye way, ie billions of globals, almost no
classes etc?

Probably, Ive seen functional style D , and while I like OO, sometimes it fits better to have free functions . In fact Id much prefer if the Phobos was all a set of free functions , with an optional OO wrappers to all of it. Right now its all mixed in all flibbily bibbily stlye , no consistency to speak of.
I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.

I never liked this either, if the getters and setters do nothing more then just that ( i.e. they might check a value for a condition etc ) , then why not just make the data public ? Even this month I read an article in favor of getters and setters in CUJ, I like python style much better. Charlie
May 17 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Charlie" <Charlie_member pathlink.com> wrote in message
news:c8aq9o$94k$1 digitaldaemon.com...
 I never liked this either, if the getters and setters do nothing more then

 that ( i.e. they might check a value for a condition etc ) , then why not

 make the data public ?

I agree. The common get/set for a simple member variable just looks like clutter to me.
May 17 2004
parent reply Derek <ddparnell bigpond.com> writes:
On Mon, 17 May 2004 15:01:18 -0700, Walter wrote:

 "Charlie" <Charlie_member pathlink.com> wrote in message
 news:c8aq9o$94k$1 digitaldaemon.com...
 I never liked this either, if the getters and setters do nothing more then

 that ( i.e. they might check a value for a condition etc ) , then why not

 make the data public ?

I agree. The common get/set for a simple member variable just looks like clutter to me.

Having public data elements tightly binds modules together. That is to say, if a class's data elements are public it allows code using that class to be dependant on it, thus making it hard to modify the class without breaking already written code. J. Anderson has mentioned that fortunately, D can help resolve this by using its property technique. Basically, if a public data element needs to be changed in some way by the class author, they can rename the public data element and make it private and create a property with the old name and datatype argument. Then the class author can handle the case where existing code is using the old data form. Example: from... class Foo { public float XX; . . . } to ... class Foo { private int _XX; public XX(float x) { if (x >= 0) _XX = cast(int)x; else _XX = 0; } public float XX(){ return cast(float)_XX;} . . . } -- Derek Melbourne, Australia
May 17 2004
parent reply Sean Kelly <sean ffwd.cx> writes:
Derek wrote:
 
 J. Anderson has mentioned that fortunately, D can help resolve this by
 using its property technique.

Not to quibble, but I said this :) Sean
May 17 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 17 May 2004 16:16:48 -0700, Sean Kelly wrote:

 Derek wrote:
 
 J. Anderson has mentioned that fortunately, D can help resolve this by
 using its property technique.

Not to quibble, but I said this :) Sean

Sorry, Sean. I was referring to something that J. Anderson wrote in message id <c7pb5h$1lei$1 digitaldaemon.com> on the 11/May. And I quote ... " I used to program that way. With D because of property methods I've found many cases where exposing properties as public is a good thing. I mean with C++, the convention was to have get/set everywhere. With D you can convert a property into a method without affecting the outside user (users being the people extending the class or using an instance). I look at each properties on its own merit and try to decide if an external user would have any good use for it. Of course there are properties that are unsafe, have some quirky rule or ify (undecided) which I make private or protected. They can always be made public later. I don't make everything public but I look on things from the other prospective. " I was replying to a message from Walter (08:01am in Melbourne, Aus) and it looks as though while I was typing my response, your message came in (8:33am) and I didn't get to read it before sending mine off. So it seems that there are at least two great D minds. ;-) -- Derek 18/May/04 9:51:18 AM
May 17 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Just to give a little bit more due credit, Matthew Wilson said nearly 
that already long, long ago - long before properties were actually 
implemented. With some (beware a shameless plug) very little assistance 
from myself, steering some deciding arguments in. :) That's what Delphi 
programmers have been doing already ages ago. Now, if D would also try 
to bolt-on some meaning for the compound assignment operators... I admit 
this is questionable.

-eye

Derek Parnell schrieb:
 On Mon, 17 May 2004 16:16:48 -0700, Sean Kelly wrote:
 
 
Derek wrote:

J. Anderson has mentioned that fortunately, D can help resolve this by
using its property technique.

Not to quibble, but I said this :) Sean

Sorry, Sean. I was referring to something that J. Anderson wrote in message id <c7pb5h$1lei$1 digitaldaemon.com> on the 11/May. And I quote ... " I used to program that way. With D because of property methods I've found many cases where exposing properties as public is a good thing. I mean with C++, the convention was to have get/set everywhere. With D you can convert a property into a method without affecting the outside user (users being the people extending the class or using an instance). I look at each properties on its own merit and try to decide if an external user would have any good use for it. Of course there are properties that are unsafe, have some quirky rule or ify (undecided) which I make private or protected. They can always be made public later. I don't make everything public but I look on things from the other prospective. " I was replying to a message from Walter (08:01am in Melbourne, Aus) and it looks as though while I was typing my response, your message came in (8:33am) and I didn't get to read it before sending mine off. So it seems that there are at least two great D minds. ;-)

May 27 2004
prev sibling next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
Charlie wrote:
 In article <c8ac4b$2kt4$1 digitaldaemon.com>, imr1984 says...

I especially dont like member protection
because im a bedroom coder so i work on my own, so protecting member variables
doesnt really appeal to me.

I never liked this either, if the getters and setters do nothing more then just that ( i.e. they might check a value for a condition etc ) , then why not just make the data public ? Even this month I read an article in favor of getters and setters in CUJ, I like python style much better.

While I personally dislike get/set methods I do understand the reasoning behind them. They are a pre-emptive tactic to enable back-end changes without requiring user-side code changes. However, properties in D pretty much eliminate the need for this tactic, as there is no semantic difference between public variables and property methods. It's worth noting that properties have been proposed as an addition to the next version of C++ (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf), probably for this exact reason. Sean
May 17 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c8bej6$181f$1 digitaldaemon.com...
 While I personally dislike get/set methods I do understand the reasoning
 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no semantic
 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.

Someday, C++ may catch up with D <g>.
May 17 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c8bjdv$1eun$1 digitaldaemon.com...
 "Sean Kelly" <sean ffwd.cx> wrote in message
 news:c8bej6$181f$1 digitaldaemon.com...
 While I personally dislike get/set methods I do understand the reasoning
 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no semantic
 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.

Someday, C++ may catch up with D <g>.

I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that D is around the corner. He told me to leave him alone and go use D, and that C++ is not gonna change anytime soon (although he said it very politely). I guess some people never realize when their time is over.
May 18 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 Someday, C++ may catch up with D <g>.


 is around the corner. He told me to leave him alone and go use D, and that
 C++ is not gonna change anytime soon (although he said it very politely).

 I guess some people never realize when their time is over.

D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming community. C++ was a great leap forward, and it practically invented generic metaprogramming. C++ isn't going away in the forseeable future. I fully expect that future C++ standards will incorporate some of D's innovations, in an analogous way that C has adopted some C++ innovations. Bjarne is right, though, in suggesting that this will not happen anytime soon. The C++ standardization process is agonizingly slow (and should be, for a mature language). And, in due course, D will eventually be run over by a new upstart, D++ <g>.
May 18 2004
next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
Walter wrote:
 
 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming community.
 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

And don't forget Alexander Stepanov. C++ may not have existed without Bjarne, but generics may not have existed without Alexander. For the uninitiated, there's a good interview here: http://www.stlport.org/resources/StepanovUSA.html
 C++ isn't going away in the forseeable future. I fully expect that future
 C++ standards will incorporate some of D's innovations, in an analogous way
 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++ standardization
 process is agonizingly slow (and should be, for a mature language).

Of course. The C++ community would go nuts if the language changed too quickly. But the language's stability is one of the reasons I favor it over the latest greatest whatever. That's both the blessing and the curse of backwards compatibility.
 And, in due course, D will eventually be run over by a new upstart, D++ <g>.

Certainly. But before then I hope that D will have contributed some new ideas and techniques to the programming world. Otherwise, why are we here? :) Sean
May 20 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c8iq5m$1au5$1 digitaldaemon.com...
 Walter wrote:
 D stands on the shoulders of giants, and one of those giants is Bjarne
 Stroustrup. Bjarne has made huge contributions to the programming


 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

And don't forget Alexander Stepanov. C++ may not have existed without Bjarne, but generics may not have existed without Alexander. For the uninitiated, there's a good interview here: http://www.stlport.org/resources/StepanovUSA.html

Yes, you're right. And Bjarne deserves the credit for understanding Stepanov's work and endorsing/incorporating it, when it would have been easy to ignore it.
 C++ isn't going away in the forseeable future. I fully expect that


 C++ standards will incorporate some of D's innovations, in an analogous


 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++


 process is agonizingly slow (and should be, for a mature language).

Of course. The C++ community would go nuts if the language changed too quickly. But the language's stability is one of the reasons I favor it over the latest greatest whatever. That's both the blessing and the curse of backwards compatibility.
 And, in due course, D will eventually be run over by a new upstart, D++


 Certainly.  But before then I hope that D will have contributed some new
 ideas and techniques to the programming world.  Otherwise, why are we
 here? :)

Yes, indeed.
May 21 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c8e2mb$2h8v$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 Someday, C++ may catch up with D <g>.



 D
 is around the corner. He told me to leave him alone and go use D, and


 C++ is not gonna change anytime soon (although he said it very


 I guess some people never realize when their time is over.

D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that future
 C++ standards will incorporate some of D's innovations, in an analogous

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++ standardization
 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart, D++


But why is it such a slow process ? I myself can work for a couple of hours and produce a better C++ spec...how come these people need years to do so ? I think some people are overhyped. With all due respect to mr Stroustrup, if he can't see that C++ has major flaws that need to be fixed *yesterday*, what can I say ? Let Java dominate, then.
May 22 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8nmek$u31$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 Someday, C++ may catch up with D <g>.



 D
 is around the corner. He told me to leave him alone and go use D, and


 C++ is not gonna change anytime soon (although he said it very


 I guess some people never realize when their time is over.

D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that future
 C++ standards will incorporate some of D's innovations, in an analogous

 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++ standardization
 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart, D++


But why is it such a slow process ? I myself can work for a couple of hours and produce a better C++ spec...how come these people need years to do so ?

Wow! Arrogance, coupled with ...
 I think some people are overhyped. With all due respect to mr Stroustrup, if

... ignorance (it's Dr Stroustrup)
 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.

... and stupidity. What a package!
May 22 2004
parent reply "Phill" <phill pacific.net.au> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c8ns6g$1697$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8nmek$u31$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 Someday, C++ may catch up with D <g>.





 that
 D
 is around the corner. He told me to leave him alone and go use D,




 that
 C++ is not gonna change anytime soon (although he said it very


 I guess some people never realize when their time is over.

D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that



 C++ standards will incorporate some of D's innovations, in an



 way
 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++



 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart,



 <g>.

But why is it such a slow process ? I myself can work for a couple of


 and produce a better C++ spec...how come these people need years to do


 Wow!

 Arrogance, coupled with  ...

 I think some people are overhyped. With all due respect to mr


 ... ignorance (it's Dr Stroustrup)

 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.

... and stupidity. What a package!

was wrapped in Bull S**t
May 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Phill" <phill pacific.net.au> wrote in message
news:c8pimj$hve$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c8ns6g$1697$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8nmek$u31$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 Someday, C++ may catch up with D <g>.





 that
 D
 is around the corner. He told me to leave him alone and go use D,




 that
 C++ is not gonna change anytime soon (although he said it very


 I guess some people never realize when their time is over.

D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that



 C++ standards will incorporate some of D's innovations, in an



 way
 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++



 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart,



 <g>.

But why is it such a slow process ? I myself can work for a couple of


 and produce a better C++ spec...how come these people need years to do


 Wow!

 Arrogance, coupled with  ...

 I think some people are overhyped. With all due respect to mr


 ... ignorance (it's Dr Stroustrup)

 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.

... and stupidity. What a package!

was wrapped in Bull S**t

Well, maybe I came off a bit strong, but I fail to see how such disrespect should be tolerated. Technically Bjarne Stroustrup is a very smart man. Moreover, he is an exceedingly foresightful man - just check my latest article in this month's CUJ in June, which describes a new technique for dramatically improving the performance of string concatenation in any C++ libraries in a thoroughly safe and non-intrusive manner. This was inspired by some research I was doing for the book on another matter - user-defined cast operators (Imperfect C++, Chapter 19, if you're interested) - that caused me to read a certain part of The C++ Programming Language. That was an unconscious bit of smarts on the part of Dr Stroustrup. As for a conscious one, he told me that he did indeed foresee the merging of template and C++ cast syntax, in smart casts. Furthermore, he's a very responsive man, and invariably helpful (even if he's necessarily terse). I have had occasion to have information and encouragement from him throughout the last year or so wrt my preparation of Imperfect C++, and I can tell you he's a very nice, genuine, fellow. Given that he could potentially be receiving emails from the 3-5 million C++ programmers in the world, that's pretty good work. A bit more respect for those whose shoulders we stand upon costs nothing, and shouldn't hurt anyone's ego. Maybe when AM has invented a language that is used to implement a significant proportion of the worlds operating systems, and the software that runs on it, I'll pay more credence to his invective. -- Matthew Wilson Author: "Imperfect C++", Addison-Wesley, 2004 (www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) ------------------------------------------------------------------------------- "So far, C++ is the best language I've discovered to say what I want to say" -- Alex Stepanov -------------------------------------------------------------------------------
May 23 2004
next sibling parent "Phill" <phill pacific.net.au> writes:
 A bit more respect for those whose shoulders we stand upon costs nothing,

 shouldn't hurt anyone's ego. Maybe when AM has invented a language that is

 to implement a significant proportion of the worlds operating systems, and

 software that runs on it, I'll pay more credence to his invective.

I agree, and i'd certainly love to see the C++ spec's that he(AM) can come up with in a "couple of hours" work.
May 23 2004
prev sibling parent Achilleas Margaritis <Achilleas_member pathlink.com> writes:
In article <c8qa63$1iu5$1 digitaldaemon.com>, Matthew says...
"Phill" <phill pacific.net.au> wrote in message
news:c8pimj$hve$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c8ns6g$1697$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8nmek$u31$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 Someday, C++ may catch up with D <g>.





 that
 D
 is around the corner. He told me to leave him alone and go use D,




 that
 C++ is not gonna change anytime soon (although he said it very


 I guess some people never realize when their time is over.

D stands on the shoulders of giants, and one of those giants is Bjarne Stroustrup. Bjarne has made huge contributions to the programming

 C++ was a great leap forward, and it practically invented generic
 metaprogramming.

 C++ isn't going away in the forseeable future. I fully expect that



 C++ standards will incorporate some of D's innovations, in an



 way
 that C has adopted some C++ innovations. Bjarne is right, though, in
 suggesting that this will not happen anytime soon. The C++



 process is agonizingly slow (and should be, for a mature language).

 And, in due course, D will eventually be run over by a new upstart,



 <g>.

But why is it such a slow process ? I myself can work for a couple of


 and produce a better C++ spec...how come these people need years to do


 Wow!

 Arrogance, coupled with  ...

 I think some people are overhyped. With all due respect to mr


 ... ignorance (it's Dr Stroustrup)

 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.

... and stupidity. What a package!

was wrapped in Bull S**t

Well, maybe I came off a bit strong, but I fail to see how such disrespect should be tolerated. Technically Bjarne Stroustrup is a very smart man. Moreover, he is an exceedingly foresightful man - just check my latest article in this month's CUJ in June, which describes a new technique for dramatically improving the performance of string concatenation in any C++ libraries in a thoroughly safe and non-intrusive manner. This was inspired by some research I was doing for the book on another matter - user-defined cast operators (Imperfect C++, Chapter 19, if you're interested) - that caused me to read a certain part of The C++ Programming Language. That was an unconscious bit of smarts on the part of Dr Stroustrup. As for a conscious one, he told me that he did indeed foresee the merging of template and C++ cast syntax, in smart casts. Furthermore, he's a very responsive man, and invariably helpful (even if he's necessarily terse). I have had occasion to have information and encouragement from him throughout the last year or so wrt my preparation of Imperfect C++, and I can tell you he's a very nice, genuine, fellow. Given that he could potentially be receiving emails from the 3-5 million C++ programmers in the world, that's pretty good work. A bit more respect for those whose shoulders we stand upon costs nothing, and shouldn't hurt anyone's ego. Maybe when AM has invented a language that is used to implement a significant proportion of the worlds operating systems, and the software that runs on it, I'll pay more credence to his invective. -- Matthew Wilson Author: "Imperfect C++", Addison-Wesley, 2004 (www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) ------------------------------------------------------------------------------- "So far, C++ is the best language I've discovered to say what I want to say" -- Alex Stepanov -------------------------------------------------------------------------------

I never spoken with bad words for you, Matthew. In fact, I was deeply annoyed by your attitude (see "clear your mixins out of my aggregates")...it sounded as if the sole puprose of the D language is to fit your needs, and not to apply to millions of programmers across the globe. With my words I wanted to stirr the pot, as well as express my question about how C++ is developed so slowly. I am not disrespecting anyone, nor I will take a chance to call you an arrogant moron, no matter how hard I want to do so. I could develop a language, If I had the time to. The fact that I work for 8 to 12 hours a day developing real-time defense applications does not leave me any time to develop my own programming language. But that does not stop me from expressing what I desire from a good language. Mr Stroustrup works for a University and has the time and resources to develop whatever he wants, and present it as research...Walter makes a living out of it. On the other hand, I am in a country that only recently has seen great developments in computers (and until recently, Basic was tought as a the first programming language in computer science courses!)...I did not have a choice to develop my own language, I have to work for another man's company. Do you want to see If I can come up with many C++ improvements, in a blink of an eye, that would not break backwards compatibility anytime ? ok, here are some of them: -strings as primitive types: new data types 'string', 'wstring', 'dstring': string foo1; wstring foo2; dstring foo3; -class properties: class Foo { public: //property property name { public: //getter string operator () () const { return m_value; } //setter void operator = (string text) { m_value = text; } private: //value string m_value; } } -class partioning: //partitioned class class Foo { public: partition SomePart { void bar() { } } } //usage Foo foo1; foo1.SomePart.bar() { } -reflection: a vtable entry which points to class data: a method table for accessing all class methods and fields. used like: Foo foo = new Foo; foo.class.method("action1", 10, 20, 30); -variants: variant v1; v1 = 5; v1 = "foo"; int i = v1; -safe variable argument lists using the variant type. -multithreading, synchronized keyword and mutex primitive: mutex m_mutex; synchronized (mutex) { <bla bla> } -signals and slots: //class with signals class MyDocument { public: signal renamed(string name); } //class with slots class Controller { public: slot onDocumentRenamed(string name) { <bla bla> } } //use signals and slots document1.renamed += controller1.onDocumentRenamed; -a new type of file extension that would solve the problem of header/implementation files: when the compiler met such a file, it would treat as a translation unit, not expecting include files and such. It could be combined with 'import' statements, as in D, with symbol processing instead of text processing. -garbage collection through the 'gc' attribute: //garbage collected class gc class Foo { } -make the -> and :: operators reduntant. -add design-by-contract, as in D. -add a 'foreach' statement. -make 'switch' able to work on non-primive types, like strings. -introduce strong typedefs with a new keyword. -add delegates to object methods and functions. -improve enums by making them strong typedefs which define a scope (as in D). -provide versioning. -make the 'operator' keyword optional. It does not make any difference, from the parsing point of view, to have it: the symbol tokens should be put within a known range, and then be recognized by the syntax analyser by a simple 'if token
= TOKEN_OPERATOR_FIRST && token <= TOKEN_OPERATOR_LAST).

-provide 'and', 'or' and 'not' boolean operators, to make the language better looking. -make the ';' after class and struct declarations optional. -provide for registered classes: allow 'new' with class names, instead of types: MyObject* foo = new "MyClass"; This, coupled with reflection, would make run-time plug-in management a breeze. As it is right now, the compiler already keeps class info through the 'type_info' structure. -make cast operators optional. Why one should need 'static_cast' etc ? a simple casting, if it is between classes, could be worked out at compile time if it is static or dynamic. -provide new types of standard length across all platforms. -provide code splitting between different files, through usage of some keyword combinations. -provide optional initialization of data with their default values. -make null a keyword. -provide strong types with ranges, like this: strong typedef int(1..10) Index; -provide static properties to types. -provide compound primitives: struct Vector { int x; int y; int z; } s = {10, 20, 30}; -provide sequence lists: sequence s = [1, 2, 3, 4, 5, "foo", object1]; -provide a new keyword 'function' which could make the language functional: assignment would not be allowed during 'function' calls, and calling procedures would not be allowed through functions. A function would make state change not allowed: class Foo { public: function int action(Bar bar1) { <bla bla state } } -provide an 'abstract' keyword. -provide managed state changes! Let the programmer model a variable's states, the state changes and the actions to be taken in order to change states. Then, the programmer could not accidentally make unwanted state changes, and many logical errors could be cought at compile time! and in run-time, throw exceptions when a state is violated. -provide for error report customization. For example, instead of 'syntax error', one could say 'class Foo must not inherit from class Bar' or something like that. -provide for data modelling like XML, but inside the language. One could than write compile-time or run-time models of data, expressing them in the simplest way possible. How all these features break backwards compatibility ? they don't. In fact, they are nice additions which solve many issues amongst developers, improve the quality of the programs, elevate the status of the language and give it new life. After all, D exists and has many of these capabilities, just because C++ just does not have these. If C++ had all these, D would not exist. Hey, I've spend a couple of minutes typing this stuff into...if I looked really hard, I could add a dozen more features. And this stuff is trivially easy to incorporate into the C++ language (many of them can already be provided in the form of code), but it will make a hell of a difference to developers. But it will never be done so, because someone has decided that it should take decades of years, when in fact it could take a few months for most compiler vendors to support them. Really wise men know how to talk with their ears, i.e. listen to everyone's opinions, even the lowly ones like me, and then rule things out based on logic and arguments. You have chosen to insult me first...what else can I say, other than you are really immature as a person.
May 24 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8nmek$u31$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8e2mb$2h8v$1 digitaldaemon.com...
 The C++ standardization
 process is agonizingly slow (and should be, for a mature language).


Committees always are. The C++ standards committee is composed of people all over the world, and there's a formal process to go through to make any changes. It's set up to try and produce consensus, and that takes time. Lots of people need to look at it, get to comment, there are public reviews, etc. It's all there to try and ensure any changes are really needed and won't break entrenched existing code.
 I myself can work for a couple of hours
 and produce a better C++ spec...how come these people need years to do so

Writing specs is pretty hard. It's further complicated by everything in C++ seems to affect everything else :-( When designing a new feature, it's very difficult to anticipate everything else it will perturb.
 I think some people are overhyped.

I've known Dr. Stroustrup since 1988 or so, and he's the genuine article.
 With all due respect to mr Stroustrup, if
 he can't see that C++ has major flaws that need to be fixed *yesterday*,
 what can I say ? Let Java dominate, then.

I'm sure he's well aware of the flaws in C++. The problem is, the flaws are due to the desire for backwards compatibility with legacy code. There's nothing to be done about it, short of making a break with backwards compatibility like D does.
May 23 2004
parent reply Juan C <Juan_member pathlink.com> writes:
I'm sure he's well aware of the flaws in C++. The problem is, the flaws are
due to the desire for backwards compatibility with legacy code. There's
nothing to be done about it, short of making a break with backwards
compatibility like D does.

D needs to break backward compatibility more (or however to express that in proper English grammar).
May 23 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Juan C wrote:

I'm sure he's well aware of the flaws in C++. The problem is, the flaws
are due to the desire for backwards compatibility with legacy code.
There's nothing to be done about it, short of making a break with
backwards compatibility like D does.

D needs to break backward compatibility more (or however to express that in proper English grammar).

Do you talk about details or fundamental concepts? As I understand it the idea behind D is to give up compatibility in terms of code, but not in terms of programming philosophy. A C/C++ programmer will have to relearn details, but the core concepts (what is a class, what is a function, etc.) are kept the same. I think, this is a great goal. No good programmer should have a problem learning a new syntax or adjusting to new language details, but changing your way of thinking is extremely hard once you got comfortable in one language.
May 23 2004
prev sibling next sibling parent "Phill" <phill pacific.net.au> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 "Sean Kelly" <sean ffwd.cx> wrote in message
 news:c8bej6$181f$1 digitaldaemon.com...
 While I personally dislike get/set methods I do understand the



 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no



 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.

Someday, C++ may catch up with D <g>.

I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that

 is around the corner. He told me to leave him alone and go use D, and that
 C++ is not gonna change anytime soon (although he said it very politely).

 I guess some people never realize when their time is over.

I think that time is a looooooong way off.
May 19 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c8dojk$2048$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:c8bjdv$1eun$1 digitaldaemon.com...
 "Sean Kelly" <sean ffwd.cx> wrote in message
 news:c8bej6$181f$1 digitaldaemon.com...
 While I personally dislike get/set methods I do understand the reasoning
 behind them.  They are a pre-emptive tactic to enable back-end changes
 without requiring user-side code changes.  However, properties in D
 pretty much eliminate the need for this tactic, as there is no semantic
 difference between public variables and property methods.  It's worth
 noting that properties have been proposed as an addition to the next
 version of C++
 (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf),
 probably for this exact reason.

Someday, C++ may catch up with D <g>.

I send an e-mail to Bjarne Stroustrup regarding the future of C++ now that D is around the corner. He told me to leave him alone and go use D, and that C++ is not gonna change anytime soon (although he said it very politely). I guess some people never realize when their time is over.

When will that be, then? 2030?
May 19 2004
prev sibling parent reply Mike Swieton <mike swieton.net> writes:
On Mon, 17 May 2004 16:46:48 +0000, Charlie wrote:
 I never liked this either, if the getters and setters do nothing more then
 just that ( i.e. they might check a value for a condition etc ) , then why
 not just make the data public ?  Even this month I read an article in favor
 of getters and setters in CUJ, I like python style much better.
 
 Charlie

That's why they are generally considered a bad idea. If a class is nothing but gets/sets, then it probably should have been a struct. Sure, there's proper uses for them, but when you start writing a lot of them, you should probably examine your design once, just to double check. Mike Swieton __ But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it the most? - Mark Twain
May 17 2004
next sibling parent clayasaurus <clayasaurus_member pathlink.com> writes:
In article <pan.2004.05.17.22.39.51.699006 swieton.net>, Mike Swieton says...
On Mon, 17 May 2004 16:46:48 +0000, Charlie wrote:
 I never liked this either, if the getters and setters do nothing more then
 just that ( i.e. they might check a value for a condition etc ) , then why
 not just make the data public ?  Even this month I read an article in favor
 of getters and setters in CUJ, I like python style much better.
 
 Charlie

That's why they are generally considered a bad idea. If a class is nothing but gets/sets, then it probably should have been a struct. Sure, there's proper uses for them, but when you start writing a lot of them, you should probably examine your design once, just to double check. Mike Swieton __ But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it the most? - Mark Twain

I'm creating a project that has a heavy OOP design with D. I like OOP so I don't have to use function(&datastruct) type syntaxes, rather class.function(), and using lots of globals is a bad design decision IMO. i like using get-set methods because it allows me to change the insides of a class without effecting the outside classes/programs that use that class, like if for some reason i wanted to change m_data to m_data[].
May 17 2004
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain

Does that mean that prior to eighteen centuries ago, there were people praying for Satan?
May 18 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Phill wrote:

 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain

Does that mean that prior to eighteen centuries ago, there were people praying for Satan?

I think, that citation is based on the theological thesis that before that time, there was no point in praying for sinners at all.
May 18 2004
parent reply "Phill" <phill pacific.net.au> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c8d2ee$nu6$3 digitaldaemon.com...
 Phill wrote:

 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain

Does that mean that prior to eighteen centuries ago, there were people praying for Satan?

I think, that citation is based on the theological thesis that before that time, there was no point in praying for sinners at all.

Ah right, because when Jesus was crucified everyone started on a new slate(except Satan ofcourse) so prior sins were paid for by Jesus's suffering on the cross.
May 18 2004
parent Mike Swieton <mike swieton.net> writes:
On Wed, 19 May 2004 09:27:17 +1000, Phill wrote:

 
 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:c8d2ee$nu6$3 digitaldaemon.com...
 Phill wrote:

 Mike Swieton
 __
 But who prays for Satan? Who, in eighteen centuries, has had the common
 humanity to pray for the one sinner that needed it the most?
 - Mark Twain

Does that mean that prior to eighteen centuries ago, there were people praying for Satan?

I think, that citation is based on the theological thesis that before that time, there was no point in praying for sinners at all.

Ah right, because when Jesus was crucified everyone started on a new slate(except Satan ofcourse) so prior sins were paid for by Jesus's suffering on the cross.

I think you're following the quote a bit much. I've always thought that the time (18 centuries) was there solely for emphasis, and that the salient was the "who has prayed for him" part. Perhaps I'm wrong; I don't have the context for that quote. Mike Swieton __ The Lord's Prayer is 66 words, the Gettysburg Address is 286 words, and there are 1,322 words in the Declaration of Independence. Yet, government regulations on the sale of cabbage total 26,911 words. - David McIntosh
May 18 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message
news:c8ac4b$2kt4$1 digitaldaemon.com...
 is anyone else here using D in a C stlye way, ie billions of globals,

 classes etc?

Empire is written that way.
May 17 2004
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
imr1984 wrote:
 is anyone else here using D in a C stlye way, ie billions of globals, almost no
 classes etc?

Sort of. I don't create many classes. Part of the reason of why I program so procedurally is that I'm not used to OOP. I've programmed a little in Turbo Pascal and Java, but I've mostly used forms of BASIC. Consequently, I think in functions rather than objects. As I become more comfortable with D, I seem to create more classes.
 D just appeals to me because of its much cleaner syntax and no header files,
not
 because of its great OOP capabilities. I especially dont like member protection
 because im a bedroom coder so i work on my own, so protecting member variables
 doesnt really appeal to me.

I'm in a similar position here, too. I don't have many people looking over my code, so I code how I want to code. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 17 2004