Interface-Methoden mit return-Werten vom Typ des Interface?

[para]

queer_boy schrieb:

para schrieb:

An dieser Stelle kommt es nun jedoch vor, dass einzelne Funktionen Objekte vom eigenen Typ zurückliefern

glaub ich dir nicht. dann müsste die funktionsdeklaration nämlich

//statt
IComplex cos();
//heißen:
ComplexAdapter1 cos();
//bzw. 
ComplexAdapter2 cos();

Deswegen schrieb ich auch extra "Pseudocode", der nur der Veranschaulichung der Situation dienen sollte. Trotzdem hast du mit diesem Detail natürlich Recht...

queer_boy schrieb:

die konsequenz bedeutet für dich: es ist in der tat ein IComplex objekt, das von cos zurück gegeben wird, _es gibt_ kein ComplexAdapter1 objekt mehr

Das ist völlig ok und beabsichtigt, da es sich hier um einen Adapter handelt, der per Definition (s.o., "Schnittmenge") nicht über mehr Funktionalitäten als die Schnittstelle verfügt. Diese Konformität nach außen ist ja auch der Sinn eines Interfaces.

queer_boy schrieb:

und du hast jetzt eben das "problem", das IComplex eine rein virtuelle basisklasse ist, bzw. das glück, dass dich der compiler deshalb auf deinen designfehler aufmerksam macht.

Als Designfehler sehe ich das nach wie vor nicht an, und die Frage nach dem "richtig/falsch" wird so einfach sicherlich auch nicht beantwortet werden können. Ein "richtig" ist in Sachen Design schließlich auch eine Frage des Kontextes. Es kann durchaus gute Gründe geben Funktionen wie cos() als eine Art indirekte Eigenschaft einer komplexen Zahl (auf Grund des direkten Bezuges zu ihr) zu betrachten und diese somit zu integrieren, um z.B. im Sinne einer Fassade die wahre Komplexität zu kapseln. Ich benötige hier auch keine Templates, da nicht etwa eine generische Funktion cos() im Vordergrund steht, sondern lediglich die komplexe Zahl...

Wenn ich Software-Architekturen entwerfe, gehe ich i.d.R. zunächst rein theoretisch an die Sache heran. Dummerweise ist in diesem speziellen Fall C++ das Problem, da bspw. Java diese Konstruktion ohne Murren zulässt - leider merkt man das eben u.U. erst bei der Realisierung in einer konkreten Sprache

para

[para]

Simon2 schrieb:

Typischer Fall von "zuviel Java programmiert"

Danke, genau das scheint der Fall zu sein (wahlweise auch c#)

[para]

Andrey schrieb:

wahrscheinlich wieder ein eher sinnloser beitrag, weil ich evtl. das problem gar nicht richtig verstanden habe, aber was solls...

Absolut nicht sinnlos (sowas gibt's nicht)! In einem anderen Kontext hättest du auch Recht, nur ist der Hintergrund hier eben ein anderer (s. vorletzte Antwort von mir) - und so wie's bislang aussieht komme ich in C++ nicht an diesem Weg vorbei und werde somit ein zweites Interface zum adaptieren der Funktionen auf komplexen Zahlen anbieten...

Dank dir,
para

[Artchi]

para schrieb:

Wenn ich Software-Architekturen entwerfe, gehe ich i.d.R. zunächst rein theoretisch an die Sache heran. Dummerweise ist in diesem speziellen Fall C++ das Problem, da bspw. Java diese Konstruktion ohne Murren zulässt - leider merkt man das eben u.U. erst bei der Realisierung in einer konkreten Sprache

Nein, Java lässt das auch nicht zu. Weil du verwechselst leider die Syntax und die Bedeutung.
Sowas hat Java garnicht:

IComplex cos();

Du hast einfach die Syntax aus Java 1:1 auf C++ übertragen, hast aber deren andere Semantik missachtet! Die Syntax in C++ ist eher die hier, wenn man Javas Semantik übertragen will:

IComplex& cos();
// oder
IComplex* cos();

[Andrey]

para schrieb:

Dummerweise ist in diesem speziellen Fall C++ das Problem, da bspw. Java diese Konstruktion ohne Murren zulässt - leider merkt man das eben u.U. erst bei der Realisierung in einer konkreten Sprache

ich hab da mal gestern versucht, ne kleine mathematische spielerei in java zusammenzubasteln, bin beinahe dran verzweifelt, weil es in java nun mal keine zeiger gibt^^ Wie verdammt unterschiedlich die beiden sprachen sind merkt man irgendwie erst dann, wenn man plötzlich von einer zu der anderen wechselt^^

[para]

@Artchi:
Duh! Ich gebe zu, dass da was dran ist. Mea culpa, vielleicht war's heute einfach zu warm und ich sollte mir die Sache nochmal genauer ansehen...

@Andrey:
Da hast ja soo Recht! Als wenn diese beiden dann auch die noch die einzigen wären - ich glaub ich werd langsam alt

[Simon2]

para schrieb:

...Dummerweise ist in diesem speziellen Fall C++ das Problem, da bspw. Java diese Konstruktion ohne Murren zulässt - leider merkt man das eben u.U. erst bei der Realisierung in einer konkreten Sprache

para

Sagen wir mal so: Wenn Du mit der Sprache richtig vertraut wärst, würdest Du merken, dass das in C++ genauso einfach und korrekt umzusetzen ist und Deine Schwierigkeiten mitnichten an der Sprache liegen
Das C++-Pendant zu Java-Referenzen sind nämlich Pointer ! Wenn Du es nun wie in Java abbilden, aber dabei keine Pointer verwenden möchtest, hast Du Dir einfach selbst ein Bein gestellt.

Ist aber nicht besonders tragisch, weil es einer der typischen Umsteigerfehler ist, wie auch hier zu sehen:

Andrey schrieb:

...weil es in java nun mal keine zeiger gibt...

Einfach falsch !!
Es gibt in Java nichts anderes als Zeiger (und primitive Typen) ! Allerdings besteht da eben deswegen keine Notwendigkeit, diese besonders zu kennzeichnen (im Gegensatz zu C++, wo es noch "Variablen" und C++-Referenzen gibt, weswegen man * und & in der Typenbezeichnung braucht).

Gruß,

Simon2.

[para]

Simon2 schrieb:

Sagen wir mal so: Wenn Du mit der Sprache richtig vertraut wärst, würdest Du merken, dass das in C++ genauso einfach und korrekt umzusetzen ist und Deine Schwierigkeiten mitnichten an der Sprache liegen
Das C++-Pendant zu Java-Referenzen sind nämlich Pointer ! Wenn Du es nun wie in Java abbilden, aber dabei keine Pointer verwenden möchtest, hast Du Dir einfach selbst ein Bein gestellt.
Ist aber nicht besonders tragisch, weil es einer der typischen Umsteigerfehler ist

Och, damit habe ich auch kein Problem. Wie ich in meinen letzten Posts bereits schrieb, hatte ich an der Stelle einfach ein "Brett vorm Kopp". Mir sind diese Punkte durchaus bekannt, nur sind sie eben länger nicht mehr abgerufen worden. Zum einen wechseln heute recht häufig meine eingesetzten Sprachen (und C++ hatte die längste Pause) und zum anderen code ich heutzutage auch immer weniger, da sich nur noch alles um Architekturen, Prozesse und Steuern von Consultants dreht. Soll heißen: fast alles entsteht als (UML-) Diagramm, und die konkrete Sprache ist "bloß" eine Nebensache...

Dank euch,
para

[Simon2]

para schrieb:

......
Och, damit habe ich auch kein Problem....

... und es ist großes Kino von Dir, das hier so zu sagen.
Danke !

Ich hoffe, ich konnte Dir helfen.

Gruß,

Simon2.

[Andrey]

Simon2 schrieb:

Andrey schrieb:

...weil es in java nun mal keine zeiger gibt...

Einfach falsch !!
Es gibt in Java nichts anderes als Zeiger (und primitive Typen) ! Allerdings besteht da eben deswegen keine Notwendigkeit, diese besonders zu kennzeichnen (im Gegensatz zu C++, wo es noch "Variablen" und C++-Referenzen gibt, weswegen man * und & in der Typenbezeichnung braucht).

sry, bin ein noob, und verstehe nicht was du meinst...

Ich bin aber 100% sicher, dass man in java niemals irgendwelche pointer auf primitive datentypen herumschieben darf. Ich kann keiner funktion drei pointer auf floats übergeben, sodass sie diese werte verändert. Und mit "pass by reference" geht es da auch nicht.

Dagegen wird _alles_ was in irgendeiner art und weise von "Object" abgeleitet ist nur über referenzen angesprochen, alle möglichen objekte werden also by-reference-gepasst, was in c++ ja wohl wirklich eher einem zeiger entsprechne würde, sodass auch polymorphie gewährleistet ist...

[Simon2]

Andrey schrieb:

...
sry, bin ein noob, und verstehe nicht was du meinst...

Hi,

macht ja nix - ist ja jeder erstmal (und Du hast ja auch schon eine Menge gelernt)

Mal sortieren:
Java-Referenzen kann man

• ins "Leere" zeigen lassen (null)
• casten,
• mal auf dieses, mal auf jenes Objekt zeigen lassen
• ... und dabei "Polymorphie" und Casting betreiben
• kopieren
• mit "new verwenden".

das trifft exakt so af C++-Pointer zu und im Wesentlichen NICHT auf C++-Referenzen (Polymorphie und ein *new mal außenvor gelassen).
C++-Pointer können zusätzlich

• auf "rohen Speicher" zeigen (muss man aber doch ziemlich viel Anstrengung reinstecken)
• Pointerarithmetik auf Arrays (was eine Relikt aus C-Zeiten und den maschinenorientierten C-Arrays geschuldet ist)

Beides Punkte, die man in Java sowieso komplett entfernt hat.
Nichts von alledem kann man in C++ mit "Objektvariablen" (also A a; ) machen.
Deswegen entsprechen IMO Java-Referenzen eben C++-Pointern (und nicht Referenzen oder Objektvariablen).

Dass Java eine Sonderbehandlung für primitive Typen eingeführt hat, finde ich persönlich nicht besonders konsistent und spricht IMO nicht gegen die Analogie.

Außerdem nennt man das, was in Java "call by value" genannt wird, in C++ "call by reference" (eben weil es auch noch einen "value-igeren call" gibt).

Gruß,

Simon2.

[Gast]

Hallo zusammen,

das Problem liegt kurz gesagt darin, dass der Copy-Construktor von dem
Objekttyp aufgerufen wird, der zurückgeliefert wird.
Das ist in dem Fall nicht möglich, da die Klasse wegen der pure virtual
Funktion keinen (public) Copy-Construktor besitzt. Eine einfache Lösung das
Problem zu lösen ist (wie KasF) schon gesagt hat, die Rückgabe eines Zeigers oder
einer Referenz. Wegen der Speicher-Verwaltung würde ich die Kapselung in
einen auto_ptr oder shared_ptr vorschlagen. Wenn du den genauen Rückgabe-Typ
des Objektes kennst, dann weißt du auch den ursprünglichen Objekt-Typ und kannst
eine andere Methode außerhalb des Interfaces aufrufen. (Wenn du ne Unterklassi-
fizierung machen möchtest, machst du halt nen Interface, das von IComplex ableitet
und machst da wieder ne pure virtual Funktion rein.)

Gruß,
CSpille

[Andrey]

Simon2 schrieb:

Außerdem nennt man das, was in Java "call by value" genannt wird, in C++ "call by reference" (eben weil es auch noch einen "value-igeren call" gibt).

jo, solangs um objekte geht. Bei primitiven datentypen gibt es in Java dagegen _nur_ das pure call-by-value, das in c++ ja eigentlich dieselbe bedeutung hat. Meine aussage, dass es in java keine pointer gebe bezog sich genau auf diese primitive datentypen.

Und was diese "Lautverschiebung" (nenn ich das mal so^^ ) angeht, da hast du natürlich recht, das was in Java einafch "call by reference" genannt wird, entspricht nur in der schreibweise eher c++ referenzen, aber verhalten tuen die sich fast wie c++ pointer.

so in etwa...

[Artchi]

Ist das jetzt nicht irgendwie egal, was Java macht und wie das in Java heißt? Für das Lösen der Aufgabe in C++ völlig unerheblich. para muß auch in C++ eine Referenz oder Pointer von IComplex zurück geben, Punkt!

[Gast]

... ( ich glaub, langsam sollte ich mal anfangen java zu lernen ) ...

Edit: syntax->correct();

[Simon2]

Andrey schrieb:

...
jo, solangs um objekte geht. Bei primitiven datentypen gibt es in Java dagegen _nur_ das pure call-by-value,...

Simon2 schrieb:

...
...Dass Java eine Sonderbehandlung für primitive Typen eingeführt hat, finde ich persönlich nicht besonders konsistent und spricht IMO nicht gegen die Analogie....

Andrey schrieb:

...
Meine aussage, dass es in java keine pointer gebe bezog sich genau auf diese primitive datentypen...

Aber Du hast es in einem Kontext gebracht (wie es eigentlich alle Javaisten tun), in dem es um Klassen ging.

Andrey schrieb:

...das was in Java einafch "call by reference" genannt wird, entspricht nur in der schreibweise eher c++ referenzen, aber verhalten tuen die sich fast wie c++ pointer....

Äh - ich dachte, in Java gibt's gar kein "call by reference" ?
Ein wesentlicher Unterschied (den ich hier im Forum gelernt habe) zwischen Java- und C++-Referenzen ist aber noch, dass die C++-Teile keine Variablen sind. Sie werden prinzipiell anders gehandhabt (musst Du Dir mal von camper, CStoll o.a. erklären lassen).
Die "Ähnlichkeit" liegt einfach darin begründet, dass man bei Java nie auf die Referenz selbst, sondern immer nur auf das dahinterliegende Objekt zugreifen kann - da wäre die Verwendung von * ziemlich sinnfrei (Dass in C++ Pointer mit "->" dereferenziert werden können, finde ich auch etwas bedauerlich (auch wenn es den Code lesbarer macht als das "(*)." ), aber ist nunmal so. Wenn's nach mir ginge, könnte man auf Objekte via Zeiger ebenso zugreifen wie über Referenzen).

Gruß,

Simon2.

[Simon2]

Artchi schrieb:

Ist das jetzt nicht irgendwie egal, was Java macht und wie das in Java heißt? ...

Finde ich nicht !
Nicht wenige Fehler von Umsteigern (egal in welche Richtung) resultieren aus der unterschiedlichen Bedeutung identischer Begriffe und ähnlicher Syntax.(die viele Flamewars zu dem Thema auch).
Ich erhoffe mir, dass para und Andere nicht nur den Code irgendwie hinbiegen, damit er funktioniert (und dann mit dem "komisches C++ mit dem ganzen Pointerquatsch"-Gefühl nachhause gehen), sondern die "unterschiedliche Denke" dahinter verstehen - dann begreift man auch das Warum, macht evtl. zukünftig weniger Fehler und schreibt bessere Programme (in der jeweiligen Sprache).

Ich gehöre zwar nicht zu denen, die glauben, jeder Konflikt beruhe lediglich auf einem Mißverständnis, aber ich glaube schon, dass Konflikte oftmals einfacher zu lösen sind, wenn man einander versteht.

Gruß,

Simon2.

[Simon2]

KasF schrieb:

... ( ich glaub, langsam sollte ich mal anfangen java zu lernen ) ...

Edit: syntax->correct();

Mach das mal ! Ist interessant ! Man lernt viel dazu - auch über C++.

Gruß,

Simon2.