Linked by Eugenia Loli on Mon 10th Oct 2005 16:48 UTC, submitted by Shlomi Fish
Permalink for comment 42726
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



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.