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

[BC]

On Wed, 12 Dec 2007 22:59:16 -0000, Gregor Richards <Richards at codu.org>  
wrote:

> Martin Hinsch wrote:
>> On Wed, 12 Dec 2007 12:24:44 -0800, Gregor Richards wrote:
>>
>>> BC wrote:
>>>> I thought it was a great idea to allow both value semantics and  
>>>> pointer
>>>> semantics for the same types in C++ by the simple addition of a * or  
>>>> &.
>>>> What was wrong with that that needed to be fixed in D? GC could have
>>>> been done without changing this. Now in D template code doesn't know
>>>> which semantics apply and structs can't inherit. If you write  
>>>> something
>>>> as a struct and then realise you need inheritance you're stuck. D has  
>>>> so
>>>> many good ideas it's a shame to see it broken in this way...
>>>
>>> No. No no no no no. I hate seeing this argument.
>>>
>>> structs are a shim. They are a way of getting lower-level access to the
>>> organization of memory.
>>>
>>> In C++, this is ANYTHING but simple:
>>>
>>> class A {
>>> ...
>>> }
>>> }
>>> void someidiotfunction(A a);
>>> void someidiotfunction2(A *a);
>>> void someidiotfunction3(A &a);
>>>
>>> You now have three ways of passing an "object", with different  
>>> semantics
>>> and different possible results!
>>>
>>> In proper object oriented design, objects are contexts. It makes no  
>>> sense
>>> to duplicate contexts. Contexts are an abstraction of an environment in
>>> which to perform actions, and it makes no sense to duplicate that
>>> environment whenever you happen to pass it from one function to another
>>> (oh except when you don't).
>>>
>>> D is not the problem. C++'s insistence on forcing details of
>>> implementation down the users' throat is the problem.
>>>

I don't see how C++ is forcing anything. C++ is the one that gives you
the choice. If I want two closely related types to be viewed through a
common interface or to share implementation in D, I have to accept
reference semantics as well, everywhere. If you have an aversion to
by-value objects you can always stick to pointers in C++. Use an alias.
We're not trying to take anything away, it's an addition.

a question: should matrices be structs or classes?

>>>   - Gregor Richards
>>  I don't mean to be offensive, but I totally don't see the point. Of  
>> course
>> C++ structs (being inherited from C) are too low-level. Still, I would
>> argue that this is a property of C++ not of value-semantics. And who
>> decides a) what "proper object-oriented design" means,
>
> Consensus and history.
>
>> b) that it's
>> inherently a great thing
>
> This is irrelevant. Whether OO is good or not, D aims to be OO.
>
>> and c) that it is tied to reference semantics?
>
> Consensus. C++ is popular, but it is the exception to the rule in this  
> regard. Virtually no other language has this bizarre property.
>
>> IMO it makes perfect sense to treat objects as just a more complicated
>> kind of value. Look at the following code:
>>  int a=1;
>> a++;
>> int b = a + 10;
>
> This code has no function calls. And, if it was all implemented with  
> operator overloading, it would be the same whether it had value or  
> reference semantics:
>
> Integer a = new Integer(/*magic internal data representing the value  
> 1*/);
> a.opIncrement(); /* no imperative language would implement this as a
>                    * copy, as then all objects would be immutable */
> Integer b = a.opAdd(new Integer(10)); /* whether the integer is copied
>                                         * or not, a returns a new one, it
>                                         * has no reason to modify its
>                                         * argument */
>
> In other words, this code is irrelevant.
>
>>  In this piece of code the variable a is used once as a reference (i.e.
>> modified in place) and once as a value (i.e. copied).
>
> No it isn't.
>
>> In the same way it
>> can make sense for "real" objects to use them as values in some  
>> operations
>> and as references in others.
>
> Intrinsic values do not mutate in the same way that objects do. In an  
> object oriented sense, they're immutable. When you say a = a + 5, it's  
> rebinding the variable a to a new value, computed as a + 5. The actual  
> data representing its original value is not modified, a is simply  
> rebound. This has the same result whether by-value or by-reference.  
> Because they're immutable, there's no distinction between by-value and  
> by-reference passing. If all the intrinsic types were actually by-ref  
> objects, there would be no difference.
>
> (Note: a++ and ++a are sort of exceptions to this rule)
>

along with a-- --a += -= *= /= %= &= |= ~= ^= <<= >>= >>>=

>> You can easily make up a way to specify which
>> way to use a function arg (like, say, 'in' and 'inout') without having  
>> to
>> know anything about values or references.
>
> Yes - D already has one.
>
>> To sum it up - I think although C++ structs + pointers + references is
>> messy, that doesn't mean that OOP and value vs. reference semantics  
>> aren't
>> completely orthogonal concepts.
>> And by the way this is the main point keeping me from using D
>
> Seriously? You are /way/ too much of a C++'er. Go use any other OO  
> language, and you will find your opinion very quickly in the minority.  
> "I don't mean to be offensive," but that's just silly.
>
>> (and the
>> fact that the gcc frontend is so slow in catching up). Since I started
>> to read the newsgroup I got the impression that the special syntactic
>> treatment of object references has been *the* major hurdle for many of  
>> the
>> more difficult/controversial language extensions (const comes to mind).
>
> This is a purely syntactic hurdle, and the giant ugly mess that is  
> by-value objects is not worth the slightly simpler syntax. Which,  
> incidentally, would be more complicated syntax in basically every other  
> scenario.
>
>>  cheers
>> Martin
>>
>
>   - Gregor Richards