Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Stricks – managed C strings library

github.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Show HN: Stricks – managed C strings library

#11

Post by gkfasdfasdf »

wheybags wrote: post #9
gkfasdfasdf wrote: post #7

There is a key difference in the 'long way' and 'stricky way' example in the readme - the 'long way' doesn't do any allocations and thus has a performance advantage out of the box. Also, where in the 'stricky way' does page get freed? This also needs to be shown in order to be equivalent to the 'long way'.

If you look later on at the readme, you'll see that the stx_catf function does not reallocate, it truncates, there is another function for reallocating append. That said, I don't really see why one would need such a no-realloc function. In c++, I would just use std::string::reserve(some_big_num).

stx_new allocates the string, per the readme.

My point is that the readme example is misleading, as the two code samples are not equivalent.

Re: Show HN: Stricks – managed C strings library

#12

Post by alcover »

wheybags wrote: post #10
alcover wrote: post #2

Dear HN, I fell in love with C, but strings stand between us. So I made this lib. It's certainly more experimental than 'industrial strength', but I learned a great deal and intend to make it a solid useful tool. In the mean time, quite thorough unit tests ensure we don't go astray. Also, I tried to produce the cleanest code I could, to please the reader. A few questions : 0- Is my header layout foolproof and portabl…

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 see…

Thank 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

Re: Show HN: Stricks – managed C strings library

#13

Post by alcover »

gkfasdfasdf wrote: post #11
wheybags wrote: post #9

Earlier quoted context omitted.

If you look later on at the readme, you'll see that the stx_catf function does not reallocate, it truncates, there is another function for reallocating append. That said, I don't really see why one would need such a no-realloc function. In c++, I would just use std::string::reserve(some_big_num).

stx_new allocates the string, per the readme. My point is that the readme example is misleading, as the two code samples are not equivalent.

You are right, I changed it to malloc.

This 'long way' thing is definitly not super useful..

Re: Show HN: Stricks – managed C strings library

#15

Post by peter_d_sherman »

alcover wrote: post #5
peter_d_sherman wrote: post #4

Earlier quoted context omitted.

>I fell in love with C, but strings stand between us. So I made this lib. You and me both! You'd like Pascal's strings, most notably those of Delphi/FreePascal -- the standard string type in those languages contains the length of the string before the pointer to the string (out-of-band signalling as opposed to in-band signalling as C's standard strings are, with a zero marking their end) -- much like your string impl…

> in-band signalling as C's standard strings Neat analogy ! > reference count ... copies ... only then is StringB copied You're right I should - and will - use this. But note it won't cover cases where the user modifies/copies the string from outside the API. The lib won't be aware. > your idea is conceptually brilliant! Oh I wish the neg offset header was my invention ! Alas it was at least used in Microsoft' BSTR a…

>> reference count ... copies ... only then is StringB copied

>You're right I should - and will - use this. But note it won't cover cases where the user modifies/copies the string from outside the API. The lib won't be aware.

But that's perfectly OK! Just explain any and all caveats/gotchas/potential issues -- to the end-user in the docs, and they'll understand and work around them! Most programmers are smart people, and they'll be totally OK with it if you explain those things to them in the docs!

>> no nested macros

>I hear you. I thought it made them more readable.

The macros DO make the code more readable(!) -- at least the non-nested ones!

The nested ones are kind of OK, and yes, they kind of make the code more readable -- but in exchange for this readability, you're getting farther and farther away from the underlying generated C code!

That's OK to a point -- but I've seen codebases where they've went N levels (not 1, not 2, but multiple, multiple) levels deep on the macros -- and what was gained in early macro readability -- gets lost in massively recursive macro hierarchies!

For your future sanity, try to avoid going in that direction!

Like, maybe set a limit of no more than two, two being the absolute maximum, and only if you really really need to do it -- levels of macros...

Because the temptation is going to be (at least in the future!) -- to use even more levels of macros!

That'll work great for a while (it's a double-edged sword!)... but at some point, a deeply nested structure can really, and I mean really bite you in the butt -- with hard-to-find bugs and anomalies, when you least expect it, and when you most need it to work!

But again, all of this being said, "I am not the market".

You might find that 1,000,000 plus C programmers -- absolutely love what you've done with the nested macros, and if so, I say "go with it!" (at least, if appealing to a broad base is your goal, and the broad base wants things done that way!)

But, all of this being said, you choose an excellent problem to solve, and you put in an excellent effort, and I applaud your work!

Post reply on HN