[HN Gopher] An informal comparison of the three major implementa...
       ___________________________________________________________________
        
       An informal comparison of the three major implementations of
       std:string
        
       Author : tyoma
       Score  : 74 points
       Date   : 2024-05-10 17:51 UTC (5 hours ago)
        
 (HTM) web link (devblogs.microsoft.com)
 (TXT) w3m dump (devblogs.microsoft.com)
        
       | kingsleyopara wrote:
       | Obligatory link to a must watch, the CppCon 2016 talk on the
       | complexities of std::string:
       | https://youtu.be/kPR8h4-qZdk?si=x2DbgNIZcKyK5PKt
        
       | gte525u wrote:
       | Somewhat related - but there are a ridiculous number of
       | platform/systems that ship with derivative of Dinkum C++ standard
       | library - MSVC (included). When you lookup the company behind it
       | - it's basically small shop that seems to be primarily one guy up
       | in MA.
        
         | rqtwteye wrote:
         | That one guy has been at it for a very long time. I remember
         | buying Dinkum around 2000.
        
       | archermarks wrote:
       | Nice article, thanks for sharing! Been implementing my own string
       | type for fun recently and this is a useful reference!
        
       | blt wrote:
       | This is great. It would be a good C/C++ interview question to
       | compare these. Of course you can't expect a Raymond Chen level
       | performance, but it should give some insight into experience with
       | low level programming.
        
       | ajross wrote:
       | tl;dr: libc++ is just bad, libstdc++ and MSVC trade punches for
       | first place, with the eyeball win going to the FSF.
       | 
       | Though really the performance gates on string-heavy code tend to
       | be in the heap and not the string library itself.
        
       | whoopdedo wrote:
       | GCC putting a pointer at the top of the structure seems
       | reminiscent of the way Pascal stored strings. A PString is the
       | address of a character buffer like C, but the length of the
       | string is stored at a negative offset. I may be remembering wrong
       | but I think there was an older C++ STL that also used negative
       | offsets.
       | 
       | As much as these snippets make clang look heavier, I wonder what
       | it compiles to in practice when the compiler can make better
       | inferences. If you can prove the state of the `is_small` bit
       | those branches disappear. Even at runtime, which implementation
       | is more performant? Real-world profiling may favor clang with
       | branch prediction and speculative processing. Then again,
       | speculation has become a dirty word lately.[1]
       | 
       | [1] Get it? "Dirty" because of the cache. I'm sorry, that pun was
       | entirely unintentional.
        
       | dataflow wrote:
       | The most interesting thing imo is what they all do similarly:
       | they all store the size, instead of the end pointer -- unlike,
       | say, std::vector. Exercise for the reader as to why this is the
       | right tradeoff.
        
       ___________________________________________________________________
       (page generated 2024-05-10 23:01 UTC)