Function Overloading

**Neil Cerutti** · Nov 14 '05, 06:49 AM

Re: Function Overloading

In article <40a2e150$0$306 $7a628cd7@news. club-internet.fr>,
Guillaume wrote:[color=blue][color=green]
>> What risks do you see?[/color][/color]
[color=blue]
> 1. Code becomes quickly difficult to understand. Or worse: it
> makes you think you understand it, when you actually don't.
>
> 2. As any other kind of superfluous facility, it's an incentive
> to use and abuse it.
>
> 3. There can be some nasty "ambiguous overloading" bugs. I've
> seen it many times in C++ code. Not all compilers are able to
> catch them. It can especially happen with operator overloading.
>
> 4. It makes you "overload" functions that you think are
> functionnally similar. It may later on turn out that they are
> not so similar, but by the time you realize that, hundreds of
> other functions may depend on them. A hell to maintain.
>
> 5. It's usually some overhead at run-time (although this point
> may not qualify as a "risk"). And a huge overhead at compile
> time, which has its importance when you work on very big
> projects (might not want to wait for hours while your code
> compiles...)
>
> 6. Speaking of overhead, they often imply security issues
> through the use of "v-tables". I'm not getting into details
> here, but many papers have been written on the subject.[/color]

Based on that last point, I think we might have different things
in mind. The function overloading I thought you meant is static,
compile time polymorphism, like that used for C's operators.

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

**Dan Pop** · Nov 14 '05, 06:49 AM

Re: Function Overloading

In <2ghjabF2tts5U1 @uni-berlin.de> Neil Cerutti <horpner@yahoo. com> writes:
[color=blue]
>In article <c7vj4o$js6$3@s unnews.cern.ch> , Dan Pop wrote:[color=green]
>> In <2gffifF29qjuU2 @uni-berlin.de> Neil Cerutti <horpner@yahoo. com> writes:
>>[color=darkred]
>>>In article <c7tofr$d6d$1@s unnews.cern.ch> , Dan Pop wrote:
>>>> In <2gf68cF214cbU1 @uni-berlin.de> Neil Cerutti
>>>> <horpner@yahoo. com> writes:
>>>>
>>>>>In article <40a2332a$0$314 $7a628cd7@news. club-internet.fr>,
>>>>>Guillaum e wrote:
>>>>>>> Overloaded functions are already just syntactic sugar.
>>>>>>
>>>>>> I agree, I think they also are syntactic sugar in C++.
>>>>>>
>>>>>> I see in them more potential risks than benefits.
>>>>>
>>>>>What risks do you see?
>>>>
>>>> Code that becomes a hell to understand and maintain.
>>>
>>>There's no way to avoid risking that, apart from not
>>>programmin g.[/color]
>>
>> Until now I've been quite successful at avoiding this risk
>> while programming in C.[/color]
>
>It depends how you define risk. I would say that, even though
>you haven't yet written code that you believe has become a hell
>to understand and maintain, you have still risked doing so by
>writing programs. If you weren't risking it, there would be no
>reason to follow good programming practice.[/color]

That's the point: by following good programming practices I avoid the
risk.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

**Neil Cerutti** · Nov 14 '05, 06:49 AM

Re: Function Overloading

In article <c807hh$m3k$1@s unnews.cern.ch> , Dan Pop wrote:[color=blue]
> In <2ghjabF2tts5U1 @uni-berlin.de> Neil Cerutti <horpner@yahoo. com> writes:
>[color=green]
>>In article <c7vj4o$js6$3@s unnews.cern.ch> , Dan Pop wrote:[color=darkred]
>>> In <2gffifF29qjuU2 @uni-berlin.de> Neil Cerutti <horpner@yahoo. com> writes:
>>>
>>>>In article <c7tofr$d6d$1@s unnews.cern.ch> , Dan Pop wrote:
>>>>> In <2gf68cF214cbU1 @uni-berlin.de> Neil Cerutti
>>>>> <horpner@yahoo. com> writes:
>>>>>
>>>>>>In article <40a2332a$0$314 $7a628cd7@news. club-internet.fr>,
>>>>>>Guillau me wrote:
>>>>>>>> Overloaded functions are already just syntactic sugar.
>>>>>>>
>>>>>>> I agree, I think they also are syntactic sugar in C++.
>>>>>>>
>>>>>>> I see in them more potential risks than benefits.
>>>>>>
>>>>>>What risks do you see?
>>>>>
>>>>> Code that becomes a hell to understand and maintain.
>>>>
>>>>There's no way to avoid risking that, apart from not
>>>>programming .
>>>
>>> Until now I've been quite successful at avoiding this risk
>>> while programming in C.[/color]
>>
>>It depends how you define risk. I would say that, even though
>>you haven't yet written code that you believe has become a hell
>>to understand and maintain, you have still risked doing so by
>>writing programs. If you weren't risking it, there would be no
>>reason to follow good programming practice.[/color]
>
> That's the point: by following good programming practices I
> avoid the risk.[/color]

I guess that about covers is. ;-)

--
Neil Cerutti
"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

**Ross Kendall Axe** · Nov 14 '05, 06:49 AM

Re: Function Overloading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Dickopp wrote:
| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
|
[snip]
|
| Function overloading can trivially be implemented using "name mangling",
| which involves no run-time overhead.
|

But leads to annoying link-time problems when used with libraries...

[snip]
|
| Martin
|
|

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAo+1S9bR 4xmappRARAqz+AJ 96zPp8HZlBByG30/LMOehSzy0cdACfR GGV
n01s6jTKPiF6tTG OfhbBuu4=
=/zzp
-----END PGP SIGNATURE-----

**Martin Dickopp** · Nov 14 '05, 06:49 AM

Re: Function Overloading

Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:
[color=blue]
> Martin Dickopp wrote:
> | Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
> |
> | Function overloading can trivially be implemented using "name mangling",
> | which involves no run-time overhead.
>
> But leads to annoying link-time problems when used with libraries...[/color]

Not really. Name mangling is common among C++ implementations , yet no
annoying link-time problems arise with C++ programs.

Martin

--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

**Ross Kendall Axe** · Nov 14 '05, 06:50 AM

Re: Function Overloading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Dickopp wrote:
| Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:
|
|
|>Martin Dickopp wrote:
|>| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
|>|
|>| Function overloading can trivially be implemented using "name mangling",
|>| which involves no run-time overhead.
|>
|>But leads to annoying link-time problems when used with libraries...
|
|
| Not really. Name mangling is common among C++ implementations , yet no
| annoying link-time problems arise with C++ programs.
|
| Martin
|
|

Fair enough, I'll believe you :-) I don't use C++ personally, but I
heard there were problems sometimes, but it could just have been in a
theoretical sense.

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFApAxh9bR 4xmappRARAus/AJ44PDXYLKpLynb QW+ibj2vY9nJtEQ CgmVNA
87aQ2Tqa0Fsz4hJ 33pMisxQ=
=wy5x
-----END PGP SIGNATURE-----

**Martin Dickopp** · Nov 14 '05, 06:50 AM

Re: Function Overloading

Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:
[color=blue]
> Martin Dickopp wrote:
> | Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:
> |
> |
> |>Martin Dickopp wrote:
> |>| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
> |>|
> |>| Function overloading can trivially be implemented using "name mangling",
> |>| which involves no run-time overhead.
> |>
> |>But leads to annoying link-time problems when used with libraries...
> |
> |
> | Not really. Name mangling is common among C++ implementations , yet no
> | annoying link-time problems arise with C++ programs.
>
> Fair enough, I'll believe you :-) I don't use C++ personally, but I
> heard there were problems sometimes, but it could just have been in a
> theoretical sense.[/color]

To be fair, there /were/ (maybe still are) problems, but they were not
related to the fact that name mangling was used, but that different
compilers used it in different ways. You could therefore not necessary
link together code compiled by two differernt C++ compilers, even on the
same system.

The same problem would arise with two C compilers if they (e.g.) passed
arguments to functions in different ways. So this is nothing specific
to C++ or name mangling.

Martin

--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

**Ross Kendall Axe** · Nov 14 '05, 06:52 AM

Re: Function Overloading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Dickopp wrote:
| Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:
|
|
|>Martin Dickopp wrote:
|>| Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:
|>|
|>|
|>|>Martin Dickopp wrote:
|>|>| Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:
|>|>|
|>|>| Function overloading can trivially be implemented using "name
mangling",
|>|>| which involves no run-time overhead.
|>|>
|>|>But leads to annoying link-time problems when used with libraries...
|>|
|>|
|>| Not really. Name mangling is common among C++ implementations , yet no
|>| annoying link-time problems arise with C++ programs.
|>
|>Fair enough, I'll believe you :-) I don't use C++ personally, but I
|>heard there were problems sometimes, but it could just have been in a
|>theoretical sense.
|
|
| To be fair, there /were/ (maybe still are) problems, but they were not
| related to the fact that name mangling was used, but that different
| compilers used it in different ways. You could therefore not necessary
| link together code compiled by two differernt C++ compilers, even on the
| same system.
|

Glad I wasn't imagining the C++ name mangling problem after all.

| The same problem would arise with two C compilers if they (e.g.) passed
| arguments to functions in different ways. So this is nothing specific
| to C++ or name mangling.

Quite true. Under Windows, for example, there are 2 popular calling
conventions, either caller pops the arguments off the stack or the
callee pops the arguments. Of course, you could also imagine args being
passed in registers as an optimisation, or any number of other
platform-specific methods. Indeed, Linux kernel modules compiled with
one version of gcc are not expected to work with a kernel compiled with
another version of gcc.

That said, I would say that C's simplicity make calling convetions much
easier to agree on, and function overloading (with it's associated name
~ mangling) exacerbates to problem.

|
| Martin
|
|

Having thought a bit more, I remember now that the linking problems I
was originally thinking of referred more to classes than overloaded
functions. Again, I'm sure that linking a class is *theoretically* not
much harder than linking standard C functions, but the complexity of the
problem means that there are many more plausible ways of doing it, thus
leading to disparities between different compilers.

However, with something as simple as a C function call, there are very
few obvious ways to do it.

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFApWbN9bR 4xmappRARAkX+AJ 47O9P0uKS8ge/KSXiC8kr6i6k4ug CgrFpM
UPVEVryJJvyXUi+ 3RAMuPFc=
=CU20
-----END PGP SIGNATURE-----

**James Kanze** · Nov 14 '05, 07:06 AM

Re: Function Overloading

Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:

|> > What risks do you see?

|> 1. Code becomes quickly difficult to understand. Or worse: it makes
|> you think you understand it, when you actually don't.

You don't need function overloading for that:-).

|> 2. As any other kind of superfluous facility, it's an incentive to
|> use and abuse it.

As you say, it is true for just about any facility. It's a negative
point; to justify any facility, you have to provide offsetting positive
points.

|> 3. There can be some nasty "ambiguous overloading" bugs. I've seen
|> it many times in C++ code. Not all compilers are able to catch them.
|> It can especially happen with operator overloading.

The answer to that is simple: don't use C++'s complex rules for overload
resolution.

|> 4. It makes you "overload" functions that you think are
|> functionnally similar. It may later on turn out that they are not so
|> similar, but by the time you realize that, hundreds of other
|> functions may depend on them. A hell to maintain.

See point 1. You can misname functions just as badly without
overloading.

|> 5. It's usually some overhead at run-time (although this point may
|> not qualify as a "risk"). And a huge overhead at compile time, which
|> has its importance when you work on very big projects (might not
|> want to wait for hours while your code compiles...)

Overloading is fully resolved at compile time. Runtime overhead is 0.

The amount of compile time overhead depends on the complexity of the
overload resolution rules (see point 3) -- although it is never totally
free, it doesn't have to be huge.

|> 6. Speaking of overhead, they often imply security issues through
|> the use of "v-tables". I'm not getting into details here, but many
|> papers have been written on the subject.

I think you're thinking of virtual functions, not overloading.
Overloading doesn't involve v-tables or any runtime mechanism.

In the end, like everything else, it is a tradeoff. Generally speaking,
concerning the positive aspects, I would say:

- It is almost essential to write good mathematical software (and some
business software). But for that, you need not only function
overloading, but full user defined types, with operator overloading
as well. What good is being able to write sin(aBigDecimal ) if I have
to write bigDecimal1.add ( bigDecimal2 ), rather than bigDecimal1 +
bigDecimal2?

- It can be very useful in certain cases of generic programming: C++
templates or perhaps some fancy macro generated code in C.

Offsetting those advantages is that the overloading rules almost have to
be complicated in C/C++, given the number of implicit conversions the
languages support. And it isn't so much overloading itself that costs,
it is the complexity of the overload resolution rules, which means that
1) the compiler has a lot of work to do, and 2) even more important, it
becomes a real guessing game for whoever reads to program to know what
function actually is going to be called.

I work mostly in C++, where I have overloaded functions. From
experience, I really only use them in the following cases:

- constructors -- C++ requires all constructors for a given class to
have the same name, so you don't have much choice,

- smart pointers -- this is a very C++ specific technic for resource
management, and totally irrelevant in C, and

- my BigDecimal class, which implements full the decimal arithmetic I
need for some commercial applications.

IMHO, only the last is in the least way relevant to C, and I'm not sure
that just simple function overloading is the best answer (in C).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

**James Kanze** · Nov 14 '05, 07:06 AM

Re: Function Overloading

Martin Dickopp <expires-2004-06-30@zero-based.org> writes:

|> Ross Kendall Axe <ross.axe@bluey onder.co.uk> writes:

|> > Martin Dickopp wrote:
|> > | Guillaume <grsNOSPAM@NO-SPAMmail.com> writes:

|> > | Function overloading can trivially be implemented using "name
|> > | mangling", which involves no run-time overhead.

|> > But leads to annoying link-time problems when used with
|> > libraries...

|> Not really. Name mangling is common among C++ implementations , yet
|> no annoying link-time problems arise with C++ programs.

That's not really true. If I compile a function in C with gcc, I can
link it with an application compiled with Sun cc; if I compile a
function in C++ with g++, I cannot link it with an application compiled
with Sun CC. The linker complains.

In fact, there are many reasons for this, and the compilers use
different mangling schemes intentionally, so that I get the error at
link time, rather than some strange run-time error. There would be no
reason for C compilers to use different manglings. But they probably
would; gcc would use a mangling compatible with g++, and Sun cc a
mangling compatible with Sun CC.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34