None of the idlc-generated interfaces require vtables, as they are all pure-virtual classes. This saves a marginal amount of space on Win32 (about 25KB).
Of course, all of the DOM IDL will need to be regenerated, too. Does this seem reasonable?
I see no reason to not make this change other than the fact that the interfaces will be converted over to XPILD soon so we'll get NS_NO_VTABLE from xpidl automatically once that's done.
Does that count as ``r=jst''?
sr=jband Looks good to me. Like jst said, we want to make this unnecessary soon. Also, don't be too aggressive in spreading the NS_NO_VTABLE meme. It is a sharp tool. If it gets applied to a class that does actually call a virtual method in its ctor then *very* bad things happen.
jband: I presume that you meant, "if it accidentally gets applied to a class that has anything but pure virtual methods, then very bad things will happen." Or do I have a fundamental misunderstanding of what's going on here?
waterson: you got it right. I think this is fine here. I'm just generally concerned about people emulating this pattern without understanding where it is approriate and where it is not. It is actually technically OK to apply it on classes that have some implemented virtuals as long as that class's ctor does not actually call those methods (directly or otherwise). For me this was a concern in even creating NS_NO_VTABLE and putting it in our headers. Our project is plagued by copy/paste programming. I just don't want to see someone out there sprinking these all over the place because the *current* implementation of class X does not happen to call virtual method Y in its ctor. I'm just cautioning that we should be careful about how the meme is spread.
Changes checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.