Operator overloading in C

Operator overloading in C

Post by jacob navi » Thu, 06 Sep 2007 18:36:07


The lcc-win compiler is an experimental compiler
freely available at

http://www.yqcomputer.com/ . *** ia.edu/~lcc-win32

It features among other enhancements operator overloading.

The specifications for that can be downloaded from:

http://www.yqcomputer.com/ ~jacob/proposal.pdf

I would be interested in feedback from this group.

Thanks in advance.

Jacob
 
 
 

Operator overloading in C

Post by Philip Pot » Thu, 06 Sep 2007 23:19:14


To provide some context for those who haven't been following this in
comp.lang.c, I believe Jacob is advocating adding operator overloading to
standard C, and thinks that the benefits of it far outweigh the downsides. He
has made this suggestion a few times in comp.lang.c but the locals suggested
that proposals for changing the C standard should be made here rather than there.

Jacob: I suggest you post your proposal rather than link to it, simply because
people are more likely to read it if you do this. Also the link seems to be
broken - I can't get your proposal at all.

Phil

--
Philip Potter pgp <at> doc.ic.ac.uk

 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 01:03:19

ere is the first part of the pdf document. I think it is easier if I
post the document here in several messages.

More will follow.


New directions in C


1:Motivation

1.1: The current situation

The development of the C++ language has had an adverse effect in
the development of C. Since C++ was designed as the better C, C was
(and is) presented as the example of how not to do things, even
if both languages retained a large common base.

All development of C as an independent language has
been neglected and C has been relegated to the past.

The need for a simple and efficient language persists however,
and C is the language of choice for many systems running today
and many new ones. However, programming in C is made more difficult
than it should be because of some glaring deficiencies like its buggy
string library, the lack of a common library for the most used
containers like lists, stacks, and other popular data structures.

Since C++ went out to be "the better C", it is important to avoid
reintroducing the whole complexities of C++ into C and keep the
language as simple as it should be, but not simpler than the
minimum necessary to use it without much pain.

Of course the idea of improving C is doomed according to the C++
people, that obviously will say that the solution is not to
improve C but to come over to C++.

This same failure forecast is found by some C people, that see
any change to their baby as the beginning of the end of the spirit of C.

This situation is exacerbated by the C standards comitee, that
after the bad reception of the new C99 standard has gone into
deep sleep, making any changes or improvements to the standard
language impossible since the earliest date for any standard
publication is setup at 2020.

C is now effectively frozen.

1.2:The most important changes needed.

This proposal seeks to address the following problems as
they appear in our day to day programming.

o The lack of a counted string data structure, that would
give programmers an alternative to the inefficient and
extremely error prone zero terminated strings.

o The need to add new numerical types to the language.

o The need for an abstract containers library that would
allow to improve the developing of portable programs by
providing simple data structures like lists, flexible
arrays, stacks, and others, without any of the
complexity of the STL of C++.

Lets see this points in more detail.

A counted string data structure
-------------------------------
C has traditionally defined the string data type as a
sequence of bytes ending with a binary zero byte. This
is an extremely inefficient way of storing strings since
the length of the string, one of the most used
information about the string, must be recalculated at
each access. This implies in most cases a function call
to strlen(), or a loop. In case of long strings this
makes C less efficient than a BASIC interpreter written in C#.

This will be recognized by most C programmers, and the
existence of countless string libraries testifies to this fact.
The problem of those libraries is that they are not
standard and must be ported from one application to the
next, and from one operating system to the next.
What is needed is language support for counted strings.

Another requirement is that the syntax for accessing strings
and the whole library should be as similar to the traditio
 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 01:10:38

eneric functions
-----------------
Motivation

Like an ordinary function, a generic function takes arguments, performs
a series of operations, and perhaps returns useful values. An ordinary
function has a single body of code that is always executed when the
function is called. A generic function has a set of bodies of code of
which only one is selected for execution. The selected body of code is
determined by the types of the arguments to the generic function.
Ordinary functions and generic functions are called with identical
function-call syntax.

Generic functions were introduced into C by the C99 standard with the
header tgmath.h. This introduction was severely limited to some
mathematical functions but pointed to the need of having one name to
remember instead of memorizing several for functions that essentially do
the same thing but with slightly different data types.

With the proliferation of numeric types in C it is obvious that
remembering the name of each sin function, the one for floats the one
for complex, the one for long doubles, etc. uses too much memory space
to be acceptable.

Here I am speaking about the really important memory space: human memory
space, that is far more precious now that the cheap random access memory
that anyone can buy in the next supermarket. As far as I know there are
no human memory extensions for sale, and an interface and a programming
language is also judged by the number of things the user must learn by
heart, i.e. its memory footprint.


To reduce the complexities of C interfaces two solutions are proposed:

1)The first is the use of generic functions, i.e. functions that group
several slightly different task into a single conceptual one,
and
2) default arguments, that reduce the number of arguments that the user
must supply in a function call, and therefore its memory footprint.

Default arguments will be explained in the next message.

Syntax

result-type overloaded functionName( argument-list )

The same rules apply to the identifier overloaded as to the identifier
operator above. It is not a keyword in this implementation to remain
compatible with the standard.

The compiler will synthesize a name for this instance of the overloaded
function from the name and its argument list.

If this instance of the overloaded function should be an alias for an
existing function, the syntax is as follows:

result-type someFn( argument-list );

result-type overloaded functionName.someFn( argument-list )


This second form avoids any automatically generated names, what makes
the code binary compatible with other compilers.

Usage rules

An overloaded function must be a new identifier. It is an error to
declare a function as overloaded after the compiler has seen a different
prototype in the same scope.

It is also an error to declare a function that was declared as
overloaded as a normal function.

The rules for name resolution are the same as the rules for operator
overloading excepting of course the operator equivalence rule.

Generic functions can't have default arguments.

Default arguments
-----------------
Motivation

Default arguments are formal parameters that are given a value (the
default value) to use when the caller does not supply an actual
parameter value. Of course, actual parameter values, when given,
override the default values.

In many situations, some of the arguments to a function can be
 
 
 

Operator overloading in C

Post by Douglas A. » Fri, 07 Sep 2007 02:20:37

I take issue with Navia's characterization of C's status, its past
and its future, as well as with several of his technical assertions.
There are so many disputable points that I don't wish to address
them individually at this time.
 
 
 

Operator overloading in C

Post by Douglas A. » Fri, 07 Sep 2007 02:22:59


Also in S and R. They work best with lazy evaluation,
which does not appear to be compatible with existing C.
 
 
 

Operator overloading in C

Post by Keith Thom » Fri, 07 Sep 2007 02:48:12

jacob navia < XXXX@XXXXX.COM > writes:

Just to be clear, are you just telling us about the extensions in your
compiler, or are you proposing a change to the language for the next
standard? (I think I know what you have in mind, but not everyone in
comp.std.c has been following the discussions in comp.lang.c.)

--
Keith Thompson (The_Other_Keith) XXXX@XXXXX.COM < http://www.yqcomputer.com/ ~kst>
San Diego Supercomputer Center <*> < http://www.yqcomputer.com/ ~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 02:49:39


Of course I am proposing a change in the language. That is why
I am posting here.
 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 02:51:21


This is of course very easy for you.

And it is very constructive. Not even the shadow of an argumentation.

jacob
 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 02:53:20


The default argument expression is evaluated each time a call to that
function is done. Nowhere do I see the need for lazy evaluation, at
least in the context of the current implementation.
 
 
 

Operator overloading in C

Post by Flash Gord » Fri, 07 Sep 2007 02:59:17

Philip Potter wrote, On 05/09/07 15:19:


The link works from here. However, I agree it is likely to be more
widely read if posted in its entirety.

Re: the need for references to do operator overloading. I don't see why
you could not do the definition as:
Type operator=(Type * const arg1,Type arg2);
Obviously behaviour on trying to access anything other than the actual
item pointed to and a good quality implementation would warn if you
attempted to do that. By the way, yes I am saying make the pointer
constant, that is deliberate.

You need to define what you mean by "user defined data types" since you
say operator overloading can only be done if one of the types is a user
defined data type. Do you mean structures, or any alias created by a
typedef or what?

Does the return type have to be one of the two types specified? Can you
use different functions depending on what the result is assigned to
which, in my opinion, could make reading the code far harder.

I'm not commenting at the moment on whether the extensions are a good
idea or not, just suggesting some tightening up that I think you need in
your proposal.
--
Flash Gordon
 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 03:05:17


True, I will change that. Thanks


They have to be structures or unions. No typedefs.
I will add that to the specs.


The result must be one of the two types specified. I did not say that,
you are right.

And no, you can't have two operators that have the same signature but
a different return value.




Thanks
 
 
 

Operator overloading in C

Post by AndrGillib » Fri, 07 Sep 2007 03:23:11


I remember of a pre-K&R C compiler with 4000 lines of assembly code.
There were less than one instruction per line, because there were empty
lines and comments.


Now, C has got so big that 2000 lines of source code is "extremely small".


Into *one* existing compiler which was probably programmed cleverly, with
extensibility in mind.

I doubt that it would be that easy to add operator overloading to a 4000
LOC compiler programmed with many global variables and without any piece
of OO design.

I don't spit on the proposal, I was rather thinking about the past
evolution of C.

--
You can contact me at < XXXX@XXXXX.COM >
 
 
 

Operator overloading in C

Post by jacob navi » Fri, 07 Sep 2007 03:31:54


>> >>> All this enhancements have added only about >>> 2 000 lines of code to the original code of the lcc-win32 compiler. >> >> I remember of a pre-K&R C compiler with 4000 lines of assembly code. >> There were less than one instruction per line, because there were empty >> lines and comments. >> >>> This is extremely small, >> >> Now, C has got so big that 2000 lines of source code is "extremely small". >>

Well, it is just around 12K object code. This is quite small
compared to the size of a c99 compiler: around 500K of code.
>>> and proves that apparently difficult >>> extensions can be inserted into an existing compiler without >>> any code bloat. >> >> Into *one* existing compiler which was probably programmed cleverly, >> with extensibility in mind. >> >> I doubt that it would be that easy to add operator overloading to a 4000 >> LOC compiler programmed with many global variables and without any piece >> of OO design.

I do not think so.

This extension implies a small change in the lexer to recognize
'operator' at the global level.

Then, a table of operators must be built, and a generation of a symbol
must exist to provide the new operator a function name.

Then, the error path of the +, - and the other operators must be
modified. Instead of writing an error it will look if there is
an overloaded operator for this operation and generate a call
to the new function.

VERY SIMPLE.
>> >> I don't spit on the proposal, I was rather thinking about the past >> evolution of C. >>

C has remained relatively small. And this proposal just makes it
simpler, since instead of hard wiring complex number implementation
into the compiler (as C99 supposes) the complex number implementation
can be an outside library called with operator overloading. I would say
that a 4 000 lines of code C99 compiler (if that beast exists) would
SHRINK with this proposal.
 
 
 

Operator overloading in C

Post by Flash Gord » Fri, 07 Sep 2007 04:22:02

jacob navia wrote, On 05/09/07 19:05:


<snip Jacobs Operator Overloading Proposal>


I did not say the same signature. I'm talking about something like:
Type1 +operator(Type1,Type2);
Type2 +operator(Type1,Type2);
Note the different return types.


See, post in the right place and people don't complain about you
suggesting changes. Whether they agree or not is another matter, but as
of this post no one has complained about the post that I can see.
--
Flash Gordon