[C#] Sets

[Dax]

Hi Leute

Mir war langweilig, also hab ich mal eine C#-Implementation der aus Delphi bekannten Mengen/Sets versucht. Natürlich ohne Boxung/Unboxing der Elemente, sondern einfach über Generics (Ich war so frech und hab die Sets gleich in den System.Collections.Generic-Namespace getan^^) Deswegen brauchen die Sets auch .net 2

An Operatoren gibts alles was man aus Delphi kennt: +, -, *, <=, >=, != und ==. Zusätzlich hab ich noch XOR als ^ eingefügt Natürlich sind die Sets IEnumerable und IEnumerable<T> sowie ICloneable. IEquatable<Set<T>> nicht zu vergessen

Also alles in allem viel Wind um nichts, wie bei allen meinen Codes

Wenn jemand eine Idee hat, wie man das ganze verbessern könnte - immer her damit

PS: Ihr könntet langsam mal cs als Endung erlauben

Edit: IEquatable sollte ja auf Set<T> sein, nicht <T>

[Elvis]

Zitat von r2c2:

Hm.. also ich seh da 2 mal void...

Was du da siehst ist einmal die wirkliche Methode, und dann 2 mal die explizite implementierung der Interfaces. Welche nur pass throughs der eigentlichen Methode sind.
Ich habe Dax gestern meine Interpretation des originalen Codes geschickt. Wie es aussieht scheint einiges in der jetzigen Version übernommen worden zu sein.

Wenn es die Ästhetik zuließ wurde das generische Interface durch eine öffentliche Methode implizit implementiert, dort wirst du nur 2 Methoden mit ähnlicher Signatur finden. Wenn selbst die generische Interface methode zu hässlich wäre, wurde sie ebenfalls explizit implementiert. Ich bin zum Beispiel kein Fan davon GetEnmerator öffentlich sichtbar zu machen, foreach braucht nur IEnumerable(<T>) aber diese hässeliche Methode bläht Intellisense IMHO nur unnötig auf...

Zitat:

Ich mein sowas:

Code:

public static implicit operator Set(object obj)
{
  Set result = new Set();
  result.Include(obj);
  return result;
}

Is nix weltbewegendes, spart aber n paar Buchstaben...

Sowas ist ganz böse... Implizite Operatoren können durchaus sinnvoll sein, aber sie können sehr schnell Code sehr unübersichtlich machen.
Ein implicit mit einem object parameter macht das Set plötzlich zuweisbar von allen Typen, wodurch man fast sämtliche Compilerprüfung verlieren würde.

Zitat:

Muss dir Recht geben. Werd das % also wahrscheinlich wieder rausnehmen...

Wäre wieder eine Verwendung eines Operators, die absolut nicht eindeutig erichtlich ist.
Wer außer dir wüte was hier passiert?

Zitat:

set3 = set1 % set2;

Zitat:

Ah und nochwas. Wie wärs mit sowas:

Code:

public Set(params T[] items)

Schaue dir die jetzige Version an, ich denke diese meiner Änderungen wurde ebenfalls übernommen.



Gibt es eigentlich irgendeinen Grund für dich mit 1.1 festzusitzen? Kann ich wirklich nicht nachvollziehen.
Immer dieses ekelhafte object-Gefriemel.

[r2c2]

Hallo Elvis

Zitat:

Zitat:

Ich mein sowas:

Code:

public static implicit operator Set(object obj)
{
  Set result = new Set();
  result.Include(obj);
  return result;
}

Is nix weltbewegendes, spart aber n paar Buchstaben...

Sowas ist ganz böse... Implizite Operatoren können durchaus sinnvoll sein, aber sie können sehr schnell Code sehr unübersichtlich machen.
Ein implicit mit einem object parameter macht das Set plötzlich zuweisbar von allen Typen, wodurch man fast sämtliche Compilerprüfung verlieren würde.

Sorry, das kommt davon, wenn zwischendurch der Browser abstürzt. Das mit object war meine Implementierung für .NET 1.1(was ja so nicht geklappt hat). Als ich zum ersten Mal den Post geschrieben hab(je der war schon fertig; und bevor ich ihn abschicken konnte, war alles wieder weg... ), hab ichs glaub ich richtig gehabt, also statt "objet" "T"...
Bei meiner .NET 1.1 implementierung hab ich leider sowieso keine Compiler-Prüfung... Muss also alles zur Laufzeit prüfen...

Zitat:

Zitat:

Ah und nochwas. Wie wärs mit sowas:

Code:

public Set(params T[] items)

Schaue dir die jetzige Version an, ich denke diese meiner Änderungen wurde ebenfalls übernommen.

Guck mir die neue Version gleich mal an...

Zitat:

Gibt es eigentlich irgendeinen Grund für dich mit 1.1 festzusitzen? Kann ich wirklich nicht nachvollziehen.
Immer dieses ekelhafte object-Gefriemel.

Grund 1: Hab noch kein .NET 2.0
Grund2: Hab noch kein VS(mein Cousin verspricht mir jede Woche VS 2005 Express(hab leider nur ISDN...), nur kommt immer was dazwischen...)
Grund3: bin grad am C# lernen und da wollte ich wenigstens was halbwegs Sinnvolles machen, statt Übungsaufgaben, die nachher sowieso nicht mehr angucke...

mfg

Christian

[phXql]

Wofür VS? Nimm einfach SharpDevelop...

[r2c2]

Zitat von phXql:

Wofür VS? Nimm einfach SharpDevelop...

Mach ich auch. Momentan. VS hat aber n paar praktische Features, die #Develop noch nicht hat. Ich muss aber sagen, dass sich #Develop sehr gut entwickelt hat. Hatte mal ne 0.8er Version, mein ich. Die war noch ziemlich buggy. Die jetzige Version ist da schon weitaus besser. Wenn die so weitermachen haben die vielleicht irgendwann VS eingeholt! Nur is das momentan eben noch nicht der Fall...

mfg

Christian

[phXql]

Was hat den VS Express, was SD nicht hat?

[Elvis]

Zitat von phXql:

Was hat den VS Express, was SD nicht hat?

Der Code editor von C# im neuen VS ist fast so gut wie der den man mit dem ReSharper im alten Studio hatte. Nur kostet C#X rein gar nix.
#d ist IMHO die mit Abstand beste IDE, aber nur vom Kern her. Die AddIns und Sprach bindings sind noch lange nicht da wo sie gerade im VS sind.

[Daniel]

Zitat von phXql:

Was hat den VS Express, was SD nicht hat?

Gehört nicht in dieses Thema. Bleibt bitte beim Ausgangsthema.

[phXql]

mkay, sorry..