Hello all,

the docs say only "Class members are always accessed with the . operator." Thus, I would have expected that the following program is correct, but it isn't:

class foo
{
int bar;
}

void main()
{
foo someObject;
someObject.bar = 3;
}

It compiles fine, but when run (Win98SE), I get an

"Error: Access Violation"

Where's the mistake, how can I fix it?

Thanks, OP

OP wrote:
> class foo
> {
> int bar;
> }
> 
> void main()
> {
> foo someObject;
> someObject.bar = 3;
> }
> 
> It compiles fine, but when run (Win98SE), I get an
> 
> "Error: Access Violation"
> 
> Where's the mistake, how can I fix it?


Thou shalt new the object ;)

foo someObject = new foo;

/* foo someObject; <--- only creates a null reference */



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

In article <d3plhv$1gdr$1@digitaldaemon.com>, Tom S says...

>Thou shalt new the object ;)
>
>foo someObject = new foo;
>
>/* foo someObject; <--- only creates a null reference */

Ah! Thank you!

BTW, is there anything a "null reference" could be useful for?

OP

On Sat, 16 Apr 2005 00:27:42 +0000 (UTC), OP <OP_member@pathlink.com> wrote:
> In article <d3plhv$1gdr$1@digitaldaemon.com>, Tom S says...
>
>> Thou shalt new the object ;)
>>
>> foo someObject = new foo;
>>
>> /* foo someObject; <--- only creates a null reference */
>
> Ah! Thank you!
>
> BTW, is there anything a "null reference" could be useful for?

The same things a null pointer can be useful for.

-Delaying allocation of object/memory.
-Later conditional assignment to existing object.

Basically, when you don't have (or want) a value to assign to it at the time of reference declaration.

Regan

OP wrote:
> BTW, is there anything a "null reference" could be useful for?

Well... just like a null pointer in C. You can set it to some meaningful value or leave it null...
E.g. in a tree structure when a node has null child pointers/references, it's a leaf.
Hmm... conclusion: a null reference is not useful for anything other but letting you know that it's not useful for anything ;)


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

The reason I ask is: Why does the D language behave like this? Isn't it *very* obvious that by

foo_class foo;

I mean that I want to actually create a class object and that the D compiler should let the garbage collector allocate memory for it?

Thanks, OP

In article <d3pmo5$1hli$1@digitaldaemon.com>, Tom S says...

>OP wrote:
>> BTW, is there anything a "null reference" could be useful for?
>
>Well... just like a null pointer in C. You can set it to some meaningful
>value or leave it null...
>E.g. in a tree structure when a node has null child pointers/references,
>it's a leaf.
>Hmm... conclusion: a null reference is not useful for anything other but
>letting you know that it's not useful for anything ;)

On Sat, 16 Apr 2005 16:19:32 +0000 (UTC), OP <OP_member@pathlink.com> wrote:
> The reason I ask is: Why does the D language behave like this? Isn't it
> *very* obvious that by
>
> foo_class foo;
>
> I mean that I want to actually create a class object and that the D
> compiler should let the garbage collector allocate memory for it?

No. "foo_class foo;" declares a reference to a class "foo_class" called "foo", nothing more.

D does not allow you to create class instances on the stack, only on the heap.

http://www.digitalmars.com/d/overview.html
"Creating object instances on the stack. In D, all class objects are by reference. This eliminates the need for copy constructors, assignment operators, complex destructor semantics, and interactions with exception handling stack unwinding. Memory resources get freed by the garbage collector, other resources are freed by using the RAII features of D."

So, in essence you must 'new' all class instances, always.

Regan.

> Thanks, OP
>
> In article <d3pmo5$1hli$1@digitaldaemon.com>, Tom S says...
>
>> OP wrote:
>>> BTW, is there anything a "null reference" could be useful for?
>>
>> Well... just like a null pointer in C. You can set it to some meaningful
>> value or leave it null...
>> E.g. in a tree structure when a node has null child pointers/references,
>> it's a leaf.
>> Hmm... conclusion: a null reference is not useful for anything other but
>> letting you know that it's not useful for anything ;)
>
>

On Sun, 17 Apr 2005 12:12:51 +1200, Regan Heath wrote:

> On Sat, 16 Apr 2005 16:19:32 +0000 (UTC), OP <OP_member@pathlink.com> wrote:
>> The reason I ask is: Why does the D language behave like this? Isn't it *very* obvious that by
>>
>> foo_class foo;
>>
>> I mean that I want to actually create a class object and that the D compiler should let the garbage collector allocate memory for it?
> 
> No. "foo_class foo;" declares a reference to a class "foo_class" called "foo", nothing more.
> 
> D does not allow you to create class instances on the stack, only on the heap.

The OP didn't mention anything about creating objects on the stack. Maybe we need to explain what is apparently obvious to some but not to others. Namely, that in D, when you code a declaration in the form ...

   <TYPE> <INDENTIFIER>;

eg  int x;
    Foo y;

then <IDENTIFIER> is created on the stack. However, if the <TYPE> is a reference type, such as a class or dynamic array, this is reference to nothing, its just a placeholder for you to later et a reference to something.

Declarations in the form

   <TYPE> <INDENTIFIER> = new <TYPE>;

then D will always create a reference item on the stack to an instance of the <TYPE> on the heap.


> http://www.digitalmars.com/d/overview.html
> "Creating object instances on the stack. In D, all class objects are by
> reference. This eliminates the need for copy constructors, assignment
> operators, complex destructor semantics, and interactions with exception
> handling stack unwinding. Memory resources get freed by the garbage
> collector, other resources are freed by using the RAII features of D."
> 
> So, in essence you must 'new' all class instances, always.

Well, only if you want them to point to an instance. ;-)

Some people, myself included, have asked for the syntax to be changed such that

   Foo y;

would be identical to

  Foo y = new Foo;

but many others, Walter especially, does not think that this is a good idea. The simplicity of the current declaration rule will thus be preserved. However, there may still be some hope for a simplified way to invoke a class constructor... maybe along the lines of ...

  Foo y();


-- 
Derek Parnell
Melbourne, Australia
17/04/2005 12:56:54 PM

On Sun, 17 Apr 2005 15:23:28 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Sun, 17 Apr 2005 12:12:51 +1200, Regan Heath wrote:
>
>> On Sat, 16 Apr 2005 16:19:32 +0000 (UTC), OP <OP_member@pathlink.com>
>> wrote:
>>> The reason I ask is: Why does the D language behave like this? Isn't it
>>> *very* obvious that by
>>>
>>> foo_class foo;
>>>
>>> I mean that I want to actually create a class object and that the D
>>> compiler should let the garbage collector allocate memory for it?
>>
>> No. "foo_class foo;" declares a reference to a class "foo_class" called
>> "foo", nothing more.
>>
>> D does not allow you to create class instances on the stack, only on the
>> heap.
>
> The OP didn't mention anything about creating objects on the stack. Maybe
> we need to explain what is apparently obvious to some but not to others.

True. Thanks.

<snip>

>> So, in essence you must 'new' all class instances, always.
>
> Well, only if you want them to point to an instance. ;-)

I think you're confusing instance and reference.

Foo f;    //class reference
new Foo() //class instance

'new' is required to create an instance.

Regan

On Sun, 17 Apr 2005 18:03:03 +1200, Regan Heath wrote:


[snip]
> 
>>> So, in essence you must 'new' all class instances, always.
>>
>> Well, only if you want them to point to an instance. ;-)
> 
> I think you're confusing instance and reference.
> 
> Foo f;    //class reference
> new Foo() //class instance
> 
> 'new' is required to create an instance.

Thank you, but I wasn't confusing the two. What I was doing was misreading your phrase "in essence you must 'new' all class instances, always" as "one must always use 'new' if you declare a class variable". Thus my response could be expanded to "Well, only if you want the class variable to reference an actual class instance". It was my mistake.

-- 
Derek Parnell
Melbourne, Australia
17/04/2005 4:14:46 PM