VS2014 Support


#1

The source of most errors I got from trying to compile JUCE with VS2014 CTP 4 seems to have been due to it supporting the noexcept keyword.

Jules, here's a patch to disable JUCE's fallback declaration, to be put somewhere in juce_PlatformDefs.h:

#if defined (_MSC_VER) && _MSC_VER >= 1900
 #define JUCE_COMPILER_SUPPORTS_NOEXCEPT 1
#endif

Do note that something about juce::Array causes the compiler to obliterate itself with error C1001, aside from error D8040 happening without a known cause.... So you won't be able to get a juce based project running yet.

Will post more fixes as I continue farting around with it.


#2
#if defined (_MSC_VER)
 #if _MSC_VER >= 1600
  #define JUCE_COMPILER_SUPPORTS_NULLPTR 1
  #define JUCE_COMPILER_SUPPORTS_MOVE_SEMANTICS 1
 #endif

 #if _MSC_VER >= 1700
  #define JUCE_COMPILER_SUPPORTS_OVERRIDE_AND_FINAL 1
  #define JUCE_COMPILER_SUPPORTS_LAMBDAS 1
 #endif

 #if _MSC_VER >= 1900
  #define JUCE_COMPILER_SUPPORTS_NOEXCEPT 1
 #endif
#endif

Edit: Btw, don't ask me what happened to version 1800... It is what it is, I guess.


#3
​#if defined (_MSC_VER)
 #if _MSC_VER >= 1600
  #define JUCE_COMPILER_SUPPORTS_NULLPTR 1
  #define JUCE_COMPILER_SUPPORTS_MOVE_SEMANTICS 1
 #endif

 #if _MSC_VER >= 1700
  #define JUCE_COMPILER_SUPPORTS_OVERRIDE_AND_FINAL 1
  #define JUCE_COMPILER_SUPPORTS_LAMBDAS 1
 #endif

 #if _MSC_VER >= 1900
  #define JUCE_COMPILER_SUPPORTS_NOEXCEPT 1
  #define JUCE_DELETED_FUNCTION = delete
 #endif
#endif

 


#4

Turns out this new VC++ has no clue how to deduce what line 477 in juce_Array.h is doing, even though it's a pretty normal thing:

new (insertPos++) ElementType (newElement);

"Error C1001: An internal error has occured in the compiler." obviously doesn't help understanding why it ain't working, and I've no way of knowing how to coax it.

Uncommenting that line, even though silly, gets the application... "running."

Small note: there are new warnings made up with this new edition of VS2014; juce code is absolutely riddled with inane garbage that's not even worth tidying up.


#5

Wow, that's a pretty mundane expression to cause an internal compiler error! Surprised they've let the compiler go out to beta if it's still so flaky.

I'd be reluctant to start nudging the syntax around just to try to work around this, as they'll presumably fix it before the release.


#6

..actually one quick thought about that compiler crash: it might work if you turn off the new noexcept handling - it could be that they have some ropey code that tries to look for possible exceptions, and something about the fact that the 'new' operator can throw is what's making it crash.


#7

Not sure what you mean by disabling the new noexcept handling. Are you referring to the bit where I changed up whatever that was related to JUCE_COMPILER_SUPPORTS_NOEXCEPT?

If so, I tried redefining noexcept to nothing, and to throw(), with both causing more trouble than what it's worth.

I've a feeling it's related to the mixture of their noexcept implementation, template deduction and placement new. We may simply have to wait for CTP5 to get back to this.


#8

Thanks for adding this Jules!


#9

I decided to bring this issue to the attention of MSFT in the hopes they would look into it and provide any clues... So far, no word from them, but figured I should put the Connect link here:
https://connect.microsoft.com/VisualStudio/Feedback/Details/1005696

If you're willing, please register with the Connect site if you haven't and vote the issue as important.