On Sunday, 15 August 2021 at 08:53:50 UTC, Tejas wrote:

Yeah, yeah I got that. My question is, if I should avoid cast(char*) and use .toStringz while both do the exact same thing?

On Sunday, 15 August 2021 at 08:56:07 UTC, rempas wrote:

They don't do the same thing. toStringz always copies, always GC-allocates, and always NUL-terminates. cast(char*) only does what you want in the case that you're applying it a string literal. But in that case you shouldn't cast, you should just

const char* s = "John";

If you need cast cast the const away to work with a C API, doing that separately, at the point of the call to the C function, makes it clearer what you're doing and what the risks are there (does the C function modify the string? If so this will segfault).

On Sunday, 15 August 2021 at 08:11:39 UTC, rempas wrote:

The D string is an alias for immutable(char)[], immutable contents of a mutable array reference (immutable(char[]) would mean the array reference is also immutable). You don't want to assign that to a char*, because then you'd be able to mutate the contents of the string, thereby violating the contract of immutable. (immutable means the data to which it's applied, in this case the contents of an array, will not be mutated through any reference anywhere in the program.)

Assigning it to const(char)* is fine, because const means the data can't be mutated through that particular reference (pointer in this case). And because strings in C are quite frequently represented as const(char)*, especially in function parameter lists, D string literals are explicitly convertible to const(char)* and also NUL-terminated. So you can do something like puts("Something") without worry.

This blog post may be helpful:

https://dlang.org/blog/2021/05/24/interfacing-d-with-c-strings-part-one/

On Sunday, 15 August 2021 at 09:01:17 UTC, jfondren wrote:

const char* s = "John";

Yeah I won't cast when having a const char*. I already mentioned that it works without cast with const variables ;)

On Sunday, 15 August 2021 at 09:06:14 UTC, Mike Parker wrote:

Thanks a lot for the info!

On 8/15/21 2:10 AM, rempas wrote:

Lots of great responses in this thread!

I wanted to stress that a string literal is sort of magic. It has extra type information inside the compiler that is not available in the normal type system. Namely that "this is a literal, and so can morph into other things".

To give you some examples:

string s = "John";
immutable(char)* cs = s; // nope
immutable(char)* cs2 = "John"; // OK!
wstring ws = s; // nope
wstring ws2 = "John"; // OK!

What is going on? Because the compiler knows this is a string literal, it can modify the type (and possibly the data itself) at will to match what you are assigning it to. In the case of zero-terminated C strings, it allows usage as a pointer instead of a D array. In the case of different width strings (wstring uses 16-bit code-units), it can actually transform the underlying data to what you wanted.

Note that even when you do lose that "literal" magic by assigning to a variable, you can still rely on D always putting a terminating zero in the data segment for a string literal. So it's valid to just do:

string s = "John";
printf(s.ptr);

As long as you know the string came from a literal.

-Steve