Auf dem Weg von DDraw nach OpenGL ..
- Schrompf
- Moderator
- Beiträge: 5047
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Und da musst Du jetzt eine weitere Überladung von Compare() hinzufügen, die statt des Strings einen const char* annimmt. Der Compiler sagt Dir ja nur, dass er keinen temporären CKString aus dem übergebenen char-Array erzeugen kann. Also gibst Du ihm entweder einen passenden Konstruktor (std::string bietet den) oder Du erfindest eine zusätzliche Compare()-Variante, die einen const char* annimmt.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ok, hab's jetzt verstanden.
sMode.Compare(sFname) funktioniert jetzt schon .. werde es sofort ausprobieren. Danke.
sMode.Compare(sFname) funktioniert jetzt schon .. werde es sofort ausprobieren. Danke.
Es ist leichter, einen Sack Flöhe zu hüten.
Re: Auf dem Weg von DDraw nach OpenGL ..
Oder noch ein ctor:
CKString(const char *);
Aber mal Titten auf den Tisch: Solange Dir solche "Kleinarbeit" Spass macht und Du dabei etwas lernst, ist es sehr gut.
Sobald Du jedoch produktiv arbeiten möchtest, solltest Du die Möglichkeiten nutzen, die Dir durch std::string und std::stringstream bereits gegeben sind.
Die benutzen nämlich viele andere Benutzer auch, deswegen sind Fehler sehr unwahrscheinlich und gleichzeitig wird dein Code für jemand anderen schneller verständlich, wenn du die gängigen Methoden benutzt.
CKString(const char *);
Aber mal Titten auf den Tisch: Solange Dir solche "Kleinarbeit" Spass macht und Du dabei etwas lernst, ist es sehr gut.
Sobald Du jedoch produktiv arbeiten möchtest, solltest Du die Möglichkeiten nutzen, die Dir durch std::string und std::stringstream bereits gegeben sind.
Die benutzen nämlich viele andere Benutzer auch, deswegen sind Fehler sehr unwahrscheinlich und gleichzeitig wird dein Code für jemand anderen schneller verständlich, wenn du die gängigen Methoden benutzt.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Das Problem ist die Tonne voll vorhandenem Quelltext der auf CString und Co basiert.
Aber du hast Recht: mir macht das Programmieren Spass!
Ich bin im Moment am abwägen .. auf der Suche nach dem optimalsten Weg .. und natürlich dem minimalsten Arbeiteinsatzes.
Aber du hast Recht: mir macht das Programmieren Spass!
Ich bin im Moment am abwägen .. auf der Suche nach dem optimalsten Weg .. und natürlich dem minimalsten Arbeiteinsatzes.
Es ist leichter, einen Sack Flöhe zu hüten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Kann mir jemand sagen, wo ich die zuständige Definition von 'std::toupper' für 'std::transformation' von 'std::string' finde.
Ich suche seine Kollegen um zu sehen, welche Möglichkeiten noch vorhanden sind.
Ich suche seine Kollegen um zu sehen, welche Möglichkeiten noch vorhanden sind.
Es ist leichter, einen Sack Flöhe zu hüten.
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Was meinst du für „Möglichkeiten“?
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ich kenn' aus Beispielen nur toupper und tolower .. will nur wissen, was da noch alles 'möglich' (to transform) ist.
Es ist leichter, einen Sack Flöhe zu hüten.
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
http://www.cplusplus.com/reference/clibrary/cctype/
Außer toupper() und tolower() gibt’s da nichts zum transformieren.
Du musst wissen, dass transform() generisch ist und es anbietet, beliebige Dinge auf beliebigen Containern auszuführen – toupper() für Strings sind nur ein Beispiel, aber so ziemlich das Einzige, das es mit Buchstaben gibt.
Außer toupper() und tolower() gibt’s da nichts zum transformieren.
Du musst wissen, dass transform() generisch ist und es anbietet, beliebige Dinge auf beliebigen Containern auszuführen – toupper() für Strings sind nur ein Beispiel, aber so ziemlich das Einzige, das es mit Buchstaben gibt.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ok, ist angekommen.
Es ist leichter, einen Sack Flöhe zu hüten.
Re: Auf dem Weg von DDraw nach OpenGL ..
Hallo,
also an Deiner Stelle würde ich die Klasse CKString von std::string ableiten. So bleibst das ganze weitgehendst Standardkonform und man kann später immer noch die Standardfunktionen nutzen.
Nur so als kleiner Verbesserungshinweis. Außerdem würde ich nur das implentieren was Du benötigt und nicht die Klasse überfrachten.
also an Deiner Stelle würde ich die Klasse CKString von std::string ableiten. So bleibst das ganze weitgehendst Standardkonform und man kann später immer noch die Standardfunktionen nutzen.
Nur so als kleiner Verbesserungshinweis. Außerdem würde ich nur das implentieren was Du benötigt und nicht die Klasse überfrachten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
'class CKString : std::string' werde ich probieren, gute Idee.
Ja, ich implementiere nur die Funktionen, welche ich in meinen bisherigen Programmen verwendet habe.
Ich habe nicht vor die gesamte ATL-Funktionalität vollständig zu 'wrappen'.
Ja, ich implementiere nur die Funktionen, welche ich in meinen bisherigen Programmen verwendet habe.
Ich habe nicht vor die gesamte ATL-Funktionalität vollständig zu 'wrappen'.
Es ist leichter, einen Sack Flöhe zu hüten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Problem in VisualStudio 9.0, berifft aber nur eine Projektmappe:
Nach dem Wechsel von Debug auf Release bleibt _DEBUG definiert.
Wenn ich im Release-Modus die Maus auf _DEBUG lege:
Ich habe nirgends ein #define _DEBUG in meinem Quellquode!
Was ist da los? Kann mir dabei jemand helfen?
Nach dem Wechsel von Debug auf Release bleibt _DEBUG definiert.
Wenn ich im Release-Modus die Maus auf _DEBUG lege:
Ich habe nirgends ein #define _DEBUG in meinem Quellquode!
Was ist da los? Kann mir dabei jemand helfen?
Zuletzt geändert von HeinzK am 24.09.2010, 14:26, insgesamt 1-mal geändert.
Es ist leichter, einen Sack Flöhe zu hüten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ok, ich habe das Problem gefunden. Im Release-Modus war (aus Versehen) der C/C++-Schalter /MTd gesetzt.
Ein Umstellen auf /MT hat zuerst nichts gebracht. Es funktionierte erst als ich alle Release/Debug-Dateien und die *.ncb
gelöscht und das Projekt neu gestartet habe.
Ein Umstellen auf /MT hat zuerst nichts gebracht. Es funktionierte erst als ich alle Release/Debug-Dateien und die *.ncb
gelöscht und das Projekt neu gestartet habe.
Es ist leichter, einen Sack Flöhe zu hüten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ist '__max(..)' unter Linux nicht definiert?
Muss ich stattdessen 'max(..)' verwenden?
Wenn ja, wie kann ich den gleichen Quellcode dann am Besten kompatibel machen?
Ich verwende VS 9.0 und Code::Blocks 8.02.
Muss ich stattdessen 'max(..)' verwenden?
Wenn ja, wie kann ich den gleichen Quellcode dann am Besten kompatibel machen?
Ich verwende VS 9.0 und Code::Blocks 8.02.
Es ist leichter, einen Sack Flöhe zu hüten.
-
- Establishment
- Beiträge: 191
- Registriert: 01.03.2009, 19:22
- Echter Name: David N.
Re: Auf dem Weg von DDraw nach OpenGL ..
Soweit ich weiß, sind __min und __max, wie auch schon durch den Underscore-Prefix angedeutet, nicht standardisierte Funktionen aus der <cstdlib> von MSVC.
Die einfachste Alternative wäre wohl, die standardisierten std::min und std::max aus <algorithm> zu verwenden.
Die einfachste Alternative wäre wohl, die standardisierten std::min und std::max aus <algorithm> zu verwenden.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ja, wenn ich ein neues Projekt aufziehen würde .. kein Problem .. aber ich suche einen Weg,
bestehenden Quellcode in beiden Systemen weiterzuverwenden (sagte er etwas hilflos).
Mein nächstes Problem ist ähnlich:
'strcmp (..)' wird gefunden '_strcmp(..)' leider nicht!
Ok, du sagts, alles was mit '_' beginnt ist nicht in der <cstdlib> und damit unter Linux nicht vorhanden!? .. Schade. :(
EDIT:
Aus einen anderen Forum:
bestehenden Quellcode in beiden Systemen weiterzuverwenden (sagte er etwas hilflos).
Mein nächstes Problem ist ähnlich:
'strcmp (..)' wird gefunden '_strcmp(..)' leider nicht!
Ok, du sagts, alles was mit '_' beginnt ist nicht in der <cstdlib> und damit unter Linux nicht vorhanden!? .. Schade. :(
EDIT:
Aus einen anderen Forum:
Randbemerkung: irgendwo in den Windows-Headern hat ein absolutes Rindvieh von Programmierer ein "#define max ..." stehen. Das beißt sich dann mit der C++-Standardbibliothek. Ein "#define NOMINMAX" vor dem "#include <windows.h>" ist unbedingt erforderlich.
Zuletzt geändert von HeinzK am 26.05.2010, 16:29, insgesamt 1-mal geändert.
Es ist leichter, einen Sack Flöhe zu hüten.
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Unbedingt! Aber pass auf, die Windows–Header definieren beide Symbole auch, was gerne zu mysterioesen Fehlern fuehrt … am besten NOMINMAX VOR #include <Windows.h> definieren.Ist '__max(..)' unter Linux nicht definiert?
Muss ich stattdessen 'max(..)' verwenden?
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Ok, das ging aneinander vorbei .. s.o. (EDIT) ..
Danke für den Hinweis.
Danke für den Hinweis.
Es ist leichter, einen Sack Flöhe zu hüten.
- Schrompf
- Moderator
- Beiträge: 5047
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Naja... sowohl __max als auch _strcmp sollten ja konfliktfrei von der Volltextsuche Deiner IDE gefunden werden können. Mach also einfach ein Suchen&Ersetzen auf's ganze Projekt und benutze in Zukunft halt die Standard-Funktionen anstatt der jeweils compiler-eigenen.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
OK, kein Problem .. aber ich bin verunsichert, weil ich die Unterschiede und auch die Gründe die
zu den unterschiedlichen Funktionen geführt haben nicht kenne.
zu den unterschiedlichen Funktionen geführt haben nicht kenne.
Es ist leichter, einen Sack Flöhe zu hüten.
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
strcmp() ist Teil der C-Standardbibliothek und damit (wie auch die C++-Standardbibliothek, also bspw ::std::string) standardisiert und steht dir überall zur Verfügung.
Alles, was im globalen Namespace liegt und mit einem Unterstrich beginnt, gehört zur C-Runtime. Darin fassen Compilerhersteller oft benötigte Funktionen zusammen, die von der Laufzeitumgebung des Programms abhängig sind. Die sind nicht standardisiert und damit nicht portabel.
Alles, was im globalen Namespace liegt und mit einem Unterstrich beginnt, gehört zur C-Runtime. Darin fassen Compilerhersteller oft benötigte Funktionen zusammen, die von der Laufzeitumgebung des Programms abhängig sind. Die sind nicht standardisiert und damit nicht portabel.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
OK, es gibt also keinen Ersatz für '_stricmp(..)' in der Standardbibliothek!
Es ist leichter, einen Sack Flöhe zu hüten.
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Hier stand Blubbshit
Zuletzt geändert von Krishty am 26.05.2010, 21:32, insgesamt 2-mal geändert.
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Unter Linux sollte strcasecmp den Zweck erfuellen. In der Standardbibliothek gibt es afaik nichts. Am einfachsten ist imho Selberbasteln :-)
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Das 'strcasecmp' schau ich mir noch an .. ansonsten bin ich schon am 'basteln', oder wie
meine kleine Tochter immer sagte: selbel machen ..
meine kleine Tochter immer sagte: selbel machen ..
Es ist leichter, einen Sack Flöhe zu hüten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Eine Verständnisfrage:
A1: int iAlt = k_sStr.find(cAlt, 0); //> OK:
A2: int iAlt = k_sStr.find(sAlt, 0); //> OK:
B1: k_sStr.replace(iAlt, iAltLg, cNeu); //> OK:
B2: k_sStr.replace(iAlt, iAltLg, sNeu); //> Falsch:
B3: k_sStr.replace(iAlt, iAltLg, sNeu.c_str()); //> Auch falsch:
Bin gerade am Testen .. wie's geht .. und wenn, wie am schnellsten.
Warum funktioniert A1 + A2 aber bei Bx nur B1?
Code: Alles auswählen
int CKString::Replace(const string &sAlt, const string &sNeu)
{
int iAlt = k_sStr.find(sAlt, 0);
int iAltLg = sAlt.length();
int iNeuLg = sNeu.length();
k_sStr.replace(iAlt, iAltLg, sNeu);
k_iStrLen = k_sStr.length();
return iNeuLg;
}
int CKString::Replace(char *cAlt, char *cNeu)
{
int iAlt = k_sStr.find(cAlt, 0);
int iAltLg = strlen(cAlt);
int iNeuLg = strlen(cNeu);
k_sStr.replace(iAlt, iAltLg, cNeu);
k_iStrLen = k_sStr.length();
return iNeuLg;
}
A2: int iAlt = k_sStr.find(sAlt, 0); //> OK:
B1: k_sStr.replace(iAlt, iAltLg, cNeu); //> OK:
B2: k_sStr.replace(iAlt, iAltLg, sNeu); //> Falsch:
B3: k_sStr.replace(iAlt, iAltLg, sNeu.c_str()); //> Auch falsch:
Bin gerade am Testen .. wie's geht .. und wenn, wie am schnellsten.
Warum funktioniert A1 + A2 aber bei Bx nur B1?
Es ist leichter, einen Sack Flöhe zu hüten.
-
- Establishment
- Beiträge: 191
- Registriert: 01.03.2009, 19:22
- Echter Name: David N.
Re: Auf dem Weg von DDraw nach OpenGL ..
Was genau heißt »funktioniert nicht«?
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
: error C2663: 'std::basic_string<_Elem,_Traits,_Ax>::replace': für 11 Überladung(en) gibt es keine zulässige Konvertierung für den this-Zeiger
Es ist leichter, einen Sack Flöhe zu hüten.
- HeinzK
- Establishment
- Beiträge: 234
- Registriert: 05.11.2009, 08:37
- Benutzertext: ZwiAner
- Echter Name: Heinz Kempter
- Wohnort: Wald
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Zum replace-Problem. Die eigentliche Ursache für meinen Versuch mit dem string-Parameter liegt darin,
dass ich unter Linux/Ubuntu/Code::Blocks folgende Meldung erhalte:
Unter VS erhalte ich diese Warnung nicht und es funktioniert auch einwandfrei (wie auch unter Ubuntu).
Kann ich an diesem Aufruf oder an der Declaration etwas verbessern?
dass ich unter Linux/Ubuntu/Code::Blocks folgende Meldung erhalte:
warning: deprecated conversion from string constant to ‘char*’
Code: Alles auswählen
CKString sKStr9("Test: Heinz Kempter");
sKStr9.Replace("Heinz", "Elfriede");
//Declaration:
int Replace(char *cAlt, char *cNeu);
Kann ich an diesem Aufruf oder an der Declaration etwas verbessern?
Es ist leichter, einen Sack Flöhe zu hüten.
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Auf dem Weg von DDraw nach OpenGL ..
Moment, hatten wir das nicht schon weiter vorne im Thread?
Aramis hat geschrieben: Das Problem ist, dass eine Zeichenkette (genauer, ein string-literal) zwar den Datentyp char* hat (bzw. zumindest in C hatte, der aktuelle C++ Sprachstandard definiert String-Literale als array of const char), aber dennoch nicht modifiziert werden darf, da der Compiler sie ueblicherweise in einer read-only Sektion ablegt. Vermutlich kompilierst du in einem der Projekte mit -wall – die Warnung ist gerechtfertigt.
Code: Alles auswählen
void fatalError(const char *message)
Heißt normalerweise: du rufst auf einem konstanten Objekt eine Memberfunktion auf, die selber nicht konstant ist.ür 11 Überladung(en) gibt es keine zulässige Konvertierung für den this-Zeiger