Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39993
--- Comment #6 from sebor at roguewave dot com 2009-04-05 17:12 ---
See also bug 39642 and bug 39653.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39653
--- Comment #5 from sebor at roguewave dot com 2009-04-05 14:20 ---
(In reply to comment #4)
The change was introduced in N2622:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2622.pdf
I couldn't find a rationale for the change. Doug might remember
--
http://gcc.gn
--- Comment #3 from sebor at roguewave dot com 2009-04-04 23:12 ---
This limitation makes implementing the latest std::tuple difficult. Quoting
from a post to c++std-...@accu.org:
Martin Sebor wrote:
> To: C++ libraries mailing list
> Message c++std-lib-23549
>
> After
--- Comment #1 from sebor at roguewave dot com 2009-04-04 23:05 ---
FWIW, I just happened to run into the same error while doing some work on
std::tuple. IIUC, the error is due to bug 35722.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39642
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39639
E on ill-formed sizeof() in variadic
template
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave d
--- Comment #6 from sebor at roguewave dot com 2009-02-18 16:50 ---
(In reply to comment #5)
> Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their ty
--- Comment #4 from sebor at roguewave dot com 2009-02-17 21:00 ---
Thanks for looking into so quickly!
In addition to the missing warnings mentioned in the initial report I would
expect a warning for each of the references to e below (i.e., on lines 3, 9,
and 15), analogously to those
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
--- Comment #5 from sebor at roguewave dot com 2009-02-17 15:48 ---
(In reply to comment #0)
> I can't think of a scenario where one would want to write x.f() over X::f()
> when f() is static. I'd like a warning for this so I can catch with -Werror.
FWIW, I've
--- Comment #20 from sebor at roguewave dot com 2009-02-14 21:58 ---
Created an attachment (id=17301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17301&action=view)
Corrected unified demo.
Attached a corrected unified demo with assertions removed and with output on
--- Comment #18 from sebor at roguewave dot com 2009-02-14 21:41 ---
I was too hasty -- the attached test case is buggy: it's missing a seek to
the beginning of the stream after the first extraction, making the results
for the num_get part meaningless.
(In reply to comme
--- Comment #17 from sebor at roguewave dot com 2009-02-14 21:21 ---
Created an attachment (id=17300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17300&action=view)
Unified money_get and num_get test case and results.
Attached is a unified test case with test results on
--- Comment #1 from sebor at roguewave dot com 2009-02-12 17:02 ---
In addition, as the test case below shows, the warning is issued inconsistently
between classes and functions, suggesting that the instance of the warning on
the class declaration on line 2 might be a bug rather than a
--- Comment #4 from sebor at roguewave dot com 2009-02-12 16:49 ---
(In reply to comment #0)
I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
includes "123,456" This
igned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
-c t.cpp
4.3.1
t.cpp: In function 'void foo(size_t)':
t.cpp:7: warning: format '%lu' expects type 'long unsigned int', but argument 3
has type 'size_t'
$
--
Summary: missing -Wformat warning on const char format string
Product: gcc
--- Comment #12 from sebor at roguewave dot com 2009-01-09 16:57 ---
(In reply to comment #3)
> Created an attachment (id=17044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17044&action=view) [edit]
As others have mentioned, the codecvt facet in your test case is b
--- Comment #2 from sebor at roguewave dot com 2009-01-04 22:37 ---
Some additional background on the problem: it's likely that the gcc binary
used to reproduce the problem on Red Hat Enterprise Linux AS release 4 has
been configured and built on SUSE Linux Enterprise Server 10. S
std::streamsize main()xsgetn(char*, std::streamsize): Assertion `!"xsgetn should not be
called"' failed.
Aborted
--
Summary: istream::read() calls streambuf::xsgetn()
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: nor
struct S { T foo (); };
>>> template T S::foo () { return T (); };
>>> template struct S;
>>> extern template struct S;
>>> int main () { return S().foo (); }
--
Summary: extern template declaration accepted after explicit
instantiation
Pr
--- Comment #3 from sebor at roguewave dot com 2008-12-30 20:08 ---
Quoting [lib.istream], p2:
Both [formatted and unformatted] input functions are described as if
they obtain (or extract) input characters by calling rdbuf()->sbumpc()
or rdbuf()->sgetc(). They may use
: inefficient code on trivial try/catch statement
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave
t: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126
t: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
FIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37404
--- Comment #2 from sebor at roguewave dot com 2008-08-27 16:48 ---
Is this by any chance related to bug 24511?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37256
--- Comment #4 from sebor at roguewave dot com 2008-08-10 02:23 ---
My gcc is yesterday's build:
gcc version 4.4.0 20080808 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37070
--- Comment #2 from sebor at roguewave dot com 2008-08-09 22:51 ---
I'm not sure what you're trying to say but it sure looks like a bug to me.
How else is one supposed to throw an exception without triggering this
warning?
Btw., the argument of a throw expression can throw, a
warning on throw statement
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.
--- Comment #1 from sebor at roguewave dot com 2008-08-08 19:47 ---
Similarly, functions declared with the const attribute such as f1() in the
test case below that violate the compiler's assumptions should be diagnosed:
$ cat -n t.C && g++ -c -O2 -Wall -W t.C
1
pure function with side-effects
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gc
rity: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37063
signedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37062
uct: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36910
--- Comment #2 from sebor at roguewave dot com 2008-07-21 16:17 ---
I agree a new warning would be useful. For example, the following code should
be diagnosed:
struct S { S () throw () { throw 0; } };
as should this:
struct S { S () throw (int) { throw ""; } };
--- Comment #1 from sebor at roguewave dot com 2008-07-19 00:53 ---
Or any other throwing ctor, for that matter:
$ cat u.cpp && g++ u.cpp -std=c++0x && ./a.out
#include
struct S {
S (const S&) throw ();
S (int) throw (int);
};
int main ()
{
assert
lse for T with a throwing vararg
ctor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at
--- Comment #1 from sebor at roguewave dot com 2008-07-19 00:44 ---
This also fails. Seems that the combination of a copy ctor and template ctor
(even non-throwing) trips the compiler up.
$ cat u.cpp && g++ u.cpp -std=c++0x && ./a.out
#include
#include
struct F
To: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36871
--- Comment #7 from sebor at roguewave dot com 2008-07-18 22:11 ---
FYI: I discussed the wording briefly with Daveed (eccp returns true if and
only if the class has a trivial ctor or the ctor has a throw() spec on it,
for just this reason). We agree that the wording is unclear and
--- Comment #5 from sebor at roguewave dot com 2008-07-18 21:47 ---
(In reply to comment #4)
The ODR is important from an ABI standpoint -- imagine a function template
that uses SFINAE and std::has_nothrow_default_constructor::type. Simply
rearranging code or even compiling multiple
oduct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36870
--- Comment #4 from sebor at roguewave dot com 2008-07-16 19:26 ---
We're using -std=gnu++0x, so we're expecting the implementation to follow
C++ 0x rules.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
--- Comment #10 from sebor at roguewave dot com 2008-07-14 18:43 ---
(In reply to comment #9)
I'd be happy to provide whatever info you need (e.g., the table of built-ins,
if you can explain to me how to get it from the front-end :)
As for the semantics of the built-ins, I assume
--- Comment #8 from sebor at roguewave dot com 2008-07-14 15:41 ---
(In reply to comment #7)
> Subject: Re: ICE on SFINAE and __is_empty
>
> sebor at roguewave dot com wrote:
>
> > My preference would be for gcc to avoid imposing restrictions on the use
>
--- Comment #6 from sebor at roguewave dot com 2008-07-14 15:24 ---
(In reply to comment #4)
> ... Is it a reasonable
> restriction on users to say "thou shalt not use __is_empty in an expression
> that gets mangled"? For example, can the user just use std::is_e
deducing template argument taking the address of
rvalue reference template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36816
riority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36813
--- Comment #1 from sebor at roguewave dot com 2008-07-10 23:04 ---
I should have mentioned: the same problem exists with .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
onent: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
n SFINAE and __is_empty
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
e function
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36707
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36656
--- Comment #3 from sebor at roguewave dot com 2008-06-26 20:46 ---
Oddly enough, doubling up on the parens around N works:
template
struct A { struct S { short f[3]; } __attribute__ ((aligned ((N; };
int main ()
{
A<123>::S s;
}
--
sebor at roguewave dot com c
id
__attribute__((aligned(N)))
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot co
--- Comment #11 from sebor at roguewave dot com 2008-06-03 19:16 ---
(In reply to comment #10)
[...]
> Quick fix from the PDF (in case it goes away again):
> Provide a manual cast for toupper to explicitly declare "which toupper" we
> mean.
>
> std::transfo
--- Comment #48 from sebor at roguewave dot com 2008-06-03 00:07 ---
FWIW, let me throw out a suggestion for an implementation of Benjamin's (2)
in the C++ front end:
1. "try" is a no-op
2. "catch" blocks are syntax-checked but eliminated as dead code
3. "
--- Comment #47 from sebor at roguewave dot com 2008-06-02 23:08 ---
(In reply to comment #46)
[...]
> 2) -ftransform-exceptions
should catch(X) expand into "else if (false)" rather than just "if (false)?"
That said, I don't think there is a way to do
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
--- Comment #7 from sebor at roguewave dot com 2008-02-13 18:15 ---
I see I should have checked the actual stdio behavior instead of relying on
the standard. Recent Linux and Solaris both do, in fact, generate SIGXFSZ out
of C stdio. AIX 5.3 does not, and neither does HP-UX 11.23
--- Comment #5 from sebor at roguewave dot com 2008-02-13 16:37 ---
I understand that POSIX requires the signal but I'm not sure I see what that
has to do with filebuf. C++ specifies that filebuf member functions behave
"as if" by calling the C stdio functions.
See 27
--- Comment #3 from sebor at roguewave dot com 2008-02-13 15:46 ---
I used setrlimit() only to emulate low disk space conditions. The same
"problem"
occurs in a pure C++ program (i.e., one that makes no POSIX or other non-C++
calls) when it really does run out of disk space.
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
--- Comment #14 from sebor at roguewave dot com 2008-01-12 22:45 ---
bg_BG is the only known example on Linux.
The original bug report we got was for a fr_FR locale on Tru64. I haven't
gone through other locales on Tru64 or any other platforms except for Linux
to see how pervasive
--- Comment #12 from sebor at roguewave dot com 2008-01-11 15:59 ---
(In reply to comment #11)
[...]
> So while I agree that "NUL thousands_sep means no grouping" to stdio and to
> iostreams in C++,
I should clarify that in C++ it means that only if the NUL comes from
--- Comment #11 from sebor at roguewave dot com 2008-01-11 15:56 ---
I think the disconnect might be in how each of us is looking at the LC_NUMERIC
data. To me, it's just a bunch of values that are independent of one another.
You, OTOH, seem to view it more as a set of rules desc
--- Comment #9 from sebor at roguewave dot com 2008-01-11 05:44 ---
I don't agree that localeconv()->grouping is garbage just because thousands_sep
is NUL. I'm not aware of anything in C or POSIX that says that. In the case of
bg_BG, the grouping is clearly correct. What&#
--- Comment #7 from sebor at roguewave dot com 2008-01-11 03:37 ---
But that's just the libstdc++ interpretation of grouping and thousands_sep (no
offense). The C library paints a different picture.
If I want to write my own formatter/parser for numbers in the Bulgarian locale
--- Comment #5 from sebor at roguewave dot com 2008-01-11 03:09 ---
It's irrelevant to the implementation but it could be relevant to user-defined
formatting (or parsing) code that bypasses num_put (or num_get) but uses
numpunct to get the expected formats.
IMO, the improvement i
--- Comment #2 from sebor at roguewave dot com 2008-01-11 02:09 ---
Right, in C it does mean that (because thousands_sep is a multibyte string, and
so the value is really ""). The problem is that in C++ a NUL thousands_sep is a
perfectly valid single-byte character, i.e.,
ot; = = " 003 003 " \n
034
--
Summary: numpunct::grouping() doesn't match libc value for
Bulgarian (bg_BG) locale
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
--- Comment #5 from sebor at roguewave dot com 2007-12-14 19:35 ---
(In reply to comment #3)
That's an interesting interpretation. I agree it's possible although I suspect
it was not intended. IMO, the _byname facets are really an implementation
detail that was exposed just t
--- Comment #1 from sebor at roguewave dot com 2007-12-13 05:41 ---
FWIW, it looks like you need a dynamic_cast in use_facet (it's not enough to
check the id and then downcast using static_cast). Something like this:
--- locale_facets.tcc 2007-10-21 08:33:43.0
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-
--- Comment #2 from sebor at roguewave dot com 2007-11-08 18:52 ---
Yes, I can confirm that, Paolo. The Apache C++ Standard Library behaves the
same (i.e., the facet sets eofbit).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34031
ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34024
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33786
--- Comment #2 from sebor at roguewave dot com 2007-09-12 03:56 ---
(In reply to comment #1)
> This is not a bug, 0 will be pasted as the same size as an int which means it
> will most likely not be passed as the same size as a NULL pointer.
I don't know about "most lik
--- Comment #3 from sebor at roguewave dot com 2007-09-12 03:47 ---
You remember correctly :)
To avoid zeroing it out use 'new buffer' w/o the parentheses.
--
sebor at roguewave dot com changed:
What|Removed
--- Comment #5 from sebor at roguewave dot com 2007-08-05 00:31 ---
There are third party tools that track these types of problems. Some of them
have started to make their way into compilers. For example, the HP static
analysis tool called Code Adviser is integrated into the HP aCC
--- Comment #7 from sebor at roguewave dot com 2007-07-15 00:03 ---
In cases when the compiler can figure out that the cast is unnecessary it would
be even better if it would optimize it away than to complain to the user about
not being able to do it.
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 ---
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over
--- Comment #7 from sebor at roguewave dot com 2007-03-15 19:55 ---
Created an attachment (id=13212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212&action=view)
test case for data member reordering
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #6 from sebor at roguewave dot com 2007-03-15 19:54 ---
(In reply to comment #5)
I've checked all three but none of them seems to achieve an optimal layout in a
modified template case. Let me attach my test program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #4 from sebor at roguewave dot com 2007-03-14 19:05 ---
(In reply to comment #2)
> Note actually some compilers actually do this even without an attribute. This
> is related to the art hack.
Out of curiosity, which compiler does it? And what's the art hack?
--- Comment #3 from sebor at roguewave dot com 2007-03-14 19:04 ---
(In reply to comment #1)
> Interesting. Do the attributes apply to derived classes automatically?
I would say no.
>
[...]
> Is D also allowed to reorder members a and b? even with an explicit
> _
ion: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
--- Comment #6 from sebor at roguewave dot com 2007-03-09 18:25 ---
(In reply to comment #5)
Good point! I hadn't thought of that. Since that option is out and __FUNCTION__
should simply behave identically to __func__ and be disallowed in global or
namespace scope function arg
--- Comment #4 from sebor at roguewave dot com 2007-02-15 23:06 ---
The wording proposed in N1970 for the C++ __func__ indentifier reads:
-1- The identifier __func__ shall be implicitly declared by the translator
as if, immediately following the opening brace of each function
--- Comment #2 from sebor at roguewave dot com 2007-02-15 21:29 ---
No, I'm not aware of any such paper. AFAIK, neither __FUNCTION__ nor
__PRETTY_FUNCTION__ is specified by either C or C++, or proposed for inclusion
either of them (I could be wrong). They're gcc extensions, a
exception specification in
__PRETTY_FUNCTION__
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at
ct: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
n, max, et al
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris
GC
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561
--- Comment #1 from sebor at roguewave dot com 2007-01-22 16:25 ---
Even better, this works too:
template <> void X<1>::X<2>::X<3>::X<4>::f();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539
1 - 100 of 182 matches
Mail list logo
