Open Hejsil opened 5 years ago
This makes sense to me for several reasons:
\0
Another thing that would be nice with this change would be if all sizes where of type size_t
. This also makes interfacing certain safer languages simpler (I can avoid an @intCast
in Zig). It is also semantically more correct as I assume there is no way a length would ever be negative. strlen
also returns size_t
:)
One small con with such a change would be that C defines behavior for unsigned int overflows but signed int overflow is undefined. Operations on signed integers can optimize better because of this.
Personally i don't see any reasons to not use null terminated strings. They are simple and fit very well as this is simple C gui library. No reasons to overcomplicate it.
Personally i don't see any reasons to not use null terminated strings.
There is one. And it's very important one. Bindings to other languages. Nowadays "nobody" is writing GUIs in C. But libraries are written in C because of easy interoperability. And so is Nuklear.
No reasons to overcomplicate it.
Feel free to design a better solution conforming to the above mentioned requirement.
C null terminated string is a standard. Every programming language has utilities for interoperability with it. I'm using Nuklear with Dlang and there's no pain with its API at all. You don't insist to rewrite windows API for example, isn't it?
Every programming language has utilities for interoperability with it.
They do, but as you said with "having utilities". That's just a nice way of saying they don't support null-terminated buffers/strings as first class citizens. And I fully agree.
You don't insist to rewrite windows API for example, isn't it?
I don't follow - Nuklear has nothing to do with Windows API.
As discussed in #890