public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: leon zadorin <leonleon77@gmail.com>
To: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: which compiler is right (either to compile or to barf)...
Date: Fri, 2 Dec 2022 18:18:48 +1100	[thread overview]
Message-ID: <CAPpySAaHZ6gwfQDGS22SG1+dzJjkqjtZbTvv7vm+zq=FSwOnGw@mail.gmail.com> (raw)
In-Reply-To: <81026ee4-8f45-3d45-57ca-a9abed92c722@126.com>

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

On Fri, Dec 2, 2022 at 5:37 PM LIU Hao <lh_mouse@126.com> wrote:

> 在 2022/12/2 08:17, leon zadorin via Gcc-help 写道:
> No, you do not _instantiate_ `J<X>`. The behavior would have been
> undefined if you did.
> `::std::shared_ptr<J<X>> p;` is fine on itself, because `J<X>` is not
> instantiated. On the other
> hand, `::std::shared_ptr<J<X>> p(static_cast<J<X>*>(nullptr));` is
> undefined, as it instantiates a
> delete expression.
>
>
> In addition to that, [temp.point]/1 specifies that the point of
> instantiation of members of a class
> template _follows the end of_ namespace scope of the most enclosing
> specialization. This allows use
> before definition, which is not permitted for non-template classes:
>
>     std::shared_ptr<struct foo> ptr(
>           (struct foo*) nullptr);  // instantiates `delete (struct foo*)
> ___`
>
>     struct foo { };   // the line above would have undefined behavior
> without this
>
>
> So, either way, your code is not undefined.
>
>
Wow, ok, many thanks -- veeery interesting :) So I'm getting confused a
little :)

Let me summarize here:

(1) On the one hand, given that I do instantiate ::std::optional with S
(whith has member v whose elements' types, I guess(?) are at the line of
declaring 'static ::std::optional<S> s', are still incompletely denifed,
i.e. X) -- the clang discussion appears to say that at this moment optional
is instantiated and S is incomplete (?) ... as so it is a UB... which I
understood Jonathan's comment to relate to as well.

(2) However, from your comment it would appear that 'instantiation of
members of class template' is done afterwards anyways...

I suppose to reconcile both bits of info:

(a) 'instantitation of members of class template' ... is it the same for
instantitaion of the class template itself? (because UB specs appears to
provide restrictions on std lib class instantiations, not specifically to
inner members, but just for whole class)?; and

(b) in the above code right at the line 'static ::std::optional<S> s' is S
considered incomplete type at that moment?

... I'm just trying to figure out whether template "::std::optional<S>" is,
itself, being instantiated at that very line (never mind its members) and
if type S at that moment is considered to be incomplete... in which case it
is UB... if not then may be its not a UB... I am confused :) ha ha :)
wouldn't be the first time though :)

  reply	other threads:[~2022-12-02  7:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01  4:51 leon zadorin
2022-12-01  9:35 ` LIU Hao
2022-12-01 23:26   ` leon zadorin
2022-12-01 23:54     ` Jonathan Wakely
2022-12-01 23:56       ` Jonathan Wakely
2022-12-02  0:17       ` leon zadorin
2022-12-02  6:37         ` LIU Hao
2022-12-02  7:18           ` leon zadorin [this message]
2022-12-02  7:22             ` leon zadorin
2022-12-02  7:45             ` LIU Hao
2022-12-02  8:34               ` leon zadorin
2022-12-02  9:16                 ` leon zadorin
2022-12-02 10:50                   ` leon zadorin

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='CAPpySAaHZ6gwfQDGS22SG1+dzJjkqjtZbTvv7vm+zq=FSwOnGw@mail.gmail.com' \
    --to=leonleon77@gmail.com \
    --cc=gcc-help@gcc.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).