Re: g++ 4.0.0: ambiguous conversion resolved in favor of conversion operator?

This code is still accepted by gcc version 4.2.0 20060306 (experimental). icc 8.1 rejects it. Check gcc's bugzilla for existing PRs. Regards, Ryan Mansfield ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/h

Re: strange link problem

The problem is because static data members need to be defined exactly once in every translation unit. Please see http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.11 Regards, Ryan Mansfield ___ help-gplusplus mailing list help-gplusplus@gnu.org

Re: strange link problem

Yes, you're right. Thank you for correcting me. I meant to say was that they can only be defined exactly once. I need more coffee. Regards, Ryan Mansfield ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help

Re: Problem with logging macros, compiles fine with gcc 2.95.1, fails with 3.4.4

Sorry if I don't correctly understand your problem. Are you trying to do something like the following? #define x(y) (#y) int main() { char buf[100] = x(TemplateClass); printf("%s\n", buf); } If you're relying on old preproccesor behavior, you could try to -traditional-cpp. You should comp

Re: problem with compilation process in mingw port

Please read: http://gcc.gnu.org/ml/gcc/2006-01/msg00015.html Regards, Ryan Mansfield ___ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus

Re: About g++ optimization

Peng, The space between the ++ and i is fine. Some find ++i more readable, that is all. It is difficult to optimize away the repeated f(n) calls because f() could have side effects and there is no guarantee it will always return a constant. If f() always returns a constant, this could potentially

Re: About g++ optimization

If you're doing more powerful optimizations, such as IPA based, its likely you will be doing loop unrolling as well. And after loop unrolling, they should generate code identical code. > Saves usually a register and replaces a check against an 'arbitrary' > number with a check for zero (which is f

Re: About g++ optimization

> Funny. Last time I looked there was no cmpl in this case. That's because you are using predecrement in this example. It changes the test completely. With predecrement you only iterate the loop 4 times, and iterate 5 times with post decrement. Since it is postdecrement, it needs the compare the

Re: unique identifiers for guard macros

Why do you need unique guards? The reason why header guards are used is to prevent multiple inclusion of a file so the macros are based on the file name. For example, foo.h would have: #ifndef FOO_H #define FOO_H #endif Sorry if this isn't very helpful, but I don't see why you would need unique

Re: unique identifiers for guard macros

Ah, files with the same name -- sorry, I should of thought of that. To work around this problem, I'd probably just prefix the filename with the namespace or folder name. I can't think of an elegant solution. Maybe someone else has come up with a clever naming convention for header guards... Regar