"Daniel Murphy" <yebbl...@nospamgmail.com> wrote in message news:jjhcj8$25sv$1...@digitalmars.com... > "Nick Sabalausky" <a@a.a> wrote in message > news:jjh9uh$1vto$1...@digitalmars.com... >> >> My understanding is that the *only* thing preventing vitrual template >> functions is the possibility of pre-compiled closed-source static libs. >> Which is why I've long been in favor of allowing vitrual template >> functions *as long as* there's no closed-source static libs preventing >> it. Why should OSS have to pay costs that only apply to closed source? >> > > That's not really it... > > The problem is that vtables contain every virtual function of a class - > and if you instantiate a template function with a new type, it would > require a new vtable entry. Therefore you need to know how every template > function in every derived class is instantiated before you can build the > base class vtable. This doesn't work with D's compilation model. >
Right, but when I tell something like rdmd to pass all my files into DMD, then DMD *does* have all the information needed. I understand that it can't be done in *all* build setups, but it would seem to be possible in many build setups, so why should *all* projects suffer when really only *some* projects have to have that limitation? That's what I've never understood. >> >> Now, as for whether or not D actually *does* omit the vtable entry for >> non-override finals, I wouldn't know. Although I seem to vaguely remember >> doing optimizations once that seemed to imply it did. If that's so, I >> don't know whether its guaranteed per D spec or just >> implementation-defined. A UFCS approach would definitely be guaranteed >> not to affect the vtable, of course. >> > > D (dmd) does not create a vtable entry for final functions that don't > override anything. It's in the frontend, so it should be the same for all > the d compilers. I see. Thanks.