[HN Gopher] Making a StringBuffer in C, and questioning my sanity
       ___________________________________________________________________
        
       Making a StringBuffer in C, and questioning my sanity
        
       Author : coneonthefloor
       Score  : 20 points
       Date   : 2025-07-15 10:48 UTC (3 days ago)
        
 (HTM) web link (briandouglas.ie)
 (TXT) w3m dump (briandouglas.ie)
        
       | ranger_danger wrote:
       | You might be interested in https://github.com/antirez/sds
        
         | fsckboy wrote:
         | neat, i like it, has some of the same ideas i've used in my
         | string packages
         | 
         | but i did see a place to shave a byte in the sds data struct.
         | The null terminator is a wasted field, that byte (or int)
         | should be used to store the amount of free space left in the
         | buffer (as a proxy for strlen). When there is no space left in
         | the buffer, the free space value will be.... a very convenient
         | 0 heheh
         | 
         | hey, OP said he wants to be a better C programmer!
        
           | ranger_danger wrote:
           | > The null terminator is a wasted field
           | 
           | I think that would break its "Compatible with normal C string
           | functions" feature.
        
       | improgrammer007 wrote:
       | I would rather focus on solving the main problem than reinvent
       | the wheel. Just use C++ if perf is critical which gives you all
       | these things for free. In this day and age the reasons for using
       | C as your main language should be almost zero.
        
       | o11c wrote:
       | Hm, this implementation seems allergic to passing types by value,
       | which eliminates half of the allocations. It also makes the
       | mistake of being mutable-first, and provides some fundamentally-
       | inefficient operations.
       | 
       | The main mistake that this makes in common with _most_ string
       | implementations make is to only provide a single type, rather
       | than a series of mostly-compatible types that can be used
       | generically in common contexts, but which differ in ways that
       | sometimes matter. Ownership, lifetime, representation, etc.
        
         | remexre wrote:
         | How would you recommend doing that sort of "subtyping"?
         | _Generic and macros?
        
         | amelius wrote:
         | I wonder how an LLM would rate this code.
        
       ___________________________________________________________________
       (page generated 2025-07-18 23:01 UTC)