5 ms·
Hey, nice project, overall looks pretty useful. I have a question, and also some feedback (from the point of view of a mostly C++ programmer, who has some knowl
by wheybags 6y ago
Hey, nice project, overall looks pretty useful.
I have a question, and also some feedback (from the point of view of a mostly C++ programmer, who has some knowledge of C by osmosis).
Why did you choose to use a char* typedef with a magic "header before" in the alloc, instead of just padding around the header struct? You get some marginal convenience when passing it into an api that expects a char, but it doesn't seem worth it when you consider that you won't get type warnings if you try to use a char where you expected an stx_t. (My understanding is that unlike C++, C compilers will generally allow wrong-pointer-types, but you can turn on warnings for it).
I think the stx_load function is a bit out of place, this doesn't seem like it should be a string library's responsibility. There is also the added issue that passing a char* in as a filepath is not suitable for windows. You (generally, there are other ways) need to use a wide char string on windows for file I/O, to handle non-ascii characters.
I'm also not sold on the usefulness of having an append function that can't reallocate. I have never wanted this, and if I did, I could emulate it with a reallocating version by just manually truncating the copy to the current capacity.
As for licensing commercially, I don't think that's likely to work out really. It is a useful project for sure, but I think it's just a bit too small to justify buying it. Most C programmers would probably prefer to write their own instead.
- alcover 6y agoThank you > marginal convenience(...) you won't get type warnings The aliasing of char* permits the user to directly use all his string-read tools. I'm not super convinced myself it's the right design choice though but it sure is convenient. The alternative would force him using Header->str every time he wants access to the real string. Yes, there is no real type safety. The user has to be conscious. But he'll be warned by stx_t being const if he ever uses out-of-API writers. > stx_load function is a bit out of place I agree. It's a bit hard to know where to stop... > not sold on the usefulness of having an append function that can't reallocate For constrained/embedded environments ? Or just a socket buffer. > I could emulate it with a reallocating version by just manually truncating the copy to the current capacity. That would be much slower I think. > Most C programmers would probably prefer to write their own instead That's not good news haha