NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/cplus/18825

Text File | 1993-01-07 | 3.5 KB | 79 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsk!pegasus!hansen
From: [e-mail] (Tony L. Hansen)
Subject: Re: Standard library functions and macros
Organization: AT&T
Date: Fri, 8 Jan 1993 04:01:02 GMT
Message-ID: <[e-mail]>
Summary: cannot overload functions with macros present
Keywords: c++, ansi c
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (tony.l.hansen)
Lines: 65

< From: [e-mail] (Jim Adcock)
<
< No, I do not disagree with this part of the decision.  I simply disagree
< that it makes sense to return the vast majority of the standard functions
< namespace to the programmer.  On the contrary I claim that the vast
< majority of these names should remain in the implementation space, because
< implementing them as macros, or providing alt implementations, as in the
< Sun example, remain useful and viable options to the implementation.
< Whereas the vast majority of the names in question represent deliberately
< "decorated" or "mangled" names if you will that have little or no
< applicability to the C++ programmer as useful member function names, or
< even global names. So in the vast majority of cases your suggested changes
< destroy utility on the implementor's side without corresponding increase
< in utility on the programmer's side.  This is clearly a bad trade-off.
< Again, if you want to go through the functions in a sensible manner, and
< choose certain names such as "free" that have plausible utility to the end
< programmer, and insist on non-macro and non-overloaded implementation of
< these functions, such that the name-space remains available to the
< programmer, then I would agree with such a thoughtful, well-considered,
< measured approach.  I just disagree with the blanket changes that have
< been proposed to date.

As long as the C functions are permitted to be implemented as macros, it is
impossible to reliably overload any function name found in the C library.

For example, consider

    #include <math.h>
    class complex ...
    complex sqrt(complex&);

This looks pretty safe, right? Wrong!

Consider what happens with the following definition of sqrt() in <math.h>:

    #define sqrt(x)    __asm(push x; call sqrt;)

Oops, that safe looking declaration of sqrt(complex&) suddenly looks like
this:

    complex push(complex&); call sqrt;

Not so pretty looking now, is it?

Do you think it's reasonable to be able to overload functions such as
fprintf() and rewind() for a type such as "File" instead of "FILE"? How
about a function such as the string functions which all start with str*?
Would you like to be able to overload those for a String class? Or how about
overloading qsort() or bsearch() as template functions which work on an
array of T instead of a void* memory area? Or how about overloading the time
functions, such as difftime() and time(), for a Time class? How about
overloading the math functions, such as sin() and tan(), using a float
instead of a double?

I think all of the above are within reasonable expectations. And guess what?
You've just covered over half of the list of ANSI C functions. And, as long
as the C functions are permitted to be implemented as macros, you won't be
able to overload any of them!

I'm not willing to lose that capability.

                    Tony Hansen
                [e-mail], [e-mail]
                att!pegasus!hansen, attmail!tony