Re: Deprecation of -I- and -iquote
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 thorough check. The message gcc output, saying that -iquote should be used instead of -I- is just plain wrong. Seeing that 4.5.0 release is just around the corner, is it feasible to have this patch committed into 4.5 branch? Best regards, Rodolfo Lima
[4.5 Regression] class partial specialization error
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 {};
template
struct foo, A> {};
int main()
{
foo,0> bar; // error here
}
// --
gcc fails with:
teste.cpp:18:23: error: aggregate ‘foo, 0> bar’ has
incomplete type and cannot be defined
If I comment out the partial specialization, it compiles.
I've created ticket #44753 to track this issue.
Regards,
rod
Re: [4.5 Regression] class partial specialization error
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
Delegating constructors patch
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
Problem with object initialization
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 for member ‘member’ in ‘a’, which is of non-class type
‘test ()(data (*)())’
Now... why the compiler assumed that I'm defining a function returning
'test' and accepting a pointer to a function returning 'data'? If I
wanted this, I'd write: test a(data(*)()), isn't it? What's the catch?
Regards,
Rodolfo Lima.
Re: Problem with object initialization
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 test and taking an argument of the type data. Thanks for the explanation. I'll look for this info in the standard to have a better grasp of what's involved here. Regards, Rodolfo Lima.
Overload resolution compilation error
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 calling the non-templated 'print' function and
there's no other non-templated 'print' overload, it should use
'void print()', with no ambiguity.
As I don't have a copy of the standard at hand, who's to blame not to be
standard compliant? g++ or Visual Studio?
#include
using namespace std;
void print() { cout << "null" << endl; }
template void print() { cout << i << endl; }
template void print() { cout << i << ' ' << j endl; }
template void call(F f)
{
f();
}
int main()
{
// proper way (according to g++) to call non-templated print
// call(static_cast(&print));
call(&print);
call(&print<5>);
call(&print<7,6>);
return 0;
}
The correct output should be:
null
5
7 6
Thanks for your help,
Rodolfo Lima.
Re: Overload resolution compilation error
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 templates can be instantiated without <>,
so the C++ compiler is confused.
I cannot see how a template function can be instantiated without <>,
since its instantiation needs the template parameters. That's why I
think that the compiler shouldn't even consider this situation in
overload resolution. With this said, in your exemple the only overload
for '&foo' should be 'void foo()'.
==
void foo() { }
template void foo() { }
int main()
{
&foo;
}
==
It can help you to understand what's happend.
Yes, thank you, your example is much more concise.
Thanks,
Rodolfo Lima.
Re: Overload resolution compilation error
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 Studio does). The point
is that non template functions arguments have higher priority than
template functions (as specified in paragraph 4), and IMO there's no
reason to differentiate between template and non-template functions'
argument target, making the latter work and the former not.
Regards,
Rodolfo Lima.
Re: Overload resolution compilation error
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 with template and non-template functions", and it's waiting for moderator approval. Regards, Rodolfo Lima.
Re: Overload resolution compilation error
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://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/52087a72bdc5de5a
Since the template parameter of the template function cannot be deduced,
the only valid function for taking its address is the non-template one,
so g++ should accept the code without error nor ambiguity.
During this week I've come along with another possibly related error:
template void foo(A0, A1) {}
void bar()
{
&foo;
}
g++ signals an error, saying:
teste.cpp: In function ‘void bar()’:
teste.cpp:4: error: statement cannot resolve address of overloaded function
I'm trying to get the address of a correctly specialized template
function, but g++ cannot resolve it. And there's no overload situation
there, just void foo(int, char) is being involved. I've not
tested it with other compilers, but this bug is less subtle then the
first one.
Address of template function bug (was: Overload resolution compilation error)
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://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/52087a72bdc5de5a
Since the template parameter of the template function cannot be deduced,
the only valid function for taking its address is the non-template one,
so g++ should accept the code without error nor ambiguity.
During this week I've come along with another possibly related error:
template void foo(A0, A1) {}
void bar()
{
&foo;
}
g++ signals an error, saying:
teste.cpp: In function ‘void bar()’:
teste.cpp:4: error: statement cannot resolve address of overloaded function
I'm trying to get the address of a correctly specialized template
function, but g++ cannot resolve it. And there's no overload situation
there, just void foo(int, char) is being involved. I've not
tested it with other compilers, but this bug is less subtle then the
first one.
