[patch] VS2003 compile fix for yaml-cpp library (emitter.cpp: fatal error C1001: INTERNAL COMPILER ERROR)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Go to trunk
2. mkdir bin\vc2003
3. cd bin\vc2003
4. del /s /q * & rmdir /s /q .
5. "%ProgramFiles%\Microsoft Visual Studio .NET 2003\VC7\bin\vcvars32.bat"
6. cmake -DBUILD_SHARED_LIBS=OFF -G "Visual Studio 7 .NET 2003" ..\..
   Note that I use the patched CMakeLists.tx from issue #87
6. Build any configuration with VS 2003

What is the expected output? What do you see instead?
Expected is that the library gets build.
Instead the following error message is displayed:
emitter.cpp: fatal error C1001: INTERNAL COMPILER ERROR

What version of the product are you using? On what operating system?
MS Visual Studio 2003 SP1 Pro on Win XP SP3

Please provide any additional information below.

Unfortunately the following lines are two complex for MSVC <= VS2003.
    // set up all possible bools to write
    struct BoolName { std::string trueName, falseName; };
    struct BoolFormatNames { BoolName upper, lower, camel; };
    struct BoolTypes { BoolFormatNames yesNo, trueFalse, onOff; };

    static const BoolTypes boolTypes = {
        { { "YES", "NO" }, { "yes", "no" }, { "Yes", "No" } },
        { { "TRUE", "FALSE" }, { "true", "false" }, { "True", "False" } },
        { { "ON", "OFF" }, { "on", "off" }, { "On", "Off" } }
    };

With the attached patch this issue is avoided.

But is there are simpler way to achieve this, so that VS2003 and before do not 
get errors?

Original issue reported on code.google.com by matthias...@gmail.com on 10 Jan 2011 at 6:03

Attachments:

• yaml-cpp_trunk_emitter_MSVC_fix.patch

[GoogleCodeExporter]

As a possibility, I moved the three local structs to an anonymous namespace 
right before the function and kept the "static" qualifier - I'm hoping what 
VS2003 is choking on is instantiating the local struct. Can you check to see if 
it works? (r436)

Thanks!

Original comment by jbe...@gmail.com on 2 Mar 2011 at 5:22

• Changed state: Started

[GoogleCodeExporter]

Same error:
c:\coding\yaml-cpp\trunk\src\emitter.cpp(625): fatal error C1001: INTERNAL 
COMPILER ERROR  (compiler file 
'f:\vs70builds\6030\vc\Compiler\Utc\src\P2\main.c', line 148)

Again the static of "const BoolTypes boolTypes".

Original comment by matthias...@gmail.com on 2 Mar 2011 at 7:58

[GoogleCodeExporter]

Hopefully done this time, r441. I refactored it to nested switch statements, 
which should be more appetizing to VS, plus made it conform to the standard 
with short bool names.

Original comment by jbe...@gmail.com on 2 Mar 2011 at 9:00

• Changed state: Fixed

[GoogleCodeExporter]

VS2003: library only, all 4 configurations built (parse.cpp has an issue left)
VS2005: all 4 configurations built

Original comment by matthias...@gmail.com on 2 Mar 2011 at 9:41

[GoogleCodeExporter]

Does it make any difference if ComputeFullBoolName() is an object method or a 
static/class method (e.g. memory consumption of instances)?

Original comment by matthias...@gmail.com on 3 Mar 2011 at 7:52

[GoogleCodeExporter]

Shouldn't make any difference (it just depends whether you pass the hidden 
"this" parameter). I made it an object method because it needs the three 
boolean state variables. We could just as easily make it a free function and 
add those three parameters to its signature (and I suppose it *might* be 
faster, since it could be inlined, but it's not as if we're calling it 
frequently, and it's not that tiny of a method). Why?

Original comment by jbe...@gmail.com on 3 Mar 2011 at 7:58

[GoogleCodeExporter]

Just curious. Only asked as boolTypes was static before.

Original comment by matthias...@gmail.com on 3 Mar 2011 at 8:09

[GoogleCodeExporter]

Oh, I see. The reason it was static before *was* a memory/speed thing. We were 
building a little data structure with all of the different bool names, and it 
was just a small optimization (pretty tiny, to be honest) to have it not build 
that every time it called the function, especially since there were strings 
involved. (Although the strings were small enough that they probably would be 
in stack memory - most string implementations have a 16-char buffer on the 
stack before they start dynamically allocating.)

So yeah, it probably didn't make much of a difference, but it was one keyword :)

And in any case, it was an ugly way to do it - I think the switch statements 
read better.

Original comment by jbe...@gmail.com on 3 Mar 2011 at 8:26