globales #define

It0101

hi leute

ich möchte im Hauptprogramm #define verwenden.
Dieses Define soll in einer Klasse verwendet werden, von der ich im Hauptprogramm ein Objekt erzeuge.
Leider funzt mein Code nur richtig, wenn das #define in der Klasse definiert ist.
Ich hätte aber gern, dass das define im Hauptprogramm steht.

Ist das irgendwie möglich, oder geht das garnicht?

Kóyaánasqatsi

Klar, solltest du auch so aufrufen können. Aber im Grunde reicht es, die Klasse an den anfang des Programms zu packen und die #define unter public zu deklarieren. Zeig doch mal dein Code.

It0101

main.cpp

#define __CLIENT__

#include "Cserver.h"

int main (int argc, char *argv[])
{

    ...

    Cserver *server = new Cserver();
    if ( !server )
        return 3;
    delete server;
    return 0;
}

Cserver.cpp

void Cserver::EineFunction()
{
    ...
    std::vector<TSourceData> *SourceList = Source->GetSourceList();
    int Size = (int)SourceList->size();
    for ( int i = 0; i < Size; ++i )
    {
        #ifdef __SERVER__
             // tu hier was
        #endif
        #ifdef __CLIENT__
             // tu hier was
        #endif
    }
    ...
}

pumuckl

#defines sind pfui, zumindest in dem was du benutzt.
nimm lieber einen const static bool als Member deiner Klasse, um zwischen den beiden Möglichkeiten z switchen. Das ist typsicher und vermüllt nicht sämtliche Sourcen mit dem Präprozessormakro. Zumal das #define nur in der jeweiligen Übersetzungseinheit gilt, also in der main.cpp, nicht in den anderen ÜEs.
Noch ne Kleinigkeit: dein Test if ( !server ) ist sinnfrei. Seit nunmehr 10 Jahren (der Standard ist von '98) liefert das normale new immer einen gültigen Pointer oder wirft eine exception (std::bad_alloc).

It0101

ok dann werd ich auf das #define verzichten.

Und eventuelle "new-fehler" werd ich dann mit exception abfangen.
( kann ja eigentlich nur "speicher-voll" sein )

pumuckl

It0101 schrieb:

( kann ja eigentlich nur "speicher-voll" sein )

Und selbst da wird das Betriebssystem dir viele Sorgen abnehmen, den Speicher kriegst du so schnell nicht voll. Ich würd bad_alloc's garnicht unbedingt abfangen, denn das Problem ist folgendes: Wenn du wirklich auch mit der größten Mühe des Betriebssystems keinen Speicher mehr bekommst, dann kriegst du auch nicht den nötigen Speicher, um noch irgendwelche großartigen Fehlerbehandlungen durchzuführen.
Irgendwo kam mal ein Stück Code, wo jemand im catch-Block eines bad_alloc einen längeren String zusammenfrickeln wollte um den einer anderen Exception zum weiterwerfen zu geben. Die Absicht war löblich. Nur als der String seinen internen Speicher angefordert hat flog die zweite Exception, und damit machte das Programm dann endgültig die Grätsche...

Nexus

way schrieb:

Klar, solltest du auch so aufrufen können. Aber im Grunde reicht es, die Klasse an den anfang des Programms zu packen und die #define unter public zu deklarieren. Zeig doch mal dein Code.

Bitte nicht solchen Unsinn erzählen.

Zum besseren Verständnis: #define ist eine Präprozessoranweisung. Wenn das Programm kompiliert wird, existiert es bereits nicht mehr. Deshalb haben Zugriffsspezifizierer wie public / private , oder eine Klasse überhaupt, rein gar keinen Einfluss auf #define . Genauso wie Gültigkeitsbereiche oder andere compilezeit-relevanten Konstrukte keine Auswirkungen haben.

Die Anweisung #define erzeugt ein Präprozessorsymbol (Makro). Dieses wird oft für Include-Guards und manchmal auch für Textersetzungen (in C oft für Konstanten) verwendet. Wie auch immer man es einsetzt, es führt nur eine Textersetzung durch.

pumuckl schrieb:

Ich würd bad_alloc's garnicht unbedingt abfangen

Das hat mich auch schon zum Nachdenken angeregt (ich hab noch nie auf std::bad_alloc geprüft). Aber wozu existiert die Exception dann?

pumuckl

Nexus schrieb:

Aber wozu existiert die Exception dann?

Wenn du sie weit genug durchrauschen lässt, sind durch das automatische Stack-Unwinding in der Regel einige Objekte zerstört worden die dynamisch alloziierten Speicher wieder freigeben. Dann funktioniert auch eine Fehlerbehandlung. Man kann den Fehler also auf höherer Ebene meistens behandeln, direkt an der Stelle wo das new aufgerufen wird hats meist wenig Sinn, schließlich wird die Funktion ihre Arbeit ohne das dynamisch alloziierte Objekt eh nicht gut fortsetzen können (wenn sie es könnte, wozu dann Speicher anfordern?)

Grade größere Programme müssen ja nicht unbedingt sofort beendet werden, nur weil irgendeine kleine Funktion keinen Speicher bekommen hat. Statt dessen erscheint dann an geeigneter Stelle einfach eine Fehlermeldung "Tut mir leid, konnte Funktion xy nicht korrekt ausführen, hab deinen Mist nicht gespeichert, da ist ein bad_alloc geflogen. Weiter im Text... [ press OK ]"

It0101

Also bisher nehme ich #defines auch nur als Include-Guard... Definitionen mach ich eigentlich auch immer als const int ... oder was auch immer.

Ich hab die Defintion die ich für die Klasse brauch jetzt einfach im Konstruktor als const static int übergeben. Das erfüllt auch seinen Zweck.

Das mit der Exception bei new ist natürlich interessant.
Wozu gibts die denn? Gibts noch andere Fehler die beim Anfordern von Speicher auftreten können außer Speichermangel?

Nexus

It0101 schrieb:

Ich hab die Defintion die ich für die Klasse brauch jetzt einfach im Konstruktor als const static int übergeben. Das erfüllt auch seinen Zweck.

Statisch und gleichzeitig im Konstruktor? Das widerspricht sich leicht. Zeig doch mal deinen Code und beschreibe genau, was du willst. Ich hab nämlich das Gefühl, du machst etwas falsch.

asc

pumuckl schrieb:

Ich würd bad_alloc's garnicht unbedingt abfangen, denn das Problem ist folgendes: Wenn du wirklich auch mit der größten Mühe des Betriebssystems keinen Speicher mehr bekommst, dann kriegst du auch nicht den nötigen Speicher, um noch irgendwelche großartigen Fehlerbehandlungen durchzuführen.

Also, die übliche Strategie die ich zum bad_alloc gelernt habe ist, das man anfangs einen Speicherbereich alloziert, den man im Falle des bad_alloc freigibt. Ob diese Strategie unter allen Betriebssystemen klappt ist die andere Frage, wäre aber eine mögliche bad_alloc Behandlung (Mit einer Meldung ala "Achtung: Sie haben nur noch wenig freien Speicher frei. Bitte beenden sie überflüssige Anwendungen und speichern sie.").

Ja, bad_alloc fange ich auch nicht ab, das liegt aber eher daran das in den Anwendungen bislang die Speicherprobleme eher das kleinste Problem wären (Aber ich kenne durchaus solche Speichermonster... z.B. Civilisation 4 zerlegt sich irgendwann... [Wie schnell hängt von der Ram-Menge ab]).

cu André