overloading, template, exception handling and c

[v4vijayakumar]

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?

 

[jacob navia]

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

 

[Ian Collins]

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.

 

[v4vijayakumar]

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.

 

[Ian Collins]

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.

 

[Bill Pursell]

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?".

 

[JesusWaffle]

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.

 

[Flash Gordon]

(e-mail address removed) 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?

 

[Default User]

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

 

[CBFalconer]

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/>

 

[Jack Klein]

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.

 

[v4vijayakumar]

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]

I think I am wrong. kindly ignore my previous message.

 

[CBFalconer]

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/>

 

[jacob navia]

CBFalconer a écrit :

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.

 

[CBFalconer]

CBFalconer a écrit :

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/>

 

[jacob navia]

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.

 

[v4vijayakumar]

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.

 

[Andrew Poelstra]

CBFalconer a écrit :

How can name mangling affect efficiency?


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?

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 still fail to see what this has to do with efficiency.

The last 9 words seem unnecessary.

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

Stop inventing things please


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.

 

[jacob navia]

Andrew Poelstra a écrit :

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.

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 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.