[Bug c++/57746] rejected valid specialization of member function of class template (I think)

["daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
According to the standard in general a definition is also a declaration
([basic.def] p2 "A declaration is a definition unless it declares a function
without specifying the function’s body (8.4), [..]"), therefore [temp.explicit]
applies here as well. 

I think that GCC is incorrect in not rejecting both cases, because the wording
clearly includes a "static data member of a class template" (This error still
exists in gcc 4.9 trunk).

I also think that the meaning of the code is well-defined only for C++11,
because in C++03 the concept of an explicit instantiation declaration did not
exist.
>From gcc-bugs-return-425420-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 29 13:45:24 2013
Return-Path: <gcc-bugs-return-425420-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2832 invoked by alias); 29 Jun 2013 13:45:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2792 invoked by uid 48); 29 Jun 2013 13:45:21 -0000
From: "harald at gigawatt dot nl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/57714] Newline rendered incorrectly in output
Date: Sat, 29 Jun 2013 13:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: harald at gigawatt dot nl
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57714-4-TT99fRqWzY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57714-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01799.txt.bz2
Content-length: 1397

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW714

--- Comment #16 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to David Krauss from comment #14)
> 1. Actually the C standard does care whether whitespace is added.

You're right for stringizing, but GCC already takes care to treat that as a
special case.

#define ID(x) x
#define STR(x) STR_(x)
#define STR_(x) #x
STR(ID(1)ID(2))ID(3)ID(4)

preprocesses to

"12"3 4

No space is inserted between the 1 and 2, because the C standard does not allow
that. No space is inserted between "12" and 3, because no space was present in
the input and no space is required. A space is inserted between 3 and 4 because
the preprocessed output would be misinterpreted otherwise.

> 2. Whitespace does not need to be added to cause the visual formatting of the output to match the input. The trick is to output a backslash character in the output.

A trailing backslash at the end of a line after preprocessing is a syntax error
and is treated as such by GCC. What you suggest requires running the result
through the preprocessor again in order to be able to compile the result. Note
that

int main() {
  ret\
urn 0;
}

is perfectly valid, but

#define ID(x) x
int main() {
  ID(ret)ID(\)
urn 0;
}

is not. If these become undistinguishable after preprocessing, it is impossible
to diagnose the syntax error, and that diagnostic is required.