Re: the first programming language: C

Discussion in 'C Programming' started by riccardo, Oct 4, 2010.

  1. riccardo

    riccardo Guest


    > and for pointers?


    The idea of pointers is not that tough to teach.. first start by
    speaking of the memory and how it's addressed, than use some easy to get
    examples of addressing.. you don't really need to get too deep in that,
    just let them enjoy the pleasure of pointers.. otherwise teach them
    Java.. less troubles, more recent language etc... the very essence of C
    is pointers.. cutting them off almost makes C meaningless if compared to
    more recent programming languages.
    Those are jsut my 2cents
    RM
    riccardo, Oct 4, 2010
    #1
    1. Advertising

  2. On 2010-10-04 12:12, riccardo wrote:
    [...]
    > the very essence of C is pointers.. cutting them off almost makes
    > C meaningless if compared to more recent programming languages.


    In C, except from simulating call by reference, the only situations
    where we really need pointers in high level application programming is
    when working with

    1. linked data structures (essential pointers)

    2. dynamically allocated arrays (all references to elements can be index
    based instead of pointer based)

    3. function pointers.


    /August

    --
    The competent programmer is fully aware of the limited size of his own
    skull. He therefore approaches his task with full humility, and avoids
    clever tricks like the plague. --Edsger Dijkstra
    August Karlstrom, Oct 4, 2010
    #2
    1. Advertising

  3. August Karlstrom <> writes:
    > On 2010-10-04 12:12, riccardo wrote:
    > [...]
    >> the very essence of C is pointers.. cutting them off almost makes
    > > C meaningless if compared to more recent programming languages.

    >
    > In C, except from simulating call by reference, the only situations
    > where we really need pointers in high level application programming is
    > when working with
    >
    > 1. linked data structures (essential pointers)
    >
    > 2. dynamically allocated arrays (all references to elements can be index
    > based instead of pointer based)
    >
    > 3. function pointers.


    C array indexing is defined in terms of pointers.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 4, 2010
    #3
  4. Keith Thompson <> writes:
    > August Karlstrom <> writes:
    >> On 2010-10-04 12:12, riccardo wrote:
    >> [...]
    >>> the very essence of C is pointers.. cutting them off almost makes
    >> > C meaningless if compared to more recent programming languages.

    >>
    >> In C, except from simulating call by reference, the only situations
    >> where we really need pointers in high level application programming is
    >> when working with
    >>
    >> 1. linked data structures (essential pointers)
    >>
    >> 2. dynamically allocated arrays (all references to elements can be index
    >> based instead of pointer based)
    >>
    >> 3. function pointers.

    >
    > C array indexing is defined in terms of pointers.


    For that matter, so are (all) function calls, though that can usually be
    ignored in practice.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 4, 2010
    #4
  5. riccardo

    Dann Corbit Guest

    In article <i8dbi9$nfs$>,
    says...
    >
    > On 2010-10-04 12:12, riccardo wrote:
    > [...]
    > > the very essence of C is pointers.. cutting them off almost makes
    > > C meaningless if compared to more recent programming languages.

    >
    > In C, except from simulating call by reference, the only situations
    > where we really need pointers in high level application programming is
    > when working with
    >
    > 1. linked data structures (essential pointers)
    >
    > 2. dynamically allocated arrays (all references to elements can be index
    > based instead of pointer based)
    >
    > 3. function pointers.


    4. strings

    5. I/O of any kind

    6. Locales

    7. Parsing

    IOW, pretty much any place one would normally consider using C.

    I guess that there are at least a dozen more cases where addresses ought
    to be used in C.
    Dann Corbit, Oct 4, 2010
    #5
  6. "Dann Corbit" <> wrote in message
    news:-september.org...
    > In article <i8dbi9$nfs$>,
    > says...
    >>
    >> On 2010-10-04 12:12, riccardo wrote:
    >> [...]
    >> > the very essence of C is pointers.. cutting them off almost makes
    >> > C meaningless if compared to more recent programming languages.

    >>
    >> In C, except from simulating call by reference, the only situations
    >> where we really need pointers in high level application programming is
    >> when working with
    >>
    >> 1. linked data structures (essential pointers)
    >>
    >> 2. dynamically allocated arrays (all references to elements can be index
    >> based instead of pointer based)
    >>
    >> 3. function pointers.

    >
    > 4. strings
    >
    > 5. I/O of any kind
    >
    > 6. Locales
    >
    > 7. Parsing
    >
    > IOW, pretty much any place one would normally consider using C.
    >
    > I guess that there are at least a dozen more cases where addresses ought
    > to be used in C.


    one could distinguish between pointers and explicit pointer arithmetic...

    pointers themselves are difficult to avoid (much like avoiding reference
    types in Java), however, most uses of pointer arithmetic can be glossed over
    and assumed not to exist if needed. granted, traditional C string handling
    is effectively built around pointer arithmetic, meaning one would have to
    essentially rethink how to approach string handling.

    one possibility would be to essentially intern all the strings, and then
    create a number of high-level string operations (each string itself is
    assumed to be immutable).

    in my case, I tend to use a hybrid strategy, typically using pointers (and
    buffers) when more convinient, and interning and abstract strings in many
    other cases.

    IMO, going the other direction, and assuming strings to be passable mutable
    arrays, is essentially the wrong direction.

    or such...
    BGB / cr88192, Oct 4, 2010
    #6
  7. On 2010-10-04 22:26, Keith Thompson wrote:
    > C array indexing is defined in terms of pointers.


    But you don't have to think of it as pointers (abstraction you see).


    /August

    --
    The competent programmer is fully aware of the limited size of his own
    skull. He therefore approaches his task with full humility, and avoids
    clever tricks like the plague. --Edsger Dijkstra
    August Karlstrom, Oct 4, 2010
    #7
  8. On 2010-10-04 23:23, Dann Corbit wrote:
    > In article<i8dbi9$nfs$>,
    >> In C, except from simulating call by reference, the only situations
    >> where we really need pointers in high level application programming is
    >> when working with
    >>
    >> 1. linked data structures (essential pointers)
    >>
    >> 2. dynamically allocated arrays (all references to elements can be index
    >> based instead of pointer based)
    >>
    >> 3. function pointers.

    >
    > 4. strings


    Only if you want to use a library designed around pointers (e.g. the
    standard library). Here is some string handling without pointer syntax:

    #include <stdio.h>

    int main(void)
    {
    char s[] = "Hello Dann";
    int i;

    i = 0;
    while (s != '\0') {
    printf("%c\n", s);
    i++;
    }

    return 0;
    }

    > 5. I/O of any kind
    >
    > 6. Locales
    >
    > 7. Parsing


    If the libraries are designed around pointers, then yes.

    > IOW, pretty much any place one would normally consider using C.


    Like for instance low-level system programming.


    /August

    --
    The competent programmer is fully aware of the limited size of his own
    skull. He therefore approaches his task with full humility, and avoids
    clever tricks like the plague. --Edsger Dijkstra
    August Karlstrom, Oct 4, 2010
    #8
  9. riccardo

    ralph Guest

    On Mon, 4 Oct 2010 14:54:13 -0700, "BGB / cr88192"
    <> wrote:

    >
    >"Dann Corbit" <> wrote in message
    >news:-september.org...
    >> In article <i8dbi9$nfs$>,
    >> says...
    >>>
    >>> On 2010-10-04 12:12, riccardo wrote:
    >>> [...]
    >>> > the very essence of C is pointers.. cutting them off almost makes
    >>> > C meaningless if compared to more recent programming languages.
    >>>

    >>
    >> I guess that there are at least a dozen more cases where addresses ought
    >> to be used in C.

    >
    >one could distinguish between pointers and explicit pointer arithmetic...
    >


    I disagree as trying to make a distinction between "pointers" and
    "pointer arithmetic", or between "pointers" and "addresses" in C IS
    impossible.

    Pointers are 'addresses'. Period. They are not 'references'. Period.

    Two of the major stated goals for the C language is low-level access
    to memory, and map language constructs to machine instructions. To
    facilitate this, C provides the pointer data type. This data type
    holds addresses and the declaration of one provides specific
    instructions to the compiler to create equations for use when applying
    arithmetic. (Not so dissimilar to how separate instructions are
    applied to do arithmetic for longs, or for doubles.)

    The only way to avoid what many seem to consider messy is a judicious
    use of const, and/or another layer of indirection - See "Handles", or
    use a language where References are supported.

    -ralph
    ralph, Oct 4, 2010
    #9
  10. ralph <> writes:
    > On Mon, 4 Oct 2010 14:54:13 -0700, "BGB / cr88192"
    > <> wrote:
    >
    >>
    >>"Dann Corbit" <> wrote in message
    >>news:-september.org...
    >>> In article <i8dbi9$nfs$>,
    >>> says...
    >>>>
    >>>> On 2010-10-04 12:12, riccardo wrote:
    >>>> [...]
    >>>> > the very essence of C is pointers.. cutting them off almost makes
    >>>> > C meaningless if compared to more recent programming languages.
    >>>>
    >>>
    >>> I guess that there are at least a dozen more cases where addresses ought
    >>> to be used in C.

    >>
    >>one could distinguish between pointers and explicit pointer arithmetic...
    >>

    >
    > I disagree as trying to make a distinction between "pointers" and
    > "pointer arithmetic", or between "pointers" and "addresses" in C IS
    > impossible.
    >
    > Pointers are 'addresses'. Period. They are not 'references'. Period.


    The latter depends on what you mean by "references". For example, C++
    has "references" (it also has pointers that are essentially identical to
    C pointers), and C++ "references" are definitely very different from
    pointers.

    However, the C Standard's own definition of "pointer" uses the word
    "reference". C99 6.2.5p20:

    A _pointer type_ may be derived from a function type, an object
    type, or an incomplete type, called the _referenced type_. A
    pointer type describes an object whose value provides a reference
    to an entity of the referenced type. A pointer type derived
    from the referenced type T is sometimes called ‘‘pointer to
    T’’. The construction of a pointer type from a referenced
    type is called ‘‘pointer type derivation’’.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 5, 2010
    #10
  11. ralph <> writes:
    > On Mon, 04 Oct 2010 16:01:04 -0700, Keith Thompson <>
    > wrote:
    >
    >>ralph <> writes:
    >>> On Mon, 4 Oct 2010 14:54:13 -0700, "BGB / cr88192"
    >>>>
    >>>>one could distinguish between pointers and explicit pointer arithmetic...
    >>>>
    >>>
    >>> I disagree as trying to make a distinction between "pointers" and
    >>> "pointer arithmetic", or between "pointers" and "addresses" in C IS
    >>> impossible.
    >>>
    >>> Pointers are 'addresses'. Period. They are not 'references'. Period.

    >>
    >>The latter depends on what you mean by "references". For example, C++
    >>has "references" (it also has pointers that are essentially identical to
    >>C pointers), and C++ "references" are definitely very different from
    >>pointers.
    >>
    >>However, the C Standard's own definition of "pointer" uses the word
    >>"reference". C99 6.2.5p20:
    >>
    >> A _pointer type_ may be derived from a function type, an object
    >> type, or an incomplete type, called the _referenced type_. A
    >> pointer type describes an object whose value provides a reference
    >> to an entity of the referenced type. A pointer type derived
    >> from the referenced type T is sometimes called ‘‘pointer to
    >> T’’. The construction of a pointer type from a referenced
    >> type is called ‘‘pointer type derivation’’.
    >>
    >>[...]

    >
    >
    > That description also includes the term 'object type', does that mean
    > C provides "objects"?
    >
    > -ralph
    > <g>


    Of course it does.

    An "object" is simply a "region of data storage in the execution
    environment, the contents of which can represent values" (C99 3.14).

    (Note that the C++ standard defines an "object" as "a region of storage"
    (C++2003 1.8p1), just in case you were thinging that an "object"
    has to be something related to object-oriented programming.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 5, 2010
    #11
  12. riccardo

    ralph Guest

    On Mon, 04 Oct 2010 17:03:11 -0700, Keith Thompson <>
    wrote:

    >ralph <> writes:
    >> On Mon, 04 Oct 2010 16:01:04 -0700, Keith Thompson <>
    >> wrote:
    >>
    >>>ralph <> writes:
    >>>> On Mon, 4 Oct 2010 14:54:13 -0700, "BGB / cr88192"
    >>>>>
    >>>>>one could distinguish between pointers and explicit pointer arithmetic...
    >>>>>
    >>>>
    >>>> I disagree as trying to make a distinction between "pointers" and
    >>>> "pointer arithmetic", or between "pointers" and "addresses" in C IS
    >>>> impossible.
    >>>>
    >>>> Pointers are 'addresses'. Period. They are not 'references'. Period.
    >>>
    >>>The latter depends on what you mean by "references". For example, C++
    >>>has "references" (it also has pointers that are essentially identical to
    >>>C pointers), and C++ "references" are definitely very different from
    >>>pointers.
    >>>
    >>>However, the C Standard's own definition of "pointer" uses the word
    >>>"reference". C99 6.2.5p20:
    >>>
    >>> A _pointer type_ may be derived from a function type, an object
    >>> type, or an incomplete type, called the _referenced type_. A
    >>> pointer type describes an object whose value provides a reference
    >>> to an entity of the referenced type. A pointer type derived
    >>> from the referenced type T is sometimes called ‘‘pointer to
    >>> T’’. The construction of a pointer type from a referenced
    >>> type is called ‘‘pointer type derivation’’.
    >>>
    >>>[...]

    >>
    >>
    >> That description also includes the term 'object type', does that mean
    >> C provides "objects"?
    >>
    >> -ralph
    >> <g>

    >
    >Of course it does.
    >
    >An "object" is simply a "region of data storage in the execution
    >environment, the contents of which can represent values" (C99 3.14).
    >
    >(Note that the C++ standard defines an "object" as "a region of storage"
    >(C++2003 1.8p1), just in case you were thinging that an "object"
    >has to be something related to object-oriented programming.)



    Well, you have convinced me.

    The C pointer is a Reference and C++ objects are only regions of
    storage unrelated to facilitating object-oriented constructs.

    -ralph
    ralph, Oct 5, 2010
    #12
  13. ralph <> writes:
    > On Mon, 04 Oct 2010 17:03:11 -0700, Keith Thompson <>
    > wrote:
    >>ralph <> writes:
    >>> On Mon, 04 Oct 2010 16:01:04 -0700, Keith Thompson <>
    >>> wrote:

    [...]
    >>>>However, the C Standard's own definition of "pointer" uses the word
    >>>>"reference". C99 6.2.5p20:
    >>>>
    >>>> A _pointer type_ may be derived from a function type, an object
    >>>> type, or an incomplete type, called the _referenced type_. A
    >>>> pointer type describes an object whose value provides a reference
    >>>> to an entity of the referenced type. A pointer type derived
    >>>> from the referenced type T is sometimes called ‘‘pointer to
    >>>> T’’. The construction of a pointer type from a referenced
    >>>> type is called ‘‘pointer type derivation’’.
    >>>>
    >>>>[...]
    >>>
    >>>
    >>> That description also includes the term 'object type', does that mean
    >>> C provides "objects"?
    >>>
    >>> -ralph
    >>> <g>

    >>
    >>Of course it does.
    >>
    >>An "object" is simply a "region of data storage in the execution
    >>environment, the contents of which can represent values" (C99 3.14).
    >>
    >>(Note that the C++ standard defines an "object" as "a region of storage"
    >>(C++2003 1.8p1), just in case you were thinging that an "object"
    >>has to be something related to object-oriented programming.)

    >
    >
    > Well, you have convinced me.
    >
    > The C pointer is a Reference and C++ objects are only regions of
    > storage unrelated to facilitating object-oriented constructs.


    A C pointer is a reference in the sense that it can refer to something.
    It is not a "reference" in the sense in which C++ uses the word.

    <OT>
    C++ objects are not necessarily related to "object-oriented" constructs,
    but you can't have the latter without the former.
    </OT>

    It's hardly surprising that words are used with different meanings
    in different contexts.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 5, 2010
    #13
  14. riccardo

    Felix Palmen Guest

    * August Karlstrom <>:
    > Only if you want to use a library designed around pointers (e.g. the
    > standard library). Here is some string handling without pointer syntax:


    Ok, assuming you are willing to ignore the fact that you can't pass an
    array to a C function and the compiler just emulates that by using
    pointers instead -- what about /returning/ a string?

    Regards,
    Felix

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
    Felix Palmen, Oct 5, 2010
    #14
  15. On 2010-10-05 09:13, Felix Palmen wrote:
    > Ok, assuming you are willing to ignore the fact that you can't pass an
    > array to a C function and the compiler just emulates that by using
    > pointers instead -- what about /returning/ a string?


    Well, in C you can't.


    /August

    --
    The competent programmer is fully aware of the limited size of his own
    skull. He therefore approaches his task with full humility, and avoids
    clever tricks like the plague. --Edsger Dijkstra
    August Karlstrom, Oct 5, 2010
    #15
  16. riccardo

    Felix Palmen Guest

    * Richard <>:
    > August Karlstrom <> writes:
    >> On 2010-10-05 09:13, Felix Palmen wrote:

    [...]
    >>> pointers instead -- what about /returning/ a string?

    >>
    >> Well, in C you can't.

    [...]
    > In C if you malloc a block of memory and strcpy something into it and
    > return a pointer to that memory you are "returning a string".


    The implicit constraint from thread context was "without using
    pointers". And so, August's answer is correct and exactly the one I
    expected. Which arguably proofs you indeed need pointers for handling
    strings in C and it is NOT just a "standard library issue".

    Regards,
    Felix

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
    Felix Palmen, Oct 5, 2010
    #16
  17. On 2010-10-05 15:13, Felix Palmen wrote:
    > * Richard<>:
    >> August Karlstrom<> writes:
    >>> On 2010-10-05 09:13, Felix Palmen wrote:

    > [...]
    >>>> pointers instead -- what about /returning/ a string?
    >>>
    >>> Well, in C you can't.

    > [...]
    >> In C if you malloc a block of memory and strcpy something into it and
    >> return a pointer to that memory you are "returning a string".

    >
    > The implicit constraint from thread context was "without using
    > pointers". And so, August's answer is correct and exactly the one I
    > expected. Which arguably proofs you indeed need pointers for handling
    > strings in C and it is NOT just a "standard library issue".


    The point is that while you need pointers to pass around arrays you
    don't need pointer syntax to access elements (nothing new). You could
    design a string library based around indices instead of pointers.


    /August

    --
    The competent programmer is fully aware of the limited size of his own
    skull. He therefore approaches his task with full humility, and avoids
    clever tricks like the plague. --Edsger Dijkstra
    August Karlstrom, Oct 5, 2010
    #17
  18. riccardo

    Felix Palmen Guest

    * August Karlstrom <>:
    > The point is that while you need pointers to pass around arrays you
    > don't need pointer syntax to access elements (nothing new). You could
    > design a string library based around indices instead of pointers.


    If you really think this is possible, please show the signature of a
    function to concatenate two strings.

    Regards,
    Felix

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
    Felix Palmen, Oct 5, 2010
    #18
  19. (Felix Palmen) writes:
    > * August Karlstrom <>:
    >> The point is that while you need pointers to pass around arrays you
    >> don't need pointer syntax to access elements (nothing new). You could
    >> design a string library based around indices instead of pointers.

    >
    > If you really think this is possible, please show the signature of a
    > function to concatenate two strings.


    void concatenate(char s1[], const char s2[]);

    On the other hand, I might argue that "char s1[]", and even the
    indexing operator, *is* "pointer syntax".

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 5, 2010
    #19
  20. riccardo

    Felix Palmen Guest

    * Keith Thompson <>:
    > (Felix Palmen) writes:
    >> * August Karlstrom <>:
    >>> The point is that while you need pointers to pass around arrays you
    >>> don't need pointer syntax to access elements (nothing new). You could
    >>> design a string library based around indices instead of pointers.

    >>
    >> If you really think this is possible, please show the signature of a
    >> function to concatenate two strings.

    >
    > void concatenate(char s1[], const char s2[]);


    Hmm ok, defined /that/ way, this leads to the next problem of declaring
    s1 so it is guaranteed to be large enough. As run-time calculated array
    sizes are not possible, this could be very problematic without pointers.

    > On the other hand, I might argue that "char s1[]", and even the
    > indexing operator, *is* "pointer syntax".


    Indeed.

    Regards,
    Felix

    --
    Felix Palmen (Zirias) + [PGP] Felix Palmen <>
    web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
    my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
    http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
    Felix Palmen, Oct 5, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Casey Hawthorne
    Replies:
    4
    Views:
    998
    Jarek Zgoda
    Aug 4, 2006
  2. jmDesktop
    Replies:
    46
    Views:
    894
    Simon Brunning
    Mar 26, 2008
  3. Francois Grieu

    Re: the first programming language: C

    Francois Grieu, Oct 3, 2010, in forum: C Programming
    Replies:
    14
    Views:
    441
    Keith Thompson
    Oct 8, 2010
  4. Ben Pfaff

    Re: the first programming language: C

    Ben Pfaff, Oct 8, 2010, in forum: C Programming
    Replies:
    3
    Views:
    319
    Seebs
    Oct 10, 2010
  5. Replies:
    3
    Views:
    226
    Ameya the ______
    Nov 2, 2010
Loading...

Share This Page