also ich hätte jern sowas in der richtung, ich weiß aber gerade nicht wie ich das umsetzen soll,...

class a
{...
};

class b
{ ...
};

a ac;
b bc;

Array[1].push_back(ac); // oder Array[1]=ac wenn das i te elem als a class blaaa
Array[2].push_back(bc);

könnt ihr mir einen kleinen ansatz liefern biddö,.. thx

class a
{
...
};

class b
{
...
};

union u
{
a ac;
b bc;
};

die union benötigt also nur soviel speicher wie das grösste element (hier class a oder class b), allerdings kann auch nur eins davon verwendet werden. du kannst jetzt aber ein array dieser union anlegen nur beim "befüllen" der elemente musst du dich festlegen welche klasse nun verwendet werden soll.

Aber falls die Objekte sich ähneln, ginge das mit Polymorphismus auch schön

thx,. abba ihhh english *g* scherz,..
geht's net irgendwie einfacher?? bzw schneller?
grüüße

ein array von versch. datentypen (seien es basisdatentypen oder klassen, structs...) geht prinzipiell nicht, nein.

was ich vorhab,.. naja:

template<class T>
class B1
{....};

class c1
{....};

class c2
{....};

template<class T>
class B2{.....};

class c3
{...};

class c4
{....};

class A
{ 
 B1<c1> b1;
 B1<c2> b2;
 B1<c1> b3; 
 array[1].push_back(b1);
 array[2].push_back(b3);
.... 

};

also die instanz b3 ist nicht gleich b1,...

ich will beliebige Instanzen verschiedener (beliebiger) objekte verarbeiten,..
in einem array halt,.. vererbung bringt mir nüscht hier an der stelle,..

oder

struct UnknownObject
{
    long  lTypeId;
    void* pObject;
};

std::vector<UnknownObject>

Falls du den Typ der Objekte bestimmen willst. Das ganze ließe sich natürlich ausbauen.

MfG
DDR-RAM

nein das sollen beliebige klassen sein,...

was ich vorhab,.. naja:

template<class T>
class B1
{....};
...

...

"beliebig" zur Compile- oder noch zur Laufzeit ? Dein Code suggeriert das erste, aber vielleicht habe ich das falsch verstanden.

zeusosc schrieb:

...
also ich hätte jern sowas in der richtung, ...

Hi,

ich will Dich nicht angreifen, sondern lediglich sanft hinterfragen: Warum ?

Derartige "Mischcontainer" (zumindestens, wenn sie zur Laufzeit variabel sein sollen) haben Nachteile und sind (zur Compilezeit) typsichereren Containern oftmals unterlegen - bisweilen einfach dadurch, dass sie "Gedankenarbeit" von dem (einen) Anfang (einmal richtig designed) auf später (jede Nutzung) verlagern (zig-mal "rumhampeln", drüber nachdenken, rumfrickeln, Sonderlocken stricken).

Natürlich gibt es Situationen, in denen sie wichtig und richtig sind (und sei es, dass Du nurmal "die Sprache ausprobieren" willst)... aber sehr viel seltener, als man oft meint.
Ich denke bei sowas 5mal nach, ob es nicht eigentlich doch der typsichere Container ist, den ich brauche. ... und bislang brauchte ich immer höchstens 3mal, um das zu erkennen (und, wo ich vorher falsch gedacht hatte).

Gruß,

Simon2.

P.S.: Nicht als Flame gemeint: Diesen Ansatz habe ich schon öfter von Leuten gesehen, die von Java her kommen und das dort Bekannte in C++ suchen, nicht finden und dann nachprogrammieren wollen. Hier hat C++ aber eine ganz andere Philosophie, ...

P.P.S: Meine Kollegin hatte das letztens "anders herum": Von C++ kommend, suchte sie in Java (zur Compilezeit) typsichere Container ... fand keine und verzweifelte an den Javakollegen und deren "Warum sollte man das brauchen ?" Da muss man im Kopf einfach switchen und sagen: "In C++ macht man das eben so und in Java eben so - fertig".

ich hoffe das folgende organigramm gibt aufschluss

class CRequest_header  ;   class CResponse_Header (beinhaltet daten und methoden)
                   \       /
                    \     /    (durch vererbung weitergegeben)
                     \   /  
                  class TClient (methoden -> Handling der Env var's,sockets)
                       |
                       | 
                  class VClient ( verarbeitet einen Vector von beliebiger menge              
                       |        ( von clienten, besitzt methoden zu analyse des              
               ...     |        ( Requestes und erzeugung der responses
                  \    |    ...
                   \   |   /
                    \  |  /   
                class TCPservice (behandelt das FD_SET, Sowie recv send,           
  ...                  |         (socketdef für beliebige TCPservices, etc...
    \                  |
     \                 |              
    class UDPservice   |                   ...
                 \     |                  /
                  \    |    class RAWservice
                   \   |   /
                class Server  (behandelt [B]beliebige[/B] instanzen, jeweiliger             
                              (services....

sooo jetzt kommen wir wieder auf meine frage zurück,...
wenn ich zur laufzeit mit dem programm interagiere um ein zusätzlichen (ein oder mehrere z.B. TCPservice<HTCPCP> (instanz) zu starten, möchte ich diese in der class Server linear durch das Array abarbeiten können,. (sei es push_back etc...)

@DDR-ROM
das mit dem struct werde ich gleich mal ausprobieren,..

thx leude

std::vector<void*>

oder

struct UnknownObject
{
    long  lTypeId;
    void* pObject;
};

std::vector<UnknownObject>

Falls du den Typ der Objekte bestimmen willst. Das ganze ließe sich natürlich ausbauen.

MfG
DDR-RAM

jo das funzt (also der compiler meckert net )
supi thx,...

@Simon2
...
wenn ich zur laufzeit mit dem programm interagiere um ein zusätzlichen (ein oder mehrere z.B. TCPservice<HTCPCP> (instanz) zu starten, möchte ich diese in der class Server linear durch das Array abarbeiten können,. (sei es push_back etc...)
...

Ich habe da aber noch nicht verstanden, warum Du da keine Polymorphie verwendest.
Da, wo Du Dich durch den vector/das Array arbeitest, muß ja die Struktur der drinliegenden Daten zumindestens "aufrufbar bekannt" sein. Haben denn wirklich die "services" keine gemeinsame Funktionsbasis ? Fände ich eher seltsam.
Macht der Server tatsächlich mit einem UDPService etwas komplett anderes als mit einem TCPService ? Und woher kommt die "Namensnähe" ("-service"), wenn sie ganz Anderes machen ?

Im Augenblick spricht für mich nichts gegen eine gemeinsame "Service-Basisklasse". Für "Spezialfunktionen" kannst Du immer noch eine "SpecialServiceHandler()" nutzen, der dann die Steuerung übernimmt ... gerade weil für allzu spezielle Fachlichkeit üblicherweise auch sehr spezielle Inputdaten, Ablaufpfade, ... notwendig werden.

DDR-ROMs Weg funktionert erstmal, führt Dich aber tief in eine Wartungshölle ... genau in die Hölle übrigens, der Du höchstwahrscheinlich mit Deiner ausgefeilten Vererbungsstrategie entgehen willst.

BTW: Wenn Du mit templates arbeitest, liegt der Typ sogar schon zur Compilezeit fest .... da brauchst Du auch keine Flexibilisierung zur Laufzeit mehr.

Gruß,

Simon2.

Ich habe da aber noch nicht verstanden, warum Du da keine Polymorphie verwendest.

Da, wo Du Dich durch den vector/das Array arbeitest, muß ja die Struktur der drinliegenden Daten zumindestens "aufrufbar bekannt" sein. Haben denn wirklich die "services" keine gemeinsame Funktionsbasis ? Fände ich eher seltsam.
Macht der Server tatsächlich mit einem UDPService etwas komplett anderes als mit einem TCPService ? Und woher kommt die "Namensnähe" ("-service"), wenn sie ganz Anderes machen ?

jupp da kann man das schon mochen,.. eine basisklasse erzeugen wovon TCP-UDPservice von erbt (z.B. schnitstellendefinitionen),.. dass ist abber nicht von VClient,..

aufrufbar bekannt,.. sind schnitstellendefinitionen für jeweils TCP UDP etc,.. und dem dementsprechenden service (z.B.: die verwaltungsebene VClient)
aber wozu soll TCPservice die Methoden von VClient,HClient,DClient (etc..) erben wenn gerade TCPservice die Methoden aufruft? (behandelt,.. die Methoden jeweiliger .Client's machen etwas semantisch ähnliches, syntaktisch aber net gerade...)

Simon2 schrieb:

DDR-ROMs Weg funktionert erstmal, führt Dich aber tief in eine Wartungshölle ... genau in die Hölle übrigens, der Du höchstwahrscheinlich mit Deiner ausgefeilten Vererbungsstrategie entgehen willst.

ein bissl sarkasmus schadet nie *g*, aber mal ehrlich,.. die objektbehandlung (also meine siehe oben )finde ich übersichtlich, und leicht ergänzbar,...

Wartungshölle würde ich das net nennen,.. da die Methoden von vector bekannt und einfach zu handhaben sind,...
grüße,.. freue mich schon auf antwort

Zum Thema:

zeusosc schrieb:

...
jupp da kann man das schon mochen,.. eine basisklasse erzeugen wovon TCP-UDPservice von erbt (z.B. schnitstellendefinitionen),.. dass ist abber nicht von VClient,..

aufrufbar bekannt,.. sind schnitstellendefinitionen für jeweils TCP UDP etc,.. und dem dementsprechenden service (z.B.: die verwaltungsebene VClient)
aber wozu soll TCPservice die Methoden von VClient,HClient,DClient (etc..) erben wenn gerade TCPservice die Methoden aufruft? (behandelt,.. die Methoden jeweiliger .Client's machen etwas semantisch ähnliches, syntaktisch aber net gerade...)

Sorry, den Satz verstehe ich schon vom Aufbau her nicht. Wo hört eine Aussage auf, wo fängt die nächste an ? Auf welche Substantive beziehen sich welche Verben ? Sind das Sätze ohne Subjekt dabei ? ....

Formuliere das doch noch mal ein wenig gründlicher (nicht unbedingt länger, sondern exakter), dann kann und will ich gerne darauf antworten.

zeusosc schrieb:

...

Simon2 schrieb:

DDR-ROMs Weg funktionert erstmal, führt Dich aber tief in eine Wartungshölle ... genau in die Hölle übrigens, der Du höchstwahrscheinlich mit Deiner ausgefeilten Vererbungsstrategie entgehen willst.

ein bissl sarkasmus schadet nie *g*,

Das war keinesfalls sarkastisch gemeint !
Sie erscheint mir (auf den ersten Blick - zu einer näheren Prüfung weiß ich zu wenig über die Aufgabenstellung) durchaus sinnvoll (wenn ich persönlich auch eher zu immer weniger Vererbung tendiere - nur noch bei ganz starken "ist-ein-Relationen").
Nur zu meinem besseren Verständnis - habe ich das richtig verstanden:

• der Server "besitzt/verweist auf" einen oder mehrere <xyz>-Services (sie erben also NICHT von ihm, sondern er hat einen Zeiger/Referenz/Vektor/... auf sie)
• erben die VClients vom TCPService ? Auch von anderen Services ?
• "VClient verarbeitet einen Vektor von einer Menge von Clienten ..." klingt mir nicht sinnvoll - Entweder IST das Teil ein Client oder es ist ein Clientenverwalter (nur in seltenen Ausnahmefällen/Baumstrukturen trifft beides zu) ... oder steht V für "Verwalter" ?
• TClient erbt von VClient ?
• "(durch vererbung weitergegeben)": Erben Request und Header von TClient ?

zeusosc schrieb:

...
aber mal ehrlich,.. die objektbehandlung (also meine siehe oben )finde ich übersichtlich, und leicht ergänzbar,...

Wartungshölle würde ich das net nennen,.. da die Methoden von vector bekannt und einfach zu handhaben sind,...
grüße,.. freue mich schon auf antwort

Wenn Du "siehe oben" schreibst, meinst Du vermutlich Deine Klassenstruktur. Ich bezog "Wartungshölle" aber auf DDR-RAMs Vorschlag.

Der Weg über "Typ-IDs" (seien es nun über die eingebaute RTTI von C++ oder Selbstgemachtes wie von DDR-RAM) ist am Anfang glatt und einfach ... aber Du musst an JEDER Stelle, an der Du damit umgehst, jeden Typ (ggf. mit seinen Eigenarten) nachpflegen. Außerdem wird es extrem haarig, wenn Du weiter "klassifizierst" ... z.B. wenn es einen "highTCPService" und einen "lowTCPService" geben soll, die sich oftmals wie ein "TCPService" verhalten sollen, manchmal aber auch nicht.
Oder ... oder ... oder....

Glaube mir: Hinter Polymorphie steckt ein langer blutiger Erfahrungsweg mit solchen Lösungen.

Gruß,

Simon2.

Nur zu meinem besseren Verständnis - habe ich das richtig verstanden:

• der Server "besitzt/verweist auf" einen oder mehrere <xyz>-Services (sie erben also NICHT von ihm, sondern er hat einen Zeiger/Referenz/Vektor/... auf sie)
• erben die VClients vom TCPService ? Auch von anderen Services ?
• "VClient verarbeitet einen Vektor von einer Menge von Clienten ..." klingt mir nicht sinnvoll - Entweder IST das Teil ein Client oder es ist ein Clientenverwalter (nur in seltenen Ausnahmefällen/Baumstrukturen trifft beides zu) ... oder steht V für "Verwalter" ?
• TClient erbt von VClient ?
• "(durch vererbung weitergegeben)": Erben Request und Header von TClient ?

hm ne,..andere richtung,..

• TClient erbt von CRequest_Header und CResponse_Header
• VClient erbt nicht von TCPservice
• VClient verwaltet eine Menge von TClient'S
• TClient erbt nicht von VClient

also andere richtung,.... das Organigramm habe ich vlt falsch herum dargestellt,...
grüüüße

werde ich mir mal durch den Kopf gehen lassen.

zeusosc schrieb:

... das Organigramm habe ich vlt falsch herum dargestellt,...

Glaube ich eher nicht. Ich habe schon öfter Probleme damit gehabt, dass ich "oben und unten" (in solchen Diagrammen) anders verstehe als meine Mitmenschen. Es wird wohl eher mein Problem sein.

Gruß,

Simon2.