Hi, I'd like to know if there's plans to merge Pedro Lamarão's
implementation of delegating constructors into trunk. While we're at it,
is there someone implementing C++0x's inheriting constructors?
Regards,
Rodolfo Lima
Jonathan Wakely wrote:
> Thanks. There's no need to post it to this mailing list too, bugzilla
> changes already go to the gcc-bugs mailing list where people can track
> new bug reports.
Oh, sorry ;)
[]s,
rod
Hello, I've posted a message to comp.gcc.help with a compiler error I'm
having but after some testing me and others found out is a regression on
gcc-4.5, the code is the following:
// ---
template
struct identity
{
typedef T type;
};
template
struct foo {};
Tom Tromey wrote:
> AFAIK the patch is still waiting for a review. I don't know what the
> hangup is. Perhaps it needs more frequent pings.
So, whoever is responsible for this, please step forward :) I'll test
the patch when I get home, but I have no knowledge of gcc's internals to
make a thorou
Andrew Pinski escreveu:
This is not the correct mailing list for this really, please use
gcc-help@ or in this case a C++ language list.
Oh sorry, it won't happen again.
Because of an ambiguous in the C++ syntax, the C++ standard decided
that this will be a function named a returning the type
Hi, I'd like to know why this rather simple code doesn't compile on gcc
(from 4.2 to 4.3, haven't tested on earlier compilers):
struct data {};
class test
{
public:
test(data) {}
int member;
};
int main()
{
test a(data());
a.member = 3;
}
The error output is:
error: request f
Dave Korn escreveu:
> Thanks, and do drop a note back with a summary of what you find out
over
> there when you're done; if there's definitely a bug in gcc's
understanding of
> the resolution rules, obviously we'd like to open a PR and get it fixed.
I think we have finally a consensus at
ht
Dave Korn escreveu:
Thanks, and do drop a note back with a summary of what you find out over
there when you're done; if there's definitely a bug in gcc's understanding of
the resolution rules, obviously we'd like to open a PR and get it fixed.
I think we have finally a consensus at
http://gr
Guys, why don't you take this to comp.std.c++ to get an authoritative
answer? That's where you'll find the greatest concentration of people who
really know what the standard /actually means/ by what it says...
Alright, thread moved to comp.lang.c++.moderated, subject "Overload
resolution wit
Ling-hua Tseng escreveu:
Obviously, {1, 2, 4, 5, 6, 7} are not matched.
Maybe you think that the item 3 is matched.
Unfortunately, it stands for the non-template functions.
Are you sure that it doesn't include template functions? Because I think
it makes sense to consider them too (as Visual S
Ling-hua Tseng escreveu:
Since the sub-expression `&print' is not a call expression,
the overload resolution mechanism will not select the non-template version
first.
&print is not a call expression the same way &print<5> isn't, but the
latter is resolved correctly.
And the function templa
Hi, the code below doesn't compile with gcc-4.2, with the following error:
test.cpp: In function ‘int main()’:
test.cpp:19: error: no matching function for call to ‘call(overloaded function type>)’
It compiles and runs fine with Visual Studio 2005. I think the compiler
should see that if I'm c
12 matches
Mail list logo
