Logfile ohne Overhead

*lt**Exit*gt*

Hallo zusammen,

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!

SeppJ

#ifdef DEBUG
// Logcode
#endif

Oder etwas ausgefallener:

#if DEBUGLEVEL > 3
// Logcode der Priorität > 3
#endif

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

*lt**Exit*gt*

hey, super Sache... Dankeschön!

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

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

*lt**Exit*gt*

Auch nicht schlecht... Thx!

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

</Exit> schrieb:

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...

Mal ein Indiz dafür, dass er es wegoptimiert:

#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.

Athar

Dead code elimination in solch offensichtlichen Fällen gehört zu den leichtesten Übungen eines C++-Compilers. Da muss man sich keine Sorgen machen.

Siassei

int* debugPointer = const_cast<int*>(&DEBUG);
        *debugPointer = 2;

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!

ipsec

Siassei schrieb:

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.

SeppJ

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.

unskilled

Vor allem muss man sich nicht um all die Compiler kümmern, die bei jedem konstanten Vergleich Warnungen ausgeben^^
schon alleine das würde mich hier auch zum präprozessor greifen lassen

bb

SeppJ schrieb:

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

*lt**Exit*gt*

wow, danke für die vielen sehr interessanten Beiträge... Ich glaub ich schau mir erstmal meinen Compiler an und werd dann sehen was geht und was nicht

Thx!

*lt**Exit*gt*

Mal noch eine Frage:
Macht es mehr Sinn, das Logfile einmal zu öffnen und erst wieder bei Programmende zu schließen oder bei jedem Zugriff zu öffnen/schließen?

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...

Grundsätzlich sollte einmal öffnen vollkommen ausreichen. Bei einem Absturz sollte das Betriebssystem zusehen, dass die Resourcen wieder freigegeben werden. Letztendlich kann man das mit Exception aber in den meisten Fällen dank der Destruktoren sogar selber erledigen.

CSpille schrieb:

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:

_ schrieb:

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

Soso, und das ändert was an dem Problem?

Lars

manni66 schrieb:

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 '_'