Can't compile with Visual Studio 2013

[muemart]

I finally got all the dependencies compiled, and am now trying to compile orxonox with MSVC12 (yeah, the numbers don't match). But apparently it doesn't like multitype, specifically reading it as an std::string. This compiles fine:

Code: Select all

#include <iostream>
#include <util\MultiType.h>

int main()
{
	orxonox::MultiType a = 42;
	std::string test;
	a.getValue<std::string>(&test);
	std::cout << test;
}

But this doesn't:

Code: Select all

#include <iostream>
#include <util\MultiType.h>

int main()
{
	orxonox::MultiType a = 42;
	std::string test = a.get<std::string>();

	std::cout << test;
}

The error message is:

1>[long path]\orxonox\src\libraries\util\multitype.h(380): error C2668: 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string' : ambiguous call to overloaded function
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xstring(949): could be 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(std::initializer_list<_Elem>,const std::allocator<char> &)'
1> with
1> [
1> _Elem=char
1> ]
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xstring(885): or 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(std::basic_string<char,std::char_traits<char>,std::allocator<char>> &&) throw()'
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xstring(778): or 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(const _Elem *)'
1> with
1> [
1> _Elem=char
1> ]
1> c:\program files (x86)\microsoft visual studio 12.0\vc\include\xstring(719): or 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &)'
1> while trying to match the argument list '(const orxonox::MultiType)'
1> [long path]\multitype test\main.cpp(9) : see reference to function template instantiation 'T orxonox::MultiType::get<std::string>(void) const' being compiled
1> with
1> [
1> T=std::string
1> ]

When I just do

Code: Select all

std::string test = a;

I get the not-so-useful message

error C2440: 'initializing' : cannot convert from 'orxonox::MultiType' to 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>'
1> No constructor could take the source type, or constructor overload resolution was ambiguous

Not really high priority, but it would be nice if there would be a quick fix for this.

[x3n]

I'm no Visual Studio expert, but if you have to compile the dependencies by yourself, does that imply that the dependencies provided on orxonox' download site for MSVC 2005, 2008, and 2010 do not work with MSVC12? If so - would you mind providing the dependencies for other users on our download site once you make it work? You can upload them into SVN here: http://svn.orxonox.net/downloads/window ... endencies/

About the compile error - maybe this only occurrs if MSVC uses C++11 features? Try disabling them.

The error is weird because the function in the second example should indirectly call the function from the first example, so both should work. But maybe MSVC is confused by the conversion operator.

Out of curiosity - what happens if you compile this:

Code: Select all

#include <iostream>
#include <util\MultiType.h>

int main()
{
   orxonox::MultiType a = 42;
   std::string test;
   test = a.get<std::string>();

   std::cout << test;
}

[muemart]

Yes, compiled libraries are not compatible with other versions of MSVC. I'll upload them if I can get orxonox to compile and make sure they actually work, too.
I searched around the net and tried out some suggestions, but there doesn't seem to be an option to disable certain language features, except installing an older toolset (i.e. and older version of Visual Studio). Your code produces the exact same compile error. Maybe it's a compiler bug, though it'd be weird when older versions can compile it without problems.

[muemart]

Maybe a bit late, but here's what I found out:
MultiType has overloaded conversions for std::string and char* (witch <class T> operator T*). You can assign both string or char* to a string, and that's where the ambiguity is. This also explains why a.get doesn't work (returns *this) but a.getValue does (does some stuff with MT_ValueBase). Of course there's also a stackoverflow question with the same problem, but without a solution that wouldn't involve going through the whole code and changing a lot of things.
I do wonder why gcc has no problem with this, though...

[x3n]

Thanks for the update.
It's difficult for me to reproduce because my gcc behaves differently, but at least I made some interesting observations.

I think if I change

Code: Select all

template <typename T> inline T get() const { return *this; }

to

Code: Select all

template <typename T> inline T get() const { return static_cast<T>(*this); }

then my gcc shows the same behaviour like your MSVC.

I hope this will help me to find a solution.

It's too late now to dig any further into this, but I'll keep you updated.

[x3n]

I committed a change to MultiType::get<T>() in r10197 (in trunk).
Please have a look and try if you can compile it now. Implicit conversion may still be ambiguous, but at least get<T>() should now work as intended.

[muemart]

Looks like implicit conversion an get<T> work now! I made only some simple tests, but all compiled. Guess I'll get back to trying to compile Orxonox when I have some more time.

[x3n]

Cool! Keep us updated if you manage to make it work. Or ask, if you run into new problems.

[muemart]

Ok, that was less painful than I thought. I can now compile everything fine with only three small changes. A few problems/questions remain, though:

• Are the poco libraries actually required? Poco linking gets disabled if the dependency package has version 7 (PackageConfig.cmake), but that version gets rejected by CheckPackageVersion.cmake (_allowed_minimum_versions is 4.4 and 6.0). Seems like a bug to me, but maybe it's not ready yet. I already compiled ogre and cegui with boost, so that would remove one of the many dependencies.
• Is the Visual Leak Detector something people use? The cmake files are a bit lackluster and can't find the include directory, which makes me think they're not used very often.
• I can't actually actually test the game on runtime, because I, naive as I was, used the newest version of cegui which is not supported. So I can't really say if the runtime errors that appear are due to me doing something wrong or because of the new cegui version. Compiling older cegui versions is a bit of a pain because of their build system and dependencies, so I'd like to avoid that...

That's all I can think of right now. The binary folder is a mess right now (~25 dlls and counting), so I'll change some libraries to link statically in the future, but it's not a high priority right now.

[x3n]

Cool! I'm glad you got that far. Here are some answers or hints:

Poco and the minimum allowed version:
Up to version 6 of the dependency package, we always created a package each for MSVC and MinGW. MSVC packages were created by Reto, MinGW packages were created by me. Version 6 used Poco.
Later I created a new package (version 7), but only for MinGW because Reto was not actively developing Orxonox anymore. This version used Boost instead of Poco (I think I did that for the same reasons like you - to get rid of one dependency).

I guess this explains the unexpected behaviour: For MSVC, the buildsystem expects version 6 because we never released version 7 for MSVC. But you can safely change that check in PackageConfigMSVC.cmake.


Visual Leak Detector:
No it's not used. I think Reto once tried to make it work but I don't know whether he succeeded or not.
Here's what I find in the commit messages for "visual leak detector":

vld.png (44.94 KiB) Viewed 82977 times

Maybe this helps to find a clue about how to use it. Use the SVN client of your choice (or the repository browser on our website: http://www.orxonox.net/changeset/8420 <- last number is the revision-number) to look at the changes.


CEGUI:
Yes this is very unfortunate, but version 0.7 is the last version of CEGUI that works with the current content of Orxonox. Version 0.8 compiles, but doesn't work at runtime because the data files use a different format.
I created a ticket 17 months ago to "Migrate to CEGUI 0.8", but so far no one was willing to do the work.


Btw, do you want to join us at the Orxonox Think Tank next week? -> http://orxonox2.vseth.ethz.ch/phpBB3/vi ... f=4&t=1113

[muemart]

Ok, thanks for that. I think I have most things sorted out now. The Visual Leak Detector should work too, just for good measure. The only thing left now would be cegui. There's no way I'll be able to port everything to the new version, so I'll try to compile the older version soonish.

Btw, do you want to join us at the Orxonox Think Tank next week? -> http://orxonox2.vseth.ethz.ch/phpBB3/vi ... f=4&t=1113

Yes, I'll come, too.

[muemart]

Phew, everything is working now and the new package is uploaded. Would be good if someone else could test it, I may have overlooked some DirectX dlls. The main dependencies should be ok though.

[x3n]

Awesome!
I'll try to test it soon. I hope it also works with the Express or Community version of Visual Studio 2013.

While we're already talking about MSVC: do you think there's a possibility to compile Orxonox in debug mode but use release-build libraries? I've tried that once with Visual Studio 2010 and the old (6.1) dependencies; it compiled, but didn't start.
The problem with debug libraries is that they are really slow which makes it a pain to run and test Orxonox with debug builds...

[muemart]

The libraries should work with all flavours of Visual Studio. Especially the Community version has most features of the full version available, I think.

Googling a bit, it seems it's not recommended to mix debug and release builds, but some libraries (e.g. tcl) are used only in their release version already, because cmake doesn't search for the debug version. It's probably really easy to add a cmake option for that and just test it.
It's true that the debug version is extremely slow though... takes like 30 seconds just to start up.

Edit: Isn't the RelWithDebInfo target there for this? I honestly never tried it, but it sounds like more or less what you want.

[x3n]

Hey that's true, I totally forgot about those build options. RelWithDebInfo still takes long to compile (or rather link), but I found that RelForDevs is really what I need. Compiles fast and runs fast. Thanks for the hint!