ich moechte ein Logfile bzw. eine Logfileklasse erstellen.
Allerdings soll mein Logfile nicht das gesamte Programm ausbremsen, aber gleichzeitig verschiedene Modi haben (Debug, Release, etc...), wobei halt mehr oder weniger viel (bis gar nichts) in das File geschrieben werden soll.

Ich habe gehoert, dass man die Aufrufe im Programm a la

if(modus == debug)
        print(...);
    else if(modus == release)
        //dont print anything
    else
        //kA

mittels Praeprozessormakros/funktionen beim compilieren schon wegoptimieren kann.

Weiss jemand wie das geht, bzw. wo man so etwas nachschauen kann? Und rentiert sich das ueberhaupt? (ich mein leserlicher wird es dadurch sicher nicht...)

Vielen Dank!

Und ja, dies ist eine bewährte und oft benutzte Methode für das was du willst.

Ich würde etwa sowas machen:

#ifdef DEBUG
const bool DEBUG_MODE  = 1;
#elsif
const bool DEBUG_MODE  = 0;
#endif

Sowas brauch man dann nur einmal und kann danach dann etwas
verwenden wie:

if(DEBUG_MODE){
// log something
}

Dann hab ich innerhalb meines Codes wenigstens keine Macros...

Ein Compiler sollte doch in der Lage sein das Wegzuoptimieren, oder?

EDIT: Immerhin handelt es sich um einen Vergleich, in dem nur Konstanten sind

Aber wird da auch sowas wie "debug > 2" wegoptimiert?

Auch nicht schlecht... Thx!

Aber wird da auch sowas wie "debug > 2" wegoptimiert?

Vergleich von zwei Konstanten...

Mir würde kein Argument einfallen, warum ein Compiler das (zumindest im Release)
nicht wegoptimieren könnte/wollte...

#include<iostream>

const int DEBUG = 1;

int main() {
        if(DEBUG == 1)
                std::cout << "DEBUG" << std::endl;
        else if(DEBUG == 2)
                std::cout << "NO DEBUG" << std::endl;
        int* debugPointer = const_cast<int*>(&DEBUG);
        *debugPointer = 2;
        if(DEBUG == 1)
                std::cout << "DEBUG" << std::endl;
        else if(DEBUG==2)
                std::cout << "NO DEBUG" << std::endl;
        return 0;
}

DEBUG
Bus error

Bei Verwendung von

int DEBUG = 1;

DEBUG
NO DEBUG

Das stärkt (denke ich) meine Annahme, dass (zumindest) mein Compiler es (sogar im DEBUG) tut...

Wenn du es genau wissen möchtest, wirst du dir den Assembler-Code anschauen müssen.

Ich kann auf die schnelle nicht sagen, ob das überhaupt funktioniert. Aber wenn es keinen Error vom Compiler gibt, dann darf er die If-Bedingung nicht wegoptimieren. Er muss erkennen, dass sich der Wert von DEBUG während der Laufzeit verändert.

Hat schon einer mal den Assembler-Code der Beispiele angesehen? Hier und nur hier erkennt man, wass optimiert wird und was nicht!

Aber wenn es keinen Error vom Compiler gibt, dann darf er die If-Bedingung nicht wegoptimieren. Er muss erkennen, dass sich der Wert von DEBUG während der Laufzeit verändert.

Nein muss er nicht. Mit const gibt der Programmierer die Garantie, dass sich der Wert der Variable nicht ändert. Außerdem verhindert der Compiler direkte Zuweisungen. Irgendwelches Zuweisen über irgendwelche Hintertürchen erzeugt aber immer UD, also muss der Compiler gar nichts tun. const_cast ist eigentlich nur für Fälle gedacht, wenn z.B. in fremden Bibliotheken nicht auf Const-Correctness geachtet wurde, auch wenn z.B. in einer Funktion ein übergebener Zeiger nicht geändert wird.

bb

Grundsatzfrage: Was spricht denn gegen die Verwendung von Makros in diesem Fall und für die Verwendung einer globalen Konstanten? Ich sehe da überhaupt keinen Vorteil. Eher im Gegenteil, weil man mit ifdef zur Not auch exotische Sachen machen könnte, mit einem einfachen if aber nicht.

Schon klar, dass der Einsatzbereich von Konstanten begrenzt(er) ist.
Allerdings mag ich persönlich absolut keine Makros in meinem Code...
Deswegen bevorzuge ich so eine Definition in irgendeinem Header, den ich nie
wieder anpacke

unskilled schrieb:

Vor allem muss man sich nicht um all die Compiler kümmern, die bei jedem konstanten Vergleich Warnungen ausgeben^^

Warnungen sind/wären ein gutes Argument gegen deren Verwendung.
Da du ja von 'all die Compiler' redest, vermute ich mal, dass der gcc
es nicht macht.

Oder habe ich ein (entscheidendes) Flag vergessen?

g++ main.cpp -pedantic -Wall -Wextra -Wstrict-overflow=5 -o test

Für meinen Privatgebrauch reicht mir eigentlich der GCC und für
Microshizzle werde ich mir es nicht angewöhnen

Thx!

Das Ganze soll ja auch bei Programmausfällen funktionieren, ist das problematisch, wenn evtl. das close entfällt (wenn man nur einmal öffnet und das Programm vor dem Schließen crasht)?
Performance-technisch wäre ja einmal öffnen schneller...

Wieso eigentlich die Verwendung von Makros im Code?

Ich würde etwa sowas machen:

#ifdef DEBUG
const bool DEBUG_MODE  = 1;
#elsif
const bool DEBUG_MODE  = 0;
#endif

Du solltest aber niemals nicht auf gar keinen Fall eine Konstante in GROSSBUCHSTABEN schreiben, da dies per Konvention den Makros vorbehalten ist. Gerade mit deinem zweiten Beispiel

const int DEBUG = 1;

könntest du Probleme bekommen.

Lars

DOCH AUF JEDEN FALL GROSS SCHREIBEN. DER CODE GEHÖRT EH IN EINEN NAMESPACE:

Soso, und das ändert was an dem Problem?

Lars

Du solltest aber niemals nicht auf gar keinen Fall eine Konstante in GROSSBUCHSTABEN schreiben, da dies per Konvention den Makros vorbehalten ist. Gerade mit deinem zweiten Beispiel

const int DEBUG = 1;

könntest du Probleme bekommen.

Danke für den Hinweis, jedoch bin ich jetzt etwas überrascht, denn wenn ich
mir so (Vorschläge für) Coding-Conventions ankucke, dann sieht man das
häufiger:
http://geosoft.no/development/cppstyle.html

Das ist nur ein Beispiel.

Generell dachte ich, dass der Compiler seine MACROS mit '_'
anfängt.

Deswegen habe ich bisher nur darauf geachtet, dass ich sowas nicht mache.
Ausnahme sind include guards.

Die haben bei mir folgende Form:

#ifndef _MY_CLASS_H_
#define _MY_CLASS_H_
#endif

Warum eigentlich?

Im gerade eingefügten Link beginnen (und enden) sie nicht mit '_'

Ausnahme sind include guards.
#ifndef _MY_CLASS_H_

Ja, weil Du oder dein Buchautor in den vom Compilerbauer mitgelieferten Includefiles mal gestöbert haben und die machen es so. Also macht man es selber nach. Ganz falscher Fehler das.

CSpille schrieb:

Ausnahme sind include guards.
#ifndef _MY_CLASS_H_

Ja, weil Du oder dein Buchautor in den vom Compilerbauer mitgelieferten Includefiles mal gestöbert haben und die machen es so. Also macht man es selber nach. Ganz falscher Fehler das.

Genau das, was ich befürchtet habe...
Deine include guards heißen;

#ifndef MY_CLASS_H

?

Bestehen Konstanten bei dir aus Großbuchstaben?

Bestehen Konstanten bei dir aus Großbuchstaben?

Wenn sie sich anfühlen wie Makros, also mal PI oder so, dann meistens ja.
Aber immer mehr Konstanten wandern mit static const in Klassen rein und da schreibe ich sie wie normale Variablen.

Generell dachte ich, dass der Compiler seine MACROS mit '_'
anfängt.

Das Problem sind ja nicht nur die Makros, die vom Compiler kommen. Jeder kann in einem Header etwas definieren. Gerade DEBUG wird fast immer auf der Kommandozeile benutzt, wenn im Debugmodus übersetzt wird. Release wird dann häufig mit NDEBUG übersetzt (das assert verlangt das seit eh und je so).

In Qt3 wird z.B. "signals" (entgegen der Konvention in Kleinbuchstaben) definiert. Jeder, der schon mal boost signals benutzt hat, wünscht den Trollen vermutlich die Pest an den Hals

Auch Adobe und Apple bekleckern sich da nicht gerade mit Ruhm.

Würden sich alle an die Konvention halten, gäbe es viel seltener Probleme.

Lars

Wenn sie sich anfühlen wie Makros, also mal PI oder so, dann meistens ja.

M_PI ist in math.h bzw cmath definiert, PI brauch man also nicht

Lars

Gerade DEBUG wird fast immer auf der Kommandozeile benutzt, wenn im Debugmodus übersetzt wird. Release wird dann häufig mit NDEBUG übersetzt (das assert verlangt das seit eh und je so).

Okay... DEBUG war vielleicht kein sooo gutes Beispiel

Du denkst dabei an Folgendes, oder?

#include<iostream>

const int DEBUG = 1;

int main() {
        if(DEBUG)
                std::cout << "DEBUG" << std::endl;
        return 0;
}

g++ main.cpp -DDEBUG -o test

wobei DEBUG von manchen Compilern automatisch definiert wird.

main.cpp:3: error: expected unqualified-id before numeric constant