3. Exception werfen

Exception werfen

  • S

    Xebov schrieb:

    Ja. Meine Base Exception hat einen char* in dem die Nachricht liegt. Die ganzen erbenden klassen schleifen in ihrem operator= und Copykonstruktor alles zur Basisklasse durch.

    Warum kein std::string?

    0
  • X

    Shade Of Mine schrieb:

    Xebov schrieb:

    Ja. Meine Base Exception hat einen char* in dem die Nachricht liegt. Die ganzen erbenden klassen schleifen in ihrem operator= und Copykonstruktor alles zur Basisklasse durch.

    Warum kein std::string?

    Ich wolte unnötiges Speicherholen vermeiden. Hab mich mit den strings mal auseinandergesetzt, und gelesen das für die ausgabe das Strings als CString nochmal Speicher geholt wird um den CString zu bauen, das wollte ich so eigentlich nicht haben, weil ich auf de reinen seite einheitlich mit den exceptions aus der std cStrings ausgeben wolte und auf der anderen Seite auch eigene Exceptions schmeiße wenn ich ein std::bad_alloc auffange, weis nicht ob meine überlegung so Sinnvoll ist oder nicht, ich fand sie auf jedenfall nicht schlecht und hab sie deshalb so umgesetzt.

    0
  • S

    Xebov schrieb:

    Ich wolte unnötiges Speicherholen vermeiden.

    Dann schreib dir eine passende string klasse.

    Man fasst rohen speicher einfach nicht haendisch an.

    0
  • X

    Shade Of Mine schrieb:

    Xebov schrieb:

    Ich wolte unnötiges Speicherholen vermeiden.

    Dann schreib dir eine passende string klasse.

    Man fasst rohen speicher einfach nicht haendisch an.

    Der aufwand würde sich nicht lohnen. Der Konstruktor nimtm die Nachricht entgegen und holt den Speicher zum reinstopfen und der Destruktor gibt ihn wieder frei, ich sehe da ehrlich gesagt keinen wirklichen Grund für eine Extra Klasse die am Ende ja auch nichts anderes macht.

    0
  • U

    Shade Of Mine schrieb:

    Xebov schrieb:

    Ich wolte unnötiges Speicherholen vermeiden.

    Dann schreib dir eine passende string klasse.

    Man fasst rohen speicher einfach nicht haendisch an.

    boar... es geht um exceptions - ich weiß ja nicht, wie ihr programmiert, aber bei mir ist es eher die ausnahme, dass exceptions fliegen - also muss ich mir da echt 0 gedanken um performance machen - weil das ohnehin meist heißt, dass irgendwas nicht geht/ging...

    bb

    0
  • ?

    Aua!!! Wer hat mir die Exception an den Kopf geworfen? Passt mal besser auf!!! 😡

    0
  • S

    unskilled schrieb:

    boar... es geht um exceptions - ich weiß ja nicht, wie ihr programmiert, aber bei mir ist es eher die ausnahme, dass exceptions fliegen - also muss ich mir da echt 0 gedanken um performance machen - weil das ohnehin meist heißt, dass irgendwas nicht geht/ging...

    Kein Mensch redet von performance...

    @Xebov:
    Eine string klasse mit minimalen speicher verbrauch ist immer nuetzlich - und sie zu schreiben ist weniger aufwendig als bei jeder exception klasse immer die ganzen operatoren zu definieren.

    komponenten wie zB strings oder aehnliches zu schreiben ist idR deutlich weniger aufwand als die funktionalitaet immer doppelt und dreifach zu schreiben 😉

    0
  • X

    Shade Of Mine schrieb:

    Kein Mensch redet von performance...

    @Xebov:
    Eine string klasse mit minimalen speicher verbrauch ist immer nuetzlich - und sie zu schreiben ist weniger aufwendig als bei jeder exception klasse immer die ganzen operatoren zu definieren.

    komponenten wie zB strings oder aehnliches zu schreiben ist idR deutlich weniger aufwand als die funktionalitaet immer doppelt und dreifach zu schreiben 😉

    Ja das is natürlich ein Argument. Wobei Copykonstruktor und operator alles nur durchreichen, die Arbeit selbst macht allein der Copykonstruktor/operator der Basisklasse. Ich werds aber mal in Betrachtziehen da ich in etlichen klassen nur einfache CStrings speichern muß, da könnte ne Kapselung nicht schaden.

    unskilled schrieb:

    boar... es geht um exceptions - ich weiß ja nicht, wie ihr programmiert, aber bei mir ist es eher die ausnahme, dass exceptions fliegen - also muss ich mir da echt 0 gedanken um performance machen - weil das ohnehin meist heißt, dass irgendwas nicht geht/ging...

    Es geht dabei weniger um Performance, wenn ich generell Exceptions werfe und welche dabei sind die OutOfMemory bedeuten ist es schon vorteil haft in diesem Fall sowenig Speicher wie Möglich zu holen um zu vermeiden das das erstellend er Exception selbst fehlschlägt.

    0
  • Administrator

    Xebov schrieb:

    Ich wolte unnötiges Speicherholen vermeiden. Hab mich mit den strings mal auseinandergesetzt, und gelesen das für die ausgabe das Strings als CString nochmal Speicher geholt wird um den CString zu bauen, ...

    Verstehe ich dich richtig, dass du nicht wolltest, wenn du die Funktion std::string::c_str() verwendest, dass hier zusätzlicher Speicher verbraucht wird? Ich hoffe, dir ist bewusst, dass die meisten std::string Implementationen hier nicht zusätzlichen Speicher allokieren, sondern den eigenen Speicher intern immer um +1 grösser halten und eine '\0' am Ende reinspeichern.

    Das was du hier machst, würde ich als PMO bezeichnen. Du probierst etwas zu optimieren, wo du noch gar keine Ahnung hast, ob es wirklich schlechter läuft.

    Grüssli

    0
  • X

    Dravere schrieb:

    Verstehe ich dich richtig, dass du nicht wolltest, wenn du die Funktion std::string::c_str() verwendest, dass hier zusätzlicher Speicher verbraucht wird? Ich hoffe, dir ist bewusst, dass die meisten std::string Implementationen hier nicht zusätzlichen Speicher allokieren, sondern den eigenen Speicher intern immer um +1 grösser halten und eine '\0' am Ende reinspeichern.

    So wie ich das mal verstanden hatte garanteirt der std:string doch nicht das die zeichen in der Reihenfolge eines CStrings im Speicher liegt und erstellt den CString nur bei bedarf? Oder war das Blödsinn?

    0
  • U

    Shade Of Mine schrieb:

    unskilled schrieb:

    boar... es geht um exceptions - ich weiß ja nicht, wie ihr programmiert, aber bei mir ist es eher die ausnahme, dass exceptions fliegen - also muss ich mir da echt 0 gedanken um performance machen - weil das ohnehin meist heißt, dass irgendwas nicht geht/ging...

    Kein Mensch redet von performance...

    wenn man performance nicht nur über laufzeit definiert, sondern auch speicherverbrauch mitzählt, dann schon!

    @Xebov: Ja, der Standard garantiert das nicht - aber ich habe bisher noch nie eine Implementation gesehen, wo der string beim c_str() umkopiert wird... ist ja auch nicht wirklich sinnvoll...

    und trotzdem ist eine solche klasse ab und an ganz hilfreich - aber das ist und bleibt eine exception - eine ausnahme - was bringt es dir, wenn dein programm in ausnahmen weit unter 1kb speicher weniger braucht?

    bb

    0
  • N

    Xebov schrieb:

    So wie ich das mal verstanden hatte garanteirt der std:string doch nicht das die zeichen in der Reihenfolge eines CStrings im Speicher liegt und erstellt den CString nur bei bedarf? Oder war das Blödsinn?

    Ich frage mich nach wie vor, wer für die Speicherverwaltung zuständig sein sollte, wenn der std::string einen neuen C-String erstellt.

    Xebov, hattest du wirklich mal eine OutOfMemoryException? Aufgrund welcher Gegebenheiten wirfst du diese? In C++ ist für zu wenig Speicher eigentlich std::bad_alloc zuständig, ansonsten hat deine Exception vielleicht nicht den richtigen Namen...

    0
  • X

    Nexus schrieb:

    Xebov, hattest du wirklich mal eine OutOfMemoryException? Aufgrund welcher Gegebenheiten wirfst du diese? In C++ ist für zu wenig Speicher eigentlich std::bad_alloc zuständig, ansonsten hat deine Exception vielleicht nicht den richtigen Namen...

    Hatte noch nie, meine Programme verbrauchen noch viel zu wenig Speicher als das das jemals passieren könnte. Ich werfe sie wenn ich in einigen programmteilen std::bad_alloc auffange, ich gliedere die Exception quasi ein, ich fange sie auf und werfe meine eigene an der Stelel weiter, aber nicht imemr, außerdem verwende ich sie für DX Fehlercodes die das selbe aussagen, wieso fragst du?

    0
  • N

    Xebov schrieb:

    wieso fragst du?

    Weil es mich wundert, dass du dir die Mühe machst, eine fast nie auftretende Exception wie std::bad_alloc noch selbstständig weiterzuleiten. Ganz konsequent wirst du das wahrscheinlich nicht machen können...

    Hast du etwas gegen die Exception-Hierarchie der Standardbibliothek?

    0
  • X

    Nexus schrieb:

    Xebov schrieb:

    wieso fragst du?

    Weil es mich wundert, dass du dir die Mühe machst, eine fast nie auftretende Exception wie std::bad_alloc noch selbstständig weiterzuleiten. Ganz konsequent wirst du das wahrscheinlich nicht machen können...

    Hast du etwas gegen die Exception-Hierarchie der Standardbibliothek?

    Nein ich habe dagegen nichts. Ich bastel ne kleine Engine zusammen und die kommt halt aus einem Guß nun habe ich aber 2 verschiedene OutOfMemory Meldungen, einmal nen fehelrcode aus DX und einmal ne std::bad_alloc aus der std, und die leite ich beide auf eine eigene OutOfMemory Exception um.

    Konsequent bin ich dabei ind er Tat nicht, da sis aber absicht, ich leite std::bad_alloc nur da um wo es sinn macht, dh Hauptsächlich wenn sich Interne Daten vergrößern, wenn aber Hauptteile "hochfahren" dann leite ich sie nicht um weil dann das Programm so oder so nicht weit käme.

    0
  • T

    Nexus schrieb:

    [...Ich frage mich nach wie vor, wer für die Speicherverwaltung zuständig sein sollte, wenn der std::string einen neuen C-String erstellt...

    Na std::string . Du bekommst über c_str() einen char const* zurück, der nur so lange gültig ist, wie es der String selbst ist. Es bleibt ja nach wie vor ein Puffer, dessen Eigentümer das String-Objekt ist. Selbst, wenn intern eine Kopie erzeugt wird.

    0
  • S

    unskilled schrieb:

    wenn man performance nicht nur über laufzeit definiert, sondern auch speicherverbrauch mitzählt, dann schon!

    Nein...

    Es geht hier um Exceptions - die treten in Ausnahmefällen auf. Hier einen optimalen Memory Footprint zu haben ist common sense und keine optimierung.

    Idealerweise würde man nämlich 0 bytes allokieren, aber das ist nicht immer möglich.

    0
  • N

    Tachyon schrieb:

    Na std::string . Du bekommst über c_str() einen char const* zurück, der nur so lange gültig ist, wie es der String selbst ist. Es bleibt ja nach wie vor ein Puffer, dessen Eigentümer das String-Objekt ist. Selbst, wenn intern eine Kopie erzeugt wird.

    Danke, das scheint Sinn zu machen. Ich war bis jetzt eher davon ausgegangen, dass in dem Falle, wo c_str() nicht der internen Repräsentation entspricht, ein eigenständiges Objekt zurückgegeben würde. Aber falls dieser Fall überhaupt vorkommt, gehört die Speicherverwaltung also dem String...

    0
  • B

    Tachyon schrieb:

    Na std::string . Du bekommst über c_str() einen char const* zurück, der nur so lange gültig ist, wie es der String selbst ist. Es bleibt ja nach wie vor ein Puffer, dessen Eigentümer das String-Objekt ist. Selbst, wenn intern eine Kopie erzeugt wird.

    Das hatten wir doch letztens schon einmal. Wie soll die Klasse sich um die Speicherverwaltung kümmern, wenn der c_str()-Aufruf das Objekt nicht verändern darf? Es geht mit Mörder-Frickelei und ausgelagerten Datenstrukturen, ja, aber nicht mit einer auch nur halbwegs praktikablen Lösung.

    0
  • T

    Badestrand schrieb:

    ...

    c_str() muss das Objekt nicht ändern. Sollte hinter c_str() tatsächlich ein anderer Puffer stehen als hinter dem Stringpuffer selbst, so muss dieser bei jeder Ändererung des Stringpuffers mitgeändert werden. Nicht erst beim Aufruf von c_str() . c_str() selbst hat dabei nichts zu melden. Die Funktion muss immer nur einen konstanten Zeiger auf die aktuelle C-String-Repräsentation des Strings zurückgeben.
    Und den (separaten) Puffer im Destruktor von std::basic_string zu zurstören beisst sich nicht im geringsten mit der constness von c_str() .
    Irgendwelche "ausgelagerten Datenstrukturen" sind dabei völlig überflüssig.

    0
Anmelden zum Antworten