Krankhafte Schnittstellen Implementation [.Net 2.0/CppCLI]

[Wütend]

Hi.
Ich probiere hier schon seit Stunden, die Schnittstelle IList<T> zu implementieren, aber das geht nicht, weil die Schnittstelle selbst von ICollection<T>, daher auch von IEnumerable<T> und deshalb dummerweise auch von IEnumerable selbst erbt. Das Problem ist, dass sowohl in IEnumerable, als auch in IEnumerable<T> eine Funktion GetEnumerator definiert ist, welche ich hier implementieren muss. Da sie sich aber nur im Rückgabetyp unterscheiden, lässt es sich aber nicht kompilieren . Was zur ***** soll das? Wie haben es den die schlauen MS Programmierer gemacht, als sie die Schnittstellen in System.Collections.Generic.IList<T> implementiert haben? Dort wurden die Methoden mit dem ganzen Namen implementiert, also System.Collections.IEnumerable.GetEnumerator und System.Collections.Generic.IEnumerator<T>.GetEnumerator, beide als private newslot virtual final instance (in MSIL natürlich ). Wenn ich das mache, motzt der Visual C++ 8.0: "this explicit override syntax requires /clr:oldSyntax"!! Ich hasse sowas... hat einer von euch vielleicht eine Idee, oder nur einen Gedankenanstoss? Wäre sehr froh, denn im I-Net gibts dazu eigentlich kein Material. Vielleicht bin ich aber auch nur zu müde ...

[Gast]

List<T> müsste IList<T> implementiert haben. Ich kann mir nicht vorstellen, dass das unmöglich ist. Eine Unterscheidung im Rückgabetyp ist außerdem legal, wenn der eine Rückgabetyp abgeleitet vom anderen ist. In diesem Fall musst du die Rückgabe des spezielleren Typs implementieren. Viel Glück noch.

P.S. Wenn du mal ne richtig abgef***t designte Klasse sehen willst, dann schau dir mal Systen.Net.Sockets.Socket an.

[*phoenix* 0]

Hi.
Also der wütende Typ war ich...(hatte kurz das PW vergessen :D)
Das Problem ist nicht, dass es nur eine Unterscheidung im Rückgabetyp ist, sondern dass ich gleichzeitig 2 (oder auch 3) Methoden die gleich heissen und die gleiche Signatur haben in einer Klasse implementieren muss. In etwa so:

generic<typename T>
private ref class foo : public IEnumerable<T>
{
public: // Hier gehts los!! :(
        IEnumerator ^GetEnumerator();
        IEnumerator<T> ^GetEnumerator();
}

Ich muss beide implementieren, was ich aber nicht darf, da sie sich aber nur im Rückgabetyp unterscheiden. In der BCL wurde eine spezielle Syntax verwendet, für die ich aber in C++/CLI kein Gegenstück finden kann (und nein: ich KENNE Google ). Mit dem expliziten Overriden von Methoden ist das auch so eine Sache. In diesem Fall lässt sich die Klasse, welche die Schnittstellen direkt implementiert zwar gut kompilieren und benutzen, aber das ist nicht das Ziel. Das Ziel ist es, eine dynamische Collection-Struktur, deren Typen teilweise extern definiert sind, serialisieren zu können. Das ist aber nicht das Problem. Wenn ich explizites member overriding anwende und den Namen auf IEnumerator ^foo, __GetEnumerator, __681add6e_3c78_4aa4_bf4c_18aea88e8c77 oder sonst was stelle, motzt der Compiler in allem abgeleiteten Klassen, dass ich sie nicht instanzieren darf, weil sie abstrakt seien ( sie implementieren GetEnumerator angeblich nicht, aber was bedeutet denn explizites overriden? ). Der Witz ist aber, dass ich GetEnumerator schon in der Basisklasse implementiert habe. Ist das nicht witzig? Bis jetzt habe ich für alle Probleme mit dem neuen .Net 2.0 Framework selbst eine Lösung gefunden, welche gut in die Syntax und Semantik von C++/CLI passen. Ich meine, ich hatte keine Probleme mit der Realisierung sicherer (!) latenter Bindung, generischer Operatoren (also rechnen mit <T>) und Konvertierfunktionen für Generics (also in <T> konvertieren ) aber mit dies hier scheint unmöglich zu sein... und ich dachte es gäbe IMMER einen weg.

In C# habe ich Code gefunden, welcher die Schnittstellen implementiert (jaja der gute Lutz Roeder ), aber in C++/CLI scheint dies nicht möglich zu sein . Ich hab mich vor einigen Stunden mal dran gesetzt und dem Entwicklungsteam geschrieben. Die prüfen das jetzt. Bis morgen werden sie hoffentlich eine Lösung gefunden haben...

mfg

[*phoenix* 0]

Hab jetzt endlich eine Lösung gefunden. Stichwort Mehrfachvererbung .
Hui zum Glück arbeit ich mit C++... schönen Tag noch!

[Gast]

Ähm mit C# muss es ja wohl oder übel auch gegangen sein? Wahrscheinlich reicht Mehrfachvererbung von Schnittstellen schon aus.

[*phoenix* 0]

Schon möglich, aber wenns nicht sofort geht, dann mixe ich mir halt schnell etwas mit unamanged C++ zusammen. Das funktioniert dann meistens . In diesem Fall habe ich die Vererbungsstruktur geändert und einige Unmanaged Klassen eingefügt (Habe mir auch hier vor einiger Zeit eine kleine Lib geschrieben, damit das ohne grosse Probleme funktioniert ). Mit C++/CLI kann man aus unamanged Klassen zum Glück recht einfach auf verwaltete Resourcen zugreifen.