Szablony vs. typy generyczne

0

Witam!
Czy prawdą jest, że jeżeli w klasie w C# mamy przeładowany jakiś operator, to jeżeli klasa ta będzie parametrem jakiejś klasy generycznej i będziemy w tej klasie generycznej używać przeładowanego operatora, to kompilator nie dopuści do tego? I jak to wygląda w szablonach w C++, bo tam chyba kompilator nie zaprotestuje.. Proszę o ewentualne jeszcze jakieś różnice między typami generycznymi, a szablonami.

0

Faktycznie masz rację. Sprawdziłem:

class Liczba
  {
    public int wartosc;

    public static Liczba operator +(Liczba l1, Liczba l2)
    {
      return new Liczba() { wartosc = l1.wartosc + l2.wartosc };
    }
  }

  class Pojemnik<T>
  {
    public T liczba;

    public T Dodaj(T innaLiczba)
    {
      return innaLiczba + liczba; // <- w tym miejscu kompilator protestuje
    }
  }

Prawdopodobnie trzeba przy dekralacji klasy Pojemnik dodać where T: ??? co tu wstawić to nie wiem ;)

0

niestety nie ma jeszcze mozliwosci w where okreslenia ze klasa ma miec zaimplementowany jakis operator

a roznice miedzy typami generycznymi C# a szablonami C++ sa zasadnicze, ale nie bede sie produkowal skoro sam MS o tym napisal
http://msdn.microsoft.com/en-us/library/c6cyy67b.aspx

0

@massther - a ma być taka możliwość? Chyba ciężko byłoby ją wmontować w istniejący język/platformę. Mogli od początku przemyśleć i zrobić jakieś interfejsy czy coś...

kubARek napisał(a)

Prawdopodobnie trzeba przy dekralacji klasy Pojemnik dodać where T: ??? co tu wstawić to nie wiem ;)

Wstawienie czegokolwiek nic nie da. Tak samo jak nie zrobisz generycznej klasy operującej na wbudowanych typach liczbowych.
Generalnie trzeba napisać niezły kawałek klas opakowujących, albo napisać przeciążone wersje metod dla każdego z możliwych typów albo wybrać toporne i niewydajne, ale działające rozwiązanie - typ dynamic.

0

toporne i niewydajne, ale działające rozwiązanie - typ dynamic.
Dlaczego toporne i niewydajne?

0

Bo jest toporne: zmieniac calkowicie model obslugi obiektu ze statycznego na dynamiczny, tylko po to aby wywolac jedna metode operator+, ktora rownie dobrze mozna byloby nazwac Dodaj, umiejscic w interfejsie i po statycznemu by tez dzialalo. Z kolei co innego, jezeli metod tych ma byc gazillion i maja faktycznie sluzyc prostszemu uzywaniu tej klasy, wtedy lepiej wziac dynamic niz tracic czas na pisanie/sprawdzanie pol setki interfejsow

0

dynamic w C# 2010 nie jest wcale dynamiczny, jest statyczny tylko późno wiązany. Nie ma w nim nic strasznego. Co do wydajności, nie sądzę żeby była jakaś widoczna różnica, można to sprawdzić.

0

Dzięki za link: http://msdn.microsoft.com/en-us/library/c6cyy67b.aspx.
Rozjaśnił sprawę. Trochę się zawiodłem. Dość intuicyjnie do tej pory szło, C# wyglądał czysto i klarowanie, utopia runęła :). Nie no trochę przesadzam.. Pozostaje czekać, może zrobią, oby.

0
Azarien napisał(a)

Co do wydajności, nie sądzę żeby była jakaś widoczna różnica, można to sprawdzić.

Obstawiam jakieś 40 - 50 razy.

Tu jest sporo w tym temacie: http://www.codeguru.pl/frmThread.aspx?gid=62&tid=87018, wraz z przykładami rozwiązań.
Szczerze mówiąc nie sądzę, żeby to kiedykolwiek zrobili, skoro nie zrobili tego do tej pory. To chyba najbardziej skopana rzecz w tej technologii.

@down - racja, nie jasno napisałem.
Obstawiam, że operacje na dynamicach są 40-50 razy wolniejsze niż na zwykłych typach liczbowych.
A link dotyczy tematu wątku, jest o typach generycznych i operatorach.

0

hej.. czy mi sie pokrecilo, sadzilem ze dynamic tyczy sie DLR? jesli tak, to to na pewno w koncu zrobia (m.in. python/ruby ich wymagaja, i jest sporo parcia aby w koncu umozliwic im zycie na .Net) i z definicji musi to byc sporo wolniejsze i "late-bound"

edit: nie, nie pokrecilo mi sie

somekind - Azarien nie mowil o dynamicznym emitowaniu IL'a dla nowych metod, ale o słówku kluczowym dynamic oraz o DLR. see http://www.hanselman.com/blog/C4AndTheDynamicKeywordWhirlwindTourAroundNET4AndVisualStudio2010Beta1.aspx, defacto jest to lasnie przyspieszona reflection o ladniejszym zapisie.
...czy "w tym temacie" oznaczalo temat watku?:) w takim razie przepraszam:)

Azarien - przeciez caly sek w tym, ze keyword dynamic formuluje wyrazenia, ktore NIE SA sprawdzane przez kompilator nawet pod katem typow danych, poniewaz dopiero poza runtimem NIE WIADOMO jakiej klasy ani nawet jaka baze/interfejs ten obiekt bedzie implementowal. call jest 100% po string-nazwie i parametrach. to nie jest statyczne, i wcale nie jest 'pozno wiazane'. to, ze kod w ogole sie kompiluje i nazwa funkcji i parametrow jest zapamietana, nie formuluje statycznosci.. to nie jest w ogole wiazane, ew. mozesz to nazwac "wiazaniem na chwile w momencie wywolania". kod w stylu: dynamic ble = X(); ble.Bum(1,2,3), zaleznie od tego co za object zroci funckja X moze wywolywac metody interfejsu COM IIBum::Ble, moze wywolywac stuby do pythona,czy p/invoke, jak i wywolac normalna metode metody o nazwie 'Bum' z dowolnej C# klasy.. Z tego co pamietam, DLR bedzie tez umozliwial jakos modyfikacje w locie definicji klas (ciezko inaczej Ruby sobie na nim wyobrazic) wiec i poznym wiazaniem ciezko to nazwac, bo jego cel mimo udanego pierwszego wizania potem moze sie zmienic i/lub wyparowac..

1 użytkowników online, w tym zalogowanych: 0, gości: 1