Ja, war irgendwie klar, dass jetzt eine "die stdlib ist Bestandteil von C++"-Diskussion kommt -- entschuldigung, die wollte ich nicht auslösen ;) So oder so, meiner Meinung nach ist std::string eh kein "String" im eigentlichen Sinne, sondern eher ein bequemes char-Array. std::string hat zum Beispiel kein Konzept von (darstellbaren) Zeichen, was ich für einen String aber unerlässlich finde.
Sven B. schrieb: > std::string hat zum Beispiel kein Konzept von (darstellbaren) Zeichen, > was ich für einen String aber unerlässlich finde. Was meinst du mit einem "Konzept von (darstellbaren) Zeichen"?
Naja, std::string hat keine Encodings oder ähnliches. Es speichert einfach nur eine Liste von Bytes. Wenn da Unicode-Zeichen drin sind, ist std::string das egal. Frage ich zum Beispiel nach der Länge eines Strings, kriege ich die Anzahl der Bytes -- nicht die Anzahl der Zeichen. Ich kann auch nicht ohne Probleme einen Unicode-Charakter durch einen anderen ersetzen etc. weil std::string keine Ahnung hat, wo ein Zeichen überhaupt anfängt. Ein "ä" zählt std::string zum Beispiel immer zweifach -- eine "echte String-Klasse", wie QString, tut das nicht.
@Sven B.: M.W. sind die Elemente von C#-Strings (Chars) 16 Bit breit und speichern Zeichen als UTF-16. Für alle Zeichen mit einem Code <0x10000 arbeitet die Length-Funktion wie erwartet. Unicodezeichen, die nicht in 16 Bit darstellbar sind (also mit einem Zeichencode >=0x10000), werden in UTF-16 als zwei 16-Bit-Werte codiert. Diese werden von der Length-Methode fälschlicherweise als zwei Zeichen gezählt. Der C#-String entspricht diesbezüglich also dem std::wstring in C++.
Dann ist das Verhalten der C++ stdlib und C# in diesem Fall meiner Meinung nach gleichermaßen ungeschickt. Das heißt, eigentlich nicht ungeschickt, sondern zum Speichern von Text ungeeignet -- es gibt ja durchaus Anwendungen, in denen dieses Verhalten gewünscht ist. Sowohl in Python als auch in Qt gibt es -- ich finde, richtigerweise -- eine klare Unterscheidung zwischen "String" und "Byte Array" (QString + QByteArray in Qt und str + bytes in Python). Das Byte Array ist jeweils dazu da, ein Array von gleich großen Werten zu speichern (sei es 8 oder 16 bit, das ist ja relativ egal). Das ist das, was std::str oder std::wstr und anscheined auch der C# string machen. Diese Art von Datentyp finde ich aber für Text, den ja schlussendlich der Benutzer lesen soll, ungeeignet; es gibt kein verlässliches replace, kein verlässliches length, und überhaupt keine Information darüber, wie der Inhalt des Ganzen denn interpretiert werden soll (Ascii? Unicode? Welches Unicode?). Ein "echter" String sollte, finde ich, wissen, wie sein Inhalt zu interpretieren ist, und dies auch in der API berücksichtigen. Grüße, Sven (Python und Qt nenne ich deshalb, weil das die beiden Plattformen sind, die ich am besten kenne)
Freizeit_Programmierer schrieb: > Nur wenn ich das hier lese, frage ich mich ob es für mich Sinn macht > eine neu Sprache mit all den Besonderheiten zu lernen oder z.B. auf > PureBasic zu wechseln. Warum ist das ein Problem ? Die "Spezialitäten" der Sprachen sind eigentlich nicht so extrem aufwendig zu lernen, insbesondere wenn man weiss was man sucht und wo man im Notfall nachgucken kann. Die "bösen" Details sind oft eher Compiler-, statt Sprachabhängig, insbesondere wenn der zugrundeliegende Standard da nicht 100% wasserdicht ist. Übler ist es, wenn man das grundlegende Sprachkonzept wechselt. Also z.B. von C/Pascal (imperativ, mehr oder weniger) <--> c++/Java/C# (Objektorientiert) <--> Prolog (Rule based, backward chaining) <--> Lisp/ML/Haskell (functional). Dann steht man oft vor dem Problem, dass man in der "neuen Welt" immer noch versucht, mit den Methoden der "alten Welt" zu arbeiten und das führt meist zu erstaunlich furchtbarem Code. Von daher stellt sich (für mich) eher die Frae, ob ich mir jedes Sprachkonzept mal so intensiv vornehme, dass ich wirklich auch in diesem Konzept "modelliere". Und das dauert^^. Es lohnt sich aber mMn sehr. Grüße Andreas
@Yalu Weil ich glaube ich mal einen C++ Freak bräuchte, der ein wenig Zeit für mich hat...
Ben _ schrieb: > Weil ich glaube ich mal einen C++ Freak bräuchte, der ein wenig Zeit für > mich hat... Dass ich kein C++-Freak bin, heißt natürlich nicht, dass ich nicht versuchen würde, anderen bei C++-Problemen zu helfen. Es gibt hier im Forum aber ein paar Leute, die da viel tiefer drinstecken. Wenn du also Fragen hast, poste sie einfach, und irgendjemand wird sicher eine Lösung finden.
Sven B. schrieb: > Sowohl in Python als auch in Qt gibt es -- ich finde, richtigerweise -- > eine klare Unterscheidung zwischen "String" und "Byte Array" (QString + > QByteArray in Qt und str + bytes in Python). Das Byte Array ist jeweils > dazu da, ein Array von gleich großen Werten zu speichern (sei es 8 oder > 16 bit, das ist ja relativ egal). Das ist das, was std::str oder > std::wstr und anscheined auch der C# string machen. Das ist so auch sinnvoll. Hätten die Zeichen variable Länge (wie in UTF-8 und UTF-16), wäre der Zugriff auf das n-te Zeichen eines Strings äußerst ineffizient. Deswegen legt man die Zeichengöße auf einen festen Wert von 8, 16 oder 32 Bit fest. Die 8- und 16-Bit-Darstellungen sind ein Kompromiss zwischen der Anzahl darstellbarer Unicode-Zeichen und dem Speicherplatzverbrauch. In C++ stehen beide Alternativen zur Verfügung, in C# die 16-Bit-Variante. Mit 32 Bit können sämtliche Unicode-Zeichen dargestellt werden. So machen es bspw. Python und Haskell¹, wo die len-Funktion auch bei chinesischen Zeichen korrekte Ergebnisse liefert. Die rohe 32-Bit- Unicode-Darstellung ist – bis auf den erhöhten Speicherbedarf — die ideale Darstellung für Texte mit beliebigen internationalen Zeichen. –––––––––––– ¹) In Haskell gibt es zusätzlich noch den effizienteren Datentyp Text, der Strings wie C++ und C# als 16-Bit-Array speichert.
Das mit den 16 bits und dem Indizieren des Strings ist schon richtig. Trotzdem: QString und der Python str "sprechen" unicode, std::wstr nicht. Zum Beispiel erkennen sie ungültige Unicode-Sequenzen, und können nicht-ASCII-Zeichen korrekt in Großbuchstaben verwandeln (ä -> Ä). Das kann (und will) wstr meines Wissens nicht -- das ist einfach nur ein Array von std::wchar_t.
Sven B. schrieb: > Naja, std::string hat keine Encodings oder ähnliches. Es speichert > einfach nur eine Liste von Bytes. Wenn da Unicode-Zeichen drin sind, ist > std::string das egal. Frage ich zum Beispiel nach der Länge eines > Strings, kriege ich die Anzahl der Bytes -- nicht die Anzahl der > Zeichen. Ich kann auch nicht ohne Probleme einen Unicode-Charakter durch > einen anderen ersetzen etc. weil std::string keine Ahnung hat, wo ein > Zeichen überhaupt anfängt. Ein "ä" zählt std::string zum Beispiel immer > zweifach -- eine "echte String-Klasse", wie QString, tut das nicht. QString zählt auch so http://stackoverflow.com/questions/8011235/finding-actual-characters-graphemes-in-a-qstring In .NET wäre es die StringInfo-Klasse und/oder TextElementEnumerator Bei Python hängt's vom Build ab... http://docs.python.org/2/c-api/unicode.html Auch UTF32 ist nicht viel besser, da auch dort einzelne Zeichen zur Darstellung aus Kombinationen zusammengebaut werden können...
Sven B. schrieb: > Das mit den 16 bits und dem Indizieren des Strings ist schon richtig. > Trotzdem: QString und der Python str "sprechen" unicode, std::wstr > nicht. Zum Beispiel erkennen sie ungültige Unicode-Sequenzen, Das müsste bei der Konvertierung von UTF-8 (oder was auch immer) ins interne 16-Bit-Format passieren, hab's jetzt aber nicht ausprobiert. > und können nicht-ASCII-Zeichen korrekt in Großbuchstaben verwandeln (ä > -> Ä). Doch, std::toupper() tut das für einzelne Zeichen, das habe ich gerade ausprobiert. Ein toupper für ganze Strings gibt es m.W. nicht, die Umwandlung von Klein- in Großschrift kann aber mit std::transform(..., toupper) gemacht werden.
Ja, stimmt, QString zählt auch so -- fällt nur i.d.R. nicht auf, weil's ein 16bit string ist. Und std::toupper kann tatsächlich unicode? Na, dann will ich mal nichts gesagt habe. ;)
die einzigen richtigen strings gibts sowieso nur in delphi ;-) (samt refcount usw. )
So, was mich jetzt nochmal ganz konkret interessieren würde: Welche möglichst kostenfreie Entwicklungsumgebung für C++ nutzt ihr? Wie schaut eure Toolchain aus, gibts gute Debugger? Edit: Als Beispiel, es gibt ja heute viele Spieleklassiker, deren Quellcode offenliegt (Doom, Quake wenn ich mich nicht irre, oder die virtuelle Eisenbahnplatte OpenTTD...). Was braucht man alles um sowas zu modifizieren bzw. danach neu zu compilieren?
Da fragt man das betreffende Projekt, was da üblich ist, das wird sich je nach dem unterscheiden. Die meisten Projekte haben ein "How to Compile" auf ihrer Webseite, oder sogar in der INSTALL-Datei im Projektverzeichnis. Ich benutze KDevleop (IDE), g++ (Compiler), gdb (Debugger), valgrind (das "ich habe keine Ahnung mehr, finde mal den Fehler"-Tool), und CMake/ninja/make (zum Bauen).
Ben _ schrieb: > So, was mich jetzt nochmal ganz konkret interessieren würde: > > Welche möglichst kostenfreie Entwicklungsumgebung für C++ nutzt ihr? > > Wie schaut eure Toolchain aus, gibts gute Debugger? > > Edit: > Als Beispiel, es gibt ja heute viele Spieleklassiker, deren Quellcode > offenliegt (Doom, Quake wenn ich mich nicht irre, oder die virtuelle > Eisenbahnplatte OpenTTD...). Was braucht man alles um sowas zu > modifizieren bzw. danach neu zu compilieren? Zu allererst einmal muss man eine Suchmaschine bedienen können. Damit haben erstaunlich viele Leute Schwierigkeiten. Ich habe auf der Arbeit eine Kollegin, die hat ein Informatik-Diplom und tut sich schwer damit. Sei's drum: Google-Suche nach: how to compile doom --> http://doomlegacy.sourceforge.net/docs/source.html http://geekchef.com/running-doom-under-linux/ http://doom.wikia.com/wiki/How_to_download_and_run_Doom etc. Google-Suche nach: free C++ IDE --> http://www.codeblocks.org/ http://www.c-plusplus.de/forum/263174-full http://www.wtfdiary.com/2012/08/8-best-and-free-ide-for-c-and-c.html etc.
Ich wollte nicht wissen was es gibt (das hätte mir eine Suchmaschine evtl. noch verraten), sondern ich wollte wissen was die hier Anwesenden so benutzen, was gut ist (das weiß die Suchmaschine nicht). Weil die werd ich auch fragen/nerven wenn ich mal nicht weiter weiß. Also vielen Dank für Deine Links, aber beim nächsten Mal doch bitte etwas überlegen bevor Du mir irgendwelchen Mist vorwirfst. Nochmal Danke.
Die Suchmaschine kann auch Postings von Nutzern finden, die das Tool XYZ verwenden. Oder manchmal hat Tool XYZ auch ein eigenes Forum.
Ja, deswegen heißt das ja Suchmaschine. Weil man dann hinterher selbst noch in den drei Millarden vermeintlichen Ergebnissen suchen darf ob irgendwo ein Glückstreffer dabei war. Nee, was mir am liebsten wäre wenn mir irgendein Freak, den ich hinterher auch um Rat fragen kann wenn ich beim Ausprobieren Probleme bekomme, sagt was er so verwendet.
Yalu X. schrieb: >> und können nicht-ASCII-Zeichen korrekt in Großbuchstaben verwandeln (ä >> -> Ä). > > Doch, std::toupper() tut das für einzelne Zeichen, das habe ich gerade > ausprobiert. Ein toupper für ganze Strings gibt es m.W. nicht, die > Umwandlung von Klein- in Großschrift kann aber mit std::transform(..., > toupper) gemacht werden. ... was bei einem Wort wie "Straße" aber nicht sonderlich gut funktionieren wird.
Rolf Magnus schrieb: > ... was bei einem Wort wie "Straße" aber nicht sonderlich gut > funktionieren wird. Ja, das stimmt. Das 'ß' ist aber auch ein ziemlich kranker Buchstabe :) Da braucht's dann in C++ wohl to_upper() aus der Boost-Locale-Bibliothek (wenn man die Funktion nicht selber schreiben will): http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/conversions.html Python 3 (str.upper()) behandelt das 'ß' schon out-of-the-box richtig. In Haskell geht es mit toUpper aus dem Paket Data.Text oder (locale- spezifisch) Data.Text.ICU. Für C# habe ich auf die Schnelle nichts gefunden. String.ToUpper() und String.ToUpper(new CultureInfo("de-DE")) wandeln das 'ß' jedenfalls nicht in Großschrift um.
>Nicht falsch verstehen: ich halte die IL-Zwischenschicht nicht für schlecht. >Die daraus resultierenden Vorteile wiegen den geringen, wenn überhauptvhandenen >Geschwindigkeitsvebei weitem auf . ........ >....deren Quellcode offen liegt Bei IL-Zwischensprache, bsp .Net, oder bei Java, liegt faktisch jede Anwendung im Quellcode (!!) vor. Ob das den meisten Programmieren bewusst ist?
Wie wäre es mit eclipse ? Wundert mich, dass der Vorschlag noch nicht kam, was spricht dagegen ?
interrupt schrieb: > Wie wäre es mit eclipse ? > Wundert mich, dass der Vorschlag noch nicht kam, was spricht dagegen ? das eclipse keine Programmiersprache ist.
Für entspanntes Programmieren unter Windows ist ganz klar C# zu empfehlen.
Peter II schrieb: > interrupt schrieb: >> Wie wäre es mit eclipse ? >> Wundert mich, dass der Vorschlag noch nicht kam, was spricht dagegen ? > > das eclipse keine Programmiersprache ist. Qt ist auch keine Programmiersprache. Mit der Entwicklungsumgebung eclipse kann man z.B. mit C, C++ und java programmieren. Was spricht also gegen eclipse ?
Genausogut könntest du auch eine Kartoffel vorschlagen ._. Im Ernst, es ging doch um eine Sprache, und auch wenn Qt natürlich keine Sprache ist, qualifiziert sich der Vorschlag "C++ mit Qt" doch in der Praxis recht gut als solche. Eclipse hingegen ist nur ein Editor.
Wenn du eclipse sagst schlage ich Visual Studio vor. So stelle ich mir die entwicklung von grafischen oberflächen vor.
Visual Studio ist aber eine Gruppe von Sprachen inkl. Entwicklungsplattform.
Eclipse ist auch eine Entwicklungsplattform und beherrscht eine Gruppe von Sprachen :P
Wenn ihr schon diese sinnlose Diskussion führt, dann doch wenigstens mit den richtigen Begriffen ;) Eclipse unterstützt eine Menge von Sprachen, und VS kann einige Sprachen übersetzen. Das sind erstmal zwei völlig unterschiedliche Dinge. Keins von beidem hat allerdings etwas damit zu tun, eine Sprache zu "sein", weil die Sprache "ist" nämlich die Spezifikation und nicht die Implementierung, und schon gar nicht die IDE.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.