I think I may have hit a bug where an implicit copy constructor can't
construct an array of a subtype with a user-defined copy constructor.
I can't see any hits searching for "invalid array assignment" on the
bug repository.
I messed up submitting my last bug so I thought I'd ask here first for
con
Axel Quote:
"Anyways there is an already filed GCC bug about this defect report
against the standard,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 ."
That bug report is suspended. Is this due to the C++ standards issue
you referred to?:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.h
Re Axel:
Quote (Axel):
"Well, I think g++ behaves correctly. As I understand the standard,
the normal function foo(int) can't be used in the template "bar",
because it is only declared afterwards."
Me:
I don't think this can be correct. Removing the template foo() but
leaving the normal one also
http://www.gamedev.net/community/forums/topic.asp?topic_id=559287
SOURCE
template
void foo(pTYPE arg)
{ arg.nid(); }
template
void bar()
{
pTYPE var;
foo(var);
}
void foo(int)
{}
int main()
{
int i;
foo(i); // OK: Resolves foo(int
g++ doesn't seem able to match a template ctor of a template class
where the ctor input is an internal class defined inside any template
class.
I briefly skimmed the titles of the current regression issues and I
didn't notice any that matched this, but I'm not 100% sure.
I first posted this here
I recently (on 18/12/2008) mailed a GCC patch to this mailing list,
but I went on holiday after and have only just arrived back. I
probably should have asked for some feedback then.
The patch is for the C++ component of GCC. It adds some compiler
warning options. The primary usage of these options
: Restrictive Exception Specification.
An extension to G++, the C++ compiler from GCC.
By Simon Hill.
Under the same license as GCC.
CONTENTS
Overview
RES Principles
Usage Tips
Whitelisting
XES
TT
CNR
MES
Implementation
Comparison with EDoc++
C++ extensions to aid RES
Design Flaws
Extract and rename as res.diff - It seems gmail wants to attach diff
files as text instead of attachments.
res.diff.tar.gz
Description: GNU Zip compressed data
Sorry I pressed enter accidentally on gmail and send with no title.
I'm curious as to why I didn't get any responses to my last posts here
on 29 / 11 / 2008.
http://gcc.gnu.org/ml/gcc/2008-11/
Is it that there's just no interest in my additions here?
Or that there's so few people here or that they're dedicated to their
own projects?
Or did I somehow not get sent o
It took me quite some time to figure out how to browse the different
types of trees that I am interested in.
There are still many types and components that I will need later to
finish my restrictive exception specification warning mechanic.
I've tried dumping trees but the format of the dumps isn'
I have recently been able to put in a few hours toward my restrictive
exception specification warning mechanic.
I have it warning me correctly on very basic regular code with throw,
try/catch, function calls and exception specifications.
It's also activated by -Wres (restrictive exception specifica
I've been planning to add a warning to GCC for a while.
I've recently begun learning the GCC internals and trying to add some code.
So far I have made very little progress.
All I have working is a warning parameter that, when enabled, emits a
warning whenever a function is declared. It's not look
I've been reading up on GCC internals so that I can begin my project.
Initial proposal: http://gcc.gnu.org/ml/gcc/2008-09/msg00383.html
(with many follow-ups).
My idea of implementing so far is: Alter the code in gcc/cp/parser.c
so that I can check strict exception specification during parsing,
si
Jonathan Wakely said:
> Simon Hill wrote:
> > Brain Dessent wrote:
> >> You're essentially trusting that all
> >> exception specifiers for every function in the program and *all* library
> >> code are always present and always correct which is a huge
Brendon Costa wrote:
> You as an author of a new template class "could" define it the other way.
>
> The issue here is that doing so restricts usage of the generic
> component. In specific cases this may be desirable, but not for generic
> components like STL containers or those in boost. For gener
Brendon Costa said:
> The author of the template class or container can't know
> what types of exceptions will be thrown from them, so you must define
> them as being able to throw all exceptions (which is how they are
> currently).
Ouch, you have a point. But couldn't you put this round the other
Thanks for all the links. I knew there were people wanting this but I
didn't quite get how big an issue it was.
Brain Dessent wrote:
> You're essentially trusting that all
> exception specifiers for every function in the program and *all* library
> code are always present and always correct which
I have been following the development of C++0x and ConceptGCC and it
has got me interested in developing for G++.
I've haven't yet dived far into the G++ code, but I have just been
reading the GCC internals documentation at
http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
horrified
Sorry Paolo, that definitely should have been.
=== THIS CODE FAILS TO LINK ===
template
class foo {
public:
foo() =default; // <<--- this works fine.
~foo();
};
template
foo::~foo() =default; <<--- ERROR: This doesn't get built by the compiler.
// foo::~foo() {}; <<-- replacing with t
I've just installed g++ 4.4 and I'm playing with some of the c++0x features.
The below page describes the =default and =delete syntax. (Used to
manipulate the special member functions default/copy constructor,
destructor and copy assign).
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n23
21 matches
Mail list logo
