In article <CI0p9J.FpM@ucc.su.oz.au>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>In article <CHtC27.5Fx@ses.com> jamshid@ses.com (Jamshid Afshar) writes:
>>So Standard C++ functions will not be allowed to be implemented as
>>macros (except, I guess for some things like va_arg())?.  That's good;
>>free, pow, exit, str*, rewind, etc. are useful member function/data
>>names.
> No, I dont think it means that. Obviously,
>macros cant be controlled by namespaces.

I believe Standard C allows any standard library function to be
implemented as a macro as long it doesn't have side-effects not
specified by the standard.  This means that a C program couldn't use
`atoi' as a local variable if <stdlib.h> was #included.  I thought
ANSI/ISO already resolved that C++ headers were not allowed to do that
and that users could, for example, define an overloaded atoi():

 int atoi(const MyString&);

Am I wrong in thinking this particular issue has already been
resolved?

Jamshid Afshar
jamshid@ses.com

In article <CIEILy.KHL@ses.com> jamshid@ses.com (Jamshid Afshar) writes:
>In article <CI0p9J.FpM@ucc.su.oz.au>,
>John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>>In article <CHtC27.5Fx@ses.com> jamshid@ses.com (Jamshid Afshar) writes:
>>>So Standard C++ functions will not be allowed to be implemented as
>>>macros (except, I guess for some things like va_arg())?.  That's good;
>>>free, pow, exit, str*, rewind, etc. are useful member function/data
>>>names.
>> No, I dont think it means that. Obviously,
>>macros cant be controlled by namespaces.
>
>I believe Standard C allows any standard library function to be
>implemented as a macro as long it doesn't have side-effects not
>specified by the standard.  This means that a C program couldn't use
>`atoi' as a local variable if <stdlib.h> was #included.  I thought
>ANSI/ISO already resolved that C++ headers were not allowed to do that
>and that users could, for example, define an overloaded atoi():
>
> int atoi(const MyString&);
>
>Am I wrong in thinking this particular issue has already been
>resolved?

 No, I believe you are basically correct. But its not
that simple, for example consider <limits.h>. Are these
to be implemented with #define or using 'const' variables?
Or both?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CHtC27.5Fx@ses.com> jamshid@ses.com (Jamshid Afshar) writes:
>>
>>The library working group is putting the whole standard library
>>in namespaces .. including the C library.
>>
>>In effect that means that one identifier is reserved
>>by the library, probably "std" or "iso" or something.
>>
>So Standard C++ functions will not be allowed to be implemented as
>macros (except, I guess for some things like va_arg())?.  That's good;
>free, pow, exit, str*, rewind, etc. are useful member function/data
>names.

 No, I dont think it means that. Obviously,
macros cant be controlled by namespaces.
>
>Do you think Standard C++ will also disallow macros for constants such
>as those defined in <limits.h>?  It would be nice to reclaim *_MIN and
>*_MAX for the user (I think ANSI C reserves any identifiers matching
>those patters, or maybe I'm thinking of POSIX).
>
>>None of this applies to macros, however, but they aren't really
>>part of the language proper. (Boy, I'd sure like to deprecate
>>that stupid preprocessor  :-)
>
>What do you mean by "none of this applies to macros"?  That the user
>can't define macros with the same name as Standard C++ functions?
>That's reasonable.  But, my original question was will Standard C++
>headers, as opposed to Standard C headers, be allowed to use
>identifiers in the user's namespace for non-standard functions like
>filebuf::fd()?  Or, must the implementation stick to identifiers with
>double underscores for implementation-specific functions, formal
>parameter names, private members, etc?

 The exact form is under discussion but: the idea is
if you #include <fred.h> you get fred functions, as in C.
If you #include <fred> without the .h, you get a namespace
for fred. In this case, you can define your own function
'hello()' whether the namespace contains 'hello()' or not.

 That is, only the top level namespace name
is a reserved word for FUNCTIONS.

 For something that might be a macro, I dont know.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CHKGLI.I55@ucc.su.oz.au>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>In article <CHH68H.ADt@ses.com> jamshid@castro.uucp (Jamshid Afshar) writes:
>>Hopefully Standard C++ will, like Standard C, define not only what
>>identifiers a standard header can and must use, but what identifiers a
>>header CANNOT use.
>
>The library working group is putting the whole standard library
>in namespaces .. including the C library.
>
>In effect that means that one identifier is reserved
>by the library, probably "std" or "iso" or something.
>
>All the other names will now be available to the user,
>provided of course you dont try to define say "memcpy"
>in the namespace its already defined in.

So Standard C++ functions will not be allowed to be implemented as
macros (except, I guess for some things like va_arg())?.  That's good;
free, pow, exit, str*, rewind, etc. are useful member function/data
names.

Do you think Standard C++ will also disallow macros for constants such
as those defined in <limits.h>?  It would be nice to reclaim *_MIN and
*_MAX for the user (I think ANSI C reserves any identifiers matching
those patters, or maybe I'm thinking of POSIX).

>None of this applies to macros, however, but they aren't really
>part of the language proper. (Boy, I'd sure like to deprecate
>that stupid preprocessor  :-)

What do you mean by "none of this applies to macros"?  That the user
can't define macros with the same name as Standard C++ functions?
That's reasonable.  But, my original question was will Standard C++
headers, as opposed to Standard C headers, be allowed to use
identifiers in the user's namespace for non-standard functions like
filebuf::fd()?  Or, must the implementation stick to identifiers with
double underscores for implementation-specific functions, formal
parameter names, private members, etc?

Jamshid Afshar
jamshid@ses.com