[RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Jonathan Wakely jwakely.gcc@gmail.com
Thu Dec 5 20:56:00 GMT 2019


On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Thu, Dec 05, 2019 at 05:03:43PM +0000, Jonathan Wakely wrote:
> > C++17 introduces a nice feature, with rationale similar to declaring
> > variables in a for-loop init-statement:
> >
> > if (auto var = foo(); bar(var))
>
> Similar to GNU C statement expressions, which are *also* only a good
> idea to use in limited cases.
>
> > The variable is only in scope for the block where you need it, just
> > like a for-loop.
> >
> > Unfortunately nearly every time I've tried to use this recently, I've
> > found it's impossible in 80 columns, e.g. this from yesterday:
> >
> >     if (auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=>
> > 0; __c != 0)
> >       return __c;
> >
> > When you're forced to uglify every variable with a leading __ you run
> > out of characters pretty damn quickly.
>
> If using this "nice feature" forces you to uglify your code, then maybe
> it is not such a nice feature, and you should not use it.

The uglification has absolutely nothing to do with the 'if'
init-statement feature, all code in libstdc++ headers has to be
uglified, always. Blame the C preprocessor for that, not C++ features.

My point is that 80 characters runs out quicker when 10% of it goes on
visual noise that's only needed because the C preprocessor means we
can't have nice names.

> If you have issues with scoping your functions are WAY too long already.

I don't have issues with scoping, it's just good practice to limit the
scope to the minimum necessary.

The example I'm talking about is:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/stl_algobase.h;h=a2fd306e6d0cca579b510148ba1a7089e2b2f3a2;hb=HEAD#l1499

That function is 46 lines long, including a micro-optimisation to use
memcmpy when appropriate. About 15% of that is on assertions to help
users debug their mistakes. Another five lines are the compile-time
if-constexpr checks to decide when the optimisation is appropriate,
which result in deep nesting, but not because of any complex if-else
branches. It could be nested less deeply to reduce indentation by 4
spaces, but that would result in more template instantiations for
users, which would take more time and memory to compile. When you have
a million users including the header in every C++ program, little
things like that help. So the code is written in an unidiomatic way to
optimise for compilation speed, not readability.

But the end result is that the call to __min_cmp is indented about 25%
of the way into the available space, and that the FIRST line of
executable code in the function. The code is not way too long, and
writing it differently would compile slower. The constraints that
apply to that code are quite different to the internals of GCC, which
most users never see or even compile themselves.

(Yes, maybe libstdc++ should stop indenting everything by 2 columns
when it's inside a namespace, given that almost everything is inside
at least one level of namespace ... that might be a good idea even if
the column limit is extended to 100 or 132, but we'll still have all
the __ prefixes eating up space.)



More information about the Gcc-patches mailing list