"not an lvalue"

[Dmitry Olshansky]

On 01.05.2011 19:31, Peter Alexander wrote:
> On 1/05/11 2:53 PM, Dmitry Olshansky wrote:
>> Ehm.. Well, first things first: you shouldn't use classes for
>> lightweight & plain data things like vectors. There are structs for
>> that. In general, structs are value-like objects living on the stack
>> while classes are reference-like objects living on the heap. Your
>> current code is going to allocate on GC heap new vector in every
>> GetColumn and I suspect also when adding two vectors.
>
> structs don't live on the stack. They live wherever they are told to. 
> In fact most structs will live in the heap as parts of class objects, 
> or other heap-allocated objects such as dynamic arrays or AAs. The 
> stack is for local variables and other things to do with the local scope.
>
It just that I wanted to keep things simple and wasn't sure if I should 
pour all this rather involved details on the OP. That's what this 'In 
general' implied ;) Now  I think I better have left the 'usually lives' 
part where it was before posting.
Yet you're right, I see the misleading core of such statements.

> While struct objects *can* go on the stack, it is false to say that 
> structs live on the stack and classes live on the heap. The type of an 
> object (value type or reference type) is orthogonal to its storage 
> location and the two should not be conflated.
The sweet irony. Sometime ago I argued on the NG that very thing about 
allocating class objects. Damn, it looked like I was the only one 
considering class storage anywhere not on the GC heap as usual thing. 
Everyone else observed that 90% of use cases are going to be heap 
allocations with new.

But what I actually had in mind was that when you see:
...
A a;
...
For struct means that it's stored directly at this 'memory scope' be it 
static, class member or anything (denote 'here').
For classes that merely means it's reference stored 'here', the object 
itself resides elsewhere, the heap being that most likely possibility.

Again, sorry for any confusion I might have caused.

-- 
Dmitry Olshansky