PlayerData iOnlineID
-
Yeah, so, the new build is running in VS2013. I’m not sure whether VS2008 works, and I’m pretty sure VS2005 won’t work.
I’ve kept the VS2008 solution files around for legacy reasons but I’m no longer checking whether something breaks with them. The 2013 solution SHOULD work in 2013 Express, if it doesn’t let me know what’s wrong with it.
-
Well, let’s see:
#include <stdio.h>#include <list>int main( int argc, char* argv[] ) { std::list <int>test; printf("%u\n", sizeof(test)); return 0; }</int></list></stdio.h>VC6, 2003 & 2010: 12
2008 SP1: 28Presumably 2005 is also using the 28 value, ergo you can’t directly use std::list with that compiler.
-
Yeah, that’s what I figured.
Not a single idea why 2005 and 2008 have a different std::list size, though. You can always conditionally test for those versions with the _MSC_VER macro and replace all std::list references with just three uints or something.
-
Huor wrote:
ah ok, typically M$.Comments like this piss me off. Nothing to do with “M$” (which playing a game that wouldn’t have existed without them is rather laughable). I’ll bet you that gcc and Clang (or llvm or whatever compiler you’re a fanboi of) have also had STL structs change in size and signature across versions. Remember, the C++ spec gives NO guarantees as to binary compatibility. What we’re doing falls under undetermined behavior.
On the topic at hand, as I said feel free to use the newest revisions but do conditional defines, that’d work as well and you can commit those to the SVN for compatibility.
-
i dont have a problem with what you have suggested FF, nor even that you have changed the layout - hell no. I am confident that i can live with the previous definition. I am not even mad that it happens. I was just wondering and would not have assumed that the size the STL containers do change just by using different versions of the library. Good to know, always something to learn
I am just a bit disappointed, cause its not the only thing that they do change and which is not compatible anymore and which is not apparent (you dont get a warning nor do i ever have read a kind of release note where they do protocol that they changed sizes and whatnot of their libraries). So why is it not M$? I use a product from them, their libraries.
PS: there is no need for me to define different versions based on _MSC_VER not as long as i am using VS2005. So i use the previous definition of EquipDescList and EquipDescVector and all is good.
PPS: I am not mad at anyone of you - just if you felt i am. No i am not! -
Again, they don’t release that information because you’re not supposed to be using it. Using it is bad design. It’s a terrible idea. The only reason we have to care is because we’re using a private API as though it were public, with binaries compiled over 10 years ago. No public API ever uses the STL for precisely that reason.
Also, using “M$” is a derogatory acronym, if you hadn’t figured that part out. I find using that childish and unwarranted.
-
I use it cause its a shortcut - that is well known - without putting anymore weight into it. Not more not less. No idea what you interpret into it.
People can get mad because of odds and ends. Sigh. I will remember that and just for the good tone - write Microsoft - in future - so no one is pissed off.
-
Just to comment here on using the STL with FL, we really should not use the stock MS versions but rather use our own implementations that are FL binary compatible. I did this partially for FL-style maps (which did not match VC6, VC7 or any other STL library version) here:
Maybe it’s fine for lists with the VC8 or higher versions, but we shouldnt really trust that because who knows if the FL devs just wrote their own implementations.
-
If the MSVC STL works, I wouldn’t recommend making our own. Wasted effort and more prone to errors.
This of course is assuming thorough testing of the STL objects in question.
-
Well that’s a special case
