Portability between compilers and platforms. On Sun, Jul 27, 2014 at 4:21 PM, Jorge Rodriguez <bs.v...@gmail.com> wrote: > Not bad. I was thinking about the Microsoft STL implementation when I wrote > that but still good to know. > > El jul 27, 2014 1:12 PM, "AnAkIn" <anakin...@gmail.com> escribió: > >> I did a quick benchmark on linux with gcc 4.9.1/clang 3.4.2, and it looks >> like std::vector is actually faster than CUtlVector when inserting 100000 >> elements: >> CUtlVector: 9021 µs >> std::vector: 4456 µs >> It's faster as well when removing the first 1000: >> CUtlVector: 88 µs >> std::vector: 39 µs >> >> It may have been true 10 years ago that Valve's STL was faster than the >> system's one, but I doubt it is today. >> >> >> 2014-07-19 18:12 GMT+02:00 Jorge Rodriguez <bs.v...@gmail.com>: >>> >>> This may not convince you to use it but in fact valves template library >>> is faster than STL. It has a few gotchas as far as usage goes but standard >>> STL implementations tend to be somewhat slow especially in debug mode. >>> >>> El jul 18, 2014 1:27 PM, "Borzh" <borz...@gmail.com> escribió: >>> >>>> I just include <algorithm> and that breaks everything (I don't need to >>>> use min/max of course). >>>> I just was writing external plugin for source and I don't really know >>>> all valve internals. >>>> Just prefer use STL, which I know is an awesome (and well tested in all >>>> ways) library. >>>> >>>> >>>> 2014-07-18 16:48 GMT-03:00 Skyler York <sky...@gmail.com>: >>>>> >>>>> Quick side note, but you can wrap std::min/max in parenthesis to >>>>> prevent macro expansion. It's not pretty but it works: >>>>> >>>>> (std::max)(a, b); >>>>> >>>>> >>>>> On Fri, Jul 18, 2014 at 11:33 AM, Tony "omega" Sergi >>>>> <omegal...@gmail.com> wrote: >>>>>> >>>>>> I don't understand why you need to use stl at all.. when the reason >>>>>> why it's incompatible, is because pretty much every use of stl has been >>>>>> wrapped by valve functions in order to tie it all into the memory >>>>>> manager. >>>>>> tier1 is full of engine compatible containers and whatnot for anything >>>>>> you >>>>>> could need to do. >>>>>> >>>>>> >>>>>> On Fri, Jul 18, 2014 at 9:20 PM, Borzh <borz...@gmail.com> wrote: >>>>>>> >>>>>>> I had to undefine it, undefine MINMAX_H also, so it could be included >>>>>>> after that and then include minmax.h manually. >>>>>>> Anyway it is ugly solution and macros should be written in uppercase >>>>>>> to not confuse with methods. >>>>>>> >>>>>>> >>>>>>> 2014-07-17 21:25 GMT-03:00 Dexter Haslem <dexter.has...@gmail.com>: >>>>>>> >>>>>>>> why not just undefine it before STL headers? >>>>>>>> >>>>>>>> On Thu, Jul 17, 2014 at 11:33 AM, Borzh <borz...@gmail.com> wrote: >>>>>>>> > Hello all, >>>>>>>> > >>>>>>>> > I propose using template functions in minmax.h instead of defines. >>>>>>>> > Or at >>>>>>>> > least use uppercase letters for macros. >>>>>>>> > >>>>>>>> > It has been discussed a lot of times: >>>>>>>> > - windows.h defines min/max, it is ugly, ok but I thought Valve is >>>>>>>> > not >>>>>>>> > Microsoft. At least for Windows you can #define NOMINMAX before >>>>>>>> > include >>>>>>>> > windows.h. >>>>>>>> > >>>>>>>> > - Valve's minmax.h defines min/max and you can't use STL because >>>>>>>> > it tries to >>>>>>>> > apply macros to std::min and std::max which breaks everything!!! >>>>>>>> > Can't avoid >>>>>>>> > it, because Valve use this macros everywhere!!! >>>>>>>> > >>>>>>>> > If someone from Valve is reading this, please do something, it is >>>>>>>> > awful !!! >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Boris. >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > To unsubscribe, edit your list preferences, or view the list >>>>>>>> > archives, >>>>>>>> > please visit: >>>>>>>> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> To unsubscribe, edit your list preferences, or view the list >>>>>>>> archives, please visit: >>>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> To unsubscribe, edit your list preferences, or view the list >>>>>>> archives, please visit: >>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -Tony >>>>>> >>>>>> _______________________________________________ >>>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>>> please visit: >>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>>> >>>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>> >>> >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
