Russ Lewis wrote:

> 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...

Well I agree it's just a matter of taste, and anyone including walter can do as he likes. Personally I tended also to tell people programming C++, -always- use classes even if you're at first thinking of a struct. It's proparle in cases of evolving software, I agree in case of application pre-designed completly on board first this does not apply, but in cases where projects just grow (often the case in opensource) having always classes usually yields to a better overall programming style. Since people will later think, man for this "struct" I could use a static handling routing for, or this "struct" completly takes over all elements of this one, so let's make it a child, if people do structs in C++ code also when they first think they apply the net result is usally a silent fall back to the pseudo-OO-C-programming-style. "Parents" as field member structs, and field function pointers instead of OO member functions.

Kent Sandvik wrote:

> "Rajiv Bhagwat" <dataflow@vsnl.com> wrote in message news:9nplbh$nsf$2@digitaldaemon.com...
>

>> It is persistance, where the common base class causes
>> problems of M/I. Maybe, the persistance should be handled
>>  by the language itself, as it ...
>
> Well, maybe Multiple Inheritance is not needed at all, I
> never use it myself, encapsulation takes care of that. But
> having a way to enforce a way ...
>
There are generally other possible ways to handle the problems that multiple inheritance is usually used to handle.  How much work those other ways take depends on what help the language provides.  If one has fine-grained control of forwarding, and also coarse-grained forwarding, then interfaces and forwarding can combine to give almost all of the benefits (and a few extra).

To be a little less abstract:

Class Bird

Wing wing_style;
Leg  leg_style;

Forward /^Wing*/ and not /WingTip/ to wing_style;
Forward /^Leg*/ to leg_style;

I suppose that one could require that each particular method to be forwarded be listed separately, but then the amount of work required has significantly increased.  And, of course, in Java one has to not only list all of the methods to be forwarded, one even has to write a wrapper for each one.  Quite annoying.  And error prone.  (Changes don't happen locally, but echo through the program.)  Whether a full regular expression parser is needed there, well, probably not.  On the other hand, it's been done, and the source code is available (in the OpenBSD Unix tree is nowhere else).  So how much is gained by using a restricted form?

Russ Lewis wrote:
> 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...

	Not to blow on the flames, but would the rigid distinction get in the
way of some evolutionary development models?  Last I heard that was
still a good thing.  (Sure you should periodically consider redoing
parts from scratch but not all the time.)
	The lack of separation in C++ also allowed programmers to add methods
to the C structures without impacting their use in C calls.  I always
thought that was pretty nifty.

Dan

a wrote:

>         Not to blow on the flames, but would the rigid distinction get in the
> way of some evolutionary development models?  Last I heard that was
> still a good thing.  (Sure you should periodically consider redoing
> parts from scratch but not all the time.)

You can evolve from a struct to a class.  Simply leave the members as public members (while adding functions and/or member functions) or turn the members into gettor/settor properties.

>         The lack of separation in C++ also allowed programmers to add methods
> to the C structures without impacting their use in C calls.  I always
> thought that was pretty nifty.

I don't understand...I don't think that it's legal to define member functions in C, right?  How could you have cross-compatibility?  (Except by derivation...)

--
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))) ]

> I don't understand...I don't think that it's legal to define member
> functions in C,
> right?  How could you have cross-compatibility?  (Except by derivation...)

struct arg {
   int a;
   static int add();
};

is allowed in C++, you could add member functions even to structs, altough they had to be public and static. BTW, don't take this example too worldly, might not compile, I didn't try it out, nor did I ever use this feature.

Axel Kittenberger wrote:

> struct arg {
>    int a;
>    static int add();
> };
>
> is allowed in C++, you could add member functions even to structs, altough they had to be public and static. BTW, don't take this example too worldly, might not compile, I didn't try it out, nor did I ever use this feature.

Actually, C++ is much more flexible than that.  You can make non-public, non-static members of structs.  The only difference between struct and class in C++ is that class defaults to private protection while struct defaults to public.  Thus,

struct
{
private:
   ......
}

is the same as a class definition.

At least, that's how I understand it.  Anybody want to contradict me?

My question was about how you would interact with C; if you declare a member function (even public-static) that won't work in C.  However, you could do the following:

struct Cstruct
{
   ...
}

class CppClass : private Cstruct
{
    ...
}

As long as the C file never included the header that declared class CppClass, that would work.

I don't agree that structs should prohibit member functions.  Seems a pointless, counterproductive restriction.  I do think that virtual member functions should be prohibited, but without any member functions on a struct it is going to be quite the PITA to make any kind of high-performance vector class.  I don't know if you can inherit from a struct... if you can't, then there is no possibility of virtuals anyway.

Let's promote the coupling of data and methods.  Allow structs to have member functions.  Even ctors and dtors!

Sean

"Russ Lewis" <russ@deming-os.org> wrote in message news:3BA21C83.481E231F@deming-os.org...
> 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.

"Sean L. Palmer" wrote:

> I don't agree that structs should prohibit member functions.  Seems a pointless, counterproductive restriction.  I do think that virtual member functions should be prohibited, but without any member functions on a struct it is going to be quite the PITA to make any kind of high-performance vector class.  I don't know if you can inherit from a struct... if you can't, then there is no possibility of virtuals anyway.
>
> Let's promote the coupling of data and methods.  Allow structs to have member functions.  Even ctors and dtors!

This is an interesting point.  Removing virtuals means that there is no need for a vtable...thus, adding member functions adds to the functional code in the compiled image, and does not interfere with struct's binary-mapping nature.

I would agree with this if there was consensus that there would not be confusion between structs and classes.  If users are used to automatic (undeclared) virtual functions in classes, will the non-virtual nature in structs cause confusion?

--
The Villagers are Online! 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))) ]

"Sean L. Palmer" wrote:
> 
> I don't agree that structs should prohibit member functions.  Seems a pointless, counterproductive restriction.  I do think that virtual member functions should be prohibited, but without any member functions on a struct it is going to be quite the PITA to make any kind of high-performance vector class.  I don't know if you can inherit from a struct... if you can't, then there is no possibility of virtuals anyway.
> 
> Let's promote the coupling of data and methods.  Allow structs to have member functions.  Even ctors and dtors!

The only major point I have against your case is that the "no virtuals" restriction on structs seems more arbitrary than the "no member functions" restriction (even though it's not, particularly).

It seems that Walter's intent with D-structs is to encourage their use only when byte-accurate layout is important, and to this end, I accept the arbitrary restrictions.[1]

You can still encapsulate your struct manipulations, class-wise, using composition instead of inheritance:

struct _hardware_registers_
{
   ...
};

class HardwareAccess
{
public:
   void DiddleSomeRegisters( void );
   ...

private:
   _hardware_registers_*   m_Registers;
   ...

};

This isn't particularly arduous. You can even make the pointer to the registers a class-static if that's advantageous.

-RB

[1] There's some weak analogy here of the Unix tradition of giving root only the sh shell rather than any of the fancy shells -- you're doing something out of the ordinary, so it's kept deliberately uncomfortable so you stay alert.

Russell Borogove wrote:
> 
> "Sean L. Palmer" wrote:
> >
> > I don't agree that structs should prohibit member functions.  Seems a pointless, counterproductive restriction.  I do think that virtual member functions should be prohibited, but without any member functions on a struct it is going to be quite the PITA to make any kind of high-performance vector class.  I don't know if you can inherit from a struct... if you can't, then there is no possibility of virtuals anyway.
> >
> > Let's promote the coupling of data and methods.  Allow structs to have member functions.  Even ctors and dtors!
> 
> The only major point I have against your case is that the "no virtuals" restriction on structs seems more arbitrary than the "no member functions" restriction (even though it's not, particularly).

	Virtual functions and polymorphism in general have a performance and
memory penalty associated with them.  Member functions are merely an
organizational tool that helps encourage the development better APIs for
dealing with a datatype, making the use and maintenance of the type
safer.

> It seems that Walter's intent with D-structs is to encourage their use only when byte-accurate layout is important, and to this end, I accept the arbitrary restrictions.[1]

	I took it as the bare bone minimum to allow compatibility with C
binaries.

> You can still encapsulate your struct manipulations, class-wise, using composition instead of inheritance:
> 
> struct _hardware_registers_
> {
>    ...
> };
> 
> class HardwareAccess
> {
> public:
>    void DiddleSomeRegisters( void );
>    ...
> 
> private:
>    _hardware_registers_*   m_Registers;
>    ...
> 
> };
> 
> This isn't particularly arduous. You can even make the pointer to the registers a class-static if that's advantageous.

	Actually, it struck me as one of those situations were the technology
is there to make it easier on you, but some egghead either decided that
the unwashed massed weren't to be trusted with such powerful features or
that nobody really needs to do that anyway.
	It would be nice to be able to wrap a nice set of member functions
around the return value of a file stat, but alas there are bigger
battles to fight.

> [1] There's some weak analogy here of the Unix tradition of giving root only the sh shell rather than any of the fancy shells -- you're doing something out of the ordinary, so it's kept deliberately uncomfortable so you stay alert.

	Funny, my Linux systems gave root bash.  I have a nasty habit of giving
him tcsh where ever I go.  I probably wouldn't have replied, but I saw
this statement and it reminded me of C++'s casts.  The committee had the
same reasoning you did.  I've always felt I and everyone else who has
had to do a cast in C++ deserved an apology from someone for C++'s
casts.

Dan