Advertising Inquiry to gcc.gnu.org

[Genry Lot via Gcc]

 Good day

Well, I had a look at your website and should say that it is really
impressive. I like the content you share as well as the style you use.
Today, I am writing to ask about advert opportunities on your website.

I’m greatly interested:

   - Guest posts,
   - Link insertion (in the existing article),
   - Homepage link placement,
   - Banners

Could you provide me with prices for these kinds of advertising?

Actually, I’m interested in permanent placements as well as the ones on a
monthly basis.

It would be a great plus if you can offer other online platforms for
advertising.

Looking forward to your answer!!!

gcc-8-20201126 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20201126 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20201126/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision c6145860aac6acfeed2a98fe7532dd2cd0ffab2b

You'll find:

 gcc-8-20201126.tar.xzComplete GCC

  SHA256=19ced46bc955ee50297b87ddb30c7dff85f215acf449dcad42e6749bc8f70ce2
  SHA1=103aa143344047434d783436bc28447448040ef8

Diffs from 8-20201119 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

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

[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.

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 via Gcc]

在 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 
:

>   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



signature.asc
Description: OpenPGP digital signature