Deprecation of -I- and -iquote
I wonder what's the current state of -I- vs. -iquote, is there anyone interested in fixing the fact that -iquote doesn't replace -I- functionality, needed for out-of-source precompiled header utilization? The relevant bug is 19541 - need another option to support what -I- did just besides -iquote, and there's a patch floating around that adds -ignore-source-dir flag (http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00653.html). What else is needed move this forward? Regards, Rodolfo Lima
C++0x Concepts development schedule
Hi, I wonder if there's any kind schedule available on the development Concepts proposal into GCC. I know there's a related branch in svn, but it seems stale as of 11/2008. Please don't take this as a pressure to get things going. I just want to know the time frame it will be ready, I'm sort of excited because of the possibilities it unleashes. I'd really like to help on this task, but I never worked on GCC internals, and helping implement concepts for it isn't the best or more efficient way to start :) Best regards and thanks for the awesome compiler you guys put out, Rodolfo Lima
Re: C++0x Concepts development schedule
Hi, Manuel López-Ibáñez escreveu: > It won't be ready for GCC 4.4 for sure. So I wouldn't expect it in any > released GCC in less than one year. I wasn't expecting it for 4.4 neither. Maybe 4.5 (unlikely) or 4.6 (likely). > "At present, the concepts branch provides almost no support for > concepts. We are in the process of migrating code from the prototype > ConceptGCC." I think I'll dive in, seems like a good challenge. First I must get acquainted with the code and how things work. Given the amount of free time I have, I'll need a month to do that. When the time to get the hands dirty arrives, I'll need to know if somebody's working off-branch on some parts to avoid unnecessary work. I also know that ConceptGCC's implementation isn't the best, so it'll be good to know which parts of it are in good shape and which must be rethought and reimplemented. Regards, Rodolfo Lima
C++0x unrestricted unions
Hi, I'd like to know if somebody is implementing c++0x's unrestricted unions (N2544) in g++, or if there are any plans to do it in mid-term. Thanks, Rodolfo Lima
Re: C++0x unrestricted unions
Rodolfo Lima escreveu: > Hi, I'd like to know if somebody is implementing c++0x's unrestricted > unions (N2544) in g++, or if there are any plans to do it in mid-term. Sorry, by 'in mid-term' I meant "in a not too distant timeframe". []s, rod
Re: Delegating constructors patch
Em 06-07-2010 07:46, Paolo Carlini escreveu: > That work is incomplete, cannot be merged as-is: Thanks for pointing it out for me, Paolo. []s, rod
out of source builds and precompiled headers
I'm just pinging bug #19541 which, despite having patches with several solutions, isn't assigned to anybody. It's a 8 years old bug... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541 Here's the note I added there, FYI: How difficult is it to add a parameter to add paths to precompiled header search list *only*? We have a big code base with #include "pch.h" in some source files. If source file directory is always searched first for headers, this breaks out-of-source builds, unless the precompiled header is generated in the source tree. For read-only source trees, this "solution" is unacceptable. The ideal solution would be a parameter like -ipch that adds to be searched for precompiled headers *before* the current source directory. I could spend some time creating a patch, but seeing that others have come with patches that weren't applied, this kind of demotivate me. Best regards, Rodolfo Lima
-Winvalid-pch semantics
Hi, I'd like to know if the current behaviour of -Winvalid-pch is the intended one, mainly because gcc prints the message saying that the pch is invalid even if later it finds a valid one. Suppose that one project builds the pch for several build types (debug, release...) in the same directory. In the first build, say Debug, only one pch is there and there's no warning. But if later you build the Release version, the old pch will be there and will firstly be picked, the warning will be shown, and then the correct pch (release) will be used. Things get worse if you use the -Werror directive. IMHO the real use of -Winvalid-pch is to trap cases where *any* pch is used, thus slowing the compilation process. If one valid pch is found, I think it's a good case, and don't deserve a warning (or an error with -Werror). I've seen people that giving up -Winvalid-pch to get rid of those spurious warnings in detriment of not knowing whether the pch was used or not. Regards, Rodolfo Lima.
Fix C++0x regressions for gcc-4.3
Hi, I'd like to know if C++0x regressions are being addressed for gcc-4.3 release. I'm saying that because of bug "Compiling error with variadic template with fixed parameter with default type." (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35297) is rather annoying for those who are already using C++0x new features. Regards, Rodolfo Lima.
Re: Fix C++0x regressions for gcc-4.3
Joe Buck escreveu: > There is no such thing as a "C++0x regression", since (very limited and > experimental) C++0x support is brand new in 4.3, and 4.3.0 hasn't been > released yet. A regression is something that worked correctly in a > previously released version of GCC, but that doesn't work now. Thanks for your explanation (and Andrew's in a private message). I was looking for this info in a FAQ but couldn't find it. Regards, Rodolfo Lima.
Re: Overload resolution compilation error
> The function template `std::make_pair<>()' is an example.
> You can directly call it without <>.
> Since &print is not a call expression, C++ compilers cannot determine it
> by
> function arguments.
You're right, I forgot that rather trivial example. But what I'm trying to
achieve is the correct resolution when we don't have the function's
parameters, as when we get the address of the function. Right now I have the
c++ standard here, and in section 13.1 (over.over, or "Address of overloaded
function"), the paragraph 4 says:
"If more than one function is selected, any function template
specializations in the set are eliminated if the
set also contains a non-template function, and any given function template
specialization F1 is eliminated if
the set contains a second function template specialization whose function
template is more specialized than
the function template of F1 according to the partial ordering rules of
14.5.5.2. After such eliminations, if
any, there shall remain exactly one selected function."
If I understand this correctly, when we have the following declarations:
template void foo() {}
void foo() {}
The overload set for "&foo" at first contains all "void foo()" and "void
foo()". Then, because of the presence of the latter, the former should be
eliminated. In the end, only "void foo()" remains, and we have no ambiguity.
> This problem can be also reduced to this one:
> ==
> void foo() { }
> void foo(int) { }
>
> int main()
> {
>&foo;
> }
> ==
This is different because there's no function template involved.
Regards,
Rodolfo Lima.
Re: Overload resolution compilation error
"Ling-hua Tseng" <[EMAIL PROTECTED]> escreveu na mensagem
> What is the `target' in your program?
> The answer is NOTHING.
> So the set of overloaded functions is empty at beginning.
In my first example, the target type is the type of the address expression,
i.e., the type of the source. I'll repeat it here:
template void bar(F f) {}
template void foo(T v) {}
void foo(int v) {}
...
bar(&foo);
According to the paragraph 2 of section 13.4, (and against of what I've said
in my previous post), if there's a template function involved, the compiler
tries to deduct the template arguments from the target type. If it succeeds,
this specialization is added to the overload set. In my example, the
compiler cannot deduct the template argument, so the template function
doesn't get added to the overload set. Only the non-template function is
added. Being the only function in the set, there's no ambiguity and the
address of "void foo()" should be passed to "bar".
Best regards,
Rodolfo Lima.
Re: Address of template function bug (was: Overload resolution compilation error)
Rodolfo Schulz de Lima escreveu: > 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 Hi, I'd like some feedback on this thread because if it's really a bug, I'd fill a bug report. Thanks, Rodolfo Lima.
