views:

189

answers:

1

I'm currently migrating from Visual Studio 2008 to 2010. My software makes heavy use of Boost and it's TR1 features. I now get a lot of compiler errors, because VC10 has it's own TR1 implementation.

I know I can disable Microsoft's TR1 implementation with the _HAS_CPP0X switch (see here), but I'm not sure if this also disables other features that could be interesting in the future.

So, I'm wondering what is the better implementation of TR1; the one from Boost or the one from Microsoft? Are there any differences at all? Does disabling the Microsoft implementation have any disadvantages?

+1  A: 

If your code doesn't compile with VC10's standard library, then that might indicate that it isn't standard-conforming. The standard library in VC10 comes from Dinkumware, and these guys aren't bad when it comes to implementing a standard library. (PJP used to be the lib working group's chair.) I'd look very closely at each issue, before dismissing it as a VC-specific problem, lest you might not be future-compatible.

Also, TTBOMK, VC10 doesn't just come with TR1, but with C++1x (e.g., std::shared_ptr instead of std::tr1::shared_ptr; ICBWT), so boost's and VC10's libraries actually aren't fully comparable.

sbi
Have you checked their list implementation? I have not looked the one came with vs2010, but before that all had linear complicity for splicing.
leiz
@leiz: No , I haven't. (I rarely ever ended up using a list, even when I started doing so. Usually, vector turns out to be better.) But I was saying that, when code doesn't even _compile_ using it, I would look really closely before dismissing this as a problem with the library implementation, rather than a problem with the code, because, _generally_, their implementation is pretty good. That doesn't mean, however, that I think there are _no problems at all_ in Dinkumware's implementation. Dinkumware is run by humans.
sbi
@leiz: C++0x now specifies that `splice` should be O(1) and authorizes `size` to be O(n) for list (because the two are incompatible), I don't know whether or not it was the case for C++03.
Matthieu M.