On the D page regarding structs it says:

a.. Member functions and static members are not allowed.

I'm wondering if there's any way I can talk you into allowing them in some form, Walter?

As is, there's no explicit way to specify a lightweight class (one that doesn't go through vtables), you're at the mercy of the compiler, just have to hope it generates decent code, realizes it doesn't need a vtable at all, and inlines properly.  None of the compilers I've ever used have been able to guarantee that, they all have problems in some situations so I bet the vtable would stay no matter what.

Definitely don't need runtime polymorphism in this case.  So the vtable could never be generated for structs.  Member functions in structs is however one feature I've gotten very accustomed to using in C++ and don't think I could leave behind.  I use it all the time.  It's great to group accessor code right with the object it's accessing.  If any data in the struct must be kept synchronized somehow or depends on some other data in the same struct, I make that private and make a gettor/settor function that keeps it straight.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a346q2$17k4$1@digitaldaemon.com...
> On the D page regarding structs it says:
>
> a.. Member functions and static members are not allowed.
>
> I'm wondering if there's any way I can talk you into allowing them in some form, Walter?

I've been reluctant to do it because it then tends down the road to being classes.

Walter wrote:

> "Sean L. Palmer" <spalmer@iname.com> wrote in message
> news:a346q2$17k4$1@digitaldaemon.com...
> 
>>On the D page regarding structs it says:
>>
>>a.. Member functions and static members are not allowed.
>>
>>I'm wondering if there's any way I can talk you into allowing them in some
>>form, Walter?
>>
> 
> I've been reluctant to do it because it then tends down the road to being
> classes.

As currently implemented, if you write a class that doesn't
have any hierarchy (it inherits from nothing but Object and
nothing inherits from it), will the vtable be optimized away
per Sean's hopes for the ideal compiler? Or is that a future
feature?

-Russell B

Yeah, ideally it'll get allocated on the stack as well, be directly embeddable in another class (not by reference), etc,etc.

Classes have a lot of extra baggage that can sometimes be stripped away.

Sean


"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C564245.6040203@estarcion.com...
> Walter wrote:
>
> > "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a346q2$17k4$1@digitaldaemon.com...
> >
> >>On the D page regarding structs it says:
> >>
> >>a.. Member functions and static members are not allowed.
> >>
> >>I'm wondering if there's any way I can talk you into allowing them in
some
> >>form, Walter?
> >>
> >
> > I've been reluctant to do it because it then tends down the road to
being
> > classes.
>
> As currently implemented, if you write a class that doesn't have any hierarchy (it inherits from nothing but Object and nothing inherits from it), will the vtable be optimized away per Sean's hopes for the ideal compiler? Or is that a future feature?
>
> -Russell B

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C564245.6040203@estarcion.com...
> Walter wrote:
>
> > "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a346q2$17k4$1@digitaldaemon.com...
> >
> >>On the D page regarding structs it says:
> >>
> >>a.. Member functions and static members are not allowed.
> >>
> >>I'm wondering if there's any way I can talk you into allowing them in
some
> >>form, Walter?
> >>
> >
> > I've been reluctant to do it because it then tends down the road to
being
> > classes.
>
> As currently implemented, if you write a class that doesn't have any hierarchy (it inherits from nothing but Object and nothing inherits from it), will the vtable be optimized away per Sean's hopes for the ideal compiler? Or is that a future feature?

Hmm. I had planned that the optimizer make them non-virtual calls, but I hadn't gone as far in my thinking as eliminating the vtbl[]. That just might be a really cool optimization.

I knew if I added member functions, you'd want constructors, destructors, etc. <g>

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a35ohu$25ph$1@digitaldaemon.com...
> Yeah, ideally it'll get allocated on the stack as well, be directly embeddable in another class (not by reference), etc,etc.
>
> Classes have a lot of extra baggage that can sometimes be stripped away.
>
> Sean
>
>
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C564245.6040203@estarcion.com...
> > Walter wrote:
> >
> > > "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a346q2$17k4$1@digitaldaemon.com...
> > >
> > >>On the D page regarding structs it says:
> > >>
> > >>a.. Member functions and static members are not allowed.
> > >>
> > >>I'm wondering if there's any way I can talk you into allowing them in
> some
> > >>form, Walter?
> > >>
> > >
> > > I've been reluctant to do it because it then tends down the road to
> being
> > > classes.
> >
> > As currently implemented, if you write a class that doesn't have any hierarchy (it inherits from nothing but Object and nothing inherits from it), will the vtable be optimized away per Sean's hopes for the ideal compiler? Or is that a future feature?
> >
> > -Russell B
>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:a35tv0$29es$2@digitaldaemon.com...
>
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C564245.6040203@estarcion.com...
> >
> > As currently implemented, if you write a class that doesn't have any hierarchy (it inherits from nothing but Object and nothing inherits from it), will the vtable be optimized away per Sean's hopes for the ideal compiler? Or is that a future feature?
>
> Hmm. I had planned that the optimizer make them non-virtual calls, but I hadn't gone as far in my thinking as eliminating the vtbl[]. That just
might
> be a really cool optimization.

   But... only the linker can know ultimately if a class has any
descendents, right?

   I mean, I believe you're still using a C-style linker, right? Are you
planning to change that?

Salutaciones,
                         JCAB

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:a36u7h$2q9c$1@digitaldaemon.com...
>    But... only the linker can know ultimately if a class has any
> descendents, right?
>    I mean, I believe you're still using a C-style linker, right? Are you
> planning to change that?

I've thought many times about building the link step into the compiler.

That sounds like the way of the future.  ;)   VC7's link time code generation is almost there.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:a36uus$pqm$1@digitaldaemon.com...
>
> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:a36u7h$2q9c$1@digitaldaemon.com...
> >    But... only the linker can know ultimately if a class has any
> > descendents, right?
> >    I mean, I believe you're still using a C-style linker, right? Are you
> > planning to change that?
>
> I've thought many times about building the link step into the compiler.

The reason for a separate linker historically has been limited memory and slow compilers. This is rapidly becoming irrelevant.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a38jjn$197r$1@digitaldaemon.com...
> That sounds like the way of the future.  ;)   VC7's link time code generation is almost there.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:a36uus$pqm$1@digitaldaemon.com...
> >
> > "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:a36u7h$2q9c$1@digitaldaemon.com...
> > >    But... only the linker can know ultimately if a class has any
> > > descendents, right?
> > >    I mean, I believe you're still using a C-style linker, right? Are
you
> > > planning to change that?
> >
> > I've thought many times about building the link step into the compiler.
>
>
>