const Char* geht nicht
-
Streamer schrieb:
In C# z.B. ist das auch nicht anders.
Blödsinn. Ein System.Char ist praktisch nix andres als ein wchar_t. Alles Andere wäre doch auch Wahnsinn...
-
Dann nehm mal den .Net-Reflector zur Hand und schau dir an wie die Char bzw. String-Klasse implementiert wurde.
-
Streamer schrieb:
Also werden wir mal konkreter. In dem Code ist wirklich alles virtual was nur irgendwie virtual sein kann. Nicht nur das. Der Code ist auch noch komplett rekursiv. Weil alles mit (fast) jedem können muss. Ihr würdet wahrscheinlich folgendes raten:
Ganz bestimmt nicht - das ist allerdings das Desing, das wir bei deinem Desing beürchten. Kannst du eventuell mal als Gegenentwurf zeigen, wie du das Problem gelöst hast bzw. lösen willst?
-
Nicht dass wir uns falsch verstehen. Der einzige Member den meine String-Klasse hat ist ein Char* und gut es gibt ein paar virtuelle Funktionen und zwei Klassen von denen gerbt wird.
-
Und dein Char hat auch virtuelle Methoden? Abgesehen davon: Was soll ich mit dem ildasm deiner Meinung nach denn groß sehen!?
Was den andren Code angeht: Gehts da darum dass deine Library eine XML Datei einlesen soll in der auch Benutzerdefiniertes Zeug liegen kann? Und das Problem ist dass die Library diese Objekte Serialisieren/Deserialisieren soll?
-
Streamer schrieb:
Nicht dass wir uns falsch verstehen. Der einzige Member den meine String-Klasse hat ist ein Char* und gut es gibt ein paar virtuelle Funktionen und zwei Klassen von denen gerbt wird.
Und dein Char besteht wiederum aus einem wchar_t und "ein paar virtuellen Funktionen", richtig? Dir ist hoffentlich klar, daß für den Einsatz von virtuellen Methoden zustäzlicher Speicher benötigt wird (Stichwort: vtable/vptr) - und das hast du an jedem der Char's, die du verwaltest.
-
Bei mir ist jede Klasse in einer Factory registriert sodass ich zur Laufzeit ein Object davon instanziieren kann. So jetzt bin ich mal auf euer Design gespannt :).
-
Unser Design für was genau? Ich kenn mich langsam nichtmehr aus. Ursprünglich gings hier um wchar_t vs. the world und jetzt auf einmal machen wir irgendwas mit Factories und XML nachdem wir extrem kranke und impraktikable Möglichkeiten strings zu repräsentieren diskutiert haben
-
dot schrieb:
Und dein Char hat auch virtuelle Methoden? Abgesehen davon: Was soll ich mit dem ildasm deiner Meinung nach denn groß sehen!?
Naja, dass die String-Klasse zum Beispiel von diversen Interfaces und den Klassen Object sowie ValueType abgeleitet ist. Einige dieser Funktionen sind z.B. auch virtual. Du hast ja gemeint die Char-Klasse wäre nichts weiter als ein wchar_t. Wenn das also schlechter Stil ist, hat mich Microsoft verdorben ;).
dot schrieb:
Was den andren Code angeht: Gehts da darum dass deine Library eine XML Datei einlesen soll in der auch Benutzerdefiniertes Zeug liegen kann? Und das Problem ist dass die Library diese Objekte Serialisieren/Deserialisieren soll?
Richtig, geht in erster Linie darum.
CStoll schrieb:
Und dein Char besteht wiederum aus einem wchar_t und "ein paar virtuellen Funktionen", richtig? Dir ist hoffentlich klar, daß für den Einsatz von virtuellen Methoden zustäzlicher Speicher benötigt wird (Stichwort: vtable/vptr) - und das hast du an jedem der Char's, die du verwaltest.
Das ist mir bewusst, nicht bewusst ist mir allerdings wie stark das ins Gewicht fällt. Aber meine Anwendung belegt gerade mal ca. 10MB bei zig geladenen Resourcen. Bei heutigen Rechnern mit 32GB Ram ist das denke ich kein Grund mich leise schämend in die Ecke zu verkrichen.
-
dot schrieb:
Ursprünglich gings hier um wchar_t vs. the world und jetzt auf einmal machen wir irgendwas mit Factories und XML nachdem wir extrem kranke und impraktikable Möglichkeiten strings zu repräsentieren diskutiert haben
Gut mit der Char-Klasse habe ich einiges Missverstanden gehabt bzw. hat mich irritiert. Was jetzt allerdings an einer Wrapper-Klasse um einen Char* krank sein soll erschließt sich mir nicht. Wie ist denn ein std::wstring implementiert?
-
Streamer schrieb:
Naja, dass die String-Klasse zum Beispiel von diversen Interfaces und den Klassen Object sowie ValueType abgeleitet ist. Einige dieser Funktionen sind z.B. auch virtual.
Und?
Streamer schrieb:
Du hast ja gemeint die Char-Klasse wäre nichts weiter als ein wchar_t. Wenn das also schlechter Stil ist, hat mich Microsoft verdorben ;).
Die Char Klasse ist grundsätzlich etwas mehr ja. Aber nachdem der JIT drübergelaufen ist sicher nichtmehr
Streamer schrieb:
Richtig, geht in erster Linie darum.
Naja, der User gibt dir ja offenbar schon eine Factory. Dann gib der eben einfach eine Methode Deserialize() die dir aus einem XML Subtree ein Objekt baut!?
Streamer schrieb:
Das ist mir bewusst, nicht bewusst ist mir allerdings wie stark das ins Gewicht fällt. Aber meine Anwendung belegt gerade mal ca. 10MB bei zig geladenen Resourcen. Bei heutigen Rechnern mit 32GB Ram ist das denke ich kein Grund mich leise schämend in die Ecke zu verkrichen.
Es fällt soweit ins Gewicht dass dein Char nichtmehr 2 sondern 8 Byte belegen wird. Abgesehen davon kann der Compiler nichtmehr wirklich inlinen, d.h. sämtliche Operationen mit deinem Char werden wirklich zu Funktionsaufrufen mit dem damit verbundenen Overhead. Und virtuelle Funktionen sind natürlich auch nicht gratis. Bei fetten Objekten macht das keinen Unterschied. Aber bei einem dämlichen Char sehr wahrscheinlich schon.
-
Streamer schrieb:
Gut mit der Char-Klasse habe ich einiges Missverstanden gehabt bzw. hat mich irritiert. Was jetzt allerdings an einer Wrapper-Klasse um einen Char* krank sein soll erschließt sich mir nicht. Wie ist denn ein std::wstring implementiert?
Ok, das ist schon was andres. std::wstring ist ein einfaches
typedef basic_string<wchar_t> wstring;Das Ding hat keine virtuellen Funktionen etc. und kompiliert im Ideafall daher auf einen einfach wchar_t Pointer runter, so als hättest du alles handgecodet...
-
Streamer schrieb:
Wie ist denn ein std::wstring implementiert?
Die übliche Variante dürfte aus einem Pointer auf ein wchar_t-Array und einigen size_t's zur Verwaltung der Größe bestehen. Aber wenn du es genau wissen willst, kannst du es dir gerne selber ansehen - wstring (alias
basic_string<wchar_t,char_traits<wchar_t>,allocator<wchar_t>>) ist ein Template und dürfte weitgehend in Reinform in der <string> stehen.
-
dot schrieb:
Die Char Klasse ist grundsätzlich etwas mehr ja. Aber nachdem der JIT drübergelaufen ist sicher nichtmehr
Gut, dass mit dem JIT wusste ich nicht.
Dann muss ich mir sobald ich wieder eine compilierfähige Version habe unbedingt mal anschauen wie groß meine Char und String Klassen nun tatsächlich sind. Ob die Char-Klasse nun 2 oder 8 Byte groß ist, ist nicht so tragisch. Eine spürbar geringere Ausführungsgeschwindigkeit wäre da schon schlimmer. Die Klassen sollen ja auch nur in direktem Zusammenhang mit meiner Library verwendet werden und nicht generell. Werde mir das Wochenende aber mal Gedanken machen wie und ob ich an der Programmstruktur was ändern kann.
-
D.h. deine Library zwingt den Benutzer all seine strings in deine komischen strings zu konvertieren nur weil du meinst nicht die Bordmittel benutzen zu wollen? Ich liebe solche Libraries...
