Hacker News Reader

I actually prefer the inline function here (while making the member char* private when compiling as C++), since that mostly prevents assignment to the member variable in settings where that would not be a valid operation.

With that said, I agree that the additional verbosity is a significant drawback, and I can understand going with the slightly-less-safe option for that reason alone.

View on HN

Ah, that’s a good point. I’m a fan of extra safety, though we’d need to make a few extra changes to get around C’s lack of private variables: We could make the internal member instead a size_t, and cast to pointer form when needed inside the library or when converting via this inline function (which is still a no-op in terms of performance). The only major downside then remaining is perhaps syntax/verbosity, which IMO is secondary to safety.

However: If we open the discussion up to C++, then this is pretty easy to solve without any real syntactic or performance compromise: we can make a class/struct which defines implicit conversions to C strings, and disables any implicit conversions from C strings.

Good point about implicit conversions; I may actually be able to use that to clean up some code in the near future.

Reply on news.ycombinator.com