[RFC] Increase libstdc++ line length to 100(?) columns

[RFC] Increase libstdc++ line length to 100(?) columns

[Jonathan Wakely]

I've touched on the subject a few times, e.g.
https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html

Libstdc++ code is indented by 2 columns for the enclosing namespace,
usually another two for being in a template, and is full of __
prefixes for reserved names. On top of that, modern C++ declarations
are *noisy* (template head, requires-clause, noexcept-specifier, often
'constexpr' or 'inline' and 'explicit', and maybe some attributes.

All that gets hard to fit in 80 columns without compromising
readability with line breaks in unnatural places.

Does anybody object to raising the line length for libstdc++ code
(not the rest of GCC) to 100 columns?

Please read my replies in the thread linked above before telling me
that the code should be split up into smaller functions to avoid deep
nesting. The function I pointed to cannot easily be split up without
making the code slower to compile and potentially slower to run:
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

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 1841 bytes --]

在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
> 
> Libstdc++ code is indented by 2 columns for the enclosing namespace,
> usually another two for being in a template, and is full of __
> prefixes for reserved names. On top of that, modern C++ declarations
> are *noisy* (template head, requires-clause, noexcept-specifier, often
> 'constexpr' or 'inline' and 'explicit', and maybe some attributes.
> 
> All that gets hard to fit in 80 columns without compromising
> readability with line breaks in unnatural places.
> 

I think I want to vote +1 for this. On my 1920x1080 laptop screen with an 11pt monospace font, 100
colons allows me to open two terminals side by side, while still providing 3 colons for line
numbers. On a larger desktop screen with a 10pt font it'd be 132 colomns, but more often I find
lines longer than 110 characters hard to read, so I agree with 100 (but I suggest making it a
'recommended limit' instead of a 'hard limit' anyway).


There was a small fragment of code in <https://gcc.gnu.org/pipermail/gcc/2019-December/231003.html>:

>                       if (present)
>                         ptr
>                           = gfc_build_conditional_assign_expr (block, present,
>                                                                ptr, nullarg);

Why not change this to:

>                       if (present)
>                         ptr = gfc_build_conditional_assign_expr (
>                             block, present, ptr, nullarg);
> 

I think it looks balanced and way more comfortable, and doesn't waste much leading space.




-- 
Best regards,
LH_Mouse


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Richard Biener]

On Fri, Nov 27, 2020 at 3:48 AM Liu Hao via Gcc <gcc@gcc.gnu.org> wrote:
>
> 在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> > I've touched on the subject a few times, e.g.
> > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> > and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
> >
> > Libstdc++ code is indented by 2 columns for the enclosing namespace,
> > usually another two for being in a template, and is full of __
> > prefixes for reserved names. On top of that, modern C++ declarations
> > are *noisy* (template head, requires-clause, noexcept-specifier, often
> > 'constexpr' or 'inline' and 'explicit', and maybe some attributes.
> >
> > All that gets hard to fit in 80 columns without compromising
> > readability with line breaks in unnatural places.
> >
>
> I think I want to vote +1 for this. On my 1920x1080 laptop screen with an 11pt monospace font, 100
> colons allows me to open two terminals side by side, while still providing 3 colons for line
> numbers. On a larger desktop screen with a 10pt font it'd be 132 colomns, but more often I find
> lines longer than 110 characters hard to read, so I agree with 100 (but I suggest making it a
> 'recommended limit' instead of a 'hard limit' anyway).
>
>
> There was a small fragment of code in <https://gcc.gnu.org/pipermail/gcc/2019-December/231003.html>:
>
> >                       if (present)
> >                         ptr
> >                           = gfc_build_conditional_assign_expr (block, present,
> >                                                                ptr, nullarg);
>
> Why not change this to:
>
> >                       if (present)
> >                         ptr = gfc_build_conditional_assign_expr (
> >                             block, present, ptr, nullarg);
> >
>
> I think it looks balanced and way more comfortable, and doesn't waste much leading space.

Other places use

       if (present)
         ptr = gfc_build_conditional_assign_expr
                                  (block, present, ptr, nullarg);

I prefer the ( on the next line.  The argument list can be two spaces
indented from
the function name or "right justified" (I think the latter looks
visually better).

Richard.

>
>
>
> --
> Best regards,
> LH_Mouse
>

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Ville Voutilainen]

On Fri, 27 Nov 2020 at 10:16, Richard Biener via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
> > Why not change this to:
> >
> > >                       if (present)
> > >                         ptr = gfc_build_conditional_assign_expr (
> > >                             block, present, ptr, nullarg);
> > >
> >
> > I think it looks balanced and way more comfortable, and doesn't waste much leading space.
>
> Other places use
>
>        if (present)
>          ptr = gfc_build_conditional_assign_expr
>                                   (block, present, ptr, nullarg);
>
> I prefer the ( on the next line.  The argument list can be two spaces
> indented from
> the function name or "right justified" (I think the latter looks
> visually better).

I find it easier to grok the code when the opening paren is on the
first line, I know instantly that I'm
looking at a function call. That sort of style probably fits better
the C++ code in libstdc++ than the code
in gcc, because in libstdc++ code we don't have a space before the
argument list.

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 1521 bytes --]

在 2020/11/27 下午4:14, Richard Biener 写道:
> 
> I prefer the ( on the next line.  The argument list can be two spaces
> indented from
> the function name or "right justified" (I think the latter looks
> visually better).
> 

The right justification thing looks reasonable. For example, I think this

```c++
basic_cow_string(const basic_cow_string& other)
  noexcept
  : m_sth(allocator_traits<allocator_type>::select_on_container_copy_construction(
                                                other.m_sth.as_allocator()))
  { this->assign(other);  }
```

looks better than

```c++
basic_cow_string(const basic_cow_string& other)
  noexcept
  : m_sth(allocator_traits<allocator_type>::select_on_container_copy_construction(
          other.m_sth.as_allocator()))
  { this->assign(other);  }
```

In the former fragment, indention of the 4th line is probably arbitrary. The only purpose is that,
if there wasn't a line break, the 3rd line would exceed a given length limit.

As you can see, qualified names in C++ can grow up to ~100 characters quite frequently. This may
deteriorate when `typename` and `template` are sometimes required. I don't think there is
practically a set of rules which governs all cases. So, if something looks better, go for it, and
that's why I think a (suggested) 100-char limit is better than the conventional 80-char limit, which
forces another line break in front of `select_on_container_copy_construction`.


-- 
Best regards,
LH_Mouse


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Ville Voutilainen]

On Fri, 27 Nov 2020 at 11:54, Liu Hao via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
> As you can see, qualified names in C++ can grow up to ~100 characters quite frequently. This may
> deteriorate when `typename` and `template` are sometimes required. I don't think there is
> practically a set of rules which governs all cases. So, if something looks better, go for it, and
> that's why I think a (suggested) 100-char limit is better than the conventional 80-char limit, which
> forces another line break in front of `select_on_container_copy_construction`.

I do have a general question/thought/rumination here, though.
Shouldn't the paren-style and the line length
of libstdc++ be mainly decided by those who develop and maintain it?
It's already not written in the same style
as gcc is, so tweaking that different style to better suit the need of
a template-heavy C++ library perhaps
should be more or less a slam dunk? :)

Despite my sizable contributions to libstd++, I don't have a
particularly strong opinion here. Except that,
my somewhat strong opinion is "let's give Jonathan what he wants,
because it helps his work". ;)

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Allan Sandfeld Jensen]

On Freitag, 27. November 2020 00:50:57 CET Jonathan Wakely via Gcc wrote:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
> 
> Libstdc++ code is indented by 2 columns for the enclosing namespace,
> usually another two for being in a template, and is full of __
> prefixes for reserved names. On top of that, modern C++ declarations
> are *noisy* (template head, requires-clause, noexcept-specifier, often
> 'constexpr' or 'inline' and 'explicit', and maybe some attributes.
> 
> All that gets hard to fit in 80 columns without compromising
> readability with line breaks in unnatural places.
> 
> Does anybody object to raising the line length for libstdc++ code
> (not the rest of GCC) to 100 columns?
> 
If you _do_ change it. I would suggest changing it to 120, which is next 
common step for a lot of C++ projects.

Often also with an allowance for overruns if that makes the code cleaner.

'Allan

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Ed Smith-Rowland]

On 11/26/20 6:50 PM, Jonathan Wakely via Gcc wrote:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
>
> Libstdc++ code is indented by 2 columns for the enclosing namespace,
> usually another two for being in a template, and is full of __
> prefixes for reserved names. On top of that, modern C++ declarations
> are *noisy* (template head, requires-clause, noexcept-specifier, often
> 'constexpr' or 'inline' and 'explicit', and maybe some attributes.
>
> All that gets hard to fit in 80 columns without compromising
> readability with line breaks in unnatural places.
>
> Does anybody object to raising the line length for libstdc++ code
> (not the rest of GCC) to 100 columns?
>
> Please read my replies in the thread linked above before telling me
> that the code should be split up into smaller functions to avoid deep
> nesting. The function I pointed to cannot easily be split up without
> making the code slower to compile and potentially slower to run:
> 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 
>
>
+1

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Thomas Koenig]

Am 27.11.20 um 00:50 schrieb Jonathan Wakely via Gcc:
> Does anybody object to raising the line length for libstdc++ code
> (not the rest of GCC) to 100 columns?

In gfortran, we have a habit of using long and expressive function
names (which is good) which lead to lots of columns of indentation,
which leads to excessive line breaks when restricted to 80 columns
(which is bad).

Even a modest increase could lead to much better readable code.
I'd also support increasing the line length there to something
reasonable, and 100 certainly isn't too high.

Fortran moved on from 80-column-card format a long time ago, we now
have 132 as maximum line length :-)

Best regards

	Thomas

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Florian Weimer]

* Allan Sandfeld Jensen:

> If you _do_ change it. I would suggest changing it to 120, which is next 
> common step for a lot of C++ projects.

120 can be problematic for a full HD screen in portrait mode.  Nine
pixels per character is not a lot (it's what VGA used), and you can't
have any window decoration.  With a good font and screen, it's doable.
But if the screen isn't quite sharp, then I think you wouldn't be able
to use portrait mode anymore.

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Allan Sandfeld Jensen]

On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote:
> * Allan Sandfeld Jensen:
> > If you _do_ change it. I would suggest changing it to 120, which is next
> > common step for a lot of C++ projects.
> 
> 120 can be problematic for a full HD screen in portrait mode.  Nine
> pixels per character is not a lot (it's what VGA used), and you can't
> have any window decoration.  With a good font and screen, it's doable.
> But if the screen isn't quite sharp, then I think you wouldn't be able
> to use portrait mode anymore.

Using a standard condensed monospace font of 9px, it has a width of 7px, 120 
char would take up 940px fitting two windows in horizontal mode and one in 
vertical. 9px isn't fuzzy, and 8px variants are even narrower.

Sure using square monospace fonts might not fit, but that is an unusual 
configuration and easily worked around by living with a non-square monospace 
font, or accepting occational line overflow. Remember nobody is suggesting 
every line should be that long, just allowing it to allow better structural 
indentation.

'Allan

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Michael Matz]

Hello,

On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote:

> On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote:
> > * Allan Sandfeld Jensen:
> > > If you _do_ change it. I would suggest changing it to 120, which is next
> > > common step for a lot of C++ projects.
> > 
> > 120 can be problematic for a full HD screen in portrait mode.  Nine
> > pixels per character is not a lot (it's what VGA used), and you can't
> > have any window decoration.  With a good font and screen, it's doable.
> > But if the screen isn't quite sharp, then I think you wouldn't be able
> > to use portrait mode anymore.
> 
> Using a standard condensed monospace font of 9px, it has a width of 7px, 120 

A char width of 7px implies a cell width of at least 8px (so 960px for 120 
chars), more often of 9px.  With your cell width of 7px your characters 
will be max 6px, symmetric characters will be 5px, which is really small.

> char would take up 940px fitting two windows in horizontal mode and one in 
> vertical. 9px isn't fuzzy, and 8px variants are even narrower.

Well, and if you're fine with a 5px cell-width font then you can even fit 
216 chars on a line in HD portrait mode.  But Florian posed the width of 
9px, and I agree with him that it's not a lot (if my monitor weren't as 
big as it is I would need to use an even wider font for comfortable 
reading, as it is 9px width are exactly right for me, I'm not using 
portrait, though).  So, it's the question if the line lengths should or 
should not cater for this situation.

> Sure using square monospace fonts might not fit, but that is an unusual 
> configuration and easily worked around by living with a non-square monospace 
> font, or accepting occational line overflow. Remember nobody is suggesting 
> every line should be that long, just allowing it to allow better structural 
> indentation.

The occasional line overflow will automatically become the usual case with 
time, space allowed to be filled will eventually be filled.


Ciao,
Michael.

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Allan Sandfeld Jensen]

On Montag, 30. November 2020 16:47:08 CET Michael Matz wrote:
> Hello,
> 
> On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote:
> > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote:
> > > * Allan Sandfeld Jensen:
> > > > If you _do_ change it. I would suggest changing it to 120, which is
> > > > next
> > > > common step for a lot of C++ projects.
> > > 
> > > 120 can be problematic for a full HD screen in portrait mode.  Nine
> > > pixels per character is not a lot (it's what VGA used), and you can't
> > > have any window decoration.  With a good font and screen, it's doable.
> > > But if the screen isn't quite sharp, then I think you wouldn't be able
> > > to use portrait mode anymore.
> > 
> > Using a standard condensed monospace font of 9px, it has a width of 7px,
> > 120
> A char width of 7px implies a cell width of at least 8px (so 960px for 120
> chars), more often of 9px.  With your cell width of 7px your characters
> will be max 6px, symmetric characters will be 5px, which is really small.
> 
I was talking about the full cell width. I tested it before commenting, 
measuring the width in pixels of a line of text.

'Allan

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Michael Matz]

Hello,

On Mon, 30 Nov 2020, Allan Sandfeld Jensen wrote:

> > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote:
> > > > * Allan Sandfeld Jensen:
> > > > > If you _do_ change it. I would suggest changing it to 120, which is
> > > > > next
> > > > > common step for a lot of C++ projects.
> > > > 
> > > > 120 can be problematic for a full HD screen in portrait mode.  Nine
> > > > pixels per character is not a lot (it's what VGA used), and you can't
> > > > have any window decoration.  With a good font and screen, it's doable.
> > > > But if the screen isn't quite sharp, then I think you wouldn't be able
> > > > to use portrait mode anymore.
> > > 
> > > Using a standard condensed monospace font of 9px, it has a width of 7px,
> > > 120
> > A char width of 7px implies a cell width of at least 8px (so 960px for 120
> > chars), more often of 9px.  With your cell width of 7px your characters
> > will be max 6px, symmetric characters will be 5px, which is really small.
> > 
> I was talking about the full cell width. I tested it before commenting, 
> measuring the width in pixels of a line of text.

Yes, and I was saying that a cell width of 7px is very narrow because the 
characters itself will only be using 5px or 6px max (to leave room for 
inter-character spacing in normal words).  You might be fine with such 
narrow characters, but not everyone will be.


Ciao,
Michael.

Re: [RFC] Increase libstdc++ line length to 100(?) columns

[Richard Earnshaw]

On 29/11/2020 17:38, Florian Weimer wrote:
> * Allan Sandfeld Jensen:
> 
>> If you _do_ change it. I would suggest changing it to 120, which is next 
>> common step for a lot of C++ projects.
> 
> 120 can be problematic for a full HD screen in portrait mode.  Nine
> pixels per character is not a lot (it's what VGA used), and you can't
> have any window decoration.  With a good font and screen, it's doable.
> But if the screen isn't quite sharp, then I think you wouldn't be able
> to use portrait mode anymore.
> 

Please remember that not everyone has 20:20 vision.  Requiring a
terminal width that's so large that the text is wrapped (or, worse, you
get horizontal scroll bars) is not acceptable, IMO.

R.