a me sembra un buon articolo dall’evidente taglio basic. Lo trasformerei in una serie.
Credo che sarebbe utile.
Puntatori 1, basic
Puntatori 2, cominciamo a vedere polimorfismo (es. una factory che restituisce un StdoutLogger piuttosto che un FileLogger), vediamo anche qualche differenza sul campo fra unique e shared (es: personalmente preferisco che la factory restituisca unique)
poi in altri episodi…vediamo gli altri smart pointers, smart pointers nei container, smart pointers e threading ecc. ecc.

P

l’esempio che ti ho postato è accademico in un senso: nessuno alloca SOLO per allocare. Tutt’altro è nel mondo reale, t’assicuro. Magari non ne hai mai sentito il bisogno, ma una mole di dati elevata è all’ordine del giorno soprattutto ora (“big data” è la nuova buzzword). Proprio ora ho scritto un software che utilizza qualche giga di RAM, fai tu!

Fosse una mia opinione, ti lascio con il dubbio: perché hanno usato “new”? Bastava l’allocazione statica sullo stack?

Non voglio poi aggiungere nulla sul fatto che, se usi solo lo stack, non puoi avere una lista (come già detto da altri), ad esempio, di oggetti derivanti da un unico padre. Se pensi alle GUI, al FEM, alle mesh, insomma ci sono milioni di modi in cui dovresti usare l’heap.

à plus!

PS. Non vedi “beginner”, quindi confermi che non vedi alla fine dell’articolo la scritta Tags:basic, containers, puntatori, stl. Puoi dare un riscontro?

Ok, ha senso, ma quindi vuol dire “lasciamo che tutti sbaglino così imparano dai loro errori”? Quindi meglio curare che prevenire? Sono d’accordo che sbagliando si impara, ma penso anche che in contesti con responsabilità e quattrini (e nel software ne girano parecchi) gli errori a volte si pagano caro e a seconda dei settori possono accadere anche cose parecchio spiacevoli (ops, crash del software per la dialisi). Se alcuni strumenti aiutano a prevenire perché non usarli? E quando dico “alcuni” intendo che molte cose, spesso, “fanno brodo”.

Produttività: visto che scrivere software non è una scienza esatta, la produttività (termine di fabbricazione economica) applicata al software è un concetto vago, hai ragione. Mi piace pensare alla produttività come una misura di efficienza, ovvero quanto valore riesci a ottenere in quanto tempo. Cos’è il valore? Questo è l’elemento “vago” del concetto di produttività. Può essere il numero di linee prodotte, può essere il numero di bug fixati, i task completati… Dipende dalle metriche con cui lavori, può essere deciso dall’alto, può essere una convenzione, può anche non esistere proprio. In questi termini anche prevenire un errore è incluso nel fantomatico concetto di produttività. Oppure riuscire a fare una modifica in 2 ore invece che in due giorni.

Mi trovi in perfetta sintonia quando dici che scrivere software è un’attività professionale. Mi paragono sempre ad un “artigiano specializzato”. Non dimentichiamo che con buona probabilità i sistemi software sono i più grandi manufatti di sempre. Sottolineo manufatti, cioè scritti a mano da qualcuno. Lasciamo stare generatori di codice e librerie su librerie che astraggono un po’ di cose. Ed essere specializzati richiede esperienza, formazione, passione (molti l’hanno persa), saper sbagliare, …

Ultima cosa: il software è comunque un business, le responsabilità sono divise, vengono creati diversi layer (tra cui quello di business) e ci lavorano diverse figure professionali. Ha probabilmente senso che esista un business layer che non sappia nulla che sotto ci sono dei puntatori, non lo so. A me piace il controllo del mio software, quindi voglio capire cosa c’è sotto, però mi rendo conto che in molti contesti è complicato. “Aumenterai la produttività e avrai più guadagni” è molto appetitosa per chi fa business o sta su un layer più alto. Ad esempio, se la ditta X fa piccoli giochini per smartphone, forse comprare un game-engine che fa tutto quello che serve è una soluzione sensata e può garantire guadagni elevati. La domanda è sempre: dove sei? Dove vuoi arrivare?

Il mio punto di vista è che sia necessario trasmettere il messaggio che gli strumenti di C++ sono molto diversi da quelli del linguaggio C. Io scrivo ancora assembler oggi (ormai poco su PC, molto di più su microcontrollori) ma questo non mi allontana dagli strumenti più evoluti che offre il nuovo standard con in primis unique_ptr e shared_ptr.

Apprezzo l’articolo di Franco proprio perché è necessario far conoscere i nuovi strumenti e dire chiaramente che C++ e C sono due linguaggi molto diversi, poi starà al lettore decidere se usarli o meno.

“Io sono sicuro che tu non abbia mai avuto problemi di questo genere,”
Io ho poche certezze, invidio te che hai certezze riguardo altri che non conosci.

” il problema è quando lavori in un team perché gli altri purtroppo possono sbagliare”
In qualsiasi mestiere si sbaglia. E anche le persone con esperienza sbagliano, meno frequetemente, se si suppone che imparino dai propri sbagli, ma sicuramente sbagliano anche loro.

“Oppure quando lasci il tuo codice in mano a gente meno in gamba di te, che magari è molto più lenta a manutenerlo, ecc”
Non c’entra il concetto di essere in gamba. C’entra il concetto di quali cose sai per certo. Il team si forma con il tempo. E’ chiaro che un neofita commetter degli sbagli di natura indipendente dal settore e anche (ovviamente) dipendente dal settore. Ma nel team si presuppone che ci siano persone con esperienza più vasta. O, in caso negativo, si presuppone che chi commette uno sbaglio lo riconosca e impari a non ripeterlo.

“Questo solo per dire che nel C++11 ci sono moltissimi strumenti volti a migliorare la produttività singola e di un intero gruppo di lavoro. Se usati bene e nel contesto giusto, gli smart pointer aiutano a scrivere meno codice con anche maggiore livello di sicurezza (e.g. exception safety).”
Non è una questione dell’ X linguaggio, è una questione di approccio. Io so Y e non so T. Cosa consco per certo? e per averlo messo in pratica? limiti? punti di forza?
Attenzione ad usare la parola “produttività”.

“Un’ultima nota: perché usare oggetti allocati sullo heap? Un altro motivo molto semplice: polimorfismo? Classi astratte? Dependency Injection? Puoi ottenere queste cose anche con delle reference, ma il gioco si fa più complicato.”
Stai parlando in generale o di casi particolari? Non ho mai detto che usare la memoria allocata nello heap sia sbagliato o non utile.

Ritorno al concetto di “produttività”.
Cosa vuol dire produttività per marco? la quantità di codice scritto per secondo?
O quanto guadgana la tua azienda per codice scritto?
Occhio che quella parola vuol dire tutto come vuol dire nulla, ma putroppo ha un fore senso commerciale.
I puntatoti intelligenti aumentano la mia produvvitaà? sei sicuro? cioè riesco a produrreo molto più codice di quello che produrrei se non li usassi?
O mi permettono di evitare alcuni errori? (e quindi c’entra poco con la produvvità intesa come quantità di codice scritto).
Se è così, allora posso non ottenere lo stesso effetto se non uso i puntatoiri intelligenti? o serve solo a non farmi pensare a rialsciare la memori allocata, cosa a cui ho pensato quando l’ho allocata?

Siccome il discorso si fa lungo mi limito a dire sottolineare i lseguente fatto.
Mia personale opininone: nel tempo si è sottovalutao il concetto di professionalità nella scrittua di codice. Ci si è dimenticati che chi scrive codice in teoria è un professionista con tanto di studi “universitari” (o lavoro professionale) alle spalle. Non è poi così diverso da uno che progetta un ponte su cui passano migliagia di auto al giorno e quindi con tutta una serie di requisiti. Invece, si è passati da un lavoro professionale con delle responsaibilità, il software architech/designer/developer/engineer (o cioò che più ti aggrada), ad un “smanettone” con tutto il rispetto per gli smanettoni.
Come in tutte le professioni ci vuole esperienza (ottenuta con anni di lavoro)per ottenre degli effetti qualitativi alti e teoria. E occorre anche una forte voglia di imparare dagli sbagli. Pensa un po’ al software, non del dentista sotto casa, ma a quello real time che gira sugli aeroplani.
Oppure ribalta il punto di vista: se ti dicessi “non ti preoccupare, marco, ho notato che nel 99% tu non badi a rilasciare la memoria che esplicitamente hai rischiesto di allocare, ci penso io, tu non ti devi preoccupare, pensa ad altro, concentrati sul tuo business layer, vedrai che aumenterai la tua produttività e avrai più guadagni!”. Mi sembra molto pià appetibile quest’ultima ipotesi non trovi?

P.S. non mi serve il preambolo diplomatico sul “sicuramente tu sei bravo” etc. Mi accontento dell’opinione sui fatti.

non mi aspettavo una risposta celere, quindi personalmente non c’è niente di cui scusarti.
Sarà l’orario ma non sono riuscito a leggere la nota riguardo la natura ‘beginner’ dell’articolo.

“Saturare lo stack è molto semplice, come dice Davide! Se però lo spazio richiesto è molto esiguo, è difficile notarlo.”
Certo, se lo fai a posta come esempio è normale che lo esaurisci. Discorso diverso è l’uso quotidiano dello stack. Quind, stai parlando di un caso specifico o di una prassi quotidiana?

“Io nel mio lavoro ho bisogno di spazi molto grandi, qualche giga, e lo stack muore (almeno nella mia piattaforma), prova anche tu”
Ripeto, a me è capito pochisseme volte su codice facente parte di un programma usato da tantissime persone.
Il discorso è questo, franco.
Se devi fare degli esempi accademici o estremizzare alcuni punti per spiegare un concetto mi va bene, ma se presenti la possibilità di esaurire lo stack come se fosse un cosa che può capitare, con notevole probabilità (coem da tuo articolo), nel lavoro quotidiano (in C++) allora il discorso è diverso.
il concetto di “variabili piccole o grandi” è relativo. Cosa vuol dire variabili piccole o grandi per franco? e la misura è la stessa per sempronio e caio?
Non è una questione dell’articolo ‘beginner’ o avanzato, è che se le cose le tieni per te è un fatt ma se vuoi trasmettere questa tua conoscenza o opinione ad un pubblico potenzialmente vasto devi fare due conti.
Io, personlmante, non punterei sul faftto che l’articolo è breve o ‘advanced’, la cosa che conta è sottolineare che l’ìinformazione da te trasmessa è una tua opinione o è un fatto concretto indipendente da valutazioni soggettive.
Io non sarei capace di scrivere un periodo di senso compiuto in italiano e non mi cimento nel farlo, ma se dovessi farlo mi aspetterei di scrivere cose certe.

“Personalmente non ho mai avuto problemi di memoria non rilasciata quando uso i puntatori o se vuoi i raw pointers. Ovviamente devi usarli nel modo corretto. Ma questo dipende da quanto codice scritto male hai alle spalle.”

Io sono sicuro che tu non abbia mai avuto problemi di questo genere, il problema è quando lavori in un team perché gli altri purtroppo possono sbagliare. Oppure quando lasci il tuo codice in mano a gente meno in gamba di te, che magari è molto più lenta a manutenerlo, ecc.

Questo solo per dire che nel C++11 ci sono moltissimi strumenti volti a migliorare la produttività singola e di un intero gruppo di lavoro. Se usati bene e nel contesto giusto, gli smart pointer aiutano a scrivere meno codice con anche maggiore livello di sicurezza (e.g. exception safety).

Un’ultima nota: perché usare oggetti allocati sullo heap? Un altro motivo molto semplice: polimorfismo? Classi astratte? Dependency Injection? Puoi ottenere queste cose anche con delle reference, ma il gioco si fa più complicato.

Sicuramente in futuro tratteremo anche argomenti più avanzati e ripasseremo per topic già discussi ma con occhio più attento e preciso. Questo articolo, ad esempio, vuole solo essere un’introduzione “leggera” agli smart pointer, al fatto che esistono e i motivi principali per utilizzarli.

Ringrazio nuovamente tutti e, tra l’altro, ricordo che se avete voglia di pubblicare le vostre idee (anche molto avanzate) potete diventare autori e inviarci i vostri contenuti!