PDA

View Full Version : PS4: attenzione, un messaggio può bloccare la console


Redazione di Hardware Upg
15-10-2018, 11:01
Link alla notizia: https://gaming.hwupgrade.it/news/videogames/ps4-attenzione-un-messaggio-puo-bloccare-la-console_78537.html

Su Reddit si sta parlando molto del fenomeno, simile ad alcuni casi capitati con gli smartphone. Al momento l'unico modo per prevenire l'inconveniente è impostare PS4 in modo tale da ricevere messaggi privati solo dagli amici

Click sul link per visualizzare la notizia.

fano
15-10-2018, 11:09
Riusciamo ad entrare nel tecnico del perché succede? Il carattere "cuoricino rossiccio" (che perché mai dovrebbe essere un carattere e non un'immagine è inspiegabile per me) cos'ha di speciale? E' uno di quelli che non sta nell'UTF-16 immagino quindi usa "surrogate pairs"?

Come questo possa triggerare un evento così distruttivo che viene interpretato dal kernel come cancellami tutto il S.O. a suon di bastonate?

Titanox2
15-10-2018, 11:11
beh dai notizia tempestiva il problema c'è solo da 2 giorni

jepessen
15-10-2018, 12:04
Sara' perche' io sviluppo in C++, ma a me sta storia dell'unicode e' sempre stata sulle balle… Mi piacerebbe un giorno vedere un bel reset di come vengono gestite le stringhe e fare qualcosa di unico e piu' pulito come avviene in C#, tutte queste codifiche diverse fra ANSI, UTF8, UTF16, ed utilizzando char, wchar_t, LPCTSTR e cosi' via creano solo una gran confusione.. non per niente ci sono un sacco di librerie per gestire sta confusione, come ICU, Boost.Locale e cosi' via; aggiungiamo che in windows si preferisce wchar_t, mentre in Linux si preferisce char...

Insomma, c'e' una gran confusione, e leggere in maniera errata una codifica significa andare a scrivere/leggere in porzioni di memoria che vanno oltre la lunghezza vera e propria della stringa. Un sacco di problemi come questo che ho analizzato e risolto (e anche creato, per carita') sono dovuti a cavolate fatte con le codifiche...

KampMatthew
15-10-2018, 12:07
novella HWU 2000 è concentrato su news ben più importanti, tipo:

La parola 'Android' non è mai stata pronunciata durante l'evento di Google del 9 Ottobre

Ebbè ma se continuano su questa linea significa che i click ci sono :asd:
Evidentemente se non fanno da anni articoli interessanti, scritti bene e che non sia un semplice copia/incolla/mal tradotto significa che questi rendono meglio.

Probabile che le persone questo vogliono e questo gli danno, e non stento a crederci, considerando l'enorme massa di zombie che campano (per modo di dire) tra facebook, twitter, influencer e stronzate varie. Pensa che c'è gente che va a comprare acqua a 8 sacchi a bottiglia perchè tale bottiglia è "griffata" "?" da una tizia che ancora devo capire cosa sa fare oltre che ad approfittare psicologicamente di una massa di decerebrati dove per farne parte il primo requisito è "essere social" altrimenti sei out. Non sei nessuno se a primo mattino non metti su feisbuc un video dove fai vedere cosa mangi a colazione, cosa caghi e non spari almeno 15 foto del tuo volto con le smorfie più idiote che si siano mai viste che poi saranno condivise e ricondivise tra amici, nemici, amanti, finchè per fortuna una di queste foto comparirà sulla bacheca di qualche profilo VIP e allora sarà veramente l'apoteosi perchè tutti ne parleranno, i laic arriveranno a tonnellate, l'ego raggiungerà vette inespolarbili e con i tuoi milioni di amici e follower ti sentirai finalmente padrone della tua vita..e della rete. Si la rete, oramai buona parte degli esseri umani vive sulla rete, e per la rete. La rete si è scatenata, i social si sono scatenati... oramai di questo si campa. :rotfl:

OttoVon
15-10-2018, 12:47
Ebbè ma se continuano su questa linea significa che i click ci sono :asd:
Pensa che c'è gente che va a comprare acqua a 8 sacchi a bottiglia perchè tale bottiglia è "griffata" "?" da una tizia che ancora devo capire cosa sa fare oltre che ad approfittare psicologicamente di una massa di decerebrati dove per farne parte il primo requisito è "essere social" altrimenti sei out.

https://youtu.be/clYHshj6VyU?t=277

ps. questo è uno dei rosik più imbarazzanti che abbia letto...

fano
15-10-2018, 14:08
Sara' perche' io sviluppo in C++, ma a me sta storia dell'unicode e' sempre stata sulle balle… Mi piacerebbe un giorno vedere un bel reset di come vengono gestite le stringhe e fare qualcosa di unico e piu' pulito come avviene in C#, tutte queste codifiche diverse fra ANSI, UTF8, UTF16, ed utilizzando char, wchar_t, LPCTSTR e cosi' via creano solo una gran confusione.. non per niente ci sono un sacco di librerie per gestire sta confusione, come ICU, Boost.Locale e cosi' via; aggiungiamo che in windows si preferisce wchar_t, mentre in Linux si preferisce char...

Insomma, c'e' una gran confusione, e leggere in maniera errata una codifica significa andare a scrivere/leggere in porzioni di memoria che vanno oltre la lunghezza vera e propria della stringa. Un sacco di problemi come questo che ho analizzato e risolto (e anche creato, per carita') sono dovuti a cavolate fatte con le codifiche...

Il problema è che in C/C++ non puoi fare le stringhe giuste (che sì sono quelle di C#, UTF-16 e basta!) perché romperesti la retrocompatibilità con i 50 anni di codice precedente... non è solo Unicode il problema, ma è anche le API che ogni azienda seria si re-implementa substring(), getline(), search() a mano... cose che nella classe string di C# esistono già, ovviamente!

Qui immagino Sony abbia creato una mega applicazione che "nasconde" il S.O. che c'è sotto (Net BSD credo) e sto messanger evidentemente è un thread che fa qualche porcata a botte di puntatori con le "stringe" C/C++ e va a sovrascrivere qualcosa di importante :mbe:

E' triste dover scrivere codice così ancora nel 2018, manco trovo giustificabile scrivere un messanger in C/C++ dai!

KampMatthew
15-10-2018, 15:41
https://youtu.be/clYHshj6VyU?t=277

ps. questo è uno dei rosik più imbarazzanti che abbia letto...


Eh si, vedo ,colpito proprio nel centro. Per me il solo pensarlo che qualcuno possa rosicare per una roba del genere ti inserisce automaticamente nella categoria di cui sopra. Io non credo che ci sia nulla da rosicare, non c'è proprio nulla che mi attira di quel mondo, nè i soldi nè il modo di vivere, nulla, sto benissimo come sto, e se sono arrivato a 50 anni senza avere bisogno di un account feisbuk, probabilmente potrò arrivare senza anche a 100. Dai su, fotografa le bottiglie che hai comprato e mettile in bacheca. :asd:

fano
15-10-2018, 15:54
Io la domanda "imbarazzante" ve la faccio lo stesso un'applicazione come sto "messenger" va davvero scritta in C/C++... magari a Sony fa schifo usare C# (visto che è del suo diretto concorrente), ma poteva usare Java, Python... ma il C, davvero?

Per me è andarsela a cercare, dai...

nexin
15-10-2018, 16:57
Fano, ma di cosa stai parlando? non hai assolutamente idea di quello che dici.

Ma cosa c# concorrente di c++? ma in quale mondo immaginario?

Poi C# non può funzionare sulla ps4, sono sistemi operativi custom. Mica ci può girare la roba Microsoft.

fano
15-10-2018, 17:17
Il sistema operativo di PS4 è semplicemente Net BSD, certo che ci può girare Net Core... anzi mono c'è pure sulla PS4: https://tirania.org/blog/archive/2014/Apr-14.html

Ma lasciamo perdere C# potresti anche usare Python, ma la domanda è ste "app" si devono davvero scrivere in sti linguaggi "unsafe" del 1950 e poi trovarsi colle ":D" che ti sovrascrivono parti del kernel?
Per un po' di "velocità" (parliamo di millisecondi tra C++ e C#!) vogliamo rischiare così la sicurezza?

Questo briccava "solo" la console, ma su PS4 ci possono essere dati sensibili (per dire lo store non è che si salva i dati della vostra Carta di Credito e in un bel char [1024]?) magari il carattere "ometto che si fa uno spinello" si mette a spedirli in giro?

fano
15-10-2018, 19:07
Da quanto tempo programmi in C? Io quasi 20 :eek:

Sì C è unsafe e per quanto riguarda le stringhe parlerei proprio di "design defect" si doveva capire da subito che non avere un tipo dedicato era un errore... e mica c'è bisogno di chissà che di esotico: le stringhe di Pascal erano safe perché il primo byte era la lunghezza della stringa stessa!

Il C non sarà degli anni '50 (iperbole), ma degli anni '70 sì... sono 40 anni! Aveva i "controcazzi" forse a quell'epoca (ma manco tanto Pascal era meglio come già detto), ma ora siamo nel 2018 e almeno se non strettamente necessario andrebbe non più utilizzato!

Su Android puoi programmare in C++ (non Object C che al massimo è su Mac OS) se usi l'NDK e in Java / Dalvik... sinceramente non so se un app Android potrebbe brikare l'intero telefono se scritta in Java.

OttoVon
16-10-2018, 01:55
Eh si, vedo ,colpito proprio nel centro. Per me il solo pensarlo che qualcuno possa rosicare per una roba del genere ti inserisce automaticamente nella categoria di cui sopra. Io non credo che ci sia nulla da rosicare, non c'è proprio nulla che mi attira di quel mondo, nè i soldi nè il modo di vivere, nulla, sto benissimo come sto, e se sono arrivato a 50 anni senza avere bisogno di un account feisbuk, probabilmente potrò arrivare senza anche a 100. Dai su, fotografa le bottiglie che hai comprato e mettile in bacheca. :asd:
#include <OTstream>
//scusate l'OT
int OT(senza flame)
{
Figurati, te lo stavi chiedendo e ti ho postato una risposta che ritengo equilibrata. Non c'è di che.

Continuare a difendertela in modo tanto becero non ti fa onore, lungi da me pensare che tu sia un 50enne fuori corso.
Dico solo, se permetti, che non accettare la possibilità che esistano modi diversi per cavarsela, che non siano il Tuo mestiere, è un filo ottuso.
Probabilmente tra i 91° e i 179° si sta comodi, però a 50 anni stare su un sito come questo a commentare in quel modo, senza informarsi prima di sparare a zero...
lo trovo al pari della categoria da te tanto bistrattata.
Ancora scrivete feisbuk, siete lolli, troppo togo fratè.
Scegliti sta cavolo di scatola B e non rompere più.:D

return IT;
}

KampMatthew
16-10-2018, 07:32
Dico solo, se permetti, che non accettare la possibilità che esistano modi diversi per cavarsela, che non siano il Tuo mestiere, è un filo ottuso.


Questo lo stai dicendo tu, non io. Quello che reputo assurdo è che tantissime persone stanno inchiodate su questi cosiddetti social (che di sociale non hanno nulla) costruendosi una vita vuota e prendendo per modelli di vita persone dalle dubbie qualità che non potranno mai trasmetterti nulla di buono o di utile per la vita reale. Il discorso era iniziato dal fatto che emiliano84 lamentava la qualità delle notizie che oramai da tempo girano su hwp, ed io ho risposto, scherzandoci ed enfatizzando un po', che evidentemente la gente questo tipo di notizie vuole.
Del resto è chiaro che siamo arrivati alla frutta, basta accendere la tv: grande fratello, l'isola dei famosi, barbara d'urso.... certo ognuno guarda quello che vuole e gestisce la sua vita come meglio crede, ma sarò pure libero di pensare che se vai a comprare una bottiglia di normalissima acqua a 8 euro solo perchè qualcuno ci ha messo la sua firma per me sei un decerebrato.

aqua84
16-10-2018, 08:29
basta accendere la tv: grande fratello, l'isola dei famosi, barbara d'urso.... certo ognuno guarda quello che vuole e gestisce la sua vita come meglio crede, ma sarò pure libero di pensare che se vai a comprare una bottiglia di normalissima acqua a 8 euro solo perchè qualcuno ci ha messo la sua firma per me sei un decerebrato.eh... fino ad ora sei (siamo) ancora liberi di pensare quelle cose (tra l'altro a mio parere giustissime), ma stiamo arrivando a dei livelli di falso perbenismo e ipocrisia che tra non molto anche solo pensare certe cose sarà vietato.

se parli male delle persone di colore sei razzista, se li chiami "negri" poi sei da galera.
non puoi dire che a te danno fastidio alcuni atteggiamenti di diversi omosessuali perchè sei omofobo.
se provi a dire che le donne non possono fare certe cose sei uno schifoso maschilista.
se anche solo provi a dire qualche parola in difesa di un Cristiano Ronaldo qualunque facendo notare alcuni chiari e palesi comportamenti della ragazza in questione, diventi anche tu come lui uno stupratore seriale.

a questo siamo arrivati, OGGI.

Riccardo82
16-10-2018, 08:44
su ps4 ci gira eccome c#...

e siamo solo all'inizio ragazzi...

Titanox2
16-10-2018, 08:47
in anteprima per voi: il problema è stato fixato da sony

tanto qui la notizia arriverà come minimo tra una settimana :doh: :D :rolleyes:

OttoVon
16-10-2018, 10:31
eh...

a questo siamo arrivati, OGGI.

A travisare il discorso di chi ti dice che la moda, per le donne, tira quanto un pelo di fica per i maschi.
Vabbè poi il solito minestrone social> popolo> coglioni> sono troppo meglio.

Minestrone che con la moda non c'entra una fava.
Del resto è chiaro che siamo arrivati alla frutta, basta accendere la tv: grande fratello, l'isola dei famosi, barbara d'urso....

Siamo arrivati alla frutta de che? Sono minimo 20 anni che esistono questi programmi, direi meno male che oggi internet sia abbastanza grande e variegato da poter fare sempre meno uso della tv.
Sono programmi pensati per le donne, a loro il chiacchiericcio spicciolo piace. Le modifichiamo geneticamente?!
Prodotti come l'acqua che citi, sono sempre esistiti.
Scendere in piazza a manifestare non ha senso e ti fa fare la figura del "manzo da social" che segue uno scandalo senza saperne nulla.
Scandalo... parola leggermente inflazionata.

ps. In generale la penso come te, infatti sono felice che spendano 8€ per l'acqua o 1750€ per un telefono.

GTKM
16-10-2018, 17:43
Diciamo che troppo spesso si nasconde l'incompetenza degli sviluppatori dietro la difficoltà di alcuni linguaggi.

È il motivo per cui, in fondo, esistono cancri come il JavaScript per lo sviluppo di applicazioni desktop.

cdimauro
17-10-2018, 14:32
Verissimo.
E oltretutto sono anni che sento dire "c è vecchio", "c++ ha i memory leak".
E poi guardi i sorgenti, e non esiste nemmeno traccia di raii. Se uno vuole fare cazzate, le fa in qualsiasi linguaggio.
Bisogna vedere che tipo di cazzate. Di bug intermittenti dovuti ad accessi sbagliati alla memoria o di use-after-delete è difficile averne in Python, e sto parlando dei bug più rognosi che uno sviluppatore generalmente ha a che fare.
Poi, il c, di per se', non ha stringhe. ha char (cioe' byte, che possono essere stampati come caratteri) e array di char.
stringhe, niente. la gestione delle stringhe viene fatta da una libreria, che non ha niente a che fare con il linguaggio in se'.
se uno ha bisogno di unicode, o stringhe a lunghezza determinata non dal null, ha altre opzioni.
Tutti i linguaggi in genere hanno una libreria standard annessa, per cui se una certa, comune, funzionalità non te la offre il linguaggio di per sé, dovrebbe metterla a disposizione la libreria standard. Al massimo una libreria di terze parti che viene comunemente usata.
senza parlare che diversi linguaggi piu' recenti sono delle vere merde.
la questione e': il c, e il suo "derivato" c++, sono nati da gente con i coglioni (e infatti una parte enorme dei linguaggi piu' moderni hanno preso parecchio da c/c++, e comunque il c++ e' ancora splendido ancora oggi. con le giuste librerie fa tutto e di piu', eccetto le webapp), altri linguaggi (qualcuno ha detto JS?) sono nati da coglioni e basta.
Mi spiace, ma dissento. Cos'hanno portato di innovativo C e C++ che altri linguaggi non offrissero già?

C è ben noto essere nato per consentire di scrivere velocemente codice, dove persino il simbolo d'assegnazione è stato scelto per pura analisi statistica (un solo tasto da premere).

C++ è nato per correggere diversi difetti del primo, e quindi già questo dimostrerebbe che la "gente coi coglioni" non abbia fatto un gran lavoro (cosa alquanto banale da dimostrare, peraltro, visto che devi ricorrere al PREPROCESSORE semplicemente per... definire delle costanti!). Aggiungendo poi un po' di roba che altri linguaggi offrivano già.

Poi che ci siano altri linguaggi che, PERSONALMENTE, mi fanno venire l'orticaria solo a guardarli, beh, è anche normale.
Per ritornare in parte IT: con qualsiasi linguaggio si possono gestire stringhe unicode, bastano le librerie giuste.
ovvio che se uno pretende di usare il c liscio per l'utf, allora e' masochista.
Anche con le librerie giuste bisogna avere una certa qual vena masochistica...
Potro' sbagliare, ma il "difetto" di c, e c++, e' che non perdonano lo sviluppatore. se uno e' incompetente, ti massacrano.
se programmi alla cazzo di cane, o alla "stackoverflow-dipendente", ti distruggono. diventano delle bombe a tempo, che prima o poi esploderanno lasciandoti nella merda piu' nera. se non li studi, lasciali perdere, non li impari con wikipedia.
Quindi mi stai dicendo che migliaia di sviluppatori che usano C/C++ e che sbagliano anch'essi, sono degli incompetenti. Anche se lavorano per Google, Microsoft, Apple, Intel, ecc..

Signori, qui ci troviamo davanti alla prossima medaglia Fields: lo sviluppatore che ha trovato il modo di scrivere sempre codice corretto, e che fa le pernacchie a gente che viene profumatamente pagata...
ma se li sai usare, e sei competente, allora diventano dei gioielli che non hanno niente da invidiare a linguaggi piu' moderni (anzi: se togliessero ruby, python, js, go, con il c++ si potrebbero sostituire, ma provate a sostituire il c++ con JS o python. ovvio, poi per le webapp, usare c++ e' una spina nel c***)
Ma certo. Ti vorrei vedere a sviluppare in C++ alcuni dei miei "scriptini" Python. Soprattutto sarebbe interessante vedere quanto c'impiegheresti.

Non è che, invece, magari scegli un certo linguaggio in base al tipo di problema che devi risolvere, e che ti consente di farlo col miglior compromesso?

Io non scrivo un s.o. in Python. Ma se devo realizzare un programma che raccolga statistiche su qualche milionata di istruzioni x86/x64 disassemblate da qualche eseguibile, impiego di gran lunga prima a scriverlo e vedere i risultati in Python (per quanto lenta sia la sua esecuzione) che in C++.

Ma magari mi sbaglio anche in questo, eh! Felice di essere smentito, in caso... :O

cdimauro
17-10-2018, 14:34
ogni volta che sento javascript, un programmatore muore

ogni volta che sento JavaScript per lo sviluppo di applicazioni desktop, un'intero reparto IT muore
https://sealedabstract.com/wp-content/uploads/2013/05/JavaScript-the-good-parts.jpg

cdimauro
17-10-2018, 14:56
:asd: avevo già visto questi libri su internet...ma esistono veramente???
Sì sì. E' proprio questo il bello. :asd:

GTKM
17-10-2018, 14:59
Bisogna vedere che tipo di cazzate. Di bug intermittenti dovuti ad accessi sbagliati alla memoria o di use-after-delete è difficile averne in Python, e sto parlando dei bug più rognosi che uno sviluppatore generalmente ha a che fare.

Tutti i linguaggi in genere hanno una libreria standard annessa, per cui se una certa, comune, funzionalità non te la offre il linguaggio di per sé, dovrebbe metterla a disposizione la libreria standard. Al massimo una libreria di terze parti che viene comunemente usata.

Mi spiace, ma dissento. Cos'hanno portato di innovativo C e C++ che altri linguaggi non offrissero già?

C è ben noto essere nato per consentire di scrivere velocemente codice, dove persino il simbolo d'assegnazione è stato scelto per pura analisi statistica (un solo tasto da premere).

C++ è nato per correggere diversi difetti del primo, e quindi già questo dimostrerebbe che la "gente coi coglioni" non abbia fatto un gran lavoro (cosa alquanto banale da dimostrare, peraltro, visto che devi ricorrere al PREPROCESSORE semplicemente per... definire delle costanti!). Aggiungendo poi un po' di roba che altri linguaggi offrivano già.

Poi che ci siano altri linguaggi che, PERSONALMENTE, mi fanno venire l'orticaria solo a guardarli, beh, è anche normale.

Anche con le librerie giuste bisogna avere una certa qual vena masochistica...

Quindi mi stai dicendo che migliaia di sviluppatori che usano C/C++ e che sbagliano anch'essi, sono degli incompetenti. Anche se lavorano per Google, Microsoft, Apple, Intel, ecc..

Signori, qui ci troviamo davanti alla prossima medaglia Fields: lo sviluppatore che ha trovato il modo di scrivere sempre codice corretto, e che fa le pernacchie a gente che viene profumatamente pagata...

Ma certo. Ti vorrei vedere a sviluppare in C++ alcuni dei miei "scriptini" Python. Soprattutto sarebbe interessante vedere quanto c'impiegheresti.

Non è che, invece, magari scegli un certo linguaggio in base al tipo di problema che devi risolvere, e che ti consente di farlo col miglior compromesso?

Io non scrivo un s.o. in Python. Ma se devo realizzare un programma che raccolga statistiche su qualche milionata di istruzioni x86/x64 disassemblate da qualche eseguibile, impiego di gran lunga prima a scriverlo e vedere i risultati in Python (per quanto lenta sia la sua esecuzione) che in C++.

Ma magari mi sbaglio anche in questo, eh! Felice di essere smentito, in caso... :O

Infatti un altro dei problemi è non usare il linguaggio giusto per la giusta occasione.

Ad esempio, JavaScript andava bene per quello per cui era stato pensato. È invece una porcata anche solo immaginare di realizzare applicazioni desktop dovendoti portare dietro un browser. Ma ripeto, questo è dovuto al voler far credere che chiunque possa realizzare buon software.

Comunque, anche pensare di scrivere una GUI in C è un'idea bizzarra. :D lo dico da utilizzatore assiduo di tale linguaggio.

cdimauro
17-10-2018, 16:00
Infatti un altro dei problemi è non usare il linguaggio giusto per la giusta occasione.

Ad esempio, JavaScript andava bene per quello per cui era stato pensato. È invece una porcata anche solo immaginare di realizzare applicazioni desktop dovendoti portare dietro un browser. Ma ripeto, questo è dovuto al voler far credere che chiunque possa realizzare buon software.
IMO Javascript non andava bene nemmeno per quello per cui era pensato, ma qui sono chiaramente "biased". :D
Comunque, anche pensare di scrivere una GUI in C è un'idea bizzarra. :D lo dico da utilizzatore assiduo di tale linguaggio.
L'hanno già fatto: dai un'occhiata a GNOME e, specificamente, a glib. :doh:
Disclaimer antiflame: nella vita di tutti i giorni uso Python, TCL(lol), Matlab e qualche volta C/C++ e vivo bene. E non reputo che C# sia un brutto linguaggio. Ma la silver bullet non esiste.
E' quel che dicevo prima, infatti: si usa lo strumento che si presta "meglio" per un determinato compito.

Nessuna polemica anche da parte mia. Non era questo lo scopo del mio commento: è solo che non ce l'ho fatta proprio a lasciar passare quel che era stato scritto.
Il C e il C++ hanno scopi e filosofie differenti anche se il secondo e' praticamente un superseed del primo. Il primo e' minimalista, il secondo e' quasi 'batteries included'. Non e' che uno dei due e' migliore. A seconda di quello che devi fare e' meglio C, C++ oppure <inserisci qui un linguaggio X>. Il non avere molte librerie nello standard e' voluto e non accidentale. Per quello c'e' C++, che cresce ad ogni versione.
C si porta già dietro un bel po' di librerie standard: il suo problema è che ha avuto una lenta evoluzione, perché per qualcosa di più complesso c'era C++.

Sia chiaro: il minimalismo di C, a livello di linguaggio, mi sta abbastanza bene, per gli ambiti in cui è ancora usato.
:confused: Ehm. Nella sezione 2.4 del K&R 'The C Programming Language' 2a versione c'e scritto come definire le costanti -senza usare il preprocessore-
Qui, però, parli già di ANSI C, e non più C K&R. Io mi riferivo a quest'ultimo, che non aveva/ha né const come keyword, né tanto meno enum, che si usano in genere per definire delle costanti, in modo più o meno comodo.

Senza const ed enum eri costretto ad andare a colpi di #define (che peraltro sono ampiamente usate proprio in quella sezione del libro. Chiaro retaggio delle origini del linguaggio, IMO), con tutte le problematiche del caso.
Python e' estremamente comodo.. ci penso ogni volta che devo modificare degli script TCL :muro: .
A chi lo dici. Quando ero alla Intel avrei dovuto scrivere dei test in TCL, per le estensioni al GDB che sviluppavamo. Roba da non dormirci la notte (anche perché i test di GDB sono script TCL che hanno MONTAGNE di regex :cry: :muro: ). Ho preferito scrivermi un mini-framework in Python allo scopo, e usarlo per una nuova test suite: ho impiegato di gran lunga meno tempo, e quel codice è molto più facilmente leggibile e manutenibile. :cool:
La scorsa estate ho fatto un contest in cui doveva essere scritto un programma che generasse istruzioni per una VM. Python si e' rivelato una scelta piu' che azzeccata. :cool:
Questo lo lasciamo come esercizio a chi vuole cimentarsi con una versione C o C++. ;)

GTKM
17-10-2018, 16:16
Grazie. Non lo sapevo. Quando ho iniziato a programmare ovviamente ANSI C si era gia' diffuso da un pezzo.

In realtà il C di K&R, soprattutto inizialmente, era disastroso. Anche le funzioni, per dire, non erano esattamente come adesso.

Comunque tutt'oggi le direttive #define sono ovunque.

cdimauro
17-10-2018, 16:47
>Bisogna vedere che tipo di cazzate. Di bug intermittenti dovuti ad accessi sbagliati alla memoria o di use-after-delete è difficile averne in Python, e sto parlando dei bug più rognosi che uno sviluppatore generalmente ha a che fare.

anche con il c++. basta pensare prima di scrivere il codice, e possibilmente non scrivere a cazzo. ovvio che se cominci a portarti in giro puntatori come se non ci fosse un domani, te li vai a cercare.
ma se usi il cervello, non e' cosi' complicato avere codice robusto. gli strumenti ci sono tutti per evitare in gran parte della cazzate.
ma se la gente continua a fare le cose alla cazzo, non e' colpa del linguaggio.
E' sempre la solita storia: è colpa del linguaggio. Però i bug, anche rognosi, chissà come mai saltano fuori anche da gente che il linguaggio lo conosce benissimo.
>Tutti i linguaggi in genere hanno una libreria standard annessa, per cui se una certa, comune, funzionalità non te la offre il linguaggio di per sé, dovrebbe metterla a disposizione la libreria standard. Al massimo una libreria di terze parti che viene comunemente usata.

libreria standard vuol dire "questo e' lo standard, ma puoi usare altre librerie".
ad esempio in passato ho avuto bisogno di tipi di dato decimal su c++, e
ci sono, e di ottima qualita'.
Non mi pare di aver detto qualcosa in contrario.
>Mi spiace, ma dissento. Cos'hanno portato di innovativo C e C++ che altri linguaggi non offrissero già?

ehm... quali altri linguaggi? il c ha una versatilita' che, al tempo, gli altri linguaggi si sognavano.
Non hai risposto alla mia domanda.
basta dire che, dopo pochi anni dalla sua introduzione, quasi tutte le aziende lo hanno valutato (e molto spesso adottato), per usi che prima richiedevano o l'assembler o linguaggi non adeguati.
guarda in che linguaggio sono stati scritti sistemi operativi, pacchetti software (da autocad, a office), una marea di utility, a soluzioni custom. tu in che linguaggio li avresti fatti, nei primi anni 70? in cobol, basic, pl1, o fortran?
guarda quanti linguaggi sono sopravvissuti dagli anni 70, cobol, lisp, fortran, basic. e basta
Perché il C si è diffuso ed è diventato lo standard di fatto in quegli ambiti, ma s.o. e software di basso livello venivano già ampiamente scritti con altri linguaggi.

Come già detto, C è nato per scrivere velocemente codice, senza tanti fronzoli, per velocizzare la scrittura di Unix (e da lì in poi anche per altri s.o. o roba di basso livello). Questo non perché lo dico io, ma gli stessi autori del linguaggio.
>C è ben noto essere nato per consentire di scrivere velocemente codice, dove persino il simbolo d'assegnazione è stato scelto per pura analisi statistica (un solo tasto da premere).

non e' cosi', e stato creato per essere flessibile e portabile.
tanto e' vero che il suo sviluppo e' stato parallelo a quello di unix.
Quello che t'ho riportato è un aneddoto raccontato dai creatori del linguaggio. Almeno loro dovrebbero saperlo, no?
>C++ è nato per correggere diversi difetti del primo, e quindi già questo dimostrerebbe che la "gente coi coglioni" non abbia fatto un gran lavoro (cosa alquanto banale da dimostrare, peraltro, visto che devi ricorrere al PREPROCESSORE semplicemente per... definire delle costanti!). Aggiungendo poi un po' di roba che altri linguaggi offrivano già.

scusa, quali difetti?
e' vero che il c++ non e' un "c con gli oggetti", ma di difetti grossi non ne ho mai visti.
Si vede che non hai usato altri linguaggi. Intanto, come dicevo prima, non aveva nemmeno la definizione delle costanti, poi:
- tipizzazione debole;
- assenza di riferimenti;
- assenza del concetto di modulo (devi ricorrere anche qui al famigerato preprocessore usando #include, e all'interno di questi sfilze di #ifdef o #if per evitare ridefinizioni et similia);
- assenza di un vero tipo stringa;
- assenza di costrutti di più alto livello (non solo stringhe, dunque).

Questi sono quelli che personalmente reputo grossi difetti, ma potrebbero essercene altri.
Poi, abbi pazienza, ma dire gente come tanenbaum e ritchie non abbia fatto un gran lavoro, no, non lo accetto assolutamente.
Scusami, ma che c'entra Tanenbaum adesso? Mica l'ha inventato (anche) lui il C... :doh:
e se cosi' non fosse, come mai quasi tutti i linguaggi piu' "moderni" derivano dal c?
Ma che stai a dire? Scusa, ma quanti altri linguaggi conosci, oltre a C e C++?
negli anni 60 ritchie ha tirato fuori un linguaggio
E' del '72.
che ancora ora e' usato, ed e' sempre stato considerato, pur con tutti i suoi difetti, perfetto da hacker,
Che ormai da tempo preferiscono Python. :D
per usi embedded,
Che da tempo si sta spostando verso il C++.
per alte prestazioni,
Fortran è ancora molto usato per questo.
per mille usi "dietro le quinte".
Senz'altro, e come già detto lo apprezzo pure, eh! Mica sono un hater del C: quando mi serve lo uso...
dire che non ha fatto un gran lavoro, e' assolutamente ridicolo.
Purtroppo direi proprio di no, e scusami se questa mia opinione cozzi con la tua, ma ho anch'io le mie brave ragioni per affermarlo.
e' stato forse il piu' grande genio che la storia dell'informatica abbia avuto.
E' un grande, ma non credo che si possa considerare il più grande. Personalmente nutro una stima maggiore per Turing, Knuth, Wirth.
Il preprocessore e' parte delle specifiche del c, visto che c'e', e' stato usato per le costanti. non che sia una figata, ma non lo vedo certo come un grosso difetto.
Certo che è una parte delle specifiche del C: senza quello vorrei ben vedere quanto sarebbe stato utile e utilizzato il C.

Anche gli assembler fanno pesante uso del preprocessore, e per il solito motivo: compensare le lacune che hanno a livello di linguaggio...
>Anche con le librerie giuste bisogna avere una certa qual vena masochistica...

e perche'? io ho usato librerie simili, e funzionano bene.
se devi lavorare, ad esempio, con i db, non e' che puoi usare solo ascii, eh
Che funzionino bene per il C, non faccio fatica a crederlo. Ma altri linguaggi mettono a disposizioni strumenti ben più comodi (e qui rientriamo nel discorso di prima: per risolvere certi problemi è meglio scegliere lo strumento "migliore").
> Quindi mi stai dicendo che migliaia di sviluppatori che usano C/C++ e che sbagliano anch'essi, sono degli incompetenti. Anche se lavorano per Google, Microsoft, Apple, Intel, ecc..

il mio discorso non era quello. intendevo che se sei uno che e' appena appena in grado di usare un ide, lascia perdere il c/c++.
se invece sei ben strutturato mentalmente, il c non da' grosse difficolta'.
Le difficoltà col C le hanno anche quelli che lo conoscono bene, come dicevo prima.
>Signori, qui ci troviamo davanti alla prossima medaglia Fields: lo sviluppatore che ha trovato il modo di scrivere sempre codice corretto, e che fa le pernacchie a gente che viene profumatamente pagata...

prima leggere, poi comprendere, e poi eventualmente rispondere ti pare brutto?
si evitano figuracce, sai.
Vedi sopra: non cambia di una virgola il discorso. Anche programmatori molto esperti scrivono codice con bug rognosi. Capita. Specialmente con linguaggi che danno la libertà/possibilità di farlo.
e poi, se parliamo di medaglie, fossi in te, dopo aver scritto che tanenbaum e ritchie non hanno fatto un gran lavoro, eviterei proprio di parlare.
dire certe cose su due geni assoluti, e' da premio oscar.
Intanto Tanenbaum non c'entra niente.

Su Richie ho già detto che è stato un grande.

Ciò, però, non implica che per questo abbia fatto un gran lavoro col C. Logica spicciola alla mano...
>Ma certo. Ti vorrei vedere a sviluppare in C++ alcuni dei miei "scriptini" Python. Soprattutto sarebbe interessante vedere quanto c'impiegheresti.

ok, allora vediamo come saresti in grado di buttar giu' codice in python che faccia le stesse cose che fanno alcuni miei sorgenti in c++.
il mio discorso era la flessibilita' di un linguaggio.
python e' ottimo per certe cose, e io non ho mai scritto diversamente, ma la flessibilita' e' media, non eccellente.
Premesso che, come dicevo, per determinati problemi si scegli lo strumento migliore, a livello puramente implementativo Python è di gran lunga più flessibile e produttivo di C e C++.

E' molto probabile che i tuoi sorgenti in C++ li scriverei molto più velocemente in Python. Partendo dalle specifiche: i sorgenti in C++ non li voglio nemmeno vedere, perché mi farebbero soltanto perdere tempo.
oltretutto, dopo decenni di utilizzo, ci sono librerie per qualsiasi cosa ti venga in mente, per il c, e ti tolgono una marea di rogne e lavoro.
Anche per altri linguaggi. E generalmente gli altri linguaggi consentono di usare librerie scritte in C (o altri linguaggi: l'importante è esporre un'interfaccia standard)
>Non è che, invece, magari scegli un certo linguaggio in base al tipo di problema che devi risolvere, e che ti consente di farlo col miglior compromesso?

Ho scritto "se togliessero".
non c'entra niente col discorso che stai facendo.
Se togliessero ci sarebbero sicuramente altri linguaggi a occupare lo stesso ruolo. Come c'erano anche prima del C, che come dicevo non ha portato alcun contributo alla letteratura informatica.

P.S. Scusa, ma non ho tempo di rileggere. Tanto dovrebbe capirsi lo stesso.

cdimauro
17-10-2018, 20:41
Grazie. Non lo sapevo. Quando ho iniziato a programmare ovviamente ANSI C si era gia' diffuso da un pezzo.
In realtà il C di K&R, soprattutto inizialmente, era disastroso. Anche le funzioni, per dire, non erano esattamente come adesso.

Comunque tutt'oggi le direttive #define sono ovunque.
Esattamente. Passare dal K&R all'ANSI C è stato già un bel passo avanti, anche se è rimasta la brutta abitudine di continuare a definire le constanti con le #define nonostante la keyword const.
* . Il problema piu' grosso IHMO e' che e' passato da semplice linguaggio per fare 'qualche ritocco estetico', ad essere necessario per fare tutto e di piu' nel mondo web-based in cui viviamo. Io spero ancora lo tolgano 'progressivamente' di mezzo nei prossimi anni con l'avvento di webasm. A quel punto chiunque potra' usare quel che gli pare come linguaggio web client side.
Ma infatti io tifo proprio per quello: che webassembly si diffonda più velocemente possibile, soprattutto come adozione standard da parte dei browser più diffusi.

Così finalmente si potrà usare il linguaggio che si vuole anche per il weeeebbbe.
Ah beh. Alla fine usare i define rimane il metodo piu' comodo per definire costanti globali che vengono incluse in piu' unita' di compilazione :fagiano: .
Francamente preferisco usare il preprocessore il meno possibile (in genere per la definizione di simboli e relative #ifdef / #if. Molto più raramente per delle macro), se il linguaggio offre già dei costrutti sintattici.

Poi, sia chiaro, è una questione di gusti.

cdimauro
17-10-2018, 21:31
verissimo. pero' i bug rognosi ci sono sempre in qualsiasi linguaggio.
ho perso giorni e giorni a trovare bug in sorgenti cobol, fai tu.
Sì, i bug rognosi ci sono anche in altri linguaggi, ma quelli prodotti da C/C++ lo sono di più. Ci sarà un motivo per cui sono stati inventati Java, C#, Go, e per ultimo Rust, no? E cito questi perché a livello sintattico sono abbastanza ispirati a C/C++.
e' stato creato con in mente la flessibilita' e la portabilita'.
e in quei tempi, era davvero notevole, visto che anche con pl1, rpg e cobol ho visto robe che di portabile avevano niente.
Guarda che il C è decisamente poco portabile come linguaggio: più utilizzi costrutti di basso livello, e meno portabile diventa.

Quanto alla flessibilità, non è chiaro tu cosa intenda.

Comunque se recupero l'intervista ai suoi creatori che parlano di come sia nato il linguaggio la posto, anche se mi pare difficile (potrei averla letta una trentina d'anni fa, fra le riviste d'informatica dell'epoca).
praticamente tutti i tool, i compilatori, i pacchetti e via dicendo (quindi non roba scritta in casa), erano assembler. portabilita' zero.
Ma anche no: ce n'era diversi scritti in linguaggi di alto livello. Persino su Amiga è stato usato il BCPL, predecessore del C, per scrivere l'AmigaDOS.
Arriva il c e ti permette di scrivere, con certi criteri, software portabili.
e oltretutto andando a sfruttare al massimo la macchina.
Intanto sulla portabilità vedi sopra. Poi proprio se vuoi sfruttare meglio la macchina ti tocca scrivere codice non portabile in C (o portabile, ma a colpi di #ifdef et similia).
non confondiamo la velocita' di scrittura (cioe' produttivita') con la velocita' stile "buttare giu'".
La velocità di scrittura è proprio "buttare giù" il codice nel minor tempo possibile.

Poi che questo sia produttivo è, invece, tutt'altro che scontato. Difatti le due cose non sono strettamente collegate.
la velocita' di scrittura ha permesso, come sopra, di fare UN sorgente per N macchine, invece che N sorgenti. questo intendeva come velocita' di scrittura.
E questo lo si faceva già con altri linguaggi di alto livello.
mi dispiace per te, invece si. e forse anche qualcuno che tu non hai mai usato.
Cobol ammetto di non averlo usato (anche se gli ho dato un'occhiata 35 anni fa circa). Per il resto ho usato o studiato diversi linguaggi, spaziando da quello macchina al Prolog.
e come ti hanno detto prima, per le costanti non serviva nemmeno il preprocessore
Su questo ho già ampiamente risposto. E mi sa che, a questo punto, tu debba essere abbastanza giovincello da non aver mai usato il C K&R, perché altrimenti non avresti scritto questa cosa. Pretendi di conoscere il C, ma non ne conosci nemmeno le origini, che poi era esattamente ciò a cui mi sono sempre riferito finora, inclusa la mia domanda a cui continui a non voler dare una precisa risposta.
tipizzazione debole non e' per forza un difetto.
Lo è, perché è fonte di bug. Se hai una tipizzazione forte già a priori certe porcate non le puoi fare.
il tipo stringa esiste. non sara' il migliore come feature, ma e' molto veloce.
e a quei tempi era molto importante.
Il C NON ha un tipo stringa. Quello che offre è soltanto dello zucchero sintattico per inizializzare o passare come parametro un vettore di caratteri. Nient'altro.

Quanto alla velocità di cui parli, è del tutto falso, visto che per conoscere la lunghezza di una stringa (operazione abbastanza comune) devi per forza scorrertela tutta fino alla fine. :doh:
i moduli? si chiamano librerie, si usano ancora oggi. se usi unix, le stai usando.
e personalmente non mi fanno rimpiangere altri sistemi piu' moderni.
funzionano, e vanno benissimo.
E meno male che hai detto di conoscere diversi linguaggi. No, il concetto di modulo è ben diverso, e c'è persino un linguaggio che ce l'ha per nome, proprio per rimarcarlo.
Poi c'e' UNA ifdef all'inizio di un modulo.
Quella #ifdef la piazzi TU, programmatore, su UN sorgente C che verrà compilato come oggetto.

Il che non ha NULLA a che vedere col concetto di modulo di cui parlavo.
costrutti di alto livello? ci sono le union e le struct.
e questo, per un linguaggio non OO, e' tutto quello che e' possibile avere.
Forse perché oltre a C non conosci altri linguaggi. Eccone uno che è stato pubblicato 2 anni PRIMA e che era ben fornito di costrutti di alto livello:
https://en.wikipedia.org/wiki/Pascal_(programming_language)#Language_constructs
poi, parlando di python... oddio...
Beh, parlane pure: qual è il problema?
io le mani me le sporco con qualsiasi linguaggio.
se ci fosse da fare un sw per cui e' adatto il python, mi sporcherei le mani col python.
ma non voler vedere il c++, e' parecchio limitante.
sinceramente poi non capisco il "perdere tempo".
ti dessero da controllare un sorgente java, non lo toccheresti?
Tranquillo: ho messo le mani in pasta ovunque.

Semplicemente se devo dimostrare la produttività di Python, preferisco partire dalle condizioni iniziali: avere le specifiche del progetto, e lavorarci direttamente. Che dovrebbe essere quello che hai fatto tu coi tuoi progetti C/C++, giusto? O li hai convertiti da linguaggi come Python?
Errore mio, ho confuso stourtroup con tanenbaum
Stroustrup l'ho conosciuto personalmente a un seminario che tenne alla New York University nel '95 (se non ricordo male), quando all'epoca girava per presentare la neonata stdlib del C++.

Alla fine del seminario ci fu un sorteggio con alcuni premi. Vinsi un biglietto per la successiva conferenza sul C++, ma siccome di natura sono molto fortunato :asd: dovetti rinunciare perché sarei stato già in Italia. Avrei preferito di gran lunga vincere il suo libro autografato. :cry:
ancora?
vai a vedere da chi hanno preso spunto java, go, rust, python e JS.
Scusami, ma in cosa avrebbe preso spunto Python dal C? Dalla presenza dell'operatore != per disuguaglianza (fino alla versione 2.7 del linguaggio c'era anche <>, che da pascaliano preferivo nettamente)?

Quanto ai primi 3 che hai citato, chiediti perché si sia sentito il bisogno di crearli anziché continuare a usare C (magari evolvendolo) o il C++.
Ha cominciato nel 69
Conta quando ha rilasciato il linguaggio pubblicamente, e altri programmatori hanno cominciato a poterlo usare.

Anch'io ho scritto dei linguaggi di programmazione (HLA, per essere precisi) più di 20 anni fa, ma non li ho mai pubblicati e ovviamente a parte me nessuno li ha mai potuti usare. Se li pubblicassi adesso, citando il '96 come anno di inizio mi renderei soltanto ridicolo.
seh, come no. voglio proprio vedere uno che fa hacking con il python.
E niente, continui a parlare di cose che non conosci. Fatti una ricerchina su qualche hackcon, guardati un po' di talk, e vedi cosa utilizzano gli hacker moderni come strumenti per il loro lavoro.

Oppure fai prima a dare un'occhiata a questo:
https://www.amazon.it/Black-Hat-Python-Programming-Pentesters/dp/1593275900

E a metterti l'anima in pace.
definisci "molto".
http://www.treccani.it/vocabolario/molto/

Per il resto Fortran rimane il linguaggio più usato in ambito HPC, con grossi nomi che continuano a usarlo. E i compilatori Fortran sono rinomati per offrire le prestazioni più elevate in quest'ambito.
io non ho mai detto il contrario.
a me ha dato fastidio la storia del "premio fields". se si discute in maniera corretta, ok, altrimenti personalmente lascio perdere.
Guarda hai sbagliato TU quando hai preteso di far passare gli altri programmatori come degli inetti.

Considerate le lacune che hai dimostrato finora, sei l'ultimo che se lo possa permettere.

cdimauro
17-10-2018, 22:09
Un paio di post che capitano a fagiolo:
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=42894&forum=17#817713
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=42894&forum=17#817715

fano
18-10-2018, 09:07
Non era mia intenzione comunque dire che K&R erano degli inetti il C negli anni '70 era una gran cosa, insomma sempre meglio che scrivere Unix tutto in ASM sul PDP-11!
Ma appunto aveva senso negli anni '70 con un processore che a quanto andava? 1 MHz?

Riguardo poi le "leased string" (stringhe con lunghezza incorporata) non sono nulla di più che questo:


typedef struct {
size_t size;
const char *value;
} leased_str_t;


certo ogni volta che fai una copia devi verificare la size della stringa di destinazione e se fai str[x] dovresti di nuovo verificare che x sia <= size, ma almeno per il primo caso ogni libreria C come si deve lo dove fare... mica puoi davvero usare sprintf() giusto? Si deve SEMPRE usare snprintf()... quindi fai sempre una strlen() che è una ricerca dentro tutta la stringa del byte col valore 0x00 che è sicuramente più lenta che accedere al campo size[1].

Aggiungo un altra cosa riguardante C#, il CLR impone che ogni accesso agli array sia buond checked è vero, ma il compilatore è libero di cambiare il codice durante l'ottimizzazione quando può dimostrare oltre ogni dubbio che è safe farlo per esempio questo for:


for (int i = 0; i < arr.Len; i++) {
arr[i] = 0;
}


non avrà buond check nell'ASM generato alla fine.

Poi certo per fare decoding / encoding il C ha magari più senso che C#, ma qui stiamo parlando di una applicazione di messaggistica quel 10% in più causata dall'uso di un linguaggio managed sarebbe stato così disastroso?

O siete ancora convinti che scriverlo in C# vorrebbe dire che andrebbe a scatti mentre scrivi?

[1] falsa sensazione di sicurezza tra l'altro visto che il C ha la tendenza a sbordare sui tappi delle povere "stringhe" e quindi la strlen() si può tranquillamente spazzolare 1024 byte prima di trovare sto povero "tappo" :mbe:

cdimauro
18-10-2018, 18:53
vedo che preferisci scrivere milioni di righe piuttosto che comprenderne due che scrivono gli altri.
quando mi dirai dove ho parlato male di qualche programmatore, fammelo sapere.
Ecco qui:
Potro' sbagliare, ma il "difetto" di c, e c++, e' che non perdonano lo sviluppatore. se uno e' incompetente, ti massacrano.
se programmi alla cazzo di cane, o alla "stackoverflow-dipendente", ti distruggono. diventano delle bombe a tempo, che prima o poi esploderanno lasciandoti nella merda piu' nera. se non li studi, lasciali perdere, non li impari con wikipedia.
Come già detto, tali linguaggi ti massacrano (usando un tuo termine) anche se li conosci bene.

Se sei così bravo e sai fare di meglio puoi sempre farti assumere da qualche multinazionale come quelle che ho citato (anche nella mia azienda ci sono posizioni aperte che cercano esperti programmatori C++), ma con la clausola che se fai un cazzata non soltanto ti mandano subito via a calci in culo, ma devi restituire tutti gli stipendi moltiplicati per 10.

Tanto sei così bravo che non succederà mai, no?
per il resto non perdo tempo a risponderti, se i tuoi modi di fare sono questi, e' perfettamente inutile discutere con te, visto che oltretutto ti credi il dio dei programmatori. l'importante e' crederci.
Non ho mai affermato questo. Adesso sei partito col puerile vittimismo da due soldi, mettendomi in bocca cose che non mi sono mai sognato di dire. Evidentemente non ti rimane altro che mentire e mistificare.

Poi che tu non possa rispondere non è una questione di perdita di tempo, ma perché hai già ampiamente dimostrato le tue scarse conoscenze, com'è messo nero su bianco in particolare nel mio ultimo commento.

EDIT. Questo l'hai aggiunto dopo:
un bel plonk e risolvo tutto, con gli arroganti e' l'unica soluzione. adios.
E chi se ne frega. La prossima volta pensaci invece di raccontare frottole e falsità, offendendo anche professionisti che sicuramente C/C++ lo conoscono di gran lunga meglio di te, che non sai nemmeno come sono implementate e quanto sono lente le "stringhe" in C...

fano
19-10-2018, 08:58
E la cosa dilettevole è che "Javascript the good parts" è scritto dallo stesso autore di Javascript stesso, beh almeno è modesto dai :D

Non so se esiste un "C the good parts" e di quante pagine sia composto :D

GTKM
19-10-2018, 11:20
E la cosa dilettevole è che "Javascript the good parts" è scritto dallo stesso autore di Javascript stesso, beh almeno è modesto dai :D

Non so se esiste un "C the good parts" e di quante pagine sia composto :D

Viene comunemente pagato "K&R", ed è un bel libro, anche piccolino.

grebanno
19-10-2018, 15:14
se compri ancora PS nel 2018 certe cose te le meriti...

Titanox2
19-10-2018, 15:23
se compri ancora PS nel 2018 certe cose te le meriti...

cosa dovremmo comprare, illuminaci