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
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 class T
struct identity
{
typedef T type;
};
template class T,
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
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
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
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
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
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
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
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
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(unresolved
overloaded function type)’
It compiles and runs fine with Visual Studio 2005. I think the compiler
should see
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 print5 isn't, but the
latter is resolved correctly.
And the function templates
12 matches
Mail list logo
