I'm trying to bring an old, large project from VS 6.0 into 2008, and I've been able to overcome a lot of the issues so far (with a lot of help from GameDev and other sources, thanks!), this one has me majorly stumped: It happens when I compile

error C2039: '_Xran' : is not a member of 'std'
error C2039: '_Xlen' : is not a member of 'std'

My research shows that this problem is very much related to moving projects from an older VS platform (notably 6.0) to a newer one. However, most people report linker errors (instead of compilation errors) with regards to these two methods. The libraries that seem to be mentioned the most based on my research is libc.lib. Any help would be greatly appreciated. Here is the code that the compiler is finicky about:

void __cdecl std::_Xran(void) 
{
	throw -1;
	OutputDebugString("Invalid subscript (probably)\n");
}
void __cdecl std::_Xlen(void)
{
}

Did YOU write that? You're NOT supposed to put stuff in namespace std!

I found this page which talks about a similar problem.

This problem is new to me, but I think what is going on is this:

- The CRT for VS 6.0 had those functions defined
- Those got removed in VS 2003
- If you had a library which was compiled against the VS 6.0 CRT, and you later tried to link it against the 2003+ CRT, then it would complain because it wanted those functions to be implemented. This problem only exists if you're linking a precompiled binary, not if you're building from source.
- I think some previous developer was in the above situation, and they added those functions as a way to solve that problem.

Now it looks like you are trying to compile this code from source. If you recompile from source, then the code gets compiled against the 2008 CRT, and that CRT doesn't declare or want those functions. So you no longer need to implement them. So perhaps the compiler would be happier if you just deleted them.

To Red Ant:

I didn't write any of the code, we received it from a 3rd party to update for Visual Studio 2008. The actual code is in a .cpp that was written for the project, are those two members adding code to the std namespace if I understand correctly?


To pinacolada:

What is CRT? C Runtime Library?(Novice here)
I removed the code and the errors disappeared, I'm just a little worried that I'll try running the program and that "missing code" might bite me in the ass, or should I even be worried about that at all?

The fact I couldn't find any information on the issue seems to agree with your theory, and makes a lot of sense based on the nature of the project.

Thanks

Quote:Original post by TylerMoore
What is CRT? C Runtime Library?(Novice here)

Yes. Although to be more accurate, I guess I should have said "C++ standard library".

Anyway, the idea is, every compiler has a bunch of C++ code which it implements behind the scenes. This contains the implementation for std::string, std::vector, and lots of other stuff.

So like any C++ code, there are the headers and there is the implementation. When you write a function header, it's like a promise to the compiler that says, "I promise that at link time, you'll find a function that looks like this." So the VS 6.0 standard library headers contained, among other things, a promise that said "I promise you'll find functions called _Xran and _Xlen".

But the actual implementation for that code is in a separate .lib file (or maybe several lib files) which is also provided by the compiler. These have names like libc.lib, or libcmt.lib, or msvcrt.lib.

So like any C++ code, you can get problems if the headers don't match up with the libraries, which is what happened when someone tried to take a library built against the VS 6.0 standard library, and linked it against the 2003 standard library. The promise to find the functions _Xran and _Xlen was broken! So some guy wrote those functions to make the linker happy.

Now the problem you have today is just a syntax error. You can't define a function inside a namespace like that, unless that function is predeclared inside a "namespace{}" block.

But anyway, the best bet is to just delete those functions because, 1) You're not supposed to define anything inside the std namespace, and 2) You're not supposed to have anything that has a name that starts with an underscore followed by a capital letter. Both of those conventions are reserved by the compiler. So if deleting those functions fixes your build errors, then I would not be worried about it.

Awesome, thanks!