🚀 go-pugleaf

In article bbl@voyager.Internex.NET, muzok@msn.com (muzo) writes:
>
>is global new/delete in any namespace ? Are there any discussions about such a
>thing ?

Namespaces don't apply to the keywords "new" and "delete" that introduce 
new-expressions and delete-expressions (any more than namespaces apply
to "if" or "while").

The entire standard C++ library, which includes the various standard versions
of operator new and operator delete, is in the "std" namespace.

---
Steve Clamage, stephen.clamage@eng.sun.com




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <470vgc$it4@engnews1.eng.sun.com> clamage@Eng.Sun.COM writes:
>The entire standard C++ library, which includes the various standard versions
>of operator new and operator delete, is in the "std" namespace.

This is no longer true.  There were various name lookup issues related
to new and delete and their interaction with namespaces, and in the latest
Working Paper, all the operator new/delete functions are outside of the
"std" namespace.

Steve Adamczyk

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

muzok@msn.com (muzo) writes:

>is global new/delete in any namespace ?

No.  I think the committee is planning to clarify the rules
to make it clear that global new/delete must not be defined
inside a namespace.

>Are there any discussions about such a thing ?

Yes, the committee has discussed this issue.  I think the conclusion
was that allowing global new/delete to be defined inside namespaces
would require some new (and complicated) lookup rules, and no-one was
interested in doing the work required for a proposal on the issue - I
guess the additional complexity outweighed any potential benefits.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

clamage@Eng.Sun.COM (Steve Clamage) writes:

>In article bbl@voyager.Internex.NET, muzok@msn.com (muzo) writes:
>>
>>is global new/delete in any namespace ? Are there any discussions about such 
a
>>thing ?
>
>Namespaces don't apply to the keywords "new" and "delete" that introduce 
>new-expressions and delete-expressions (any more than namespaces apply
>to "if" or "while").
>
>The entire standard C++ library, which includes the various standard versions
>of operator new and operator delete, is in the "std" namespace.

Although it is indeed stated in the April draft and the September
working paper that all library entities are defined in the
`std' namespace [17.3.1.1/2], it is elsewhere stated that the library
defines `operator new' and `operator delete' in the global namespace [3.7.3/2],

and indeed also that `operator new' and `operator delete'
must be either static class members or global functions
[3.7.3.1/2], and so cannot be defined inside a namespace.
(3.3.4/2 makes it clear that "global" means in the global namespace,
not in any other namespace.)

In other words, the draft standard is inconsistent. 

I think the most likely resolution of this inconsistency is that
17.3.1.1/2 will be changed so that it is clear that the library
definitions of `operator new' and `operator delete' are in the global
namespace.  It is possible that 3.7.3.1 could be changed to allow
allocation and deallocation functions to be defined in a namespace, and
this might well be a better solution, but this would require changes to
the name lookup rules for allocation functions, and I think a change of
that magnitude is less likely at this stage.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]