[Strings] Welche benutzt ihr?
-
mal fix aus der bcb hilfe:
A wchar_t type is the same size, signedness, and alignment requirement as an int type.
damit ist ein wchar_t so groß wie 32 normale chars
@Artchi
char* text=new char[6];
*text="Hallo";
ist langsamer als
char[6]=Hallo;
deshalb benutz ich gerne char arrays für Kleinigkeiten.und performance ändert wohl was an den fakten!
-
otze schrieb:
string is für char
wstring für wchar_tDas ist mir klar. Ich formuliere meine Frage um: wieso verwenden hier (scheinbar) alle ANSI-Strings, wenn sie stattdessen Unicode-Strings verwenden könnten? Man beachte: Unicode ist ein neuerer und weitaus umfassenderer Standard.
(Kommt natürlich auf den genauen Einsatz an, aber in den meisten (= eigentlich allen) Gebieten sollte man Unicode verwenden.)
EDIT:
Sorry, Doppelposting. Bitte löschen.
-
otze schrieb:
mal fix aus der bcb hilfe:
A wchar_t type is the same size, signedness, and alignment requirement as an int type.
damit ist ein wchar_t so groß wie 32 normale chars
Hmm, also ich komme auf viermal: ein char ist 8 Bit, nicht ein Bit! Außerdem sollte es bei modernen PCs kein Problem mehr sein, viermal größere Strings zu bearbeiten. Ob man nun mit 8 Bit oder mit 32 Bit rechnet, ist einem 32-Bit-Prozessor sowieso egal (er paddet die 8 Bit auf 32 hoch). D.h. die Geschwindigkeit sollte die gleiche sein, nur der Speicherbedarf (im RAM!) ist höher.
-
Naja, weil Unicode leider nicht so gut unterstützt wird, wie man meinen sollte.
Wir benutzen in unseren Projekten (im VW-Konzern) nur auf Anforderung Unicode in den Java-Applikationen. Bis vor gut 12 Monaten war es unmöglich Unicode auf einer IBM DB2-Datenbank auf einem IBM-Mainframe OS/390 (ja, kein popliger Intel-Server!) abzulegen. Es kam am Ende nur Datenschrott bei raus. Selbst das Euro-Zeichen macht uns heute noch sorgen, wenn wir diese in der DB2 speichern wollen. Und das, obwohl so ein Mainframe ein paar Mio. Euro kostet, funktionierte nicht mal das bis vor gut einem Jahr.
Man kann/muß nicht immer allem neuen hinterher laufen.
Und das Unicode-Problem ist uns auf dem Mainframe nur aufgefallen, weil die Applikation auch bei VW-China eingesetzt werden sollte. Bisher haben wir nur ANSI-Code benutzt, was ausreichend war.
-
Konrad Rudolph schrieb:
otze schrieb:
mal fix aus der bcb hilfe:
A wchar_t type is the same size, signedness, and alignment requirement as an int type.
damit ist ein wchar_t so groß wie 32 normale chars
Hmm, also ich komme auf viermal: ein char ist 8 Bit, nicht ein Bit! Außerdem sollte es bei modernen PCs kein Problem mehr sein, viermal größere Strings zu bearbeiten. Ob man nun mit 8 Bit oder mit 32 Bit rechnet, ist einem 32-Bit-Prozessor sowieso egal (er paddet die 8 Bit auf 32 hoch). D.h. die Geschwindigkeit sollte die gleiche sein, nur der Speicherbedarf (im RAM!) ist höher.
ja bei der größe muss ich dir zustimmen, mein fehler, hab bit/Byte vertauscht^^
aber ramspeicher ist immer sehr rar,vorallem bei größeren Programmen, da man sogar heute noch keine 512mb ram in nem pc als standard bezeichnen kann,macht sich der doch viel höhere speicherbedarf bei Unicode sehr stark bemerkbar.
-
Unsinn, das macht sich kein Stück bemerkbar. Zur Info, der am häufigsten verwendete Unicode-Standard braucht 2Byte pro Zeichen und umfasst alle europäischen und die meisten (wichtigsten) asiatischen Sprachen.
Wenn du ein Bitmap in Bildschirmgröße malst, kannst du damit genauso viel Speicher verbraten wie mindestens 1000 Zeichen Text. Ist doch ein völliger Unsinn, an der falschen Stelle rumzugeizen.
Ein paar Textdaten sind i.d.R. nicht das, was den ganzen RAM zusammenfrisst, sondern eher ein paar 100MB an Leveldaten und Texturen in Far Cry.
-
Optimizer schrieb:
Unsinn, das macht sich kein Stück bemerkbar. Zur Info, der am häufigsten verwendete Unicode-Standard braucht 2Byte pro Zeichen und umfasst alle europäischen und die meisten (wichtigsten) asiatischen Sprachen.
Ich nehme mal an Du sprichst von MS's Pseudo-UTF-16 (wird in vielen WinAPIs verwendet, sowie in VBC und .NET)? Tja, das ist leider etwas proprietäres von MS und daher ganz schlecht, wenn man plattformübergreifend programmieren möchte ... Aber nun ja, zur Not macht man sich das selber.
-
Optimizer schrieb:
Unsinn, das macht sich kein Stück bemerkbar. Zur Info, der am häufigsten verwendete Unicode-Standard braucht 2Byte pro Zeichen und umfasst alle europäischen und die meisten (wichtigsten) asiatischen Sprachen.
Wenn du ein Bitmap in Bildschirmgröße malst, kannst du damit genauso viel Speicher verbraten wie mindestens 1000 Zeichen Text. Ist doch ein völliger Unsinn, an der falschen Stelle rumzugeizen.
Ein paar Textdaten sind i.d.R. nicht das, was den ganzen RAM zusammenfrisst, sondern eher ein paar 100MB an Leveldaten und Texturen in Far Cry.wir reden hier von wchar_t das sind 4 byte,also nur 500 zeichen,und nehmen wir ein komplettes Buch im Unicode format haben wir sofort verschissen
-
sizeof(wchar_t) ist bei mir 2. Das ist natürlich Implementierungsabhängig, aber wie gesagt, UCS-2 ist der geläufigste Standard.
-
otze schrieb:
string benutzt new, das nur mal so am rande erwähnt
nö, string nutzt einen Allocator, der muss nicht new verwenden oder gar den Heap
zu dem was du zu Unicode sagst, kann ich nur sagen, dass du absoluten blödsinn erzählst. Bei heutigen PCs kommt es nicht auf 1MB mehr oder weniger an. Schau dir mal eine Anwendung an, die viel RAM verbraucht. Dafür geht so gut wie nichts für Text drauf. Auch wenn du ein oder mehrere Buch komplett in Unicode hast, ist das kein Problem.
Konrad Rudolph schrieb:
Ich nehme mal an Du sprichst von MS's Pseudo-UTF-16 (wird in vielen WinAPIs verwendet, sowie in VBC und .NET)? Tja, das ist leider etwas proprietäres von MS und daher ganz schlecht, wenn man plattformübergreifend programmieren möchte ... Aber nun ja, zur Not macht man sich das selber.
nein, dass ist nichts proprietäres, sondern einfach UCS-2. Ist zwar mittlerweile veraltet, deswegen gibt es UTF-16 um veraltete Architekturen (wie zB. Windows XP) mit dem kompletten Unicode Zeichensatz bedienen zu können.
@Optimizer
warum der geläufigste Standard?@Artchi
UTF-8
-
@Optimizer
warum der geläufigste Standard?Ok, war vielleicht vorschnell geurteilt.
Auf jeden Fall implementieren alle mir bekannten C++ Implementierungen (ok, sind nicht so viele ), Java und C# diesen Standard. Deshalb bin ich jetzt einfach mal davon ausgegangen. Wir reden ja auch nur über Programmiersprachen, oder?
-
kingruedi schrieb:
otze schrieb:
string benutzt new, das nur mal so am rande erwähnt
nö, string nutzt einen Allocator, der muss nicht new verwenden oder gar den Heap
hab mich ma fix schlau gemacht:
The Standard C++ Library provides a default allocator class, allocator, that implements this interface using the standard new and delete operators for all storage management.damit is klar, dass der heap benutzt wird,da new aufm heap speicher reserviert
-.-
-
otze schrieb:
char* text=new char[6];
*text="Hallo";Das hier soll langsamer sein?
Das kompiliert nicht einmal.MfG Eisflamme
-
@otze
aber du kannst den allocator beliebig ändern und anpassen. Deswegen ist eine generelle Aussage, dass string mit new arbeitet falsch.(btw. new allokiert auf dem FreeStore nicht auf dem Heap
)@Optimizer
also der GCC nutzt UCS-4 soweit ich weiss
-
dann erklär mir mal den Unterschied zwischen FreeStore und heap. Ich hab in der bcb hilfe nach mehreren minuten suche(FreeStore kennt der nicht, ka wieso^^) unter heap nämlich "free storage(heap)" gefunden,so wies aussieht scheints ein und dasselbe zu sein.
und zum thema string: string benutzt den standard allocator,was man an folgenden code zeilen sehen kann:
[cpp]
template <class charT,class traits = char_traits<charT>,class Allocator = allocator<charT> >
class basic_string;
[/cpp]
man könnte ja jetzt denken, dass in string ein anderer allocator benutzt werden könnte, aber:typedef basic_string <char> string;demnach benutzt string new, und für den Fall,dass FreeStore und heap ein und dasselbe sind,benutzt es auch den heap.
-
Hallo,
free store ist für new und delete, der heap für malloc und free.
-
ihr vergesst die short-string-optimization...
std::string ist bzw. kann mehr sein als ein simples char-array. Leider ist dies nur selten der Fall. Aber STLPort hat zB eine _sehr_ schnelle string Klasse, während der VC++6 eine _sehr_ langsame (wegen COW) hat.
-
Hi,
jetzt hab ich da doch mal ein paar Fragen was ist der Unterschied zwischen der STL und STLPort?
Welche Compiler benuzen was? ( MinGW/GCC, VC, BCC)?
Welche Variante ist hat die schnellste Implementation?
Ich dachte immer STL == STLPort aber da hab ich mich wohl getäuscht.
MfG
-
eViLiSSiMo schrieb:
jetzt hab ich da doch mal ein paar Fragen was ist der Unterschied zwischen der STL und STLPort?
STLPort ist eine STL Implementierung (www.stlport.org)
Wobei STL eigentlich nicht der richtige Name ist - denn in wirklichkeit heisst es ja "C++ Standard Library", aber STL hat sich eingebürgert.
Welche Compiler benuzen was? ( MinGW/GCC, VC, BCC)?
gcc verwendet die libstdc++, eine freie STL implementierung
vc++ verwendet die dinkumware STL (eine kommerzielle Implementierung), VC++6 verwendet eine sehr alte Version, da ist diese Library recht mies. Neuere Versionen sind da wesentlich besser.
bcb verwendet seit version 6 STLPort, dafür RogueWave (eine komererzielle Implementierung). mit dem freien bcc habe ich damit eigentlich nur probleme gehabt.Welche Variante ist hat die schnellste Implementation?
STLPort ist _sehr_ gut, aber angeblich sollen die neuen Dinkumware Libraries auch gut sein. RoqueWave ist eigentlich mist (kenne aber keine neue Version davon).
-
CarstenJ schrieb:
Hallo,
free store ist für new und delete, der heap für malloc und free.
und wo ist der unterschied?
ich hab weder in der bcb hilfe, noch in meinen Lektüren, noch in der msdn nützliche einträge dazu gefunden,und bei google hab ich dazu auch keine erklärung erhalten können.