Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Newsgroups | comp.std.c++ |
| Subject | Re: Proposal: Compilation-unit scoped private member functions |
| Date | 2013-02-28 22:16 -0800 |
| Organization | Sonic.Net |
| Message-ID | <512EB1FB.2050304@amacapital.net> (permalink) |
| References | <ff2d9902-a232-40f4-9e22-97b2563099f8@googlegroups.com> <ahu6pqFijb1U1@mid.individual.net> <kgdpvp$1qju$1@news.ett.com.ua> |
On 02/25/2013 09:01 AM, Balog Pal wrote: > > On 12/14/2012 6:19 PM, Ian Collins wrote: >>> Currently many C++ programmers revert to one of these approaches to >>> implementing complex/lengthy member functions: >>> >>> 1. Write huge, unwieldy member functions that become incredibly >>> difficult to validate / test / document, >> >> Your proposal would not improve testability, the locally private >> functions would, by virtue of their linkage, be impossible to test. > > IMO "impossible" goes too far -- those who want to test the private > functions directly can put the test in that TU or #include the > implementation file in the test case. Those who test privates through > public interface get the same as before. > > But if term "testability" is used in a wider sense, not limited to > automatic code execution, the proposal provides tools to provide more > locality and flexibility. What is positive. *If* the premise of "minor > language change" holds IMO it worth investigating. > >> It is better to split the functionality into smaller objects than to >> design a class with member function that end up doing too much (with >> results in the bloated code you describe earlier). > > There are cases where you mostly operate with functions and creating > more objects does not help. > > And my estimate on private function attributes is that majority would > fit listed restriction, so could be put out of class. > > And having privates in the class headers is quite PITA now for a ton of > reasons while PIMPL is also painful at best. So I consider anything in > between is value. > > Just to mention one painful case, that would be solved by the proposal: > if my private functions use types from some different header, but I'm > lucky enough to not need any of those types in the class state (or can > work that around). It's not exactly rare, and I could go back to include > those foreign headers with implementation only. > >> I can see some merit in the suggestion, but it looks to much like a >> crutch for bad design rather than a cure... > > To me it looks like a patch on imperfections the language has. And on > one that is addressed/worked around on daily basis in many suboptimal > ways. Yes, it is not a root-cause cure (what possibly a perfect > "modules" solution would be) but on the correct vector. > > If we're positive that a better proposal will cover the cases in the > next release, sure, let's concentrate efforts on that one, otherwise I > think "light" improvements are better processed. Another reason: libraries. If cleaning up the implementation of a class in a library requires adding a new non-virtual private member function, you risk running into spurious ODR issues. This proposal eliminates that problem. (If you can give these special function static or extern linkage upon request, then you can test them easily and you can access them from multiple files in a library while still retaining the benefits.) --Andy -- [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Back to comp.std.c++ | Previous | Next — Previous in thread | Find similar
Proposal: Compilation-unit scoped private member functions kfsone@googlemail.com - 2012-11-21 11:29 -0800
Re: Proposal: Compilation-unit scoped private member functions Francis Glassborow<francis.glassborow@btinternet.com> - 2012-12-14 09:10 -0800
Re: Proposal: Compilation-unit scoped private member functions Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-12-14 09:11 -0800
Re: Proposal: Compilation-unit scoped private member functions Ian Collins<ian-news@this.is.invalid> - 2012-12-14 09:19 -0800
Re: Proposal: Compilation-unit scoped private member functions christopher.dearlove@googlemail.com - 2012-12-17 08:52 -0800
Re: Proposal: Compilation-unit scoped private member functions Ian Collins<ian-news@this.is.invalid> - 2012-12-18 16:06 -0600
Re: Proposal: Compilation-unit scoped private member functions christopher.dearlove@googlemail.com - 2013-02-22 10:48 -0600
Re: Proposal: Compilation-unit scoped private member functions ootiib@hot.ee - 2013-02-22 16:39 -0600
Re: Proposal: Compilation-unit scoped private member functions Jason McKesson <jmckesson@googlemail.com> - 2013-02-23 23:22 -0800
Re: Proposal: Compilation-unit scoped private member functions Balog Pal<pasa@lib.hu> - 2013-02-25 11:01 -0600
Re: Proposal: Compilation-unit scoped private member functions Ian Collins <ian-news@this.is.invalid> - 2013-02-23 18:21 -0800
Re: Proposal: Compilation-unit scoped private member functions christopher.dearlove@googlemail.com - 2013-02-25 10:59 -0600
Re: Proposal: Compilation-unit scoped private member functions Balog Pal<pasa@lib.hu> - 2013-02-25 11:01 -0600
Re: Proposal: Compilation-unit scoped private member functions Andy Lutomirski <luto@amacapital.net> - 2013-02-28 22:16 -0800
csiph-web