D - Properties
- Martin York (15/15) Jan 14 2002 I was looking at the properties part of the syntax and thinking this was...
- Pavel Minayev (7/17) Jan 14 2002 In D, there is not :: nor ->
- Martin York (10/19) Jan 14 2002 OK.
- Pavel Minayev (12/18) Jan 14 2002 I don't know why Walter did so, but I guess it adds too much complexity,
- Martin York (6/7) Jan 14 2002 IMHO: Because you know exactly when destructors are
- Juan Carlos Arevalo Baeza (27/33) Jan 14 2002 That's one reason. It's been argued a lot with Java. Java doesn't all...
- Walter (5/14) Jan 16 2002 Keep
- Sean L. Palmer (10/24) Jan 16 2002 Luckily those few brave souls who actually know how can just make a libr...
- Juan Carlos Arevalo Baeza (8/18) Jan 16 2002 library
- Sean L. Palmer (9/29) Jan 17 2002 It has a lot of interesting things, things I'd want C++ to have, but yea...
- Juan Carlos Arevalo Baeza (14/26) Jan 16 2002 vectors,
- Walter (15/24) Jan 16 2002 C++ does have a lot of tools in it. But it's missing important features
- Pavel Minayev (8/13) Jan 17 2002 Well, D also has a lot of tools in it (GC, DBC, unittests). But it's mis...
- Pavel Minayev (1/1) Jan 17 2002 oops, forgot default values for function parameters! =)
- Russell Borogove (7/13) Jan 17 2002 Come on, lay off of Walter. He's expressed the intent to
- Pavel Minayev (3/5) Jan 17 2002 Heh, yes!
- Pavel Minayev (6/9) Jan 15 2002 Just don't write code in destructors that relies on order
I was looking at the properties part of the syntax and thinking this was a great idea. But this really looks like static methods and the syntax should reflect this. int::size() /*Access the static member size() for the class int. returns the size of an int*/ (4).size() /* This again access the static member of the object 4. where 4 is an instance of the int class.*/ Which leads me onto everything as objects (including what are considered the base types). Whatever happens don't do what Java did and have (int and Integer [basic and class types]). just my 0.02p Has this topic been discussed before? Martin
Jan 14 2002
"Martin York" <Martin.York veritas.com> wrote in message news:a1v6s4$1fvn$1 digitaldaemon.com...I was looking at the properties part of the syntax and thinking this was a great idea. But this really looks like static methods and the syntax should reflect this. int::size() /*Access the static member size() for the class int. returns the size of an int*/ (4).size() /* This again access the static member of the object 4. where 4 is an instance of the int class.*/In D, there is not :: nor -> You always use dot, and the compiler determines what you've meant by the context.Which leads me onto everything as objects (including what are consideredthebase types).Would be too bloatsome, IMO.
Jan 14 2002
OK. I have re-read the section that mentions that all objects are created on the heap using the new operator (like Java). Do you have any references that I could read that persuaded you to use this java like style, rather than following the C++ style that allows you to have local objects that are created on stack and automatically destroyed at the end of the scope.int::size() /*static member size() for the class int.*/ (4).size() /* static member of the object 4.*/ /*where 4 is an instance of the int class.*/In D, there is not :: nor -> You always use dot, and the compiler determines what you've meant by the context.Yes. If all instances of a class are implemented as pointers to the object I would agree. Martin.Which leads me onto everything as objects (including what are considered the base types).Would be too bloatsome, IMO.
Jan 14 2002
"Martin York" <Martin.York veritas.com> wrote in message news:a1vc3b$1j9d$1 digitaldaemon.com...I have re-read the section that mentions that all objects are created on the heap using the new operator (like Java). Do you have any references that I could read that persuaded you to use this java like style, rather than following the C++ style that allows you to have local objects that are created on stack and automatically destroyed at the end of the scope.I don't know why Walter did so, but I guess it adds too much complexity, while giving too little. Because of the ability of objects to exist on stack and be passed by value, C++ employs things like references, copy constructors (with a whole bunch of associated rules), assignment ops etc... most other languages deal with this simply by disallowing "object" variables at all - you always work with references. This is not only the Java way, the same can be seen in Object Pascal (btw for those who remember, it first had stack objects in BP5-7, but in Delphi they were replaced by references), VB... What big advantages are in creating objects on stack, anyhow?
Jan 14 2002
What big advantages are in creating objects on stack, anyhow?IMHO: Because you know exactly when destructors are being called, resource management (memory but mainly other) is excellent when using stack based objects. I would loke to know bad points (apart from the obvious complexity issues). Martin
Jan 14 2002
"Martin York" <Martin.York veritas.com> wrote in message news:a1vpav$1rgj$1 digitaldaemon.com...That's one reason. It's been argued a lot with Java. Java doesn't allow destructors. The justification for this is that they are not needed, as memory will be recalled as appropriate. The problem is that destructors are useful not only to release memory, but to release other kinds of resources (mutex locks, file handles, sockets, etc...). Thus, having destructors is a good thing. Now comes the million-dollar question: when does an object's destructor get called, when the object is never explicitly destroyed? The answer: maybe never. Thus rendering them useless when all objects are alllocated on the heap and garbage collected. In short, this memory model makes the lifes of the compiler makers and the language users easier, as long as they don't need the kind of automatic resource management that has become ubiquitous in C++. I wouldn't want to live without stack-based objects, precisely for this reason. The other reason is that this memory model widens the gap between predefined types and user-defined types. And that's, IMHO, going in the wrong direction. Instead of adding complex numbers and whatnot to the language (for performance reasons and to avoid user-defined overloaded operators), the language should allow those complex numbers (and vectors, and matrices, etc...) to be easily created and integrated as libraries. Keep the core language simple, and allow libraries to add the complex bits. That's my opinion. It's one of the strengths of C++, even if it's somewhat incomplete and with rough corners there. Salutaciones, JCABWhat big advantages are in creating objects on stack, anyhow?IMHO: Because you know exactly when destructors are being called, resource management (memory but mainly other) is excellent when using stack based objects.
Jan 14 2002
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:a20eab$28mc$1 digitaldaemon.com...The other reason is that this memory model widens the gap between predefined types and user-defined types. And that's, IMHO, going in the wrong direction. Instead of adding complex numbers and whatnot to the language (for performance reasons and to avoid user-defined overloaded operators), the language should allow those complex numbers (and vectors, and matrices, etc...) to be easily created and integrated as libraries.Keepthe core language simple, and allow libraries to add the complex bits. That's my opinion. It's one of the strengths of C++, even if it's somewhat incomplete and with rough corners there.It's not at all easy to create user-defined types with overloaded operators in C++.
Jan 16 2002
Luckily those few brave souls who actually know how can just make a library for use by the masses that can't figure it out. With D, *nobody* can make types with overloaded operators except you, Walter. Sean "Walter" <walter digitalmars.com> wrote in message news:a24id1$1uqg$1 digitaldaemon.com..."Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:a20eab$28mc$1 digitaldaemon.com...vectors,The other reason is that this memory model widens the gap between predefined types and user-defined types. And that's, IMHO, going in the wrong direction. Instead of adding complex numbers and whatnot to the language (for performance reasons and to avoid user-defined overloaded operators), the language should allow those complex numbers (andsomewhatand matrices, etc...) to be easily created and integrated as libraries.Keepthe core language simple, and allow libraries to add the complex bits. That's my opinion. It's one of the strengths of C++, even if it'soperatorsincomplete and with rough corners there.It's not at all easy to create user-defined types with overloadedin C++.
Jan 16 2002
"Sean L. Palmer" <spalmer iname.com> wrote in message news:a24ln6$20tb$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:a24id1$1uqg$1 digitaldaemon.com...libraryIt's not at all easy to create user-defined types with overloadedoperatorsin C++.Luckily those few brave souls who actually know how can just make afor use by the masses that can't figure it out. With D, *nobody* can make types with overloaded operators except you, Walter.:) I guess you and I agree that D is not for us, Sean. It does make for some very interesting discussions, though. And the whole DBC thing is very cool indeed. Salutaciones, JCAB
Jan 16 2002
It has a lot of interesting things, things I'd want C++ to have, but yeah probably C++ will remain my main tool for a while. I could get some use out of D for making tools perhaps. Stuff like Perl and Ruby are just too wierd for me. C++ is kind of a pain for little tools. I can only hope the new C++ standard committee maybe learns a few things Sean "Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:a24nq2$2211$1 digitaldaemon.com..."Sean L. Palmer" <spalmer iname.com> wrote in message news:a24ln6$20tb$1 digitaldaemon.com..."Walter" <walter digitalmars.com> wrote in message news:a24id1$1uqg$1 digitaldaemon.com...libraryIt's not at all easy to create user-defined types with overloadedoperatorsin C++.Luckily those few brave souls who actually know how can just make afor use by the masses that can't figure it out. With D, *nobody* can make types with overloaded operators except you, Walter.:) I guess you and I agree that D is not for us, Sean. It does make for some very interesting discussions, though. And the whole DBC thing is very cool indeed. Salutaciones, JCAB
Jan 17 2002
"Walter" <walter digitalmars.com> wrote in message news:a24id1$1uqg$1 digitaldaemon.com..."Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:a20eab$28mc$1 digitaldaemon.com...vectors,Instead of adding complex numbers and whatnot to the language (for performance reasons and to avoid user-defined overloaded operators), the language should allow those complex numbers (andsomewhatand matrices, etc...) to be easily created and integrated as libraries.Keepthe core language simple, and allow libraries to add the complex bits. That's my opinion. It's one of the strengths of C++, even if it'soperatorsincomplete and with rough corners there.It's not at all easy to create user-defined types with overloadedin C++.Well... no. Generally speaking, no simple task is easy in C++. The main problem with that language (and its main strength, too) is that it's more like an untidy and quite full bag of tools. Many of those tools need "qualified experts" to handle them, though. This means that you can do A LOT of different things with the language, but it also means that the result is never optimal. Salutaciones, JCAB
Jan 16 2002
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message news:a24nrc$2217$1 digitaldaemon.com...Well... no. Generally speaking, no simple task is easy in C++. The main problem with that language (and its main strength, too) is that it's more like an untidy and quite full bag of tools. Many of those tools need "qualified experts" to handle them, though. This means that you can do A LOT of different things with the language, but it also means that the result is never optimal. Salutaciones, JCABC++ does have a lot of tools in it. But it's missing important features like: 1) garbage collection 2) design by contract 3) support for unit testing It certainly is possible to use garbage collection with C++, and I do so myself. But two words that describe using gc with C++ are do it "very carefully". Garbage collectors for C++ have not caught on likely for that reason. You can emulate DBC in C++ with a collection of ungainly macros and virtual functions. The result is not too attractive. Ditto for unit testing. Of course, everything you can do in C++ can also be done in C, as cfront proves <g>.
Jan 16 2002
"Walter" <walter digitalmars.com> wrote in message news:a24t94$25gp$1 digitaldaemon.com...C++ does have a lot of tools in it. But it's missing important features like: 1) garbage collection 2) design by contract 3) support for unit testingWell, D also has a lot of tools in it (GC, DBC, unittests). But it's missing important features like: 1) operator overloading 2) templates 3) adequate support for strings =)
Jan 17 2002
oops, forgot default values for function parameters! =)
Jan 17 2002
Pavel Minayev wrote:Well, D also has a lot of tools in it (GC, DBC, unittests). But it's missing important features like: 1) operator overloading 2) templatesCome on, lay off of Walter. He's expressed the intent to support some form of generic programming at some point in the future. And he _will_ come around on operator overloading or I'll break his thumbs.3) adequate support for stringsAdequate meaning "having a dedicated comparison operator?" -RB
Jan 17 2002
"Russell Borogove" <kaleja estarcion.com> wrote in message news:3C4706DD.7070306 estarcion.com...Heh, yes!3) adequate support for stringsAdequate meaning "having a dedicated comparison operator?"
Jan 17 2002
"Martin York" <Martin.York veritas.com> wrote in message news:a1vpav$1rgj$1 digitaldaemon.com...IMHO: Because you know exactly when destructors are being called, resource management (memory but mainly other) is excellent when using stack based objects.Just don't write code in destructors that relies on order of destruction... Alternatively, the delete operator can be used - AFAIK it calls the destructor immediately.
Jan 15 2002