ZFX + Developia

Verfasst: **19.05.2010, 14:28**

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.

Verfasst: **19.05.2010, 14:40**

Ok, hab's jetzt verstanden.
sMode.Compare(sFname) funktioniert jetzt schon .. werde es sofort ausprobieren. Danke.

Verfasst: **19.05.2010, 14:54**

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.

Verfasst: **19.05.2010, 15:00**

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.

Verfasst: **19.05.2010, 15:11**

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.

Verfasst: **19.05.2010, 15:32**

Was meinst du für „Möglichkeiten“?

Verfasst: **19.05.2010, 15:35**

Ich kenn' aus Beispielen nur toupper und tolower .. will nur wissen, was da noch alles 'möglich' (to transform) ist.

Verfasst: **19.05.2010, 15:45**

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.

Verfasst: **19.05.2010, 15:50**

Ok, ist angekommen.

Verfasst: **22.05.2010, 08:32**

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.

Verfasst: **22.05.2010, 09:29**

'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'.

Verfasst: **25.05.2010, 08:30**

Problem in VisualStudio 9.0, berifft aber nur eine Projektmappe:
Bild

Nach dem Wechsel von Debug auf Release bleibt _DEBUG definiert.
Bild

Wenn ich im Release-Modus die Maus auf _DEBUG lege:
Bild

Ich habe nirgends ein #define _DEBUG in meinem Quellquode!
Was ist da los? Kann mir dabei jemand helfen?

Verfasst: **25.05.2010, 09:08**

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.

Verfasst: **26.05.2010, 15:56**

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.

Verfasst: **26.05.2010, 16:09**

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.

Verfasst: **26.05.2010, 16:20**

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:

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.

Verfasst: **26.05.2010, 16:29**

Ist '__max(..)' unter Linux nicht definiert?
Muss ich stattdessen 'max(..)' verwenden?

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.

Verfasst: **26.05.2010, 16:31**

Ok, das ging aneinander vorbei .. s.o. (EDIT) ..
Danke für den Hinweis.

Verfasst: **26.05.2010, 16:34**

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.

Verfasst: **26.05.2010, 16:49**

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.

Verfasst: **26.05.2010, 17:18**

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.

Verfasst: **26.05.2010, 21:24**

OK, es gibt also keinen Ersatz für '_stricmp(..)' in der Standardbibliothek!

Verfasst: **26.05.2010, 21:30**

Hier stand Blubbshit

Verfasst: **26.05.2010, 21:31**

Unter Linux sollte strcasecmp den Zweck erfuellen. In der Standardbibliothek gibt es afaik nichts. Am einfachsten ist imho Selberbasteln :-)

Verfasst: **26.05.2010, 21:36**

Das 'strcasecmp' schau ich mir noch an .. ansonsten bin ich schon am 'basteln', oder wie
meine kleine Tochter immer sagte: selbel machen ..

Verfasst: **27.05.2010, 19:25**

Eine Verständnisfrage:

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;
}

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?

Verfasst: **27.05.2010, 20:04**

Was genau heißt »funktioniert nicht«?

Verfasst: **27.05.2010, 20:15**

: 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

Verfasst: **28.05.2010, 09:00**

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:

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);

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?

Verfasst: **28.05.2010, 09:12**

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)

ür 11 Überladung(en) gibt es keine zulässige Konvertierung für den this-Zeiger

Heißt normalerweise: du rufst auf einem konstanten Objekt eine Memberfunktion auf, die selber nicht konstant ist.

ZFX + Developia

Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Re: Auf dem Weg von DDraw nach OpenGL ..