Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-virtual interface (Template Method pattern) #484

Closed
Jon12345 opened this issue Jan 6, 2016 · 2 comments
Closed

Non-virtual interface (Template Method pattern) #484

Jon12345 opened this issue Jan 6, 2016 · 2 comments
Labels

Comments

@Jon12345
Copy link

Jon12345 commented Jan 6, 2016

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"?

@hsutter
Copy link
Contributor

hsutter commented Jan 7, 2016

Good catch, thanks.

@cubbimew
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants