The more interesting question

Marco Leise Marco.Leise at gmx.de
Wed May 23 21:53:41 PDT 2012


Am Tue, 15 May 2012 20:23:53 +0200
schrieb Timon Gehr <timon.gehr at gmx.ch>:

> On 05/15/2012 10:39 AM, deadalnix wrote:
> > Le 14/05/2012 19:38, Alex Rønne Petersen a écrit :
> >> [...]
> >> That being said, dropping the null-termination rule when passing strings
> >> to non-const(char)* parameters/variables/etc would be sane enough (I
> >> think).

I thought the same.

> > This looks to me like a bad practice. C string and D string are
> > different beasts, and we have toStringz .

When we talk about literal strings they can be both.
void foo(const(char)*) will turn a string literal into a '\0'-terminated C string.
void foo(string) will use D string (slices).
It is a special case for C interop. There may already be a few others in the language.

> It is not. Claiming valid use cases are bad practice does not help the 
> discussion. It is disrespectful and patronising.

Alex' use case of this feature:
	void log(string text) {
		printf(text);
	}
made me think the same: "That's a bad idea...". This runs against a D programmer's understanding of a string as a pointer and length without explicit termination. If you just had this in mind:
	printf("abc");
that looks kosher.

> > It is kind of dumb to create a WAT is the language because druntime dev
> > did mistakes.

Yes, let's have zero appended when literals are used as char* parameters.
I just greped druntime for [f]printf and except for one ternary operator and one (tbuf.ptr, tbuf.length, ...) the format specifiers were all literals. No concatenations and slicing (thank god ;) ) or lookups and storage in a string before use. If these 759 printf statements reflect the general case, then there should be no problem with the proposal. (The one use of the ternary operator can probably be changed to an if-else.)

> The conclusion is based on a wrong premise therefore it is meaningless.
> 
> > It have to be fixed.
> 
> It can be fixed better by making (null !is []) hold instead of making 
> ("" is null) hold.

It's easy. Revert to 2.057. I agree with you, but I'm ignorant to the reasons behind the change. It could have meant an allocation for empty arrays (the way it was implemented in 2.057) or that the GC cannot collect a large memory block because a slice of length 0 is holding a reference to it.

-- 
Marco



More information about the Digitalmars-d mailing list