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 #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.gnu.org
: 4.5.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=39653
--- 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
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 dot com
http
: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39639
--- 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
--- 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 types
--- 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 seen x.y when y
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 #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
--- 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=17300action=view)
Unified money_get and num_get test case and results.
Attached is a unified test case with test results on popular
--- 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 comment #7
--- 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=17301action=view)
Corrected unified demo.
Attached a corrected unified demo with assertions removed and with output on
popular
--- 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 behavior
--- 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
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
on const char format string
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 dot com
http://gcc.gnu.org
--- 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=17044action=view) [edit]
As others have mentioned, the codecvt facet in your test case is broken
--- 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. Should
--- 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 other public
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=38677
at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
: 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
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
: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126
: 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=37404
: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
--- 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
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
--- 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, and when
--- 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
at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37062
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
-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://gcc.gnu.org/bugzilla
--- 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 extern int i;
2
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 ; } };
--
http
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 #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_constructorT::type. Simply
rearranging code or even compiling multiple
--- 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
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36871
--- 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 cassert
#include type_traits
struct F
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 roguewave dot com
--- 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 cassert
struct S {
S (const S) throw ();
S (int) throw (int);
};
int main ()
{
assert (__has_nothrow_copy
--- 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 #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_empty instead?
As a data
--- 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
of these helpers to facilitate
--- 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 both
: 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=36813
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
: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
--- Comment #1 from sebor at roguewave dot com 2008-07-10 23:04 ---
I should have mentioned: the same problem exists with stdarg.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
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
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 int N
struct A { struct S { short f[3]; } __attribute__ ((aligned ((N; };
int main ()
{
A123::S s;
}
--
sebor at roguewave dot com changed
)))
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=36625
--- 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::transform(s[0], s[0] + 5, s[0
--- 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 this using the preprocessor
alone
--- 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. throw checks to see if a user
: 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 #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.
So again
--- 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.8.1, p2
--- 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
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 libc
(e.g.,
via
--- 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 described
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
--- 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., '\0'. IMO
--- 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 in any
--- 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 #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's questionable
--- 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 to show how
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=34449
--- 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 -0600
--- 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
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
--- 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 |Added
--- 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 likely. sizeof(int
--- 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 #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 #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=13212action=view)
test case for data member reordering
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- 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
space waste
Product: gcc
Version: 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
--- 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
__attribute__((reorder
--- 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?
--
http
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 argument
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
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 roguewave
--- 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, aren't
--- 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
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
GCC host triplet: sparc-sun-solaris
GCC target triplet: sparc
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 X1::X2::X3::X4::f();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539
array
Product: gcc
Version: 4.1.0
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
--- Comment #4 from sebor at roguewave dot com 2007-01-09 22:34 ---
(In reply to comment #3)
The standard refers to (l+n)%size(), so if size()=0, that seems to be
undefined. On the other hand, it seems fairly obvious what should happen in
this case (ie nothing).
The requirement
1 - 100 of 180 matches
Mail list logo
