Discussione:
Newsgroup morto
(troppo vecchio per rispondere)
Rd0
2014-03-31 18:30:45 UTC
Permalink
Riposi In Pace, Amen
f***@gmail.com
2014-03-31 19:33:01 UTC
Permalink
Post by Rd0
Riposi In Pace, Amen
Ma no.
enoquick
2014-04-01 00:11:09 UTC
Permalink
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)

Si vede che in Italia oramai il C lo usano 4 gatti
Andrea Rimicci
2014-04-01 10:26:38 UTC
Permalink
Post by enoquick
Si vede che in Italia oramai il C lo usano 4 gatti
Spero di no, magari chi lo usa non ha molto tempo per usare nntp, che
tra l'altro e' sempre piu' soppiantato dal uebb e forums vari.
Comunque, meglio pochi ma buoni. Se hai un dubbio sul C, qui ci sono
persone in gamba.
--
andrea - ri mi cci, name
enoquick
2014-04-01 13:12:23 UTC
Permalink
Post by Andrea Rimicci
Post by enoquick
Si vede che in Italia oramai il C lo usano 4 gatti
Spero di no, magari chi lo usa non ha molto tempo per usare nntp, che
tra l'altro e' sempre piu' soppiantato dal uebb e forums vari.
E' un linguaggio che ha perso molto rispetto al passato surclassato da
altri linguaggi di livello più elevato
Non è una critica al linguaggio, è nell' ordine delle cose
Essendo un assembler portabile va utilizzato appunto per quello
Oltre sarebbe inutile
Quindi non mi stupirei se oggi fossero 4 gatti ad utilizzarlo
Post by Andrea Rimicci
Comunque, meglio pochi ma buoni. Se hai un dubbio sul C, qui ci sono
persone in gamba.
Ti ringrazio, ma non ne ho bisogno
Lo conosco molto bene
Massimo Soricetti
2014-04-01 16:20:15 UTC
Permalink
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
Per un progetto nuovo non userei il C, ora come ora.

Cioè, se fosse un firmware sì, oppure per fare una .DLL ( o .SO) che
implementa algoritmi critici che devono essere molto ma molto veloci, ma
per tutto il resto c'è in giro roba più adatta.

Il C fu inventato in un'epoca in cui i computer avevano 128K di RAM
quando andava bene, e compilare un sorgente ci impiegavano ore se non
giorni, e i compilatori ottimizzanti erano quasi fantascienza.
Molte limitazioni di cui soffre (e a cui devi girare attorno) non hanno
più senso.
f***@gmail.com
2014-04-01 16:44:00 UTC
Permalink
Post by Massimo Soricetti
Post by enoquick
Si vede che in Italia oramai il C lo usano 4 gatti
Per un progetto nuovo non userei il C, ora come ora.
I miei due cent..

Per me il C, anche se non si usa, bisogna studiarlo. Magari ci se lo scorda
dopo un annetto, però insieme ad Assembly (di un processore qualsiasi) e
Lisp (o magari un funzionale derivato, Haskell?) fanno parte del bagaglio
culturale fondamentale di ogni informatico. Del resto, perché ad informatica
si studia elettronica sennò (tipo VHDL e Verilog)? Per riempire il
curriculum accademico? non penso proprio.. ;)

In effetti i newgroup di "teoria" (chessò, comp.theory, per esempio) sono
molto meno frequentati di quelli più "pratici", ma questo non vuol dire
che non siano allo stesso modo utili.

Ciao!
Massimo Soricetti
2014-04-02 14:25:54 UTC
Permalink
Post by f***@gmail.com
Per me il C, anche se non si usa, bisogna studiarlo.
vero
Post by f***@gmail.com
In effetti i newgroup di "teoria" (chessò, comp.theory, per esempio) sono
molto meno frequentati di quelli più "pratici", ma questo non vuol dire
che non siano allo stesso modo utili.
M'hai incuriosito. Ne linko qualcuno...
enoquick
2014-04-01 19:17:00 UTC
Permalink
Post by Massimo Soricetti
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
Per un progetto nuovo non userei il C, ora come ora.
Chi fatto sqlite ha deciso per il C
E non lo ha deciso 20 anni fa
Poteva scegliere il C++ ad esempio, ma non lo ha fatto
Ovviamente avrà avuto le sue ragioni
Post by Massimo Soricetti
Cioè, se fosse un firmware sì, oppure per fare una .DLL ( o .SO) che
implementa algoritmi critici che devono essere molto ma molto veloci, ma
per tutto il resto c'è in giro roba più adatta.
Certo
Post by Massimo Soricetti
Il C fu inventato in un'epoca in cui i computer avevano 128K di RAM
quando andava bene, e compilare un sorgente ci impiegavano ore se non
giorni, e i compilatori ottimizzanti erano quasi fantascienza.
Molte limitazioni di cui soffre (e a cui devi girare attorno) non hanno
più senso.
Oggi il C ha senso solo come assembler portabile, quindi dove serve un
assembler portabile
Se per limitazioni intendi la mancanza di OO ad esempio non è una
limitazione,esiste il C++ per questo
Andrea D'Amore
2014-04-01 21:03:21 UTC
Permalink
Post by enoquick
Chi fatto sqlite ha deciso per il C
E non lo ha deciso 20 anni fa
Lui però è appassionato di C, vedi Fossil SCM.
Post by enoquick
Poteva scegliere il C++ ad esempio, ma non lo ha fatto
Ovviamente avrà avuto le sue ragioni
Probabilmente è una persona dotata di buon gusto e senso estetico.
;-)
--
Andrea
Massimo Soricetti
2014-04-01 22:27:50 UTC
Permalink
Post by Andrea D'Amore
Probabilmente è una persona dotata di buon gusto e senso estetico.
+1 :-D
Massimo Soricetti
2014-04-01 22:53:35 UTC
Permalink
Post by enoquick
Se per limitazioni intendi la mancanza di OO ad esempio non è una
limitazione,esiste il C++ per questo
Anche, ma non principalmente: si può lavorare OO pure con il C, basta
avere un minimo di disciplina. Però trattare le stringhe come array di
char, la libertà sintattica che porta a fare errori (di logica) senza
nemmeno accorgersene... queste cose sono le vere limitazioni. La
sintassi "aperta" serve per avere un compilatore piccolo e veloce, le
stringhe come array per avere una gestione stringhe efficiente. OK, una
volta questi erano aspetti chiave, ma ora come hai detto tu sono tutte
cose che relegano il C al ruolo di assembler portatile.

E' vero che la sintassi del C ha fatto scuola: è stata adottata da così
tanti altri linguaggi che in pratica non puoi fare a meno di impararla,
ti piaccia o meno.
Ma non so se è un bene... mi sembra come la storia della tastiera
QWERTY, che siccome tutti sono abituati a quella si usa quella, anche se
ci sarebbe la dvorak che è più comoda.

Per dirne una, il C usa le parentesi graffe per qualunque tipo di
blocchi di istruzioni: IF, cicli FOR, funzioni, struct ecc. ecc...
d'accordo, funziona e amen, però a me pare più utile usare cose come
beginfunc/endfunc e beginproc/endproc: invece di vedere una scaletta di
quattro o cinque parentesi graffe chiuse, che visivamente si giocano
tutto sull'indentazione, vedere endif; endfor; endfor; endproc;
renderebbe tutto molto più leggibile.

La differenza per chi programma? La quantità di concentrazione
necessaria, e il tempo risparmiato per riprenderla quando il seccatore
di turno se ne va :-)

Era solo un esempio, però ogni tanto mi chiedo seriamente se per caso
non esista un tipo di sintassi radicalmente migliore di quella C-like
che usano i linguaggi di oggi.
enoquick
2014-04-02 00:21:16 UTC
Permalink
Post by Massimo Soricetti
Post by enoquick
Se per limitazioni intendi la mancanza di OO ad esempio non è una
limitazione,esiste il C++ per questo
Anche, ma non principalmente: si può lavorare OO pure con il C, basta
avere un minimo di disciplina. Però trattare le stringhe come array di
char, la libertà sintattica che porta a fare errori (di logica) senza
nemmeno accorgersene... queste cose sono le vere limitazioni.
La
Post by Massimo Soricetti
sintassi "aperta" serve per avere un compilatore piccolo e veloce, le
stringhe come array per avere una gestione stringhe efficiente. OK, una
volta questi erano aspetti chiave, ma ora come hai detto tu sono tutte
cose che relegano il C al ruolo di assembler portatile.
E' vero che la sintassi del C ha fatto scuola: è stata adottata da così
tanti altri linguaggi che in pratica non puoi fare a meno di impararla,
ti piaccia o meno.
Ma non so se è un bene... mi sembra come la storia della tastiera
QWERTY, che siccome tutti sono abituati a quella si usa quella, anche se
ci sarebbe la dvorak che è più comoda.
Per dirne una, il C usa le parentesi graffe per qualunque tipo di
blocchi di istruzioni: IF, cicli FOR, funzioni, struct ecc. ecc...
d'accordo, funziona e amen, però a me pare più utile usare cose come
beginfunc/endfunc e beginproc/endproc: invece di vedere una scaletta di
quattro o cinque parentesi graffe chiuse, che visivamente si giocano
tutto sull'indentazione, vedere endif; endfor; endfor; endproc;
renderebbe tutto molto più leggibile.
La differenza per chi programma? La quantità di concentrazione
necessaria, e il tempo risparmiato per riprenderla quando il seccatore
di turno se ne va :-)
Era solo un esempio, però ogni tanto mi chiedo seriamente se per caso
non esista un tipo di sintassi radicalmente migliore di quella C-like
che usano i linguaggi di oggi.
E' un assembler, non si puo pretendere di piu
Quelle che tu chiami limitazioni sono design precise del linguaggio per
avere un compilatore piccolo e soprattutto generare codice efficiente
Non ci sono solo i PC a questo mondo dove oramai la memoria e l' HD non
sono piu un problema per lo spazio
E' un assembler e fa il ruolo da assembler
E IMHO è giusto che sia cosi

Per quanto riguarda le graffe anche C++,java e perl le usano per i
blocchi (per motivi che sappiamo)
Se vuoi i blocchi tipo begin/end puoi andare su Ada (sintassi pascal
like) che è anche un lui un linguaggio molto potente per quanto riguarda
il design di un problema
Ha un po di futeres che mi piacerebbe fossero portate in C++
Massimo Soricetti
2014-04-02 10:21:02 UTC
Permalink
Post by enoquick
Per quanto riguarda le graffe anche C++,java e perl le usano per i
blocchi (per motivi che sappiamo)
Motivi che sappiamo? Quali motivi? O_O
Post by enoquick
Se vuoi i blocchi tipo begin/end puoi andare su Ada (sintassi pascal
like) che è anche un lui un linguaggio molto potente per quanto riguarda
il design di un problema
Il pascal non è poi tanto diverso dal C, sai? Cambia la grammatica, ma
alla fine sono molto, molto simili. Te ne accorgi dopo aver programmato
in Lisp o Prolog... allora sì che vedi qualcosa di diverso :-)
enoquick
2014-04-02 13:11:37 UTC
Permalink
Post by Massimo Soricetti
Post by enoquick
Per quanto riguarda le graffe anche C++,java e perl le usano per i
blocchi (per motivi che sappiamo)
Motivi che sappiamo? Quali motivi? O_O
Che hanno preso la sintassi dal C (perl anche dalla shell)
Post by Massimo Soricetti
Post by enoquick
Se vuoi i blocchi tipo begin/end puoi andare su Ada (sintassi pascal
like) che è anche un lui un linguaggio molto potente per quanto riguarda
il design di un problema
Il pascal non è poi tanto diverso dal C, sai? Cambia la grammatica, ma
alla fine sono molto, molto simili. Te ne accorgi dopo aver programmato
in Lisp o Prolog... allora sì che vedi qualcosa di diverso :-)
Non sapevo che lisp e prolog avessero i blocchi begin/end (ironico)
CortexA57
2014-04-02 06:03:14 UTC
Permalink
OK, una volta questi erano aspetti chiave, ma ora come hai detto tu sono tutte
cose che relegano il C al ruolo di assembler portatile.
+1€, comuque lavorando in ambiente embedded e con SO RT, qui almeno l'
80% e' ancora scritto in C, il restante in C++.
E' vero che la sintassi del C ha fatto scuola: è stata adottata da così
tanti altri linguaggi che in pratica non puoi fare a meno di impararla,
ti piaccia o meno.
Ma non so se è un bene... mi sembra come la storia della tastiera
QWERTY, che siccome tutti sono abituati a quella si usa quella, anche se
ci sarebbe la dvorak che è più comoda.
Rigore e' quando arbitro fischia :-)
Per dirne una, il C usa le parentesi graffe per qualunque tipo di
blocchi di istruzioni: IF, cicli FOR, funzioni, struct ecc. ecc...
d'accordo, funziona e amen, però a me pare più utile usare cose come
beginfunc/endfunc e beginproc/endproc: invece di vedere una scaletta di
quattro o cinque parentesi graffe chiuse, che visivamente si giocano
tutto sull'indentazione, vedere endif; endfor; endfor; endproc;
renderebbe tutto molto più leggibile.
Non sono per NULLA d'accordo: le parentesi graffe sono eleganti e
concise ! Ho sempre odiato quei cazzo di begin/end anche differenziati
per tipo di statement e non ci trovo niente di utile (Opinione personale).
Era solo un esempio, però ogni tanto mi chiedo seriamente se per caso
non esista un tipo di sintassi radicalmente migliore di quella C-like
che usano i linguaggi di oggi.
C'e' sempre qualche cosa di migliore, ma comi mi diceva il nonno,
spesso il meglio e' nemico del bene.

AA
AleTV
2014-04-02 11:34:10 UTC
Permalink
Post by Massimo Soricetti
Anche, ma non principalmente: si può lavorare OO pure con il C, basta
avere un minimo di disciplina.
Com'è che si fanno le interfacce in C e come si scrivono classi che
implementano interfacce?
f***@gmail.com
2014-04-02 11:48:13 UTC
Permalink
"Massimo Soricetti" ha scritto nel messaggio
Post by Massimo Soricetti
Anche, ma non principalmente: si può lavorare OO pure con il C, basta
avere un minimo di disciplina.
Com'è che si fanno le interfacce in C e come si scrivono classi che
implementano interfacce?
Per contratto.

E comunque tipo i linguaggi a oggetti non è detto che abbiano le interfacce,
guarda Python.

Ciao!
AleTV
2014-04-02 12:02:55 UTC
Permalink
Post by AleTV
Com'è che si fanno le interfacce in C e come si scrivono classi che
implementano interfacce?
Per contratto.
Cioè?
Post by AleTV
E comunque tipo i linguaggi a oggetti non è detto che abbiano le interfacce,
guarda Python.
Non ne so nulla, ma rimaniamo al C che mi incuriosisce (usato begli anni fa,
ma al massimo con le solite struct + enne funzioni che si pigliano il primo
argomento come un puntatore alla struct per simulare così una sorta di OO
base base).
f***@gmail.com
2014-04-02 12:16:42 UTC
Permalink
Post by AleTV
Post by f***@gmail.com
Post by AleTV
Com'è che si fanno le interfacce in C e come si scrivono classi che
implementano interfacce?
Per contratto.
Cioè?
Cioè sai che, anche se il linguaggio non ti forza in alcun modo, certe
strutture e firme _devono_ essere così come te le aspetti.
Post by AleTV
Post by f***@gmail.com
E comunque tipo i linguaggi a oggetti non è detto che abbiano le interfacce,
guarda Python.
Non ne so nulla, ma rimaniamo al C che mi incuriosisce (usato begli anni fa,
ma al massimo con le solite struct + enne funzioni che si pigliano il primo
argomento come un puntatore alla struct per simulare così una sorta di OO
base base).
Ah beh, come me sfondi una porta aperta. Ho anche fatto una serie di video
(disponibili su youtube, ora son privati in attesa di refactoring, ma se
t'interessa ti do il link) proprio su questo argomento.

Ciao!
AleTV
2014-04-02 18:04:06 UTC
Permalink
Post by f***@gmail.com
Cioè sai che, anche se il linguaggio non ti forza in alcun modo, certe
strutture e firme _devono_ essere così come te le aspetti.
Non capisco che intendi dire.
Tipo prendere una struct e metterci dentro puntatori a funzione di vario
genere intendo così una sorta di dichiarazione di interfaccia?
f***@gmail.com
2014-04-02 19:08:42 UTC
Permalink
Post by AleTV
Post by f***@gmail.com
Cioè sai che, anche se il linguaggio non ti forza in alcun modo, certe
strutture e firme _devono_ essere così come te le aspetti.
Non capisco che intendi dire.
Tipo prendere una struct e metterci dentro puntatori a funzione di vario
genere intendo così una sorta di dichiarazione di interfaccia?
http://it.wikipedia.org/wiki/Design_by_contract

Portato all'estremo (cosa che si può (e quindi si deve) evitare quasi sempre)
ti potresti anche solo passare void* ovunque.

Ciao!

P.S. Non che in C++ la situazione sia tanto migliore, eh - il C++ "scritto
bene" a-la-boost è un guazzabuglio di static_cast<>.
Massimo Soricetti
2014-04-03 00:32:59 UTC
Permalink
Post by f***@gmail.com
P.S. Non che in C++ la situazione sia tanto migliore, eh - il C++ "scritto
bene" a-la-boost è un guazzabuglio di static_cast<>.
Il che IMHO la dice lunga su cos'è diventato il C++, ma non è questa la
sede per siffatte considerazioni...
enoquick
2014-04-03 03:15:19 UTC
Permalink
Post by Massimo Soricetti
Post by f***@gmail.com
P.S. Non che in C++ la situazione sia tanto migliore, eh - il C++ "scritto
bene" a-la-boost è un guazzabuglio di static_cast<>.
Il che IMHO la dice lunga su cos'è diventato il C++, ma non è questa la
sede per siffatte considerazioni...
Il C++ è molto migliorato con il tempo (ed il C++11 ha fatto ancora
passi avanti)
Se i programmatori di boost usano troppi static cast o hanno avuto una
buona ragione (ad esempio interfacce vicine alle librerie C o all' hw) o
hanno progettato male le varie interfacce e propendo per questa ultima
ipotesi
f***@gmail.com
2014-04-04 10:59:27 UTC
Permalink
Post by enoquick
Post by Massimo Soricetti
Post by f***@gmail.com
P.S. Non che in C++ la situazione sia tanto migliore, eh - il C++ "scritto
bene" a-la-boost è un guazzabuglio di static_cast<>.
Il che IMHO la dice lunga su cos'è diventato il C++, ma non è questa la
sede per siffatte considerazioni...
Il C++ è molto migliorato con il tempo (ed il C++11 ha fatto ancora
passi avanti)
Se i programmatori di boost usano troppi static cast o hanno avuto una
buona ragione (ad esempio interfacce vicine alle librerie C o all' hw) o
hanno progettato male le varie interfacce e propendo per questa ultima
ipotesi
Spesso con colleghi o amici programmatori parlo di questa cosa.. secondo me
è solo questione dello "stile" che si preferisce: i due capisaldi degli
estremi sono le Qt e le Boost. Le prime sono pulite, facili e flessibili,
molto overhead ma sembra di programmare ad altissimo livello, le seconde
sono un devasto di template (quanto sono, 80Mb di headers?) complesse
da capire e imparare ma fanno tutto a compile time.
Personalmente apprezzo molto di più lo stile delle Qt (che poi, lo ricordo,
hanno parti che sono state sviluppate /prima/ delle STL, e secondo me
sarebbero dovute essere lo standard da quanto sono più ben fatte).
Evidentemente Stroustrup e la maggior parte dei C++isti la pensano
diversamente.

Ciao!
Massimo Soricetti
2014-04-04 12:49:07 UTC
Permalink
Post by f***@gmail.com
Evidentemente Stroustrup e la maggior parte dei C++isti la pensano
diversamente.
IMHO c'entra molto una certa mentalità caratteristica dei programmatori,
inclini a gestire tutto fin nei più minimi insignificanti dettagli: il
risultato è che invece di semplificarsi la vita, uno se la complica :-D
f***@gmail.com
2014-04-04 13:00:01 UTC
Permalink
Post by Massimo Soricetti
Post by f***@gmail.com
Evidentemente Stroustrup e la maggior parte dei C++isti la pensano
diversamente.
IMHO c'entra molto una certa mentalità caratteristica dei programmatori,
inclini a gestire tutto fin nei più minimi insignificanti dettagli: il
risultato è che invece di semplificarsi la vita, uno se la complica :-D
Beh, il C++ è così utilizzato anche perché è così flessibile che puoi
programmare a qualsiasi livello di astrazione tu voglia. Quando le
performance dell'applicativo finale sono uguali o non interessano diventa
solo una guerra di religione, IMHO.

Ciao!
enoquick
2014-04-04 13:23:56 UTC
Permalink
Post by f***@gmail.com
Post by enoquick
Post by Massimo Soricetti
Post by f***@gmail.com
P.S. Non che in C++ la situazione sia tanto migliore, eh - il C++ "scritto
bene" a-la-boost è un guazzabuglio di static_cast<>.
Il che IMHO la dice lunga su cos'è diventato il C++, ma non è questa la
sede per siffatte considerazioni...
Il C++ è molto migliorato con il tempo (ed il C++11 ha fatto ancora
passi avanti)
Se i programmatori di boost usano troppi static cast o hanno avuto una
buona ragione (ad esempio interfacce vicine alle librerie C o all' hw) o
hanno progettato male le varie interfacce e propendo per questa ultima
ipotesi
Spesso con colleghi o amici programmatori parlo di questa cosa.. secondo me
è solo questione dello "stile" che si preferisce: i due capisaldi degli
estremi sono le Qt e le Boost. Le prime sono pulite, facili e flessibili,
molto overhead ma sembra di programmare ad altissimo livello, le seconde
sono un devasto di template (quanto sono, 80Mb di headers?) complesse
da capire e imparare ma fanno tutto a compile time.
Non ho messo in discussione l' eredità orizzontale (detta anche
programmazione generica o programmazione a template) ma l' uso abnorme
(cosi Massimo aveva scritto) degli static cast
Personalmente non uso e non ho mai letto i sorgenti di boot ma prendo
per vera l' affermazione di Massimo
Post by f***@gmail.com
Personalmente apprezzo molto di più lo stile delle Qt (che poi, lo ricordo,
hanno parti che sono state sviluppate /prima/ delle STL, e secondo me
sarebbero dovute essere lo standard da quanto sono più ben fatte).
Evidentemente Stroustrup e la maggior parte dei C++isti la pensano
diversamente.
Stroustrup molti anni fa lo disse chiaramente, l' efficienza è uno degli
obiettivi primari per una libreria di uso generale
Per l' efficienza in C++11 hanno pure introdotto la sintassi di move per
evitare di usare un puntatore e la relativa gestione della memoria
Post by f***@gmail.com
Ciao!
AleTV
2014-04-04 13:27:49 UTC
Permalink
Post by enoquick
Stroustrup molti anni fa lo disse chiaramente, l' efficienza è uno degli
obiettivi primari per una libreria di uso generale
E per fortuna! Oggi abbiamo dei multicore a 2 GHz e passa sui telefonini e
vanno lenti lo stesso...
f***@gmail.com
2014-04-04 13:45:02 UTC
Permalink
Post by AleTV
Post by enoquick
Stroustrup molti anni fa lo disse chiaramente, l' efficienza è uno degli
obiettivi primari per una libreria di uso generale
E per fortuna! Oggi abbiamo dei multicore a 2 GHz e passa sui telefonini e
vanno lenti lo stesso...
Perché sui "telefonini" non programmi in C++. Ho visto gente programmare app
in HTML5+JS, vedi te. Per non parlare di Android, dove in pratica è tutto
una grossa Javeria. Tremendo.

Ciao!
f***@gmail.com
2014-04-04 13:50:10 UTC
Permalink
Post by enoquick
Non ho messo in discussione l' eredità orizzontale (detta anche
programmazione generica o programmazione a template) ma l' uso abnorme
(cosi Massimo aveva scritto) degli static cast
Personalmente non uso e non ho mai letto i sorgenti di boot ma prendo
per vera l' affermazione di Massimo
(L'avevo scritto io, ma tant'è)
Post by enoquick
Stroustrup molti anni fa lo disse chiaramente, l' efficienza è uno degli
obiettivi primari per una libreria di uso generale
Sì, no, boh. E' l'idea sua. Se diceva che "l'obiettivo primario era la
facilità nello scrivere codice" sarebbe stato sensato lo stesso.
Comunque, visto che l'ha detto lui, e non io o te, come si dice a Roma
"tocca stacce". :)
Che poi non è che non mi piacciono le STL eh, al contrario, le uso anche
tantissimo. Però se sto scrivendo una roba che già usa le Qt uso solo le Qt,
con grande gioia.

Ciao!
enoquick
2014-04-04 18:45:50 UTC
Permalink
Post by f***@gmail.com
Post by enoquick
Non ho messo in discussione l' eredità orizzontale (detta anche
programmazione generica o programmazione a template) ma l' uso abnorme
(cosi Massimo aveva scritto) degli static cast
Personalmente non uso e non ho mai letto i sorgenti di boot ma prendo
per vera l' affermazione di Massimo
(L'avevo scritto io, ma tant'è)
Un piccolo errore, chiedo scusa
Post by f***@gmail.com
Post by enoquick
Stroustrup molti anni fa lo disse chiaramente, l' efficienza è uno degli
obiettivi primari per una libreria di uso generale
Sì, no, boh. E' l'idea sua. Se diceva che "l'obiettivo primario era la
facilità nello scrivere codice" sarebbe stato sensato lo stesso.
Comunque, visto che l'ha detto lui, e non io o te, come si dice a Roma
"tocca stacce". :)
Che poi non è che non mi piacciono le STL eh, al contrario, le uso anche
tantissimo. Però se sto scrivendo una roba che già usa le Qt uso solo le Qt,
con grande gioia.
Ciao!
Non voglio certo mettere in dubbio le preferenze personali in fatto di
librerie, ci mancherebbe altro
ulisse
2014-09-11 13:07:58 UTC
Permalink
Post by Massimo Soricetti
Si vede che in Italia oramai il C lousano 4 gatti
credo qualche gatto in più, magari anche più di 44.
Post by Massimo Soricetti
Per un progetto nuovo non userei il C, ora come ora.
Dissento sui criteri c-si c-no, ma come giustamente detto dipende dalle situazioni.
Se l'hw non ti viene rinnovato, anche se hai molto ma molto più di 128k, talvolta conviene proprio rimanere sul C.



----Android NewsGroup Reader----
http://www.piaohong.tk/newsgroup
CortexA57
2014-09-11 14:01:40 UTC
Permalink
Post by Massimo Soricetti
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
Oppure ormai e' cosi' conosciuto che non c'e' bisogno di altro :-)
Post by Massimo Soricetti
Per un progetto nuovo non userei il C, ora come ora.
Cioè, se fosse un firmware sì, oppure per fare una .DLL ( o .SO) che
implementa algoritmi critici che devono essere molto ma molto veloci, ma
per tutto il resto c'è in giro roba più adatta.
Ma anche no ;-)
Post by Massimo Soricetti
Il C fu inventato in un'epoca in cui i computer avevano 128K di RAM
quando andava bene, e compilare un sorgente ci impiegavano ore se non
giorni, e i compilatori ottimizzanti erano quasi fantascienza.
Molte limitazioni di cui soffre (e a cui devi girare attorno) non hanno
più senso.
Pare sia ancora al top :-)
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

AA.

AleTV
2014-04-02 11:31:58 UTC
Permalink
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
E si son messi in croce dando vita al C# !!!! ROTFL!!!!!
francesco
2014-04-03 06:58:20 UTC
Permalink
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
A scuola ancora si usa, io come docente tecnico pratico lo insegno ai
miei studenti del terzo anno in un itis di informatica. Prima usavo il
Pascal, ma tanti anni fa. Ora che i programmi ministeriali sono cambiati
con la riforma, imparare il C aiuta a capire meglio la programmazione in
Assembly. Infatti, prima di realizzare un programma in Assembly, lo
implementiamo in C, e poi vediamo le differenze. Dover fare Assembly in
terza mi ha aiutato ad introdurre subito i puntatori, già dalle
primissime lezioni, diciamo che prima di spiegare la printf ho spiegato
il concetto di indirizzo di una variabile e l'operatore &, poi la
dimensione di un dato con sizeof, e poi l'allocazione dinamica di una
variabile con malloc. Ora stiamo lavorando sulle stringhe in Assembly,
perchè le avevamo già introdotte tempo addietro con il C e l'allocazione
dinamica. Stiamo lavorando sugli algoritmi di conversione da stringa ad
intero o float e viceversa. Poi il C ci ha facilitato l'uso dell'assembly
in quanto lavorando in Linux usiamo le syscall per svolgere operazioni
tipo input/output dei dati. Insomma, la conoscenza del C per un
programmatore è fondamentale.

Francesco
ricky
2014-04-03 07:55:48 UTC
Permalink
Post by francesco
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
A scuola ancora si usa, io come docente tecnico pratico lo insegno ai
miei studenti del terzo anno in un itis di informatica. Prima usavo il
Pascal, ma tanti anni fa. Ora che i programmi ministeriali sono cambiati
con la riforma, imparare il C aiuta a capire meglio la programmazione in
Assembly. Infatti, prima di realizzare un programma in Assembly, lo
implementiamo in C, e poi vediamo le differenze. Dover fare Assembly in
terza mi ha aiutato ad introdurre subito i puntatori, già dalle
primissime lezioni, diciamo che prima di spiegare la printf ho spiegato
il concetto di indirizzo di una variabile e l'operatore &, poi la
dimensione di un dato con sizeof, e poi l'allocazione dinamica di una
variabile con malloc. Ora stiamo lavorando sulle stringhe in Assembly,
perchè le avevamo già introdotte tempo addietro con il C e l'allocazione
dinamica. Stiamo lavorando sugli algoritmi di conversione da stringa ad
intero o float e viceversa. Poi il C ci ha facilitato l'uso dell'assembly
in quanto lavorando in Linux usiamo le syscall per svolgere operazioni
tipo input/output dei dati. Insomma, la conoscenza del C per un
programmatore è fondamentale.
Sono d'accordo su tutta la linea, e aggiungo osservazioni che vanno
nella stessa direzione.

Mi occupo di calcolo HPC: può capitare che mi arrivino codici scritti in
Matlab, e la richiesta di "passarli in codice parallelo", perchè troppo
lenti. Capita che a volte questa lentezza sia da ricondurre ad una
leggerezza nella programmazione Matlab.

Che c'entra col C? Chi ha imparato a programmare in C ha una chiara idea
della propria distribuzione dei dati in memoria, e sviluppa una affinità
molto più stretta con l'hardware che sta utilizzando. Risultato: a volte
basta trasporre qulche matrice, evitare qualche copia, vettorizzare
qualcosa, e anche il codice Matlab diventa utilizzabile.

Però la capacità di vedere dove sono i problemi, me l'ha data il C...

Riccardo
francesco
2014-04-03 17:58:58 UTC
Permalink
Post by ricky
Sono d'accordo su tutta la linea, e aggiungo osservazioni che vanno
nella stessa direzione.
Mi occupo di calcolo HPC: può capitare che mi arrivino codici scritti in
Matlab, e la richiesta di "passarli in codice parallelo", perchè troppo
lenti. Capita che a volte questa lentezza sia da ricondurre ad una
leggerezza nella programmazione Matlab.
Che c'entra col C? Chi ha imparato a programmare in C ha una chiara idea
della propria distribuzione dei dati in memoria, e sviluppa una affinità
molto più stretta con l'hardware che sta utilizzando. Risultato: a volte
basta trasporre qulche matrice, evitare qualche copia, vettorizzare
qualcosa, e anche il codice Matlab diventa utilizzabile.
Però la capacità di vedere dove sono i problemi, me l'ha data il C...
Riccardo
Anche se questo gruppo sembra "morto", il gruppo "comp.lang.c" mi sembra
vivo e vegeto. Poi qua in Italia molti altri gruppi sembrano essere
andati in letargo. Sarà stata la crisi ?
f***@gmail.com
2014-04-03 18:15:21 UTC
Permalink
Post by francesco
Anche se questo gruppo sembra "morto", il gruppo "comp.lang.c" mi sembra
vivo e vegeto. Poi qua in Italia molti altri gruppi sembrano essere
andati in letargo. Sarà stata la crisi ?
Di base tutto usenet è morto. Si usano altre tecnologie.
E' un peccato, ma alla fine decide la maggioranza.

Ciao!
enoquick
2014-04-03 13:15:47 UTC
Permalink
Post by francesco
Post by enoquick
Post by Rd0
Riposi In Pace, Amen
sempre sii lodato (newsgroup)
Si vede che in Italia oramai il C lo usano 4 gatti
A scuola ancora si usa, io come docente tecnico pratico lo insegno ai
miei studenti del terzo anno in un itis di informatica. Prima usavo il
Pascal, ma tanti anni fa. Ora che i programmi ministeriali sono cambiati
con la riforma, imparare il C aiuta a capire meglio la programmazione in
Assembly. Infatti, prima di realizzare un programma in Assembly, lo
implementiamo in C, e poi vediamo le differenze. Dover fare Assembly in
terza mi ha aiutato ad introdurre subito i puntatori, già dalle
primissime lezioni, diciamo che prima di spiegare la printf ho spiegato
il concetto di indirizzo di una variabile e l'operatore &, poi la
dimensione di un dato con sizeof, e poi l'allocazione dinamica di una
variabile con malloc. Ora stiamo lavorando sulle stringhe in Assembly,
perchè le avevamo già introdotte tempo addietro con il C e l'allocazione
dinamica. Stiamo lavorando sugli algoritmi di conversione da stringa ad
intero o float e viceversa. Poi il C ci ha facilitato l'uso dell'assembly
in quanto lavorando in Linux usiamo le syscall per svolgere operazioni
tipo input/output dei dati. Insomma, la conoscenza del C per un
programmatore è fondamentale.
Francesco
Ed è giusto che sia cosi (insegnarlo a scuola)
luka
2014-05-04 17:33:59 UTC
Permalink
On Mon, 31 Mar 2014 18:11:09 -0600
Post by enoquick
[...]
Si vede che in Italia oramai il C lo usano 4 gatti
Sciocchezza e anche piuttosto pesante!
m***@gmail.com
2014-04-10 13:41:15 UTC
Permalink
Post by Rd0
Riposi In Pace, Amen
E' usenet ad essere in fase morente, non certo il C.
luka
2014-05-04 17:29:30 UTC
Permalink
On Mon, 31 Mar 2014 20:30:45 +0200
Post by Rd0
Riposi In Pace, Amen
No, non direi, semplicemente ci sono altre fonti, a parer mio tuttavia
il livello di questo gruppo è indiscutibilmente alto.

Tornerà a nuova vita non appena 'finirà' l'overdose da informazioni
che stiamo vivendo.
Loading...