Quote:
Originally Posted by Mattie
Quote:
Originally Posted by theqizmo
In other words, USE STD::VECTOR.
|
But ... why? Do you know of bugs in CUtlVector (etc) that cause you to say this? Or is it just a preference? I see no real reason why people should be reluctant to use std::vector (etc), yet I also haven't seen any reason why people should be reluctant to use the Valve container classes.
While I've been paid to code for nearly a decade now, Source is my first experience using one of Valve's SDKs. If there are pitfalls that their development teams commonly fall back into, I'd love to hear about those problems.
Quote:
If your version of gcc can use CUtlVector, then it can definitely use std::vector.
|
Absolute statements were meant to be broken. ;) I'm probably the only case where this isn't true: my old Linux box has an older gcc which has a linker bug when I try to statically link libstdc++.a.
I could spend hours grabbing a new GCC without the problem, rebuilding it all on the slow machine, and then rebuilding and testing my plugins. Instead, at the moment I'm just happy that I used Valve's slightly-clunky classes so I'm not forced to do so.
-Mattie
|
I use CUtlVector's extensively in my plugin
Im new to Visual C..So I used what they gave me..
I dont know if CUtlVector's have more overhead than std::vectors...
but CUtlVector was the first container class I could find when starting on this...
I wish Valve used Borland
__________________