0

I'm building an event system which mimics to some extent how Qt's signal/slots work.

I make connections which looks something like this: 

EventHandler::connect(&EventDispatcher::getInstance(), &EventDispatcher::mouseClicked, (Button*)this, &Button::on_mouseClicked);

The mouseClicked is a member function in EventDispatcher with an empty body and is merely used to signal which event was triggered:

void mouseClicked(float /*x*/, float /*y*/) {}

The issue I'm having is that visual studio seems to optimize all member functions with the same parameter list and body to be equal to each other. This is not an issue in Debug mode, nor with Clang or GCC (in Linux and OS X).

In short:

void mouseClicked(float /*x*/, float /*y*/) {}
void windowResized(float /*w*/, float /*h*/) {}
EventDispatcher::*func1(float, float) = &EventDispatcher::mouseClicked;
EventDispatcher::*func2(float, float) = &EventDispatcher::windowResized;
assert(func1 != func2); // <- This only fails in Visual studio Release mode

Temporary fix

As a quick fix I added a dummy function body (which really makes me cringe, but I'm crunching towards a release) that just logs some crap. Since the function isn't ever called, that shouldn't affect performance.

I'd love to hear alternative solutions.

JBarberU
  • 999
  • 8
  • 16
  • 2
    Well, this is what optimization is for. Why do you need those functions to be different if they are same? – Agent_L May 26 '14 at 13:57
  • The functions are ment to signal what event was triggered, they are never called. – JBarberU May 26 '14 at 13:58
  • 1
    I thought the signal is passed by **CALLING** the function. I fail to grasp the very idea of function created to be never called. Do you use their addresses as some kind of ID? Then perhaps a combination of `__FILE__` and `__LINE__` would suit better. – Agent_L May 26 '14 at 14:01
  • The connection is basically an instance of Object (caller), a pointer to member function (signal), an instance of Object (callee) and a pointer to member function (slot, which is actually called). – JBarberU May 26 '14 at 14:08
  • possible duplicate of [Why are (member) function pointers behaving so weirdly in Visual C++?](http://stackoverflow.com/questions/14176320/why-are-member-function-pointers-behaving-so-weirdly-in-visual-c) – Holt May 26 '14 at 14:10
  • Well, then if the signal does nothing, it's irrelevant which one is called, as they both do same. You can use linker option `/OPT:NOICF` to disable this particular optimization, but imho it's a very bad idea to depend on some compile-time option. Code should be judged only by what it does; if they do same thing, they should be considered same function. It's a problem in your design if you really need them to be different. But do you really? – Agent_L May 26 '14 at 14:11
  • See http://msdn.microsoft.com/en-us/library/bxwfs976%28v=vs.110%29.aspx, and particulary the note on `/OPT:ICF` which is enable by default with optimization on VS. – Holt May 26 '14 at 14:12
  • @Agent_L, Strictly speaking ICF is an illegitimate optimization. The standard says that "Two pointers of the same type compare equal if and only if they are both null, *both point to the same function*, or both represent the same address." The 'address clause' is not relevant here because the standard only speaks of addresses in relation with objects, not functions. – ach May 26 '14 at 14:23
  • @AndreyChernyakhovskiy I agree. But the part of C++ job description is to deal with things not conforming to standard. And one can argue if 2 functions with exactly same result are same function or not. – Agent_L May 26 '14 at 14:37
  • @Agent_L, here I do not differ. – ach May 26 '14 at 14:47

0 Answers0