January 22, 2012 [Issue 1918] __traits(getVirtualFunctions) returns final functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1918 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
January 23, 2012 [Issue 1918] __traits(getVirtualFunctions) returns final functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1918 --- Comment #9 from yebblies <yebblies@gmail.com> 2012-01-24 02:36:20 EST --- (In reply to comment #6) > Why would it be useful to have a non-virtual function listed as a virtual function? Because that's what you're doing when mark a function which doesn't override anything final. It's _not_ in any kind of override chain. Well, you make some good points. I'm not entirely convinced there isn't some template forwardingy application (are there any uses for __traits(getVirtualFunctions)?) that would find the other way useful. Anyway, I'm not sure this fix is correct. After a little bit of poking around I discovered that a final method that doesn't override anything IS STILL VIRTUAL. It still creates a vtable slot. Is this a bug? From what I can tell that means there is no way to actually create a non-virtual non-static member function. If final functions that do not override anything were implicitly non-virtual, it would fix this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
January 23, 2012 [Issue 1918] __traits(getVirtualFunctions) returns final functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1918 --- Comment #10 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-01-23 07:56:13 PST --- final functions which don't override anything _definitely_ shouldn't be virtual. There's no reason for them to be virtual, and it harms performance. If the compiler fails to make them non-virtual, then that's definitely a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
January 23, 2012 [Issue 1918] __traits(getVirtualFunctions) returns final functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1918 --- Comment #11 from yebblies <yebblies@gmail.com> 2012-01-24 04:25:43 EST --- (In reply to comment #10) > final functions which don't override anything _definitely_ shouldn't be virtual. There's no reason for them to be virtual, and it harms performance. If the compiler fails to make them non-virtual, then that's definitely a bug. By the looks of it, the compiler manages to optimize out the virtual call with all final functions, which is probably why nobody ever noticed this before. The problem seems to be that whether the functions actually needs a vtable slot is resolved much too late. This is essential for linking with c++, which I'm trying to improve. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation