Il costrutto o la tecnica di tipo Objective-C in C++?

Question

La funzione di categoria Objective-C consente al programmatore di aggiungere un nuovo metodo che non è stato definito nella definizione di classe originale.

Posso archiviare funzionalità simili (costruzione del linguaggio o tecnica) su C++?

La principale preoccupazione è la sintassi di chiamata del metodo coerente (. o -> operatore).

Answer 1

Consideriamo la seguente classe da estendere:

struct A { 
    int x, y; 
    A(int x, int y) : x(x), y(y) {} 
}; 

È possibile ereditare da questa classe o scrivere una classe wrapper che contiene un'istanza di questa classe. Nella maggior parte dei casi, l'ereditarietà è la strada da percorrere, come una classe wrapper non è una A, ma avvolge (contiene) una A.

Con C++ 11 semantica muoversi, promuovere un'istanza A a una sottoclasse B (ereditando A) sarà efficace e non richiede di copiare l'istanza A:

class B : public A { 
public: 
    B (A &&a) : A(a), someOtherMember(a.x + a.y) {} 

    // added public stuff: 
    int someOtherFunction() const { return someOtherMember; } 

private: 
    // added private stuff: 
    int someOtherMember; 
}; 

codice completo con l'esempio: http://ideone.com/mZLLEu

Naturalmente la funzione aggiungo ed è un po 'sciocco (e il membro ancora di più, dal momento che non rispetta ulteriori cambiamenti dei membri originali x e), ma dovresti avere un'idea di ciò che voglio dimostrare.

Nota il costruttore B (A &&a) che è qualcosa che chiamo "promuovi costruttore" (questo non è un termine standard). Normalmente, move constructor, che sposta il contenuto dell'istanza B fornita in un nuovo B in procinto di essere costruito. Io uso la semantica di spostamento su sposta un'istanza di A (che è stata restituita da un'altra funzione) in la super-classe A di B.

In modo efficace, è possibile promuovere A a B rendendo possibile l'utilizzo di B come A.

In contrasto con la risposta di Soonts, la mia soluzione funziona anche con tabelle virtuali aggiunte, poiché non si basa sul casting puntatore non sicuro.

Answer 2

C++ ha l'ereditarietà per quello. Inoltre, ho usato il seguente trucco un paio di volte a estendere le classi generate da #import "progid: ..." direttiva:

// This one is part of external framework, or auto-generated, or dllimport, or #import, etc.. 
class A 
{ 
    protected double m_x; 
}; 

// This one is the extension class. Make sure you only add non-virtual methods here. 
// Static methods and static data members are OK as well. 
class __declspec(novtable) B: public A 
{ 
public: 
    double getSquare(){ return m_x * m_x; } 
    __declspec(property(get = getSquare)) double square; 
}; 

// Usage example 
double someFunc(A& arg) 
{ 
    B& b = static_cast<B&>(arg); // Note we've not constructed any instance of B, just casted. 
    return b.square; 
} 

Answer 3

Un'altra opzione, che non può essere vista come "pulita" da alcuni (sebbene sia a mio parere) ma che comunque compia la stessa cosa, sta utilizzando una classe statica. È importante ricordare che quando creiamo una funzione membro, ciò che sta realmente accadendo dietro le quinte è che la compilazione genera una funzione in cui l'oggetto (detto anche "questo") è il primo parametro. Quindi, possiamo fare la stessa cosa per estendere le funzionalità della nostra classe senza derivarne.

class Something 
{ 
public: 
    Something() 
    ~Something() 
} 

// In objective-c you may call this category Something+Utils 
class SomethingUtils 
{ 
    // You can use a pointer, or a reference here, your call. 
    static int GetSomethingElse(Something *something, int parameter); 
} 

Questo raggiungerà lo stesso intento come una categoria: si estende la funzionalità del vostro oggetto di classe, e non si deve creare una nuova classe derivata. Non sarai in grado di accedere a funzioni e variabili membro private o protette, ma non lo puoi fare comunque in ogg-c, quindi non c'è nulla di perso su quel fronte (e se stai provando ad usare uno stato membro privato o protetto, tu hai perso completamente il punto delle categorie). Non saresti in grado di usare il. e -> operatori, ma a mio parere, è un compromesso molto meglio che derivare un nuovo tipo solo per aggiungere alcuni metodi di utilità.

Answer 4

ho ottenuto un quasi coerente convenzione di chiamata con an idea I talked about in a lightning talk un anno fa:

(l'intro rende meno senso senza che il commento - ora til si arriva al C++ bit).

Nota che il materiale non era destinato a essere preso sul serio - anche se alcuni, inevitabilmente, hanno ;-)