Newsgroup: it.comp.lang.c++
Titolo: Conflitto metodo tra base e derivata

Il metodo Lion::Copy nasconde Animal::Copy (vedi sotto), nell'implementazione bisogna ricordarsi di fare una chiamata esplicita anche al metodo della classe base. 
Esiste un disegno migliore per disegnare questi oggetti in modo da non essere proni a dimenticanze ed errori? 
 
 
class Animal
{
public: 
  // ...
  bool Copy(const Animal&)
  {
 
  }
};
 
 
class Lion : public Animal
{
public: 
  // ...
  bool Copy(const Lion&);
 
};
 


forse e' questo che intendevi:
 
In Animal:
virtual bool Copy(const Animal&);
 
In Lion:
bool Copy(const Animal&)override;
 
 
 
Oppure questo:
 
class Animal {
	public:
		using unique_ptr_t=std::unique_ptr<Animal>;
		virtual unique_ptr_t clone()const=0;
 
},
 
 
class Lion : public Animal {
	public:
		unique_ptr_t clone()const override;
};
 


ma perchè il c++ è cosi noioso?
 

Il 25/02/19 09:40, Ronie ha scritto:

E' fatto cosi,e' per gente noiosa
 

 ma perchè il c++ è cosi noioso?
 
E` un linguaggio vecchio, che si porta dietro costrutti vecchi, prolissi e inutilmente complessi. Persino Stroustrup comincia a essere seriamente preoccupato[*]. Se vuoi un consiglio: passa ad altro :)
 
[*]
https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
 
 
 

Il 28/02/19 05:12, 
a.laf...@gmail.com
 ha scritto:

Sara anche vecchio,prolisso e noioso ed inutilmente complesso.
Ma java non e' universale come c++.
Rimane il buon vecchio C ma per progetti complessi non e' adatto.
Alla fin fine occorrerebbe un sostituto che per ora non c'e
Forse Rust in futuro potra esserlo ma per ora non e' cosi
 
 

 Alla fin fine occorrerebbe un sostituto che per ora non c'e
 
Certo che c'e`.
 

Il 28/02/19 07:27, 
a.laf...@gmail.com
 ha scritto:

Se hai un sostituto presentalo ad esempio ai signori che hanno 
progettato Fallout4 per PC
Vediamo se gli va bene.
Ovviamente questo e' solo un esempio,esistono miliardi di righe di 
codice in c++ in giro per il mondo.
Vai da lor signori e offrigli il sostituto.
Se riescono a sopravvivere dinosauri come COBOL e FORTRAN allora mi sa 
che c++ avra ancora lunga vita al dispetto di quello che pensi tu.
 
 

 Se hai un sostituto presentalo[...]
 
Non te ne uscire coi soliti argomenti fantoccio che ti piacciono tanto. Tool come Docker a Kubernetes sono stati scritti in Go. Le alternative a C++ ci sono GIA`. Informati.

Il 28/02/19 10:22, 4ndre4 ha scritto:

Se ci sono alternative come mai e' il linguaggio piu usato al 3/4 posto 
sul pianeta ?
Evidentemente queste alternative non vengono considerate molto.
 

 Evidentemente queste alternative non vengono considerate molto.
 
Evidentemente non ti fai le domande vere: chiediti perche` un tool strausatissimo come Docker ed un orchestrator strausatissimo come Kubernetes sono scritti in Go. Chiediti perche` Prometheus e` scritto in Go. Chiediti perche` Grafana e` scritto in Go. Chiediti perche` Terraform e` scritto in Go. Chiediti perche` etcd e` scritto in Go. E molto altro ancora. Un tempo, C e C++ per quei tool sarebbe stata d'obbligo. 
 
Ma sto parlando arabo per te, vero? 
 
Evidentemente, sei il solito incompetente.
 

Il 28/02/19 10:56, 4ndre4 ha scritto:

Chiediti sto mke2fs perche te lo invio
C++ non ha solo codice legacy (tutti i linguaggi piu usati hanno codice 
legacy in giro per il pianeta)
In c++ sviluppano oggi e se qualcuno ha deciso di fare in Go qualche 
cosa non  significa una beneamata mazza.
Rimane sempre il 3/4 linguaggio usato sul pianeta quindi non ho bisogno 
di chiedermi delle scelte fatte da qualcuno.
Se vuoi saperle rivolgiti a chi a scritto Kubernetes e tutti i tuoi sw 
che ti piacciono tanto.
 
 

 cosa non  significa una beneamata mazza.
 
Certo che conta. Conta alla luce del fatto che un tempo C o C++ sarebbero stati linguaggi eletti per quello. Io lo so benissimo perche` il C++ e` utilizzato ancora oggi. Sei tu che ignori perche` il resto del mondo valuti altre soluzioni per problemi complessissimi come quelli gestiti da Kubernetes. Ma cosa vuoi saperne tu? Sei un language jihadist confinato da secoli in quattro stupidaggini. Cosa ne sai? :)

 Io lo so benissimo perche`
Forse perche' sei uscito dal CEPU?
ROTFL! Non ho mai letto tante stronzate.

On Thursday, 28 February 2019 20:15:04 UTC, acc  wrote:
 
[...]
LOL :) Ma esisti ancora? Tranquillo, non mi aspetto che un certo "acc" comprenda quanto scritto ;)

 Cosa ne sai? :)
 
Ah, l'inossidabile Laforgia, che da più di trent'anni risponde con insulti a
domande che nessuno ha posto.
 
Sull'argomento (che, come al solito, lui stesso ha portato in OT) ci starebbe
pure da parlare: personalmente non ho né la voglia né la forza di rispondere
a chi ovviamente non ha la capacità di comprendere anche semplici testi,
quindi passo.
 
 
Ciao!

 
 
Io non ignoro un beata fava
Se tu che tiri fuori discorsi assurdi sul perche hanno fatto il sw X non 
con c++ ma con linguaggio Y.
Forse vai ad intervistare i progettisti  sul perche hanno scelto Y 
invece che c++ ?
Ovviamente no,le tue sono belle congetture.
Continua a sognare bello che intanto le prestazioni del tuo java non mi 
sembrano cosi entusiasmanti come speravi
E poi sarei io un language jihadist
 

 LOL :) Ma esisti ancora? Tranquillo, non mi aspetto che un certo "acc" comprenda quanto scritto ;)
 
Certo coglione, comprendere non fa parte del tuo dizionario.

 };
 
No così sarebbe stato normale... :)
 
Avevo scritto questo post perché nel progetto che stavo sviluppando, tutte le classi dovevano derivare dalla stessa classe base (come si faceva un tempo con la CObject delle MFC), ma che è stata implementata con dei limiti che causano il problema che ho tentato di esporre. 
 
Una volta che le classi derivate dalla base diventano migliaia, correggere è impossibile. Per questo mi chiedevo se il linguaggio o qualche buona pratica potessero evidenziare/evitare questi problemi prima che diventino una catastrofe. 
 

Il 01/03/19 10:20, _merlinO_ ha scritto:

Allora scusami ma non ho capito bene cosa intendi visto che i due esempi 
da me postati non vanno bene.
 

 da me postati non vanno bene.
 
Purtroppo è passato troppo tempo, credo mi fossi ritrovato in un problema di design creato dalla classe base (non creata da me). Fossero stati metodi virtuali non ci sarebbe stato problema.

Il 02/03/19 11:09, _merlinO_ ha scritto:

Pensandoci forse una cosa di questo genere ?
 
 
class base {
	public:
		void speak() {  pre(); virtual_speak();post();}
	protected:
		virtual void virtual_speak()=0;
	private;
		void pre();
		void post();
};
 
class d : public base {
	protected:
		void virtual_speak() override;
};
 
Evita di chiamare il metodo della classe base