Different version of the STL and Far Cry

Started by
5 comments, last by Conner McCloud 18 years, 10 months ago
I was looking at the changes in the latest Farcry patch and thought this was an interesting comment
Quote: Recompiled the 32bit version with a different version of STL to address some server slowdowns.

"I can't believe I'm defending logic to a turing machine." - Kent Woolworth [Other Space]

Advertisement
Quote:Original post by Rattrap
I was looking at the changes in the latest Farcry patch and thought this was an interesting comment

Quote:
Recompiled the 32bit version with a different version of STL to address some
server slowdowns.


And ? ... The C++ standard tells us what are the different components of the STL. it do not enforce the implementation. Different compiler vendors might have different implementations of the STL, and some implementations might be standalone.

Regards,
I guess I just find this funny because I see all of the arguements about using the STL, because it is already optimized, etc. And the fact that there is at least one major company who decided that what ever one they were using wasn't quite good enough. I don't want to start another STL debate, I just found it interesting.

"I can't believe I'm defending logic to a turing machine." - Kent Woolworth [Other Space]

Quote:Original post by Rattrap
I guess I just find this funny because I see all of the arguements about using the STL, because it is already optimized, etc. And the fact that there is at least one major company who decided that what ever one they were using wasn't quite good enough. I don't want to start another STL debate, I just found it interesting.


But they still use the STL :)

Since there are multiple implementations on the market, and since these implementations are different, there is at least one implementation that is faster than another when it comes to a particular point.

I agree with you, this a good lesson to learn: as programmers, we should not stick to a particular implementation of a solution, unless it is good enough. It seems that in their case, the STL they used was not good enough :)

Regards,
also, a good point worth making is that because they used the STL it was a simple job of pluggin a new version it, recompiling and off they went.

If it had been some custom non-standard code then this wouldnt have been an option and might well have required extra work.
Quote:Original post by _the_phantom_
also, a good point worth making is that because they used the STL it was a simple job of pluggin a new version it, recompiling and off they went.

If it had been some custom non-standard code then this wouldnt have been an option and might well have required extra work.


That is what I was thinking. All they probably had to do was copy and past the new files, and they get a speed increase with the same code.
Quote:Original post by Rattrap
I guess I just find this funny because I see all of the arguements about using the STL, because it is already optimized, etc.

I think you misunderstand the argument. The argument is not that the STL is already optimized, so you're guarenteed that its the best solution. The argument is that the STL is already optimized *and standard*, so you can focus more on getting the project done than on twiddling basic containers, without worrying that you're using a poorly written algorithm [assuming you use the library correctly, of course]. Then, after all is said and done, should a profile show that some aspect of the STL *isn't* ideal, you can easily fix it with minimal changes.

CM

This topic is closed to new replies.

Advertisement