overloading in C

[uday]

Does C supports overloading. I am thinking no. But some people are
saying yes. If yes how. Please answer with examples.

Also in c++ size of empty class is one. why. and what are the
default methods created in a class. These questions are asked in
interviews. so please explain.

 

[Richard Bos]

Does C supports overloading. I am thinking no. But some people are
saying yes. If yes how.

No. In C99, some of the generic math functions are essentially
overloaded by the Standard, but (thank heavens) there is no mechanism
for creating overloaded functions, or worse, operators, yourself.

Please answer with examples.

Do your own homework.

Also in c++

C++ is off-topic in comp.lang.c.

Richard

 

[S.Tobias]

No. In C99, some of the generic math functions are essentially
overloaded by the Standard, but (thank heavens) there is no mechanism
for creating overloaded functions, or worse, operators, yourself.

Some people (including me) consider C operators as overloaded:
1 + 2
1u + 2
1l + 2
1. + 2
mean entirely different operations, and which ones is resolved
based on the types of the arguments (ie. operands).

 

[Dan Pop]

Some people (including me) consider C operators as overloaded:
1 + 2
1u + 2
1l + 2
1. + 2
mean entirely different operations, and which ones is resolved
based on the types of the arguments (ie. operands).

They *are* overloaded, but there is no way to extend this overloading in
your code. Which is exactly what people mean when they ask about operator
overloading in C.

A small amount of type-generic stuff (not exactly the same thing as
function overloading) can be done with function-like macros.

Dan

 

[Mark McIntyre]

Some people (including me) consider C operators as overloaded:

Pardon? In all cases + adds two numbers together. There's nothing 'entirely
different' about that.
This compares to C++ where operator+ could be defined to mean absolutely
anything, at the users' discretion.

and which ones is resolved based on the types of the arguments (ie. operands).

And printf does different things based on its argument types. So what?

 

[S.Tobias]

On 25 Nov 2004 11:04:55 GMT, in comp.lang.c , "S.Tobias"

Pardon? In all cases + adds two numbers together.

No, the C `+' operators do not add two numbers, are not the same as
Mathematics `+' operation for Real numbers. Most visibly they differ
in their domain. For other example, C `+' for unsigned implements
clock arithmetic - equivalent of addition in Rings. For floats again
C `+' does not add numbers: 1e99 + 1e-99 == 1e99.
C `+' operator is of course meant to "reasonably" add things, but
these operations have their own rules and can't be thought of
as just "addition". IMHO.

There's nothing 'entirely
different' about that.

(unsigned)-1 + 1
(unsigned long)(unsigned)-1 + 1
obviously differ in value.
They will differ in machine instructions; the difference is even
more obvious for integer and float types.

The compiler decides which instructions to emit depending on
what the arguments are. What do you call it, if not "overloading"?

This compares to C++ where operator+ could be defined to mean absolutely
anything, at the users' discretion.

Not exactly: a user cannot redefine operator+ for built-in types.
But apart of that:
const Int operator+(const Int& , const Int&);
const Double operator+(const Double&, const Double&);
(for some classes Int and Double) are to each other in terms
of concept of overloading as are:
(int) + (int)
(double) + (double)
- they have different return types, and invoke different instructions.
You cannot tell what
a + b
will do until you know the types of `a' and `b'.

Qed.

And printf does different things based on its argument types. So what?

No, after the arguments have been prepared (read: thrown on the stack;
ellipsis is a language feature, there's no function or operator call
yet so we can't speak of overloading here) the sequence of instructions
issued by the compiler is the same each time. I would say that printf
is a data-driven function.

 

[jacob navia]

No, the C `+' operators do not add two numbers, are not the same as
Mathematics `+' operation for Real numbers. Most visibly they differ
in their domain. For other example, C `+' for unsigned implements
clock arithmetic - equivalent of addition in Rings. For floats again
C `+' does not add numbers: 1e99 + 1e-99 == 1e99.
C `+' operator is of course meant to "reasonably" add things, but
these operations have their own rules and can't be thought of
as just "addition". IMHO.

Exactly.

This fact, and the fact that the C99 comitee introduced overloaded
functions like sqrt, sin, pow, etc, led me to implement operator
overloading within a C context. This has been very useful to implement
all kind of numbers just extending the C99 overloaded functions to them.

For instance the qfloat type (350 bits) has been implemented this way.

To avoid gratuituos incompatibilities with C++ I use the same syntax.

qfloat operator+(qfloat &,qfloat b);

This has been atacked ad nauseum by the conservatives in this group,
and I do not want to rehash this polemic for the 1000th time.

The rationale for this is as follows:

If the designers of C99 needed this feature and proposed an overloaded
sqrt/pow/sin/ etc functions why shouldn't the user be able to solve this
in his/her context as well?

If the implementor of a language needs a feature, the user needs it as
well and should be allowed to have it.

jacob

http://www.cs.virginia.edu/~lcc-win32

 

[Michael Mair]

Exactly.

This fact, and the fact that the C99 comitee introduced overloaded
functions like sqrt, sin, pow, etc, led me to implement operator
overloading within a C context. This has been very useful to implement
all kind of numbers just extending the C99 overloaded functions to them.

For instance the qfloat type (350 bits) has been implemented this way.

To avoid gratuituos incompatibilities with C++ I use the same syntax.

qfloat operator+(qfloat &,qfloat b);

This has been atacked ad nauseum by the conservatives in this group, ad nause_a_m
and I do not want to rehash this polemic for the 1000th time.

Well, keep the advertising of non-standard solutions clearly separated
from your standard C answers. I, for one, am interested in a look
behind the scenes but not necessarily in this newsgroup.

The rationale for this is as follows:

If the designers of C99 needed this feature and proposed an overloaded
sqrt/pow/sin/ etc functions why shouldn't the user be able to solve this
in his/her context as well?

If the implementor of a language needs a feature, the user needs it as
well and should be allowed to have it.

I think this is a "dangerous" argument as this would mean that I
should be able to do the same things all standard library functions
do within the scope of the language. And portably.
The repercussions of this are IMO very clear and not very nice.

Operator overloading would be a nice feature in more than one setting
but may complicate things in a way that we end up with people
doing subsetting where it is not necessary _now_.

As long as you clearly keep everything separate and full
conformance to the original language is kept, that is fine with
me, though.


BTW: Are you going to go for full C99 conformance? I would be
more interested in a "real" C99 compiler rather than have C++
features wander over. (And no, I do not need anyone slandering
Jacob and his compiler along the vein of "He cannot provide even
C89".)


Cheers
Michael

 

[dandelion]

Well, keep the advertising of non-standard solutions clearly separated
from your standard C answers. I, for one, am interested in a look
behind the scenes but not necessarily in this newsgroup.



I think this is a "dangerous" argument as this would mean that I
should be able to do the same things all standard library functions
do within the scope of the language. And portably.
The repercussions of this are IMO very clear and not very nice.

My major concern is that 'crreeping featurism' will make 'C' a lot 'fatter'
and less usable on very small platforms. As it is, i have trouble enough
with memory-footprints and the thing I like about 'C' is that good compilers
tend to churn out nice and small code.

Operator overloading, IMHO is one of the nicer features of C++, allthough it
does have the potential of blatant misuse. OTOH, almost any language feature
has that.

(And no, I do not need anyone slandering
Jacob and his compiler along the vein of "He cannot provide even
C89".)

Expect no slander from me. Anyone who succeeds in implementing serious
compilers (in contrast to toy-languages) has my full admiration. The attempt
alone will yield my applause and best wishes.

dandelion

 

[Chris Croughton]

This fact, and the fact that the C99 comitee introduced overloaded
functions like sqrt, sin, pow, etc, led me to implement operator
overloading within a C context. This has been very useful to implement
all kind of numbers just extending the C99 overloaded functions to them.

For instance the qfloat type (350 bits) has been implemented this way.

To avoid gratuituos incompatibilities with C++ I use the same syntax.

qfloat operator+(qfloat &,qfloat b);

How did you implement it in standard C? That is not valid C syntax, it
will give an error on any conforming C compiler.

If you mean that you wrote a compiler for some language C(extended)
which is neither C nor C++ but which contains some features from both,
that is your privilege but it has nothing to do with either C or C++.

If the designers of C99 needed this feature and proposed an overloaded
sqrt/pow/sin/ etc functions why shouldn't the user be able to solve this
in his/her context as well?

Because it isn't in the standard, therefore programs using it won't be
portable. If you want to suggest it for the standard, join the
appropriate standards organisations and make your point there.

If the implementor of a language needs a feature, the user needs it as
well and should be allowed to have it.

In the case of typeof() (which is needed -- or some similar mechanism --
to implement the overloaded maths functions), I agree that they should
have put it into the language. And/or left out the weird overloaded
functions (which would be my preference, I see no point in them and a
number of potential bugs).

Chris C

 

[jacob navia]

BTW: Are you going to go for full C99 conformance? I would be
more interested in a "real" C99 compiler rather than have C++
features wander over. (And no, I do not need anyone slandering
Jacob and his compiler along the vein of "He cannot provide even
C89".)

The big part of this is the writing of a C99 compliant C library.

It is done for the math.h, but I have still some problems with complex
numbers. I have implemented all complex numbers a long double _Complex
to avoid the incredible proliferation of library functions needed
to support all combinations of complex functions:

double _Complex casin(double _Complex)
float _Complex casinf(float _Complex)
long double _Complex casinl(long double _Complex)

etc!

What language features is concerned I support already variable
length arrays, dynamically allocate data in the stack, and actually
most features.

Missing are:

named arguments initialization
variable arguments macros

I support already anonymous literals, and all other features.

jacob

 

[jacob navia]

The memory footprint of the generated code doesn't change
at all.

It is the same code size if I write:

qfloat c = AddQfloat(a,b);

or if I write:

qfloat c = a+b;

Note that IN C, there isn't any constructors/destructors
or other implicit function calls. The code generated will
be a call to the user defined function.

Besides, this is completely an optional feature:
you do not use it?

You do NOT pay for it. Yes, the compiler will be slightly larger
but the generated code STAYS 100% the same!

This is just syntatic sugar for function calls,
allowing for a more rational notation.

Operator overloading is best used for numbers, numbers of
any kind.

Example 1:
----------
Within many embedded systems, fixed point numbers are common.
The problem is that all software must be rewritten to use them:

For this code:

double c = 2.3;
c /= (c*49.876);

You have to rewrite:

FixedPoint c = DoubleConstantToFixed(2.3);
c = DivFixed(c,MultFixed(c,DoubleConstantToFixed(49.876)));

It would be MUCH better to be able to just port the code like this

FixedPoint c = 2.3;
c /= (c*49.876);

isn't it?

With operator overloading you just supply the conversion functions!

This allows you to easily port floating point software to a platform
without FPU without adding a HUGE floating point emulator and with a lot
of less effort.

There are some standadization attempts to be able to use fixed point
in embedded systems, but they are much less general and much less easy
to use than this simple enhancement of the basic language.

Example 2
---------
A similar problem appears when you try to implement numbers that support
clamped addition (MMX in the x86). For instance

Current c:

unsigned char c = 254;
unsigned char d = 3;

char r = c+d; // r is now 1

Clamped addition:
r = c+d ; // r is now 255

To be able to do this you have to rewrite all code using
function calls.

r = ClampledAdd(c,d);

Clamped addition is necessary when you are adding intensities
for instance, to avoid that adding a bit of white to an
almost white color results in a black pixel!

jacob

 

[Dan Pop]

BTW: Are you going to go for full C99 conformance? I would be
more interested in a "real" C99 compiler rather than have C++
features wander over. (And no, I do not need anyone slandering
Jacob and his compiler along the vein of "He cannot provide even
C89".)

I'm entirely convinced that Jacob *can* provide full C89 conformance,
my criticism is that he doesn't do it when the compiler is invoked in
ANSI conforming mode. More precisely, that his ANSI conforming mode
doesn't conform to any known C standard. Which is completely
disqualifying it from being advertised in this newsgroup.

Dan

 

[Dan Pop]

Expect no slander from me. Anyone who succeeds in implementing serious
compilers (in contrast to toy-languages) has my full admiration. The attempt
alone will yield my applause and best wishes.

The compiler was written by other people. Jacob merely "extended" it.

Dan

 

[Dan Pop]

The rationale for this is as follows:

If the designers of C99 needed this feature and proposed an overloaded
sqrt/pow/sin/ etc functions

They're merely type-generic *macros*, not overloaded functions. They're
modelled after FORTRAN 77's generic functions and not after *any* C++
feature. And the only language extension needed to implement them is
something like gcc's __builtin_types_compatible_p().

why shouldn't the user be able to solve this
in his/her context as well?

Because the user knows where to find C++ if he needs this feature.

One of the *fundamental* properties of C code is that it can be taken at
face value (very little happens behind the scenes). Operator and
function overloading destroy this property, so they cannot be considered
as harmless extensions to the language.

A C standard introducing support for function/operator overloading would
be even less popular among the C community than C99.

C89 did a fairly good job of adopting *all* the C++ features that could be
integrated into C without changing the fundamental nature of the language.

I don't mind new features into the language (all GNU C extensions are OK)
as long as the spirit of the language designed by Dennis Ritchie is
preserved.

Dan

 

[Dave Vandervies]

(And no, I do not need anyone slandering
Jacob and his compiler along the vein of "He cannot provide even
C89".)

Except that it's not "can't" that we're complaining about; it's "can't
be bothered to". It's hard to be taken seriously when you build a C
compiler that doesn't make an effort to comply with any known C standard,
even when hit the user hits it over the head with requests to not use
any incompatible extensions. It's even harder to be taken seriously
when you claim that this is a Good Thing.


dave

 

[Mark McIntyre]

On 26 Nov 2004 01:14:29 GMT, in comp.lang.c , "S.Tobias"

(responding my my comment)

Not exactly: a user cannot redefine operator+ for built-in types.

Ths sort-of makes my point. Overloading is a user feature in C++. There is
no such feature in C. The implementation may use all sorts of tricks, but
thats not relevant.

 

[Mark McIntyre]

If the implementor of a language needs a feature, the user needs it as
well and should be allowed to have it.

This is utter bullshit. Implementors need to manipulate registers, disk
drives, display devices, modem control lines. Users do not. Unless your
implementor is useless of course.

 

[S.Tobias]

On 26 Nov 2004 01:14:29 GMT, in comp.lang.c , "S.Tobias"
<[email protected]> wrote:

(responding my my comment)

Ths sort-of makes my point. Overloading is a user feature in C++. There is
no such feature in C. The implementation may use all sorts of tricks, but
thats not relevant.

What you are thinking of is user-defined overloading, which C
does not supply, true. But it does not mean that the language
definition can't overload operators. (Actually, we should speak
about overloading of _names_.)
http://dict.die.net/overloading/