Auf dem Weg von DDraw nach OpenGL ..

[HeinzK]

Ok .. glu.h und GLU eingebaut und es funktioniert.
Wo liegen unter Linux eigentlich die Lib's und h-Dateien (also glu.h bzw. glu.lib)?

[Psycho]

Oder aber glOrtho():

gluOrtho2D sets up a two-dimensional orthographic viewing region. This is equivalent to calling glOrtho with near=-1 and far=1.

[HeinzK]

Danke für den Hinweis.

[Tobiking]

Wo liegen unter Linux eigentlich die Lib's und h-Dateien (also glu.h bzw. glu.lib)?

Das ist nicht immer ganz einheitlich. Nach dem FHS (Filesystem Hierarchy Standard) befinden sich die Header und Libs für das System selber unter /usr/include und /usr/lib (oft auch /usr/lib64). Manchmal wird aber auch /usr/TARGET/lib usw. für das Standardtarget genutzt. Das Target das st so etwas wie i386-linux-gnu. Wenn man Libs selber compiliert haben diese auch oft als Ziel /usr/local/lib. Eine Distribution kann das allerdings auch ganz anders machen.

[HeinzK]

Ok, dann werde ich diese auf finden .. und weiter im Text:
Linux/Ubuntu/OpenGL: Ist es richtig, dass am Programmende keine Resourcen (Window, OpenGL) freigegeben werden müssen?

[Aramis]

hmm ja, Resourcen muesstest du eigentlich schon freigeben. Fuer die ganzen X11–Objekte gibt es meist entsprechende Loesch-Funktionen, z.B. XFreeColormap, XDestroyWindow, XCloseDisplay

[HeinzK]

Gut zu wissen, in meinem vorliegenden Beispiel hat sich keiner darum gekümmert.

[HeinzK]

Ich habe versucht meine erste Klasse unter Linux/C++ entwerfen:

Code: Alles auswählen

class CKOpenDisplay : public CObject
{
  public:
    CKOpenDisplay(void);
    virtual ~CKOpenDisplay(void);

  private:

};

Ist es das, was ich fürchte .. es gibt kein CObject unter Linux .. oder was habe ich falsch gemacht?
/home/hk/TestOpenGL/KOpenGL.h|2|error: expected class-name before ‘{’ token|
||=== Build finished: 1 errors, 0 warnings ==pe

[Aramis]

CObject gehoert zu MFC. Die gibt es unter Linux nicht, und auch unter Windows wuerde ich davon abraten. Entweder ueberhaupt keine Basisklasse … oder eine selbstgebastelte, falls alle deine Klassen sich gewisse Verhaltensweisen teilen.

[HeinzK]

Das Problem ist .. ich verliere ohne CObject das Serialize .. war bisher Bequem und einfach damit alle Variablen incl. Objektzeiger zu speichern und zu laden .. jammerschade ..
PS:
Ich bin für eine LFC (Linux Foundation Classes) !

[Aramis]

Ja, Serialisierung wirst du dir wohl selber basteln muessen. boost.serialization kann dabei vielleicht helfen.

[HeinzK]

Ok, danke für den Hinweis mit dem 'serialize'. Für heute ist Schluss, das alles muss ich zuerst einmal verkraften ..

[HeinzK]

Ich hab' heut nacht im Traum 'Serialize' programmiert .. und glaub', so könnt es sogar klappen.
Frage:
Bisher habe ich CString genutzt. Als Ersatz habe ich mal mit std::string 'gespielt'.
OK, was ich nutze, ist fast alles vorhanden, außer 'Format'.
Beispiel:

Code: Alles auswählen

CString sText;
sText.Format("%s%d%0.5f", "Test", 100, 4.5);

Wie löst man das am effektivsten mit std::string?

[Aramis]

Mit std::stringstream:

Code: Alles auswählen

std::stringstream ss;
ss << 4.f << " ist eine tolle Zahl";
const std::string s = ss.str();

Das kann man auch noch geschickt wrappen um die Konstruktion des temporaeren stringstream's zu verbergen. Alternativ, wenn du naeher an CString::Format bleiben willst, boost.format. Bietet ebenso wie std::stringstream Typsicherheit.

Ansonsten gibt es noch sprintf, eine Hilfsfunktion aus der C–Standardbibliothek. Du kannst deine Strings in einem statischen Buffer zusammenbasteln und dann in einen std::string konvertieren (das ist von den Genannten die unidiomatischte Methode, und die gefaehrlichste).

[HeinzK]

Ich bin am experimentieren.
Im Moment bin ich auf gutem Weg eine Lösung zu finden.
Problem:

Code: Alles auswählen

std::stringstream ss;

Unbehandelte Ausnahme ... std::bad_alloc ..
Habe ich da ein Problem, weil ich mit 'new' und 'delete' arbeite? Oder was ist los.
Was ich eigentlich machen will:

Code: Alles auswählen

char *cBuff = new char[256];
..
std::string sFrm(cBuff);

Also einfach ein CharArray eine std::string zuordnen. Was mach ich da falsch? Oder geht auch das nicht?

[kimmi]

Der char-Array sollte NULL-terminiert sein.

Gruß Kimmi

[HeinzK]

Bin kurz vor der Lösung meines Problems (hoffe ich). Es scheint an 'new/delete' kontra 'malloc/free' zu liegen.
Ich vermute std::string arbeitet mit 'malloc/free' und ich habe den char* mit 'new/delete' angelegt. Sobald es läuft (oder auch nicht) melde ich mich wieder.

[Aramis]

Nein.

Dein Fehler ist, dass dir das RAII-Konzept (siehe Wikipedia) nicht gelaeufig ist. Dahinter steht, vereinfacht, die automatische Verwaltung von Resourcen durch den Konstruktor/Destruktor Mechanismus von C++.

Wenn du deine Objekte sauber designst, musst du so gut wie *nie* Speicher manuell erzeugen oder freigeben. Die STL, zu der std::string zaehlt, ist ein Paradebeispiel dafuer. Welchen Allokator dein String intern benutzt um seinen Buffer anzulegen, ist irrelevant – du kriegst davon gar nichts mit.

Nicht DU musst Speicher anlegen und dem String geben. Sondern der String legt fuer sich selber den Speicher an, den er benoetigt – und gibt ihn frei, sobald er selber zerstoert wird. Wenn du dem c‘tor eine Zeichenkette uebergibst, so versucht er eine Kopie davon zu erstellen und sieht diese fortan als sein Eigentum an.

(vermutlich war der Speicherbereich, den du versucht hast an den String zu ‘binden’, undefiniert – der Versuch davon eine Kopie zu machen knallt also mit hoher Wahrscheinlichkeit, da die Laenge des Strings ja von der Praesenz eines Null-Zeichens am Ende abhaengt)

Code: Alles auswählen

void foo(..)
{
// erstellt eine Kopie des Strings 'ahoi' und legt sie im Objekt ab
std::string s = "ahoi";

// erstellt eine unaebhaengige Kopie des Objektes
std::string s2 = s;

// std::string definiert den '+'–Operator um zwei Strings zu verknuepfen. 
// das Ergebnis ist ein dritter, der wieder fuer sich selber Speicher anlegt.
std::string s3 = s2+s;

// genau jetzt wird der d'tor der strings aufgerufen. Aller Speicher wird freigegeben.
}

[HeinzK]

Ja, das habe ich verstanden. Mein Problem war einen char* nach std::string zu konvertieren.
Ich habe es nun gelöst, in dem ich eine eigene String-Klasse angelegt habe. Diese wird die
von mir benutzten Methoden von CString mit Hilfe von std::string nachbilden.
Vorerst habe ich das Problem mit Visual Studio bearbeitet .. und es läuft. Nun werde
ich es auf Linux/Ubuntu portieren .. melde mich wieder.

[HeinzK]

Geschafft, ein erster Entwurf von CKString ist im 'Kasten'.

Code: Alles auswählen

  
CKString sKStr1("Test1");
 cout << "A: " << sKStr1.GetsStr() << endl;

int iLen = sKStr1.GetLength();
cout << "B: " << iLen << endl;

CKString *pKStr2 = new CKString("Test2");
CKString sKStr3;
sKStr3 = pKStr2->GetsStr();
if (pKStr2 != NULL)
{
delete pKStr2;
pKStr2 = NULL;
}
cout << "C: " << sKStr3.GetsStr() << endl;

CKString sKStr4;
sKStr4.SetsKString("Test4");
sKStr4 = sKStr4.Left(2);
cout << "D: " << sKStr4.GetsStr() << endl;

CKString sKStr5;
sKStr5.SetsKString("Test5");
sKStr5 = sKStr5.Right(3);
cout << "E: " << sKStr5.GetsStr() << endl;

CKString sKStr6("Test6");
sKStr6 = sKStr6.Mid(1, 3);
cout << "F: " << sKStr6.GetsStr() << endl;

CKString sKStr7("TestCompare");
CKString sKStr8("TestCompare");
int iCmp = sKStr7.Compare(sKStr8);
cout << "G: " << iCmp << endl;

sKStr8.SetsKString("TestCom");
iCmp = sKStr7.Compare(sKStr8);
cout << "H: " << iCmp << endl;

sKStr8.SetsKString("TestComparer");
iCmp = sKStr7.Compare(sKStr8);
cout << "I: " << iCmp << endl;

CKString sKStr9;
sKStr9.Format("%s %d %0.3f", "Test1", 100, 1.23456789);
cout << "J: " << sKStr9.GetsStr() << endl;

Ergebnis:

Für alle die es testen wollen:
http://www.zwianer.de/$PCSpiel$/Problem ... String.zip
Mt CKString kann ich CString in meinem Quelltexten für Windows und Linux ersetzen. :D

[Krishty]

::std::string::empty() ist da um zu testen, ob der String leer ist. Um den String zu leeren (was sowieso nicht nötig ist, dafür sorgt der Konstruktor) gibt es ::std::string::clear().

Gruß, Ky

[HeinzK]

Das ist ein Unterschied zu CString:
CString::Empty leert den String und gibt den Speicher frei.
Der Test auf 'Leer' wird über CString::GetLength() gemacht.
Aber danke für diesen Hinweis. Diesen Unterschied hätte ich wahrscheinlich erst beim debuggen entdeckt.
PS:
Das Freigeben des Speichers kann durchaus Sinn machen, wenn z.Bsp. der String nur vorübergehend nicht mehr benutzt wird.

[Krishty]

Du kannst den Speicher nicht mit Sicherheit freigeben – die Größe des Strings wird zwar auf 0 gesetzt, intern bleibt aber noch was allokiert (.c_str() muss ja z.B. auch für leere Strings zumindest einen Zeiger auf eine Null zurückgeben). Und im Default-Konstruktor, von dem aus du .empty() aufgerufen hast, ist der String sowieso von Anfang an in diesem Zustand.

[HeinzK]

Ok, danke für die Hinweise.

[Aramis]

Das Freigeben des Speichers kann durchaus Sinn machen, wenn z.Bsp. der String nur vorübergehend nicht mehr benutzt wird.

Genau genommen gehen die meisten std::string–Implementierungen so vor, dass fuer kleinere Strings ein statischer Buffer direkt im String–Objekt zum Einsatz kommt (MSVC veranschlagt ~16Bytes). std::string::clear() trifft keine Aussage in Bezug auf den Speicherverbrauch, sondern setzt nur die Laenge des Strings zurueck auf 0.

[HeinzK]

Code: Alles auswählen

#ifdef _WIN32
  #include "stdafx.h"
#else
 #include "/media/D_DRIVE/Kempter/VC9/ZwiAnerOpenGL/Linux/Tests/TestKString/main.h"
#endif

Ich möchte die gleichen Dateien unter Windows und Linux nutzen.
Mache ich etwas falsch, oder ist es prinzipiell nicht möglich #ifdef und #include zu mischen?
Was ist die Alternative?

[Aramis]

Mache ich etwas falsch, oder ist es prinzipiell nicht möglich #ifdef und #include zu mischen?

Doch, das ist moeglich. Dein Beispiel inkludiert stdafx.h wenn _WIN32 definiert ist, andernfalls diesen schrecklichen Absolutpfad (wieso nicht einfach den Pfad als zusaetzlichen Includepfad an den Compiler uebergeben [gcc: -I<pfad>]).

[HeinzK]

Nein, das tut es nicht. Ich erhalte unter Windows einen fatal error C1019: Unerwartetes #else!
Den 'schrecklichen Absolutpfad' brauche ich im Moment für Ubuntu.
Ich versuche ja im Moment gemeinsam von Windows und Linux auf die gleiche Datei zuzugreifen.

[Aramis]

Nein, das tut es nicht.

Doch, tut es :-) Der Fehler muss an anderer Stelle liegen.

Ich erhalte unter Windows einen fatal error C1019: Unerwartetes #else!

Vielleicht fehlt am Ende der stdafx.h etwas. Die wird ja schließlich an genau der Stelle in den Quelltext eingefuegt. Wenn sie z.B so aussieht:

Code: Alles auswählen

#endif

… waere genau so eine Fehlermeldung die Folge.

[Krishty]

Ins Blaue: Deine Line-Endings sind nicht konsistent, weil du die Datei sowohl unter Windows als auch unter Linux bearbeitet hast.