has_new_operator fail if several new operators is overrided

[Runar Undheim <r.undheim@…>]

This code will not compile:

#include <stdio.h>
#include <tchar.h>

#include <boost/type_traits.hpp>
#include <boost/type_traits/has_new_operator.hpp>

class A {
public:
  void* operator new(std::size_t);
  void* operator new(std::size_t, void*);
};

int _tmain(int argc, _TCHAR* argv[])
{
  boost::has_new_operator<A>();
	return 0;
}

};

int _tmain(int argc, _TCHAR* argv[]) {

boost::has_new_operator<A>(); return 0;

}

The has_new_operator could be updated with a new check_sig3 test. Where the new(std::size_t, void*) is moved to the new check_sig3. But because of ticket #3400, the function should also be split into tree different functions (ex. has_new_operator, has_new_operator_array and has_new_operator_placement).

[Robert Ramey]

Hmmm - I notice your name is the first on the list of authors in the source code for has_new_operator.hpp.

I suspect that I and john maddock made just minor tweaks. How about updating has_new_operator.hpp and sending it to me so I can check it in. This is much easier for me than diving back into this.

Now that I look at it, there is a "rutger" on the user list for this site. Could I just assign this to you and let you take care of this? Same would go for #3400. This would be very helpful to me.

Robert Ramey

[anonymous]

I've been meaning to look at this as well, but haven't had the time yet :-(

Before we get too carried away with any changes:

• I'd prefer it if has_new_operator retained the existing semantics - which is to say returns true if the class has any of the new operator signatures overloaded.
• With regard to splitting in 3: just remember that there are actually 6 (I think!) variations if we include the nothrow versions as well. Wait, make that 8 if we include the 2 placement versions! Not sure whether has_operator_new should return true for placement operator overload though?

Just thinking out loud yours, John.

[anonymous]

Will be fixed in Trunk shortly (but not the splitting up).

[John Maddock]

(In [56730]) Fixes #3401.