Newsgroup: it.comp.lang.c
Titolo: C risolve tutto

Ciao mi chiamo Davide volevo porvi una domanda
dunque io lavoro in una software house e ho poche basi informatiche
ho imparato quello che so sul campo
programmo in php, asp, cold fusion, JS SQL
quindi tecnologie non veri linguaggi di programmazione,
ho molta intuizione ma non poso definirmi un programmatore
in quanto ho imparato a mettere le mani sul codice ad intuizione e reciclando
ovviamente le mie conoscenze sono leggermente migliorate col tempo ma 
vorrei fare un vero salto di qualita
in quanto desidero  colmare il gap che c'è tra me ed i miei colleghi,
quello che volevo sapere se facendo un corso in c anche se non programmero 
mai in c
puo essere una buona partenza per dare un certo ordine nell'approcio e nel 
modo di fare
e colmare le basi che mi mancano
grazie Davide
--
Posted from 
sea.glamm.com
 [194.185.237.3] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 nel modo di fare e colmare le basi che mi mancano
  Il C e` un linguaggio di programmazione che rasenta la perfezione
divina. Ha una sintassi relativamente semplice, non produce eccessivi
obblighi per l'utente ed e` sufficientemente di basso livello per
mantenere il programmatore sempre cosciente di cio` che sta facendo.
  La programmazione in C richiede ordine mentale, capacita` di
osservazione ed intuizione. Il C non fornisce gabbie ma neanche reti di
protezione, e` un cannone senza sicura.
  In C si possono scrivere le peggiori porcate della storia
dell'informatica ma anche codice di una raffinata eleganza espressiva.
  Inoltre, insieme--ahime`--al Cobol, e` lo strumento produttivo piu`
utilizzato in ambito informatico: un'intera classe di sistemi operativi
e` stata sviluppata in C (i cosiddetti "Unices") e su tali piattaforme
l'integrazione tra il sistema e l'ambiente di sviluppo e` cosi` stretta
da rendere complementari le conoscenze sistemistiche e di
programmazione.
  Il C e` uno dei pochi linguaggi di programmazione il cui standard,
insieme a quello delle sue librerie di base--e` riconosciuto, mantenuto
ed ampliato da un apposito comitato dell'Organizzazione Internazionale
per gli Standard (ISO). Questo assicura un sotto-insieme minimale di
funzionalita` comuni a tutti le piattaforme ove esso sia presente.
  Il C e` utilizzato nello sviluppo negli ambiti piu` svariati: dai
videogame (Quake e Doom) ai sistemi /embedded/ (micro-controllori,
processori di apparati di rete come i /router/ Internet), dai succitati
sistemi operativi al sistema di controllo del progetto missilistico
Arianne.
  Il C conta una comunita` di sviluppatori tra le piu` vaste--se non
*la* piu` vasta--del mondo: UseNet conta decine di gruppi di discussione
sul C nelle lingue piu` impensabili.
  Il C e` lo strumento di sviluppo preferenziale per i compilatori e gli
interpreti di altri linguaggi: Perl, Java e Fortran sono implementati in
linguaggio C. 
  Serve altro? ;)
	Alla prossima,
		Marco

linguaggio C. 
Cantiamo pure le lodi del C (meritate a mio avviso), ma aggiungo una
cosa essenziale : il C e' vecchio. Troppo ormai, per essere
considerato un linguaggio da *imparare*. Meglio, a mio avviso,
cominciare a studiare il C++, se proprio bisogna *imparare* un
linguaggio potente come e piu' del C.
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------
#exclude <windows.h>

 linguaggio potente come e piu' del C.
Sono d'accordo con te su tutta la linea.  Java e` un altro
candidato, ma C++ resta piu` potente (e piu` difficile).  Al
peggio, se si usa C++ in ambienti disamichevoli, sara` questione
di sapere quali delle sue possenti feature non si possono
esporre "all'interfaccia" (templates, ecc).
Alex

 C.
  Il C++ (utilizzato con il paradigma OOP) potrebbe anche essere un buon
linguaggio ma:
	1. E` piu` difficile da imparare del C;
	2. Non ha un'implementazione univoca (i.e.: su 
	   moltissime piattaforme esistono compilatori C++ vetusti 
	   e totalmente fuori standard);
	3. In molte occasioni da` l'impressione di essere il 
	   classico cannone usato contro la formica;
	4. Il paradigma ad oggetti prevede un'accurata 
	   formazione progettuale del tutto estranea ad un 
	   normale programmatore;
	5. Fino alla versione precedente all'ultimo standard--che 
	   non conosco--non era neanche universalmente considerato 
	   un linguaggio OO a tutti gli effetti.
  Il C++ al di fuori del paradigma ad oggetti ("Un C migliore?", Bjarne
Stroustrup) non ha moltissime ragioni di esistere, in particolar modo
ora che l'ISO ha recepito per lo standard del C alcune delle sue
caratteristiche piu` notevoli.
	Alla prossima,
		Marco

caratteristiche piu` notevoli.
Io non credo sia cosi'.
Il C++, secondo me, ha moltissime ragioni di esistere, prima di tutte,
quella di offrire un codice meno soggetto a bug.
Il fatto stesso, per esempio, che esso contenga una libreria di
strutture dati del tipo liste, alberi, code, ecc... puo' agevolare la
vita a molti, molti programmatori ! ;)


 agevolare la vita a molti, molti programmatori ! ;)
  Certo. Il Perl ed il Lisp questi concetti li hanno addirittura
implementati nativamente... ;)
	Alla prossima,
		Marco
[1] Standard de facto e non de jure, basato sulle "reference" 
    presentate nella prima edizione del libro di Kernighan e Ritchie.

 caratteristiche piu` notevoli.
Quali compilatori C supportano al 100% il nuovo standard del C?
In pratica, se voglio usare anche solo UNA piccola cosa fondamentale,
cioe` la "dichiarazione just-in-time" (dichiarare una variabile solo subito
prima del suo primo uso), che e` un'idea C++ finalmente adottata in C
solo oggi, con i compilatori a mia disposizione DEVO chiamare i
sorgenti qualcosa.cpp (o usare equivalenti switch per dire al compilatore
che sto lavorando in C++); se li chiamo qualcosa.c (e non uso switch
particolari) il compilatore diagnostica un errore.  E similmente per
le union anonime, ecc, ecc (l'unica estensione C++ che sembra piu`
o meno equivalentemente adottata dai compilatori C di oggi [come
estensione al vecchio standard C dell'89, piu` che come parte del
nuovo standard C di oggi] e` l'uso di // per i commenti:-).
Alex

 Quali compilatori C supportano al 100% il nuovo standard del C?
  E` ipotizzabile che le prossime versioni dello GNU CC lo faranno cosi`
come gli ambienti di sviluppo complementari a quelli per gli ambienti
Microsoft non tarderanno ad adeguarsi in breve tempo. Inoltre, a mio
avviso, il sotto--insieme del C99 supportato dalle versioni correnti di
molti compilatori C e` gia` sufficiente a farne ottimi strumenti di
sviluppo.
  Sempre a mio avviso, le uniche due caratteristiche che avrebbero
potuto migliorare lo standard C89 sarebbero state la definizione in
linea delle funzioni (gia` supportata dalle macro-istruzioni ma
sicuramente positiva per la leggibilita` del codice) e l'inserimento
nella libreria standard della gestione delle espressioni regolari.
  La prima e` stata recepita--ma era gia` implementata da tempo in molti
prodotti--, la seconda no (purtroppo).
  Ad ogni modo, le differenze tra le due versioni dello standard, il
tempo intercorso tra loro e la sinergia tra il progresso dei compilatori
e lo sviluppo dello standard rendera` l'aggiornamento molto rapido.
	Alla prossima,
		Marco
[1] Il seguente brano di codice e` compilabile con un compilatore C 
    ma non con un compilatore C++, i.e.: il C++ non e` strettamente 
    un sovra-insieme del C. ;)
<code>
	struct animal {
		char *class;
		char *genus;
		char *species;
	};
</code>

 es 
http://www.talkorigins.org/faqs/flatearth.html
  Nessun essere senziente considera la Terra rotonda: 
<cite src="F. Guccini 'La Genesi'">
	Ma fatta la luce ci vide più chiaro: là nello spazio girava 
		una palla.
	Restò pensoso, gli parve un po' strano, ma scosse il capo: 
		"Chi non fa non falla!"
	Rise Lucifero stringendo l'occhio quando lui e gli angeli 
		furon da soli:
	"Guarda che roba! Si vede che è vecchio: l'ha fatto 
		tutto schiacciato sui poli!"
</cite>
  ;)
	Alla prossima,
		Marco

 strutture dati del tipo liste, alberi,
Alberi? Sei sicuro che la libreria standard del C++ offra anche alberi
espliciti (impliciti forse si)?
EMG

#exclude <windows.h>
Urca, allora ho sbagliato tutto :-(

   Il bug non lo produce il codice ma il programmatore o l'analista.
Lo stesso che dicono i fanatici delle armi da fuoco in USA per
opporsi alla loro regolamentazione: "non e` la pistola che uccide,
e` la persona che preme il grilletto".  Lo stesso che dicono le
linee aeree a basso budget dopo ogni crash dei loro aeroplani:
"noi non abbiamo colpa, e` stato un errore umano".  Ecc, ecc.  E
non convince in nessuno di questi casi.
Gli esseri umani sono fatti in un certo complicato modo X (e
adesso che il genoma e` mappato forse cominceremo a capirlo,
ma ne dubito:-).  E` *la tecnologia* (e il suo metodo di uso) che
dev'essere APPROPRIATA, *ADATTANDOSI* alla natura
umana.  Se l'interazione fra tecnologia e natura umana produce
un risultato spiacevole, sfogati pure incolpando l'uomo e/o il suo
creatore (che lo ha progettato malaccio assai, senza dubbio),
ma e` la tecnologia (e il suo metodo di uso) a doversi adattare.
Alex

 
<code>
	map { print "Hello, $_" if length $_ > 93 } <STDIN>
</code>
  Perl 1 -- C++ 0 ;)
	Alla prossima,
		Marco

  Perl 1 -- C++ 0 ;)
Prova a scrivere un Interactive Voice Response System in Perl e poi ne
riparliamo ;)

l'impressione che condivida questo assunto)
Assolutamente si'.

 doversi adattare.
  La tecnologia C produce ed ha prodotto ottimi risultati e pessimi
mostri, la dinamite ha ucciso forse milioni di uomini ma ha scavato
gallerie e cavato materiali dalle miniere fondamentali per il progresso.
Le cose e le idee non fanno male, sono il loro utilizzo e la loro
strumentalizzazione che uccidono.
  Uhm... stiamo andando un po' troppo fuori tema. Per quel che mi
riguarda la discussione termina qui (con che faccia, altrimenti, potrei
"cazziare" i poveri new-user con le loro domande sulle porte seriali?
:))) ).
	Alla prossima,
		Marco

Andrea,

  Che fai, palleggi? La sfida era sui compiti semplici, non su quelli
(quasi) impossibili. Prova a scrivere in C++ un programma che rimuova
tutti i commenti da un file in formato HTML... ;)
	Alla prossima,
		Marco

implementati nativamente... ;)
Non sto confrontando linguaggi, sto solo esponendo i vantaggi di *un*
linguaggio evolutosi nel tempo.
Non ci crederai, in Perl e in Lisp ho provato a scrivere un programma
che interagisce a basso livello con delle schede Dialogic per la
gestione del traffico telefonico di un Call Center, ma sinceramente
non ci sono riuscito : in C++ si'.
Ogni linguaggio e' adeguato ai suoi ambiti, ma questo e' un altro
discorso ;)

espliciti (impliciti forse si)?
Non so EMG, non conosco bene la libreria standard, posso aver detto
una maialata, so solo che potrei farci un sacco di cose senza la
minima fatica e non la so usare !!!
Accidenti a me che non mi decido mai ad andare avanti col "Thinking in
C++" ! ;)

definizione di "vecchio" affibbiata al C?
Non vorrei che ci fossilizzassimo sul termine "vecchio" usato bene o
male. Per me qualcosa diventa vecchio, quando c'e' gia' qualcosa di
meglio e pronto a sostituirlo. Se bisogna imparare un linguaggio,
bisogna aggiornarsi al presente e imparare cio' che c'e' di nuovo. 
Non vedo perche' perdere tempo ad apprendere il C, quando e' possibile
apprendere direttamente il C++ (considerando il fatto che il salto,
prima o poi, e' inevitabile). Bada che quando parlo di C++, non sto
succhiandone fuori solo la parte OO.
Tuttavia, qui dentro si vedono persone che sbattono la testa su come
creare liste con i puntatori, con i puntatori a puntatori, con i
puntatori a puntatori a puntatori, e chi piu' ne ha piu' ne metta,
senza pensare ai litri di sangue che potrebbero versare i loro
clienti. Il C++ solleva da gran parte di questi problemi ! 

  Che fai, palleggi?
..ops.. piu' che altro dormivo sugli spalti ;)

 #exclude <windows.h>
come mai? io sto (r)imparando adesso le Win32 API e anche se è un modo
di programmare diverso da le sue soddisfazioni!
ciao

 Be', io ero al corrente che il C fosse *nato* qualche anno prima ;)
Difatti la prima versione del linguaggio C è stata creata da Dennis Ritchie
(quello del libro) alla Bell nel 1972 (2 anni prima).
ciao

 invece degli array (e malloc/free/realloc, ecc) e` semplicemente enorme.
Il fatto è che bene o male le librerie standard del C++ eseguono lo stesso
codice chiamato in C più dell'altro che servirà per i vari controlli,ecc.
Quindi per applicazioni dove la velocità è necessaria (anche scritte in C++)
penso che sia meglio un array di std::vector. Ma lo stesso discorso
si potrebbe fare tra C e assembler...
ciao

 clienti. Il C++ solleva da gran parte di questi problemi !
Per carita`, questo e` verissimo.  La combinazione di eccellenti
prestazioni, grande flessibilita` e generalita`, e relativa
facilita` e sicurezza d'uso, della libreria standard C++, e`
tale da sfidare l'incredulita`; Stepanov e` senza alcun dubbio
un genio (il comitato ha contribuito tanti dettagli importanti
alla standardizzazione della libreria, che non erano in STL, ma
il fondamentale nucleo di idee geniali incorporato nella libreria
standard C++ viene da STL [al punto che il diffuso erroraccio di
considerare STL _la stessa cosa_ di "libreria standard C++" ha
persino una certa licenza poetica:-]).
Ed e` un commento importante e profondo sul C++ che esso ha
permesso a Stepanov di incarnare cosi` a fondo le sue idee
(che, ad esempio, in Ada era riuscito a portare sino a un
certo punto, ma mai altrettanto avanti; anche se, a onor del
vero, C++ e Stepanov si sono incontrati in una fase del
processo di standardizzazione in cui ancora qualche piccola
lucidatina al linguaggio, per perfezionare certi aspetti
della libreria, poteva essere, ed e` stata, apportata).
Ma non e` il mero passaggio del tempo (vecchio vs nuovo) che
ha permesso questo:-).  Unix, ad esempio, per quel che riguarda
parecchie idee-base del kernel, e` vecchio; non per questo e`
necessariamente inferiore a sistemi operativi piu` nuovi, come
VMS, Dos, o Windows/NT!-)  E quel che vale per un SO puo` in
teoria valere anche per un linguaggio (vogliamo paragonare il
vecchio Common LISP con il piu` giovane Visual Basic?-).
Alex

 C++" ! ;)
O per la libreria standard, magari il Josuttis, se il linguaggio
lo conosci gia`; sembra davvero ottimo.
Alex

 riguarda la discussione termina qui (con che faccia, altrimenti, potrei
Anche per me.  Dopo avere letto questo ultimo tuo ALLUCINANTE
paragrafo, che ho citato e a cui ho ampiamente risposto, non
credo di avere molto interesse a continuarla.  Se mai dovessi
leggere tue asserzioni su temi che non sono immediatamente in
grado di verificare, come potrei sapere se sono almeno semi
sensate, o sul piano di "ActiveX che soppianta COM"...?!
Alex

   Perl 1 -- C++ 0 ;)
Questo "programma" Perl ha svariati bug rispetto alle
specifiche.  Complimenti, sei riuscito ancora una volta
a dimostrare che la densita` di bug per carattere di
sorgente e` superiore in Perl che in qualsiasi altro
linguaggio.  Te ne segnalo solo uno, cosi` ovvio che
sarebbe dovuto essere evidente persino a te: se la
riga letta e` molto lunga, essa va comunque inviata
su standard output (e il C++ lo fa); il tuo programma
Perl invece non esegue alcun output in questo caso.
Comunque, non c'e` dubbio che linguaggi di piu` alto
livello sono piu` adatti anche del C++ (e a maggior
ragione del C) per la maggior parte dei compiti (io
naturalmente preferirei Python, ma questo e` un altro
discorso).  Il punto e`: non c'e` alcuno bisogno che
un programma debba essere object-oriented perche` vi
siano vantaggi importanti a realizzarlo in C++
*** INVECE CHE IN C ***.  E questo, a smentire la tua
errata asserzione in contrario.
Analogia: una pistola e` un'arma piu` letale di
un coltello.  Questo non e` inficiato minimamente
dal fatto che una bomba atomica lo sia in misura
ancora (enormemente) maggiore.
Alex

 si potrebbe fare tra C e assembler...
Cercare di misurare differenze di prestazioni fra un array di
int allocato con malloc e un std::vector<int> non mi ha mai
permesso di rilevarne alcuna, entro il "rumore di fondo".
Un'applicazione hard real-time non usera` memoria allocata
dinamicamente, ovviamente -- ne` in C, ne` in C++, ne` in
Assembler.  Se si puo` allocare dinamicamente la memoria,
ci si puo` permettere di farlo con std::vector invece che
con malloc.  In C++, hai l'ulteriore vantaggio di potere
evitare l'allocazione dinamica (definendo un allocator
opportuno e usandolo come parametro del template vector)
in quei rarissimi casi in cui non puoi permettertela, e
per il resto lasciare identico il tuo codice.
Alex

 C++" ! ;)
Ti capisco. Neanch'io riesco a finirlo.
EMG

 clienti. Il C++ solleva da gran parte di questi problemi !
e vvabbe' ... ma vuoi mettere la soddisfazione !!!!!!
-- 
Antonio barbone ......
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
		-- Groucho Marx

 casi? Secondo me e' l'esatto contrario...
  Perche`? C'e` differenza nel dire "il C e` un'alternativa al C++ solo
in determinati casi" oppure il "il C++ e` un'alternativa al C solo in
determinati casi"? Se non dai una definizione dei "determinati casi" a
me sembrano due affermazioni totalmente speculari. ;)
	Alla prossima,
		Marco

me sembrano due affermazioni totalmente speculari. ;)
Hai mai osservato l'immagine speculare di una bilancia con un peso su
un piatto e sull'altro no ?
E' un discorso di priorita'.
Io utilizzo come linguaggio di default il C++, non disdegnandone la
parte buona di C che esso possiede (e che non e' totalmente
compatibile con il C standard).

VMS, Dos, o Windows/NT!-)
Esatto, ma se venisse fuori Unix++, volendo imparare ad usare un s.o.
Unix-like, io inizierei da quello ! ;)

C?), argomenti con valori di default e altre amenità del genere.
Hai imparato il C++, e' questo il punto.
Stai utilizzando costrutti del C++, e' questo il punto.
Quando scrivi un ciclo for come lo usi ?
Con:
for (int i = 0 ; ...
Allora stai usando il C++, non il C.
Il fatto che lo usi come un C migliore, non significa che stai
programmando in C. 
Il C++ aggiunge molto al semplice C contenuto in esso. 

 in quanto desidero  colmare il gap che c'=E8 tra me ed i miei
colleghi <snip>
Il C, come linguaggio a se' stante, non e' molto difficile da
imparare, anche se, per un suo uso corretto, ci vuole molta
esperienza.
Per un salto di qualita' credo che tu possa 'irrobustire' le basi
della programmazione, cio' ti permettera' di districarti piu'
agevolmente in qualunque linguaggio tu debba avere a che fare.
Infatti, e credo ne converrai, e' molto importante il <metodo> nella
scrittura di programmi.
Un buon libro e' "Algoritmi + strutture dati = Programmi", di Wirth,
insegna un metodo per la risoluzione di problemi semplici, e la sua
applicazione a problemi piu' complessi.
IMHO il vero salto di qualita' che si puo' fare oggi e' l'imparare UML
e gli strumenti CASE relativi (tipo Rational Rose, per citare il piu'
conosciuto), infatti adesso l'attenzione del mondo del software si
sta' portando dalla programmazione verso il design (che tuttora e'
fatto bene da pochissimi soggetti...), e questo grazie anche ai tools
RAD, come Borland Builder, che permettono allo sviluppatore di
concentrarsi di piu' sul "cosa deve fare l'applicazione" e molto meno
sul "come sviluppare il codice".
Buon lavoro, Andrea
--
UML Unified Modelling Language
RAD Rapid Application Development
 ('< ----------------+-------------------+-----------------
 /V\   Andrea        | arimicci @@       | Inet Abuse Dept.
<(_)        Rimicci  |      aritaly. com |     AR Italy
--~~-+---------------+-------------------+-----------------
     |     Phone & Fax 
+39-019-489197
      /__ /\
_____#__ Male, 33, Italian, C programmer__](__=_`)apx______

 Unix-like, io inizierei da quello ! ;)
Io (nell'ipotesi controfattuale di non conoscere gia` Unix), invece,
non necessariamente.  Dipende.  Ad esempio: Unix si distingue per
la semplicita` del suo filesystem, rispetto a quelli ricchissimi e
complessi di altri sistemi operativi come MVS o VMS.  Uno "Unix++"
che aggiungesse mille ricchi, potenti, complessi "tipi di file",
sarebbe un miglioramento?  Meriterebbe di piu` di essere appreso?
Ne dubito.  I filesystem 'ricchi', tipici ad esempio di VMS, nelle
parole di Thomson, "fill a badly-needed gap".  Non e` questione di
nuovo o vecchio: MVS, piu` vecchio di Unix, e VMS, piu` nuovo,
hanno entrambi gran dovizie di "file-access methods"; invece di
lasciare alle applicazioni (e librerie di livello applicativo) il
compito di 'sovrapporre' eventuale struttura a dei file davvero
semplici ed elementari, queste funzionalita` sono portate nel
sistema operativo stesso.  La mia opinione concorda con quella
oggi piu` diffusa: questa architettura e` sub-ottimale.
Meglio dunque, in questo ipotetico caso, studiare ed usare il
sistema operativo piu` vecchio, che non quello (ipotetico) piu`
nuovo ed arricchito; almeno, secondo me.
Se tutto quel che si puo` dire di C++ rispetto a C fosse "ha
aggiunto della roba", non si potrebbe dunque necessariamente
raccomandarlo senza riserve in alternativa al C.  Si puo`, ma
e` perche` le varie aggiunte sono (nel complesso, e con qualche
eccezione) _ben progettate_, e si integrano fra loro (e con le
caratteristiche pre-esistenti) con buona sinergia; inoltre,
oltre alle varie aggiunte, vi sono alcune strategiche _rimozioni_;
non abbastanza, ahime`, poiche` la stretta compatibilita` C e`
sempre stata fra gli obbiettivi del C++, ma, per esempio, i
vari casi in cui "int" poteva in C essere omesso (con vari
effetti negativi), sono stati rimossi... e` gia` qualcosa.
Alex

gestire appieno questa situazione.
Questo, come la maggior parte di quelli che puoi esibire, è un
problema di libreria, non del linguaggio C in sè.
Scrivendo una piccola funzione (dell'ordine di qualche decina
di righe) o meglio ancora usando un'adeguata libreria che si occupi
dell'allocazione dinamica di memoria alla stringa, posso ottenere
lo stesso identico risultato in C.
E` indubbio che la libreria standard del C++ sia più ricca e più
pulita di quella del C, e che il C++ abbia dalla sua la possibilità
di usare paradigmi multipli (che in alcuni casi ci aiutano a
"organizzare" meglio il progetto e a risparmiare linee di codice)
ma questo non ci autorizza a dire che il linguaggio C++ sia
più "potente" del linguaggio C.
L'unica misura scientifica della "potenza" di un linguaggio di
programmazione è quella che si calcola tramite il raffronto con
strutture teoriche di cui sia stata già matematicamente e
rigorosamente calcolata la "potenza" di calcolo (DFA, LBA,
Macchina di Turing).
E da quel punto di vista, il C++ e il C (e il pascal, il fortran
il basic, e giù, giù fino al linguaggio macchina) sono tutti
linguaggi polinomialmente correlati: non esistono cioè problemi
risolvibili in tempo polinomiale in uno di essi che non siano
anche risolvibili altrettanto "velocemente" negli altri.
Quello che fa la differenza sono solo le librerie disponibili,
i compilatori e le preferenze personali in fatto di paradigmi.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
--
Posted from [212.171.231.27] by way of 
f6.law10.hotmail.com
 [64.4.15.6] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 i compilatori e le preferenze personali in fatto di paradigmi.
Se cosi` fosse, perche` i comitati di standardizzazione dei
vari linguaggi di programmazione lavorano per tante ore, giorni,
mesi, anni -- tutta questa montagna di lavoro, per partorire un
topolino che si riduce alle mere "preferenze personali"?
Eh no.  Se ogni 5-10 anni i linguaggi di programmazione che
si possano dire piu` o meno "vivi" sono soggetti a un altro
round del processo di standardizzazione, e` perche` un
enorme numero di persone e di aziende ritiene di potere
sancire uno standard per un linguaggio *migliore* di quello
precedente: generalmente, si mira a renderlo piu` potente,
e spesso anche piu` sicuro, piu` comodo, eccetera.
Di solito, gli obbiettivi sono piu` o meno tutti questi,
anche se ovviamente non e` detto che in pratica vengano
raggiunti (in tutto, o in parte).  Certo, i risultati
(pratici, e importantissimi) dell'ingegneria del software
non sono pura e astratta matematica, ma fra l'astrazione
matematica da una parte, e le "preferenze personali"
dall'altra, c'e` un'amplissima gamma di realta` concrete,
tecnologiche, nonche` ingegneristicamente importanti.
E la _potenza_ dei diversi linguaggi (e delle diverse
versioni di un linguaggio) e` una di queste realta`.
Alex

e spesso anche piu` sicuro, piu` comodo, eccetera.
Sicuramente! più potente, sempre nel senso "pratico" del termine.
E il fatto che anche il C sia stato recentemente soggetto
a una nuova standardizzazione testimonia che sicuramente non
è un linguaggio morto o "rimpiazzato" dal C++.
Tra l'altro, basta considerare ad esempio due "grossi" progetti
relativamente recenti che vengono portati avanti parallelamente,
uno in C e l'altro in C++ : mi riferisco a gnome e a kde.
Procedono entrambi molto bene, e gnome non ha affatto problemi
rispetto a kde, pur essendo scritto nel "vecchio" e tanto
criticato C.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
--
Posted from [212.171.214.89] by way of 
f77.law10.hotmail.com
 [64.4.15.77] 


 produttività, bensì solo uno teorico-scientifico.
Io, invece (cosi` come, immagino, la grande maggioranza dei
lettori di questo gruppo), ho come principali interessi quelli
pratici (la teoria e` interessante e divertente, ma di per se` non
mi mette pane e salame in tavola).  L'importante, mi sembra, e`
che, a parte il diverso "focus" dei nostri rispettivi interessi, ci
troviamo perfettamente d'accordo: un programmatore e` piu`
produttivo in C++ (chiaramente cio` vale sia se lavora per una
software house, sia se lavora invece sviluppando software per
un'azienda che fa anche altre cose, sia se lavora in proprio,
che sia per hobby oppure come free-lance, ecc ecc), poiche`
puo` risparmiarsi di "badare ai mille trabocchetti del C" (in
realta` anche il C++ ha i suoi specifici trabocchetti, e in piu`
ne eredita alcuni di quelli del C, ma per fortuna il totale resta
ancora inferiore:-).
Alex

produttivo in C++
Sì, siamo d'accordo sulla maggiore produttività, senza dubbio.
Rimangono comunque certe aree di sviluppo in cui tutt'ora
c'è di fatto un uso pressochè esclusivo del C: in particolare
il kernel developing e la scrittura di compilatori (aree quindi,
in cui c'è una fase molto intensa di debugging).
Riguardo al kernel developing ad esempio è interessante notare
che sia Cutler che Linus hanno più volte ribadito che
intendono continuare a usare il C (anche ora che il C++ è
stato standardizzato) ed evidentemente hanno i loro
buoni motivi per farlo: in rete c'è una piccola intervista a
Linus in proposito (tradotta in italiano dal pluto journal).
L'url è 
http://ftp.pluto.linux.it/journal/pj9807/linus.html
(ultima domanda, alla fine del testo).
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com
--
Posted from [213.45.221.139] by way of 
f127.law10.hotmail.com
 [64.4.15.127] 


 wrote in message
[...]
| Rimangono comunque certe aree di sviluppo in cui tutt'ora
| c'è di fatto un uso pressochè esclusivo del C: in particolare
| il kernel developing e la scrittura di compilatori (aree quindi,
| in cui c'è una fase molto intensa di debugging).
Guarda il BeOS: confronta le prestazioni del Kernel in C++ con quelle del
kernel in C di Linux.
E considera il vantaggio di poter usare il C++ per la manutenibilita'...

 E considera il vantaggio di poter usare il C++ per la manutenibilita'...
Se il C++ e` usato in modo totalmente appropriato, certo.  Non
va scordato che il C++ *permette* le stesse astrusita` (che sono
poi difficili da manutenere) del C, se non anche di piu`, se viene
usato senza disciplina.  Non e` certo un linguaggio che IMPONE
l'approccio giusto (nessuno ci riesce, ma il C++, come il C, non
ci prova neppure, mentre altri, come Eiffel, ci provano:-).
Le osservazioni di Thorvalds sul C++, riportate nell'intervista
citate in questo thread, ricalcano in modo impressionante un
mio rapporto tecnico (ad uso interno dell'azienda) del 1991, in
cui, sostanzialmente, concludevo: no, non e` ancora maturo,
per [le ragioni che Thorvalds riporta oggi].  Solo che la mia
conclusione di allora era: quindi non possiamo usarlo oggi in
codice di produzione; ma, visto che maturera`, continuiamo i
progetti-pilota, di ricerca, per monitorare il suo stato di sviluppo,
e sviluppare quella maturita` di comprensione del linguaggio
che ci permettera` di usarlo al meglio quando sara` tempo.
Nove anni dopo, la situazione e` drasticamente cambiata, e
solo in meglio.  Escono i primi compilatori+librerie che
promettono 100% di compliance con lo standard (IBM Visual
Age C++ 5), e il livello "99%" e` sostanziamente garantito
su tutte le piattaforme di interesse.  Sappiamo ormai, sia
collettivamente sia individualmente, quali parti del linguaggio
vanno sposate senza riserve, quali usate solo con estrema
parsimonia, quali ancora restano immature nelle attuali
implementazioni benche` ben progettate nello standard
(locale e facet:-) o anche destinate a restare immature almeno
sino alla prossima revisione dello Standard in quanto NON
ben progettate (valarray:-).  E` quindi un curioso segno di
miopia ripetere nell'anno 2000 critiche che avevano certo
una loro, temporanea ma cruciale, validita` 8-9 anni fa:-).
Alex

 una loro, temporanea ma cruciale, validita` 8-9 anni fa:-).
Allora riscrivi il kernel di linux in c++ e dimostra a Thorvalds che i problemi
da lui incontrati sono solo storia di 9-10 anni fa ,
del tutto obsoleti nell 'attaule contesto informatico e che oggi si puo' fare
di meglio di quanto lui nella sua "curiosa miopia"
sia in grado di poter fare :):)
Ivan Molella

 sia in grado di poter fare :):)
La mia opinione di coloro che forkano un progetto open source
(soprattutto se l'unica vera motivazione e` un dissenso tecnico
col project leader), ed e` una diffusa percezione di questo
atto nella comunita` open source, e` tale che questo tuo
"spiritoso" suggerimento equivale grosso modo a suggerire a
qualcuno di tagliare la coda a qualche gatto per strada (se
non peggio) se vuol davvero dimostrare che l'acciaio taglia
meglio del bronzo.  (La quantita` di lavoro necessaria per
riscrivere un kernel, e quella necessaria per catturare i
felini in questione, possono essere equiparate, in prima
approssimazione; dipende anche dal numero di gatti in gioco).
Se hai altre idiozie, o "argomenti ab auctoritate" (e spero
che questa fallacia logica sia a tutti ben nota come tale?),
da proporre, accomodati.  O alternativamente, per dimostrare
che il C e` altrettanto adatto del C++ a scrivere framework
per compilatori, riscrivi ANTLR in C, che ne dici?  Mi sembra
una contro-proposta piu` ragionevole della tua, visto che
ANTLR e` un progetto meno ampio del kernel di linux.
Alex

สวัสดีครับ 
Ehm... coff coff....
Prima di startare un flame (brutta cosa), ricordiamoci di Turing, e
smettiamo di dire che un linguaggio e' <meglio> di un altro.
Con il C si possono fare certe cose, e con il C++ se ne possono fare
anche altre. Punto e basta.
Usare il C++, l'ereditarieta' multipla, l'information hiding, per poi
stampare "Hello, world!" su di un display, non serve a molto.
Nel senso che le cose vanno usate solo quando servono, e non
semplicemente perche' 'sono disponibili'.
Se un kernel scritto in C funziona bene, e' leggibile, e' mantenibile,
spostarne il codice al C++ e' una cosa che si potra' fare solo se sara'
davvero necessario e, allo stato attuale, il kernel di linux non mi
sembra che abbia quella necessita' impellente.
Il C++ ha tante belle cose, ma ha anche molte piu' insidie nascoste, e
per un azienda che deve sviluppare codice che deve essere mantenuto
negli anni, si vuole evitare ogni tipo di problema. Per questo molto
spesso chi usa il C++ si limita giusto all'uso delle classi e, qualche
volta, dell'ereditarieta', e lascia da parte tutti i discorsi
accademici, come le classi basi totalmente virtuali con ereditarieta'
multipla e costruttori virtuali di classe derivata, con overloading dei
relativi operatori. Se un domani occorre fare una modifica al codice,
che si fa? si perde mezza giornata a capire dove mettere le mani ???
O si cerca lo sviluppatore che lo aveva realizzato ??? [sperando che
sia ancora in azienda!]
Andrea
 ('< ----------------+-------------------+-----------------
 /V\   Andrea        | arimicci @@       | Inet Abuse Dept.
<(_)        Rimicci  |      aritaly. com |     AR Italy
--~~-+---------------+-------------------+-----------------
     |     Phone & Fax 
+39-019-489197
            /__ /\
_____#__ Male, 33, Italian, C programmer________](__=_`)apx

 sia ancora in azienda!]
Questi problemi sono tipici del software complesso (che e`
altrettanto, se non piu` spesso, espresso in linguaggi puramente
procedurali).  Per evitarli, spingere a tavoletta l'acceleratore
della semplicita`, usando le tecnologie appropriate per
ottenere questa semplicita`.  (Ci sono rimedi preventivi
anche per il problema di "ma questa parte chi e` che la
conosce bene": 
www.xprogramming.com
 e i tanti altri siti
della nuovissima moda, "Extreme Programming", possono
servire a spiegarli, ma personalmente suggerisco l'ottimo,
leggibilissimo libro "Extreme Programming Explained", di
Beck; ma la chiave di tutto e` *la semplicita`*).
Alex

Ciao a tutti,
  Come apparira` chiaro ai piu`, questo thread e tutti i suoi child sono
decisamente *off* *topic* in questo gruppo, il cui argomento non
comprende discussioni sulle comparazioni tra il C ed altri linguaggi
ovvero sulle nuove tecnologie di sviluppo del software.
  Poiche` e` possibile continuare quella che sembra una simultanea
contro Alex Martelli anche utilizzando mezzi telematici o non che non
sovraccaricano risorse pubbliche come UseNet, vi invito tutti a
considerarne uno come alternativa ed iniziare a farne uso.
  Io l'ho fatto con la posta elettronica privata e, finche` il tempo
me/ce ne ha dato la possibilita`, la discussione e` proseguita
interessantemente.
  Consideratelo un consiglio spassionato: non vorrete passare tutti per
/troll/, vero? ;)
	Alla prossima,
		Marco