E
E. Robert Tisdale
Mabden said:
I think that you have just described function *overriding*.
JaSeong Ju may have meant
function overriding instead of function overloading.
I think that you have just described function *overriding*.
JaSeong Ju may have meant
function overriding instead of function overloading.
K
Keith Thompson
Mabden said:
Yes, you certainly could, but I fail to see how this addresses the
OP's question.
A wrapper provides a new function, with a new name, that extends the
functionality of an existing function. Overloading provides two or
more functions with the same name.
Would you care to clarify what you meant?
J
Jack Klein
It would have been better perhaps if Jacob had stated: "lcc-win32 is a
compiler that supports function overloading as an extension", but I
think your reaction is a little overboard.
If a compiler supported signed and unsigned long long types or a
built-in Boolean type five years ago, it wasn't a strictly conforming
C compiler either, at least not when operated in a mode where these
things existed.
One of the most practical ways to propose the addition of features to
new generations of a language like C is not only to propose them, but
to show an existing implementation. Then the pros and cons become
directly testable and not merely theoretical.
Whether or not you or I think function overloading is something that
should be added to C is irrelevant.
At least compiler vendor has implemented <tgmath.h> functionality by
temporarily switching their implementation into C++ "mode" while
processing the header, which in their version contains ordinary C++
overloaded functions. At the end of the header it switches back to C
"mode", but the processed prototypes remain in the symbol table. The
proper overloaded function is called based on the types of the
arguments in the C source.
In fact, providing these as special case overloaded functions if
probably the simplest way to implement <tgmath.h> functionality in C,
and is of course perfectly legal for an implementation to do so.
K
Keith Thompson
E. Robert Tisdale said:
But overriding usually (I think) means providing a new function with
the same name. C doesn't support that either.
M
Mark McIntyre
Because of 6.9(2) I think
"There shall be no more than one external definition for each identifier
declared with internal linkage in a translation unit. Moreover, if an
identifier declared with internal linkage is used in an expression (other
than as a part of the operand of a sizeof operator whose result is an
integer constant), there shall be exactly one external definition for the
identifier in the translation unit."
C
Christian Bau
Mark McIntyre said:
Which means any program using function overloading would invoke
undefined behavior according to the C Standard (that is what the _shall_
means). An implementation is free to define the behavior in this case.
So your program is definitely not a C program, but a C compiler may
still accept it; some error messages may be required.
S
Stephen Sprunk
Christian Bau said:
Non-conforming compilers are free to accept non-conforming code without
generating errors. The compilers I've worked with (gcc, icc, msvc) are not
strictly conforming in their default mode, but at least one of them can be
invoked as such if desired.
Function overloading is unusual because it requires breaking the ABI for a
given platform; most compiler extensions I've used only involve
non-conforming source, not broken binaries.
S
M
Mark McIntyre
Provided "some... may" means "at least one ... must"
A conforming compiler is free to accept anything at all, provided it
produces at least one diagnostic. It could accept the Grays Anatomy, or the
WEB source for Pascal, either before or after being tangled or woven.
If it does something with it other than produce the diagnostic, its not a
ISO C compiler, its something else.
M
Mark McIntyre
Yup.
Meaningless statement. Non-conforming compilers are free to set fire to
your hair and paint your toenails green too.
Meaningless statement. Non-conforming compilers are free to set fire to
your hair and paint your toenails green too.
A
Arthur J. O'Dwyer
And provided "must be" means "is". ;-)
Not true. It might produce the diagnostic and *then* do something
else, such as setting fire to your toenails; and still remain conforming.
What it could *not* do would be to set fire to your toenails without
first producing at least one diagnostic (such as "look out, your toenails
are on fire"). [Cf early (C90) versions of gcc, which according to legend
would treat '#pragma' as a request to launch 'rogue'. Did that make gcc
non-conforming because ISO didn't mention 'rogue' in the Standard? No.
It merely made gcc perverse.]
IOW, getting back to the point that started this whole subthread
(AFAICT): Jacob's lcc-win32 compiler *may be* a conforming C compiler,
even though it incorporates non-ISO extensions, as long as it also
incorporates a standard C compiler. (Yet discussion of lcc-win32 is
just as off-topic here as is discussion of any other specific
implementation.)
Any *program* that takes advantage of lcc-win32's non-ISO extensions,
however, is most definitely not a standard C program --- and thus would
also be off-topic in this group.
Still, discussion of lcc-win32's conformance to the Standard, and the
cute features that make it conforming despite all its crazy extensions,
would IMHO be topical here.
-Arthur
J
jacob navia
Mark McIntyre said:
lcc-win32 (when invoked without the -ansic flag) is not just an ISO C
compiler.
It will provide you with a shorthand notation where you give
a common name to a set of related routines.
This is nothing really new, and many languages provide this facility.
Instead of writing
int fn_int(int a);
int fn_long_double(long double a);
int fn_foo(foo a);
AD NAUSEUM
you have to remember only ONE name. Easy with the neuron's
random access memory. It shouldn't be wasted storing trivial
facts like zig different names for each variant of the same routine.
Of course this isn't in ISO C 89. But in 99, the C standard accepted
the "principle" that this construct *is* useful and provided a
SINGLE sqrt function without you having to remember 3 names for
each different function.
#include <tgmath.h>
I am confident that the 2009 edition will make the next logical
step and provide this for everybody according to the principle:
"If the implementor needs a certain feature the user needs it too".
M
Mark McIntyre
Frankly, and don't take offense, thats a ludicrous principle. The
implementor of a steel hulled ship needs a rivet gun. Passengers on the
boat don't.
G
Gordon Burditt
A conforming compiler is free to accept anything at all, provided it
Where in ANSI C does it say that the diagnostic must be produced
*FIRST*? Why couldn't the diagnostic be "your toes have burned
off", after you've arrived at the emergency room, or even after
you've gotten the bill?
It gets even messier when undefined behavior starts violating
temporal causality or invokes time travel. It gets even tricker
when undefined behavior retroactively alters the ANSI C standard.
For example, I think it was a "void main" program posted to comp.lang.c
that removed function concatenation from ANSI C.
(function concatenation: func = funccat(func1, func2) returns a
function pointer so that func(x) acts the same as func1(func2(x))
except that it calls private copies, not originals, of func1 and
func2 (meaning that any static or file-scope variables referenced
by func1 and func2 are not shared with the function called by func()
.. The function pointer returned by funccat *MUST* be cast to void
TWICE and passed to free() before terminating the program).
I believe I actually saw this one work.
Gordon L. Burditt
Where in ANSI C does it say that the diagnostic must be produced
*FIRST*? Why couldn't the diagnostic be "your toes have burned
off", after you've arrived at the emergency room, or even after
you've gotten the bill?
It gets even messier when undefined behavior starts violating
temporal causality or invokes time travel. It gets even tricker
when undefined behavior retroactively alters the ANSI C standard.
For example, I think it was a "void main" program posted to comp.lang.c
that removed function concatenation from ANSI C.
(function concatenation: func = funccat(func1, func2) returns a
function pointer so that func(x) acts the same as func1(func2(x))
except that it calls private copies, not originals, of func1 and
func2 (meaning that any static or file-scope variables referenced
by func1 and func2 are not shared with the function called by func()
.. The function pointer returned by funccat *MUST* be cast to void
TWICE and passed to free() before terminating the program).
I believe I actually saw this one work.
Gordon L. Burditt
J
jacob navia
Mark McIntyre said:
This doesn't hold. Users of compilers are building software, as the
compiler implementor is doing. Passangers aren't building ships.
Users of C programs do not need overloading of functions, agreed.
But users of C compilers do, since they are in exactly the same
business as the compiler implementor: they are building software.
R
Richard Tobin
K
Keith Thompson
Mark McIntyre said:
As far as I can tell, conforming compilers are equally free to set
fire to your hair and paint your toenails green.
C
CBFalconer
jacob said:
All this is a way of further reducing the already poverty-stricken
internal checking and inherently minimal redundancy of C code,
thus leading to ever increasing density of programmer errors,
reduction of trust in software, and proliferation of subject
matter for the comp.risks newsgroup.
H
Harti Brandt
On Tue, 1 Jun 2004, jacob navia wrote:
jn>Instead of writing
jn>
jn>int fn_int(int a);
jn>int fn_long_double(long double a);
jn>int fn_foo(foo a);
jn>
jn>AD NAUSEUM
jn>
jn>you have to remember only ONE name. Easy with the neuron's
jn>random access memory. It shouldn't be wasted storing trivial
jn>facts like zig different names for each variant of the same routine.
One of the problem is that this makes programs harder to read if you
didn't write them. In C a line like
a = fn_int(b, c);
just requires you to lookup the definition for fn_int() to see what
happens. With overloading the line:
a = fn(b, c);
requires you to lookup the definition of b, c and a, lookup their types,
then to lookup fn() for the correct combination of types.
\begin{OT}
Even worse in C++ it requires you to lookup the inheritance
hierarchy for the types of b and c, all the possible candidate functions
that could be called here (taking into account type conversion
constructors), to remember the complex ruleset that directs the lookup of
the function and then to find out which functions really gets called here.
\end{OT}
Additionally there is, of course, no guarantee that fn(int, int) does more
or less the same as fn(long, int).
harti
jn>Instead of writing
jn>
jn>int fn_int(int a);
jn>int fn_long_double(long double a);
jn>int fn_foo(foo a);
jn>
jn>AD NAUSEUM
jn>
jn>you have to remember only ONE name. Easy with the neuron's
jn>random access memory. It shouldn't be wasted storing trivial
jn>facts like zig different names for each variant of the same routine.
One of the problem is that this makes programs harder to read if you
didn't write them. In C a line like
a = fn_int(b, c);
just requires you to lookup the definition for fn_int() to see what
happens. With overloading the line:
a = fn(b, c);
requires you to lookup the definition of b, c and a, lookup their types,
then to lookup fn() for the correct combination of types.
\begin{OT}
Even worse in C++ it requires you to lookup the inheritance
hierarchy for the types of b and c, all the possible candidate functions
that could be called here (taking into account type conversion
constructors), to remember the complex ruleset that directs the lookup of
the function and then to find out which functions really gets called here.
\end{OT}
Additionally there is, of course, no guarantee that fn(int, int) does more
or less the same as fn(long, int).
harti
J
jacob navia
Harti Brandt said:
Since lcc-win32 is NOT a C++ compiler we are lucky: this doesn't apply here.
M
Mark McIntyre
Passengers are using the ship, just like I'm using the compiler. And just
Frankly, if you want C++, you know where it is.
And BTW all this arguing just persuades me not to use your C compiler, I
could never trust it to do what its supposed to. I'd rather trust MS which
is a terrible indictment I reckon...