Auf dem Weg von DDraw nach OpenGL ..

[HeinzK]

Ich arbeite unter VS mit /W3.

[Aramis]

Ja, gut – und wieso aenderst du den Prototyp nicht einfach ab, damit er ‘korrekt’ (im Sinne dass du ihn mit konstanten Stringliteralen benutzen kannst) ist?

Es ist eigentlich egal womit du arbeitest, wenn du standardkonformen Code schreibst. Machst du das nicht, meckert halt der eine oder andere Compiler. Eine implizite Konvertierung von const char* nach char* ist gemaeß Cpp03 illegal bzw. bestenfalls als C–Kompatibilitaets„feature” mit drin.

[HeinzK]

Auch für diesen Hinweis ein dankeschön. Ich war der Meinung das const char* den Zeiger auf den char meint und nicht den Inhalt.

Code: Alles auswählen

int Replace(const char *cAlt, const char *cNeu);

Jetzt meckert keiner mehr! :!:

[Krishty]

Ich war der Meinung das const char* den Zeiger auf den char meint und nicht den Inhalt.

Postfix-const und von hinten lesen. Aber eine Million Fliegen können sich ja nicht irren …

[Psycho]

Ich finde, dass char const * scheisse aussieht :( Genauso wie Vergleiche ala 1 == i.

[Krishty]

Nur, weil man in der natürlichen Sprache die Konstante zuletzt nennt? Man schreibt doch auch nicht i == 1 || 2 oder 1 < i < 3 … C++ ist kein Schönheitswettbewerb. Was den Code besser wartbar macht, ist immer vorzuziehen. Den Code bekommt kaum jemand je zu sehen, aber dafür jeder die Bugs zu spüren.

(Abgesehen davon finde ich Konsistenz noch immer am schönsten)

[Psycho]

Ok bei i == 1 bin ich noch kompromissbereit.

Und Du hast es bestimmt schon etliche Male hier im Forum erwähnt, aber kannste nochmal kurz sagen was an Postfix-Const besser ist? Seh es auf den ersten Blick jetzt nicht.

[Krishty]

Typen werden grundsätzlich rückwärts gelesen.
• int * liest du rückwärts als * int, „pointer to integer“.
• char const * const * & liest du rückwärts als & * const * const char, „reference to pointer to constant pointer to constant character“.

Abhängig davon hast du meistens keine andere Möglichkeit, als const hinten anzuhängen:
• Ein konstanter Zeiger zu einem int ist nunmal int * const. Wenn man jetzt die Präfix-Variante gewohnt ist, ist man geneigt, das fälschlicherweise als int const * zu schreiben (es ist aber „pointer to constant integer“ statt „constant pointer to integer“). Ebenso lässt sich ein konstanter Zeiger zu einem konstanten int nicht als const int const * schreiben (bzw. der Compiler lässt es zu, weil mehr als ein const pro Typ erlaubt ist, aber der Code tut nicht das, was man beabsichtigt – „pointer to constant int constant!?“).
• Eine Member-Funktion, die ihr Objekt nicht verändert, wird int Foo() const; deklariert. Mit Präfix wäre es auch hier unmöglich zu bestimmen, ob mit const die Funktion oder der Rückgabewert gemeint ist. (Bzw für den Compiler wäre glasklar, dass der Rückgabewert gemeint ist, und der Programmierer hätte keine Möglichkeit mitzuteilen, dass er die Funktion meint.)

Schade, dass C/V-Qualifier (const und volatile) überall stehen dürfen. Wenn der Standard Postfix vorschreiben würde, wäre uns sicher die Hälfte der Anfängerfehler in Sachen const-Correctness erspart geblieben.

Hach, ich liebe diesen Thread. Hier kann ich mal so richtig klugsch***en … ;)

[Psycho]

Dankeschön, das war ausführlich.

[HeinzK]

Die erste Runde ist wohl geschafft.
Ich habe die bisherigen Ergebnisse auf http://www.zwianer.de/$PCSpiel$/Downloa ... ojekte.htm zusammengefasst.
Von dort aus ist es möglich, dass gesamte Projekt für Windows und Linux herunterzuladen.

Unter <../Windows> befinden sich die Projekt-Dateien für VS 2008.
Unter <../Linux> befinden sich die Projekt-Dateien für g++.
Unter <../Gemeinsam> sind *.cpp;*.h, welche von beiden Systemen gemeinsam genutzt werden.

Als nächstes suche ich nun einen Ersatz für:

Code: Alles auswählen

CTypedPtrList<CPtrList, CKZnEbene *> k_pEbnLayObjListe;
//> Typischer Einsatz:
k_pEbnLayObjListe.AddTail(pEbene);
(k_pEbnLayObjListe.GetCount() > 0)
POSITION pos = k_pEbnLayObjListe.GetHeadPosition();
while (pos != NULL)
{
  CKZnEbene *pEbene = k_pEbnLayObjListe.GetNext(pos);
}
CKZnEbene *pEbene = k_pEbnLayObjListe.GetTail();
k_pEbnLayObjListe.RemoveAll();

Für alle Arten von Hinweisen bin ich sehr dankbar.
PS:
Wenn das geschafft ist, dann geht's endlich wieder mit der 'Grafik' weiter!

[glassbear]

std::vector oder std::list

[HeinzK]

Danke für den Hinweis.

[HeinzK]

Bin gerade am Testen von <vector>, <list> und <map>.
Nun ist beim 'Erstellen' schon mehrfach vorgekommen:

1>------ Erstellen gestartet: Projekt: TestKVector, Konfiguration: Debug Win32 ------
1>Verknüpfen...
1>TestKVector.obj : fatal error LNK1000: Internal error during IncrCalcPtrs

Ein nachfolgendes Erstellen klappt dann aber immer.
Hat jemand Erfahrung damit?
PS:
Microsoft Visual Studio 2008
Version 9.0.30729.1 SP
Microsoft .NET Framework
Version 3.5 SP1

[HeinzK]

OK, Problem erkannt .. aber nicht gebannt:
http://connect.microsoft.com/VisualStud ... crcalcptrs

[HeinzK]

Ich möchte nun folgendes machen:

Code: Alles auswählen

#include <string>
#include <list>
//> Declaration:
class CKList(X);
//> Implementation:
CKList::CKList(X)
{
  //> list<string *> liStrings;
  //> list<string *>::iterator li;
  list<X *> liStrings;
  list<X *>::iterator li;
}

Wie muss ich 'X' gestalten, um dies zu erreichen?

[Krishty]

Wie muss ich 'X' gestalten, um dies zu erreichen?

Gemäß einem beliebigen Tutorial über Klassentemplates. Oder die Klugsch***er-Antwort: X muss über einen Default- und Kopierkonstruktor verfügen ;)

[Schrompf]

Hör auf, die STL-Container ableiten zu wollen. Das wär ein Anfang.

Zu Deiner konkreten Frage: Du willst ein template schreiben. Den Syntax dafür kann ich Dir auf die Schnelle nicht erklären, da das Thema einfach zu umfangreich ist. Die Ableitung hier müsste etwa so aussehen:

Code: Alles auswählen

template <typename X> class IchWillMeineEigeneListe : public std::list<X>
{
  ...
}

Aber ich seh grad, Krishty war eh schneller.

[HeinzK]

Hör auf, die STL-Container ableiten zu wollen. Das wär ein Anfang.

Danke für den Ratschlag, aber ich muss wohl auf längere Sicht in beiden 'Welten' arbeiten.
Bis ich weiss, wo's langgeht, solange versuch' ich halt mit möglichst wenig codeumbau auszukommen. :)
Und danke für den Fisch .. ääh .. für die hilfreichen Tipps.
An diesem regnerischen Feiertag ist es schön ruhig bei der Arbeit .. ideal zum spielen .. ääh .. testen!

[HeinzK]

Ich schaff' es nicht CPtrList und <list> so zu wrappen, dass ich beide von aussen auf die gleiche Weise bedienen könnte.
Also werd' ich mich Wohl oder Übel für <list> entscheiden müssen! (CPtrList hat mir über 12 Jahre lang gute Dienste geleistet :( ).
Und weiter geht's:

Code: Alles auswählen

//> Auszug aus der CKString.h:
class CKString
{
  public:
    CKString(void);
    CKString(const CKString &sKStr);
    CKString(const string &sStr);
    virtual ~CKString(void);
    //> ...
    bool operator == (const CKString &sKStr) const;
    bool operator == (const string &sStr) const;
    bool operator < (const CKString &sKStr) const;
    bool operator < (const string &sStr) const;
    CKString &operator = (const CKString &sKStr);
    CKString &operator = (const string &sStr);
    CKString operator + (const CKString &sKStr);
    CKString operator + (const string &sStr);
    CKString operator += (const CKString &sKStr);
    CKString operator += (const string &sStr);
    //> ...
//> Eine Anwendung:
    {
          map<CKString, int> mpPunkteTab;
	  map<CKString, int>::iterator mp;
  	
	  pair<CKString, int> Spieler;
  	
	  Spieler = make_pair("Heinz", 100);         //> OK:
	  mpPunkteTab.insert(Spieler);
  	
	  Spieler.first = "Wingo";                   //> OK:
	  Spieler.second = 200;
	  mpPunkteTab.insert(Spieler);

          Spieler.first.SetString("Tester");         //> OK:
	  Spieler.second = 300;
	  mpPunkteTab.insert(Spieler);
	  
	  mp = mpPunkteTab.find(CKString("Wingo"));  //> OK:
	 [b] //mp = mpPunkteTab.find("Wingo");          //> Warum nicht?:[/b]
  	
	  if (mp != mpPunkteTab.end())
	  {
	    cout << mp->first.GetString() << " Punkte: " << mp->second << endl;
  	  
	  }
    }

Warum funktioniert 'mpPunkteTab.find("Wingo")' nicht?

[HeinzK]

Und noch eine Frage:

Code: Alles auswählen

{for (li = liKStrings.begin(); (li != liKStrings.end()); li++)
  cout << (*li)->GetString() << endl;   //> 1):
  (*li)->Format("%s= %i", "Test", li);    //> 2):
  cout << (*li)->GetString() << endl;

}

Zu 1):
Nur zur Laufzeit:
Program received signal SIGILL, Illegal instruction.
Zu 2):
Nach dem Linken:
warning: cannot pass objects of non-POD type ‘struct std::_List_iterator<CKString*>’ through ‘...’; call will abort at runtime
Unter VS2008 funkioniert der Code einwandfrei. Es wird auch keine Warnung ausgegeben!

[Alexander Kornrumpf]

2) Ich denke das liegt daran dass Format nicht typsicher ist, und dass hinten in format sehr wahrscheinlich *li (mit *) heißen soll.


EDIT: Zumindest wüsste ich nicht warum um alles in der Welt CKString::Format einen iterator als Parameter akzeptieren sollte.

[HeinzK]

Ok, ein Problem gelöst:

Code: Alles auswählen

(*li)->Format("%s= %i", "Test", li);    

Es sollte natürlich '.., "Test", *li);' lauten! (Da es unter VS2008 ohne Probleme lief, habe ich nicht mehr so genau hingeschaut :roll:)

Bin gerade am Testen ob 'CKString(const char* cStr);' mein zweites Problem löst:

Code: Alles auswählen

mp = mpPunkteTab.find(CKString("Wingo"));  //> OK: 
//mp = mpPunkteTab.find("Wingo");          //> Warum nicht?:

Wenn ich 'CKString kStr("TEST");' verwende wird bisher 'CKString(const string &sStr);' angesprochen.
Deshalb war ich der Meinung, ich brauche den 'char' nicht.

Ich habe die vollständigen Projekte zum Download bereitgestellt:
http://www.zwianer.de/Download/TestObjekte.exe
Darin finden sich folgende Verzeichnisse:
'Gemeinsam'
'Linux'
'Windows'
Unter Linux und Windows sind jeweils die vollständigen Projekte.

[Krishty]

Ich schaff' es nicht CPtrList und <list> so zu wrappen, dass ich beide von aussen auf die gleiche Weise bedienen könnte.

Ja, an so einer Liste musste ich trotz diverser Referenzimplementierungen im Internet ziemlich lange feilen. Es gibt bestimmt etwas bei boost oder so, das dir da hilft, aber da ich nicht weiß, was CPtrList von <list> und diversen auto_arrays unterscheidet (und scheinbar auch so ziemlich niemand anders hier), kann ich dir da auch nicht wirklich weiterhelfen … :/

Es sollte natürlich '.., "Test", *li);

Ein Hoch auf Format-Strings.

Lässt sich mpPunkteTab.find("Wingo"); garnicht erst kompilieren oder scheitert es zur Laufzeit? In ersterem Fall ist der Fehler, dass der Compiler nicht mehr als eine implizite Typkonvertierung zulässt … wenn eine Funktion wie CKString::CKString(…) einen ::std::string fordert aber einen char const * bekommt, kommt der Compiler noch drauf, dass man ersteren durch einen Konstruktor aus letzterem erzeugen kann. Wenn aber eine Funktion einen CKString fordert und einen char const * bekommt, kann der Compiler unmöglich auf den absurden Umweg kommen, erst einen ::std::string zu erzeugen. (Sonst könnte jeder Funktionsparameter über zwei oder drei Typen in jeden beliebigen anderen umgewandelt werden und die Typsicherheit wäre dahin. Ist sie auch so schon, deshalb gibt es ja explicit … hätten sie stattdessen lieber mal implicit implementiert …)

[HeinzK]

Ok, dein 'edit' war schneller! Aber ..

VS2008:
Konvertierung des Parameters 1 von 'const char [6]' in 'const CKString &' nicht möglich
Linux/Ubuntu/CB:
no matching function for call to ‘std::map<CKString, int, std::less<CKString>, std::allocator<std::pair<const CKString, int> > >::find(const char [6])’

.. ich erhalte diese Errors beim Kompilieren.

[HeinzK]

Auch dieses Problem gelöst, danke für eure Hilfe.

Code: Alles auswählen

class CKString
{
  public:
    CKString(void);
    CKString(const CKString &sKStr);
    CKString(const string &sStr);
    CKString(const char *cStr);
    virtual ~CKString(void);

    //> Funkt's:

    void Empty(void);
    string Format(const char *pFrm, ...);
    string Left(const int &iCn);
    string Right(const int &iCn);
    string Mid(const int &iC1, const int &C2);
    void MakeLower(void);
    void MakeUpper(void);
    
    int Compare(const CKString &sKStr) const;
    int Compare(const string &sStr) const;
    int Compare(const char *cStr) const;
    
    int CompareNoCase(const CKString &sKStr) const;
    int CompareNoCase(const string &sStr) const;
    int CompareNoCase(const char *cStr) const;
    
    int Replace(const char *cAlt, const char *cNeu);

    //> Set's:

    void SetString(const CKString &sKStr);
    void SetString(const string &sStr);
    void SetString(const char *cStr);

    //> Get's:

    int GetLength(void) const;
    const string &GetString(void) const;
    
    //> Operatoren:
    
    bool operator == (const CKString &sKStr) const;
    bool operator == (const string &sStr) const;
    bool operator == (const char *cStr) const;
    
    bool operator < (const CKString &sKStr) const;
    bool operator < (const string &sStr) const;
    bool operator < (const char *cStr) const;
    
    CKString &operator = (const CKString &sKStr);
    CKString &operator = (const string &sStr);
    CKString &operator = (const char *sStr);
    
    CKString operator + (const CKString &sKStr);
    CKString operator + (const string &sStr);
    CKString operator + (const char *sStr);
    
    CKString operator += (const CKString &sKStr);
    CKString operator += (const string &sStr);
    CKString operator += (const char *sStr);

  private:
    string k_sStr;
    int k_iStrLen;
    //> Funkt's:
    void Ini(void);
    string KFormatArgmList(const char *pFrm, va_list Argm);
};

Ich habe jetzt überall 3 Überladungen: CKString&, string& und char*.

[HeinzK]

Ich teste gerade den Einsatz von glDrawPixel(). Und nun habe ich folgende Fragen:

Code: Alles auswählen

// Vorbereitung:
glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0.0f, width, height, 0.0f);      //> KoordinatenSystem(Oben/Links):
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

Es geht um den Einsatz von gluOrtho2D(). glDrawPixel() ignoriert diese Einstellung richtig? (oder mache ich da etwas falsch)!
Zweite Frage: Die Umrechnung der Pixel von Unten/Links auf Oben/Links ist etwas komplex.

Code: Alles auswählen

unsigned long ulZe = ((ulPx / k_iBildX) + 1);  //> ulPx=Aktueller Pixel, k_iBildX=Pixel pro Zeile:
unsigned long ulPs = (k_ulRGBPixBuff - (ulZe * k_iBildX));  //> k_ulRGBPixBuff=Anzahl aller Pixel:
unsigned long ulPz = (ulPx - ((ulZe - 1) * k_iBildX));
unsigned long ulPk = (ulPs + ulPz);

Kann ich mir durch eine OpenGL-Einstellung diese Berechnungszeilen ersparen?
PS:
Warum Oben/Links? Ich arbeite im Moment noch mit DirectX. Dort schreibe ich Pixel direkt in das VRAM.
Und der Standard im VRAM für die Pixel ist von Oben/Links nach Unten/Rechts.

[HeinzK]

OK, anscheinend gibt es da wohl keine speziellen Funktionen, hab' bisher auch nichts mehr gefunden.
Aber was anderes.
Unter Linux/gcc fehlt mir der Befehl TRACE() (ist mal wieder einer aus der ATL).
Wie kann ich beim Debuggen mit cout oder printf() Texte in das Debug-Fenster schreiben?

[Aramis]

Evtl. suchst du nach std::cerr, dem standardmaessigen Fehlerjammerkanal, unter Linux meist direkt die Konsole quaelend. Unter Windows wuerde ich aber OutputDebugString nutzen – dann erst erscheinen die Messages im Debugger.

Code: Alles auswählen

#include <iostream>
std::cerr << "This is a number: " << 16 << std::hex << " .. and this is the same number: 0x" << 16 << std::endl;

[HeinzK]

Danke

[HeinzK]

Kann mir jemand mit einfachen Worten erklären warum das so und nur so funktioniert?

Code: Alles auswählen

class CKString
{
  public:
     const char &operator [] (const long lIdx) const;
};
void Test(const CKString sTxt)
{
  int i = 0;
  char cTk = sTxt[i];
}

Speziell der Unterschied zwischen dem ersten und letzten const.
Lasse ich das erste const weg >> 'error C2440' und CKString wird nicht kompiliert.
Lasse ich das letzte const weg wird CKString kompiliert, aber 'Test' nicht >> ' error C2678'.