Visual Studio: #pragma optimization_level?

[anonym]

Ahoi,

ich möchte meine Enumerationsmember nicht mit Präfixen versehen, weshalb ich diese in eine Wrapper-Klasse packe sowie einen Member des Typs der Aufzählung in der Klasse habe, auf den mittels überladener Operatoren und Konstruktor zugegriffen werden kann. Dass blöde ist nun, dass ich mangels aktiviertem Inlining beim Debuggen immer in die beiden überladenen Operatoren und den Konstruktor springe. Kann man in Visual Studio irgendwie einstellen, dass für diese Methoden beim Kompilieren ein anderes Optimierungslevel verwendet wird, als in den Compilereinstellungen gesetzt und diese Operatoren somit geinlined werden? Führt das zu längeren Kompilierungsdauern (sowohl hinsichtlich Wrapper als auch Optimization-Level-Modifikationen)? GCC kennt #pragma optimization_level (1|2|3|reset).

Wenn man im Debugmodus nun das Optimization-Level für bestimmte Funktionen bestimmen könnte, wäre es dann möglich, Wrapper-Klassen (ähnlich C# mit toString, fromString, aber auch cos, sin, sqrt, ...) für eingebaute Typen zu schreiben/generieren, allerdings ohne dabei enorme Performance-Verluste im Debugmodus durch non-inline Funktionsaufrufe zu erleiden oder in andere Schwierigkeiten zu geraten? Mit dem Optimization-Level /O2 kommt mit Wrapper der gleiche Assemblercode heraus wie ohne.

Code: Alles auswählen

struct Scalar {
private:
	float _t;
public:
	Scalar(float t) : _t(t) {}
	operator float() { return _t; }
	Scalar& operator=(float t) { _t = t; return *this; }
	// ...
	static Scalar fromString(const char* t) { return atof(t); }
	static Scalar cos(Scalar t) { return ::cosf(t); }
};

Mfg

[Krishty]

Hi,

Dafür ist keine Pfriemelei an den Optimierungen nötig: http://www.codeguru.com/cpp/v-s/debug/a ... NoStepInto

Gruß, Ky

Edit: Ups, da habe ich mich wohl verlesen. Du willst ja tatsächlich optimierten Code und nicht nur, dass er nicht in die Funktionen hüpft. Duck und weg!

[Unknown GER]

Also dein Kernanliegen (keine Präfixe bei Enumerationen) löse ich persönlich immer recht pragmatisch folgendermaßen (und habe damit bis jetzt immer nur positive Resonanz erhalten weil es sehr übersichtlich im Code zu lesen ist und keinerlei Overhead erzeugt).

Ich packe das enum in einen namespace, den ich so nenne, wie das enum eigentlich heißen sollte. Das enum an sich heißt Enum. Beispiel:

Code: Alles auswählen

namespace Color
{
    enum Enum
    {
        Red,
        Green,
        Blue
    };
}

// Ein paar beispielhafte Verdeutlichungen:

void setColor(Color::Enum color); // Also ich finde es genial und äußerst leserlich ;-)

setColor(Color::Red); // Immer noch nicht überzeugt? :D

[Krishty]

So mache ich es auch … da meine enums aber oft klassen- oder funktionslokal sind, muss ich dann structs statt namespaces benutzen … ist im Grunde aber das Gleiche. Leider befürchte ich, dass es dem OP bei nicht-enum-Sachen (wie seinem Scalar-Beispiel) nicht weiterhilft.

Ich würde aber ehrlich gesagt die NoStepInto-Lösung benutzen und auf die Performance pfeifen – weil ich mir schlicht und einfach nicht vorstellen kann, dass die Programm-Performance vernichtend stark vom Inlining einer cos-Funktion (die übrigens sowieso nicht geinlined wird, sondern auch auf höchster OptimierungsStufe ein indirekter Aufruf der C-Runtime ist) oder eines enum-Getters abhängt.