C Portability

This is a discussion on C Portability within the General Discussions forums, part of the Community Boards category; I know C is sometimes called a portable assembler but exactly how portable is it? Are there any systems where ...

  1. #1
    The Registered User Aparavoid's Avatar
    Join Date
    May 2009
    Posts
    74

    C Portability

    I know C is sometimes called a portable assembler but exactly how portable is it? Are there any systems where the low levelness of C is bad because the system doesn't deal with memory(or something else) the same way C does? Would a language that doesn't directly deal with memory, like Scheme, be more portable or about the same?

  2. #2
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,403
    Quote Originally Posted by Aparavoid View Post
    I know C is sometimes called a portable assembler but exactly how portable is it? Are there any systems where the low levelness of C is bad because the system doesn't deal with memory(or something else) the same way C does? Would a language that doesn't directly deal with memory, like Scheme, be more portable or about the same?
    C is highly portable. It can be be used to program PIC controllers. Note the memory characteristics.

    I'm unsure what you mean by not dealing directly with memory. But C standard makes no specifications as to how memory should be internally managed. It's up to the implementation (the compiler/linker) to defined such things given the architecture for which it is being built.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #3
    The Registered User Aparavoid's Avatar
    Join Date
    May 2009
    Posts
    74
    Using pointers and having to manage allocating and freeing memory. I probably shouldn't have said directly, but I hope that clears thing up.

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,403
    Well, there is no special requirements to my knowledge that would make the use of malloc/calloc/realloc/free incompatible with a certain architecture. The architecture doesn't need to provide any special features.

    The important thing perhaps to take in consideration is that this is about how memory is used by the program. Not really how memory is deal with by the architecture. You have three types of memory usage:

    Static Memory - static variables, global variables and static class members. It's memory that is allocated when the program starts and deallocated when it ends. It is said the object is allocated on static memory. However, this is not to say there is a special architecture feature to use this memory. For all matters, the term is meant to differentiate the different types of memory usage. The actual object may reside anywhere within the memory space of the system.

    Automatic Memory - Called automatic because objects are created and destroyed automatically. All local objects are automatic memory and they are said to be created on the stack. But the term follows the exact same rules as above.

    Free Store - It's your objects created with malloc and deallocated with free. It is said these objects reside on the heap... but again the term is just meaningful to us programmers.

    As long as the architecture provides a memory space, you can use any of these types of memory because their implementation doesn't care about anything else. This is at least my understanding of the whole issue.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Just a few observations, vis the alternatives: many or most of them use compilers which are today written in C. From the looks of the wikipedia page, I would say this includes most implementations of Scheme -- some of them use C as intermediary code, and the common LISP interpreter is written in C. Of course, an executable (such as a compiler or interpreter) does not contain actual C pointers, etc, it is in asm, but I think there is probably a very intimate historical relationship between C, asm, and processor architecture. Eg, Linus Torvalds went into chip design after inventing the linux kernel, which is in C.

    Basically, what I am trying to say is that the things you are concerned about ("Using pointers and having to manage allocating and freeing memory") are probably the reasons C is so portable, as opposed to being features which would restrict this.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    The Registered User Aparavoid's Avatar
    Join Date
    May 2009
    Posts
    74
    I figured being low-level meant a restriction of portability somewhere but I guess not. Thanks for answering my question.

  7. #7
    One Level Below Beginner
    Join Date
    Jul 2009
    Location
    Corner of Nowhere and Yonder
    Posts
    19
    I think that is why I decided to start off with C,
    is because of it's portability.
    Provided of course you use the correct libraries




    (Just a skiddie wanting to become more)

  8. #8
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,591
    >> Provided of course you use the correct libraries
    Libraries have absolutely nothing to do with a language's portability. (not the kind your thinking of, at least). C/C++ can be optimized in such a way, that it's produced result requires NO runtime libs whatsoever, that's why it's used so extensively in OS programming.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  9. #9
    One Level Below Beginner
    Join Date
    Jul 2009
    Location
    Corner of Nowhere and Yonder
    Posts
    19
    Ah, so I have been misinformed...

    Thank you for correcting me....

  10. #10
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Yarin View Post
    C/C++ can be optimized in such a way, that it's produced result requires NO runtime libs whatsoever, that's why it's used so extensively in OS programming.
    That's not entirely accurate. At least not with C. While C++ has cin/cout, C has printf/scanf which are both part of libraries. While one could say that C could simply write the byte to the appropriate area of memory, and it could, that region would be different for each architecture, making the resulting program not generally portable.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  11. #11
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by abachler View Post
    That's not entirely accurate. At least not with C. While C++ has cin/cout, C has printf/scanf which are both part of libraries. While one could say that C could simply write the byte to the appropriate area of memory, and it could, that region would be different for each architecture, making the resulting program not generally portable.
    Hmmm. Altho with OS (kernel) programming not sure how much standard IO is necessary -- standard IO would seem to me something that exists once you do have a running kernel/OS. Eg, with linux, within the kernel itself non-standard, perhaps platform specific libraries are used for such, there is no printf() or fprintf(). But I'm not sure.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  12. #12
    One Level Below Beginner
    Join Date
    Jul 2009
    Location
    Corner of Nowhere and Yonder
    Posts
    19
    So, was I wrong, or right?

    Because, couldn't we create a library defining printf() to (what ever linux) uses?

  13. #13
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    Quote Originally Posted by Banned View Post
    So, was I wrong, or right?

    Because, couldn't we create a library defining printf() to (what ever Linux) uses?
    Yes. You are right and wrong. You don't use different libraries (as the standard C libraries are. . . standard). What you do use that is different, however, is a specifically compiled version of said libraries for the platform you are targeting.

    As for the Linux kernel not having a printf, this is not completely correct either. printk() is the name, but it _IS_ defined as a printf function. The choice for the 'k' was so that one couldn't accidentally link against GlibC as that could be "bad".

  14. #14
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,403
    Quote Originally Posted by Banned View Post
    So, was I wrong, or right?
    My opinion is that you are more right than wrong. But this is debatable.

    Even in the presence of a fully standard library, portability isn't guaranteed since it will always depend on the implementation on the other system. Portability across systems is dependent on portability across implementations. So, a standard library influences the ability to receive code from, or send code to, another system.

    This is more evident when new additions occur to the standards and each implementation takes its sweet time to adjust their libraries and compilers accordingly. But you can also observe it on about any implementation that decides to include languages extensions to its standard library implementation.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #15
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Kennedy View Post
    As for the Linux kernel not having a printf, this is not completely correct either. printk() is the name, but it _IS_ defined as a printf function. The choice for the 'k' was so that one couldn't accidentally link against GlibC as that could be "bad".
    Yeah, I'm aware of that, it's in "module.h". Which I haven't looked at "module.h" but I was thinking that part of the reason for this is to provide platform specific IO, as opposed to using stdio.h, which will not work in the kernel -- altho my thinking about all this could be muddled.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. COM application portability
    By Opariti in forum Windows Programming
    Replies: 3
    Last Post: 11-21-2008, 12:17 PM
  2. Replies: 1
    Last Post: 10-24-2005, 06:35 AM
  3. Program Portability (code portability)
    By Perica in forum C++ Programming
    Replies: 2
    Last Post: 11-10-2002, 09:03 AM
  4. what does portability mean?
    By elad in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 10-03-2002, 02:46 AM
  5. portability of a pause function
    By Eigenvalue in forum C Programming
    Replies: 2
    Last Post: 09-15-2002, 02:22 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21