Stilfrage

[C Newbie]

Ich werde diesen Rat in Zukunft berücksichtigen.

Auch für sinnlose Spielereien

[SnorreDev]

Ist nicht immer eine sinnlose Spielerei. In STL Containern kann es sehr hilfreich sein, wenn man nicht über Pointer die Klassen hält. Sonst wird nach dem CopyCTor immer der DTor aufgerufen, und die Initialisierten sachen drin werden überschrieben usw.

[Bashar]

Erklär ...

Hört sich irgendwie schmutzig an was du vorhast, aber du klingst, als würdest du das ständig machen:)

[volkard]

klingt so abwegig, daß ich gar nicht abwarten muss, was er genau vor hat.

[full-qoute]

Original erstellt von SnorreDev:
Ist nicht immer eine sinnlose Spielerei. In STL Containern kann es sehr hilfreich sein, wenn man nicht über Pointer die Klassen hält. Sonst wird nach dem CopyCTor immer der DTor aufgerufen, und die Initialisierten sachen drin werden überschrieben usw.

[SnorreDev]

Ich halte es nicht für Mist, was ich da verzapft habe.

#include <cstdlib>
#include <fstream>
#include <iostream>
#include <string>
#include <vector>

class MyClass {
    char *ptr;

public:
    MyClass( int size ) : ptr( NULL ) {
        std::cout << "Ctor" << std::endl;
        ptr = new char[size];

        for( char i = 0; i < size; i++ ) {
            ptr[i] = i+65;
        }
    }

    virtual ~MyClass() {
        std::cout << "DTor" << std::endl;
        delete [] ptr;
        ptr = NULL;
    }

    inline char* GetPtr() {
        return this->ptr;
    }
};

std::vector< MyClass > vec;

int main()
{
    vec.push_back( MyClass( 10 ) );

    char *ptr = vec.begin()->GetPtr();

    for( char i = 0; i < 10; i++ )
        std::cout << ptr[i] << " - ";

    int i;
    std::cin >> i;

    return EXIT_SUCCESS;
}

Klar - wenn ich vector genommen hätte statt PTR, dann würde es gehen, nur ist vector nicht immer die beste Wahl.
Versteht ihr was ich meine? Und ich Packe z.b. keinen Vertexbuffer oder so in einen vector. Das währe ein viel zu großer Verwaltungsaufwand vom Speicher. Besonders beim Terrain, wo die Meshes echt riesig sind.

[volkard]

kapier net, was du meinst.

[Bashar]

Cool, ein Smart Pointer ohne Smart. Vielleicht sollte man den Smartass-Pointer nennen *g*

[SnorreDev]

@volkard:
Ich meine z.B. bei meinem Terrain habe ich Tiles, die jedes einzelne ein Mesh enthalten. Ich kann so wie´s mir am liebsten ist aber nicht im DTor zerstöhren. Denn sonst sind die gespeicherten daten Hinüber. Also bleibt mir nur der weg über ein extra Release, Kill, Destroy oder wie man das auch immer nennt.

Beim push_back wird der Copy constructor meiner Class aufgerufen, danach der Destruktor, da die eigentliche Instanz die ich erzeugt habe ja nicht weiter Existiert -> vec.push_back( MyClass( 10 ) );

Wenn du den Code ausführst, dann wirst du sehen - er erstellt den Speicher, schreibt ABCDEF... rein, und löscht ihn durch den DTor. Danach kriegtst du durch die schleife nur müll ausgegeben.

@Bashar:
hehe - smartass pointer sind cool - ne jetzt ohne schmarn - kann sein, weil ich nicht der Held im OOP bin, und duch sehr lange Prozedurale Programmierung, daß das Design dann in meinem Terrain Kacke ist, nur weiß ichs nicht besser - aber das der DTor aufgerufen wird läßt sich leider nicht vermeiden!

[Shade Of Mine]

SnorreDev:

es IST käse was du machst.
mach ein vernünftiges Ref Counting (am besten mittels smart pointer).

[Bashar]

"Das ist Käse" kann ja jeder sagen, nur seh ich ehrlich gesagt nicht das wirkliche Problem ... das ist statisches manuelles Refcounting wenn man so will ... man muß als Programmierer zu jeder Zeit wissen, wieviele Referenzen existieren. Dann weiß man auch, wann man destroy() aufrufen muß.

Vielleicht kann das ja mal jemand erhellen.

[volkard]

Original erstellt von Shade Of Mine:
SnorreDev:
es IST käse was du machst.
mach ein vernünftiges Ref Counting (am besten mittels smart pointer).

bitte nicht. man muß ja nicht nur, weil man exceptionsicher proggen will, auf jede performance verzichten.

[SnorreDev]

@Shade & Bashar: Refcounting brauche ich ja eigentlich nicht - existieren tut eh nur eine Instanz im Terrain. Wozu dann Smartptr? Die kann man in anderen Fällen gut gebrauchen, aber in diesem sehe ich keinen Anlaß. Vorallem weil die Pointer nicht weitergegeben werden. Ok - ein auto_ptr würde vielleicht gehen. Als ich das erste mal mit dem Problem konfrontiert wurde habe ich stundenlang gesucht, wo das Problem ist. Nunja - das ist halt ein kleines Workaround

[volkard]

Original erstellt von SnorreDev:
@Shade & Bashar: Refcounting brauche ich ja eigentlich nicht

naja, schlag was vor, wie du im falle einer exception kein speicherloch hast, und dann verzichte auf refcounting.
aber lieber refcounten als löcher haben.

[Bashar]

try {
  foo();
} catch(...) {
  bar.destroy();
  throw;
}

[ Dieser Beitrag wurde am 25.06.2003 um 19:57 Uhr von Bashar editiert. ]

[volkard]

Original erstellt von Bashar:
**```
try {
foo();
} catch(...) {
bar.destroy();
throw;
}

  
  
[ Dieser Beitrag wurde am 25.06.2003 um 19:57 Uhr von [qb]Bashar** editiert. ][/QB]

jo, dat klappt wohl.
wobei es nicht mein stil ist. ich geb alles per destruktor frei. und will ich was freigeben, bau ich gern auch ne freigebende klasse.
in diesem fall eine, die die objekte besitzt, und deshalb auch verantworlich für sie ist. unabhängig vom besitz kann es mit lokalerer lebensdauer ja beliebig viele container voll mit smartass-pointers geben.

[Bashar]

Das ist eine Idee. Also so, dass die Smartass-Pointer das äquivalent zu Weak Pointern sind?

[volkard]

Original erstellt von Bashar:
Das ist eine Idee. Also so, dass die Smartass-Pointer das äquivalent zu Weak Pointern sind?

jup.
außer, daß man

char *ptr = vec.begin()->GetPtr();

statt

char *ptr = *vec.begin();

schreibt, aber das ist ja nur formsache.
wenn man allerdings den smartass-pointers mehr zugriffsbeschränkungen oder metfoden besorgt, kann ein hübsches gedicht draus werden.