www.digitalmars.com         C & C++   DMDScript  

D - Properties

reply "Martin York" <Martin.York veritas.com> writes:
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
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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 considered


the

 base types).


Would be too bloatsome, IMO.
Jan 14 2002
parent reply "Martin York" <Martin.York veritas.com> writes:
 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.


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.


 Which leads me onto everything as objects (including what are
 considered the base types).


 Would be too bloatsome, IMO.


Yes. If all instances of a class are implemented as pointers to the object
I would agree.


Martin.
Jan 14 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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
parent reply "Martin York" <Martin.York veritas.com> writes:
 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
next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Martin York" <Martin.York veritas.com> wrote in message
news:a1vpav$1rgj$1 digitaldaemon.com...

 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.


   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,
                         JCAB
Jan 14 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.


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.


It's not at all easy to create user-defined types with overloaded operators
in C++.
Jan 16 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
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...

    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.


 It's not at all easy to create user-defined types with overloaded


operators

 in C++.
Jan 16 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"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...

 It's not at all easy to create user-defined types with overloaded


 operators

 in C++.


 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.


   :) 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
parent "Sean L. Palmer" <spalmer iname.com> writes:
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...

 It's not at all easy to create user-defined types with overloaded


 operators

 in C++.


 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.


    :) 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
prev sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"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...

 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.


 It's not at all easy to create user-defined types with overloaded


operators

 in 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
parent reply "Walter" <walter digitalmars.com> writes:
"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,
                          JCAB


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 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
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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 testing


Well, 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
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
oops, forgot default values for function parameters! =)
Jan 17 2002
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
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) templates




Come 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 strings



Adequate meaning "having a dedicated comparison operator?"

-RB
Jan 17 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C4706DD.7070306 estarcion.com...


     3) adequate support for strings



 Adequate meaning "having a dedicated comparison operator?"


Heh, yes!
Jan 17 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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