Thread: Operator new

Well, you are passing 3 arguments to new (the first one being "behind the scenes"), so the overloaded operator must also take 3 arguments (it's missing the char* argument).

I think part of the problem here is the fact that C++ automatically uses the operator new from the class of which you are creating an object from [in this case struct X] when there is an overloaded operator new in the class. If there is no matching form that matches the class and arguments to new, then it will give a compiler error, not pick a different variant of new from some other class (or the global variant) simply because those have the right argument set. It also works this way for operator new in base-class of a derived class - it calls operator new for the base-class [unless the derived class implements it's own operator new of course].

The reason it does this, I'm fairly sure, is so that you do not have to KNOW if a class overloads new or not - it would be very hard to write generic code if it didn't work this way [think template code such as STL that may need to create a "new" copy of a class, which is supplied to the code itself from code that the STL programmer doesn't know about].

It would of course also make a whole lot more work for the programmer(s) if we had to change all calls to new in an existing piece of code, just because we have added a operator new() to an existing class that is widely used.

Where I work, we have certain base-classes that provide an operator new - the main purpose here is to clear the content of the class to zero, so operator new essentially does:

Code:

class Base
{
  ...
public:
   void *operator new(size_t size)
   {
       void *ptr = malloc(size);
       if (!ptr)  
             error();
       memset(ptr, 0, size);
    }
  ...
}

This would not work as nicely if you had to know that the Base class has an operator new implemented.

--
Mats

When do you need to include the <new> header?

When you want to use nothrow new, or you want to catch bad_alloc exceptions specifically.

The operator new in class X is obviously hiding the global operator new - even though it takes the wrong arguments for the call in question. Is that normal?

Yes. The C++ name lookup rules say that the compiler first looks for the name, and when it has found it, it chooses the correct overload from all the functions by that name in the found scope. It's the same with member functions from a base:

Code:

struct Base { void f(); };
struct Derived : Base { void f(int); };
int main() {
  Derived d; d.f(); // error: no suitable overload found, candidate is Derived::f(int)
}

You've not "overloaded"; you've "overridden".

No, overriding only means overriding a virtual function. What you mean here is simply "hiding".

That's just stupid. Hiding is a perfectly good word to describe the situation. Why would you want to use a longer word that has a completely different meaning for that?

Originally Posted by DL1

That does seem to be a bit at odds with the usual lookup rules though, where only those functions are considered whose formal parameters match the arguments in the function call.

Yes, but the whole point of making a class-specific operator new is that you want the class to be created through that interface. So by looking in the global namespace for a new operator when the class has it's own operator would violate that. Just like this:

Code:

class X
{
   public:
      static int func(int a);
};

int func(int a, int b);

int main()
{
   class X x;
   x.func(1, 2);
   return 0;
}

You don't expect this code to use the ::func(), do you?

--
Mats

Originally Posted by DL1

That does seem to be a bit at odds with the usual lookup rules though, where only those functions are considered whose formal parameters match the arguments in the function call.

The normal lookup rules work exactly like those for operator new.

Code:

void f() {}

namespace ns {
	void f(int);

	void g()
	{
		f();
	}
}

int main()
{
	ns::g();
}

results in:

error C2660: 'ns::f' : function does not take 0 arguments

Lookup by name comes first, resolution of overloads second. No exceptions.

Ok, so to use Scott Meyers principle of explaining opertor behaviour (and explain better what both cornedbee and me have been saying):

Code:

X *x = new X;

translates to:

Code:

X *x = X::operator new(sizeof(X));

The compiler will issue it's own version of operator new (just like it makes constructors and destructors if you don't specify any) for default "just size" variant.

So, no the global option doesn't actually work here.

--
Mats

That's not correct. The lookup rules for operator new are special in that they look in the class first and then in the global namespace. Nothing else does that outside the context of the class. Operator new is also special in that it is the only entity that may appear in global scope, but not in namespace scope. (Well, it may appear, but it won't be looked up for the new operator.)

If the transformation as you describe it were correct, you could never use a global placement new for any class type.

Originally Posted by CornedBee

That's not correct. The lookup rules for operator new are special in that they look in the class first and then in the global namespace. Nothing else does that outside the context of the class. Operator new is also special in that it is the only entity that may appear in global scope, but not in namespace scope. (Well, it may appear, but it won't be looked up for the new operator.)

If the transformation as you describe it were correct, you could never use a global placement new for any class type.

Ok, so the words I use to describe the process may not be what you use, but essentially, you could say that "if you do not provide one, the compiler does it for you" in the sense that it uses the global one.

I do agree with your description of how it works, just in case the above comes across as different - that's how the compiler goes about it.

--
Mats