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

[Denis Shelomovskij]

20.03.2014 13:52, 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.

I'd say must unittests do test UTF-16 & UTF-32 versions. As for 
documentation, function signatures contain template parameter for 
character but probably there is a lack of ddoc unittests and/or 
documentation.

>
>>> 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 :)

Thanks. So the algorithm is like this: find C library which needs more 
love and file me an issue [1]. As I just added all common use-cases I 
have seen.

[1] https://bitbucket.org/denis-sh/unstandard/issues

-- 
Денис В. Шеломовский
Denis V. Shelomovskij