Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #594

Re: Proposal: Compilation-unit scoped private member functions

Show all headers | View raw

On Friday, February 22, 2013 2:39:34 PM UTC-8, oot...@hot.ee wrote:
> On Friday, 22 February 2013 18:48:40 UTC+2, christophe...@googlemail.com  wrote:
> > On Tuesday, December 18, 2012 10:06:37 PM UTC, Ian Collins wrote:
> > >  christophe...@googlemail.com  wrote:
> > >>  On Friday, December 14, 2012 5:19:33 PM UTC, Ian Collins wrote:
> > >>>  Your proposal would not improve testability, the locally private
> > >>>  functions would, by virtue of their linkage, be impossible to test.
> > >>  How do you test a normal private function?
> > >  I wouldn't.
> >
> > So your objection to the proposal is that it doesn't improve tetability,
> > something which the OP didn't claim, when the current alternative is
> > from your comment, untestable.
>
> I trust that main problem with public functions that have huge set of
> responsibilities is that those are expensive to test.
>
> Such functions contain some core functionality and when software evolves
> are most often altered by maintenance. Good set of automated tests is
> only way to keep them under control.
>
> There are no difference how and if at all to split those into private
> parts that do not relieve that main problem.
>
> Splitting the responsibilities between several easier-to-test smaller
> classes is the usual path taken to reduce the complexity and said
> costs. Current proposal failed to mention the most usual practice in
> "Background".

"Most usual practice" is a loaded term. There are no "most usual
practices" for just about anything in C++. Some people love
test-driven design; some people avoid it like the plague. Some people
love templates and use them whenever possible; others don't. And so
on.

Many people do use test-driven coding techniques. But calling them
"usual practice" is simply a fact not in evidence. C++ has to serve
everyone, even people who don't do test-driven coding.

Or to put it another way, a possible feature of C++ should not be
discounted for the sole reason that it wouldn't be applicable to one
particular coding style. The fact that you could solve this problem in
some other way does not stop it from being a problem for someone who
doesn't feel that they should have to go through that much refactoring
to get the problem solved. And the fact that test-driven coding tends
to avoid these kinds of functions to begin with does not change the
fact that these kinds of functions *still get written*.

Or, to put another way, people who use bad design still need crutches ;)

Personally, I'd say that the far bigger problem is that the proposal
is generally driven by issues of compile time. In effect, he wants a
form of Pimpl, but just for private member functions. The only reason
to want this is to be able to add members without touching the header
and thus provoking a potentially vast recompile. Otherwise he could
just put them in the header, since private members are, by definition,
*not* part of the "public API".

This is an issue that is rooted in minimizing recompilation times. And
the modules proposal will be dealing with recompiling in a *far* more
effective way. In short, this, like Pimpl in general, will be a moot
point once we get modules. You'll just make the functions private, and
nobody will care, since any recompilation will be lightning fast.

And if the issue really is to remove them from the class just so that
people can't see them by looking at the header... that's not reason
enough to add a feature to the language. By that logic, we should be
able to remove private variables from the header too, possibly
replaced with some std::aligned_storage or whatnot.


--
[ 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 | Next in thread | Find similar

Thread

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