Typlose Zeiger in C++
-
~john schrieb:
...sabber...
Es gibt noch andere Dinge als Unix und Windows. DSPs z.B., oder Mikrocontroller. Oder die gute alten VAX und deren Nachfolger. Irgendwie habe ich da so meine Probleme die der Portabilität, wenn ich Unix-Libraries benutze. Keine Ahnung, woher das kommt.
Und Mist baut man nicht, wenn man von einer spezifischen Anordnung der Daten ausgeht (dann ist man sich nämlich der Probelematik bewusst), sondern wenn man sie außer Acht lässt.
-
Ich kann dier ja mal meine Projektseite geben, dannn muss ich hier nicht so viel erklären und du hast vielleicht auch eine bessere Vorstellung der Problematik. Also es geht um die Datenbanken und es sind ca.50 unterschiedliche Typen nötig um diese Datensätze zu verarbeiten (geschätzt), die Datenbankenstructur wurde gerade komplet überarbeitet - also die veröffentlichte Struktur (Download .pdf) ist veralted! Aber das Prinzip ist ziemlich gleich geblieben.
Wie du siehst können keine vorgefertigten Datenbanken eingesetzt werden. Ich muss diese Datenbankklasse von Grund auf selbst schreiben!
Wie kann ich das mit viod* noch genauer erkären ... O.K. 3. Anlauf
void PartBase::read( void *unterschiedlich_lange_typen , int laenge ) { Einlesen von laenge Bytes, bei Bedarf mehrmals(- warscheinlich eher nicht) auf die Basisadresse *unterschiedlich_lange_typen. }Jetzt müsste doch klar sein um awas es geht?
Funktioniert das? Nach meiner Rechersche - Ja.
Ich will halt nicht Tausende Zeilen schreiben und dann beim Probelauf auf eine Datenbank feststellen, daß das irgendwo nicht funktioniert.Shade Of Mine schrieb:
Wir haben ein Datenbank System entwickelt. Nun brauchen wir eine Moeglichkeit Daten unterschiedlicher Typen hinein zuschreiben und wieder auszulesen. Das Problem dabei ist nun, dass der Client Code nicht weiss welchen Typ ein Datensatz hat. Wir brauchen daher ein vereinheitlichtes system um auf 50 verschiedene typen ueber das selbe interface zugreifen zu koennen.
Irgendwie ist dann doch die Problematik sehr gut durchgedrungen.
Ich kann dein Beisbiel voll und ganz so stehen lassen! Daß jedoch niemand auf die Idee kommt einfache Datensätze anzunehmen wo standard Datenbanken Anwendung fänden, müsste man noch auf die dynamischen Datensätze hinweisen.asc schrieb:
1. typedef struct ist redundant. Jede struct, class, enum, union ist bereits eine Typdefinition. Das typedef lässt man daher weg. Nachfolgender Code definiert einen Typ xtyp:
struct xtyp { int x; };Dank dir! Jetzt fällt es mir auch auf, daß es Unsinn ist das typedef anzugeben. Und alles passt wieder perfekt zusammen.
-
bastl schrieb:
Und was Assembler angeht muss ich hier auch noch was loßwerden, Ich programiere mit Assembler jetzt schon seit ca 15 Jahren Opjekt Orientiert und solche Sachen wie X11 oder QT sind nichts besonderes in Assembler und durchaus einfacher zu programieren als mit C++. Sowas wie X11 und QT in Einem habe ich schon in Assembler programmiert - das waren noch Zeiten unter DOS.
Hmm, naja, ich wollte das zwar eigentlich nicht bewerten, aber die Aussage ist so haarsträubend, dass ich jetzt doch mal mache:
Also Qt z.B. ist eine Sache bei der alleine die Grundentwicklung schon 7 Jahre gedauert hat. In einem Team mit vielen Leuten in C++. Jede Zeile C++-Code produziert dabei eine ganze Menge Zeilen in Assembler.
Nun sagst Du, dass Du noch zu DOS-Zeiten so was in Assembler gemacht hast. Du machst das seit 15 Jahren. 1994 hast Du also damit angefangen und konntest das ganze vermutlich noch nicht auf einem ausreichend hohen Niveau um so was wie X11 oder Qt umzusetzen.
Sagen wir also, Du hast zwei Jahre benötigt, um einen MPP-Assembler (z.B. x86 oder PPC) ausreichend perfekt zu lernen, um hochdynamische, komplexe Programme und Bibliotheken wie X11 und Qt damit zu entwickeln (wobei 2 Jahre schon extrem optimistisch sind).
Danach hast Du dann also noch zu DOS-Zeiten was Vergleichbares entwickelt. 1998 war DOS schon so ziemlich in den letzten Zuckungen (eher früher), und Du hast in zwei Jahren alleine (klingt zumindest so) was hochgezogen, wozu andere in einer Hochsprache im Team alleine 7 benötigt haben, um eine releasefähige Version zu produzieren?
Alle Achtung. Du bist der Batman der Informatik...
-
bastl schrieb:
Ich kann dier ja mal meine Projektseite geben, dannn muss ich hier nicht so viel erklären und du hast vielleicht auch eine bessere Vorstellung der Problematik. Also es geht um die Datenbanken und es sind ca.50 unterschiedliche Typen nötig um diese Datensätze zu verarbeiten (geschätzt), die Datenbankenstructur wurde gerade komplet überarbeitet - also die veröffentlichte Struktur (Download .pdf) ist veralted! Aber das Prinzip ist ziemlich gleich geblieben.
Wie du siehst können keine vorgefertigten Datenbanken eingesetzt werden. Ich muss diese Datenbankklasse von Grund auf selbst schreiben!
Ich habe dich ja schonmal gefragt ob du ein Typsystem brauchst wo ein Query eben unterschiedliche Typen liefern kann und der Client Code den typ vorher nicht kennt.
Ist eine triviale Sache. Wie das geht habe ich sogar schon erklaert.
Du hast eine Basisklasse "Typ" oder so aehnlich und davon erben alle anderen Typen. Die meisten Typen-Klassen sind dabei sehr klein und nur sehr wenige haben wirklich komplexitaet drinnen. Uber laufzeit polymorphie kannst du dann den echten Typen bestimmen.Oder aber du gehst den Weg den die meisten Datenbanken gehen und bietest mehrere Methoden an um an die Daten zu kommen. Wenn du ein select foo from bar machst, dann machst du nachher zB ein result.get<int>("foo") bzw. result.get<string>("foo"). Dann hast du keine laufzeit polymorphie und sparst dir vermutlich 70% der klassen...
Wie kann ich das mit viod* noch genauer erkären ... O.K. 3. Anlauf
Und ich habe dir in jedem von meinen Postings gesagt, dass uns das nichts bringt weil du nicht weisst _wie_ du es loesen willst. also sag mir nicht _wie_ du es machen willst, weil das ist falsch falsch falsch und tut weh.
void PartBase::read( void *unterschiedlich_lange_typen , int laenge ) { Einlesen von laenge Bytes, bei Bedarf mehrmals(- warscheinlich eher nicht) auf die Basisadresse *unterschiedlich_lange_typen. }Jetzt müsste doch klar sein um awas es geht?
Funktioniert das? Nach meiner Rechersche - Ja.Habe ich bereits erklaert.
du kannst entweder mit ::operator new oder mit new char[] laenge Bytes reservieren.Mehrmals speicher an der selben adresse reservieren macht dagegen keinen Sinn. Was meinst du damit?
Du kannst natuerlich speicher an der adresse X reserviern, ihn wieder freigeben und neu speicher reservieren.aber new gibt dir halt idR immer eine andere adresse zurueck.
und in deiner funktion muss der void* natuerlich by reference uebergeben werden...
Ich will halt nicht Tausende Zeilen schreiben und dann beim Probelauf auf eine Datenbank feststellen, daß das irgendwo nicht funktioniert.
komplett falscher ansatz.
und tausende zeilen? wofuer? fuer ein paar typen klassen?
brauchst du denn 150 mio Typen fuer eine erste test version? reichen da nicht 1-3 typen?Irgendwie ist dann doch die Problematik sehr gut durchgedrungen.
Ich kann dein Beisbiel voll und ganz so stehen lassen! Daß jedoch niemand auf die Idee kommt einfache Datensätze anzunehmen wo standard Datenbanken Anwendung fänden, müsste man noch auf die dynamischen Datensätze hinweisen.Und meinst du nicht dass das ein ziemliches Standard Problem ist? Ich meine: wieviele Datenbanksysteme sind in C++ geschrieben? eine Menge. Du bist also bei weitem nicht der erste der vor so einem Typ Problem steht.
Schau dir doch die APIs an die anderen RDBMS anbieten.
-
Tachyon schrieb:
7 benötigt haben, um eine releasefähige Version zu produzieren?
Alle Achtung. Du bist der Batman der Informatik...Ich gehemal kurz drauf ein:
Für dich mag es unwarscheinlich klingen, aber in Assembler hast du andere Möglichkeiten!
Du formatierst dir deine "Hochsprache" selbst. Du bist verantwortlich für Speichernutzung und Speicherverarbeitung. In C++ benötigst du Deklarationen dazu. Das heißt in Assembler hast du oft nur die Hälfte an Schreibarbeit, dafür musst du mehr wissen! Dann kommt noch hinzu, daß du im OO-Bereich oft nochmals nur 1/3 bis 1/20 der c++ Zeilen in Assembler benötigst.
So kommst du auf ca. 4 Jahre für eine Lauffähige Umgebung, die nur auf diesem Entwicklungsrechner läuft !!! Den ganzen Kode für kompatibilität sparst du ein! Die Ausführbare Umgebung (.exe) hatte eine Größe von 36 KB das sind dann so um 8 MB Assemblerdateien ( ungefähr, ist schon länger her).
Ich kann dir mal mein CNC-Projekt sagen, wenn du etwas von NASM verstehst und interessiert bist. Unter Download - Steuerungen - scr-hse-light :
http://freenet-homepage.de/PCNC/
Das ist jetzt nicht OO-programmiert aber möglicherweise unterstreicht es meine Fähigkeiten ein bischen.Shade Of Mine schrieb:
Du hast eine Basisklasse "Typ" oder so aehnlich und davon erben alle anderen Typen. Die meisten Typen-Klassen sind dabei sehr klein und nur sehr wenige haben wirklich komplexitaet drinnen. Uber laufzeit polymorphie kannst du dann den echten Typen bestimmen.
Gilt allse nicht für eine anwendungsoptimierte Datenbank - da muss man selber ran - sorry. Aslo wenn das mit void* funktioniert ist die Sache im Kasten.
Dann bedanke ich mich bei allen und tschüss.
-
bastl schrieb:
Du formatierst dir deine "Hochsprache" selbst. Du bist verantwortlich für Speichernutzung und Speicherverarbeitung. In C++ benötigst du Deklarationen dazu. Das heißt in Assembler hast du oft nur die Hälfte an Schreibarbeit, dafür musst du mehr wissen! Dann kommt noch hinzu, daß du im OO-Bereich oft nochmals nur 1/3 bis 1/20 der c++ Zeilen in Assembler benötigst.
Absoluter Schwachsinn auf der ganzen Linie.
So kommst du auf ca. 4 Jahre für eine Lauffähige Umgebung, die nur auf diesem Entwicklungsrechner läuft !!! Den ganzen Kode für kompatibilität sparst du ein! Die Ausführbare Umgebung (.exe) hatte eine Größe von 36 KB das sind dann so um 8 MB Assemblerdateien ( ungefähr, ist schon länger her).
Geht in C++ auch, ohne Probleme.
Aber du widersprichst dir selber: du sagst du brauchst in assembler weniger zeilen und dann redest du von 8mb source code...was natuerlich klar ist: in assembler brauchst du natuerlich deutlich mehr code um das selbe zu erreichen wie in einer hochsprache.
assembler ist keine magie. C ist im Prinzip nur ein Makro-Assembler. Du hast in Assembler nicht soviel mehr Moeglichkeiten - du bist idR sogar sehr limitiert. Natuerlich kannst du hier und da einen Trick einsetzen den du unter C++ nicht machen kannst (aber dafuer gibt es die moeglichkeit inline asm in C++ zu verwenden).
Ich kann dir mal mein CNC-Projekt sagen, wenn du etwas von NASM verstehst und interessiert bist. Unter Download - Steuerungen - scr-hse-light :
http://freenet-homepage.de/PCNC/
Das ist jetzt nicht OO-programmiert aber möglicherweise unterstreicht es meine Fähigkeiten ein bischen.Hab mir das da runter geladen: http://freenet-homepage.de/PCNC/src/pcnc-1.2.7.tar.bz2
Da sehe ich kein bisschen etwas von ordentlichem Code. Und von Assembler sehe ich auch nix. Wo verstecken sich die Asm Dateien denn?
Gilt allse nicht für eine anwendungsoptimierte Datenbank - da muss man selber ran - sorry. Aslo wenn das mit void* funktioniert ist die Sache im Kasten.
Schwachsinn. auf ganzer Linie.
Aber wenn es dir spass macht, bitte.
Aber wenn ich mir den PCNC Code ansehe... Du hast noch eine Menge uebers programmieren zu lernen. Nicht falsch verstehen bitte - aber du trittst hier auf als ob du schon jahrelang das alles koenntest, aber dein Code spricht eine komplett andere sprache.uU solltest du weniger fixiert auf eine loesung hin arbeiten als vielmehr das problem zu betrachten und eine loesung zu designen.
-
Du formatierst dir deine "Hochsprache" selbst. Du bist verantwortlich für Speichernutzung und Speicherverarbeitung. In C++ benötigst du Deklarationen dazu. Das heißt in Assembler hast du oft nur die Hälfte an Schreibarbeit, dafür musst du mehr wissen!
diese schlussfolgerung erschließt sich mir nicht. kannst du das mal genauer ausführen?
kennst du den spruch "wenn man einen hammer hat, sieht alles aus wie ein nagel"? oder konkret auf deine aussagen gemünzt: du kannst assembler, aber kein c++, also ist assemblercode in deinen augen besser, schöner, schneller.
es ist ja verständlich, dass du dich an dein sauer erlerntes wissen und deine erfahrungen klammerst, aber 1990 ist ja nun schon eine ganze weile her. die hochsprachen und ihre compiler haben sich weiterentwickelt, die hardware auch.http://freenet-homepage.de/PCNC/ schrieb:
Open Source heißt:
* Sie dürfen nichts für diese Software bezahlen oder verlangen.
[...]
* Sie dürfen mit der Anwendung der Software soviel Geld verdienen wie sie wollen.die erste aussage ist einfach nur falsch. die zweite widerspricht der ersten.
-
bastl schrieb:
kleiner tipp zu der seite: der hinweis, dass man javascript einschalten soll, wird mit javascript angezeigt. das kann nicht funktionieren.
-
Ich hoffe, in der Frässoftware sind nicht so viele Rechtschreibfehler wie auf der Seite
-
bastl schrieb:
Und was Assembler angeht muss ich hier auch noch was loßwerden, Ich programiere mit Assembler jetzt schon seit ca 15 Jahren Opjekt Orientiert und solche Sachen wie X11 oder QT sind nichts besonderes in Assembler und durchaus einfacher zu programieren als mit C++. Sowas wie X11 und QT in Einem habe ich schon in Assembler programmiert - das waren noch Zeiten unter DOS ...
Nö klar, X11 und Qt vor 15 Jahren unter DOS - kann es sein, dass der werte Herr ein bißchen ein Vollpfosten ist?