Logfile ohne Overhead

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

volkard

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.

volkard schrieb:

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?

volkard

CSpille schrieb:

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.

CSpille schrieb:

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