public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/53248] std::array<T,0> doesn't work when T is not default-constructible
Date: Sun, 06 May 2012 11:41:00 -0000 [thread overview]
Message-ID: <bug-53248-4-Etubasjme8@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-53248-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248
--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-05-06 11:21:47 UTC ---
(In reply to comment #2)
> Daniel, can you see other options besides adding a specialization? (which would
> be a straightforward task, I may even get around to do pretty soon when I will
> do debug-mode std::array, already in my todo list)
I haven't implemented it completely, but an alternative to a partial
specialization could be something like the following:
template <class T, size_t N>
struct __array_data_traits
{
typedef T type[N];
};
template <class T>
struct __array_data_traits<T, 0>
{
struct type {};
};
template <class T, size_t N>
struct array
{
typename __array_data_traits<T, N>::type elems;
};
array<int, 1> ai1 = {1};
array<int, 1> ai1b = {};
array<int, 0> ai0 = {};
The sole (?) disadvantage of this approach would be that
std::is_empty<array<int, 0>> does not evaluate to true. But all the
specialization-relevant logic could also be added to __array_data_traits in
terms of static (constexpr where possible) functions.
Technically the traits-based approach would be preferable, because otherwise I
see the risk that user-code that itself would try to specialize std::array with
some T for a user-provided type could notice the difference. Consider:
// Within Library:
template <class T, size_t N>
struct array
{
T elems[N];
};
template <class T>
struct array<T, 0>
{
};
// User world:
struct User {};
template <size_t N>
struct array<User, N>
{
User elems[N > 0 ? N : 1];
};
array<User, 0> au0 = {}; // Error, ambiguous
The problem with the current library wording is that it does not *explicitly*
allow a *specialization* for std::array (in contrast to vector<bool> or to
numeric_limits for cv-variations of the actual type), therefore I believe that
from the current wording state a partial-specialization by the library is
borderline to invalid, at least a gray zone, because of the need to support
[namespace.std] p1.
If a library issue should be submitted, I would suggest to provide the library
the freedom for providing a special for the zero-size case.
next prev parent reply other threads:[~2012-05-06 11:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-05 20:14 [Bug libstdc++/53248] New: " dwalker07 at yahoo dot com
2012-05-05 21:59 ` [Bug libstdc++/53248] " daniel.kruegler at googlemail dot com
2012-05-05 23:57 ` paolo.carlini at oracle dot com
2012-05-06 11:41 ` daniel.kruegler at googlemail dot com [this message]
2012-05-06 15:42 ` paolo.carlini at oracle dot com
2012-05-06 18:56 ` paolo.carlini at oracle dot com
2012-05-06 19:19 ` daniel.kruegler at googlemail dot com
2012-05-06 19:56 ` paolo.carlini at oracle dot com
2012-10-01 23:44 ` paolo.carlini at oracle dot com
2012-10-04 0:02 ` paolo at gcc dot gnu.org
2012-10-04 0:03 ` paolo.carlini at oracle dot com
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=bug-53248-4-Etubasjme8@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@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).