dead

[legacy]

• 

dead

[saimon69]

• 

(1) vuoi dire che il codice malefico qui sopra e' come il tallone di Achille? E se ci scivoli ti ritrovi a fare compagnia a Lucifero?
Niente diavolesse compiacenti? Solo malefiche e nefaste conseguenze, ulteriori motivi per tagliare la barba a Mr Stallman
.P.E.T.I.Z.I.O.N.E.

Se gli vuoi far VERAMENTE male allora devi fargli una pedicure completa

[Nonefonow]

• 

Codice: [Seleziona]

     
     die(); /* Just kidding! Say hAllo to lucifer, you are going to pass through Hell */
}


Da intendersi nel senso letterario della frase, dove Lucifer, dal latino lux e facere = Lucifero, e' infatti il portatore della luce che permette di attraversare l'inferno. 

In ogni caso si puo' fare un reboot.   

[saimon69]

• 

Io Lady Death la vedo come la potenziale fidanzata amata ma gelosa di Lobo, che come farebbero costoro le catastrofi cosmiche quando bisticciano non le fa nessuno...

(e se ricordate anche Deadpool e la trista mietitrice hanno un delizioso quadretto di amore/odio)...

[Z80Fan]

• 

if you're not using the bloated parts of C++, you're not doing it right 

Dov'è che direbbe in quel link di usare le "bloated parts", e in particolare quali sarebbero tali parti?

[Z80Fan]

• 

il commento di un amico 

Beh puoi dire al tuo amico che è un cretino.

ma anche questa discussione

Quella discussione mi rallegra, sapendo che qualche utente con un po' di sale in zucca esiste ancora...
Ti consiglio di stare lontano da chiunque usi frasi tipo "C++ runtime" oppure che usa "C/C++" parlando come se fosse un solo linguaggio; è assai probabile che la persona in questione non conosca nè il C, nè il C++...

[Z80Fan]

• 

In un video di qualche anno fa Stroustrup (dove ha buttato una grande quantità di merda sul C++) ha detto che il C++ non è un linguaggio object oriented ma multi-paradigm (ma questo lo sosteneva già da prima). E questo lo dice in senso molto dispregiativo: non è un vantaggio, per qualsiasi linguaggio.

Ok... quindi? Non vedo cosa c'entra con quello che ho detto sopra... è un fatto noto che fin troppo codice C++ è scritto da persone che non lo conoscono e che non sono familiari con i suoi paradigmi, solo perchè è "simile" a quello che conoscono già: ad esempio programmatori C che lo usano come se fosse C usando al massimo class e const, o programmatori Java che riempiono il codice di puntatori e new/delete manuali invece di usare gli oggetti sullo stack e/o usare le strutture standard...
Questo è terribile specialmente nell'insegnamento, perchè si continuano a perpetrare questi usi sbagliati; non a caso ogni anno, nelle varie conferenze sul linguaggio, c'è sempre un panel che parla su come approcciare l'educazione nonostante la grande disinformazione che c'è già in giro.
Per questo dico di diffidare di chiunque accomuni C e C++ come se fossero lo stesso linguaggio, o due dialetti della stessa cosa.

In più, ti devo chiedere di provvedere un link a tale video o per lo meno il suo titolo, perchè ho visto molte sue presentazioni, e in nessuna "ha buttato una grande quantità di merda sul C++" (a meno che per te "buttare una grande quantità di merda sul C++" significhi discuterne con calma le sue problematiche più che altro storiche e trovare delle soluzioni, nel qual caso è semplicemente una differenza di terminologia tra noi due), e men che meno che essere "multi-paradigm" è una brutta cosa, anzi ricordo proprio l'esatto contrario.

[Nonefonow]

• 

Se c'è una cosa che uno sviluppatore (in particolare un designer) impara nel tempo è il motto reduce complexity, è anche l'obiettivo principale dell'ingegneria in generale, sviluppare ed utilizzare strumenti semplici per risolvere problemi complessi. Un linguaggio multi-paradigm è uno strumento eccessivamente (ed inutilmente) complesso con cui lavorare, questo è anche uno dei motivi per cui Stroustrup gettò fuori quella frase che ho postato prima.

"Reduce Complexity" oltremodo  conosciuta con il principio della parsimonia.  Ovvero non adoperare 3 line di codice se 1 e' abbastanza. 

In diretto contrasto con i metodi + comuni di remunerazione visto che gli sviluppatori sono retribuiti basati sul volume. 

Quanto tempo ci vuole per imparare tale obiettivo?   

[Allanon]

• 

Adesso mi leggo "The Little Go Book" 

[Allanon]

• 

Di questo linguaggio ne avevo sentito parlare, forse addirittura in qualche thread qua su NSA, però non avevo avuto il tempo di approfondire. Ieri ho visto questo bel book di appena 50 pagine e da quel poco che ho letto sembra interessante.
Farò di sicuro qualche esperimento, ho qua una macinino Linux che si sta girando i pollici da qualche mese

[Allanon]

• 

Ecco un'altro "siluro" che devo leggermi  thanks @dsar

[Z80Fan]

• 

Tuttavia nel suo libro The Design and Evolution of C++ (mi pare che qui se ne sia già parlato) trovi "tanta merda buttata" da parte sua.

E' anche vero che la prima (e unica) edizione di quel libro è datata 1994, precedente non solo agli standard del 2011 e 2014 (che è poco dire hanno rivoluzionato il linguaggio), ma addirittura dello standard del 1998 (che è il C++ "classico").
Ottimo come libro di storia; meno per parlare del futuro.

Se c'è una cosa che uno sviluppatore (in particolare un designer) impara nel tempo è il motto reduce complexity, è anche l'obiettivo principale dell'ingegneria in generale, sviluppare ed utilizzare strumenti semplici per risolvere problemi complessi. Un linguaggio multi-paradigm è uno strumento eccessivamente (ed inutilmente) complesso con cui lavorare, questo è anche uno dei motivi per cui Stroustrup gettò fuori quella frase che ho postato prima.

Esatto: strumenti semplici: infatti uno degli  obiettivi principali della STL e in generale di tutta la libreria standard C++ è fornire algoritmi e strutture dati generici, di alte prestazioni e facili da usare. Allo stesso tempo, mette a disposizione strumenti potenti e avanzati per i programmatori di librerie, in modo che possano costruire interfacce (inteso nel senso più generale del termine) con tali caratteristiche e che possano modellare precisamente il problema che sono chiamate a risolvere.

Also, visto che va di moda quotare Stroustrup: VIDEO a 1:23:43 (e puoi anche vedere lui che "spara merda", come dici tu, a 1:17:47) (c'è anche un talk del 2014 dove dice cose simili un po' più aggiornate).

Questa frase mi ha fatto riflettere parecchio, agli ISO committees obbligherei anche la scrittura del compilatore dopo la stesura del loro standard. Vi piace tanto aggiungere feature a i linguaggi? Scrivetelo voi il compilatore. Voglio vedere poi se non fanno una pulizia e semplificazione generale

Fatto: funzioni più nuove del linguaggio o della libreria standard previste per C++17 (ma successo anche per i precedenti 11 e 14) sono già implementate in modo sperimentale da sviluppatori di compilatori (che spesso sono anche quelli che hanno proposto la funzionalità in primo luogo), e anche per le librerie esistono già implementazioni, vuoi perchè sono standardizzazione di librerie già esistenti (molte delle librerie aggiunte in 11, 14 e 17 sono una variante di Boost), oppure perchè sono state sviluppate ex-novo per essere inserite nello standard (come tutta la proposta dei Ranges che è stata proposta e implementate da Eric Niebler - blog, video).

o aggiungere una intera galassia di Razzate al next_step(C), che poi diventa too.bloated.C++

Ancora con 'sta parola: bloated.
Bloated per cosa?

- Bloated per occupazione della memoria? -> falso: un programma C++ non è intrinsecamente più grande di un programma C, anzi può anche essere più corto in quanto fornisce molte più informazioni al compilatore, che così può fare scelte più accurate nella generazione del codice e rimuovere meglio eventuali duplicati.

- Bloated per uso della CPU? -> falso, praticamente per lo stesso motivo di sopra. Esempio classico: std::sort vs qsort

- Bloated nel senso di "verbose", ovvero serve scrivere tanto più codice per fare la stessa cosa? -> falso: grazie sopratutto alla molto più grande libreria standard, algoritmi equivalenti possono essere espressi in molte meno linee di codice in C++ rispetto all'equivalente in C (e sopratutto non serve ogni volta reimplementarsi containers comuni tipo le liste concatenate, o peggio ancora mappe e set).

- Bloated perchè ha moltissime funzionalità? Ovvio che C++ ha più funzionalità del C; sarebbe lo stesso linguaggio altrimenti. Il fatto è che un principiante NON DEVE conoscere TUTTO il linguaggio per usarlo produttivamente: std::vector (che è una classe che implementa un vettore dinamico e ne gestisce automaticamente la memoria) è implementato usando template, classi, move constructors, specializzazioni particolari, overloading degli operatori, allocators e altro ancora, ma per usarlo è sufficiente fare:

std::vector<int> mioVettore;
mioVettore.push_back(42);

Si può dibattere sul fatto che avere molte funzionalità aumenta il pericolo che un programmatore che soffre dell'effetto Dunning-Kruger crei un'accozzaglia di roba inusabile, ma sinceramente, preferisco risolvere questo problema educando i programmatori piuttosto che segare le gambe anche ai programmatori bravi/esperti che le funzionalità sanno quando devono usarle e possono creare interfacce e librerie molto più usabili e espressive di tanti altri linguaggi.

non aggiungono SOLO try/catch() e minime al C, che poi diventa SafeC 

Più che try/catch dovresti mettere try/catch/finally, tipico costrutto necessario a tutti i linguaggi che non hanno un qualche modo per fare il clean-up automatico, ma in generale non faresti altro che sostituire i goto/setjmp/longjmp con un'altro sistema un pelo migliore e più type-safe, ma il problema di ragionare sul percorso di esecuzione del codice rimarrebbe inalterato.

Se c'è una cosa che bisognerebbe aggiungere al C sarebbe proprio un sistema di clean-up automatico, che probabilmente assomiglierebbe alla RAII del C++ (1, 2), che però implicherebbe un anche limitato supporto agli oggetti.
Praticamente si arriverebbe a concludere che, piuttosto che usare C e basta, sarebbe già più conveniente usare il C++ come "C with classes, and RAII".

hypothesizing that 99% of the horrible C errors "caused by pointers" are actually caused by people having to use pointers to manipulate strings (because there is no good alternative.)

Magari il 99% degli errori fosse causato solo dall'usare stringhe...

[Z80Fan]

• 

Chiedo scusa se rispondo in ritardo; in questo fine mese stanno convergendo una serie di avvenimenti e deadline che mi lasciano pochissimo tempo libero... forse devo iniziare a pensare quadridimensionalmente?

I programmatori bravi ed esperti usano un subset molto piccolo del C++

Usano le funzioni che servono in quel momento per implementare quella cosa; cercare di usare sempre tutto in qualsiasi tipo di lavoro, indipendentemente dai requirements e dalle specifiche di progetto è proprio quello che io definirei il comportamento di un cattivo/principiante programmatore.

e ne parlano male praticamente ogni giorno.

Mi sorprende che tu ne parli bene,

Non ne sto "parlando bene", sto solo controbattendo alle tue affermazioni che sono errate o eccessivamente esagerate; non sono qui per vendere un prodotto o "diffondere il verbo", come forse stai pensando.
Se lo scopo della discussione fosse elencare le cose che non mi piacciono del C++ potrei andare avanti per pagine (e mi ricordo bene che in passato non mi sono mai tirato indietro nel criticare); nei pochi anni (circa 8 ) dove ho programmato in questo linguaggio, ho toccato quasi tutte le caratteristiche del linguaggio (sia in progetti "seri" che in miei programmi/librerie personali), e nonostante non sia per niente un esperto, se vuoi possiamo prendere il testo dello standard, andare funzione per funzione e criticarle tutte, ma suppongo che non sarebbe un uso produttivo del tempo, nè per me, ne per te.

Mi sono pure io messo a pensare a un mio linguaggio di programmazione, che prendesse tutte le cose che apprezzo del C++, ne rimuovesse/cambiasse le cose che io (per il settore di programmi che mi trovo a scrivere) uso poco o che vorrei essere fatte in modo diverso, e ne modificasse le funzinalità/sintassi esistenti ma che in qualche altro linguaggio trovo siano fatte meglio; un occhio di riguardo era specialmente verso funzionalità per la programmazione embedded/basso livello, quindi modi di specificare in modo esatto la grandezza di strutture in memoria, gestione di campi di bit etc (Ho proprio sul desktop un grosso documento dove ho inserito tutte le varie idee nel corso degli anni; volevo aprire un thread qui sul forum però (per mancanza di tempo/voglia) non l'ho mai fatto, non so neanche se potrebbe interessare...)

Alla fine però sarebbe stato comunque un YAPL (Yet Another Programming Language), e sapevo bene che, anche se l'avessi descritto formalmente, creato il compilatore (probabilmente un front-end per LLVM), scritto la libreria standard e tutto, sarei comunque l'unica persona che lo userebbe, sarebbe difficilissimo trovare programmatori (anche se, essendo molto simile al C++ moderno, probabilmente in poco tempo uno riuscirebbe a usarlo, essendo pure molto più semplice by-design), e sicuramente non avrei le risorse per andare contro altri linguaggi di grosse compagnie come il succitato Go, ma anche Swift etc. Oltretutto, sarei comunque limitato dai target che supporta LLVM, e auguri ad avere il compilatore per le piattaforme proprietarie (ovvero la maggiorparte degli embedded; già è difficile trovare un compilatore C++, immagina per un linguaggio totalmente sconosciuto!).

Quindi, se uso il C++, è perchè è per me lo strumento migliore (nel senso di meno-peggio) per il settore di cui mi occupo, sia perchè concordo con il modo in cui sono implementate molte funzionalità/librerie, è già molto supportato da una community di milioni di programmatori, ci sono già tantissimi tool disponibili (compilatori/debugger/analizzatori...), e i nuovi standard stanno sistemando molti dei problemi di un tempo.

A proposito di subset ristretto, da quando il team di GCC è passato a C++ ha fatto un coding convention dedicato:

Sono regole ragionevoli, di buon senso diciamo. In realtà sono sorpreso che siano per lo più regole di stile, e non siano più strette: dato che GCC è un progetto preesistente scritto in C, mi immagino che la maggioranza dei programmatori conosca tale linguaggio invece che C++, quindi mi sarei aspettato che avessero messo regole più strette (per impedire l'arrivo dell'omino Dunning-Kruger che dicevo prima).
E' anche vero che GCC, come qualsiasi progetto di grosse dimensioni che si rispetti, ha già tutto un sistema di mantainer e code-review, quindi possono identificare eventuali problemi sul nascere.

e non riesco a scrivere nessun tool, non riesco a scrivere nessun interprete

io sono sempre + convinto che se avessi i mezzi e le risorse (sopratutto le conoscenze) potrei portare a termine il progetto SafeC
ovvero dalla La_maestrina che e' solo una revisione della sotto grammatica C99 del C, ad un vero compilatore con tanto di specifiche
e quelle due o tre feature che a me piacerebbe avere nel C senza scomodare altro

Ma perchè invece di fare tutto da capo, non provi a usare qualcosa di già pronto (anche limitandoti a elaborare solo il C)? Ad esempio conosco libclang, che è una versione "a libreria" del compilatore Clang (che esso stesso è un front-end per C/C++ verso LLVM): tu gli dai il sorgente in input, e lui ti torna tutta l'AST parsata, su cui puoi fare tutte le elaborazioni e controlli del caso. E' una interfaccia in C, quindi puoi usarla con il linguaggio che vuoi; se ti senti avventuroso, esiste anche il wrapper per Python.

Ancora più interessante nel tuo caso, sono i Clang Plugins, che sono dei plugin appunto che vengono aggiunti al compilatore Clang vero e proprio, e permettono, durante la compilazione, di effettuare passate aggiuntive sulla AST generata.
L'idea è che puoi prendere Clang liscio, scrivere plugin_maestrina, e automaticamente, durante la compilazione (quindi niente secondo passaggio che può essere raggirato), eseguire tutti i controlli aggiuntivi che vuoi.
La differenza con libclang è che il plugin è una parte integrante di Clang, quindi deve essere scritto in C++, mentre libclang è in C; in più, se usi i plugin hai "molte più informazioni sulla AST" (così come dice la documentazione, ma non so quali siano tali informazioni) che libclang non mette a disposizione.

C'è anche una versione chiamata LibTooling che però non ho indagato.

Links:
http://clang.llvm.org/docs/index.html
https://kevinaboos.wordpress.com/2013/07/23/clang-tutorial-part-i-introduction/
http://railsware.com/blog/2014/02/28/creation-and-using-clang-plugin-with-xcode/ (specifico per Xcode, ma la maggiorparte delle cose sono le stesse)
https://www.mikeash.com/pyblog/friday-qa-2014-01-24-introduction-to-libclang.html

[Nonefonow]

• 

E lì scoprimmo IBM RPG...

Documentazione e commenti zero, nomi delle variabili indecifrabili, campi e nomi tabelle con frasi totalmente compresse fino all'illeggibilità (tblrted, tbloort, tblkggf, ecc..)

E mi chiedi se avrò tempo?

Su questo mi associo pienamente e mi sento un po' sollevato a sapere che noi non siamo gli unici.  Per un po' pensavo che noi avessimo impiegato dei ritardati.  Ma vedo che era un male comune in quegli anni.

Ma se non hai tempo oer aiutare legacy e hai voglia di divertirti dai un'occhiata  a questo "snip" qua'.
http://www.a-mc.biz/nsa/index.php?topic=3291.msg63076#msg63076

C'ho tempo fine alla fine dell'anno poi il programma verra' "purged".

Dal punto di vista aziendale il problema oraganizzativo risiede nel fatto che si sa' che tutti queste funzioni servono a qualcosa.  A che cosa non si sa.
 
Il batch che gira ogni notte pian piano viene "pulito" e poi dopo una settimana o due di trovi dei casini infernali e si scopre che uno dei programmi che doveva girare era stato rimosso dal batch e cancellato e nessuno riesce a riscriverlo. 

Misteri della scienza che nemmeo gli scienziati riescono a capire. 

[saimon69]

• 

[OT]Te stai a sentire a me, chiama o manda una mail a Gibson che con tutti sti aneddoti ci tira fuori un'altra trilogia cyberpunk come prequel al neuromante, ma fatti pagare le royalty mi raccomando [/OT]