Microsoft is doing strange things.

It can be understood from recent announcements that Visual Studio 11:

1. Won’t allow building desktop applications with its free (“Express”) editions. Only that Win8 “Metro” stuff. Probably to force developers to make Metro apps.
2. Applications built with VC11 won’t work Windows XP. Probably to force developers force users to upgrade to Win8.
3. There is very little progress on implementing C++11 features (mainly fixes and range-for, that can be already sufficiently emulated). Probably because they wasted time on introducing proprietary language extensions for Metro apps development.

Because of that we certainly won’t move forward from VC10 to VC11 as our primary platform. We can’t drop Win XP support nor expect developers to buy commercial VC editions. Without improved support for C++11 there is even no reason for us to want that.

I tried building VCMI with VC11 beta and it fails. It’s probably a bug in Boost.Assign that appears on compilers that support rv-refs too good. I guess it’s why Ivan #ifdefed initializers lists for GCC there. Anyway, I wouldn’t like introducing a third ifdef variant nor degrading code to lowest common denominator. I’ll wait for Boost to fix this or for Visual to support initializer lists.

So for now and predictable future VS11 is not supported and known to fail to build VCMI. VC10 on Win and GCC 4.5 elsewhere remain and will remain our primary platforms.

[size=75]I guess I kinda should check out MinGW if I don’t want to be stucked with VC10 forever. :/[/size]

Now that’s really strange decision from MS. Abandoning WinXP is … predictable but basically butchering VC Express into Metro-only IDE? Really strange…
Just wondering - what’s the difference between normal apps and metro code-wise? Mandatory CLI.NET?

Yup. Boost assign breaks with c++11. Haven’t found any better way to fix this apart from rewriting 2-3 places in our code.
I believe that this is the already reported here: svn.boost.org/trac/boost/ticket/5419 but it does not looks promising:

[size=59]You should at least check QtCreator with MinGW - it has really good integration with gcc\gdb. No need for console![/size]

I have tried to build VCMI with MinGW but with no success. You have to compile ffmpeg, SDL, SDL_mixer, Boost,… on your own as I didn’t find any precompiled packages for MinGW. So you need at least much time:) The biggest problem is to get SDL_mixer built. It has many dependencies to other libraries and I failed to build SDL_mixer. (there is also a problem with the newest SDL_mixer and MinGW). Perhaps you have more luck:) If you got VCMI successfully built with MinGW tell me about it.

I just did.
GCC/GDB integration indeed is good. I did however needed to use CMake project, because by default it uses MSVC compiler (with success) and CDB debugger (without any success) and haven’t been able to change this.
Semantic highlighting is working, though the choice of configurable colors is really surprising. I can set colors for local variable, class field or virtual method… but not for non-virtual methods nor global functions nor variables.
Code completion started working reasonably after I manually forced updating code model. It knows methods of set, but doesn’t know anything about setOfStringInst.begin()->… After such expression highlighting also goes wild.

Still not there, though it’s a little better than I expected. And it doesn’t throw “Out of memory” exceptions in my face like Eclipse CDT did.

Metro application code is compiled to normal, native machine code. It just uses the new WinRT library (huge, COM-like thing). Writing C++ Metro code usually involves using the new language extensions, so called C++/CX. They are syntactically similar to C++/CLI (though entirely separate) but it’s actually optional. You can write Metro apps in plain ISO C++, it just means having to type much boilerplate code by hand.

It’s not that bad actually.
Some MinGW distribution come packaged with Boost (ie nuwen.net/mingw.html ). SDL and SDL_* and zlib don’t have to be recompiled, they’re pure-C libraries, so they have ABI portable across compilers. ffmpeg is not needed, it’s dependency related to non-win-os, not the compiler. MinGW builds can use H3 bink/smack dlls.

The real difficulty is build system. A few weeks ago I tried to get Makefiles working with MinGW/MSYS and it’s a nightmare, I wasted many hours to no avail. I guess I should try with CMake. Now I don’t have time but I’ll let you know aobut progress.

I tried non-mingw libraries on mingw compiler and it mostly works fine - all general windows libraries links properly and appears to work correctly - including allegro etc.

There only two main problems with mingw:

1. it needs mingw runtime libraries installed on windows
2. It’s both GCC and Win compiler - which may fail assertions done on conditional compiling (rare found bugs with source code which have felt on mingw much more than “rare”)

It seems any library for the platform (win/x86 or win/amd64) should work (almost) out of the box. Thats probably the reason that you couldn’t find libraries version for mingw - the ones whch differ much are already included with mingw compiler - rest should work on all Borland C++,MS Visual C++ and mingw. Of course there may be some compiler pecularities to fix (mostly bugs from other compilers which make them not fully compatible with C++ standard).

It (almost) worked out-of-the-box for me. The only problem was SDL with headers in non-default path (/usr/include/SDL).
I agree that it can’t detect some tricky cases. Theoretically this can be fixed by using IDE really integrated with clang.

After recent release of clang-3.1 with finally implemented lambdas I’ve been trying to compile VCMI with it. With some dark magic like manually compiled boost and using libcxx I’ve managed to do this.
Results are far better than I expected: 5 errors and ~100 warnings (some of them look like actual bug in VCMI). Fixing them shouldn’t be a problem. And this clang have almost complete c++11 support far better than both gcc and msvc!

Have no idea how well clang works on Win though.

Only Java programmers can write text editor that has 200 Mb in size and extremely slow. ©

CMake would be nice to have. It’s definitely more easy to use than current autotools.

Libraries that have interface in C can be used with different compilers. C has standarized ABI and it just works. (At least for given OS)
Interface using C++ however won’t work, and you’ll need to have library build specific for your compiler. Or even worse — for your compiler and its libraries version. That’s why you see often C++ libraries that are flattening their interface to pure C and using all that extern “C” stuff.

Every C++ application needs runtime libraries to be either
a) installed on system
b) distributed with application
c) statically linked into application

It’s not a MinGW-specific problem. Same for ifdef magic. Clang or ICC will fail as well, unless they disguise as MSVC. But it’s not a fault of compiler.

Qt Creator developers are apparently onto this: labs.qt.nokia.com/2011/10/19/qt- … and-clang/ I’ll keep my fingers crossed, IDE looks promising but needs this.

VC10 code completion works perfectly [1] and they apparently use a compiler to obtain high-level code structure representation. I’m really looking forward for open-source IDEs (and other tools) to utilize clang’s power. C++ is a pain to process and it was limiting their usability for a long time. Libclang may bring really great improvements for IDEs: accurate code completion, semantic highlighting, code navigation, refactoring and so on. Or not. We’ll see.

I personally hope to have some fun with clang — I’d like to implement a language extension (compile-time type introspection) as part of my MS Thesis.

I have managed to build it from SVN using VC10. Only to discover it doesn’t support VC ABI, so it won’t work with its runtime. Hello world program fails with linker errors that can’t be helped. I either have to manage to build libc++ and force Clang to use it… or try better luck with Clang built by MinGW. However ATM my MinGW fails to build it.

In LLVM 3.1 release there are experimental Clang binaries for MinGW, haven’t checked them yet.

I have a colleague of mine working on this, it’s likely we’ll get them soon.

[1] And with Visual Assist X it’s even better. :>

What about switching to vc11 now after adding mingw support addition and presence of c::b as alternate free windows IDE? (also we may switch to gcc as main backend on all platforms)

I’d like to stick with VC as release compiler as long as possible.

The good news is that Microsoft is trying to correct their mistakes:

1. Express Edition allowing targeting desktop environment has been announced and recently released blogs.msdn.com/b/vcblog/archive/ … x#10349418

2. Windows XP support has been promised to be fixed in future update

3. More C++11 support has been promised to be implemented in future update

4. is necessary condition for switching. 3) will be a reason to do it.

ATM there is little to no reason to support VC11. If you want to use it now, then you should have also VC10 compiler installed and use it as toolset: blogs.msdn.com/b/vcblog/archive/ … 95093.aspx
That way you can take advantage of VC11 IDE improvements and avoid trouble with porting code to VC11 (AFAIR that’s only a few places where Boost.Assign fails but still I don’t like introducing a third #ifdef variant of code).

1. As for me, I`ll with not use VC anyway.
2. I just suggest to use less boost and more stdc++ with at lest as possible compiler-related ifdefs.
3. If vc10 toolchain will have good support of c++11 there is no reason to stop supporting it.

2. Too many ifdef’s? Take a look on video player. Especially ffmpeg part…

The problem is different compilers. gcc-4.5 has one set of supported features, VS has its own set.
Compilers may have bugs (slow unordered_map destructor in VS), may have incomplete lib (emplace in gcc containers), sometimes bugs may be in used libraries (clang + boost 1.46 filesystem).

ifdef’s are usually used when everything else fails - i doubt that there is easy way to remove them especially when you can’t test code in another compiler (like recent INFINITE_DIST 3-4 commits)

Compiler features and bugs is the thing I`m talking about. I didn’t mean that there many ifdefs now, contrary I mean that we may add a few, but no more. I just suggest to have a look at c++11 features that replace boost features (ideally remove all boost-related from global includes, use “locally” only where it really usefull).

Feature-like they’re mostly the same (C++11 library additions are almost entirely from Boost).
However Boost is now more portable and reliable. Both VC10 and GCC have incomplete (or buggy) c++11 standard library implementations and using the new std:: features usually leads to unpleasant surprises.

The only thing that should be now taken from std and not boost are smart pointers, especially since there is no unique ptr equivalent in boost (there were no rv-refs at the time). As for the rest… I guess we’ll gradually move towards std as the implementations catch up. I wouldn’t do that now though.

We try to use ifdefs as rarely as possible. Sometimes this is just the least worst.

It won’t, c++11 update is only for VC11.

Microsoft released “Update 1” for Visual Studio 2012 that fixes WinXP targeting. It makes VC11 an acceptable upgrade and most likely upcoming Windows releases will be built with it (making it a primary win toolset). Therefore, within several days, I’ll probably replace VC10 projects with VC11 project files.

VC10 remains supported for now, though I’d like to drop it relatively soon. Treat is as deprecated. Most likely within ~3 months there will another update for VS2012 with more C++11 support, including initializer lists, variadic templates and explicit conversion operators. I want to have Visual 2010 dead by then.

“C++11 support” - GCC 4.7.2 has a lot of it already - not like “C#” + “LINQ”, but close… and GCC 4.8 will add even more, like constructor inheritance - something Delphi 7 has …
Why would you even want support for “VS” above 2008, which seems the most balanced “VS” up to date?
Suggestion: focus on the code, not on RAD IDEs…
I’ll give “SDL”, “mingw”, and my cross-compiler a try, and see what falls out …
Again, focus on the code if you ask me - “JSON” is “nice” for slow*, dynamic* and complex*, and the maps parser is a mess in my POV, but is it what you need?.. The AI should be scripted, in my POV - let the best players define it! …
Good luck!

It is absolutely logical to use native toolchain on each platform. So if we want to use C++11 features (because we focus on code) avaliable only in newer versions of Visual Studio - we should use them despite they are not balanced from you point of view.

You criticize without suggesting an alternative.

Yeah it is already a lot of work to do! Feel free to help us with your patches And what about scripted AI we should choose scripting language for VCMI first: Lua, Python, or something else.

The issue with AI is not whether it should be scripted or not, but how the hell make it scriptable at all. Neither current reasoning and callback system seem to be good subject for scripts.

Certainly it is. But it’s one of the oldest part of code, only recently BeeGee is working with it.

… while Debian Stable still uses gcc 4.4.
Latest gcc is nice but this means abandoning almost all Linux distros. Not worth it.

And what do you propose? Back to plain-text parsers? Some custom format?
“slow” - I don’t know any speed issues with json parser. Especially compared to time needed to read any file from HDD or load images into memory.
“dynamic” - While H3 structures are static they have a lot of optional parameters or arrays\lists. Json works quite well here.
“complex” - Yes, H3 structures are complex and have a lot of interconnections between them. Json (indirectly) allows us to connect all of them.

The only alternative to Json I know about are such formats like XML. Which are even more slower to parse and more complex to write - most of our json configs are written manually.

Python most likely. Can’t be said for sure until someone will actually start working on scripting though.

Actually it looks that our map parser is the oldest part of code along with defHandler: sourceforge.net/apps/trac/vcmi/changeset/27

Well, I can think of several reasons. VC IDE received a number of improvements.

1. To allow C++11.
2. To have reliable intellisense (code completion, tooltips, finding references and so).
3. To have semantic code highlighting.
4. To have proper support for dark themes.
5. To have reference highlighting.

I’m not sure what do you man by “most balanced” IDE. For me VS2008 is just inferior. Now its only merit is being relatively light-weight when compared to future releases. But if you are looking for light-weight IDE, then VS is certainly a bad choice.

I don’t think it is an alternative. IDE is a tool allowing to read and write code more effectively.
And, discussed in this thread, migration to VC11 is mainly motivated by upcoming imprvements to C++11 support that is a feature strictly for the code.

It has been done, VCMI should build fine with MinGW.

I am aware. We have what we have, the project is not perfect. From time to time on of the worst parts gets rewritten, so I hope the general code quality improves over time.

I’m fine with writing AI in C++. Scripts means additional layer of glue between languages that needs to be written and maintained. In future we will likely provide a way to write a AI in a script language. [Likely Python but it is not that relevant.]
Players usually just play. We should not rely on them doing our job.

Pointing out, not “criticize”. Nevertheless … you can see the ones in “Baldur’s Gate” II for example.

I’ve done the map parser already… Thanks. Time will show.

In my POV, you have the wrong question here. You should learn to implement game AI first - try doing some AI scripting for existing mod-able games first. Make a basis for comparison - learn to use some existing game scripting engines, and then, try to implement one yourself.

I failed to understand you. GCC 4.4. should be perfectly capable of building GCC 4.7.2, or any other version for that matter - you can always build and install GCC 4.7.2 on any distro* being it 32 or 64 bit build…

You’re assuming. Time will show.

IDE is a tool - thats correct, the rest is wrong in my POV. Its the person what is creating the program, not the IDE… I’ve used tons of VS versions and other RAD tools the past 10 years, at work…
Let you ask you: You want to craft a program what works and is robust, or you want to “code more effectively” - whatever that is supposed to mean

Nevertheless, you’re free to choose.
BTW, writing from a guest account is not my favorite, so I’ll not be writing again.

Good luck!