On Sun, Jan 29, 2012 at 06:23:33PM -0800, Walter Bright wrote: [...]
> C has varying size for builtin types and fixed size for aliases. D is just the reverse - fixed builtin sizes and varying alias sizes.  My experience with both languages is that D's approach is far superior.

I agree. It's not perfect, but it definitely beats the C system.


> C's varying sizes makes it clumsy to write portable numeric code, and the varying size of wchar_t is such a disaster that it is completely useless - the C++11 had to come up with completely new basic types to support UTF.

Not to mention the totally non-commital way the specs were written about wchar_t: it *could* be UTF-16, or it *could* be UTF-32, or it *could* be a non-unicode encoding, we don't guarantee anything. Oh, you want Unicode, right? Well for that you need to consult your OS-specific documentation on how to set up 15 different environment variables, all of which have non-commital descriptions, and any of which may or may not switch the system into/out of unicode mode. Oh, you want a function to guarantee unicode mode? We're sorry, that's not our department.

Yeah. Useless is just about right. It's almost as bad as certain parts of the IPMI spec, which I had the misfortune to be given a project to code for at my day job once.


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On 1/29/2012 6:46 PM, H. S. Teoh wrote:
> Not to mention the totally non-commital way the specs were written about
> wchar_t: it *could* be UTF-16, or it *could* be UTF-32, or it *could* be
> a non-unicode encoding, we don't guarantee anything. Oh, you want
> Unicode, right? Well for that you need to consult your OS-specific
> documentation on how to set up 15 different environment variables, all
> of which have non-commital descriptions, and any of which may or may not
> switch the system into/out of unicode mode. Oh, you want a function to
> guarantee unicode mode? We're sorry, that's not our department.


I've had people tell me this was an advantage because there are some chips where chars, shorts, ints, and wchars are all 32 bits. Isn't it awesome that the C standard supports that?

The only problem with that is that while the C standard supports it, I can't think of a single C program that would work on such a system without a major, and I mean major, rewrite. It's a useless facet of the standard.

On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote:
> On 1/29/2012 6:46 PM, H. S. Teoh wrote:
> >Not to mention the totally non-commital way the specs were written about wchar_t: it *could* be UTF-16, or it *could* be UTF-32, or it *could* be a non-unicode encoding, we don't guarantee anything. Oh, you want Unicode, right? Well for that you need to consult your OS-specific documentation on how to set up 15 different environment variables, all of which have non-commital descriptions, and any of which may or may not switch the system into/out of unicode mode. Oh, you want a function to guarantee unicode mode? We're sorry, that's not our department.
> 
> 
> I've had people tell me this was an advantage because there are some chips where chars, shorts, ints, and wchars are all 32 bits. Isn't it awesome that the C standard supports that?
> 
> The only problem with that is that while the C standard supports it, I can't think of a single C program that would work on such a system without a major, and I mean major, rewrite. It's a useless facet of the standard.

I can just see all those string malloc()'s screaming in pain as buffer overflows trample them to their miserable deaths:

	void f(int length) {
		char *p = (char *)malloc(length); /* yikes! */
		int i;
		for (i=0; i < length; i++) {
			/* do something with p[i] ... */
		}
		...
	}

Is there an actual, real, working C compiler that has char sized as anything but 8 bits?? This one thing alone would kill, oh, 99% of all C code?


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

On 1/29/2012 8:21 PM, H. S. Teoh wrote:
> On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote:
>> I've had people tell me this was an advantage because there are some
>> chips where chars, shorts, ints, and wchars are all 32 bits. Isn't it
>> awesome that the C standard supports that?
> Is there an actual, real, working C compiler that has char sized as
> anything but 8 bits?? This one thing alone would kill, oh, 99% of all C
> code?

Yes. Those chips exist, and there are Standard C compilers for them. But every bit of C code compiled for them has to be custom rewritten for it.

On Sun, Jan 29, 2012 at 09:24:48PM -0800, Walter Bright wrote:
> On 1/29/2012 8:21 PM, H. S. Teoh wrote:
> >On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote:
> >>I've had people tell me this was an advantage because there are some chips where chars, shorts, ints, and wchars are all 32 bits. Isn't it awesome that the C standard supports that?
> >Is there an actual, real, working C compiler that has char sized as anything but 8 bits?? This one thing alone would kill, oh, 99% of all C code?
> 
> Yes. Those chips exist, and there are Standard C compilers for them. But every bit of C code compiled for them has to be custom rewritten for it.

Interesting. How would D fare in that kind of environment, I wonder? I suppose it shouldn't be a big deal, since you have to custom rewrite everything anyways -- just use int32 throughout.


T

-- 
Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted.

On 1/29/2012 10:39 PM, H. S. Teoh wrote:
> Interesting. How would D fare in that kind of environment, I wonder? I
> suppose it shouldn't be a big deal, since you have to custom rewrite
> everything anyways -- just use int32 throughout.

You could write a custom D compiler for it.