[Proposal] Add module for C-strings support in Phobos

[Rikki Cattermole]

On Thursday, 20 March 2014 at 09:32:33 UTC, Denis Shelomovskij 
wrote:
> 20.03.2014 13:20, Rikki Cattermole пишет:
>> On Thursday, 20 March 2014 at 08:24:30 UTC, Denis Shelomovskij 
>> wrote:
>>> It's filed as enhancement 12418 [2]:
>>>
>>> C-strings processing is a special and common case so:
>>> 1. C-strings should be supported with both performance and 
>>> usability.
>>> 2. There should be a dedicated module for C-strings (instead 
>>> of adding
>>> such functions here and there in other modules).
>>>
>>> Current state: there is no good support for C-strings in 
>>> Phobos, there
>>> is slow and broken `toStringz` (Issue 12417 [3]), and no 
>>> standard way
>>> to make many common operations, like converting returned 
>>> C-string to
>>> string and releasing its memory or creating a C-string from 
>>> string
>>> using an allocation function.
>>>
>>> So I propose to add `unstd.c.string` [1] module to Phobos 
>>> which
>>> include all use-cases I have seen implementing (correct and 
>>> fast in
>>> contrast to existing ones like GtkD (yes, it's both incorrect 
>>> and slow
>>> because of tons of GC allocations)) C library wrappers.
>>>
>>>
>>> [1] 
>>> http://denis-sh.bitbucket.org/unstandard/unstd.c.string.html
>>> [2] https://d.puremagic.com/issues/show_bug.cgi?id=12418
>>> [3] https://d.puremagic.com/issues/show_bug.cgi?id=12417
>>
>> Looks like it wouldn't be really useful with Windows API. 
>> Given that
>> wstrings are more common there.
>
> You misunderstand the terminology. C string is a 
> zero-terminated string. Also looks like you didn't even go to 
> docs page as the second example is WinAPI one.
I understand how c strings work. It would be nice to have more 
unittests for dstring/wstring, because it looks more geared 
towards char/string. Which is why it looks on the offset that it 
is less going to work.

>> Another thing that would be nice to have is a wrapper struct 
>> for the
>> pointer that allows accessing via e.g. opIndex and opSlice. 
>> Ext.
>> Use case: Store the struct on D side to make sure GC doesn't 
>> clean it up
>> and still be able to access and modify it like a normal string 
>> easily.
>
> I don't understand the use-case. If you did implemented some C 
> library wrappers and have a personal experience, I'd like to 
> hear your opinion on C functions calling problem and your 
> proposal to solve it, if you dislike mine. Also with examples, 
> please, where my solution fails and your one rocks. )

I don't dislike your approach at all. I just feel that it needs 
to allow for a little more use cases. Given the proposal is for 
phobos.

What you have done looks fine for most cases to c libraries. I'm 
just worried that it has less use cases then it could have.
I'm just nitpicking so don't mind me too much :)