overloading, template, exception handling and c

Discussion in 'C Programming' started by v4vijayakumar, May 15, 2006.

  1. Why there is no overloading (function and operator), function templates
    and exception handling support in c? after all these are all useful
    programming constructs.

    What prevents ANSI/ISO committee to add these into c?
     
    v4vijayakumar, May 15, 2006
    #1
    1. Advertising

  2. v4vijayakumar

    jacob navia Guest

    v4vijayakumar a écrit :
    > Why there is no overloading (function and operator), function templates
    > and exception handling support in c? after all these are all useful
    > programming constructs.
    >
    > What prevents ANSI/ISO committee to add these into c?
    >


    Well, the lcc-win32 C compiler provides some of those.

    See the document
    ftp://ftp.cs.virginia.edu/pub/lcc-win32/proposal.pdf

    for a detailed description
     
    jacob navia, May 15, 2006
    #2
    1. Advertising

  3. v4vijayakumar

    Ian Collins Guest

    v4vijayakumar wrote:
    > Why there is no overloading (function and operator), function templates
    > and exception handling support in c? after all these are all useful
    > programming constructs.
    >
    > What prevents ANSI/ISO committee to add these into c?
    >

    Because they can be found elsewhere, C++ for example. C does what it
    does, if you want do do something else, use another tool.

    --
    Ian Collins.
     
    Ian Collins, May 15, 2006
    #3
  4. Ian Collins wrote:
    > Because they can be found elsewhere, C++ for example. C does what it
    > does, if you want do do something else, use another tool.


    the question is "why these are not C yet?". IMHO, If C++ or any other
    programming languages have these then it can not be a solution to C.
     
    v4vijayakumar, May 15, 2006
    #4
  5. v4vijayakumar

    Ian Collins Guest

    v4vijayakumar wrote:
    > Ian Collins wrote:
    >
    >>Because they can be found elsewhere, C++ for example. C does what it
    >>does, if you want do do something else, use another tool.

    >
    >
    > the question is "why these are not C yet?". IMHO, If C++ or any other
    > programming languages have these then it can not be a solution to C.
    >

    The answer is why should they be in C?

    This has been asked many times before, have a look though the group
    archives.

    --
    Ian Collins.
     
    Ian Collins, May 15, 2006
    #5
  6. v4vijayakumar

    Bill Pursell Guest

    Ian Collins wrote:
    > v4vijayakumar wrote:
    > > Ian Collins wrote:
    > >
    > >>Because they can be found elsewhere, C++ for example. C does what it
    > >>does, if you want do do something else, use another tool.

    > >
    > >
    > > the question is "why these are not C yet?". IMHO, If C++ or any other
    > > programming languages have these then it can not be a solution to C.
    > >

    > The answer is why should they be in C?


    I think a better answer is: "they aren't in C **yet** because
    they never will be. The never will be because they don't belong."

    It's like asking: "when will assembly have garbage collection?"
    or "when will VHDL provide a tty interface?".
     
    Bill Pursell, May 15, 2006
    #6
  7. v4vijayakumar

    Guest

    C is, at heart, a systems programming language. It has to be able to
    run without a runtime environment, and often on very small computers.
    Adding such features would reduce the usefulness of the language for
    many important purposes.
     
    , May 15, 2006
    #7
  8. v4vijayakumar

    Flash Gordon Guest

    wrote:

    Please provide context when replying. See the Google section at
    http://clc-wiki.net/wiki/Intro_to_clc

    > C is, at heart, a systems programming language. It has to be able to
    > run without a runtime environment,


    That will be why it has a library defined by the standard then, so that
    there is no run time support...

    > and often on very small computers.
    > Adding such features would reduce the usefulness of the language for
    > many important purposes.


    Possibly. A bigger reason in my opinion is that there are already
    languages with those things, so why turn C in to one?
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc
     
    Flash Gordon, May 15, 2006
    #8
  9. v4vijayakumar

    Default User Guest

    wrote:

    > C is, at heart, a systems programming language. It has to be able to
    > run without a runtime environment, and often on very small computers.
    > Adding such features would reduce the usefulness of the language for
    > many important purposes.


    What features? Please read the information below.



    Brian
    --
    Please quote enough of the previous message for context. To do so from
    Google, click "show options" and use the Reply shown in the expanded
    header.
     
    Default User, May 15, 2006
    #9
  10. v4vijayakumar

    CBFalconer Guest

    "" wrote:
    >
    > C is, at heart, a systems programming language. It has to be able to
    > run without a runtime environment, and often on very small computers.
    > Adding such features would reduce the usefulness of the language for
    > many important purposes.


    What features?

    In general on usenet you should realize that readers may very well
    not have convenient access to previous articles in a thread. That
    means that your reply articles should include adequate context, so
    that they stand by themselves. Google is NOT usenet, it is only a
    very poor interface to the real usenet system. To include proper
    context when using google, see my sig. below. Please be sure to
    read the referenced URLs.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Also see <http://www.safalra.com/special/googlegroupsreply/>
     
    CBFalconer, May 15, 2006
    #10
  11. v4vijayakumar

    Jack Klein Guest

    On 15 May 2006 03:43:45 -0700, "v4vijayakumar"
    <> wrote in comp.lang.c:

    > Why there is no overloading (function and operator), function templates
    > and exception handling support in c? after all these are all useful
    > programming constructs.
    >
    > What prevents ANSI/ISO committee to add these into c?


    Common sense.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, May 16, 2006
    #11
  12. wrote:
    > C is, at heart, a systems programming language. It has to be able to
    > run without a runtime environment, and often on very small computers.
    > Adding such features would reduce the usefulness of the language for
    > many important purposes.


    Overloading, template function, exception handling will not affect the
    portability or simplicity of the language. These are mechanisms and not
    policies. A language should be mechanisms rich and free of any
    policies. Implementing 'garbage collection' into C could cause an
    effect on running it in small computers, because 'garbage collection'
    is a policy.
     
    v4vijayakumar, May 16, 2006
    #12
  13. I think I am wrong. kindly ignore my previous message.

    v4vijayakumar wrote:
    > wrote:
    > > C is, at heart, a systems programming language. It has to be able to
    > > run without a runtime environment, and often on very small computers.
    > > Adding such features would reduce the usefulness of the language for
    > > many important purposes.

    >
    > Overloading, template function, exception handling will not affect the
    > portability or simplicity of the language. These are mechanisms and not
    > policies. A language should be mechanisms rich and free of any
    > policies. Implementing 'garbage collection' into C could cause an
    > effect on running it in small computers, because 'garbage collection'
    > is a policy.
     
    v4vijayakumar, May 16, 2006
    #13
  14. v4vijayakumar

    CBFalconer Guest

    v4vijayakumar wrote:
    > wrote:
    >
    >> C is, at heart, a systems programming language. It has to be able
    >> to run without a runtime environment, and often on very small
    >> computers. Adding such features would reduce the usefulness of
    >> the language for many important purposes.

    >
    > Overloading, template function, exception handling will not affect
    > the portability or simplicity of the language. These are mechanisms
    > and not policies. A language should be mechanisms rich and free of
    > any policies. Implementing 'garbage collection' into C could cause
    > an effect on running it in small computers, because 'garbage
    > collection' is a policy.


    However allowing for the possible use of these added mechanisms
    will seriously complicate simple code.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Also see <http://www.safalra.com/special/googlegroupsreply/>
     
    CBFalconer, May 16, 2006
    #14
  15. v4vijayakumar

    jacob navia Guest

    CBFalconer a écrit :
    > v4vijayakumar wrote:
    >
    >> wrote:
    >>
    >>
    >>>C is, at heart, a systems programming language. It has to be able
    >>>to run without a runtime environment, and often on very small
    >>>computers. Adding such features would reduce the usefulness of
    >>>the language for many important purposes.

    >>
    >>Overloading, template function, exception handling will not affect
    >>the portability or simplicity of the language. These are mechanisms
    >>and not policies. A language should be mechanisms rich and free of
    >>any policies. Implementing 'garbage collection' into C could cause
    >>an effect on running it in small computers, because 'garbage
    >>collection' is a policy.

    >
    >
    > However allowing for the possible use of these added mechanisms
    > will seriously complicate simple code.
    >


    How?

    I have explicitely pointed out that this can't affect any existing code.
    You fail to bring any new argument. Just assertions without any proof.
     
    jacob navia, May 16, 2006
    #15
  16. v4vijayakumar

    CBFalconer Guest

    jacob navia wrote:
    > CBFalconer a écrit :
    >> v4vijayakumar wrote:
    >>> wrote:
    >>>
    >>>> C is, at heart, a systems programming language. It has to be able
    >>>> to run without a runtime environment, and often on very small
    >>>> computers. Adding such features would reduce the usefulness of
    >>>> the language for many important purposes.
    >>>
    >>> Overloading, template function, exception handling will not affect
    >>> the portability or simplicity of the language. These are mechanisms
    >>> and not policies. A language should be mechanisms rich and free of
    >>> any policies. Implementing 'garbage collection' into C could cause
    >>> an effect on running it in small computers, because 'garbage
    >>> collection' is a policy.

    >>
    >> However allowing for the possible use of these added mechanisms
    >> will seriously complicate simple code.

    >
    > How?
    >
    > I have explicitely pointed out that this can't affect any existing
    > code. You fail to bring any new argument. Just assertions without
    > any proof.


    You have expressed your *opinion* that there are no effects. The
    actuality is different, as almost anyone who has ever designed a
    runtime system from the ground up should know.

    Let's take overloading as a horrible example. You have a choice -
    add a hidden parameter to each function call to identify the flavor
    (which automatically affects the code), or effectively do the same
    thing by name mangling. Now how do you handle the __function__ (I
    think) provision of the standard? How do you ensure that the
    linkage system can handle the mangled names. You may further
    restrict the length of user function names to accomodate the
    linker. Or other ugly things, totally unexpected by the innocent
    programmer.

    Think of the nasty effects of unwinding stack markers for an
    exception.

    Bear in mind that being able to do something cheaply on an x86
    windoze machine running the worlds most unsafe operating system
    does not mean it is feasible everywhere. You are playing in a
    narrow crevice in the C world.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Also see <http://www.safalra.com/special/googlegroupsreply/>
     
    CBFalconer, May 16, 2006
    #16
  17. v4vijayakumar

    jacob navia Guest

    CBFalconer a écrit :
    > Let's take overloading as a horrible example. You have a choice -
    > add a hidden parameter to each function call to identify the flavor
    > (which automatically affects the code), or effectively do the same
    > thing by name mangling.


    How can name mangling affect efficiency?

    > Now how do you handle the __function__ (I
    > think) provision of the standard?


    you get a very long function name like
    _operator_plus_Sometype_SomeType

    > How do you ensure that the
    > linkage system can handle the mangled names.


    Modern linkers accept very long names...

    > You may further
    > restrict the length of user function names to accomodate the
    > linker. Or other ugly things, totally unexpected by the innocent
    > programmer.
    >


    I still fail to see what this has to do with efficiency.

    > Think of the nasty effects of unwinding stack markers for an
    > exception.
    >


    ?????
    What is that?
    Where in the proposed document is that mentioned?

    Stop inventing things please.

    > Bear in mind that being able to do something cheaply on an x86
    > windoze machine running the worlds most unsafe operating system
    > does not mean it is feasible everywhere. You are playing in a
    > narrow crevice in the C world.
    >


    If you do not like Windows do not use it. Nobody is forcing you to use it.
     
    jacob navia, May 16, 2006
    #17
  18. v4vijayakumar wrote:
    > Why there is no overloading (function and operator), function templates
    > and exception handling support in c? after all these are all useful
    > programming constructs.
    >
    > What prevents ANSI/ISO committee to add these into c?


    Let me conclude.

    1. c will be neat and simple as always.

    2. completeness to c is not when "there is nothing more to add to it"
    but "there is nothinng more to remove"

    3. (c + something) can only be c++/d/c+2, but c will stay c only.

    4. (please add more easy-to-understand points here...)

    TIA.
     
    v4vijayakumar, May 16, 2006
    #18
  19. On 2006-05-16, jacob navia <> wrote:
    > CBFalconer a écrit :
    >> Let's take overloading as a horrible example. You have a choice -
    >> add a hidden parameter to each function call to identify the flavor
    >> (which automatically affects the code), or effectively do the same
    >> thing by name mangling.

    >
    > How can name mangling affect efficiency?
    >
    >> Now how do you handle the __function__ (I
    >> think) provision of the standard?

    >
    > you get a very long function name like
    > _operator_plus_Sometype_SomeType
    >

    Will the Standard dictate how to mangle names? Or will
    the user-programmer have to open up the object code every
    recompile to see what his function is actually called?

    >> How do you ensure that the
    >> linkage system can handle the mangled names.

    >
    > Modern linkers accept very long names...

    Of course, people manually linking assembler with C
    will have to figure out what functions do what, as
    he won't have any function names to compare.

    >
    >> You may further
    >> restrict the length of user function names to accomodate the
    >> linker. Or other ugly things, totally unexpected by the innocent
    >> programmer.
    >>

    > I still fail to see what this has to do with efficiency.
    >

    The last 9 words seem unnecessary.

    >> Think of the nasty effects of unwinding stack markers for an
    >> exception.
    >>

    >
    > ?????
    > What is that?
    > Where in the proposed document is that mentioned?
    >
    > Stop inventing things please
    >
    >> Bear in mind that being able to do something cheaply on an x86
    >> windoze machine running the worlds most unsafe operating system
    >> does not mean it is feasible everywhere. You are playing in a
    >> narrow crevice in the C world.
    >>

    >
    > If you do not like Windows do not use it. Nobody is forcing you to use it.

    If you modify C so that only on Wintel will your code
    run quickly, you are indeed forcing people to use
    Windows.
     
    Andrew Poelstra, May 16, 2006
    #19
  20. v4vijayakumar

    jacob navia Guest

    Andrew Poelstra a écrit :
    > On 2006-05-16, jacob navia <> wrote:
    >
    >>CBFalconer a écrit :
    >>
    >>>Let's take overloading as a horrible example. You have a choice -
    >>>add a hidden parameter to each function call to identify the flavor
    >>>(which automatically affects the code), or effectively do the same
    >>>thing by name mangling.

    >>
    >>How can name mangling affect efficiency?
    >>
    >>
    >>>Now how do you handle the __function__ (I
    >>>think) provision of the standard?

    >>
    >>you get a very long function name like
    >>_operator_plus_Sometype_SomeType
    >>

    >
    > Will the Standard dictate how to mangle names? Or will
    > the user-programmer have to open up the object code every
    > recompile to see what his function is actually called?
    >


    Please read the proposal. There I describe an algorithm for choosing the
    overloaded/operator function.

    >
    >>>How do you ensure that the
    >>>linkage system can handle the mangled names.

    >>
    >>Modern linkers accept very long names...

    >
    > Of course, people manually linking assembler with C
    > will have to figure out what functions do what, as
    > he won't have any function names to compare.
    >


    I have proposed a method to avoid mangling for overloaded functions.
    Please read the document.

    >>
    >>If you do not like Windows do not use it. Nobody is forcing you to use it.

    >
    > If you modify C so that only on Wintel will your code
    > run quickly, you are indeed forcing people to use
    > Windows.



    Linux uses the same CPU, and nothing in the proposal is windows specific.

    Just polemic, polemic, polemic.
     
    jacob navia, May 16, 2006
    #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. Howard Gardner
    Replies:
    4
    Views:
    362
    Howard Gardner
    Jul 20, 2006
  2. Hicham Mouline
    Replies:
    0
    Views:
    441
    Hicham Mouline
    Apr 23, 2009
  3. Hicham Mouline
    Replies:
    1
    Views:
    424
    Michael DOUBEZ
    Apr 24, 2009
  4. Peter
    Replies:
    34
    Views:
    1,975
    James Kanze
    Oct 17, 2009
  5. VSK
    Replies:
    0
    Views:
    255
Loading...

Share This Page