Linked by Eugenia Loli on Mon 10th Oct 2005 16:48 UTC, submitted by Shlomi Fish
General Development Shlomi Fish has written a new essay titled "When C is the Best? (Tool for the Job)". Its theme is giving several reasons (besides high speed and low memory consumption) why some code should still be written in C.
Thread beginning with comment 42736
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Re: More Blah
by stew on Mon 10th Oct 2005 20:00 UTC in reply to "Re: More Blah"
stew
Member since:
2005-07-06

Endiness isn't that big of a problem. You have what: two possibilities?

And why on earth would I want to use a language that lets the programmer deal with it instead of doing it itself? I can't think of any situation where as a programmer you would want to have the endianess differences exposed to your programs (not even in drivers). Just make everything be big endian in source code level and let the compiler figure out how put that in machine language.

Also, null terminated byte arrays are a library convention. It's not a language feature. If you want to manipulate unicode, use the proper library.

So, no portable strings in C? It's only portable when I rely on the standard C library, which uses null-terminated strings. When I have to rely on other libraries, I lose the (supposed) portability.

Reply Parent Score: 1

RE[2]: Re: More Blah
by corentin on Mon 10th Oct 2005 20:21 in reply to "RE: Re: More Blah"
corentin Member since:
2005-08-08

> Just make everything be big endian in source code level and let the compiler figure out how put that in machine language.

And how do you "make everything be big endian", exactly? :-)

Reply Parent Score: 1

RE[3]: Re: More Blah
by stew on Mon 10th Oct 2005 21:19 in reply to "RE[2]: Re: More Blah"
stew Member since:
2005-07-06

> And how do you "make everything be big endian", exactly?

Have the compiler "correct" my bit-shifts and char* casts automatically on little-endian platforms. Having not to deal with machine-specific issues and not having to reinvent the wheel for string operations is the whole point of why one would want to use a high-level language instead of assembly.

I don't see how you can call a language "portable" in which the exact source code can returns different results on PPC and x86, even when compiled with the same compiler. And if you think endianess issues never happen, then you have never dealt with UTF16, raw PCM audio or bitmap data.

Reply Parent Score: 1

RE[2]: Re: More Blah
by corentin on Mon 10th Oct 2005 20:39 in reply to "RE: Re: More Blah"
corentin Member since:
2005-08-08

> So, no portable strings in C? It's only portable when I rely on the standard C library, which uses null-terminated strings. When I have to rely on other libraries, I lose the (supposed) portability.

If you change an API, I have to admit it is quite hard not to change the program...

Reply Parent Score: 1

RE[2]: Re: More Blah
by rhavyn on Mon 10th Oct 2005 23:04 in reply to "RE: Re: More Blah"
rhavyn Member since:
2005-07-06

And why on earth would I want to use a language that lets the programmer deal with it instead of doing it itself? I can't think of any situation where as a programmer you would want to have the endianess differences exposed to your programs (not even in drivers).

You're going to want endianess differences exposed whenever you're dealing with a binary encoding. This includes various binary encodings for network protocols, video and audio encodings and even the bytecode which a JVM or .Net runtime needs to decode. If the compiler automatically enforced the endianess of the hardware (and some hardware allows you to change the endianess, what then?) how would you go about encoding or decoding such binary protocols?

Besides encoding and decoding binary protocols, when would a programmer even worry about endian issues anyways? I can't think of one time that I was actually bothered by that in normal application code.

Reply Parent Score: 1

RE[3]: Re: More Blah
by stew on Tue 11th Oct 2005 01:54 in reply to "RE[2]: Re: More Blah"
stew Member since:
2005-07-06

> If the compiler automatically enforced the endianess of the hardware how would you go about encoding or decoding such binary protocols?

The way you would do it on any big endian machine.

>(and some hardware allows you to change the endianess, what then?)

Are you talking about the PPC? Besides the fact that I have never ever seen any reason why you would want to do that during the runtime of a program, you'd usually have to write separate code for such cases - when your compiler abstracts that, the compiler would just to what the PPC itself does - Wikipedia tells me that "in Little-Endian mode, the three lowest-order bits of the effective address are exclusive-ORed with a three bit value selected by the length of the operand". If you really need to switch the target platform in the middle of the code (is there any compiler that supports that at all?), you'd have to introduce pragmas anyway.

Reply Parent Score: 1

RE[2]: Re: More Blah
by on Wed 19th Oct 2005 01:16 in reply to "RE: Re: More Blah"
Member since:

And why on earth would I want to use a language that lets the programmer deal with it (snip)

Any C programmer worth her salt would use htons/ntohs/htonl/ntohl when endianness is an issue. In practice, it rarely is.

Reply Parent Score: 0