Dopo tutto, la catena di eredità potrebbe essere qualsiasi cosa: anche Interface<CBase>, anche Interface<C<B<A<CBase>>>>, ci sono tonnellate di varianti. Dovremmo lanciare CBase in modo sequenziale a tutte le possibili varianti, il che non è realistico.
Ricordo che avevo intenzione di implementare la memorizzazione delle informazioni sulle interfacce nell'oggetto classe stesso, e in aggiunta ai pad di interfaccia esistenti per fare classi di interfaccia indipendenti che avrebbero funzionato come un wrapper sopra il nostro pad. Ma poi sono arrivato alla conclusione che tutto questo era inutile e superfluo. In pratica, non ho mai visto la necessità di lanciare una classe base a qualsiasi interfaccia, semplicemente non ha alcun senso. L'unica opzione è scoprire se la classe supporta questa interfaccia per scopi di debug, ma non abbiamo bisogno del casting per questo.
Secondo me, dovremmo memorizzare l'interfaccia nell'interfaccia. Interface<T,CBase>::GetComparer().Compare(CBase &a, T& b); Ho abbozzato del codice per un esempio, ma non voglio davvero ingombrare il forum con troppe lettere.
Secondo me, l'interfaccia dovrebbe essere memorizzata nell'interfaccia stessa. Interface<T,CBase>::GetComparer().Compare(CBase &a, T& b); Ho abbozzato del codice per un esempio, ma non voglio davvero ingombrare il forum con troppe lettere.
Vai avanti e pubblicalo. Comunque, non è spazzatura ma un argomento di discussione. Ma in quel thread da cui la discussione è stata spostata qui, sarebbe inappropriato.
Ah, ho capito, allora hai sbagliato tutto. La classe IComparer nel tuo caso dovrebbe essere come IComparer<T1,T2,CBase>. Di conseguenza, anche il metodo:
virtual Compare(T1 &op1, T2 &op2) = 0;
E quando si eredita la classe si sovraccarica esattamente questo metodo, tutto cadrà al suo posto.
Non ho l'obiettivo di renderlo esattamente come in C#, inoltre, non ho capito in dettaglio come si fa lì. Ma a colpo d'occhio l'IEnumerator di due funzioni reset e next è molto scomodo, sicuramente non lo copierei nella stessa forma )
una funzione virtuale pura è scritta così -virtualeint CompareTo(Number *par) = 0;
il compilatore sarà maledetto al posto del surrogato di eccezione auto-scritto.
Non ho bisogno che il compilatore imprechi perché manipolo costantemente classi di tipo base (Numero in questo esempio). Se il compilatore impreca, il codice non funzionerà affatto
Dopo tutto, la catena di eredità potrebbe essere qualsiasi cosa: anche Interface<CBase>, anche Interface<C<B<A<CBase>>>>, ci sono tonnellate di varianti. Dovremmo lanciare CBase in modo sequenziale a tutte le possibili varianti, il che non è realistico.
Ricordo che avevo intenzione di implementare la memorizzazione delle informazioni sulle interfacce nell'oggetto classe stesso, e in aggiunta ai pad di interfaccia esistenti per fare classi di interfaccia indipendenti che avrebbero funzionato come un wrapper sopra il nostro pad. Ma poi sono arrivato alla conclusione che tutto questo era inutile e superfluo. In pratica, non ho mai visto la necessità di lanciare una classe base a qualsiasi interfaccia, semplicemente non ha alcun senso. L'unica opzione è scoprire se la classe supporta questa interfaccia per scopi di debug, ma non abbiamo bisogno del casting per questo.
Secondo me, dovremmo memorizzare l'interfaccia nell'interfaccia. Interface<T,CBase>::GetComparer().Compare(CBase &a, T& b); Ho abbozzato del codice per un esempio, ma non voglio davvero ingombrare il forum con troppe lettere.
Secondo me, l'interfaccia dovrebbe essere memorizzata nell'interfaccia stessa. Interface<T,CBase>::GetComparer().Compare(CBase &a, T& b); Ho abbozzato del codice per un esempio, ma non voglio davvero ingombrare il forum con troppe lettere.
Vai avanti e pubblicalo. Comunque, non è spazzatura ma un argomento di discussione. Ma in quel thread da cui la discussione è stata spostata qui, sarebbe inappropriato.
ok)
ok)
Perché il metodoIComparer::Compare(CBase &op1, T &op2) esiste se entrambi gli argomenti dovrebbero essere T
E perché esiste il metodoIComparer::Compare(CBase &op1, T &op2) se entrambi gli argomenti devono essere T
È possibile confrontare solo gli stessi tipi? La mia ipotesi è che non lo sia. Fai T==CBase e ci saranno entrambi gli argomenti T )
Ah, ho capito, allora hai sbagliato tutto. La classe IComparer nel tuo caso dovrebbe essere come IComparer<T1,T2,CBase>. Di conseguenza, anche il metodo:
E quando si eredita la classe si sovraccarica esattamente questo metodo, tutto cadrà al suo posto.Ah, capisco, hai sbagliato tutto allora. La classe IComparer nel tuo caso dovrebbe essere come IComparer<T1,T2,CBase>:
E quando si eredita una classe, si sovraccarica questo metodo, tutto andrà a posto.E cosa significa questo CBase? E perché si devono confrontare esattamente 2 valori di un tipo?
cast dinamico per il confronto? Sei fuori di testa?
una funzione virtuale pura è scritta così -virtuale int CompareTo(Number *par) = 0 ;
è il compilatore che sarà maledetto e non il surrogato di eccezione scritto in proprio.
una funzione virtuale pura è scritta così -virtuale int CompareTo(Number *par) = 0;
il compilatore sarà maledetto al posto del surrogato di eccezione auto-scritto.
Non ho bisogno che il compilatore imprechi perché manipolo costantemente classi di tipo base (Numero in questo esempio). Se il compilatore impreca, il codice non funzionerà affatto