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 42726
To read all comments associated with this story, please click here.
Re: More Blah
by rajj on Mon 10th Oct 2005 19:48 UTC
rajj
Member since:
2005-07-06

What it sounds like you're saying is, "Gee, if everyone just wrote their programs for x runtime, everything would be peachy." Isn't that the same as arguing that everyone just write for x hardware architecture, and that will solve all portablity problems?

I don't think moving the portablity problem from hardware to x virtual machine is a silver bullet. It just moves the problem somewhere else. Porting VMs is sometimes more difficult than just porting the program that would have run on it on the first place.

Endiness isn't that big of a problem. You have what: two possibilities? Most portability problems in C result from misuse/understanding of types or making broad assumptions.

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.

Now, don't go on a flame fest just yet. I don't advocate using C for large application programs. I'm definately in the python/lisp camp; however, I don't blame C for begin deficient for features (or the lack of them) that were specifically meant to model the hardware closely. Richie wasn't a moron after all.

Reply Score: 1

RE: Re: More Blah
by stew on Mon 10th Oct 2005 20:00 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[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[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

RE: Re: More Blah
by ma_d on Mon 10th Oct 2005 20:03 in reply to "Re: More Blah"
ma_d Member since:
2005-06-29

Well, I believe things like strcat are defined in ansi c, and they use null terminated strings.
However, most of the ansi-c libs are tiny and pretty easy to rewrite. So yea, you could certainly define your own string struct and libs to deal with it.

I think if you're having an endiness problem, well, QUIT USING THE SHIFT OPERATOR; or prepare to write that code over for every platform (not that big a deal).

Reply Parent Score: 1