- LINUX
- GCC-4.3.1

Das hier hilft mir herauszufinden ob es sich Loht diese Aufgabe weiterhin mit c++ zu verfolgen oder ob ein Unterprojekt mit NASM und einem Makefile die schnellere Lösung darstellt. Weiterhin benötige ich voraussichtlich sowieso NASM um die Schnelligkeit der Simulation zu gewährleisten.

Kann man nun void *zeiger dazu benützen nacheinander mit dem gleichen Zeiger unterschiedliche formatierungen anzusprechen, die die gleiche Länge haben?

Ja, du musst den Zeiger entsprechend umwandeln (mit static_cast ), bevor du den Speicherbereich dahinter interpretierst. Und du musst natürlich dafür sorgen, dass du den richtigen Typ ansprichst.

Der gewünschte Benutzerna schrieb:

Oder andersrum, kann man den void *zeiger in einem read( void *zeiger, int laenge ) Member benutzen zur übergabe der Startadresse auf typedevs unterschiedlicher Länge, oder ist nach dem ersten Aufruf der sozusagenden Typzuweisung und damit Definition des Zeigers schluß?

Hier bin ich mir nicht ganz sicher, was du meinst. Du willst also eine Funktion bereitstellen, die die Adresse für einen beliebigen Typen ausliest? Und die Typen sind erst zur Laufzeit bekannt?

Irgendwie wirst du ja schon zur Compilezeit wissen, wie sich die einzelnen Typen verhalten, um sie auch spezifisch zu behandeln. Eventuell wären daher Templates angebracht. Aber um was für Typen geht es denn? Klassen? Oder nur PODs?

Ich bin gerade mal wieder an die Grenzen von C++ gestoßen. Das hat sich ziemlich schnell wenn man Assembler gewohnt ist.

Was du sagen willst ist, dass du sehr schnell an deine Wissensgrenzen stoesst...

Kann man nun void *zeiger dazu benützen nacheinander mit dem gleichen Zeiger unterschiedliche formatierungen anzusprechen, die die gleiche Länge haben?

Klar.
Aber aufs padding aufpassen.

Generell klingt das etwas komisch was du machen willst. magst du vielleicht erklaeren was du genau vor hast - uU gibt es sinnvollere ansaetze.

Oder andersrum, kann man den void *zeiger in einem read( void *zeiger, int laenge ) Member benutzen zur übergabe der Startadresse auf typedevs unterschiedlicher Länge, oder ist nach dem ersten Aufruf der sozusagenden Typzuweisung und damit Definition des Zeigers schluß?

Aeh... ein Zeiger besteht nur aus einer adresse und einem typen - mehr nicht. es koennen unendlich viele zeiger mit unendlich vielen typen auf die selbe speicherzelle zeigen...

Das hier hilft mir herauszufinden ob es sich Loht diese Aufgabe weiterhin mit c++ zu verfolgen oder ob ein Unterprojekt mit NASM und einem Makefile die schnellere Lösung darstellt. Weiterhin benötige ich voraussichtlich sowieso NASM um die Schnelligkeit der Simulation zu gewährleisten.

erklaer mal lieber was du genau machen willst.
in der regel sind assembler implementierungen langsamer als die selbe implementierung in einer hochsprache...

Alle Typen die ich so behandle sind Datensätze (z.B. 78byte lang manche auch unbestimmt und werden im zweiten Teil mit new erweitert) aus Dateien.
Der Datensatz ist definiert als typedev struct, also eine Klasse.
Der Datensatztyp enthält auch andere Typedev struct, hat also andere Klassenelemente.
Dürfte bis dahin kein Problem sein, solange, sobald die Länge sizeof() verfügbar ist und einen zusammenhängenden bereich im Speicher einnehmen. Also die Datensätze mit new kann ich im ganzen vergessen, da muss ich zwei Teile draus machen; einen der eingelesen werden kann (der enthält auch die Anzahl für die mit new zu erstellenden Datensätze, die mit new erzeugten Datensätze haben dann wiederum einen zusammenhängend Bereich (new type[n]))

static_cast, da muss ich mich mal schlau machen ... dürfte aber kein Problem sein, da die Typen alle global definiert sind....

type-casting ...
dynamic_cast <new_type> (expression)
reinterpret_cast <new_type> (expression)
static_cast <new_type> (expression)
const_cast <new_type> (expression)

Ich denke mal das funktioniert mit dynamic_cast dann auch für meine Typen mit klassenelementen und Funktionen

Also, ich will alle Member meiner Datenbankklasse mit der Typlänge und der dazugehörigen Basisadresse füttern. Bleiben wir bei diesem Problem dann habe ich genügend Übung für das andere.

Lese mir dann erst noch Artikel zur Awendung dieser Funktionen durch - also ich bin dann mal am studieren. (dann kann ich auch mitreden)

Bin mal kurz schlafen, bis gleich

bastl

Ich merke schon, das Tema wird nicht leicht, da wird man schon beleidigt.

Davon sehe ich hier nichts, falls du das mit den Wissensgrenzen meinst, so scheint dies zumindestens bezüglich C++ tatsächlich zu stimmen - dies ist aber keine Beleidigung, sondern das was man aus deinen Beschreibungen ablesen kann. Dies kann unter anderem an deiner langen Assemblerlaufbahn liegen, da man C++ eigentlich auf eine gänzlich andere Art benutzt als Assembler (Andere Ansätze, andere Paradigmen).

bastl schrieb:

Doch was mir bei C++ aufällt ist, daß sobald man an IO Operationen ran muss und damit auf Systemkomponenten zugreift, wird C++ sehr umständlich und langsam - dafür hat man natürlich eine ausgesprochene Kompatibilität.

Ich habe persönlich nur wenig Assemblererfahrungen, aber wenn die IO-Umsetzung der Standardbibliothek nicht gepuffert ist etc. kann diese auch langsam sein (z.B. sind die Streams unter Microsoft Visual C++ tendenziell langsam, wenn man ihnen keinen Buffer zuweist).

Zudem ist alles was ich inzwischen gehört habe, das C++ sich nicht wirklich hinter Assembler verstecken muss, und spätestens bei großen Anwendungen ist mit Sicherheit die Entwicklungszeit noch ein sehr wichtiges Argument. Je nach dem wie man C++ einsetzt kann es sehr langsam sein, aber ebenso kann man sehr schnelle Programme schreiben.

bastl schrieb:

...Der Datensatz ist definiert als typedev struct, also eine Klasse... new type[n]... alle global definiert...

Dies sind Dinge die schon darauf hinweisen, das du eher C als C++ entwickelst (unter C++ ist die schreibweise "typedef struct" mehr als unüblich, dies ist eher ein typisches C-Relikt; C-Arrays sind - wie der Name schon sagt auch eher in C als in C++ zu finden). Auch deine Typbeschreibung deutet eher von einer Assemblersichtweise hin. Dies mag auch dazu führen das du dein Problem in einer weise schilderst die für mich aus der C++ Sicht eher schwer verständlich ist.

Vielleicht löst du dich etwas von deiner stark technischen Beschreibung, und erklärst deine Problematik mal ohne Nennung von irgendwelchen Implementationsdetails (Außer vielleicht bezogen auf die Eingangsgrößen und Ausgangsgrößen).

dynamic_cast ist übrigens für polymorphe Objekte (Umwandlung von einen Zeiger einer Basisklasse in einen Zeiger einer abgeleiteten, polymorphen [Thema virtuelle Funktionen] Klasse), nicht für normale Typumwandlungen.

Zudem, mag sein das ich das auch aus deinem Text falsch ablese, solltest du dir bezüglich new/new[] nochmal Gedanken machen. Mit new erzeugte Einzelobjekte und ein mit new Erzeuges Array sind unterschiedliche Dinge...

cu André

Doch was mir bei C++ aufällt ist, daß sobald man an IO Operationen ran muss und damit auf Systemkomponenten zugreift, wird C++ sehr umständlich und langsam - dafür hat man natürlich eine ausgesprochene Kompatibilität.

Wenn du mit IO die IOStreams meinst - die sind für komfort optimiert, du kannst jederzeit aber ein CreateFile/WriteFile machen wie du es in Assembler auch machen würdest...

Und damit gleichmal zur Schnellchkeit, wo ich dich berichtigen muss und ich wohl jede Menge Rückendeckung habe: Assembler ist natürlich viel schneller und mit keiner Hochsprache zu vergleichen;

Ich wage es zu bezweifeln dass man komplexe programme in assembler effizienter programmieren kann als in einer hochsprache wie C++. Kleine Stellen in Algorithmen ja, aber generell nein.

Ich denke mal das funktioniert mit dynamic_cast dann auch für meine Typen mit klassenelementen und Funktionen

Äh... Nein.
Erkläre bitte was du machen willst - nicht welche C++ Mittel du einsetzen willst.

Willst du rohen Speicher als Objekte unterschiedlicher Typen betrachten?
Warum?

Oder willst du einfach ein abstraktes Typsystem haben, im Sinne von: die Funktion foo() liefert einen Wert den man als integer, double, string oder sonstwas interpretieren kann? Ähnlich wie einer ScriptSprache mit DuckTyping?

Oder willst du soetwas wie bei einer Datenbank API üblich: du machst "select foo from bar" und je nachdem welchen Typ foo hat soll dementsprechend ein passendes objekt zurück gegeben werden? uU kann man foo als integer und als string betrachten und das willst du im client dann durchweselbar machen?

uU suchst du auch einfach nur "union" oder variant/any.

deshalb: erkläre _was_ du machen willst und _warum_ und nicht _wie_. Denn das _wie_ sagen wir dir dann...

PS:
und beleidigen will ich dich sicher nicht, aber dein C++ Wissen scheint mir nunmal nicht wirklich umfassend zu sein. Ist ja keine Beleidigung, einfach nur eine feststellung.

So wie ich das verstanden habe, hat er Typen, welche u.a. Zeiger auf andere Typen enthalten. Den Zeigern kann dann bei Bedarf allokierter Speicher (auf die anderen Typen) zugeordnet werden. Nun meint er, dass dabei die Speichebereiche nicht zusammenhängend sein können.
Das können sie aber. Das geht mit placement new .

O_o

das habe ich nichtmal annäherend herausgelesen. ich denke eher dass er richtung ducktyping will... aber ok - da muss er wohl näher erklären was er will...

das habe ich nichtmal annäherend herausgelesen. ich denke eher dass er richtung ducktyping will... aber ok - da muss er wohl näher erklären was er will...

Okay, wenn's das wirklich sein sollte, dann wäre Assembler so ziemlich das Letzte, womit ich das implementieren wollte. Ich wäre da nichtmal auf die Idee gekommen, das im gleichen Atemzug zu erwähnen.

Wenn ich mir den Eröffnungspost nochmal durchlese, hast Du vermutlich sogar recht. Ich habe mir meine Vermutung irgendwie aus der Antwort auf Deinen Vorschlag zusammengereimt.

Wenn ich mir den Eröffnungspost nochmal durchlese, hast Du vermutlich sogar recht. Ich habe mir meine Vermutung irgendwie aus der Antwort auf Deinen Vorschlag zusammengereimt.

Ja das mit dem new hab ich nichtmal ansatzweise kapiert was er will

Kann man nun void *zeiger dazu benützen nacheinander mit dem gleichen Zeiger unterschiedliche formatierungen anzusprechen, die die gleiche Länge haben?

Ohje, das ist totaler Nonsense. Man kann das technisch zwar machen, aber das ganze ist nicht mehr portabel, da hier solche Dinge wie Padding, Aligment, Byte Order etc. zum Tragen kommen. Wenn man Assembler programmiert, kann man das so machen, da der Code ohnehin nicht portabel ist, sobald man aber mit C++ anfängt muß man davon die Finger lassen.

Ohje, das ist totaler Nonsense. Man kann das technisch zwar machen, aber das ganze ist nicht mehr portabel, da hier solche Dinge wie Padding, Aligment, Byte Order etc. zum Tragen kommen. Wenn man Assembler programmiert, kann man das so machen, da der Code ohnehin nicht portabel ist, sobald man aber mit C++ anfängt muß man davon die Finger lassen.

Das ist ebenfalls Nonsense. Nicht jedes C++ Programm ist dafür gedacht, portabel zu sein. Manchmal will man auch einfach nur schnell zu einer effizienten, günstigen Lösung kommen. Portabel sind C++-Programme schon dann nicht mehr, wenn sie plattformspezifische Bibliotheken benutzen, und das machen eine Menge Programme...

Dies sind Dinge die schon darauf hinweisen, das du eher C als C++ entwickelst (unter C++ ist die schreibweise "typedef struct" mehr als unüblich, dies ist eher ein typisches C-Relikt; C-Arrays sind - wie der Name schon sagt auch eher in C als in C++ zu finden). Auch deine Typbeschreibung deutet eher von einer Assemblersichtweise hin.

Also asc Ich hätte dann auch schon gerne, daß du die C Thematik dann auch für C++ angibst (wie man es in C++ richtig macht).
Ich benötige einen Typnamen (z.B. für new), jedoch keinen Klassennamen außer für meine dynamische Typen. Wenn gcc es halt nicht anders akzeptiert musst du mir einen Vorschlag machen - ich probiere das gerne aus.

-----
Zu dir Shade Of Mine, das unterschiedliche formatieren eines Speicherbereiches lassen wir mal beiseite, wird sonst zu kompliziert hier auf zwei Probleme einzugehen. Das eigentliche Problem ist also die Datenbankklasse mit den normalen Members, die man so braucht, read, write, und und das einstreamen unterschiedlicher Typen (Längen von 10 Byte bis 10 MB pro Typ).
Ich kann jetzt für jede Datenbank eine eigene Klasse schreiben (ca. 50 Stück) oder eine Klasse für alle Datenbanken. Daraus ergibt sich die Problematik der unterschiedlichen Typen. Das hat dazu gefhürt die Möglichkeit hier zu erörtern, ob dies ohne gröpßeren Aufwand möglich ist. Eine und für mich die plausibelste Mölichkeit ist, den Basiszeiger eines zusammenhängenden Speicherbereiches zu übergeben und die dazugehöige Länge, ist ja oben schon beschrieben. Manche Typen müssen mehrfach in Stücken eingelesen werden, da diese Datenbanken aus dynamischen Datensätzen bestehen.Wir können hier nur abstrakt erörtern, das muss ich auch beim programieren so machen.

Und ich muss hier auch sagen, daß man C++ nicht programieren kann ohne zu wissen wie der Kompiler funktioniert. Man muss genau wissen wie werden Daten im Speicher abgelegt, was macht new und wie verhält sich was wenn man es so programmiert; da kommt mir meine Assembler Erfahrung teilweise schon zugute.

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

Tachyon schrieb:

So wie ich das verstanden habe, hat er Typen, welche u.a. Zeiger auf andere Typen enthalten. Den Zeigern kann dann bei Bedarf allokierter Speicher (auf die anderen Typen) zugeordnet werden.

Keine Zeiger, aber der Datensatz ermöglicht es mit seiner enthaltenen Info ihn zu vervollständigen (man kann mit dem ersten Teil den noch fehlenden Teil ausrechnen). Jetzt ist es so, daß mich zwei nicht zusammenhängende Blöcke aber nicht stören, da diese Typen sowieso dynamisch sind und auf zweimal eingelesen werden müssen. Was placement angeht - ja, deshalp wird ein ARRAY von Typen mit new erzeugt - dann ist es automatisch zusammenhägnend.(mit new erzeugte arrays und strings sind immer zusammenhängend)

2.) Mit Assembler kann ich halt den kompletten dynamischen Datensatz auf einmal einlesen und c++ die nötige Info dazu liefern (Laufzeitimplementierung).

ducktyping betrift die Umformatierung was ich vorerst hier mal weglassen will.
------

Shade Of Mine schrieb:

Ja das mit dem new hab ich nichtmal ansatzweise kapiert was er will

Was braucht ihr da für Info? - Wenn es in diesem Block nicht stehen sollte.

Wie sieht es nun mit void *zeiger aus? Ist der Geltungsbereich dann nur innerhalb der Funktion, in der ich diesen void *zeiger benutze? Oder überträgt sich das auf die nächsten Aufrufe? Jeder Aufruf der Funktion ist ja mit einem Zeiger auf einen Typ, der eine Länge hat, die sich von der des vorherigen Aufrufs unterscheidet. Ich vermute mal, daß der Geltungspereich die Funktion ist und somit void *auf_gleiche_laenge nur innerhalb der Funktion gilt.

Mich würde mal interessieren, was überhaupt mit dem Wort "Formatierung" in diesem Zusammenhang gemeint ist.

Ich denke schon, daß dies ein kompakter Ausdruck ist, der angemessen ist.
- Wenn 2 Typen gleicher Länge (z.B Typ1 mit 8 chars und Typ2 mit 2 ints) die gleiche Basisadresse haben. Der Seicherbereich ab Basisadresse hat somit 2 unterschiedliche ansprechbare Formate oder anders ausgedrückt: ein Typ formatiert lediglich einen Abschnit im Speicher ab Basisadresse. Speicher ist Speicher und besteht aus Bits erst eine Formatierung sagt mir wie ich einen Speicherbereich benützen soll, muss, darf - so will es C++.

Ohje, das ist totaler Nonsense. Man kann das technisch zwar machen, aber das ganze ist nicht mehr portabel, da hier solche Dinge wie Padding, Aligment, Byte Order etc. zum Tragen kommen. Wenn man Assembler programmiert, kann man das so machen, da der Code ohnehin nicht portabel ist, sobald man aber mit C++ anfängt muß man davon die Finger lassen.

Da hast du absolut Recht, jetzt muss ich abwegen ....

IA64 - O.K. davon gehe ich aus.
Apple hat jetzt IA86 - O.K.
Sparc - Nein, das ist nicht gut
S390 - Nein, garnicht gut

In 2 Jahren hab ich vielleicht die erste Version dann gibt es vieleicht schon einen IA64 64 core dann läuft das Programm auch ordentlich.
O.K. ich verzichte auf Portabilität.

asc schrieb:

Dies sind Dinge die schon darauf hinweisen, das du eher C als C++ entwickelst (unter C++ ist die schreibweise "typedef struct" mehr als unüblich, dies ist eher ein typisches C-Relikt; C-Arrays sind - wie der Name schon sagt auch eher in C als in C++ zu finden). Auch deine Typbeschreibung deutet eher von einer Assemblersichtweise hin.

Also asc Ich hätte dann auch schon gerne, daß du die C Thematik dann auch für C++ angibst (wie man es in C++ richtig macht).

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

bastl schrieb:

Ich benötige einen Typnamen (z.B. für new), jedoch keinen Klassennamen außer für meine dynamische Typen

Keine Ahnung was du damit meinst (Ein Klassenname IST ein Typenname).

2. Unter C++ verwendet man C-Array eher selten, da es weder sinnvoll Kopiert etc. Statt dessen sind eigentlich die Containerklassen der Standardbibliothek in Verwendung (std::vector, std::list, std::map, std::tr1::array...).

3. void* ist nicht für delete geeignet. delete benötigt Typinformationen, die erhält es durch ein void* nicht. Wenn du unbedingt mit rohen Speicher hantieren willst, würde ich eher ein char* oder std::vector<char> nehmen, dann kannst du es wenigstens byteweise interpretieren.

Ebenso kann man void* nur benutzen wenn man weiß wie man die Daten zu interpretieren hat.

C++ arbeitet nun einmal mit einem statischen Typsystem.

bastl schrieb:

Und ich muss hier auch sagen, daß man C++ nicht programieren kann ohne zu wissen wie der Kompiler funktioniert. Man muss genau wissen wie werden Daten im Speicher abgelegt, was macht new und wie verhält sich was wenn man es so programmiert

Das ist absoluter Nonsense, es sei vielleicht, man will alles auf binärer Ebene bearbeiten, was eigentlich in C++ nicht üblich ist - Dann sollte man gleich in Assembler weiterarbeiten.

Eine Programmiersprache ist ein Werkzeug um eine Aufgabe zu erledigen. Das man ungefähre Vorstellung hat, wie etwas realisiert werden könnte kann manchmal hilfreich, nicht selten aber auch die sprichwörtlichen Scheuklappen sein. Um ein Ziel zu erreichen sollte es - zumindestens in einer Hochsprache - vollkommen egal sein was der Compiler im Hintergrund daraus macht.

bastl schrieb:

Was placement angeht - ja, deshalp wird ein ARRAY von Typen mit new erzeugt - dann ist es automatisch zusammenhägnend.(mit new erzeugte arrays und strings sind immer zusammenhängend)

Das ist auch beim std::vector oder std::tr1::array definiert.

cu André

Das ist ebenfalls Nonsense. Nicht jedes C++ Programm ist dafür gedacht, portabel zu sein. Manchmal will man auch einfach nur schnell zu einer effizienten, günstigen Lösung kommen. Portabel sind C++-Programme schon dann nicht mehr, wenn sie plattformspezifische Bibliotheken benutzen, und das machen eine Menge Programme...

Das ist totaler Quatsch! (Wohl bisher nur unter Windows gearbeitet?) UNIX Programme verwenden seit Jahrzehnten spezielle UNIX Libraries und laufen trotzdem auf sehr vielen verschiedenen Prozessorachitekturen.

Wenn man unter UNIX, Linux oder Windows entwickelt, dann gibt es mehr als eine Prozessorarchitektur! Bei Windows gibt es IA32, IA32-64, IA64 bei den anderen Plattformen kommen noch Power, HP-PA, SPARC, ARM, MIPS etc. dazu. Wenn man da ohne Not von einer spezifischen Anordnung der Daten ausgeht, baut man einfach nur Mist. Zum Beispiel sollen Daten ja auch unabhängig vom 32Bit oder 64Bit Modus eingelesen werden können, und es gibt Betriebssysteme die laufen nicht nur auf einer Hardwarearchitektur. Wenn man nicht gerade an Computerspielen oder ähnlich zeitkritischen Programmen arbeitet sollte man die Finger von Mikrooptimierungen lassen, denn in der Regel lebt der Code länger als einem beim Entwerfen bewußt ist.

IA64 - O.K. davon gehe ich aus.
Apple hat jetzt IA86 - O.K.
Sparc - Nein, das ist nicht gut
S390 - Nein, garnicht gut

In 2 Jahren hab ich vielleicht die erste Version dann gibt es vieleicht schon einen IA64 64 core dann läuft das Programm auch ordentlich.
O.K. ich verzichte auf Portabilität.

1. Du meinst IA32-64. IA64 wäre der Itanium! Windows läuft auf IA64.
2. Es ist auch über verschiedene Compilerversionen nicht portabel!

Das ist totaler Quatsch! (Wohl bisher nur unter Windows gearbeitet?) UNIX Programme verwenden seit Jahrzehnten spezielle UNIX Libraries und laufen trotzdem auf sehr vielen verschiedenen Prozessorachitekturen.

Es gibt Ausnahmen, die Regel (zumindestens in der Anwendungsentwicklung in kommerziell orientierten Projekten), ist es möglichst schnell eine Lösung zu präsentieren. Und dazu greifen viele Firmen auf OS-Spezifische Bibliotheken zu.

Man kann C++ auch sehr portabel schreiben (das es unter vielen Betriebssystemen wieder gelinkt werden kann), aber das erlebe ich eigentlich eher selten. Auch wenn ich selbst ein Fan davon bin in Anwendungen zumindestens die Schichten zwischen UI auf der einen, und Datenzugriff auf der anderen Seite weitgehend portabel zu halten.

cu André

Ich benötige einen Typnamen (z.B. für new), jedoch keinen Klassennamen außer für meine dynamische Typen.

"struct" und "class" sind in C++ fast dasselbe. Es sind auch Typen, aber es gibt weitere Arten von Typen.

bastl schrieb:

Zu dir Shade Of Mine, das unterschiedliche formatieren eines Speicherbereiches lassen wir mal beiseite, wird sonst zu kompliziert hier auf zwei Probleme einzugehen. Das eigentliche Problem ist also die Datenbankklasse mit den normalen Members, die man so braucht, read, write, und und das einstreamen unterschiedlicher Typen (Längen von 10 Byte bis 10 MB pro Typ).

Was willst Du machen? Objektgraphen (de)serialisieren oder RDBMS Abfragen auf ein RDBMS loslassen? Davon hängt maßgeblich ab, wie man es umsetzt.

Ich benötige einen Typnamen (z.B. für new), jedoch keinen Klassennamen außer für meine dynamische Typen. Wenn gcc es halt nicht anders akzeptiert musst du mir einen Vorschlag machen - ich probiere das gerne aus.

Ich glaube ich habe verstanden was du machen willst.
Aber eine schoene Erklaerung waere nicht schlecht - da muss man nicht soviel raten.

Du kannst rohen Speicher besorgen:

void* p = ::operator new(100);

das besorgt die 100 byte Speicher.

Nun kannst du wenn du zB eine struct Foo oder Bar hast:

struct Foo { int i[5]; }
struct Bar { double d[5]; }

Theoretisch ein:

Foo* f = static_cast<Foo*>(p);
Bar* b = static_cast<Bar*>(p);

machen - oder aber mit einer Union arbeiten.

Aber das ist mit sehr grosser Wahrscheinlichkeit genau das falsche vorgehen...

Das eigentliche Problem ist also die Datenbankklasse mit den normalen Members, die man so braucht, read, write, und und das einstreamen unterschiedlicher Typen (Längen von 10 Byte bis 10 MB pro Typ).
Ich kann jetzt für jede Datenbank eine eigene Klasse schreiben (ca. 50 Stück) oder eine Klasse für alle Datenbanken.

Meinst du wirklich 50 unterschiedliche Datenbanken? Oder meinst du 50 unterschiedliche typen?

Jedenfalls:
Wenn du Datenbanken meinst - da verwendet man ein vereinheitlichtes interface (zB ODBC, ADO,...) um auf sie zuzugreifen und muss nur gegebenenfalls leicht adaptieren.
Wenn du Typen meinst: ja, dann musst du 50+ Klassen schreiben, wobei die meisten klassen sehr sehr sehr klein sein werden.

Daraus ergibt sich die Problematik der unterschiedlichen Typen. Das hat dazu gefhürt die Möglichkeit hier zu erörtern, ob dies ohne gröpßeren Aufwand möglich ist. Eine und für mich die plausibelste Mölichkeit ist, den Basiszeiger eines zusammenhängenden Speicherbereiches zu übergeben und die dazugehöige Länge, ist ja oben schon beschrieben. Manche Typen müssen mehrfach in Stücken eingelesen werden, da diese Datenbanken aus dynamischen Datensätzen bestehen.Wir können hier nur abstrakt erörtern, das muss ich auch beim programieren so machen.

Nein - nicht sagen wie du es machen willst. Einfach erklaeren _was_ du machen willst. Und zwar mit der richtigen terminologie.

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

Und dennoch bist du unfaehig ein Problem zu _beschreiben_?

2.) Mit Assembler kann ich halt den kompletten dynamischen Datensatz auf einmal einlesen und c++ die nötige Info dazu liefern (Laufzeitimplementierung).

Du kannst in C++ sehr wohl nur rohe daten anfassen...

Was braucht ihr da für Info? - Wenn es in diesem Block nicht stehen sollte.

Eine korrekte terminologie brauche ich und keine erklaerung was du mit basisklassenzeiger machen willst oder sonstwas. ein _was_ du machen willst brauche ich, kein _wie_.

Erklaer die Aufgabenstellung einfach mal so, wie du sie einem Schueler stellen wuerdest. zB:

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.

So in der Art bitte.

Wie sieht es nun mit void *zeiger aus? Ist der Geltungsbereich dann nur innerhalb der Funktion, in der ich diesen void *zeiger benutze?

Aeh... Das sind eigentlich Grundlagen - programmierst du wirklich schon 3 jahre lang in C++?
Naja, jedenfalls: eine variable (ein zeiger ist auch nur eine variable) ist in ihrer gueltigkeit durch ihren Scope beschraenkt. Der Speicher auf den ein Zeiger zeigt unterliegt ebenfalls einem Scope: speicher am Stack wird geloescht wenn die stack-variable out of scope geht. Speicher der am Free Store liegt, bleibt solange bestehen bis er explizit geloescht wird (delete).

Oder überträgt sich das auf die nächsten Aufrufe? Jeder Aufruf der Funktion ist ja mit einem Zeiger auf einen Typ, der eine Länge hat, die sich von der des vorherigen Aufrufs unterscheidet. Ich vermute mal, daß der Geltungspereich die Funktion ist und somit void *auf_gleiche_laenge nur innerhalb der Funktion gilt.

Das ergibt fuer mich keinen Sinn.
sizeof(void*) und sizeof(T*) sind uebrigens gleich gross...

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

http://keda.berlios.de/

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.

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

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.

http://keda.berlios.de/

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.