--- Comment #6 from 2011-07-01 07:19:12 PDT ---
(In reply to comment #5)
> 1. It only helps if you're actually keeping zero-terminated strings around,

You just call the function nested:


Hiding CcharPtr inside toStringz2 seems useful to avoid the mistake of using
just CcharPtr(someCharPointer):

auto toStringz2(string s) {
    static struct CcharPtr {
        const char* ptr;
        alias ptr this;

    return CcharPtr(toStringz(s));

// example of C function
extern(C) size_t strlen(ReturnType!toStringz2 str);

You are also free to add a wrapper, for the cases where you are sure to already
have a zero terminated C string.

> 2. Even if your suggestion does help prevent bugs, _none_ of the C functions 
> in
> druntime are going to be declared to use CcharPtr,

Who knows :-)

> so it doesn't help at all
> unless you're declaring a bunch of C declarations yourself.

If you are writing a wrapper for a C library I think the improved safety is
worth the effort of writing:

extern(C) size_t foobar(ReturnType!toStringz2 str1, ReturnType!toStringz2

instead of:

extern(C) size_t foobar(const char* str1, const char* str2);

The work involved to write this is not significant.

> There are plenty of suggestions which could be given to improve code quality.
> That doesn't mean that they belong in the standard library's documentation. If
> there were some sort of page with tips for D programmers, then perhaps it 
> could
> go there, but I really don't think that it has any business going in the
> standard docs.

Even if this idea of toStringz2 is not so good and people will want to close
down this enhancement suggestion, I like the general idea of showing and
suggesting good idioms in the standard library. Delphi, Python and Ruby (and
maybe PHP too) libraries do it and I have appreciated this. Just a list of
functions and classes is not enough. You have to show how to use things well,

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to