Like Tree3Likes
  • 1 Post By MK27
  • 1 Post By AndrewHunter
  • 1 Post By MK27

Types in C

This is a discussion on Types in C within the C Programming forums, part of the General Programming Boards category; What exactly are you trying to discuss here Maz? A C string is a built-in composite type; this is not ...

  1. #1
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866

    Types in C

    What exactly are you trying to discuss here Maz? A C string is a built-in composite type; this is not an opinion but a fact. Arguing this is equivalent to saying the "sky is purple". Arguing these topics, as I warned earlier, is not worth the effort unless you have a specific reason to go down this route.
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,758
    Quote Originally Posted by AndrewHunter
    A C string is a built-in composite type; this is not an opinion but a fact.
    More accurately, a C string is of a built-in composite type.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Quote Originally Posted by laserlight View Post
    More accurately, a C string is of a built-in composite type.
    Thanks Laser, I can always trust you for correction.
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  4. #4
    Maz
    Maz is offline
    Registered User Maz's Avatar
    Join Date
    Nov 2005
    Location
    Finland
    Posts
    194
    well. I try not to argue. At first I just impressed my dislike using word "type" with C strings. Reason was that for me word type suggested that "thing" which we are talking about has known size thus making bitwise assignment possible (in theory), as well as detecting overflows or just declaring that type of a variable without size constraints. Not to mention forced data content ('\0' at the end).

    Now I am just interested in finding out how type is defined. What makes something a type? So lets not argue then, could you educate me, and show/explain me definition of type in C?

  5. #5
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Posts
    322
    Well, this is my gathering of types:

    A "type" is a C built-in type (int, char, double, etc.) or an array type (char[], int[]) or a pointer type (char*, int*) or a user-defined type (struct, union, typedef) or a function pointer type.

    Now some might argue that array types an pointer types are the same but they do have subtle differences; that becomes clear when dealing with multiple-dimension arrays.

  6. #6
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Quote Originally Posted by Maz View Post
    Now I am just interested in finding out how type is defined. What makes something a type? So lets not argue then, could you educate me, and show/explain me definition of type in C?
    At the risk of hijacking this thread even more.....(MODS may split these conversations out if they want too)

    So, what is a type? That is a very good question. The answer is there are in fact 3 categories of types for the C language: primitive, composite-built in, and composite user(I will discuss primitive here, all others can be later if required).

    Primitive Type
    A primitive type for any language is something that the parser can directly translate into machine code. It is "primitive" because it is directly built into the parser logic (usually a series of function calls) without recursion. The "without recursion" part makes it a primitive. For instance, lets look at the primitive type of "int x". ^
    Now, when we write something like: "int x = 5;" in C, the parser can directly translate that into machine code. In the data section(specifically .BSS section*), a variable named x would be created of type int (for 32-bit architecture) this would be a double word. For NASM syntax, declaration of X in the .BSS would be:
    Code:
    x resd 1; reserves 1 double word- 32 bits(sizeof(int) on 32 bit OS).
    ^ It is important to note that the job of finding and declaring variable names in their appropriate sections is often the task of the lexical scanner and not the parser.
    *BSS was actually not an initial construct of a program. It was added in the 1950's by an IBM assembler and actually stands for "Block Started by Symbol".

    Now since the declaration of x is taken care of, we now need to look at the assignment. In this case we declare x to be 5. So now the parser needs to handle this, and luckily since an int is a primitive we can convert this directly to machine code*:
    Code:
    LEA EDX, [X]; load address of x to EDX register
    MOV EAX, 5; place 5 into EAX reg (32-bit)
    MOX [EDX], EAX; place 5 into x
    *Note, since this is a primitive we do not need any loop statements (which means the parser did not use any recursion) to complete this expression.

    This is what is going on "under the hood" as you like to say with the compiler. Now, if you would like to discuss composite types ask the mods to split out this thread since the OP isn't done. All a built in composite type is a primitive, that is recursively built by the compiler. (This does involve stack usage and the stack pointer, along with looping for optimization).

    *Extra Info:*
    As for function calls, they are handled by the 'call' statement in NASM assembly. Note based on parser design for languages like C the return value from a function is stored in the EAX register on x86 machines.
    Pointers:=(if you get it feel free to PM me)These are constructs which denote the manner in which the parser deals with the register. Did you note the use of the square brackets '[' ']'? If they are present that means indirect addressing in NASM, which means place whatever is going there into the memory address that is stored by that register. So without '[' ']' means direct and with means indirect when it comes to registers**.

    **Note the instruction LEA has its own requirements which are beyond the topic of this post.

    EDIT:Added clarification based on Laser's response.
    Last edited by AndrewHunter; 09-30-2011 at 08:44 AM.
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  7. #7
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,758
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #8
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Thank you Laser!
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  9. #9
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,758
    Quote Originally Posted by AndrewHunter
    So, what is a type? That is a very good question. The answer is there are in fact 3 types for the C language: primitive, composite-built in, and composite user(I will discuss primitive here, all others can be later if required).
    That is a list of categories of types, not an exhaustive list of types in C.

    Quote Originally Posted by Maz
    What makes something a type? So lets not argue then, could you educate me, and show/explain me definition of type in C?
    Here is how a draft version of the C standard introduces types:
    Quote Originally Posted by ISO/IEC 9899:TC2 Clause 6.2.5 Paragraph 1
    The meaning of a value stored in an object or returned by a function is determined by the type of the expression used to access it. (An identifier declared to be an object is the simplest such expression; the type is specified in the declaration of the identifier.) Types are partitioned into object types (types that fully describe objects), function types (types that describe functions), and incomplete types (types that describe objects but lack information needed to determine their sizes).
    In other words, a type is meta-information that determines how a compiler (and a human) would interpret a value.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #10
    Registered User
    Join Date
    Jun 2005
    Posts
    6,311
    Quote Originally Posted by MacNilly View Post
    Now some might argue that array types an pointer types are the same but they do have subtle differences; that becomes clear when dealing with multiple-dimension arrays.
    Pointers and array types are completely different. They are equivalent in some contexts. Unfortunately, too many textbooks encourage beginners to believe they are always equivalent.

    The differences, when they occur, can be quite subtle (for example, only detected when code does not behave quite as intended). In other cases, they are quite blatant (for example, resulting in compilation errors).

    Multi-dimensional arrays are only one of several cases where the difference between pointers and arrays can be detected.
    Right 98% of the time, and don't care about the other 3%.

  11. #11
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Quote Originally Posted by laserlight View Post
    That is a list of categories of types, not an exhaustive list of types in C.
    You are correct, and I edited my post accordingly.

    Quote Originally Posted by laserlight View Post
    In other words, a type is meta-information that determines how a compiler (and a human) would interpret a value.
    For the purpose of this thread, let's actually peel back the concept of 'meta-information'. Your response is, of course, correct and 100% accurate, however let's 'break into the compiler' and see what is actually going on. I believe this is really the only way to resolve the 'type' question.

    Quote Originally Posted by grumpy View Post
    Pointers and array types are completely different. They are equivalent in some contexts. Unfortunately, too many textbooks encourage beginners to believe they are always equivalent.

    The differences, when they occur, can be quite subtle (for example, only detected when code does not behave quite as intended). In other cases, they are quite blatant (for example, resulting in compilation errors).

    Multi-dimensional arrays are only one of several cases where the difference between pointers and arrays can be detected.
    You are completely correct, and if required, we should demonstrate 'why'.
    Last edited by AndrewHunter; 09-30-2011 at 08:56 AM.
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  12. #12
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by AndrewHunter View Post
    let's 'break into the compiler' and see what is actually going on. I believe this is really the only way to resolve the 'type' question.
    Not really, since the C standard does not say anything about this, or how compilers should work under the hood (my search of the C99 draft shows the word "compiler" is only used once).

    So while what you describe is pragmatically interesting, a theoretical computer given to me by aliens, using alien hardware and alien software, could successfully implement a standard compliant C compiler that does not do any of the things you refer to. It does not even have to translate code to ASM. It could be filled with billions of tiny very quick thinking binary elves that absorb source code directly into their nano-minds, and understand types. Etc.

    It's a matter of interpreting law, the law in question being the C standard. Of course, this law was no doubt written in light of certain pragmatics, but the history of how and why a law came to be is not what binds.
    Last edited by MK27; 09-30-2011 at 09:09 AM.
    iceaway likes 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

  13. #13
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Quote Originally Posted by MK27 View Post
    Not really, since the C standard does not say anything about this, or how compilers should work under the hood (my search of the C99 draft shows the word "compiler" is only used once).
    You are correct, however the standard does mention translation units, whitespace management, ect.

    Quote Originally Posted by MK27 View Post
    So while what you describe is pragmatically interesting, a theoretical computer given to me by aliens, using alien hardware and alien software, could successfully implement a standard compliant C compiler that does not do any of the things you refer to. It does not even have to translate code to ASM. It could be filled with billions of tiny very quick thinking binary elves that absorb source code directly into their nano-minds, and understand types. Etc.
    This is also true, and in fact our theoretical compiler wouldn't produce ASM syntax but rather binary, but what use would that be in demonstrating behavior?

    Quote Originally Posted by MK27 View Post
    It's a matter of interpreting law, the law in question being the C standard. Of course, this law was no doubt written in light of certain pragmatics, but the history of how and why a law came to be is not what binds.
    Forest for the trees, my friend. In my discussion I am specifically talking about C, and specifically talking about what a primitive type is in C. In order to due that I am giving concrete examples of how the language was evolved and the decisions that were made. In software development, as you know, there is a recursive loop that exists between what the developers want and what hardware provides. Software developers demand requirements to which hardware developers design architecture too, which in turn feeds back to what software developers want to demand.

    When defining a language you have to first determine your grammer. What grammer you select is often based of the limitations of the current hardware. To ignore this fact is absurd and results in overly complicated constructs (this is in fact why for years the ability to parse mathematical expression became complex and burdensome). Once your grammar is determined you create your parser for the grammar, which is just the representation of your grammar in code (note: lexical analysis and pre-processor are constructs to enable the parser to do it's job and conform to host requirements). Once all of that is done you have created your language, the standardization.

    As you correctly mentioned, it is not history of the development of the language but rather the current law (standard) that binds. A standard however, is an abstraction of the language away from hardware, to enable your alien friends (and others) to create compilers and programs which operate consistently across implementations. The standard however, does not define 'primitive type'. This concept is in fact talked about and in order to understand what that is, it is necessary to talk about the specifics of the development of the language.
    MK27 likes this.
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

  14. #14
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by AndrewHunter View Post
    You are correct, however the standard does mention translation units, whitespace management, etc.
    These are to provide "precedence among the syntax rules of translation", and eg:

    Quote Originally Posted by C99 draft 5.1.1.2 #5
    Implementations must behave as if these separate phases occur, even though many are typically folded together in practice.
    Which is to say, it is again about ensuring uniform functionality. The purpose of "these phases" in the standard is not to provide compiler writers with ideas about how to make it happen. It is about what the implementation must provide as an interface for the programmer (hence "as if").

    our theoretical compiler wouldn't produce ASM syntax but rather binary, but what use would that be in demonstrating behavior?
    My point is the standard is only about behavior and not process. The computer could just be plain magic as far as the C programmer is concerned. A standard complaint implementation provides the behavior defined in the standard. Whether it requires ASM or binary or space cheese is irrelevant.

    Quote Originally Posted by C99 5 #1
    An implementation translates C source files and executes C programs in two data-processing-system environments, which will be called the translation environment and the execution environment
    Pretty sure this is nearly synonymous with "compilation time" and "run time", but is in fact not even that specific, because it does not actually say the implementation must compile source into an executable that can then be run. What it must do is provide a translation environment (an evaluation of the code considered as an abstract entity, aka, a potential executable, "as if" it had passed through a number of specific phases) and an execution environment -- the possibility for a concrete instance of execution.

    So our theoretical, fully compliant alien magic implementation might not even involve the concept of "compiled executable". It just needs to give you the programmer feedback in accord with the concept of a translation environment, and the possibility for actual execution. Not such a weird thing if you think about how interpreted languages happen.

    In my discussion I am specifically talking about C, and specifically talking about what a primitive type is in C.
    I don't think "primitive types" are discussed at all in the standard (as you later observe). This is more of a general CS concept. It has nothing "specifically" to do with C.

    Of course, I still totally found your insight/explanation interesting.

    In software development, as you know, there is a recursive loop that exists between what the developers want and what hardware provides. Software developers demand requirements to which hardware developers design architecture too, which in turn feeds back to what software developers want to demand.
    Are you sure it is that reciprocating? I think it is much more one sided -- hardware developers provide, and software developers make what they can of it. I imagine that all hardware developers can qualify as software developers, but the inverse is not true. The reciprocation is between the consumer and the hardware developer (hardware developers answer to consumer demand).

    Software developers are just monkey-grunts hired afterward to perform a pre-determined task.

    When defining a language you have to first determine your grammer. What grammer you select is often based of the limitations of the current hardware.
    Can you provide a concrete example of how this is true (your reference to "mathematical expressions" is very ambiguous)? To be frank, I don't believe hardware can do anything to either limit or enable anything specific on the level of grammar, simply because binary logic is exactly that (binary logic) and it precedes hardware, just as 2+2 equaled 4 before there were electronic calculators.

    No doubt, the relationship between complexity and hardware potential requires consideration, but I don't think that is about grammar. It is just about complexity.

    Once your grammar is determined you create your parser for the grammar, which is just the representation of your grammar in code (note: lexical analysis and pre-processor are constructs to enable the parser to do it's job and conform to host requirements). Once all of that is done you have created your language, the standardization.
    That is all 100% about software; it has nothing to do with hardware. It is also again all about CS theory and practice, and not at all specifically C.

    A standard however, is an abstraction of the language away from hardware
    Yes, the standard completely abstracts the language from the hardware, that is a primary purpose. A specific implementation of the standard of course has everything to do with specific hardware(s), but the idea of the standard is that the hardware has absolutely nothing to do with the language.

    The standard however, does not define 'primitive type'.
    What's more, if you look at how "composite types" are referred to, it is just WRT to resolving compatibility. Beyond that, the implementation does not have to be involved at all with with either primitive or composite types (even if in reality they always are). Our alien magic super-computer could be a sentient being possessing the ability to provide a translation environment and an execution environment, given you provide it with some source code to consider.

    it is necessary to talk about the specifics of the development of the language.
    I think it is interesting (I'm the kind of geek fascinated by the history of just about anything), but I don't think it's necessary. That's another purpose of the standard (it is completely abstracted from "why" and "how"). It may often be one of the better ways to explain something (and your post is an example of such, but you can't definitively settle an argument that way -- to do that you must reference the standard).
    Last edited by MK27; 09-30-2011 at 02:47 PM.
    AndrewHunter likes 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

  15. #15
    Registered User
    Join Date
    May 2011
    Location
    Around 8.3 light-minutes from the Sun
    Posts
    1,866
    Quote Originally Posted by MK27 View Post
    Are you sure it is that reciprocating? I think it is much more one sided -- hardware developers provide, and software developers make what they can of it. I imagine that all hardware developers can qualify as software developers, but the inverse is not true. The reciprocation is between the consumer and the hardware developer (hardware developers answer to consumer demand).

    Software developers are just monkey-grunts hired afterward to perform a pre-determined task.
    Yes, I am sure. The evolution of graphics technology is a perfect case study of this. You are right however, in that the consumer does indeed set the long term goals of where they want the community to move towards.
    Quote Originally Posted by MK27 View Post
    Can you provide a concrete example of how this is true (your reference to "mathematical expressions" is very ambiguous)? To be frank, I don't believe hardware can do anything to either limit or enable anything specific on the level of grammar, simply because binary logic is exactly that (binary logic) and it precedes hardware, just as 2+2 equaled 4 before there were electronic calculators.
    Yes, the language we are discussing currently is a perfect example of this. Notice the fact that I did not say that the grammer is limited by the current hardware but rather I noted that the grammer selected is often chosen based on the current hardware limitations. As you noted later, not doing so can greatly increase the complexity of the interpreter.
    So for the concrete example:
    Quote Originally Posted by dmr
    [They] are `close to the machine' in that the abstractions they introduce are readily grounded in the concrete data types and operations supplied by conventional computers
    The Development of the C Language

    As for the "mathematical expressions" comment I made, that does indeed warrant an explanation. I was referring to the constructs that have been created in the past to parse expressions such as: 1+(3*5)/2. I understand that the 'shunting yard algorithm' is an exercise in stacks, however it is worthwhile to note that such constructs came about in order to solve the 'precedence issue'. Many other, even more complicated, algorithms were created to solve this problem; however with all stack based CPU architecture, the solution is as simple as a series of function calls.

    (I can provide a simple example if deemed required for this discussion.)

    Quote Originally Posted by MK27 View Post
    I think it is interesting (I'm the kind of geek fascinated by the history of just about anything), but I don't think it's necessary. That's another purpose of the standard (it is completely abstracted from "why" and "how"). It may often be one of the better ways to explain something (and your post is an example of such, but you can't definitively settle an argument that way -- to do that you must reference the standard).
    We are in agreement, again. I was not responding to settle an argument, rather I was replying to Maz's post where he asked for an "explanation of types in C".
    Quote Originally Posted by anduril462 View Post
    Now, please, for the love of all things good and holy, think about what you're doing! Don't just run around willy-nilly, coding like a drunk two-year-old....
    Quote Originally Posted by quzah View Post
    ..... Just don't be surprised when I say you aren't using standard C anymore, and as such,are off in your own little universe that I will completely disregard.
    Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Assigning enum types to enum types?
    By see the big C in forum C Programming
    Replies: 10
    Last Post: 12-21-2010, 01:32 AM
  2. How to convert integral types into pointer types?
    By rohit99 in forum C++ Programming
    Replies: 3
    Last Post: 03-20-2008, 09:57 AM
  3. data types types...
    By gftmc in forum C++ Programming
    Replies: 3
    Last Post: 09-11-2006, 11:30 AM
  4. Types, Integral Types, Bytes?!?!?!
    By Kaidao in forum C++ Programming
    Replies: 3
    Last Post: 03-21-2006, 07:15 AM
  5. types
    By kermit in forum C Programming
    Replies: 7
    Last Post: 10-02-2004, 02:01 AM

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