public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/110195] New: defaulted constructor does not respect the private accessor
@ 2023-06-09 15:21 jack.cui2 at foxmail dot com
2023-06-09 15:27 ` [Bug c++/110195] " pinskia at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: jack.cui2 at foxmail dot com @ 2023-06-09 15:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
Bug ID: 110195
Summary: defaulted constructor does not respect the private
accessor
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jack.cui2 at foxmail dot com
Target Milestone: ---
class Single
{
private:
Single() = default;
};
auto s1 = Single{}; // compiles fine with c++11,14,17. Compilation error with
c++20. Unexpected.
auto s2 = Single(); // compilation error. expected behavior.
Single s3; // compilation error. expected behavior.
----------------------------
but with
class Single
{
private:
explicit Single() = default;
};
or
class Single
{
private:
Single() {}
};
auto s1 = Single{}; // compilation error. expected behavior.
auto s2 = Single(); // compilation error. expected behavior.
Single s3; // compilation error. expected behavior.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
@ 2023-06-09 15:27 ` pinskia at gcc dot gnu.org
2023-06-09 15:35 ` jack.cui2 at foxmail dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-09 15:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Before C++20, Single{} didn't call the constructor so this behavior is
expected.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
2023-06-09 15:27 ` [Bug c++/110195] " pinskia at gcc dot gnu.org
@ 2023-06-09 15:35 ` jack.cui2 at foxmail dot com
2023-06-09 16:10 ` jack.cui2 at foxmail dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jack.cui2 at foxmail dot com @ 2023-06-09 15:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #2 from jack <jack.cui2 at foxmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Before C++20, Single{} didn't call the constructor so this behavior is
> expected.
Could you explain why it didn't call the constructor before c++20? C++ standard
rules or compiler make it this way?
Really appreciate if you could explain a bit more.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
2023-06-09 15:27 ` [Bug c++/110195] " pinskia at gcc dot gnu.org
2023-06-09 15:35 ` jack.cui2 at foxmail dot com
@ 2023-06-09 16:10 ` jack.cui2 at foxmail dot com
2023-06-09 16:13 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jack.cui2 at foxmail dot com @ 2023-06-09 16:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
jack <jack.cui2 at foxmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |UNCONFIRMED
--- Comment #3 from jack <jack.cui2 at foxmail dot com> ---
Tried another version.
class Single
{
private:
Single() = default;
int a;
};
auto s1 = Single{}; // compilation error. expected behavior
What is the difference compared with
class Single
{
private:
Single() = default;
};
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
` (2 preceding siblings ...)
2023-06-09 16:10 ` jack.cui2 at foxmail dot com
@ 2023-06-09 16:13 ` pinskia at gcc dot gnu.org
2023-06-09 16:19 ` jack.cui2 at foxmail dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-09 16:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note clang accepts Single{} where Single is an empty class also before C++20
...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
` (3 preceding siblings ...)
2023-06-09 16:13 ` pinskia at gcc dot gnu.org
@ 2023-06-09 16:19 ` jack.cui2 at foxmail dot com
2023-06-09 20:52 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jack.cui2 at foxmail dot com @ 2023-06-09 16:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #5 from jack <jack.cui2 at foxmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> Note clang accepts Single{} where Single is an empty class also before C++20
> ...
I think Clang accepting empty class case does not neccessarily mean it is
correct.
Because this one defeat the purpose of the uniform initialization and probably
a surprise that use can create it even if it is private.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
` (4 preceding siblings ...)
2023-06-09 16:19 ` jack.cui2 at foxmail dot com
@ 2023-06-09 20:52 ` redi at gcc dot gnu.org
2023-06-10 1:25 ` jack.cui2 at foxmail dot com
2023-06-10 8:18 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-09 20:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to jack from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Before C++20, Single{} didn't call the constructor so this behavior is
> > expected.
>
> Could you explain why it didn't call the constructor before c++20? C++
> standard rules or compiler make it this way?
The standard.
class Single
{
private:
Single() = default;
};
In C++17 Single is an aggregate, and Single{} is aggregate-initialization,
which initializes each member in turn, without calling a constructor. Since it
doesn't use the constructor, it doesn't matter if it's private.
In C++20 it's not an aggregate, so Single{} does value-initialization using the
constructor, which is private.
The C++17 rule is:
An aggregate is an array or a class (Clause 12) with
— no user-provided, explicit, or inherited constructors (15.1),
— no private or protected non-static data members (Clause 14),
— no virtual functions (13.3), and
— no virtual, private, or protected base classes (13.1).
The type above meets this definition. It has a user-declared constructor, but
not a user-provided constructor.
In C++20 the rule changed to:
An aggregate is an array or a class (Clause 11) with
— no user-declared or inherited constructors (11.4.5),
— no private or protected direct non-static data members (11.8),
— no private or protected direct base classes (11.8.3), and
— no virtual functions (11.7.3) or virtual base classes (11.7.2).
Now the user-declared constructor means it's not an aggregate.
For the other classes:
class Single
{
private:
explicit Single() = default;
};
Not an aggregate in any version of C++ because it has an explicit user-declared
constructor.
class Single
{
private:
Single() {}
};
Not an aggregate in any version of C++ because it has a user-provided
constructor.
class Single
{
private:
Single() = default;
int a;
};
Not an aggregate in any version of C++ because it has a private member.
In all these cases the type is not an aggregate, so Single{} always does
value-initialization and always uses the constructor.
GCC is doing exactly what the standard requires.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
` (5 preceding siblings ...)
2023-06-09 20:52 ` redi at gcc dot gnu.org
@ 2023-06-10 1:25 ` jack.cui2 at foxmail dot com
2023-06-10 8:18 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jack.cui2 at foxmail dot com @ 2023-06-10 1:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #7 from jack <jack.cui2 at foxmail dot com> ---
(In reply to Jonathan Wakely from comment #6)
> The standard.
> In C++17 Single is an aggregate, and Single{} is aggregate-initialization,
> which initializes each member in turn, without calling a constructor. Since
> it doesn't use the constructor, it doesn't matter if it's private.
> ...
> ...
> In all these cases the type is not an aggregate, so Single{} always does
> value-initialization and always uses the constructor.
>
> GCC is doing exactly what the standard requires.
Thanks for the detailed information. Clears my confusion.
Could we say this is a defect in C++ standard but fixed in C++20?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/110195] defaulted constructor does not respect the private accessor
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
` (6 preceding siblings ...)
2023-06-10 1:25 ` jack.cui2 at foxmail dot com
@ 2023-06-10 8:18 ` redi at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-10 8:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In the context of the C++ standard a "defect report" has a very specific
meaning, and it doesn't apply here.
The proposal
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1008r1.pdf changed
this property, and doesn't describe the old semantics as defective, just
unfortunate.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-06-10 8:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-09 15:21 [Bug c++/110195] New: defaulted constructor does not respect the private accessor jack.cui2 at foxmail dot com
2023-06-09 15:27 ` [Bug c++/110195] " pinskia at gcc dot gnu.org
2023-06-09 15:35 ` jack.cui2 at foxmail dot com
2023-06-09 16:10 ` jack.cui2 at foxmail dot com
2023-06-09 16:13 ` pinskia at gcc dot gnu.org
2023-06-09 16:19 ` jack.cui2 at foxmail dot com
2023-06-09 20:52 ` redi at gcc dot gnu.org
2023-06-10 1:25 ` jack.cui2 at foxmail dot com
2023-06-10 8:18 ` redi at gcc dot gnu.org
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).