Używanie "super" w C++

Zawsze używałem "odziedziczone", a nie super. (Prawdopodobnie ze względu na tło Delphi), i zawsze robię to private, aby uniknąć problemu, gdy 'dziedziczona' jest błędnie pominięta w klasie, ale podklasa próbuje jej użyć.

class MyClass : public MyBase
{
private:  // Prevents erroneous use by other classes.
  typedef MyBase inherited;
...

Mój standardowy 'szablon kodu' do tworzenia nowych klas zawiera typedef, więc nie mam okazji przypadkowo go pominąć.

Nie sądzę, aby przykuta sugestia "super:: super" była dobrym pomysłem - jeśli to robisz, jesteś prawdopodobnie bardzo mocno przywiązany do określonej hierarchii, a zmiana jej prawdopodobnie zepsuje coś źle.

Problem polega na tym, że jeśli zapomnisz (ponownie)zdefiniować super dla klas pochodnych, to każde wywołanie Super::coś będzie dobrze skompilowane, ale prawdopodobnie nie wywoła żądanej funkcji.

Na przykład:

class Base
{
public:  virtual void foo() { ... }
};

class Derived: public Base
{
public:
    typedef Base super;
    virtual void foo()
    {
        super::foo();   // call superclass implementation

        // do other stuff
        ...
    }
};

class DerivedAgain: public Derived
{
public:
    virtual void foo()
    {
        // Call superclass function
        super::foo();    // oops, calls Base::foo() rather than Derived::foo()

        ...
    }
};

(Jak zauważył Martin York w komentarzach do tej odpowiedzi, problem ten można wyeliminować, czyniąc typedef prywatnym, a nie publicznym lub chronionym.)

Fwiw Microsoft dodał rozszerzenie dla _ _ super w swoim kompilatorze.

Super (lub dziedziczona) jest bardzo dobrą rzeczą, ponieważ jeśli chcesz przykleić kolejną warstwę dziedziczenia między bazą a pochodną, musisz tylko zmienić dwie rzeczy: 1. "class Base: foo" i 2. typedef

Jeśli dobrze pamiętam, Komitet Standardów C++ rozważał dodanie do tego słowa kluczowego... dopóki Michael Tiemann nie zauważył, że ta sztuczka na maszynie działa.

Co do dziedziczenia wielokrotnego, skoro jest pod kontrolą programisty możesz robić co chcesz: może super1 i super2, czy co tam.

Nie przypominam sobie, żebym widział to wcześniej, ale na pierwszy rzut oka mi się to podoba. Jak zauważa Ferruccio, to nie działa dobrze w obliczu MI, ale MI jest bardziej wyjątkiem niż regułą i nie ma nic, co mówi, że coś musi być użytecznego wszędzie, aby być użytecznym.

Znalazłem alternatywne obejście. Mam duży problem z podejściem typedef, które mnie dzisiaj ugryzło:

• typedef wymaga dokładnej kopii nazwy klasy. Jeśli ktoś zmieni nazwę klasy, ale nie zmieni typedef, pojawią się problemy.

Więc wymyśliłem lepsze rozwiązanie, używając bardzo prostego szablonu.

template <class C>
struct MakeAlias : C
{ 
    typedef C BaseAlias;
};

Więc teraz, zamiast

class Derived : public Base
{
private:
    typedef Base Super;
};

Masz

class Derived : public MakeAlias<Base>
{
    // Can refer to Base as BaseAlias here
};

W tym przypadku, BaseAlias nie jest prywatne i próbowałem aby uchronić się przed nieostrożnym użyciem, wybierając nazwę typu, która powinna ostrzec innych programistów.

Widziałem ten idiom w wielu kodach i jestem prawie pewien, że widziałem go gdzieś w bibliotekach Boosta. Jednak, o ile pamiętam, najczęściej spotykaną nazwą jest base (lub Base) zamiast super.

Ten idiom jest szczególnie przydatny przy pracy z klasami szablonów. Jako przykład, rozważmy następującą klasę (z prawdziwego projektu):

template <typename TText, typename TSpec>
class Finder<Index<TText, PizzaChili<TSpec> >, PizzaChiliFinder>
    : public Finder<Index<TText, PizzaChili<TSpec> >, Default>
{
    typedef Finder<Index<TText, PizzaChili<TSpec> >, Default> TBase;
    // …
}

Dość często widziałem go używanego, czasami jako super_t, gdy baza jest złożonym typem szablonu (boost::iterator_adaptor robi to na przykład)

czy jest to użycie typedef super common / rare / never seen in the code you work with?

Nigdy nie widziałem tego konkretnego wzorca w kodzie C++, z którym pracuję, ale to nie znaczy, że go nie ma.

czy użycie typedef jest super Ok (tzn. czy widzisz silne czy nie tak silne powody, aby go nie używać)?

Nie pozwala na wielokrotne dziedziczenie(w każdym razie czysto).

Czy "super" powinno być dobre, czy powinno być nieco znormalizowane w C++, a może to użycie przez typedef już wystarczy?

Z wyżej przytoczonego powodu (dziedziczenie wielokrotne), nie Powodem, dla którego widzisz "super" w innych wymienionych językach, jest to, że obsługują one tylko pojedyncze dziedziczenie, więc nie ma wątpliwości, co do tego, do czego odnosi się "super". Oczywiście, w tych językach jest to przydatne, ale tak naprawdę nie ma miejsca w modelu danych C++.

Oh, I FYI: C++ / CLI wspiera tę koncepcję w postaci słowa kluczowego "__super". Proszę. zauważ jednak, że C++ / CLI również nie obsługuje dziedziczenia wielokrotnego.

Dodatkowym powodem, dla którego należy użyć typedef dla superclass, jest używanie złożonych szablonów w dziedziczeniu obiektu.

Na przykład:

template <typename T, size_t C, typename U>
class A
{ ... };

template <typename T>
class B : public A<T,99,T>
{ ... };

W klasie B byłoby idealne, aby mieć typedef dla A, w przeciwnym razie utkniesz powtarzając go wszędzie, gdzie chcesz odwołać się do członków A.

W tych przypadkach może działać również z wieloma dziedziczeniami, ale nie miałbyś typedef o nazwie 'super', nazywałby się 'base_A_t' lub coś w tym stylu to.

--jeffk++

Po migracji z Turbo Pascala do C++ z powrotem w dzień, robiłem to, aby mieć odpowiednik dla Turbo Pascala "dziedziczone" słowo kluczowe, które działa w ten sam sposób. Jednak po programowaniu w c++ na kilka lat przestałem to robić. Okazało się, że po prostu nie potrzebuję go bardzo.

Nie wiem, czy to rzadkie, czy nie, ale na pewno zrobiłem to samo.

Jak już wspomniano, trudność w tworzeniu tej części języka polega na tym, że Klasa korzysta z dziedziczenia wielokrotnego.

Używam tego od czasu do czasu. Kiedy tylko znajdę się wpisując typ klasy podstawowej kilka razy, zastąpię go z typedef podobny do twojego.

Myślę, że może się przydać. Jak mówisz, jeśli twoja klasa bazowa jest szablonem, może zapisać typowanie. Ponadto klasy szablonów mogą przyjmować argumenty, które działają jako zasady działania szablonu. Możesz dowolnie zmieniać typ bazy bez konieczności poprawiania wszystkich odniesień do niej tak długo, jak długo pozostaje interfejs bazy kompatybilny.

Myślę, że użycie przez typedef już wystarczy. I tak nie widzę jak by to było wbudowane w Język, ponieważ wiele dziedziczeń oznacza, że może być wiele klas bazowych, więc możesz wpisać je tak, jak uważasz za odpowiednie dla klasy, którą logicznie uważasz za najważniejszą klasę bazową.

Próbowałem rozwiązać ten sam problem; rzuciłem kilka pomysłów, takich jak użycie różnych szablonów i rozszerzenie pakietu, aby umożliwić dowolną liczbę rodziców, ale zdałem sobie sprawę, że spowoduje to implementację jak 'super0' i 'super1'. Zniszczyłem go, bo to byłoby ledwie bardziej przydatne niż nie posiadanie go na początku.

Moje rozwiązanie zawiera klasę pomocniczą PrimaryParent i jest zaimplementowane tak:

template<typename BaseClass>
class PrimaryParent : virtual public BaseClass
{
protected:
    using super = BaseClass;
public:
    template<typename ...ArgTypes>
    PrimaryParent<BaseClass>(ArgTypes... args) : BaseClass(args...){}
}

Wtedy, które klasy chcesz użyć będzie deklarowane jako takie:

class MyObject : public PrimaryParent<SomeBaseClass>
{
public:
    MyObject() : PrimaryParent<SomeBaseClass>(SomeParams) {}
}

Aby uniknąć konieczności używania dziedziczenia wirtualnego w PrimaryParent na BaseClass, konstruktor przyjmujący zmienną liczbę argumentów jest używany do umożliwienia budowy BaseClass.

Powodem dziedziczenia public BaseClass do PrimaryParent jest umożliwienie MyObject pełnej kontroli nad dziedziczeniem BaseClass pomimo posiadania klasy pomocniczej między nimi.

Oznacza to, że każda klasa, którą chcesz mieć super musi używać klasy pomocniczej PrimaryParent, a każde dziecko może dziedziczyć tylko z jednej klasy używając PrimaryParent (stąd nazwa).

Innym ograniczeniem tej metody jest MyObject może dziedziczyć tylko jedną klasę, która dziedziczy z PrimaryParent, a ta musi być dziedziczona za pomocą PrimaryParent. Oto co mam na myśli:

class SomeOtherBase : public PrimaryParent<Ancestor>{}

class MixinClass {}

//Good
class BaseClass : public PrimaryParent<SomeOtherBase>, public MixinClass
{}


//Not Good (now 'super' is ambiguous)
class MyObject : public PrimaryParent<BaseClass>, public SomeOtherBase{}

//Also Not Good ('super' is again ambiguous)
class MyObject : public PrimaryParent<BaseClass>, public PrimaryParent<SomeOtherBase>{}

Zanim odrzucisz to jako opcję ze względu na pozorną liczbę ograniczeń i fakt, że pomiędzy każdym dziedziczeniem jest klasa średnia, te rzeczy nie są złe.

Dziedziczenie wielokrotne jest silnym narzędziem, ale w w większości przypadków będzie tylko jeden rodzic podstawowy, a jeśli są inni rodzice, prawdopodobnie będą to Klasy Mixin, lub klasy, które nie dziedziczą po PrimaryParent. Jeśli dziedziczenie wielokrotne jest nadal konieczne (choć w wielu sytuacjach korzystniej byłoby użyć kompozycji do zdefiniowania obiektu zamiast dziedziczenia), to tylko jawnie zdefiniuj super w tej klasie i nie Dziedzicz z PrimaryParent.

Oczywiście każda sytuacja jest inna, ale rozważ te rzeczy, które powiedziałem, decydując, którą opcję użyć.

Nie powiem zbyt wiele oprócz obecnego kodu z komentarzami, które pokazują, że super nie oznacza wywołania bazy!

super != base.

W skrócie, co w ogóle znaczy" super"? a co ma znaczyć "baza"?

1. super oznacza, wywołanie ostatniego implementatora metody (Nie metody bazowej)
2. base oznacza wybór, która klasa jest domyślną bazą w dziedziczeniu wielokrotnym.

Te 2 Zasady dotyczą w klasie typedefs.

Rozważmy bibliotekę kto jest super, a kto base?

Aby uzyskać więcej informacji tutaj działa kod do skopiuj wklej do swojego IDE:

#include <iostream>

// Library defiens 4 classes in typical library class hierarchy
class Abstract
{
public:
    virtual void f() = 0;
};

class LibraryBase1 :
    virtual public Abstract
{
public:
    void f() override
    {
        std::cout << "Base1" << std::endl;
    }
};

class LibraryBase2 :
    virtual public Abstract
{
public:
    void f() override
    {
        std::cout << "Base2" << std::endl;
    }
};

class LibraryDerivate :
    public LibraryBase1,
    public LibraryBase2
{
    // base is meaningfull only for this class,
    // this class decides who is my base in multiple inheritance
private:
    using base = LibraryBase1;

protected:
    // this is super! base is not super but base!
    using super = LibraryDerivate;

public:
    void f() override
    {
        std::cout << "I'm super not my Base" << std::endl;
        std::cout << "Calling my *default* base: " << std::endl;
        base::f();
    }
};

// Library user
struct UserBase :
    public LibraryDerivate
{
protected:
    // NOTE: If user overrides f() he must update who is super, in one class before base!
    using super = UserBase; // this typedef is needed only so that most derived version
    // is called, which calls next super in hierarchy.
    // it's not needed here, just saying how to chain "super" calls if needed

    // NOTE: User can't call base, base is a concept private to each class, super is not.
private:
    using base = LibraryDerivate; // example of typedefing base.

};

struct UserDerived :
    public UserBase
{
    // NOTE: to typedef who is super here we would need to specify full name
    // when calling super method, but in this sample is it's not needed.

    // Good super is called, example of good super is last implementor of f()
    // example of bad super is calling base (but which base??)
    void f() override
    {
        super::f();
    }
};

int main()
{
    UserDerived derived;
    // derived calls super implementation because that's what
    // "super" is supposed to mean! super != base
    derived.f();

    // Yes it work with polymorphism!
    Abstract* pUser = new LibraryDerivate;
    pUser->f();

    Abstract* pUserBase = new UserBase;
    pUserBase->f();
}

Kolejnym ważnym punktem jest to:

1. wywołanie polimorficzne: wywołanie w dół
2. super call: rozmowy w górę

Wewnątrz main() używamy polimorficznych wywołań w dół, które Super wywołują w górę, niezbyt przydatne w prawdziwym życiu, ale to pokazuje różnicę.

Używam słowa kluczowego _ _ super. Ale jest specyficzny dla Microsoftu:

Http://msdn.microsoft.com/en-us/library/94dw1w7x.aspx

Jest to metoda, której używam, która używa makr zamiast typedef. Wiem, że nie jest to sposób działania w C++, ale może to być wygodne podczas łączenia iteratorów ze sobą poprzez dziedziczenie, gdy tylko klasa bazowa najdalej w dół hierarchii działa na odziedziczonym offsecie.

Na przykład:

// some header.h

#define CLASS some_iterator
#define SUPER_CLASS some_const_iterator
#define SUPER static_cast<SUPER_CLASS&>(*this)

template<typename T>
class CLASS : SUPER_CLASS {
   typedef CLASS<T> class_type;

   class_type& operator++();
};

template<typename T>
typename CLASS<T>::class_type CLASS<T>::operator++(
   int)
{
   class_type copy = *this;

   // Macro
   ++SUPER;

   // vs

   // Typedef
   // super::operator++();

   return copy;
}

#undef CLASS
#undef SUPER_CLASS
#undef SUPER

Ogólna konfiguracja, której używam, sprawia, że bardzo łatwo jest czytać i kopiować/wklejać między drzewem dziedziczenia, które mają zduplikowany kod, ale muszą być nadpisane, ponieważ Typ powrotu musi pasować do obecnej klasy.

Można by użyć małej litery super do replikacji zachowania widzianego w Javie, ale moim stylem kodowania jest używanie wszystkich wielkich liter w makrach.