Aktiviert "default" Fallstörung Sprungtischoptimierung?

Question

In meinem Code, den ich verwendet Standard-Fallback-Fälle zu schreiben wie die folgenden enthalten behauptet, mich zu schützen gegen das Vergessen Sie den Schalter für den Fall, Semantik

switch(mode) { 
case ModeA: ... ; 
case ModeB: ... ; 
case .. /* many of them ... */ 
default: { 
    assert(0 && "Unknown mode!"); 
    return ADummyValue(); 
} 
}; 

ändern ich, ob die künstliche Fall- Jetzt aktualisieren fragen, Back Check Default Case wird die Jump-Table-Generationen stören? Stellen Sie sich vor, dass "ModeA" und "ModeB" usw. aufeinanderfolgend sind, damit der Compiler in eine Tabelle umgewandelt werden kann. Da der "Standard" -Fall eine tatsächliche "return" -Anweisung enthält (da die Assert im Freigabemodus verschwindet und der Compiler über eine fehlende return-Anweisung meckert), scheint es unwahrscheinlich, dass der Compiler die Standardverzweigung optimiert.

Was ist der beste Weg, damit umzugehen? Ein Freund empfahl mir, "ADummyValue" durch eine Nullzeiger-Dereferenzierung zu ersetzen, so dass der Compiler bei Vorhandensein von nicht definiertem Verhalten auslassen könnte, um vor einer fehlenden return-Anweisung zu warnen. Gibt es bessere Möglichkeiten, dies zu lösen?

Answer 1

Wenn Ihr Compiler MSVC ist, Sie __assume Eigen verwenden können: http://msdn.microsoft.com/en-us/library/1b3fsfxw(v=VS.80).aspx

Answer 2

Ich sehe nur 1 Lösung für den Fall, dass die Optimierung tatsächlich gestört ist: der berüchtigte "#ifndef NDEBUG" rund um den Standardfall. Nicht der schönste Trick, aber klar in dieser Situation.

BTW: Haben Sie schon gesehen, was Ihr Compiler mit und ohne den Standardfall tut?

Answer 3

Wenn Sie einen Zustand haben, der nie erreicht werden sollte, sollten Sie das Programm beenden, weil es gerade im Freigabemodus einen unerwarteten Zustand erreicht hat (Sie könnten diplomatischer sein und Benutzerdaten speichern und alles tun das andere nette Zeug vor dem Untergehen).

Und bitte nicht über Mikro-Optimierungen besessen, es sei denn, Sie haben tatsächlich (mit einem Profiler) gemessen, dass Sie sie brauchen.

Answer 4

Der beste Weg, damit umzugehen, ist nicht die Assert zu deaktivieren. Auf diese Weise können Sie auch mögliche Fehler im Auge behalten. Manchmal ist es besser, wenn die Anwendung mit einer guten Nachricht abstürzt und erklärt, was genau passiert ist, um dann weiter zu arbeiten.

Answer 5

Zumindest mit den Compilern, die ich angeschaut habe, ist die Antwort im Allgemeinen nein. Die meisten von ihnen werden eine switch-Anweisung wie folgt kompilieren entspricht in etwa den Code zu:

if (mode < modeA || mode > modeLast) { 
    assert(0 && "Unknown mode!"); 
    return ADummyValue(); 
} 
switch(mode) { 
    case modeA: ...; 
    case modeB: ...; 
    case modeC: ...; 
    // ... 
    case modeLast: ...; 
} 

Answer 6

wenn Sie mit „default“ (ha !) <assert.h>, ohnehin zum NDEBUG Makro gebunden ist die Definition, also vielleicht nur

case nevermind: 
#if !defined(NDEBUG) 
    default: 
     assert("can" && !"happen"); 
#endif 
    } 

Answer 7

Verwenden Compiler Erweiterungen:

// assume.hpp 
#pragma once 

#if defined _MSC_VER 
#define MY_ASSUME(e) (__assume(e), (e) ? void() : void()) 
#elif defined __GNUC__ 
#define MY_ASSUME(e) ((e) ? void() : __builtin_unreachable()) 
#else // defined __GNUC__ 
#error unknown compiler 
#endif // defined __GNUC__ 

-

// assert.hpp 
#include <cassert> 
#include "assume.hpp" 

#undef MY_ASSERT 
#ifdef NDEBUG 
#define MY_ASSERT MY_ASSUME 
#else // NDEBUG 
#define MY_ASSERT assert 
#endif // NDEBUG