Google C++ Style Guide
Andrea Laforgia
GM
> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Questa non l'ho capita (la seconda parte):
Composition is often more appropriate than inheritance. When using
inheritance, make it public.
GM
Tommy
"GM" <G...@no.spam.it> wrote
>> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
>
> Questa non l'ho capita (la seconda parte):
>
> Composition is often more appropriate than inheritance. When using
> inheritance, make it public.
>
> GM
Si riferisce al fatto che in genere si dovrebbe preferire composition
rispetto ad inheritance. Questo per vari motivi elencati in tanti testi tra
cui effective C++ 2005 item 38:
"Item 38: Model "has-a" or "is-implemented-in-terms-of" through
composition."
Il "make it public" si rifersice al public in: class XXXX : public YYYY
Per capire perche' potresti leggere: "Item 39: Use private inheritance
judiciously.", sempre nello stesso libro.
In generale si dovrebbe usare inheritance solo quando c'e' una relationship
di tipo "is-a".
Tommy
GM
>
> Si riferisce al fatto che in genere si dovrebbe preferire composition
> rispetto ad inheritance....
Su questo sono ASSOLUTAMENTE d'accordo.
Quello che non capisco è perché "vietare" di brutto l'eredità privata
quando IMHO può avere la sua utilità. Anzi spesso viene citata come una
"via di mezzo" con la composizione con certi vantaggi (e ovviemante
certi svantaggi). Insomma se sai quello che fai può essere utile e come!
Vedi Es.
http://www.parashift.com/c++-faq-lite/private-inheritance.html
e soprattutto
Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions di Herb Sutter
Item 24. Uses and Abuses of Inheritance
GM
Andrea Laforgia
> Quello che non capisco è perché "vietare" di brutto l'eredità privata
> quando IMHO può avere la sua utilità.
Concordo.
Credo che quelle dei googlers siano linee guida *molto* precauzionali.
Troppo.
GM
A volte ho l'impressione che chi scrive certe "linee guida" dove ci sono
troppi divieti aprioristici in realtà vorrebbe un c++ downgradato verso
java.
Se gli piace java, che usino java!
GM
Andrea Laforgia
> A volte ho l'impressione che chi scrive certe "linee guida" dove ci sono
> troppi divieti aprioristici in realtà vorrebbe un c++ downgradato verso
> java.
> Se gli piace java, che usino java!
Non so se Java è il loro obiettivo (ma conoscendo un po' la situazione
per via indiretta da parte di Alex Martelli, che lavora lì, e qualche
volta ha parlato degli approcci al lavoro di quell'azienda non credo).
Sta di fatto che sicuramente vogliono portare lo sviluppo in C++ da
loro a un livello più basso. Leggendo alcune regole con un collega
abbiamo strabuzzato gli occhi. Non ci riteniamo espertoni di C++, però
il fatto di vietare a priori l'uso delle eccezioni mi sembra sia un
po' troppo. Credo che siano regole un po' troppo vincolanti che non
tengono conto del fatto che il C++, essendo un linguaggio molto
potente, ha applicazioni molto specifiche: ciò che è vantaggioso in un
caso, potrebbe non esserlo in un altro. Tutto va calibrato con cura...
GM
> On 16 Lug, 12:03, GM <G...@no.spam.it> wrote:
>
>> A volte ho l'impressione che chi scrive certe "linee guida" dove ci sono
>> java.
>> Se gli piace java, che usino java!
>
Non parlavo del caso specifico, ma in generale di alcule linee guida che
si trovano in giro.
Enrico Franchi
> Non ci riteniamo espertoni di C++, però
> il fatto di vietare a priori l'uso delle eccezioni mi sembra sia un
> po' troppo. Credo che siano regole un po' troppo vincolanti che non
> tengono conto del fatto che il C++, essendo un linguaggio molto
> potente, ha applicazioni molto specifiche: ciò che è vantaggioso in
> un
> caso, potrebbe non esserlo in un altro.
Da quello che ho capito (parlando con Alex qualche tempo fa) la
sostanza è "usa C++ quando devi *volare* come performance"). Tutto
quello che va "contro" questo (e le eccezioni sono indubbiamente
"relativamente" costose) viene proibito. "Se hai bisogno di roba di più
alto livello, usa Python".
Oltretutto ho pure idea di essere stato parecchio rincoglionito quella
sera, perchè dalla conversazione ricordo che mi avesse detto che
auto_ptr per loro fosse OK (quando sensato usarlo) e *mai* e poi *mai*
usare shared_ptr o qualunque cosa che facesse reference counting,
poichè va contro i principi di località della memoria e rischia di
degradare le performance in modo scarsamente controllabile.
In buona sostanza la regola riportata nel documento analogo dice di
usare con parsimonia shared e di non usare auto. E non avevo ancora
iniziato a bere!
--
Any inaccuracies in this index may be explained by the fact that it has
been sorted with the help of a computer.
Donald Knuth
Andrea Laforgia
<ri...@despammed.com> wrote:
>Da quello che ho capito (parlando con Alex qualche tempo fa) la
>sostanza è "usa C++ quando devi *volare* come performance"). Tutto
>quello che va "contro" questo (e le eccezioni sono indubbiamente
>"relativamente" costose) viene proibito. "Se hai bisogno di roba di più
>alto livello, usa Python".
Dal mio punto di vista questo è opinabile. Il punto è che quando
accadono "conversioni" religiose, si perde un po' obiettività (ricordo
quando - una decina d'anni fa - Alex vantava il C++ come il miglior
linguaggio del mondo). Non che ci sia nulla di male, in questo,
s'intende. Basta saperlo.
Enrico Franchi
> Dal mio punto di vista questo è opinabile. Il punto è che quando
> accadono "conversioni" religiose, si perde un po' obiettività
> (ricordo
> quando - una decina d'anni fa - Alex vantava il C++ come il miglior
> linguaggio del mondo). Non che ci sia nulla di male, in questo,
> s'intende. Basta saperlo.
Si, ma qui non sono coinvolti i punti di vista, ma le policy aziendali.
Che possono essere corrette o meno, avere buoni motivi o meno, ma hanno
poco a che vedere con le opinioni del singolo.
--
It's funny, isn't it? How your best friend can just blow up like that?
Andrea Laforgia
<ri...@despammed.com> wrote:
>Si, ma qui non sono coinvolti i punti di vista, ma le policy aziendali.
Le policy aziendali hanno poco senso se non nascono dai punti di vista
dei singoli.
Davide Quack
> Da quello che ho capito (parlando con Alex qualche tempo fa) la sostanza è
> "usa C++ quando devi *volare* come performance").
Sarei curioso di sapere dove gli serve il C++ a quelli di google. I
loro colli di bottiglia, immmagino io, sono lo storage e subito dopo la
sincronizzazione del loro marchingegno. Non credo che la forza bruta
della CPU sia così cruciale con i loro budget.
Mi pare di aver capito che usano un Linux taroccato, ma la fonte non
era affidabile.
Detto questo, detto da me che NON lavoro con sistemi della complessità
di google mi verrebbe da dire che python + C + asm è la scelta giusta
per loro. Con piccole dosi di C e dosi veramente minime di asm.
--
Articolo 33 della Costituzione italiana: L'arte e la scienza sono
libere e libero ne è l'insegnamento.
Se siete tosti: http://www.rexresearch.com/kervran/kervran.htm
Gabriele Greco
> Le policy aziendali hanno poco senso se non nascono dai punti di vista
> dei singoli.
Spesso nascono in base all'esperienza sul campo (ad esempio gli 80
caratteri di lunghezza massima delle linee, prova a leggere su un
terminale testuale di fortuna del codice a 160 caratteri...).
Per quanto riguarda le eccezioni ho notato in alcuni progetti degli
ultimi anni, in particolare nel codice di programmatori + giovani in
azienda, un abuso di questa facility del C++ che portava il codice a
sparare exception che venivano magari "trappate" a livello altissimo in
quanto non previste e facevano saltare la logica dell'applicazione.
try
K
catch ...
metodo K
a <- spara exception
b
c
Errore molto facile se chi scrive K non sa che a puo` causare exception.
Il problema fondamentale dell'exception e` che sfugge molto piu`
facilmente di un bel core dump in fase di debug, e pure in fase di
deployment se gli effetti non sono nefasti puo` passare inosservata per
troppo tempo.
Andrea Laforgia
<gabrie...@REMOVEUPPERCASETOMAILtin.it> wrote:
>Spesso nascono in base all'esperienza sul campo
Be' sì, praticamente sempre, direi. Alla fine si tratta quasi sempre
di sintesi basate su tonnellate e tonnellate di codice letto e
scritto.
>Per quanto riguarda le eccezioni ho notato in alcuni progetti degli
>ultimi anni, in particolare nel codice di programmatori + giovani in
>azienda, un abuso di questa facility del C++ che portava il codice a
>sparare exception che venivano magari "trappate" a livello altissimo in
>quanto non previste e facevano saltare la logica dell'applicazione.
Secondo me un vero problema di chi usa le eccezioni è che spesso
vengono gestite per controllare il flusso, anziché, appunto, i casi
eccezionali d'errore. Poi, sempre secondo me, non c'è nulla di male
nel far sì che le eccezioni vengano trappate a livello altissimo,
purché ovviamente la logica generale non venga stravolta. In generale,
un codice exception-safe dovrebbe fregarsene altamente di dove vengono
generate le eccezioni. Il problema è che - specie per i principianti -
è difficile scrivere codice del genere.
Enrico Franchi
> In generale,
> un codice exception-safe dovrebbe fregarsene altamente di dove vengono
> generate le eccezioni. Il problema è che - specie per i principianti -
> è difficile scrivere codice del genere.
Beh, il codice strongly exception safe è proprio costoso. Da scrivere e
da eseguire. Oltretutto non sempre è vantaggioso, visto che un qualunque
punto non SE safe rende tutto quello che c'è sopra non SE safe.
Garanzie più blande sulla exception safety sono ovviamente più
facilmente ottenibili.
--
-riko
Andrea Laforgia
Franchi) wrote:
>Beh, il codice strongly exception safe č proprio costoso.
Dipende da come lo si scrive.
Enrico Franchi
> Dipende da come lo si scrive.
Solo nel senso in cui se lo si scrive male è *estremamente* costoso e se
lo si scrive bene è solo molto costoso.
Una funzione Strongly Exception Safe significa che se viene lanciata
un'eccezione è "come se non fosse stata eseguita". Questa è quella che
Meyers chiama la 'strong guarantee'.
Uno dei modi più comuni per offrire la garanzia forte è una strategia di
tipo *copy* and swap. Quando leggo *copy* ovviamente leggo qualcosa che
potrebbe essere costoso, a prescindere di quanto bene scrivi il codice
(ovvero, se è scritto male è *molto* costoso, se scritto bene è solo
costoso). Garantire codice atomico è in generale sempre costoso (salvo
quando è proprio banale).
Ma da solo il copy&swap non offre ancora nulla. Ogni volta che io ho
codice tipo:
{
...
a();
b();
...
}
anche se a() e b() sono SE, se b() lancia un'eccezione, devi avere
qualche sistema per annullare quanto fatto da a(). Questo lo puoi
ottenere con qualche sistema di checkpointing o di logging (nel senso
che si usa parlando di progettazione di database systems -- ovvero del
*backend* --). Tutto questo è *notoriamente* costoso.
Meyers stesso dice che quando è possibile è bene offrire la garanzia
forte, ma di rassegnarsi che di fatto ci sono molti casi in cui
semplicemente è troppo costoso.
E ripeto, buttare su un sistema di checkpointing e farsi copie di tutto
quello che si modifica è un buon modo per definire qualcosa di
*costoso*. Il fatto che poi ci siano applicazioni in cui è necessario
(per esempio proprio nel backend di un database) è un altro discorso.
In molti casi la garanzia base è più conveniente, perchè altrimenti il
tutto diventa troppo lento.
--
-riko
Andrea Laforgia
Franchi) wrote:
>E ripeto, buttare su un sistema di checkpointing e farsi copie di tutto
>quello che si modifica è un buon modo per definire qualcosa di
>*costoso*.
Indubbiamente, ma non vedo altre strade in moltissimi casi. Non
capisco il "troppo" costoso: che alternative hai?
Forse adoperare come si deve il RAII aiuta a gestire le uscite
improvvise, senza preoccuparsi troppo di "farsi copie di tutto quello
che si modifica" in maniera troppo manuale.
Enrico Franchi
> Indubbiamente, ma non vedo altre strade in moltissimi casi. Non
> capisco il "troppo" costoso: che alternative hai?
offrire la basic guarantee invece della strong. in termini di
performance ci può essere un abisso. dipende, come sempre.
--
-riko