On Visual Studio 11 support

International board Development
#21

So, our self-made guru failed to register? Farewell then :wink:

#22

@bar
You made me really curious of what an IDE is for you and why you oppose ease of reading/writing code and code quality. It’s sad you won’t post again to explain it…

#23

I have uploaded project files for VC11.
If you still use VC10, you can open VCMI_VS10 solution and switch platform toolset back to v100 in project properties. (files seem to be backward compatible)

Recommended setup:
0. Keep vcxproj files in sync with repository. Don’t edit them for reasons other than adding/removing file.

  1. Keep your paths and build settings in the VCMI_global.props, VCMI_global_debug.props and VCMI_global_release.props property sheets. Add them to your ignore-on-commit list.

That way you can update project file list without committing all your paths.
Let me know if this causes any issues for you and if you need to make any additional changes to projects to have them built (/Zm ? ).

#24

I’ve started refactoring towards more usage of enums. A few bugs already showed up. In certain places lack of forward enum declarations makes refactoring quite problematic (additional .h dependencies, sometimes circular). Is anyone against dropping support for gcc 4.5 / MSVC 2010 for this benefit?

#25

I think it`s better to reafctor dependencies. There are to much them ATM.

#26

It’d be nonsense anyway, like putting all enums in global.h. A common pattern:

//A.h
class A{
public:
  enum EB {...};
  ...
};

Let’s suppose a function from different header want to return A::EB. You can either:

  1. include A.h in header – just wrong,
  2. put enum EB somewhere else – but why? it logically belongs here,
  3. use forward enum decls.

For me forward enum decls are like any other forward declaration – they solve mutual dependencies. Refactoring them out without regard does not seems to be the right way. Just think about removing other forward declarations by refactoring – it’d be a total catastrophe.

#27

Right choise is 2 - (header with (maybe) forward decl of class A (if EB really belongs to A, then all it user most likely need at least forward of A otherwise EB is not belongs A) and enum EB.

#28

I don’t understand you. EB belongs to A – it’s an assumption. How do you conclude moving it somewhere else is better than forward decl?

EDIT:
I just realized that one cannot forward declare nested enums. What a shame. So solution 3 is not quite possible anyway…

#29

I may be wrong assumption. Again: if EB is used w|o A then EB most likely not belongs to A.

I said more. Even if using forwards of enums, EB and A forwards should be in one place (some header of forward decls for component A and EB belongs too). And w|o using forwards of enums, forward of class A and full decl of EB should be put in that header.

Another way of refactoring is abstraction: extract interface from class A and put in separate header along with EB, this breaks dependency circle. “Any design problem can be salved by addition of abstraction level, except too many abstraction levels problem”

#30

Never mind, I’m not going to fight with language standard. If an enum makes problems, I’m going to put it in GameConstants.h

#31

Too much outgoing dependencies from one file is not good too - any change triggers nearly full recompilation - this an issue for me.

#32
  1. there is a lot of enums in this file already
  2. I’d like to keep compilation times low too
  3. those enums are not supposed to change often
  4. other options, except ‘make one file per enum/a few enums and include where needed’?
#33

There is always the happy medium (between all enums in one file and one file for each enum), but it may be non trivial to find it. Smth like “one new file for all enums typedefs and forwards from one existing file” may be good decision for now.

#34

If enum and class are related, you’re supposed to put them next to each other in a common namespace. (or in a global namespace, if there is no danger of name collision) Classes were not meant as a mean of providing scope to coupled types.

#35

It doesn’t look any nicer. A namespace for two objects? Then:

  1. it should be anonymous, or
  2. there would be many using namespace X in files using that class/enum or
  3. it would be unhandy to use (NamespaceName::ClassName) and break our conventions.

I think enum for secondary skills is a good example that we have to sacrifice something.

#36

I can’t compile latest code due to missing std::tuple template, does it mean new compiler is needed?

Which version is the most suitable?

#37

Well, I thought VC 2010 has std::tuple. Anyway, I can easily get rid of it.

VC 2012 is preferred, 2010 is deprecated and support will be dropped in a few months (most probably when VS 2012 update 2 is released).

#38

Basically it is safer to use Boost equivalent unless you know that given part of standard library is supported by both VC10/GCC 4.5

While VC11 provides full C++11 standard library support (except of some C99 parts, like cinttypes), GCC still has not completed it. What’s worse, I can’t find any comprehensive list of what is avaialble in which version. (only for the current build gcc.gnu.org/onlinedocs/libstdc++ … s.iso.2011 )

#39

Tow, gcc.gnu.org/projects/cxx0x.html ? + links on that page

#40

This is only for core language features. I’m looking for something like that but for standard library additions. I can’t check when the std::tuple, std::thread or std::regex were implemented. Unless I missed something?