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]

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.

[v4vijayakumar]

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.

[Ian Collins]

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.

[Bill Pursell]

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

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

[Default User]

Je*********@gmail.com 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.

[Flash Gordon]

Je*********@gmail.com 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

[CBFalconer]

"Je*********@gmail.com" 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/>

[Jack Klein]

On 15 May 2006 03:43:45 -0700, "v4vijayakumar"
<v4***********@yahoo.com> 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/~a...FAQ-acllc.html

[v4vijayakumar]

Je*********@gmail.com 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]

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

v4vijayakumar wrote:

Je*********@gmail.com 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.

[CBFalconer]

v4vijayakumar wrote:

Je*********@gmail.com 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/>

[jacob navia]

CBFalconer a écrit :

v4vijayakumar wrote:

Je*********@gmail.com 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.

[CBFalconer]

jacob navia wrote:

CBFalconer a écrit :

v4vijayakumar wrote:

Je*********@gmail.com 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/>

[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]

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.

[Andrew Poelstra]

On 2006-05-16, jacob navia <ja***@jacob.remcomp.fr> 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.

[jacob navia]

Andrew Poelstra a écrit :

On 2006-05-16, jacob navia <ja***@jacob.remcomp.fr> 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.

[Richard Heathfield]

jacob navia said:

Andrew Poelstra a écrit :

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.

Linux is not constrained to x86. Also, there are other platforms than Linux
and Windows.
Just polemic, polemic, polemic.

Oh, be fair to yourself. You don't /just/ spout polemic. You also advertise
your product, over and over again. The rest of us don't do that. Why do you
think it's okay for you to do it?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Andrew Poelstra]

On 2006-05-16, jacob navia <ja***@jacob.remcomp.fr> wrote:

Andrew Poelstra a écrit :

On 2006-05-16, jacob navia <ja***@jacob.remcomp.fr> 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.

g++, MSVC++, and various other compilers use different algorithms,
none of which are the same as yours (at most one is the same), and
one that I designed is different from all of them! Name mangling
locks you into a specific compiler, and frequently a single CPU or
operating system.

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.

The two functions need to be different, because of the way that C
interfaces with [x86] assembler. I don't want that kind of added
complexity.

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.

As Richard said, Linux is not constrained to x86. I personally have written
code for x86, x86_64, PPC, ARM, NES, and the Linksys WRT54G. (I'm not sure
what exact processor the last two use). I know that I can do C on all those
systems reasonably efficently, thanks to C's low-level nature. With a lot
of your proposed add-ons, I'd lose that low-level-icity.
Just polemic, polemic, polemic.

You are arguing as well, and advertising too.

[CBFalconer]

jacob navia wrote:

Andrew Poelstra a écrit :

.... snip ...

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.

No, Linux CAN use the same CPU. It can also use other CPUs. How
many distinct CPU architectures does LCC-Win32 run on? I have
noted before that it doesn't even run on a '486 executing W98,
which is not by any measure a distinct architecture from a
Pentium. Does this bode well for your assertions that the
proposals are portable?

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

[John Bode]

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?

We already have C++.

[v4vijayakumar]

John Bode wrote:

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?

We already have C++.

yes. we already have comp.lang.c++ too!

[santosh]

v4vijayakumar wrote:

John Bode wrote:

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?

We already have C++.

yes. we already have comp.lang.c++ too!

And we already have enough trolls in this group too!

[v4vijayakumar]

santosh wrote:

v4vijayakumar wrote:

John Bode wrote:

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?

We already have C++.

yes. we already have comp.lang.c++ too!

And we already have enough trolls in this group too!

I don't know what a troll is before reading
http://en.wikipedia.org/wiki/Internet_troll. I think I am not the one.

I am convinced by two answers to my question.

1. common sense
2. we already have c++

but, I am looking for some concrete answers and still I hope.

[santosh]

v4vijayakumar wrote:

santosh wrote:

v4vijayakumar wrote:

John Bode wrote:
> 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?
>
> We already have C++.

yes. we already have comp.lang.c++ too!
And we already have enough trolls in this group too!

I don't know what a troll is before reading
http://en.wikipedia.org/wiki/Internet_troll. I think I am not the one.

Okay, tell me what you think tommorow.
I am convinced by two answers to my question.

1. common sense
Of which you can do with some.
2. we already have c++
Thanks for the timely reminder. Bjarne will be greatful to you.
but, I am looking for some concrete answers and still I hope.

I'm inspired by your positive attitude.

[pete]

v4vijayakumar wrote:

santosh wrote:

v4vijayakumar wrote:

John Bode wrote:
> 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?
>
> We already have C++.

yes. we already have comp.lang.c++ too!

And we already have enough trolls in this group too!

I don't know what a troll is before reading
http://en.wikipedia.org/wiki/Internet_troll. I think I am not the one.

I am convinced by two answers to my question.

1. common sense
2. we already have c++

but, I am looking for some concrete answers and still I hope.

"The way that C should be",
regarding proposals for new features and such,
is on topic on
news:comp.std.c

Try to organize your thoughts very well before posting there.
They're not as technically casual over there, as we are here.

--
pete

[CBFalconer]

pete wrote:

v4vijayakumar wrote:

santosh wrote:

v4vijayakumar wrote:
John Bode wrote:
> 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?
>
> We already have C++.

yes. we already have comp.lang.c++ too!

And we already have enough trolls in this group too!

I don't know what a troll is before reading
http://en.wikipedia.org/wiki/Internet_troll. I think I am not the one.

I am convinced by two answers to my question.

1. common sense
2. we already have c++

but, I am looking for some concrete answers and still I hope.

"The way that C should be",
regarding proposals for new features and such,
is on topic on
news:comp.std.c

Try to organize your thoughts very well before posting there.
They're not as technically casual over there, as we are here.

Come on. Isn't it obvious that v4vijayakumar has a language
barrier, and that he has accepted the primary reasons for no silly
extensions. It is high time to put this thread to the natural
death it deserves.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html