Bug 13903 - using namespace X does not work for operator new
Summary: using namespace X does not work for operator new
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid, diagnostic
: 13483 35110 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-01-28 22:14 UTC by Niall Douglas
Modified: 2008-02-09 04:18 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-01-28 23:18:21


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Niall Douglas 2004-01-28 22:14:31 UTC
Stock download of GCC v3.3.2 will not compile the following:

/* Demo of namespace scoping bug in GCC
by Niall Douglas
*/

typedef unsigned int size_t;

namespace FX {
	void *operator new(size_t size) throw();
}

namespace App {
	using namespace FX;
	class Foo
	{
		Foo()
		{
			// This should use FX::operator new
			// NOT cause an ambiguity error with ::operator new
			int *a=new int;
		}
	};
}

/* This claims "operator new is already defined in this scope".
However the standard permits multiple functions with the same name 
and specification to exist in the same namespace, the error is
thrown when you try to use an ambiguous one, *not* *here* */

using FX::operator new;

int main(void)
{
	/* This correctly generates an ambiguous call error */
	int *a=new int;
}

This refuses to compile with:

/home/ned/TnFOX/test2.cpp:19: error: call of overloaded `operator new(unsigned
   int)' is ambiguous
<internal>:19: error: candidates are: void* operator new(unsigned int)
/home/ned/TnFOX/test2.cpp:8: error:                 void* FX::operator
   new(unsigned int)
/home/ned/TnFOX/test2.cpp: At global scope:
/home/ned/TnFOX/test2.cpp:30: error: `operator new' is already declared in this
   scope

This error is critical because it totally breaks the use of namespaces to 
implement alternative memory allocation idioms eg; ones which throw an exception 
other than std::bad_alloc.

Cheers,
Niall Douglas
Comment 1 Andrew Pinski 2004-01-28 23:18:20 UTC
Actually this is invalid code, from ICC 6.0::
pr13903.cc
pr13903.cc(8): error: allocation operator may not be declared in a namespace
          void *operator new(size_t size) throw();
                ^

pr13903.cc(29): error: namespace "FX" has no member "operator new"
  using FX::operator new;
            ^

compilation aborted for pr13903.cc (code 2)

You cannot have an operator new defined in a namespace.
Comment 2 Niall Douglas 2004-01-28 23:55:26 UTC
Having just checked the standard, you are absolutely right. My apologies for 
bothering the list.

(Major redesign unfortunately is now coming ... balls :( )

Cheers,
Niall
Comment 3 Niall Douglas 2004-01-28 23:58:13 UTC
*** Bug 13483 has been marked as a duplicate of this bug. ***
Comment 4 Andreas Schwab 2008-02-06 19:05:22 UTC
*** Bug 35110 has been marked as a duplicate of this bug. ***
Comment 5 Gilad Odinak 2008-02-08 18:30:19 UTC
Could you please tell me which standard does not allow it, and if a previous standard does allow it.
It is the only way I found to avoid the memory allocator in my code from colliding with the memory allocator of a library (that is the functionality did work)
Comment 6 Manuel López-Ibáñez 2008-02-09 00:23:06 UTC
(In reply to comment #5)
> Could you please tell me which standard does not allow it, and if a previous
> standard does allow it.

The only thing I can tell you is that in our codebase the code is commented as:

   /* [basic.std.dynamic.allocation]/1:

       A program is ill-formed if an allocation function is declared
       in a namespace scope other than global scope or declared static
       in global scope.

       The same also holds true for deallocation functions.  */

where the first line is a reference to the ISO C++ standard.

Anyway, this is not the appropriate place to get help with C++.
Comment 7 Gilad Odinak 2008-02-09 04:18:14 UTC
Thanks by the way there's a typo in the spec locator it is not static but sometimes std and sometimes stc see here for the original suggestion to change the behavior
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0727.htm
no rationale of course