1

I am porting a solution from Visual C++ 8 (visual studio 2005) to 10 (visual studio 2010), and I am getting a puzzling error for which I have found only sparse links on the web (for example this which refers to visual studio 2005, but there is no follow up so he must have fixed in some way).

The error is the following. In files which include the fstream header I get 

1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\fstream(111): error C2766: explicit specialization; 'bool std::_Ungetc<char>(const char &,_iobuf *)' has already been defined
1>          C:\Program Files\Microsoft Visual Studio 10.0\VC\include\fstream(103) : see previous definition of '_Ungetc'

At first I supposed that there was some remaining reference to VC 8, so I started from scratch adding existing files to a new solution / project but I am getting the same error. Commenting out the include (and the relevant functionality) the project compiles and links.

This must be some kind of misconfiguration on my parts, since a minimal program like this 

#include <fstream>
int main(){
    std::fstream stream;
    return 0;
}

is compiled without errors, so the header didn't get somehow corrupt after installation.

I am unfortunately unable to reproduce a minimal working example, but I hope that something of this problem could ring a bell to someone. Do you have some suggestions of things that I could check?

Francesco
  • 3,200
  • 1
  • 34
  • 46

1 Answers1

2

The code around the lines mentioned in the error message defines several specializations for _Ungetc(), based on const char&, const signed char& and const unsigned char&, respectively.

The error seems to indicate that your compiler is treating signed char as the same type as char, which should not happen.

My best guess is that, somewhere in your code, before <fstream> is included, you have:

#define char signed char

Or, worse:

#define signed

In that case, removing the offending line will fix your problem. Note that char is signed by default anyway in MSVC, unless you pass it the /J option.

Community
  • 1
  • 1
Frédéric Hamidi
  • 258,201
  • 41
  • 486
  • 479
  • Thanks, that was my analysis. This is a legacy code base and everything could happen... but I cannot find such an evil definition (and furthermore it is working under vc++ 8). Thanks anyway, I will look again. – Francesco Nov 09 '11 at 16:13
  • Frederic you were right. In one of the legacy headers there was a #define signed. I had looked for #define char ... The offending define was conditionally not parsed in the vc++ 8 solution but in the migration it was being compiled. Thanks again. – Francesco Nov 09 '11 at 16:22
  • I must add that you really saved my day :) – Francesco Nov 09 '11 at 16:24