I think it's an old asked question, now what the difference between a struct and a public-only class? Do we need structs after all?

Axel Kittenberger wrote:

> I think it's an old asked question, now what the difference between a struct and a public-only class? Do we need structs after all?

In C++, there wasn't any difference - in fact, you could declare private members of a struct.

I think that Walter has done a Good Thing by separating the two in D.
Key differences (as I understand them):
* No member functions of any kind in structs (and therefore no vtable)
* All members public in structs
* Structs can be created on the stack; all class objects are created on
the heap
* Specified alignment possible in structs, not in classes

I like this because it makes a separation between a hardware-like type (struct) which is simply a mapping of a conglomeration of types over a certain range of memory and a OOP-like type (class) which is a high-level programming abstraction designed to facilitate good and easy programming.

This allows the program to have low-overhead access to hardware (a key feature of C) or to subroutines from other languages while still allowing high-level OO design.

 > I like this because it makes a separation between a hardware-like type
 > (struct) which is simply a mapping of a conglomeration of types over a
 > certain range of memory and a OOP-like type (class) which is a high-level
 > programming abstraction designed to facilitate good and easy programming.

 Well especially on hardware types for a certain range of memory, it would
 be often very nice to provide a set of functions just related to this.

Russ Lewis wrote:
> I think that Walter has done a Good Thing by separating the two in D.

I agree, but --

> Key differences (as I understand them):
> * No member functions of any kind in structs (and therefore no vtable)

For pendantry, I'll just point out that member functions in themselves don't require a C++ class to have a vtable -- only virtual functions.

> This allows the program to have low-overhead access to hardware (a key
> feature of C) [...]

And of C++, because of the above. You can even get OO encapsulation around a struct/class which represents memory-mapped hardware!

-RB

"Rajiv Bhagwat" <dataflow@vsnl.com> wrote in message news:9nplbj$nsf$3@digitaldaemon.com...
> 'size' does not differ for each object of a class, so need not be carried with each one.
>
Right it shouldn't. It should be related to the type, not the instance. However it is impossible (or much much harder) to write a generic container of "objects" if they don't all have a common base class, however lightweight. This is part of the reason why it is a good idea.

That lightweight generic base class should at least allow you to ask:
 - How big is an instance (this should be a class not instance method)
 - Is the object in fact of this type (RTTI, is-a test)

A generic virtual method on the base class to display any object as a string like Java has is nice but not vital.

Oh, then the programmer object can invoke the compiler object sending it the program object to get the object object <g><g>!

Seriously, people have discussed at length (particularly wrt library designs - MFC included) about how deriving from a single base class leads to unfavourable situations. I vaguely remember a reference to Coplien's article on this subject. I would try to fish out the details later.

-- Rajiv

Jan Knepper <jan@smartsoft.cc> wrote in message news:3BA2100F.5D2F9436@smartsoft.cc...
> Rajiv Bhagwat wrote:
>
> > Why have a common base class 'object'? There is nothing common in 'date'
and
> > 'point'.
>
> Not on functional level...
> From both could be said that they are an 'object' as for which both could
be
> derived from 'object'... <g>
>
> Jan
>
>

Rajiv Bhagwat wrote:

> Oh, then the programmer object can invoke the compiler object sending it the program object to get the object object <g><g>!

<g>

> Seriously, people have discussed at length (particularly wrt library designs - MFC included) about how deriving from a single base class leads to unfavourable situations.

It's all a matter of design is what I think...
For some functional designs it is favourable to derive from a single base class.
For others it is not. I don't think I have complete application around with all
classes derived from one single base class. I however do have certain functional
implementation that do for the reason that it is very favourable in that
situation... <g>

Jan

Russell Bornschlegel wrote:

> > Key differences (as I understand them):
> > * No member functions of any kind in structs (and therefore no vtable)
>
> For pendantry, I'll just point out that member functions in themselves don't require a C++ class to have a vtable -- only virtual functions.

True.  However, Walter has made the design decision that all member functions in D are virtual.  That doesn't necessarily mean you'll need a vtable (if you never override functions for your 'struct', or you never call those functions by pointer), but it makes it more likely.  IMHO, this illustrates the double-minded approach of C++; it can never make up its mind whether its an OOP language or a low-level language, so it tries to do both in one language element.  I like the way that D does both - but separates the two into very distinct language elements.

> > This allows the program to have low-overhead access to hardware (a key
> > feature of C) [...]
>
> And of C++, because of the above. You can even get OO encapsulation around a struct/class which represents memory-mapped hardware!

True. :) Ofc, the same can be done in D by declaring a member struct inside a class; the class provides the programming interface, while the encapsulated struct provides a memory interface.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

> True. :) Ofc, the same can be done in D by declaring a member struct inside a class; the class provides the programming interface, while the encapsulated struct provides a memory interface.

Yes, thats always possible. But it's then a wrong IS-A, HAS-A relationship. Taken with this aproach in example you don't even need inheritance. You can always use "fathers" as member values. Well a pratice often done in C.

- Axel

Axel Kittenberger wrote:

> > True. :) Ofc, the same can be done in D by declaring a member struct inside a class; the class provides the programming interface, while the encapsulated struct provides a memory interface.
>
> Yes, thats always possible. But it's then a wrong IS-A, HAS-A relationship. Taken with this aproach in example you don't even need inheritance. You can always use "fathers" as member values. Well a pratice often done in C.

Sounds like you're taking an OOP purist view of things...please correct me if I'm mistaken.

OOP-purist isn't bad, so let's define this "interface" class in what (I think)
might make good OOP sense.
* The struct IS-A memory interface of type X.
* The class IS-A program interface of type X-int that HAS-A memory interface of
type X.

I understand that in C++ you had the convenience of encapsulating the memory and program interfaces into a single type.  But I still like the fact that the two are separated.  My types tend to start out as glorified structs that slowly migrate into more and more complex classes.  D would force a more rigid distinction.  Hmmm...repeating myself.  Probably time to step out of this before it gets too repetitive and flamy...

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]