what was wrong with struct & class in C++?

[BC]

On Thu, 13 Dec 2007 01:51:13 -0000, Yigal Chripun <yigal100 at gmail.com>  
wrote:

>  > a question: should matrices be structs or classes?
>
> I'd like to clarify your question:
> do you want to ask -
> a) whether they should be value types or reference types?
> or
> b) whether they should be implemented with D structs or D classes?
>

i should have been clearer, i meant a. although i'd argue it's the same
question.

> if you mean a than it really doesn't matter.
> you are quite right that you can implement OOP features with both  
> reference and value semantics. doing both is redundant because they  
> achieve the same goal.
> i.e. passing by value achieves the same as const reference and passing  
> the address of the value achieves the same as passing by mutable  
> reference.
> so it's just a question of implementation and most languages choose  
> reference semantics due to the more efficient memory use.
> so in this case the consensus is the better option.
>
> also note that you can mix-n-match: you can implement one semantic with  
> the other:
> ref to value: you can have a dup method (clone in java, but you knew  
> that already) although it should be avoided and probably isn't needed in  
> the general case.

in template code, you have to dup everything, just in case. and then it
may not have a dup method, or a copy constructor (which aren't generated
automatically, and if it has both which do you use?)

> value to ref: you can pass addresses of values to simulate references.

but then you need to change everything to pointer syntax. it would be
nice to sneak in references as opposed to pointers. i suppose this
comes under the header of 'c++ dirty tricks'

> if you meant b than i think that classes should be used.
> I'm new to D, but from what little i know, if you want OOP behavior (and  
> matrices would benefit from polymorphism) than you need to use a class  
> and not a struct.
>
> the semantics shouldn't matter as it's a matter of implementation and  
> not interface. (ideally you'd just use "in" and "inout" and let the  
> compiler optimize when you pass around parameters).
> if you want a matrix to be a value type you can simulate that with a dup  
> method, i think.

it's so easy to miss one dup out and get very weird behaviour. code working
on matrices with dups all over the place is not something i relish.
i don't know, i'm not entirely convinced of my own argument. i just think
things could be 'excellent' or envelope-pushing rather than just 'ok'.

> D structs should only be used for PODs. a good example would be a struct  
> containing an internet address where you need it to be in a specific  
> memory layout (endian-ness).

i think there's a distinction between something that's a value type and
something that's POD. matrices, by their nature, are value types - their
identity is irrelevant. but they could do with inheritance, or at least
interfaces.

> also, if you care about heap allocation vs. stack, than you could always  
> use scope classes which would be stack based.
>
> that's all from a theoretical POV of course, practically, there maybe  
> other issues that influence that decision. also const still has a few  
> kinks that need to be sorted out in D.
>
> Just my 2 cents..