JPEG Bilder die 2te

[Swordfish]

...

[Enno]

Ich hab da mal rein geluschert udn auf meine spezielle Frage keine Antwort gefunden. Darfst mir gerne verraten wo das steht.

[SeppJ]

Enno schrieb:

Ich hab da mal rein geluschert

Dir wurde hier wieder und wieder gesagt, dass du dich mit deinem Projekt vollkommen übernimmst. Du hast wieder und wieder versichert, dass du dich unbedingt durchbeißen möchtest. Und jetzt bist du zu unkonzentriert/faul, die grundlegende Beschreibung des Formates gründlich durchzulesen?

Ich weiß wirklich nicht, wie man dir noch helfen soll...

[Swordfish]

...

[Enno]

Swordfish schrieb:

Enno schrieb:

Darfst mir gerne verraten wo das steht.

Das ist aber überaus gnädig von dir!

CCITT/ITU T.81, p. 15 schrieb:

[...] No default values for quantization tables are specified in this Specification; applications may specify values which customize picture quality for their particular image characteristics, display devices, and viewing conditions. [...]

// edit: Bevor du jetzt auf die Idee kommst zu Fragen, wo du die Quantization tables denn nun herzaubern sollst: Section B.2.4.1: Quantization table-specification syntax, ebendort.

Danke genau das wollte ich wissen.
Aber wie ich an die DQT komme weiß ich danke.
Geht bei FFDB los, nächsten 4 Zeichen geben die Länge, nächstes Zeichen die Genauigkeit der Werte, das nächste Zeichen die Tabellen Nr. und die dadrauf folgenden 64 Bytes sind dann im ZigZag die Tabelle. (wenn die Länge 67 ist )

[Swordfish]

...

[Enno]

Nein das war der Hammer der immer gegen meine Kopf geschlagen hat!!!
Aber so konnte mir das hier auch keiner sagen.

P.S.: Ich steck da jetzt voll drin muss das jetzt nur noch in Code umsetzten das wird auf jeden fall noch dauern.

[Enno]

So ich hab hier jetzt mal was geschrieben und würde einfach gerne mal hören ob ihr das so gut findet!
Das mit dem new hab ich so weil das in allen Projekten so drin ist. Da würde ich gerne nicht drüber diskutieren.
Ansonsten würde ich gerne wissen ob ihr versteht was ich da mache.

DQT.h

#include <iostream>

#include "marker.h"

class DQT{
public:
  ZigZag();
  ~ZigZag();
  void getPointer();
  void buildQT(const char* dqt, int dqtcount);
private:
  Marker *marker;
  int    quantTable[0][64];
};

DQT.cpp

#include <iostream>
#include <vector>

#include "DQT.h"

DQT::DQT(){
  marker = new Marker(); //Aus der Klasse Marker bekomme ich die Pointer auf die stelle FFDB
}

DQT::~DQT(){
  delete marker;
}

/*
 * function to get pointer to quantization table
 */
void DQT::getPointer(){
  int dqtcount = marker->getDQTcount();
  for(int i=0; i<=dqtcount; i++){
    marker->setDQTcounter(i);
    const char* dqt = marker->getDQT();
    if(!dqt)
      return;
    DQT::buildQT(dqt+5);
  }
}

/*
 * function to build quantisation table
 */
void DQT::buildQT(const char* dqt, int dqtcount){
  bool up = true;
  char buf;
  int count = 0;
  for(int i=0; i<8; i++){
    if(up){
      for(int j=0; j<=i; j++){
        buf = (char)dqt[8 * (i - j) + j];
        quantTable[dqtcount][count++] = buf;
      } 
    }else{
      for(int j=i; j>=0; j--){
        buf = (char)dqt[8 * (i - j) + j];
        quantTable[dqtcount][count++] = buf;
      }
    }
    up = !up;
  }
  for(int i=7; i>=0; i--){
    if(up){
      for(int j=0; j<i; j++){
        buf = (char)dqt[8 * (7 - j) +  8 - i + j];
        quantTable[dqtcount][count++] = buf;
      }
    }else{
      for(int j=0; j<i; j++){
        buf = (char)dqt[8 * (8 - i + j) + 7 - j];
        quantTable[dqtcount][count++] = buf;
      }
    }
    up=!up;
  } 
}

[SeppJ]

Enno schrieb:

Das mit dem new hab ich so weil das in allen Projekten so drin ist. Da würde ich gerne nicht drüber diskutieren.

Dann brauchst du hier nicht zu fragen. Das new und wie du es benutzt ist ein ganz gravierender Mangel an deinem Code.

#include <iostream>

#include "marker.h"

class DQT{
public:
  void getPointer();
  void buildQT(const char* dqt, int dqtcount);
private:
  Marker marker;
  int    quantTable[0][64];
};

#include <iostream>
#include <vector>

#include "DQT.h"

/*
 * function to get pointer to quantization table
 */
void DQT::getPointer(){
  int dqtcount = marker.getDQTcount();
  for(int i=0; i<=dqtcount; i++){
    marker.setDQTcounter(i);
    const char* dqt = marker.getDQT();
    if(!dqt)
      return;
    DQT::buildQT(dqt+5);
  }
}

/*
 * function to build quantisation table
 */
void DQT::buildQT(const char* dqt, int dqtcount){
  bool up = true;
  char buf;
  int count = 0;
  for(int i=0; i<8; i++){
    if(up){
      for(int j=0; j<=i; j++){
        buf = (char)dqt[8 * (i - j) + j];
        quantTable[dqtcount][count++] = buf;
      }
    }else{
      for(int j=i; j>=0; j--){
        buf = (char)dqt[8 * (i - j) + j];
        quantTable[dqtcount][count++] = buf;
      }
    }
    up = !up;
  }
  for(int i=7; i>=0; i--){
    if(up){
      for(int j=0; j<i; j++){
        buf = (char)dqt[8 * (7 - j) +  8 - i + j];
        quantTable[dqtcount][count++] = buf;
      }
    }else{
      for(int j=0; j<i; j++){
        buf = (char)dqt[8 * (8 - i + j) + 7 - j];
        quantTable[dqtcount][count++] = buf;
      }
    }
    up=!up;
  }
}

Bamm! Ich habe nur Code entfernt und das Ergebnis ist tausendfach besser als das was da vorher stand.

edit: Noch eine Runde Codeentfernung, die das Ergebnis nochmal tausendmal besser macht:

/*
 * function to build quantisation table
 */
void DQT::buildQT(const char* dqt, int dqtcount){
  bool up = true;
  char buf;
  int count = 0;
  for(int i=0; i<8; i++){
    if(up){
      for(int j=0; j<=i; j++){
        buf = dqt[8 * (i - j) + j];
        quantTable[dqtcount][count++] = buf;
      }
    }else{
      for(int j=i; j>=0; j--){
        buf = dqt[8 * (i - j) + j];
        quantTable[dqtcount][count++] = buf;
      }
    }
    up = !up;
  }
  for(int i=7; i>=0; i--){
    if(up){
      for(int j=0; j<i; j++){
        buf = dqt[8 * (7 - j) +  8 - i + j];
        quantTable[dqtcount][count++] = buf;
      }
    }else{
      for(int j=0; j<i; j++){
        buf = dqt[8 * (8 - i + j) + 7 - j];
        quantTable[dqtcount][count++] = buf;
      }
    }
    up=!up;
  }
}

Schon Faktor eine Million. Noch eine Runde:

/*
 * function to build quantisation table
 */
void DQT::buildQT(const char* dqt, int dqtcount){
  bool up = true;
  int count = 0;
  for(int i=0; i<8; i++){
    if(up){
      for(int j=0; j<=i; j++){
        quantTable[dqtcount][count++] = dqt[8 * (i - j) + j];
      }
    }else{
      for(int j=i; j>=0; j--){
        quantTable[dqtcount][count++] = dqt[8 * (i - j) + j];
      }
    }
    up = !up;
  }
  for(int i=7; i>=0; i--){
    if(up){
      for(int j=0; j<i; j++){
        quantTable[dqtcount][count++] = dqt[8 * (7 - j) +  8 - i + j];
      }
    }else{
      for(int j=0; j<i; j++){
        quantTable[dqtcount][count++] = dqt[8 * (8 - i + j) + 7 - j];
      }
    }
    up=!up;
  }
}

Was macht eigentlich get_Pointer? Da wird gar nichts ge-get-et. Das up könntest du dir übrigens auch sparen, aber ich sehe ein, dass es dann eventuell unübersichtlich wird. Ist das eigentlich richtig, dass die beiden Member unabhängig und frei aufrufbar sind? Das klingt doch stark danach, als sollten die beiden private sein und vom Konstruktor aufgerufen werden.

[daddy_felix]

Ich kenne mich mit dem JPG-Komprimierungsverfahren nciht aus, kann daher inhaltlich nicht wirklich viel sagen. So ein paar Anmerkungen zum Code allgemein:

* marker.h brauchst du im Header nicht, da reicht eine Vorwärtsdeklaration (ein Vorteil durch die Pointer-Implementierung)
* "getPointer" ist sehr ungünstig gewählt. "get" impliziert, dass es sich um einen Getter handelt. "Pointer" ist auch nicht sonderlich aussagekräftig.
* Anstelle von "int quantTable[0][64]" als rohes array zumindest std::array.
* Den Aufruf von marker->setDQTcounter(i) würde ich nicht separat machen, sondern das i an marker->getDQT() übergeben: marker->getDQT(i) - sofern diese Methoden nicht anderweitig ncoh verwendet werden.
* Der Rückgabewert von marker->getDQT() erscheint mir auch ein wenig fragwürdig. Würde ich auch eine Lösung der STL vorziehen.
* Der Aufruf DQT::buildQT(dqt+5); wird nicht kompilieren, da ein Argument zu wenig. Außerdem brauchst du das "DQT::" nicht.
* in buildQT sind mir zu viele magic numbers drin, besser durch lesbare Konstanten ersetzen

[Enno]

SeppJ schrieb:

Noch eine Runde:

/*
 * function to build quantisation table
 */
void DQT::buildQT(const char* dqt, int dqtcount){
  bool up = true;
  int count = 0;
  for(int i=0; i<8; i++){
    if(up){
      for(int j=0; j<=i; j++){
        quantTable[dqtcount][count++] = dqt[8 * (i - j) + j];
      }
    }else{
      for(int j=i; j>=0; j--){
        quantTable[dqtcount][count++] = dqt[8 * (i - j) + j];
      }
    }
    up = !up;
  }
  for(int i=7; i>=0; i--){
    if(up){
      for(int j=0; j<i; j++){
        quantTable[dqtcount][count++] = dqt[8 * (7 - j) +  8 - i + j];
      }
    }else{
      for(int j=0; j<i; j++){
        quantTable[dqtcount][count++] = dqt[8 * (8 - i + j) + 7 - j];
      }
    }
    up=!up;
  }
}

Was macht eigentlich get_Pointer? Da wird gar nichts ge-get-et. Das up könntest du dir übrigens auch sparen, aber ich sehe ein, dass es dann eventuell unübersichtlich wird. Ist das eigentlich richtig, dass die beiden Member unabhängig und frei aufrufbar sind? Das klingt doch stark danach, als sollten die beiden private sein und vom Konstruktor aufgerufen werden.

getpointer ist vielleicht als Name falsch gewählt aber bis auf den schirtt den ich Zitiert habe verstehe ich dich nicht.
1. Ich kann doch mein Speicher so verwalten ich hab ja auch mein delete drin.? Ist doch aberm it new schneller?
2. WTF?! Wie soll buildQT den jetzt wissen was abgeht und wo sie anfängt wenn du die getPointer Funktion einfach "wegkürzt"??

daddy_felix schrieb:

Ich kenne mich mit dem JPG-Komprimierungsverfahren nciht aus, kann daher inhaltlich nicht wirklich viel sagen. So ein paar Anmerkungen zum Code allgemein:

* marker.h brauchst du im Header nicht, da reicht eine Vorwärtsdeklaration (ein Vorteil durch die Pointer-Implementierung)
* "getPointer" ist sehr ungünstig gewählt. "get" impliziert, dass es sich um einen Getter handelt. "Pointer" ist auch nicht sonderlich aussagekräftig.
* Anstelle von "int quantTable[0][64]" als rohes array zumindest std::array.
* Den Aufruf von marker->setDQTcounter(i) würde ich nicht separat machen, sondern das i an marker->getDQT() übergeben: marker->getDQT(i) - sofern diese Methoden nicht anderweitig ncoh verwendet werden.
* Der Rückgabewert von marker->getDQT() erscheint mir auch ein wenig fragwürdig. Würde ich auch eine Lösung der STL vorziehen.
* Der Aufruf DQT::buildQT(dqt+5); wird nicht kompilieren, da ein Argument zu wenig. Außerdem brauchst du das "DQT::" nicht.
* in buildQT sind mir zu viele magic numbers drin, besser durch lesbare Konstanten ersetzen

*ok
*ja war behindert von mir.
*ok stimmt
*den ganzen kram hab ich jetzt noch mal ganz anders geplant mit einer next Funkion die in marker.h ist. Ist bisschen komplizierter. xD Müsste ich jetzt den ganzen Code posten aber auf jeden Fall gute Anregung werde ich was besser. machen.
*gleiche Begründung wie ein höher
*ja stimmt das Hab ich irgendwie komplett vergessen
*das versteh ich nicht was willst du da für Konstante??

[daddy_felix]

Enno schrieb:

*das versteh ich nicht was willst du da für Konstante??

Wenn ich sowas sehe:

dqt[8 * (7 - j) +  8 - i + j]

dann frage ich mich "Warum steht da mal eine 7, mal eine 8 und was zum Geier sind i und j"

es scheint hier ja um ein 2-dimensionales Feld zu gehen. Statt i und j vielleicht besser "row" und "col".

und mit Konstante meine ich sowas:

const int SIZE = 8;
for (unsigned int row = 0; row < SIZE; ++row)

[SeppJ]

Enno schrieb:

getpointer ist vielleicht als Name falsch gewählt aber bis auf den schirtt den ich Zitiert habe verstehe ich dich nicht.
1. Ich kann doch mein Speicher so verwalten ich hab ja auch mein delete drin.?

Du darfst auch gerne zu Fuß über die Autobahn gehen, trotzdem ist es nicht unbedingt gut, so zu handeln.

Ist doch aberm it new schneller?

Unter anderem. Zudem viel einfacher zu benutzen. Dein Code enthält nämlich mindestens noch einen dicken Fehler bei der manuellen Speicherverwaltung, den jeder hier im Forum auf den ersten Blick sehen würde. Das wurde dir aber schon so oft gesagt, das sag ich dir nicht noch einmal, lies deine alten Threads.

2. WTF?! Wie soll buildQT den jetzt wissen was abgeht und wo sie anfängt wenn du die getPointer Funktion einfach "wegkürzt"??

Ich habe sie bloß nicht jedes Mal gezeigt. Deine Empörung zeigt aber, dass die Funktionen nicht unabhängig sind und meine Vermutung

SeppJ schrieb:

Ist das eigentlich richtig, dass die beiden Member unabhängig und frei aufrufbar sind? Das klingt doch stark danach, als sollten die beiden private sein und vom Konstruktor aufgerufen werden.

wohl voll ins Schwarze trifft. Lass mich raten wie das Objekt benutzt wird:

DQT dqt;
dqt.getPointer();
dqt.buildQT(parameter1, parameter2);

Trifft es das so etwa? Und wenn man den zweiten Schritt weglässt, dann klappt der dritte nicht und nur mit dem Ergebnis des ersten Schritts kann man wahrscheinlich auch noch nichts machen.

[knivil]

Zwischenfrage: Was ist das?

int    quantTable[0][64];

[Enno]

SeppJ schrieb:

Enno schrieb:

getpointer ist vielleicht als Name falsch gewählt aber bis auf den schirtt den ich Zitiert habe verstehe ich dich nicht.
1. Ich kann doch mein Speicher so verwalten ich hab ja auch mein delete drin.?

Du darfst auch gerne zu Fuß über die Autobahn gehen, trotzdem ist es nicht unbedingt gut, so zu handeln.

Ist doch aberm it new schneller?

Unter anderem. Zudem viel einfacher zu benutzen. Dein Code enthält nämlich mindestens noch einen dicken Fehler bei der manuellen Speicherverwaltung, den jeder hier im Forum auf den ersten Blick sehen würde. Das wurde dir aber schon so oft gesagt, das sag ich dir nicht noch einmal, lies deine alten Threads.

Du sprichst den const char* an richtig? Ich weiß nicht aber du weiß ja nicht was ich da zurück gebe. Ich gebe dort einen Pointer zurück der in einem struct liegt. Kp ob du das dann sinnvoller findest. Aber da ich jetzt mehr wissen hab als in meinen alten Threads darfst du gerne mir sagen wieso das ein DICKER Fehler ist.

SeppJ schrieb:

2. WTF?! Wie soll buildQT den jetzt wissen was abgeht und wo sie anfängt wenn du die getPointer Funktion einfach "wegkürzt"??

Ich habe sie bloß nicht jedes Mal gezeigt. Deine Empörung zeigt aber, dass die Funktionen nicht unabhängig sind und meine Vermutung

SeppJ schrieb:

Ist das eigentlich richtig, dass die beiden Member unabhängig und frei aufrufbar sind? Das klingt doch stark danach, als sollten die beiden private sein und vom Konstruktor aufgerufen werden.

wohl voll ins Schwarze trifft. Lass mich raten wie das Objekt benutzt wird:

DQT dqt;
dqt.getPointer();
dqt.buildQT(parameter1, parameter2);

Trifft es das so etwa? Und wenn man den zweiten Schritt weglässt, dann klappt der dritte nicht und nur mit dem Ergebnis des ersten Schritts kann man wahrscheinlich auch noch nichts machen.

Nope so wird das nicht benutzt.

Ich hab jetzt den ganzen kram noch einmal verbessert.

DQT.h

#include <iostream>

#include "marker.h"

class DQT{
public:
  ZigZag();
  ~ZigZag();
private:
  void findDQT();
  void buildQT(int dqtcount);
  Marker *marker;
  int    quantTable[0][64];
};

DQT.cpp

#include <iostream>
#include <vector>

#include "DQT.h"

DQT::DQT(){
  marker = new Marker();
}

DQT::~DQT(){
  delete marker;
}

/*
 * function to build quantisation table
 */
void DQT::buildQT(){
  const char* dqt = marker->getDQT();
  do{
    bool up = true;
    int count = 0;
    for(int i=0; i<8; i++){
      if(up){
        for(int j=0; j<=i; j++){
          quantTable[i][count++] = (char)dqt[8 * (i - j) + j];
        }   
      }else{
        for(int j=i; j>=0; j--){  
          quantTable[i][count++] = (char)dqt[8 * (i - j) + j];
        }
      }
      up = !up;
    }
    for(int i=7; i>=0; i--){
      if(up){
        for(int j=0; j<i; j++){
          quantTable[i][count++] = (char)dqt[8 * (7 - j) +  8 - i + j];
        }
      }else{
        for(int j=0; j<i; j++){
          quantTable[i][count++] = (char)dqt[8 * (8 - i + j) + 7 - j];
        }
      }
      up=!up;
    } 
  }while(marker->nextIndex() == true)
}

nur kleiner ausschnitt aus maker.h und marker.cpp
maker.h

struct POS{ //save pointers on Markers
  char *APP;
  char **DQT; //to save same pointers in 1 with index [DQTcount]
  char *SOF;
  char **DHT; //to save same pointers in 1 with index [DHTcount]
  char *SOS;
  int  DQTcount; 
  int  DHTcount;
};

marker.cpp

void Marker::findMarker(const char* SOI, size_t length){
  for(unsigned int i=0; i<length; i++){
    if(SOI[i] == (char)0xff){
      i++;
      switch(SOI[i]){
        case 0xe0:
          POS.APP = &SOI[i];
          break;
        case 0xdb:
          POS.DQT[POS.DQTcount] = &SOI[i];
          POS.DQTcount++;
          break;
        case 0xc0:
          POS.SOF = &SOI[i];
          break;
        case 0xc4:
          POS.DHT[POS.DHTcount] = &SOI[i];
          POS.DHTcount++;
          break;
        case 0xda:
          POS.SOS = &SOI[i];
          break;    
      }//switch
    }//if
  }//for
}

/*
 * next function to return all DQT pointer
 */
bool Marker::nextIndex(){
  DQTindex++;
  if(POS.DQT[DQTindex] > POS.DQT[POS.DQTcount]) return false;
  return true;
}
const char* Marker::getDQT(){
  return POS->DQT[POS.DQTcount];
}

Das mit dem int quantTable[0][64] mach ich jetzt also muss dazu nicht unbedingt was gesagt werden. Das ändere ich jetzt wollte nur schon mal auf SeppJ antworten.

[Nexus]

Enno schrieb:

Das mit dem int quantTable[0][64] mach ich jetzt also muss dazu nicht unbedingt was gesagt werden

Doch, muss schon. Deutlicher als knivil: Was bewirkt das 0 hier?

Ein paar Bemerkungen zu deinem letzten Code:

• Warum castest du eigentlich nach char , was schon ein char ist? Ohnehin solltest du keine C-Casts, sondern static_cast und die anderen C++-Operatoren benutzen.
• Deine DQT -Klasse verletzt die Regel der Grossen Drei (angenommen, Konstruktor/Destruktor wären richtig benannt).
• Würdest du STL-Container statt new[] und delete[] verwenden, wäre die Regel der Grossen Drei automatisch erfüllt, und du hättest sonst einige Probleme weniger.
• Verwende die Konstruktor-Initialisierungsliste statt Zuweisungen.
• Im Weiteren hast du nicht benutzte #includes .
• Explizite Vergleiche auf == true sind unnötig.
• Statt if (x) return true; else return false; schreibe return x; .
• Bevorzuge in For-Schleifen Prä-Inkrement über Post-Inkrement, bei Iteratoren kann der Unterschied relevant werden.
• Zeiger auf Zeiger sind in C++ fast immer unnötig. Wahrscheinlich kann man das besser lösen.

[Enno]

Nexus schrieb:

Doch, muss schon. Deutlicher als knivil: Was bewirkt das 0 hier?

Ehm also was ich dort machen wollte ist das ich ein 2d Array haben möchte. Die 0 hab ich dort eingetragen weil mir gesagt wurde, wenn ich diese dort reinschreibe ich so viele Spalten erhalte wie ich brauche. Mal 2 Spalten mal 4 Spalten.

**Ein paar Bemerkungen zu deinem letzten Code:
[list][*]Warum castest du eigentlich nach char , was schon ein char ist? Ohnehin solltest du keine C-Casts, sondern static_cast und die anderen C++-Operatoren benutzen.
**
Hab ich vergessen..

**[*]Deine DQT -Klasse verletzt die Regel der Grossen Drei (angenommen, Konstruktor/Destruktor wären richtig benannt).
***[]Würdest du STL-Container statt new[] und delete[] verwenden, wäre die Regel der Grossen Drei automatisch erfüllt, und du hättest sonst einige Probleme weniger.
***[]Verwende die Konstruktor-Initialisierungsliste statt Zuweisungen.
**
Das schau ich mir jetzt noch einmal genauer an.

**[*]Im Weiteren hast du nicht benutzte #includes .
**
Hoppla.

**[*]Explizite Vergleiche auf == true sind unnötig.
**
Warum?

[*]Statt if (x) return true; else return false; schreibe return x; .
ich weiß nicht aber für mich leuchtet das nicht ein warum ich da return x; machen soll. Ich will ja nicht x haben sondern solange true zurück geben bis **DQT also *DQT[] komplett durch ist. Ich hab also mehrere Zeiger die ich mit einem index durchlaufen kann. So war der Plan.

**[*]Bevorzuge in For-Schleifen Prä-Inkrement über Post-Inkrement, bei Iteratoren kann der Unterschied relevant werden.
**
Verstehe ich nicht, wo soll das den dort grade besser sein und warum ist das allgemein besser?

**[*]Zeiger auf Zeiger sind in C++ fast immer unnötig. Wahrscheinlich kann man das besser lösen.**Ich denke das hab ich oben schon gesagt bei dem return.

[Jockelx]

Enno schrieb:

**[*]Explizite Vergleiche auf == true sind unnötig.
**
Warum?

Weil du doch eh schon einen boolschen Wert hast. Warum testest du den nochmal auf == true?
Das ändert den boolschen Wert nicht und macht es nur schwerer lesbar.

Enno schrieb:

[*]Statt if (x) return true; else return false; schreibe return x; .
ich weiß nicht aber für mich leuchtet das nicht ein warum ich da return x; machen soll. Ich will ja nicht x haben sondern solange true zurück geben bis **DQT also *DQT[] komplett durch ist. Ich hab also mehrere Zeiger die ich mit einem index durchlaufen kann. So war der Plan.

Das Gleiche. Du hast schon einen boolschen Wert! Gib den doch zurück (mit ! in deinem Fall).

Enno schrieb:

**[*]Bevorzuge in For-Schleifen Prä-Inkrement über Post-Inkrement, bei Iteratoren kann der Unterschied relevant werden.
**
Verstehe ich nicht, wo soll das den dort grade besser sein und warum ist das allgemein besser?

Das ist dort egal, aber warum solltest du dir die ungünstigere Variante angewöhnen?
Wie gesagt, wenn mal über Iteratoren iterierst, ist der Prä-Inc besser, da Post-Inc eine lokale Kopie erstellt.

[Nexus]

Enno schrieb:

Ehm also was ich dort machen wollte ist das ich ein 2d Array haben möchte. Die 0 hab ich dort eingetragen weil mir gesagt wurde, wenn ich diese dort reinschreibe ich so viele Spalten erhalte wie ich brauche. Mal 2 Spalten mal 4 Spalten.

Wer hat das gesagt? Das ist nämlich Schwachsinn. Arrays sind in C++ nicht veränderbar in ihrer Grösse. Dazu könnte man eben STL-Container nehmen.

Enno schrieb:

**[*]Explizite Vergleiche auf == true sind unnötig.
**Warum?

Du schreibst auch nicht if ((2 < 3) == true) , wieso also if (marker->nextIndex() == true) ? Davon abgesehen ist "nextIndex" ein verwirrender Name, niemand würde hier einen bool -Typen erwarten.

Enno schrieb:

Ich will ja nicht x haben sondern solange true zurück geben bis **DQT also *DQT[] komplett durch ist.

Nimm nicht alles wörtlich, x war nur ein Platzhalter für beliebige boolsche Ausdrücke.

Enno schrieb:

Ich denke das hab ich oben schon gesagt bei dem return.

"Mehrere Zeiger mit einem Index durchlaufen" verstehe ich nicht, wozu brauchst du überhaupt mehrere Zeiger? Wieso reicht eine einfache Indirektion nicht? Denk dran, du kannst 2D-Arrays auch auf 1D-Arrays abbilden und dann Indizes umrechnen. In deinem Fall der Quantisierungstabellen könnte man sich sogar eine kleine Klasse überlegen, oder aber mindestens eine globale at(array, x, y) -Funktion, die Indizes auf 1D abbildet.

Enno schrieb:

Verstehe ich nicht, wo soll das den dort grade besser sein und warum ist das allgemein besser?

a = i++

ist semantisch äquivalent zu

auto copy = i;
++i;
a = copy;

Bei Built-In-Typen spielt das zwar keine Rolle, wenn du den Ausdruck nicht weiterverwendest. Aber besser, du gewöhnst dir das gleich richtig an, Prä-Inkrement kostet ja nichts.

[Enno]

Nexus schrieb:

Enno schrieb:

Ehm also was ich dort machen wollte ist das ich ein 2d Array haben möchte. Die 0 hab ich dort eingetragen weil mir gesagt wurde, wenn ich diese dort reinschreibe ich so viele Spalten erhalte wie ich brauche. Mal 2 Spalten mal 4 Spalten.

Wer hat das gesagt? Das ist nämlich Schwachsinn. Arrays sind in C++ nicht veränderbar in ihrer Grösse. Dazu könnte man eben STL-Container nehmen.

Ok dann wurde mir mist erzählt!!! -.-
Danke.

Nexus schrieb:

Enno schrieb:

**[*]Explizite Vergleiche auf == true sind unnötig.
**Warum?

Du schreibst auch nicht if ((2 < 3) == true) , wieso also if (marker->nextIndex() == true) ? Davon abgesehen ist "nextIndex" ein verwirrender Name, niemand würde hier einen bool -Typen erwarten.

Ok das leuchtet ein. Danke.

Nexus schrieb:

Enno schrieb:

Ich will ja nicht x haben sondern solange true zurück geben bis **DQT also *DQT[] komplett durch ist.

Nimm nicht alles wörtlich, x war nur ein Platzhalter für beliebige boolsche Ausdrücke.

Enno schrieb:

Ich denke das hab ich oben schon gesagt bei dem return.

"Mehrere Zeiger mit einem Index durchlaufen" verstehe ich nicht, wozu brauchst du überhaupt mehrere Zeiger? Wieso reicht eine einfache Indirektion nicht? Denk dran, du kannst 2D-Arrays auch auf 1D-Arrays abbilden und dann Indizes umrechnen. In deinem Fall der Quantisierungstabellen könnte man sich sogar eine kleine Klasse überlegen, oder aber mindestens eine globale at(array, x, y) -Funktion, die Indizes auf 1D abbildet.

Das Problem ist das ich den gleichen(nicht selben) Zeiger habe. Es gibt nun mal mehrere Qunatisierungstabellen.

Nexus schrieb:

Enno schrieb:

Verstehe ich nicht, wo soll das den dort grade besser sein und warum ist das allgemein besser?

a = i++

ist semantisch äquivalent zu

auto copy = i;
++i;
a = copy;

Bei Built-In-Typen spielt das zwar keine Rolle, wenn du den Ausdruck nicht weiterverwendest. Aber besser, du gewöhnst dir das gleich richtig an, Prä-Inkrement kostet ja nichts.

Ok aber ich versteh den Sinn noch nicht was dadran so toll ist. Sorry aber für mich sind das einfach mehr Zeilen. Also wo gewinne ich da einen Vorteil?

Ich danke dir Nexus das du mir hier so viel hilfst.