public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Paul Smith <psmith@gnu.org>
Cc: Kai Song <kaisong1515@gmail.com>, gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Compilation of lengthy C++ Files
Date: Sat, 21 Oct 2023 07:52:16 +0100	[thread overview]
Message-ID: <CAH6eHdRM4E4frMgV4kye2Gmy8bPAPg+WndFAnZdsHXwrwK6g0g@mail.gmail.com> (raw)
In-Reply-To: <f0805cc954218be623158d95c58c45167b8995b8.camel@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Fri, 20 Oct 2023, 23:04 Paul Smith via Gcc-help, <gcc-help@gcc.gnu.org>
wrote:

> On Fri, 2023-10-20 at 23:08 +0200, Kai Song via Gcc-help wrote:
> > Yes. I have invested time on my end to cause some understanding for
> > an issue.
>
> Maybe I can provide context.  Note I'm not a GCC developer although I
> have worked on compiler implementations in the past.
>
> The C++ standard defines an abstract definition.  Individual
> implementations of compilers for the C++ standard will have limitations
> on the abstract definition, obviously: computers are not abstract and
> so they are limited.
>

And this is explicitly called out in the C++ standard:
https://eel.is/c++draft/intro.compliance#general-2.1
https://eel.is/c++draft/implimits


Kai, we are not sceptics who are doubting your marvelous theories. It is an
empirical fact that gcc will fail to compile ridiculously large functions
written in your preferred coding style. Some of us have tried to suggest
alternatives that might have more success.

At this point I consider any further engagement in this thread to be a
waste of time. You have answers to your questions now, but you seem
unwilling to take the advice given.

Good luck compiling your ridiculously constructed programs.

  reply	other threads:[~2023-10-21  6:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 16:04 Kai Song
2023-10-18 21:59 ` Jonathan Wakely
2023-10-19  8:36   ` Andrew Haley
2023-10-19 12:47 ` David Brown
2023-10-19 12:47   ` David Brown
2023-10-19 14:16   ` Kai Song
2023-10-19 14:26     ` Jonathan Wakely
2023-10-19 15:11       ` Kai Song
2023-10-19 16:03         ` David Brown
2023-10-20  9:32           ` Kai Song
2023-10-20 10:19             ` Jonathan Wakely
     [not found]             ` <CACJ51z3rYUSSe7XpcL4d2xfAhMaiVZpxWAnpkqZc1cn2DRf+uA@mail.gmail.com>
2023-10-20 21:08               ` Kai Song
2023-10-20 22:03                 ` Paul Smith
2023-10-21  6:52                   ` Jonathan Wakely [this message]
2023-10-21 14:10                     ` Kai Song
2023-10-24 14:57                       ` Paul Smith
2023-10-25 11:09                         ` Richard Earnshaw
2023-10-25 14:49                           ` Paul Smith
2023-10-26 11:19                             ` David Brown
2023-10-19 15:15     ` David Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH6eHdRM4E4frMgV4kye2Gmy8bPAPg+WndFAnZdsHXwrwK6g0g@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=kaisong1515@gmail.com \
    --cc=psmith@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).