JPEG Bilder die 2te

daddy_felix

Warum erstellst du imgFile mit new?

und es heißt "Destruktor", nicht "Dekonstruktor"

Enno

daddy_felix schrieb:

Warum erstellst du imgFile mit new?

Ich versteh nicht was das Problem ist? Hab ich da was schlechtes gelern?

daddy_felix schrieb:

und es heißt "Destruktor", nicht "Dekonstruktor"

Ups.

Skym0sh0

Naja, wenn du new verwendest muss das Gründe haben. Theoretisch ist es (fast) dasselbe wie ohne new, aber es hat halt in der Praxis Auswirkungen.

Denn Zu jedem new gehört genau ein delete. Und genau das muss sichergestellt sein, dass dieses ausgeführt wird.

Dann gibt es die Regel der großen 3 (die sich aushebeln lässt wie ich vor 2-3 Wochen gemerkt hab ;)), diese besagt, dass wenn du auch nur einen der folgenden Dinge selbst definierst, die anderen auch selbst definieren musst/sollst:
- Kopierkonstruktor
- Destruktor
- Zuweisungsoperator (Ok, lässt sich über das Copy'n'Swap Idiom implementieren und ist damit ein 2 Zeiler in jeder Klasse)

Des Weiteren wäre noch die sogenannte Initialisierungsliste zu nennen.
Du gehst davon aus, dass sich ein Zeiger auf einen const char (const char implizit zu einem vector<char>::iterator konvertieren lässt, die mannigfaltigen Möglichkeiten des Iterators nutzt du dennoch aber nicht, da hättest ja bei einem Zeiger bleiben können (zumal ein Iterator ja was anderes ist und für andere Dinge zuständig ist als nur zu zeigen).

Enno

Das ist ja schön und gut mit dem new. Allerdings mach ich doch den delete also ist doch alles ok? Ansonsten wollte ich eigentlich nur mal wissen ob mein Gedenken weg da logisch ist oder ob das Quark ist.

Das mit dem const char sehe ich ein, hab ich auch geändert.

Nexus

In C++ verwaltet man Speicher sehr selten manuell -- new , new[] , delete und delete[] trifft man in gutem Code nicht häufig an. Oder vielleicht noch new , aber nicht die anderen.

Schau dir dazu mal das RAII-Idiom an. Grundsätzlich geht es darum, dass Objekte selbstständig für ihre Ressourcen (einschliesslich Speicher) zuständig sind. Statt eines ImgFile* könnte man Smart-Pointer wie std::unique_ptr<ImgFile> verwenden, oder noch besser direkt ImgFile . Wozu brauchst du den Zeiger?

Enno

Nexus schrieb:

In C++ verwaltet man Speicher sehr selten manuell -- new , new[] , delete und delete[] trifft man in gutem Code nicht häufig an. Oder vielleicht noch new , aber nicht die anderen.

Ok danke für die erklärung.

Nexus schrieb:

Schau dir dazu mal das RAII-Idiom an. Grundsätzlich geht es darum, dass Objekte selbstständig für ihre Ressourcen (einschliesslich Speicher) zuständig sind. Statt eines ImgFile* könnte man Smart-Pointer wie std::unique_ptr<ImgFile> verwenden, oder noch besser direkt ImgFile . Wozu brauchst du den Zeiger?

Ok das mit dem Smart-Pointer schau ich mir an.
ImgFile liefert mir das JPEG Bild. D.h. das ist eine eigene Klasse. Meinst du mit direkt ImgFile zu benutzen, dass ich das vererben soll? Ansonsten hab ich das grade nicht verstanden.

Nathan

Nein, er meinte so etwas:

class foo {};
clss bar {foo f;}

Skym0sh0

Nein, vererben nicht, komponieren sollst du.

class A
{ };

class B
{
    A my_a; // das meint er, das nennt man Komposition
};
// B "hat-ein" A

class Base
{ };

class Derive : public Base // das ist Vererbung, etwas ganz anderes
{ };
// Derive "ist-ein" Base

Nexus

Enno schrieb:

ImgFile liefert mir das JPEG Bild. D.h. das ist eine eigene Klasse. Meinst du mit direkt ImgFile zu benutzen, dass ich das vererben soll? Ansonsten hab ich das grade nicht verstanden.

Nein, du schreibst ja auch

int i = 5;

und nicht

int* i = new int(5);

Wenn du keine dynamische Speicherverwaltung brauchst, benutze sie nicht. In deinem Fall solltest du die Konstruktor-Initialisierungsliste verwenden.

class Start
{
public:
    Start();
    // kein Destruktor mehr notwendig
private:
    ImgFile imgFile;
};

Start::Start()
: imgFile() // <- hier könnte man Argumente an den ImgFile-Konstruktor übergeben
{
    // eigentlicher Konstruktorrumpf
    // keine Zuweisungen hier!
}

Enno

Ok allerdings kommt das für mich irgendwie auf das gleiche raus ob ich nun ein Pointer auf das Objekt mache oder das Objekt direkt anspreche.

Meine eigentlich frage ist nicht auf das new bezogen sondern ob das generell Quark ist oder ob mein angehen jetzt in die richtige Richtung geht.

Nathan

Ja, ist Quark.
Du brauchst überhaupt keinen Pointer und kannst einfach mit . auf die Member zugreifen.
Ein Pointer ist hier absolut überflüssig.

Enno

Nathan schrieb:

Ja, ist Quark.
Du brauchst überhaupt keinen Pointer und kannst einfach mit . auf die Member zugreifen.
Ein Pointer ist hier absolut überflüssig.

Es geht gar nicht um den Pointer mehr! Das hab ich ja schon jetzt grade oft genug verstanden. Danke.

Ethon

Schreib doch erstmal nen Loader für unkomprimierte TGA-Bilder.
Den Code kannst du praktisch zu 90% übernehmen und du hast nur minimal Zusatzarbeit gemacht, weißt aber wie die absoluten Basics von JPEG funktionieren.

Nathan

@Enno:
Ach so, tschuldigung, habe dich falsch verstanden.

Enno

Ethon schrieb:

Schreib doch erstmal nen Loader für unkomprimierte TGA-Bilder.
Den Code kannst du praktisch zu 90% übernehmen und du hast nur minimal Zusatzarbeit gemacht, weißt aber wie die absoluten Basics von JPEG funktionieren.

Hast du alles gelesen? Dann wüsstest du das ich das nicht machen will sondern gleich dabei bleibe.
Trotzdem danke für den Tipp ich weis das zu schätzen.

Nathan schrieb:

@Enno:
Ach so, tschuldigung, habe dich falsch verstanden.

Und die Anfänger müssen sich immer anhören das sie richtig lesen soll.
Ne ist ja kein Problem.

Ethon

Enno schrieb:

Ethon schrieb:

Schreib doch erstmal nen Loader für unkomprimierte TGA-Bilder.
Den Code kannst du praktisch zu 90% übernehmen und du hast nur minimal Zusatzarbeit gemacht, weißt aber wie die absoluten Basics von JPEG funktionieren.

Hast du alles gelesen? Dann wüsstest du das ich das nicht machen will sondern gleich dabei bleibe.
Trotzdem danke für den Tipp ich weis das zu schätzen.

Das würde ich metaphorisch verpacken als "Ich baue kein Rad, sondern gleich ein Auto, das 4 Räder hat". Aber naja, dein Bier, viel Erfolg.

Enno

Danke

Enno

Hey Leute,
ich habe mich nun weiter durch gekämpft. Bin auch gut voran gekommen.
Meine Frage:
Muss man sich für verschiedene JPEG Bilder immer neue Quantisierungstabellen errechnen oder kann man dafür auch feste(also const) Tabellen nehmen?

Ich meine sowas:

//luminocity quantanization table
static const int lqt[64]{2, 1, 1, 2, 3, 5, 6, 7,
          1, 1, 2, 2, 3, 7, 7, 7,
          2, 2, 2, 3, 5, 7, 8, 7,
          2, 2, 3, 3, 6, 10, 10, 7,
          2, 3, 4, 7, 8, 13, 12, 9,
          3, 4, 7, 8, 10, 12, 14, 11,
          6, 8, 9, 10, 12, 15, 14, 12,
          9, 11, 11, 12, 13, 12, 12, 12};

//chromaticity quantanization table
static const int cqt[64]{2, 2, 3, 6, 12, 12, 12, 12,
          2, 3, 3, 8, 12, 12, 12, 12,
          3, 3, 7, 12, 12, 12, 12, 12,
          6, 8, 12, 12, 12, 12, 12, 12,
          12, 12, 12, 12, 12, 12, 12, 12,
          12, 12, 12, 12, 12, 12, 12, 12,
          12, 12, 12, 12, 12, 12, 12, 12,
          12, 12, 12, 12, 12, 12, 12, 12};

Swordfish

...

Enno

Swordfish schrieb:

Die ganze Kacke steht doch eh in CCITT/ITU T.81!?

Geile Antwort. Das steht auch alles in meinem Buch! Antwort auf meine Frage ist das trotzdem nicht.