Some Were Meant for C (2017) [pdf]

Re:Some Were Meant for C (2017) [pdf] by Nursie on Thursday April 25, 2019 @06:45AM (#19746741)

To be fair it doesn't really have strings 'built in' particularly well either. It directly manipulates memory patches, and the string support that is there is mostly a very simple abstraction on that.

If you want support for unicode etc, there are libraries.

[ Parent | on HN ]

Re:Some Were Meant for C (2017) [pdf] by solarkraft on Thursday April 25, 2019 @08:38AM (#19747395)

But then that brings you compatibility issues, overhead ...

[ Parent | on HN ]

Re:Some Were Meant for C (2017) [pdf] by Nursie on Thursday April 25, 2019 @09:22AM (#19747767)

If you want to avoid development overhead, absolutely, C is a terrible language to pick.

I'm not sure what you mean by compatibility issues in this context?

[ Parent | on HN ]

Re:Some Were Meant for C (2017) [pdf] by solarkraft on Friday April 26, 2019 @11:08AM (#19758284)

I'm thinking about differen string representations used by different libraries. Is this not true?

[ Parent | on HN ]

Re:Some Were Meant for C (2017) [pdf] by Nursie on Friday April 26, 2019 @12:29PM (#19759234)

Honestly all I've encountered default strings (and people shy away from those now) and LibICU stuff. I think ICU has become a defacto standard but I have been out of C for a few years.

This tends to be important for strings you're going to show to the user (or input you gather from them), maybe most of the C in the world isn't aimed at interfaces like that...

[ Parent | on HN ]