[solved] gcc 4.4 support
Moderator: PPS-Leaders
[solved] gcc 4.4 support
Recently we found a "bug" in the Orxonox Core having the effect, that we cannot compile Orxonox with GCC 4.4. Since this part of Orxonox is not necessarily my expertize, I hope x3n can give a better insight into the problem.
I've just read, that the standard compiler of Ubuntu 9.10 will be GCC 4.4. Other systems with more up to date repositories use GCC 4.4 already. From my point of view we have until October this year to fix that problem.
I've just read, that the standard compiler of Ubuntu 9.10 will be GCC 4.4. Other systems with more up to date repositories use GCC 4.4 already. From my point of view we have until October this year to fix that problem.
"I'm Commander Shepard and this is my favorite forum on the internet."
Re: gcc 4.4 support
Thanks for starting this thread.
I can't say much at the moment, I've just discovered this problem on the notebook of a pps student (Si). I didn't had the time to investigate this further, but at the first glance it looked like a problem with templates.
We have some situations in our code, where we create a template with template-argument T, where T is for example "const int&". The most common occurence of such code is the Functor with a functionpointer to a function like "void setName(const std::string& name)".
Over several functioncalls we then reach MultiType::setType<T>(). Remember, T is still a const reference. setType<T>() then calls "this->someFunction(T())", where T() is a constructor. In other words, we create an instance of type T and pass it to the function. The problem is, we can't create an instance of "const std::string&" or "const int&" or whatever.
In the past (or on any compiler <= gcc v4.3) T somehow changed from "const int&" to "int". I can't tell right now where the template-argument changed, but it obviously worked somehow.
So the future steps are:
I can't say much at the moment, I've just discovered this problem on the notebook of a pps student (Si). I didn't had the time to investigate this further, but at the first glance it looked like a problem with templates.
We have some situations in our code, where we create a template with template-argument T, where T is for example "const int&". The most common occurence of such code is the Functor with a functionpointer to a function like "void setName(const std::string& name)".
Over several functioncalls we then reach MultiType::setType<T>(). Remember, T is still a const reference. setType<T>() then calls "this->someFunction(T())", where T() is a constructor. In other words, we create an instance of type T and pass it to the function. The problem is, we can't create an instance of "const std::string&" or "const int&" or whatever.
In the past (or on any compiler <= gcc v4.3) T somehow changed from "const int&" to "int". I can't tell right now where the template-argument changed, but it obviously worked somehow.
So the future steps are:
- Localize the problem, is it really what I've described above? (I only looked for some minutes at the code and the compiler error)
- Fix the problem with a small change in MultiType::setType<T>(), in other words "setType<int>()" and "setType<const int&>()" must lead to the same function.
- Search the gcc changelog for a change that explains our problem
- a) Search the web / the gcc documentation for a way to solve this problem without changing our code
or - b) Find a way to avoid const references as template arguments - which could result in some not-really-nice changes in Functor.h (which already is an unreadable bunch of macro-templates).
Fabian 'x3n' Landau, Orxonox developer
Re: gcc 4.4 support
I would like to add a related problem: Our code doesn't compile with Visual Studio 2005 anymore. The problem this time is not us but rather the compiler.
To reproduce you just need to call createFunctor(MyClass::function) where 'function' is a const member:
That's it. The compiler complains about "ambiguous call to overload function", but it really isn't ambiguous and the problem has been reported and fixed in VS2008:
http://connect.microsoft.com/VisualStud ... kID=101619
I could come up with but two resolutions:
1. The easy way: Don't use const member functions with createFunctor (or make a const_cast)
2. The complicated one: Add a function createMemberFunctorConst which in turns adds quite a few more 'unreadable' macro lines to Functor.h.
Furthermore the latter approach implicates writing such const overloads for all kind of macros: network functions, console commands, XMLPort, etc.
So the only solution I can see really is the first one.
Or does anybody have a brilliant idea on how to resolve this issue?
To reproduce you just need to call createFunctor(MyClass::function) where 'function' is a const member:
Code: Select all
class MyClass
{
public:
void asdf() const;
};
static Functor* myFuncto = createFunctor(MyClass::asdf);
http://connect.microsoft.com/VisualStud ... kID=101619
I could come up with but two resolutions:
1. The easy way: Don't use const member functions with createFunctor (or make a const_cast)
2. The complicated one: Add a function createMemberFunctorConst which in turns adds quite a few more 'unreadable' macro lines to Functor.h.
Furthermore the latter approach implicates writing such const overloads for all kind of macros: network functions, console commands, XMLPort, etc.
So the only solution I can see really is the first one.
Or does anybody have a brilliant idea on how to resolve this issue?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: gcc 4.4 support
1337 wrote:Or does anybody have a brilliant idea on how to resolve this issue?
Code: Select all
#ifdef __VS2005
#define const
#endif
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
No seriously, I dont' think there are many other possibilities than you suggested. But if it's fixed in VS2008, why do we care about VS2005? Orxonox also doesn't compile on earlier versions of gcc...
And why does this problem happens only now? Did we just never use const functions in our templates before? As far as I see, you "fixed" this in r3178 but you were able to commit a hell of a lot changes before. Are you using VS2008 then? And if yes, why do we even care? ^^
Fabian 'x3n' Landau, Orxonox developer
Re: gcc 4.4 support
Well, I would like to officially support VS2005, mainly because I use it for the memory leak detector (which in turn doesn't work on VS2008).
The more compilers we use ourselves the better, that's another thing (most at least, surely not in this caes...)
The reason really is that we've never used const-functions. Up until January 09 I have been using VS2005 and there were no problems.
But it seems that using non-const member functions with Functors is not a big deal, so personally I call it fixed, sorry for the fuss, I really thought this issue was bigger.
Btw: Which versions exactly of GCC are not compliant? Because I could then include that in the BuildConfigGCC.cmake script and meaningfully warn the user.
The more compilers we use ourselves the better, that's another thing (most at least, surely not in this caes...)
The reason really is that we've never used const-functions. Up until January 09 I have been using VS2005 and there were no problems.
But it seems that using non-const member functions with Functors is not a big deal, so personally I call it fixed, sorry for the fuss, I really thought this issue was bigger.
Btw: Which versions exactly of GCC are not compliant? Because I could then include that in the BuildConfigGCC.cmake script and meaningfully warn the user.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: gcc 4.4 support
Hehe, ok, then we leave it like that for now. And yes, most functions in Functors are static (console commonds, at least for now) or used in Timers (where they usually manipulate an object). Now we can use network functions, but most of them will also manipulate some date, the 3 functions you had to change are more or less a special case. ![Wink ;)](./images/smilies/icon_e_wink.gif)
And no, sorry, I don't know which versions of gcc are not compliant. We could try to search for "exotic" stuff like variadic macro support or such, but I don't suggest to do so - much work for almost nothing.![Wink ;)](./images/smilies/icon_e_wink.gif)
![Wink ;)](./images/smilies/icon_e_wink.gif)
And no, sorry, I don't know which versions of gcc are not compliant. We could try to search for "exotic" stuff like variadic macro support or such, but I don't suggest to do so - much work for almost nothing.
![Wink ;)](./images/smilies/icon_e_wink.gif)
Fabian 'x3n' Landau, Orxonox developer
Re: gcc 4.4 support
Most people use GCC 3.4 and higher anyway. And that compiles fine.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: gcc 4.4 support
I shall further investigate that const reference problem with GCC 4.4 (or rather our code). There are some very promising solutions provided by Alexandrescu's "Modern C++ Design" like type traits.
His entire code is implemented in the Loki library (which mainly consists of mysterious combinations of the "template" identifier). And this library is at least available for ubuntu, debian and windows. If we lack support for certain distributions, we could just put a few headers in our repository. Most of the Loki library is just templates and doesn't require linking.
There are by the way a lot more interesting (but complicated) features of Loki:
http://loki-lib.sourceforge.net/index.p ... n.HomePage
Btw: Would it be possible for a linux user to get gcc 4.4 and post the exact error output?
His entire code is implemented in the Loki library (which mainly consists of mysterious combinations of the "template" identifier). And this library is at least available for ubuntu, debian and windows. If we lack support for certain distributions, we could just put a few headers in our repository. Most of the Loki library is just templates and doesn't require linking.
There are by the way a lot more interesting (but complicated) features of Loki:
http://loki-lib.sourceforge.net/index.p ... n.HomePage
Btw: Would it be possible for a linux user to get gcc 4.4 and post the exact error output?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: gcc 4.4 support
If the problem really is the one described, then I have found a very simple solution:
Instead of instantiating T(), you simply do it with TypeStripper<T>::RawType()
Code: Select all
template <class T> struct TypeStripper
{ typedef T RawType; };
template <class T> struct TypeStripper<const T>
{ typedef T RawType; };
template <class T> struct TypeStripper<const T&>
{ typedef T RawType; };
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: gcc 4.4 support
Nice, I hope someone can try this soon with gcc 4.4.
Fabian 'x3n' Landau, Orxonox developer
Re: gcc 4.4 support
trunk -> checkout -> compile with gcc 4.4 -> works: yes/no
anyone please?
anyone please?
Fabian 'x3n' Landau, Orxonox developer
Re: gcc 4.4 support
I'm upgrading to Ubuntu 9.10 right now. gcc-4.3 is no longer supported in this version, instead they use version 4.4 for everything. I'll be back in a few hours to tell you if that worked out.
[EDIT:] And yes, I was able to compile it, but due to other problems on this computer I won't try to start it. I'll try to do this at home on my laptop, which will also be upgraded to gcc-4.4.
[EDIT:] And yes, I was able to compile it, but due to other problems on this computer I won't try to start it. I'll try to do this at home on my laptop, which will also be upgraded to gcc-4.4.
"I'm Commander Shepard and this is my favorite forum on the internet."
Re: gcc 4.4 support
sorry forgot about this thread
I'm using ubuntu 9.10 since some time now and gcc-4.4 works without problems (same with ogre-1.6).
I'm using ubuntu 9.10 since some time now and gcc-4.4 works without problems (same with ogre-1.6).
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Re: gcc 4.4 support
I think I remembered that we solved the problem, but since there was nothing here, I supposed we didn't. But in this case I'll close the thread.
"I'm Commander Shepard and this is my favorite forum on the internet."
Who is online
Users browsing this forum: No registered users and 2 guests