search for: eastl

...a historical problem? Compilers have gotten much better about > inlining stuff that is actually small, if Clang handles it then I think > we're good. Marking these attribute(always_inline) is massive overkill. > > Well, it is historical from about 5 years ago when I was working on EASTL. The compilers we were using at the time were gcc and MSVC. We found cases in the standard STL where inlines were nested up to 10 levels deep, and in some of those cases the compiler just gave up trying to inline things that deeply. > Overall the code is looking great. I'd recommend check...

...is this a historical problem? Compilers have gotten much better about inlining stuff that is actually small, if Clang handles it then I think we're good. Marking these attribute(always_inline) is massive overkill. > > Well, it is historical from about 5 years ago when I was working on EASTL. The compilers we were using at the time were gcc and MSVC. We found cases in the standard STL where inlines were nested up to 10 levels deep, and in some of those cases the compiler just gave up trying to inline things that deeply. Ok, LLVM uses a completely different (bottom-up, incremental, sim...

On Feb 17, 2012, at 12:26 AM, Talin wrote: > OK here's a patch with the latest, including unit tests. I've also tried to make the comments clear that this is intended for the case of "generic" key types, where you are either hashing multiple data types together, or you don't know in advance what the data type will be - for cases such as strings where a tailored algorithm

OK here's a patch with the latest, including unit tests. I've also tried to make the comments clear that this is intended for the case of "generic" key types, where you are either hashing multiple data types together, or you don't know in advance what the data type will be - for cases such as strings where a tailored algorithm is available, you should use that instead of