Newsgroup: it.comp.lang.c++
Titolo: Google C++ Style Guide

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

 
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

 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

 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

 quando IMHO può avere la sua utilità.
Concordo.
Credo che quelle dei googlers siano linee guida *molto* precauzionali.
Troppo.

Andrea Laforgia ha scritto:

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

 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...

 Non so se Java č il loro obiettivo ...
Non parlavo del caso specifico, ma in generale di alcule linee guida che 
si trovano in giro.

 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

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.

 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?

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.

 "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

 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.

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.

 è 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

Beh, il codice strongly exception safe č proprio costoso.
Dipende da come lo si scrive. 

 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

*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.

 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