----------------------------------------
From: s_sourceforge@nedprod.com To: boost-users@lists.boost.org Date: Wed, 12 Feb 2014 19:50:47 +0000 CC: stl@microsoft.com Subject: Re: [Boost-users] Boost or Standard when there is the choice?
The reason that Microsoft's STL ends up performing better than both Dinkumware's and Boost's implementations is because Microsoft cares about performance and implements most of the optimizations and because, like you said, Boost has more surface area. Microsoft currently cares and they know their compiler/platform better.
I agree that Microsoft do a ton of customisation of the Dinkumware STL, or rather, they /used/ to do a ton of customisation up till VS2013. From my reading of the Dinkumware STL headers, most of the customisation was MSVC specific workarounds rather than optimisations per se. When running a diff between VS2013's STL and the vanilla one we had at BlackBerry I saw a large drop in size of the patchset as compared to VS2012. I didn't investigate, so in fairness the cause could be anything.
My point here, though apparently I didn't get it across well at all, was to give credit to Microsoft and STL for caring about performance and pushing to make it better. My example of make_shared was wrong, but I think the pattern still holds that Boost starts with a 'better' implementation and the standard implementers catch up and sometimes 'beat' Boost in some respect.
Note: the STL that Dinkumware ships is not the same as the one Microsoft ships, so perhaps I'm just being pedantic about naming.
It's pretty close. The BB10 NDK also uses the Dinkumware STL, and it was not unheard of for us to compare the two when a bug turned up to see our STL had been fixed without us realising.
Correct, they are likely to be very close because Microsoft gives fixes back, which for portable fixes, means everyone benefits.