You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although I originally submitted that TODO item expecting a "yes" as well, I am not sure it makes a good candidate for a guideline that may be checked by tools: mechanically NVI'ing every virtual function gives us things like std::time_get with seven dummy public forwarders. Is it any different from dummy getters and setters? If the customization points exactly match the public API this seems superfluous.
Something like std::streambuf, where customization points are entirely different from the public API makes more sense as a design guideline, but how could it be formalized?
I was surprised to read "Speaking of virtual functions, should non-virtual interface be promoted? NO." in the "To-do" list.
The guidelines in http://www.gotw.ca/publications/mill18.htm are sound, yet not widely understood.
What's the reason for the "NO"?
The text was updated successfully, but these errors were encountered: