On Mon, 23 Jun 2003 14:17:21 -0500 (06/24/03 05:17:21)
, Carlos Santander B. <carlos8294@msn.com> wrote:

> I have something like this:
>
> struct A { ... }
> ...
> A* a;
>
> But if I attempt to do anything with 'a', I get an access violation. The
> only way I can think to solve this is:
>
> a=(A*)malloc(A.size);
>
> And it actually works.

I would have thought that ...

  A* a;

only declares a variable 'a' such that it is possible for it to hold an address (pointer to an 'A'), but at this moment in time, 'a' does NOT have an address in it. It holds an undefined value. Thus if you use it without doing anything else, your app will be referencing some spot in RAM that is probably not under your app's control, and so BANG!, an access violation occurs.

 The malloc() call (or something similar) is needed to cause 'a' to hold a valid address value.

 a = new A;

would seem to be a simple way of doing this, but I don't think D is this simple. ;-)


If you use malloc() I think you are obliged to manage the memory yourself. The GC does not take responsibility for it in this case.

-- 
Derek

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bd7qoq$22th$1@digitaldaemon.com...
> Walter or some other guru, could you please explain why the obvious "new A" is prohibited?

That looks like a bug I need to fix.

> BTW, is there a legal way for returning a stack-allocated struct from a function?

Yes. If you just return it, a copy will be made of it. If you return a pointer to it, well, your code will have a pointer bug.

Ilya Minkov wrote:

> Carlos Santander B. wrote:
> 
>> struct A { int x; }
>> A* a; /////////[1]
>> a.x=7;  //<------ Access violation
>>
>> changing [1] to:
>>
>> A* a=(A*)malloc(A.size);
> 
> 
> Because on [1], only place for a pointer is reserved on stack, no heap allocation is done. you may want to replace it with
> 
> A * a = new A;

Err, no.  The type after new is a literal description outside of static arrays, so what you're allocating with that new is a stack object.  "new A[1];" is the correct expression.

> which is basically the same as with malloc, but GC-friendly.
> malloc is a part of C library, thus whatever it gives you is not collected by the GC.
> 
> Besides: try not to use the C-style cast, but instead "cast(newtype) expr", since the other may not be supported in future compilers. Reasons are following:
> 
>  - the requierement to recognize C-style casts rejects some otherwise legal expressions;
>  - Burton is against having them, and i believe Walter as well, because they cannot be searched for.

I'm not as against C-style cast syntax as I am against D-style cast syntax, which is horrid.  I don't like syntax that requires semantic analysis like the C-style cast does in D, though.

Burton Radons wrote:
> Err, no.  The type after new is a literal description outside of static arrays, so what you're allocating with that new is a stack object.  "new A[1];" is the correct expression.

Oh... OK. I considereed new as allocating sizeof(expr) space on the GC heap, so the "stack semantics" somewhat irritates me. :/ And doesn't make A[1] any more obvious in this case.

-i.