"the last change" for ranges
Jason House
jason.james.house at gmail.com
Thu May 21 05:50:38 PDT 2009
dsimcha Wrote:
> == Quote from Jason House (jason.james.house at gmail.com)'s article
> > dsimcha Wrote:
> > > == Quote from Jason House (jason.james.house at gmail.com)'s article
> > > > IMHO, D should have a type with low size and function call overhead > like a
> > > struct as well as reference semantics like a class.
> > >
> > > What's wrong with a pointer to a heap-allocated struct? I sometimes need what you
> > > describe, too, and I've never seen a case where this doesn't do the job.
> > That does the job, but it looks ugly ;) I think it's also not allowed in safe d.
>
> Well then that argues more for a generic reference type than for a whole new
> aggregate type different from both classes and structs. IIRC, Ref was supposed to
> be coming to std.typecons soon. Also, if you don't care about the few bytes of
> overhead for vtbl and monitor, there's always final classes. The bottom line is
> that I can see where what you're asking for could be useful, but the cases where
> neither a final class nor a pointer to a heap-allocated struct cut it are way too
> few and far between to justify a whole new aggregate type.
Maybe I'm a bit cynical, but I never expect my posts to cause a change in D, or for my bug reports to even get a comment. My long posts with well thought out ideas either get no response or a reaction like Andrei's recent switch range thread. I no longer try to work out the details and merely hope my efforts plant a seed for thought. It's far less frustrating that way.
As far as a struct-like reference type, my only goal was to point out a gap that is effecting users. Your suggestion about a library implementation sounds reasonable. Personally, I use final classes and don't care about the extra overhead. I used to not worry about making classes final, especially since the D "spec" says a compiler can be smart enough to detect when they're appropriate. I can't help but wonder if struct pointers are in my future as I continue to push for performance. What would irk me most about doing that is if such a decision causes a ripple of changes throughout my code base.
More information about the Digitalmars-d
mailing list