Newsgroup: it.comp.lang.c++
Titolo: parere

 
http://www.netservers.com/~agriff

 > programmazione C++ o peggio sulla programmazione in genere.
Concordo.
Ciao,
Nicola

 sinceramente interessato a piu' opinioni di esperti.
Non sono un esperto però nelle frasi che hai riportato non mi sembra di
vedere grossi strafalcioni, anzi. Quali sono esattamente i punti su cui
dissenti?
EMG

 sinceramente interessato a piu' opinioni di esperti.
Vuoi sapere se Schildt è ritenuto un autore valido per il C++? Qui da noi
non è molto stimato, e non solo qui.
Scrive bene e in modo comprensibile, ma è autore di sviste grossolane che
possono non causare danni ad un programmatore "esperto", ma possono causarne
di gravissimi ai principianti. Per questo mi trovo a concordare con Andrea
su Schildt.
Per il resto, non ho letto quell'articolo su Dev, ma se se ne parla male, un
motivo ci sarà (corro a leggerlo...).
Ciao
Domenico Barra

Grazie.
Mi basta.
La mia non voleva essere una richiesta di levata di scudi verso
qualcuno(forse ho dato questa impressione per aver lasciato il nome
dell'autore), ma un sincero sondaggio su Schildt e le sue opere, che
invece negli anni, mio malgrado, mi sono trovato piu' volte a
suggerire per i neofiti approfittando appunto del suo approccio
didattico, del fatto che nel panorama letterario attuale  "scrive
bene" mantenendo un congruo linguaggio specifico, e che contempla(va)
anche argomenti di calcolo a volte molto ricercati.
Grazie mille.

di che numero di Dev si trattava?
    Rony.
--
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
"Solo due cose sono infinite,
l'universo e la stupidita' umana,
e non sono sicuro della prima."
Albert Einstein

    Rony.
DEV Luglio/Agosto 1999
Titolo:
  Array associativi
Sottotitolo:
  Gli array associativi: che cosa sono e come
  costruirne uno in C++
Autore:
  Andrea T.M. Frosini


cominciare col C++ vero e proprio.
hehehe... falsa modestia ? Io ho iniziato a guardare seriamente il
C++ solo nel 2000 e ho iniziato a scrivere qualcosa che sia piu'
di semplici esperimenti solo pochi mesi fa.
Ho usato per un po' di tempo il "C con le classi" ovvero un
sottoinsieme molto ristretto del C++ (non avevo mai usato reference,
mai usato overload di operatori, mai usate istanze che non fossero
allocate sullo heap, mai usate restrizioni di accesso, mai usati
namespace, mai usate exceptions, mai usata multiple inheritance,
mai usati template e mai usata la libreria standard C++)
Prima del "C con le classi" ho usato per molto tempo C ANSI in modo
object-oriented ricostruendomi quello che mi serviva (es. late
binding) utilizzando quello che passava il convento (es. puntatori
a funzione).
Questo basterebbe a rendermi un "guru" del linguaggio C++ ?
Spero che si trattasse di sarcasmo che non ho capito :DDD
Dei guru mi mancano soprattutto le cicatrici da battaglia (anche
se qualche sberlone dal C++ ho cominciato a prenderlo).
Come si dice... "in teoria non c'e' differenza fra la teoria
e la pratica, ma in pratica la differenza c'e'".
...
Riguardo all'autore di questo posting, credo che che mi stia
odiando con tutte le sue forze da quando ho detto che secondo
me una sua miglioria di una gestione stack che non faceva
controlli era in realta' un netto peggioramento (la sua
versione evitava sconfinamenti e potenziali crash, ma facendo
passare sotto silenzio la cosa - ovvero *nascondendo* gli
eventuali errori logici).
Si tratta di qualcosa che ho visto spesso... la confusione
fra cosa e' un crash e cosa e' un errore, la perversione di
curare i sintomi invece della malattia.
Da quel posting, in cui forse ho esagerato un po' con il
tono (ma in cui non credo di aver esagerato con il contenuto),
e' iniziata una strana lotta di cui vi risparmio i penosi
dettagli (il tutto ormai e' stato consegnato all'eternita'
di dejanews) e fra le altre cose e' saltato fuori il nome di
Schildt e frasi sul tono di "tu non sai chi sono io...
appena vedrai i miei titoli e la mia professione ti si
gelera' il sangue nelle vene!!!".
Non posso che provare pena per le vittime di questo
pressapochista della programmazione e un po' di rabbia per
la figura che ci fa la categoria dei programmatori.


anche argomenti di calcolo a volte molto ricercati.
Schildt si impegna. Puo' fare molto piu' a detta di molti, ma dopo
aver letto 
http://www.lysator.liu.se/c/schildt.html
 ho perso tutta la
fiducia. Sara' anche bravo a scrivere, ma se proprio devi scrivere,
almeno scrivi cose giuste :)
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

ho letto sul tuo sito (ah, complimenti per il sito!) le mail che vi siete
scambiati, però mi sembra che la risposta dell'autore non fosse del tutto
spiantata.
considera il target di DEV... con tutto il rispetto, ma alcune cose vanno
prese con le pinze; chi può pensare di imparare a programmare BENE con una
rivista di 50 pagine, in particolar modo da un articolo di n pagine (con
2<=n<=5, suppongo)?
DEV suggerisce varie hints per iniziare, ma per far qualcosa di decente è
necessario documentarsi un po' più degnamente... trovo semmai più grave che
un LIBRO sul C contenga tutti gli strafalcioni citati in
http://www.lysator.liu.se/c/schildt.html
.
N.B. detto da uno che NON sa programmare bene, ma che assume che non se la
caverà con DEV, e preferisce leggere lo Stroustrup.
cordiali salumi a tutti.
    rony.


   costruirne uno in C++
Testo:
#include <map>
Hey, devo mettermi a scrivere articoli! E' cosi' facile... :-)
Ciao,
Nicola

la figura che ci fa la categoria dei programmatori.
Non credo che la categoria dei programmatori ci faccia in se una grande
figura. Almeno non in confronto alla categoria dei valutatori (leggi 
professori) che assegnano i titoli e dei recruiter (leggi boss) che 
assumono dei curriculum invece che delle persone. I primi non li salvo. 
I secondi li salvero' nel momento in cui vedro' un curriculum di tre
pagine
con allegato diploma di laurea e certificati vari sviluppare un sistema.
-- 
Posted from 
adsl-21-135.38-151.net24.it
 [151.38.135.21] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

tutto spiantata. considera il target di DEV...
Tu non hai letto l'articolo vero ?


certificati vari sviluppare un sistema.
Guarda che avere una laurea non e' sempre detto che significhi essere
un incapace; mi spiace vedere questo astio. Il problema e' che non
si puo' generalizzare. Gli imbecilli non stanno di qua o di la dalla
laurea... purtroppo stanno ovunque !!!! :D ... per fortuna questo
vale anche per le persone serie.
                   OGNI generalizzazione e' un errore
(non male come generalizzazione eh ? ;) )
Andrea
(laureato)


 con allegato diploma di laurea e certificati vari sviluppare un sistema.
Se non altro i secondi hanno un compito piu' difficile.
Ciao,
Nicola

no, ma ho letto le tue argomentazioni contro di esso.
si trattava di osservazioni pertinenti; ovviamente di qualcuno che la sa
lunga... o forse non ci vuole molto a capire che non č il caso di fare una
realloc ad ogni inserimento in un array... perň conosco piů o meno la
rivista e ho letto la risposta dell'autore.
io non entravo nel merito della struttura dati...
quello che sostenevo č solo che ci sia poco da scandalizzarsi per DEV, e piů
per i libri "teorici".
probabilmente un articolo di Knuth avrebbe affrontato l'argomento
diversamente.
avendo a che fare con l'informatica e con il settore del mondo del lavoro ad
essa connesso, mi pare che i problemi siano altri.
    rony.
P.S. ho visto la sezione Demo, e rinnovo i complimenti per il sito. conosci
un certo "manta"?


disciplina personale ne ho incontrate proprio poche.
Non ci crederai, ma io invece ho incontrato pochissime persone che
uscite dall'universita', riuscissero anche solo a ricordare cos'e' la
cpu. Se credi che sia l'universita' a fornirti le conoscenze su COME
vadano costruiti i programmi, a mio avviso, ti sbagli.
Io conosco fior di ingegneri e dottori che lavorano per case software
medio-grandi, che sono stati capaci di progettare le migliori porcate.
Non mi posso sentir dire "abbi un po' di pazienza, sai e' appena
uscito dall'universita'", come se fosse giusto che io, da
"programmatorus praticus" debba avere compassione di uno che ha solo
studiato e mai messo in pratica.
Mah... sara' che hai ragione tu, ma io ho visto case costruite da
semplici muratori stare in piedi fieramente e case costruite da
ingegneri disfarsi in mille pezzi.


 >disciplina personale ne ho incontrate proprio poche.
Concordo... ma si tratta di esperienze personali... e direi che quelle di
Nicola e le mie non debbano valere più di quelle di Andrea.
Rony.

vaga offesa -> vox media -> complimento.
Smanettone non e' mai stata un'offesa.
E' la traduzione + o - azzardata del termine "Hacker" che non vuol
dire "Cracker", come molti pensano. (v. Jargon File).


 dire "Cracker", come molti pensano. (v. Jargon File).
Veramente anni fa entrambe i termini erano intesi nel senso di
"pasticcione"; solo in seguito hacker ha assunto il significato prima di
pirata (gli hacker erano quelli che scrivevano i virus) e solo
recentemente ha assunto il senso attuale.
Ciao,
Nicola

 malapena.
Intravedo sotto questa svalutazione degli ingegneri un certo senso di
frustrazione e di insofferenza. Va beh, tiriamo avanti: il fatto che tu
tenga corsi a persone laureate in ingegneriainformatica non vuol dire che tu
sia un gradino sopra di loro, ma  semplicemente che conosci meglio
l'argomento specifico. Chi esce da ing. inf. non è un programmatore per il
semplice fatto che all'università non si è occupato solo di programmazione.
Personalmente ammiro la tua competenza quando si parla di ereditarietà e di
costruttori virtuali, ma ti assicuro che spesso il mestiere di
programmatore, per chi si laurea in ing., è solo il primo gradino della vita
professionale.
Sinceramente mi dispiace sentire fare questo genere di discorsi tra l'altro
anche abbastanza sgradevoli nei confronti di quella ragazza che chiedeva
informazioni sul compilatore e che tu hai strumentalizzato come esempio di
"universitaria brocca".
I brocchi e i geniacci sono uniformemente distribuiti tra i laureati e i
non, e buttare nel secchio chi ha deciso di studiare mi sembra ingiusto.
Tanto più che tu stesso ammetti di averci provato... se poi era così inutile
potevi evitare la fatica dall'inizio?!?

recentemente ha assunto il senso attuale.
No, niente affatto.
La cultura hacker e' nata al MIT negli anni 60 e il termine in
questione HA SEMPRE significato "programmatore in gamba", mai
"pasticcione". Il significato di "pirata" e' errato ed e' stato
affibbiato dai media (quelli che hanno intenzioni maligne sono i
CRACKER, non gli HACKER).
Dal "Jargon File" :
hacker n. 
[originally, someone who makes furniture with an axe] 1. A person who
enjoys exploring the details of programmable systems and how to
stretch their capabilities, as opposed to most users, who prefer to
learn only the minimum necessary. 2. One who programs enthusiastically
(even obsessively) or who enjoys programming rather than just
theorizing about programming. 3. A person capable of appreciating hack
value. 4. A person who is good at programming quickly. 5. An expert at
a particular program, or one who frequently does work using it or on
it; as in `a Unix hacker'. (Definitions 1 through 5 are correlated,
and people who fit them congregate.) 6. An expert or enthusiast of any
kind. One might be an astronomy hacker, for example. 7. One who enjoys
the intellectual challenge of creatively overcoming or circumventing
limitations. 8. [deprecated] A malicious meddler who tries to discover
sensitive information by poking around. Hence `password hacker',
`network hacker'. The correct term for this sense is cracker. 
The term `hacker' also tends to connote membership in the global
community defined by the net (see the network and Internet address).
For discussion of some of the basics of this culture, see the How To
Become A Hacker FAQ. It also implies that the person described is seen
to subscribe to some version of the hacker ethic (see hacker ethic). 
It is better to be described as a hacker by others than to describe
oneself that way. Hackers consider themselves something of an elite (a
meritocracy based on ability), though one to which new members are
gladly welcome. There is thus a certain ego satisfaction to be had in
identifying yourself as a hacker (but if you claim to be one and are
not, you'll quickly be labeled bogus). See also wannabee. 
This term seems to have been first adopted as a badge in the 1960s by
the hacker culture surrounding TMRC and the MIT AI Lab. We have a
report that it was used in a sense close to this entry's by teenage
radio hams and electronics tinkerers in the mid-1950s. 


 aiuta a capirlo *approfonditamente*.
Per me il problema è molto semplice: se conosco già il C, nel passaggio
al C++ posso trovarmi avvantaggiato per determinate cose e svantaggiato
per altre (OOP). Se non conosco il C e oggi voglio cominciare a studiare
il C++ allora devo cominciare con quest'ultimo e non avrebbe senso
iniziare con il C. Tanto più che vedo che anche all'Università oramai
insegnano (si fa per dire!) direttamente il C++.
EMG

Ho letto, ma non mi interessa molto: io ti dico come il termine hacker
e' stato interpretato dagli informatici italiani negli ultimi vent'anni.
Giusto o sbagliato rispetto a presunti canoni, e' nelle accezioni che ti
ho descritto che il termine veniva usato quand'ero all'universita'.
Il tipico esempio di hacker o smanettone era uno che prima prova e poi
legge il manuale.
Ciao,
Nicola

potevi evitare la fatica dall'inizio?!?
No ho mai detto che studiare e' inutile, io mi sono iscritto
all'universita' perche' studiare mi e' sempre piaciuto, per me non e'
mai stato (lo dico rischiando di passare per immodesto) una fatica e
sono sempre stato dalla parte di chi studia.
Certo che potevo evitare la fatica dall'inizio, ma non potevo certo
prevedere i gravissimi problemi (estranei all'universita') che ho
avuto a breve distanza dal primo esame. Una di quelle situazioni nelle
quali ti e' abbastanza difficile mantenere il cervello sveglio.
Fortunatamente nel tempo mi sono reso conto che riesco a fare il mio
lavoro anche senza il supporto dell'universita'.
Chiuderei qui la questione, dilungatasi fin troppo in un off-topic.
Torno nel cerchio infuocato dei programmatori ad invidiare il paradiso
degli ingegneri.
;)


un certo "manta"?
Thanks :) ... io non sono un profondo conoscitore
dell'underground del coding... ho qualche amico "nel giro"
ma quel nick mi suona nuovo.
Andrea "6502" Griffini :DDDD


(laureato)
Per merito tuo, non del tuo esaminatore. Credo che concorderai.


Se non altro i secondi hanno un compito piu' difficile.
Essere un buon insegnante/valutatore e' altrettanto se non piu'
difficile che
essere un buon recruiter/valutatore. La differenza e' che uno scarso
valutatore
puo' essere lo stesso un buon insegnante, ma non puo' essere un buon
recruiter.
Ripeto: laurea/universita' non sono "cattive" e neppure "inutili" sono 
semplicemente "insufficienti". L'errore principale e' considerare la
laurea
una garanzia. Non lo e'. Un buon laureato non e' una persona che "ha
imparato", 
e' una persona che molto probabilmente "sa imparare". Che poi abbia o
meno
imparato e' un altro discorso. Inoltre non vale la proprieta'
riflessiva: 
l'assenza di laurea non e' assenza di conoscenza o capacita'.


dire "Cracker", come molti pensano. (v. Jargon File).
Ti bacerei sulla bocca!
Sono quasi 10 anni che litigo su questo punto con giornalisti e "dotti"
in genere (chissa' perche' soprattutto quelli provenienti dalla "cultura
progressista di sinistra") e continuo a strapparmi i capelli ogni volta 
che mi tocca leggere un articolo dove si fa uso del termine hacker!



Sappiamo tutti che hacker in italia (e in parte anche in america, a
iniziare
dal famigerato internet-crackdown) e' un termine che viene usato nel
modo 
sbagliato. Ma il fatto che il 90% delle persone non sappiano cosa
significa 
hacker non ne cambia il significato.
Altro esempio: cosa significa il termine italiano "affatto" ? Chiedilo a
100
persone e ascolta le risposte. La maggior parte ti dira' che significa
"per 
niente". 
Vai a consultare il dizionario e scoprirai che significa l'esatto
opposto.
Affatto significa: "completamente", "del tutto".
Anche se la maggior parte degli italiani capiscano roma per toma se si
trovano davati ad una frase del tipo: "Oggi sono affatto contento!" (che
interpreteranno quasi immancabilmente per la sua negazione "Oggi NON
sono
affatto contento!") non significa che la frase abbia questo secondo 
significato. Significa solo che non conoscono l'italiano.


> si dicono cose *false* vestendole bene si fanno danni gravi.
Ne approfitto per dire brevemente la mia, quotando il testo originale
di Andrea Griffini. Ammetto sinceramente di non aver mai letto nessun
libro di questo famigerato Schildt, ed infatti pur avendone sentito
parlar male praticamente ovunque mi sono sempre astenuto da commentare
i giudizi negativi espressi dalle persone che ne parlavano. Tuttavia
mi sembra un pò esagerato pensare che i programmatori possano essere
fuorviati dalle nozioni errate tanto da imparare cose sbagliate e
pregiudicare la loro carriera. Chi decide di imparare la
programmazione attraverso i libri di testo sa benissimo che nessun
libro potrà mai essere perfetto, sicuramente tutti conterranno o delle
inesattezze o delle carenze sotto alcuni punti di vista, il compito di
riscontrare e verificare ciò che impara dai libri sta al programmatore
stesso, che lo deve fare sperimentando oppure documentandosi tramite
il maggior numero di fonti che ha a disposizione.
Chi spera di imparare i concetti di programmazione(in qualsiasi
linguaggio) affidandosi solamente alla lettura di un libro o ad una
sola categoria di libri(in questo caso i libri del signor Schildt)
dedicando anima e corpo ad essi parte sicuramente con il piede
sbagliato, visto che le sue conoscenze alla fine dipenderanno
solamente da quello che le sue fonti gli offrono, percui penso che se
questo Schildt scrive cose errate i suoi libri vadano sicuramente
evitati, ma mi sembra un pò ridicolo imputargli la colpa di aver
distorto le povere menti dei programmatori che hanno avuto a che fare
con i suoi testi.
Il Ghenio
WINWORD.EXE - ERRORE DI APPLICAZIONE
l'istruzione a "0x3017ff27"ha fatto riferimento alla
memoria a "0x02a3143c".La memoria non poteva essere 'read'.

2<=n<=5, suppongo)?
Nessuno credo. Per imparare a programmare non bastano le rivistine
come quella, e comunque non mi pare che DEV si rivolga ai
principianti. Sulla qualità degli articoli postati non mi pronuncio,
finora ho acquistato solo due numeri e sinceramente di articoli sul
c++ ne ho visti ben pochi.


Ti bacerei sulla bocca!
No grazie :))


 l'assenza di laurea non e' assenza di conoscenza o capacita'.
D'accordo. Ma la garanzia di avere d'avanti una persona che "sa
imparare" vale moltissimo. Purtroppo l'universita' italiana questa
garanzia non la da'.
Ciao,
Nicola

 significato. Significa solo che non conoscono l'italiano.
No, significa che conoscono l'italiano di oggi e non quello di due
secoli fa.
Ciao,
Nicola

garanzia non la da'.
Ecco. Appunto!


 differenza ...
Cioe': quello che dici e' vero solo se i metodologi hanno un *mare* di
esperienza pratica.
Ciao,
Nicola

intenderci.
anche se stiamo scadendo nell'OT, mi puoi spiegare brevemente com'è il
paradigma funzionale? E' supportato dal C++?
anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.44, higher than 97% of all previous test takers.
Visual Basic 5: 3.06, higher than 77% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

e di programmazione ad oggetti.
Conosco A.T.Frosini da molti anni ormai, anche se solo via email.
Questi giudizi assoluti li trovo francamente eccessivi, sopratutto se
non conosci di chi stai parlando.
E non e' una questione del "non sa con chi stai parlando", ma e'
proprio una questione del "non sa con chi stai parlando".
Personalmente il mio primo articolo per una rivista infomedia l'ho
scritto nel 95. Ti assicuro che dormo benissimo la notte, anche se mi
rendo conto che in passato ho scritto delle fesserie. Non mi sento in
colpa se non so tutto. Non mi sento in colpa se ancora oggi dico delle
fesserie (recentemente ho detto una cosa sbagliata ad un lettore su
cose che riguardano i DB). Se l'alternativa e' il niente, perche' chi
sa non vuole perdere tempo a scrivere articoli, allora (per me) e'
meglio provarci.
Le mie valutazioni sulla conoscenza della programmazione di Frosini si
basano su un lustro di articoli, e non su uno. Quello non e' un gran
che come articolo? Pace. Non generalizziamo pero', per favore. Frosini
non vuole usare il C++ come linguaggio ad oggetti? Pace, ognuno e'
libero di vedere il mondo come crede. Ognuno e' libero di comunicare
il suo pensiero. Ognuno e' libero di criticarlo. Non pero' di
esagerare passando sul piano personale (ma sono un pessimo pulpito per
prediche simili n.d.p.)
Tra l'altro trovo alcune tue considerazioni corrette, e altre corrette
solo ed esclusivamente se consideri "giusto" un approccio OO. Sulla
mitizzazione del data hidding avrei parecchio da dire, (e in realta'
su tante cosette della OO). Personalmente, da quando ho incontrato la
Extreme Programming, considero la OOP sbagliata nei fondamenti
filosofici che ci sono alla base. Ho riletto con le mie convinzioni di
oggi il libro di Pescio "Manuale di Stile". C'e' molto dogmatismo in
quel libro. Quello e' un libro "pratico" che prenderei ad esempio su
come pensare ad OO. Pescio, anzi le idee di Pescio, sono comunque un
mio punto di riferimento. Anche se non le condivido piu'.
Infondo il piu' saggio di tutti e' Stroustrup. Se uno vuole usare il
C++ come un C migliore e' liberissimo di farlo. Per me non esiste mai
"una" strada ottima, ma solo un insieme vario di strade buone, meno
buone, e pessima. Ma mai una ottima (tranne negli articoli).
++++
Dal momento pero' che non mi piace la gente che mi aspetta con un
bastone in mano, non parlero' mai male pubblicamente dell' OO.
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

bastone in mano, non parlero' mai male pubblicamente dell' OO.
Nessuno ti bastonera' se parli male di OO. Anzi: se dici che l'OO non
funziona in un contesto in cui la programmazione srutturata o l'Extreme
Programming sono di casa, potresti persino sentirti dare ragione. Pero'
se cerchi di applicare l'Extreme Programming per risolvere i problemi
per cui e' nata la OO, le bastonate rischi di tirartele da solo.
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


 paradigma funzionale? E' supportato dal C++?
Non sono la persona piu' adatta a rispondere in dettaglio. In soldoni
l'idea e' che la programmazione avvenga esclusivamente attraverso
chiamate di funzioni che calcolano il proprio valore in base ai dati di
ingresso, *senza* effetti collaterali.
Il C++ non la supporta direttamente, anche se esistono librerie
orientate in questo senso.
Ciao,
Nicola

bastone in mano, non parlero' mai male pubblicamente dell' OO.
Boh... io queste paure di dire cio' che penso non le ho.
Andrea


Per merito tuo, non del tuo esaminatore. Credo che concorderai.
Non ho capito il senso di questa tua frase...


Non ho capito il senso di questa tua frase...
Si riferiva al fatto che sei laureato. E a da quello che scrivi
sei un laureato che si e' fatto il mazzo. Quello vero non il
"mazzo minimo" (stile CEPU).
Quindi il valore della tua laurea deriva dal tuo merito, e non 
dall'esame (o meglio gli esami) che in se non sono, purtroppo,
sufficienti a garantire nulla sulla tua effettiva 
preparazione/capacita'.



Se questa e' la tua definizione allora C e C++ lo supportano
benissimo. Ed e' esattamente quello che intendevo io inzialmente
parlando di uso del C++ con filosofia (o se preferisci paradigma)
funzionale.
Mi hai corretto dicendo che con paradigma funzionale si intende quello
del Lisp.
In lisp c'e' qualche cosina di piu' che una programmazione "a
funzioni" che non creano side effects (a parte che anche in lisp puoi
avere situazioni di side effects, perlomeno sulle associazioni
"permanenti" agli atomi che tanto per mischiare un pochino i thread
altro non e' che un array associativo a livello di sistema!).
Per rispondere invece alla domanda: se si intende "programmazione
attraverso funzioni" il concetto base e' tutto li.
Se si intende la filosofia del LISP, dovrebbe essere facile trovare
testi che spiegano questo linguaggio, ma forse puo' essere utile "a
priori" cercare qualche testo sul lambda calcolo.
Qualunque buona libreria scientifica o universitaria dovrebbe avere
titoli disponibili (o richiedibili).

Programming sono di casa, potresti persino sentirti dare ragione.
Ci sono concetti "filosofici" di base non conciliabili.
E' evidente che una teoria puo' permettersi di essere "estrema",
mentre nella realta' e' meglio andarci con i piedi di piombo.
Il progettista, essere senziente, deve decidere di volta in volta.
Personalmente odio chi ha la verita' in tasca, e mi sono scocciato di
sentire gente che tira fuori le parole magiche (OO, WAP, XML e chissa'
cosa altro n.d.p.).
Tu, in questa sede publica, mi vedrai sempre replicare stizzito a chi
afferma che le variabili globali o i goto sono da evitare
"assolutamente". Se ho voglia di replicare naturalmente. Spesso si
sentono queste affermazioni. Per me sono semplicemente cose da
evitare, salvo contesti particolari, e mi guardo bene dal dire che
sono sbagliati se li incontro. Decido volta per volta.
Prendi il caso "mitico" del pattern singleton. E' cosi' brutto
scrivere:
// file xxx.cpp
namespace
{
   //dati locali al modulo eventualmente inglobati una classe
  //definita dentro questo namespace anonimo
   ...
}
Funz1()
Funz2()
Funz3()
Funzioni globali invece di una classe istanziabile solo una volta, o
un wrapper su una classe istanziabile una volta sola (con paranoie sul
costruttore privato, o sugli oggetti statici).
Questo non e' OO, e' puro e semplice VB.
Se mi sento dire che questo e' sbagliato per un motivo, ascolto
attento il motivo e decido. Se mi sento dire che e' sabgliato perche'
non e' OO scrollo le spalle (le piume n.d.p.)
"Quelo" mi dice la seconda che ho detto


 non e' OO scrollo le spalle (le piume n.d.p.)
Se ti dicono che e' sbagliato perche' non e' OO ti dicono una cavolata
pertanto fai bene a scrollarti le piume. Ma i casi che puoi affrontare
con le soluzioni da te proposte sono solo alcuni di quelli gestibili
con un singleton. Inoltre una cosa e' l'OO e un'altra sono i pattern.


 sbagliando la sintassi
per il semplice motivo che sono io a portare questo argomento?
Libero di pensare che io sono un folle, ma ci andrai piano a giudicare
cosi' anche cio' che sta intorno a me come follia. Infondo programmo
anche in C++ :-)
Non e' offendendo che si puo' instaurare una discussione pacata e
costruttiva. Personalmente mi ritengo offeso da un modo simile di
porre la questione.


 porre la questione.
Questo e' la cosa che piu' mi spiace. Ancor piu' delle vicende legate
all'articolo che ha scatenato la cosa.
--


porre la questione.
Mi spiace un poco. Non capisco cosa ho detto di cosi' terribile
nei confronti di Frosini.
Non credo che tu ti debba necessariamente sentire obbligato
a distruggere le statue di Frosini che tieni in cortile
(era una battuta :D )


fregare di meno di essere un bravo programmatore C++ n.d.p.).
Ma allora perché scrive articoli sul C++, peraltro su argomenti
piuttosto complessi e dedicati come gli array associativi?


non e' OO scrollo le spalle (le piume n.d.p.)
Qui condivido in pieno l'atteggiamento.


e piu' tempo libero) l'eventuale approfondimento in merito.
Putroppo, per un programmatore, "piu' tempo libero" corrisponde
secondo me al 30 di Febbraio (questa triste realta' e' una cosa
da tenere presente quando c'e' la tentazione di scrivere una
"porcata" per mettere una pezza dicendo a se stessi "lo sistemo
meglio dopo, quando avro' piu' tempo"...)


 meglio dopo, quando avro' piu' tempo"...)
io concordo in pieno, ma vaglielo a far capire alla M$ e al suo good 
enough software... 
:(

 :(
Anche io concordo. Ma non ho capito il riferimento a M$. E soprattutto
quello al good enough SW.


 meglio dopo, quando avro' piu' tempo"...)
E altri casi simili: "ora scrivo il codice, poi scrivero' i commenti".
Senza rendersi conto che la maggior parte del codice che scrivi lo
scrivi perche' non hai mai avuto il tempo di scrivere i commenti al
codice scritto in passato.
Ecco dove (per richiamare una parte di discussione che forse veniva da
un altro thread e forse non era fra me e te, o forse si) entra in
gioco il concetto del pseudocodice. Il linguaggio di programmazione e'
talmente "formalizzato" che ti dice un sacco di cose. Scrivere in
pseudocodice ti obbliga a "spegare" invece che "codificare".
La scelta e' fra: codificare e poi commentare (sempre che si riesca a
evitare la trappola del "commento poi").
E l'alternativa: pseudo codice prima, codice dopo. In questo caso il
pseudcodice diventa commento (salvo commentare eventuali "language
tricks" che sarebbero comunque da evitare).
Riferimenti: "Code Complete" non l'ho sotto mano e non ricordo
l'autore.


 quello al good enough SW.
Good enough software: filosofia commerciale che afferma: 
"il programma funziona nel 90% dei casi? allora e' vendibile"
ora afferri il riferimento?
Non pensi che prima di rilasciare nuove tecnologie, (dcom, com+, 
etc...) andrebbero magari rafforzate le basi? tutto il complesso 
WinXXXX mi ricorda tanto una piramide di bicchieri capovolta...
Non sono un fanatico di Un*x, pero' ci sono molte cose che andrebbero 
migliorate, prima di rilasciare nuove versioni a rotta di colon, e non 
parlo solo del sistema operativo (SSL su Explorer, i vari bug di IIS, 
Exchange, Mail, le uova di pasqua nei programmi, etc... etc...)

l'autore.
Io non sono un sostenitore dello pseudo codice... dal codice
deve essere leggibile cosa si sta facendo; perche' lo sto facendo
lo scrivo nei commenti. Ho notato che ora pero' non commento piu'
cose che ritengo totalmente ovvie e metabolizzate... in pratica
ho la tendenza a pensare solamente a me stesso quando scrivo un
commento... una cosa forse un po' troppo egoistica.


 Exchange, Mail, le uova di pasqua nei programmi, etc... etc...)
Questa e' una opinione comune. Ed e' anche la mia, per quanto riguarda
i prodotti svluppati da me. Ma non e' l'opinione di MS.
MS applica il GESW. Ovvero rilascia il SW molto prima che sia
perfetto. Anzi: molto prima che sia anche solo accettabile. Lo
rilascia "non appena il livello di funzionalita' e' tale da generare
una risposta commerciale consistente da parte degli utenti". La scelta
non e' dovuta a mancanza di tempo. E una considerazione commerciale
pura. MS non rilascia SW con i bachi perche' non e' capace di fare SW
senza bachi. E neppure perche' non ha avuto il tempo di risolvere i
bachi prima della data prevista per il rilascio.
Ecco come funziona:
Quando parte un nuovo progetto MS non ne parla. Il progetto continua
per alcuni anni sotto completo non disclosure. Ad un certo punto la
tecnologia e' abbastanza matura per cominciare ad essere
"interessante" in termini tecnologici. Viene considerata
l'opportunita' di parlarne. La logica e':
1) prima di rilasciare la nuova tecnologia MS deve creare "attesa
commerciale". Ovvero il desiderio da parte degli utenti di possederla.
Questo significa parlare agli utenti della nuova "futura" tecnologia e
spiegare loro come funziona, quali vantaggi porta e come prepararsi ad
adottarla. Questa e' una forza "pro" il parlare della nuova tecnologia
al piu' presto.
2) la concorrenza e' sempre all'erta. Chi arriva prima commercialmente
ha un grosso vantaggio. Militarmente si parlerebbe del vantaggio
tattico dell'attacco a sorpresa. Parlare della nuova tecnologia mette
all'erta la concorrenza. I problemi che la nuova tecnologia vuole
risolvere possono essere ovviamente risolti in molti modi.
Commercialmente e' necessario evitare che i concorrenti possano
affrontare gli stessi problemi con soluzioni alternative prima che la
soluzione proposta da MS sia adottata. Questa e' una forza "contro".
Spinge in direzione del parlare della nuova tecnologia il piu' tardi
possibile.
Le due forze vengono continuamente valutate. Nel momento in cui la
prima viene considerata preponderante sulla seconda MS "parla". E
comincia un processo di "missonariato" volto a: illustrare i problemi
che la tecnologia risolve, creare coscienza degli stessi, proporre la
nuova tecnologia come soluzione, creare "attesa commerciale".
Piu' o meno nello stesso tempo MS e' obbligata a fare due cose: dare
una previsione di quando la nuova tecnologia sara' disponibile, e dare
al piu' presto un "preview" di cosa sta facendo. La previsione NON SI
BASA sul momento atteso perche' la tecnologia sia completa. Fin da
subito si basa su una "previsione" di quando sara' "abbastanza
completa". Se tecnicamente MS pensa che la tecnologia sara' completa
dopo 4 anni ma che sara' "abbastanza completa" dopo 2 anni. MS dice
pubblicamente che sara' disponibile dopo "un anno e mezzo o due".
Qusto aumenta il livello di "attesa commerciale" (primo scopo in
questa fase) e scoraggia eventuali concorrenti dal tentare soluzioni
alternative (secondo scopo). Inoltre nel giro di un mese o due,
qualunque sia il livello esistente, la build viene rinominata
"technology preview" (un eufemismo per dire che e' una beta uno con
qualita' alfa).
Da quel punto in poi inizia la vera corsa. Non in senso tecnico, in
senso commerciale. Le versioni rilasciae saranno (in genere): "beta
1", "beta 2", "beta 3", "release candidate", "version 1". A cui
seguiranno i service pack etc.
La questione e': pensi che questi numeri e nomi siano legati ad un
dato parametro tecnico? Per esempio una data %le di funzionalita'
completata o di bachi risolti? Ti sbagli. Il livello di beta e' una
scelta commerciale, non tecnica. Il salto al gradino successivo
dipende solo ed esclusivamente dalla risposta degli utenti. Se
rispetto al prodotto pianificato la funzionalita' e' solo implementata
al 50% e quel 50% ha un livello di bachi che possiamo definire
"funzionante al 20%", difficilmente gli utenti useranno il prodotto
per nulla piu' di una "technology preview". Ma puo' anche succedere
che, per assurdo, MS scopra che anche con quella funzionalita' quasi
tutti gli utenti che hanno messo mano sulla "technology preview" hanno
finito per usarla nel loro "production environment". Se questo dovesse
succedere, MS se ne frega delle previsioni e della qualita': gli
utenti sono gia' contenti cosi'. Quindi inutile "regalare" loro il
prodotto. I tempi di rilascio previsti di 2 anni scendono. Nel giro di
8/10 mesi il prodotto "scala" tutta la gerarchia dei nomi ed esce. Gli
utenti si sono dichiarati disponibili a sposare il prodotto "nello
stato in cui si trova" e MS risponde "Very Well" (la MS inglese,
quella americana magari dice "Ok" e il centro di localizzazione in
Irlanda dira' probabilmente "All Right").
Semplice. Commerciale. Redditizio.
E sai perche' lo fa? Perche conviene a tutti. Si, per assurdo conviene
anche agli utenti.
Ricorda i vari casi di MS vs IBM a livello tecnologico. Tutte e due
lavoravano su tecnologie diverse ma simili (nel sesno che affrontavano
gli stessi problemi). GLi utenti scalpitavano e dicevano: mi serve una
soluzione a questo e questo problema. IBM rispondeva "ci sto lavorando
ma non e' ancora maturo". MS rispondeva "ci sto lavorando ma non e'
ancora maturo". E gli utenti chiesero: quando cavolo pensate che sara'
maturo. IBM ha risposto "penso fra circa un anno o due". MS ha detto
"penso fra un annetto al massimo". IBM ha commentato "sappiamo bene
cosa sta facendo MS, fra un anno non avranno un prodotto
funzionante.". Dopo sei mesi MS ha detto "non e' ancora pronto ma se
vuoi te lo do lo stesso". Gli utenti lo hanno preso. IBM ha detto
"visto che non funziona? E dato QUANTO non funzione mi sa che noi ve
lo daremo funzionante fra un altro anno e mezzo mentre il loro non
funzionera' per almeno altri due".
Chi aveva ragione? Entrambe! Il prodotto di MS non ha mai funzionato
del tutto (prima che funzionasse gli utenti volevano di piu' e usci'
una versione ancora piu' complessa). IBM usci come previsto con un
prodotto funzionante al termine dei due anni previsti. I clienti
dissero bello. E funziona. Ma oramai da un anno e mezzo tutto il mondo
usa il prodotto di MS. Che non funziona del tutto, ma migliora piano
piano. E soprattutto lo usano oramai tutti e io devo adeguarmi al
resto del mondo.
MicroSoft e' diventata Micro$oft. E International Business Machines e'
diventata International Businessless Machines.
Se non ti piace il SW MS non comperarlo. Se DEVI comperarlo perche' lo
usano tutti non dare la colpa a MS: dai la colpa a tutti. Se non
funziona come vorresti lamentati pure. Ma contuera' cosi' fino a che
non smetteranno tutti di comperarlo.
Chi nella prima meta' degli anni 80 voleva un sistema all'avanguardia,
avanti technologicamente di 15 anni poteva averlo. Ai tempi in cui i
PC non avevano ancora la EGA e dicevano "beep" con l'altoparlante. Ai
tempi in cui Apple vendeva ancora gli Apple II. Esisteva gia' un
sistema con schermo grafico, finestre, mouse, lettore CD, capacita' di
acquisizione e playback Audio stereofonico, networking, e prototipo di
playback audio-video su schermo! Un sistema nativamente multimediale!
Supportava nativamente un sistema di sviluppo con IDE grafica
integrata (piu' completa ancora dell'attuale VC) e API di sistema
Object Based! E non lo faceva ne Apple ne MS ne IBM. Derivava dalle
idee di Mr. Jobs (allora ex fondatore di Apple, successivamente
sbattuto fuori a calci perche' le sue idee non piacevano. Anni dopo fu
richiamato con tante scuse). Si chiamava Next Step. E aveva pochissimi
bachi.
Pero' non lo compero' nessuno!


 commento... una cosa forse un po' troppo egoistica.
Se il target dei tuoi commenti e' quello classico della OO allora
certamente non sei tu! Idealmente devi immaginare che chi legge il
commento sia qualcuno che non conosce bene ne il problema ne la
soluzione, e poco il linguaggio. Tipico esempio: un neoassunto con
poco C++ che "dovra' entrare" nel team di sviluppo che sta per
cominciare a lavorare alla 3a versione del prodotto. Tu naturalmente
stai ora scrivendo la prima versione. Pochi aziende ragionano in
questo modo. Io stesso mica lo faccio (tranne rarissimi casi). E
tutti, io, tu, e le varie aziende, ce ne pentiamo. E sai quando?
Guarda caso quando dobbiamo "formare" assumere i nuovi assunti del
team che lavorera' alla terza versione!
Com'e' quella citazione? Fra la teoria e la pratica, in teoria ...


 Pero' non lo compero' nessuno!
 
Eggia'... che vuoi farci, cosi' va il mondo, speriamo meglio nel 
prossimo
(PS: sono agnostico :)

con un singleton. Inoltre una cosa e' l'OO e un'altra sono i pattern.
Insomma, quello che intendevo mi sembra chiaro. Sia OO che i pattern
sono argomenti molto "cool" di questi tempi. La OO da un bel pezzo in
verita'. Ora sulla OO molti faticano a vedere che certe soluzioni
procedurali sono in realta' soluzioni molto ad oggetti (anche se
allora non era di moda chiamarli cosi'). Sui pattern invece sembra che
altri non capiscano che si ragionava a pattern da molto prima che
simili nomi venissero "inventati".
In sintesi io mi trovo a lavorare anche con persone pronte riempirsi
la bocca con belle parole e teorie. A parte il codice che non
funziona, la cosa triste e' che poi nella pratico mi trovo cagate
come:
1) mancanza di commenti
2) codice morto che non viene eliminato ("puo' sempre servire")
3) 
void Funct(const string ciccio);
invece di:
void Funct(const std::string& ciccio);
che tra l'altro non mi obbliga ad aprire il namespace std se non
voglio.
4) 
try
{
  funct1_conthrow();
}catch(...)
{
  //gestione dell'errore
}
try
{
  funct2_conthrow();
}catch(...)
{
  //gestione dell'errore
}
try
{
  funct3_conthrow();
}catch(...)
{
  //gestione dell'errore
}
invece di un piu' compatto, ma poco cool:
if( NESSUN_ERRORE <>  funct1() )
  //gestione errore
if( NESSUN_ERRORE <>  funct2() )
  //gestione errore
if( NESSUN_ERRORE <>  funct3() )
  //gestione errore
Istintivamente sono portato a diffidare da chi usa parole come OO e
Pattern, e in altri ambiti come Java, XML e altre cose molto cool.
Per esempio un esempio che odio e' il classico:
"Dalla classe motore non si puo' derivare la classe aereoplano,
perche' un aereoplano "non e'" un motore".
Orbene, io penso che sia una fesseria come affermazione presa "cosi'
come e'". E penso che sia una fesseria perche' in questo esempio
classico si da per scontato che degli oggetti reali debbano avere dei
corrispondenti nel software. Questo (per me) e' una pericolosissima
"anticipazione" della soluzione. In un programma reale un "aereoplano"
puo' benissimo essere un "motore" speciale, e il tutto avere una sua
pulizia formale notevole. Dipende dal caso, e il caso potebbe volere
che in quel specifico contesto, anche avendo a che fare con motori e
aereoplani reali, dividere i moduli software su tali oggetti potrebbe
essere una scelta pessima.
Purtroppo quando parlo del dogmatismo non evidente che ci potrebbe
essere in certe soluzioni ad oggetti prefritte, di solito, vengo
accusato di essere troppo astratto. Come se fosse un'accusa per un
progettista software.
Per inciso non ho mai trovato nessuna scuola filosofica che non
ritenesse piu' che corretto "modulare" il codice reale su casi
concreti, ritenendo di fatto la realta' un ottimo "generatore" di
soluzione software.


 soluzione software.
Mi sa che non ho capito cosa intendi. Le scuole filosofiche intese,
come dice giustamente Griffini, come paradigmi si applicano
all'analisi e al design. Poco hanno a che fare con il codice reale
(salvo tenere conto in fase di design delle eventuali limitazioni
dovuto al linguaggio/compiler che verra' usato). Se invece parli di
"filosofia" come tecnica di coding ... quasi tutte ti danno delle
regole, ti spiegano a cosa servono le regole e perche' esistono, e
finiscono col dirti che tutto poi dipende dal caso concreto (salvo
documentare sempre quello che fai e perche').
Quindi non capisco.
E non ho capito cosa intendi dicendo che "la realta' un ottimo
"generatore" di soluzione software".
Andrea Ferro



Appunto. La MS (o meglio i suoi tecnici) non applica(no) il "lo
sistemo meglio dopo" , applica (o meglio i suoi commerciali applicano)
il "te lo vendo anche se non e' ancora finito" (ovvero "anche se i
tecnici non lo hanno ancora finito").


  //gestione errore
In realta' nel software di grandi dimensioni il metodo di gestione del C++ e'
piu' conveniente, in quanto permette di gestire l'errore (o piu' in generale,
l'eccezione) a piu' livelli, cosa questa piu' difficile da realizzare nel
metodo tradizionale. Certo il secondo e' piu' compatto, ma il primo e' spesso
piu' sicuro: val bene la pena scrivere 10 righe in piu', ma essere sicuri che
un'operazione andra' a buon fine o, in caso contrario, l'errore sara' ben
gestito. Questo sempre in linea di massima. Inoltre ricorda che il C ricorre
spesso a errno e simili, per non occupare lo spazio destinato all'eventuale
restituzione di un valore, e questo metodo e'  spesso meno efficiente della
gestione delle eccezioni del C++
Ciao
Domenico Barra

a distruggere le statue di Frosini che tieni in cortile
Quelli con i Nani di Gesso me le rubano tutte il "movimento del fronte
di liberazione dei nanetti di gesso". Quelle di Frosini non me le ruba
proprio nessuno.


persino criticabile l'OO stessa. 
Tecnicamente la OO la critico da prima, da molto prima. Essenzialmente
per la questione su come si dovrebbe sviluppare un progetto in un
ottica OO (oppure che io credo che la OO in genere dica su come si
dovrebbe sviluppare). Cose che ho sempre trovato praticabili solo sui
libri, ma controproducenti nella realta'.
Pero' recentemente alcune critiche della XP alla OO mi hanno assai.
Ci sono modalita' di sviluppo della XP che non adottero' mai, neanche
sotto tortura, pero' ho trovato fruttuoso alcune cose che ho letto su
di esso.


Fra le parole magiche non hai citato "XP" ... e' una dimenticanza ?
No, non e' una dimenticanza. Per fortuna la XP non e' ancora diventata
di moda. Ma non ho dubbi che se anche la XP entrera' tra le cose
"cool" e anche lei sara' citata a vanvera.
In fondo se sento di siti web progettati a oggetti (siti di una pagina
con una foto), perche' non dovrei sentire di Paperi disegnati secondo
metodologie XP. Incomincio a vedere i primi libri di XP tradotti in
italiano, forse ci avviamo ad una nuova "rivelazione"?
Succedera' anche questo. Per ora pero' sento parlare di piu' di Paperi
XML. Questione di "momenti storici". Arriveranno anche i Paperi XP. 
<spoiler>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Credo anzi che la Disney stia lavorando ad una versione di Paperino
XP, ma per ora sono solo voci.
</spoiler>


 </esempio>
Certo. Infatti "Algoritmi" non ha senso come titolo di un articolo di
rivista. Magari "Introduzione al QuickSort" avrebbe piu' senso. Un
articolo da rivista, per definizione, e' focalizzato. Puo' dare alcune
premesse e trarre alcune conclusioni, ma non deve (ne puo') essere
esaustivo. L'articolo sul quicksort non deve certo spiegare cosa e' un
algoritmo o cosa e' una struttura dati. Ne le relative teorie. E
neppure deve dire molto sul sorting in se. Puo' certamente
"premettere" che il QS e' un algoritmo e che funziona bene se la
struttura dati sottostante permette un accesso casuale. Puo' anche
accennare a cosa significa "accesso casuale". Ma non deve andare
oltre. Deve spiegare il quicksort punto e basta. Puo' terminare
facendo una brevissima panoramica degli algoritmi di sort (e della
"storia" del sorting) e notare che il QS non e' il piu' efficiente in
alcuni casi specifici. Puo' anche accennare all'enhanced quicksort. Ma
non andare oltre.
Se invece il tuo argomento e' "sorting", allora non stai parlando di
un articolo ma di una serie. In questa serie parlerai del sorting e
dei vari algoritmi in maniera estensiva. Ma non parlerai piu' di tanto
ne delle strutture dati ne degli algoritmi in generale. E' una
questione di "OT" se vuoi.
Se il tuo scopo e' essere esaustivo su un argomento vasto, non vai su
una rivista. Va su un libro. O su una serie di libri! Come la
pentalogia (non completata e rimasta trilogia) di Knuth.


 Pero' recentemente alcune critiche della XP alla OO mi hanno assai.
E1324 Syntax Error. Complement expected before '.'


 del programmatore" per far di meglio.
La prima e' accettabile, la seconda molto meno. Soprattutto vista la
potenzialita' di Infomedia. Infomedia sa fare molto meglio, se vuole.


Quelle di Frosini non me le ruba proprio nessuno.
Ne sono assolutamente convinto. Puoi dormire tranquillo.


di queste si chiama Doctor Dobbs Journal (versione USA).
Io DDJ lo compravo molti anni fa... e non mi dispiaceva affatto.
Ho quindi commesso l'errore di comprare la versione italiana ...
una storia triste.


 una storia triste.
Secondo te perche' ho messo fra parentesi che mi riferivo alla versine
USA :-(


 E1324 Syntax Error. Complement expected before '.'
Questa invece è semplicemente mitica ;-)
Massimo

piu' conveniente,
Non ne sono tanto convinto. Quello che vedo al lavoro e' una
proliferazione delle classi utilizzate per il throw. Questo e' un
fenomeno che mi preoccupa assai. Altra cosa che ho notato e' il falso
senso di sicurezza che puo' derivare da una buona gestione degli
errori.
<caso reale>
Contento della stabilita' di un mio certo programma ho guardato per
puro scupolo i file di log molti mesi dopo il rilascio dell'ultima
versione. Mi sono accorto che sbagliavo un certa query sul DB, questo
causava una eccezione, che veniva intercettata, ma il programma
riusciva a ritornare in una situazione stabile e ripartire.
Mi sono solo accorto solo io dell'errore, ma e' stato solo per caso.
Questo e' un fenomeno che preferirei non si ripetesse piu'. Non che
centrino piu' di tanto la gestione degli errori del C++, ma in codice
stile C ero piu' abituato stare sul "chi va la'". Il C++ se ti
rilassi, ti ricorda i tuoi limiti.
</caso reale>


"generatore" di soluzione software".
Modellare il codice su esempi concreti di come la gente lavora e' un
ottimo modo per generare software sballato. 
Almeno nel famigerato mondo dell'automazione industriale.
Almeno per me.


 Almeno per me.
Penso si debba modellare solo l'interfaccia utente in modo che
rifletta il modo in cui la gente pensa di lavorare. E le interazioni
fra i componenti in modo che riflettano la realta' oggettiva o
astratta (secondo cosa modelli). Ma soprattuto si dovrebbe cercare di
analizzare in che modo la gente lavora, non in che modo crede di
lavorare. E poi anche il perche' lo fa. E in che modo la cosa puo'
cambiare.


 esperienza).
Considerando che alla Disney ha lavorato per qualche anno Stan Lippmann,
autore di C++ Primer, sarebbero stati in condizione di far molto meglio
di DEV :-)
Ciao,
Nicola

Ne sono assolutamente convinto. Puoi dormire tranquillo.
Temevo di vederti nel mio giardino, non sono esattamente sicuro che tu
non faccia parte del "fronte di liberazione dei nanetti di gesso". Il
tuo sito mi sembra sospetto, credo che ci siano link nascosti al
movimento.


Considerando che alla Disney ha lavorato per qualche anno Stan Lippmann,
Pero' Paperino non e' andato da DEV. Probabilmente non e' un caso!


rifletta il modo in cui la gente pensa di lavorare. 
Il fatto che certi programmi sono rivoluzionari. Se non hai mai visto
un programma di grafica, fare tante analisi su come sarebbe giusto
lavorare non serve a mitigare l'impatto.
Di piu', spesso e' difficile dire in anticipo cosa cambiera'
modificando certe modi di lavorare aziendali. 
Di piu', spesso si fanno errori a cui e' difficile rimediare.


 Di piu', spesso si fanno errori a cui e' difficile rimediare.
Salvo uno degli apparenti assurdi del SW design moderno: da un lato "design for
reuse" dall'altro "if it does not work, do not fix it: redo it".


 molto OO.
...scusa, non dovrebbe essere esattamente il contrario ?!?
Massimo

...scusa, non dovrebbe essere esattamente il contrario ?!?
Si, e' cosi'. Mi sono dimenticato un "NON" nel posto originale.


cambiamento.
Perle di saggezza.
Perle che personalmente mi sono costate anni di lacrime e sangue. Oggi
do per scontato che possa non esistere la soluzione ottimale ad un
problema, e che il "divenire" perenne e' l'unica soluzione che abbiamo
"oggi" per saltarci fuori.
Poi domani, con il "senno del poi", potremo anche pensare a soluzioni
ottimali a "quel" problema. Se ce ne sara' il tempo :-)
oltre che di sogni infranti. Ma presumo che maturare sia anche il
volere accettare il "non essere guru", 


 ottimali a "quel" problema. Se ce ne sara' il tempo :-)
E soprattutto se sara' necessario. Nel 90% dei casi non lo e'.


Yep. Ma hai idea di quanti di questi siano per buona parte "frutto" di MS?
Non importa chi definisce lo standard, ma se quel standard e' seguito.
SQL e' uno standard nato in IBM, ma che nessuno sente IBM. E' di
tutti. Kerberos e' uno standard di tutti, e allora perche' la
Microsoft deve taroccare il suo Kerberos per renderlo non standard?
La Microsoft, storicamente, si e' fatta sempre i suoi standard, e non
li coindivide. 
Vedi per esempio il supporto della Standard Template Library. Se c'e'
un baco nella loro libreria (e ce ne sono piu' di uno) non te la
mettono a posto con il service pack, ti devi scaricare dal sito
vattelapesca (a tuoi rischio e pericolo) la versione aggiornata.
In compilatore C++ invece di supportare gli standard li "sopportano".


 vattelapesca (a tuoi rischio e pericolo) la versione aggiornata.
Guarda che MS non ha proprio nessun supporto per la STL. La STL e' sviluppata da
terze parti. La versione rilasciata con il compilatore non era (e non e')
conforme cosi' come non lo e' il compilatore. Nel frattempo la STL in questione
si e' evoluta e ha risolto alcuni bachi e si e' resa piu' conforme. La
risoluzione dei bachi (sia del compilatore che della libreria) viene distribuita
con i service pack "purche' non renda incompilabile codice che prima colo era o
non cambi il funzionamento run-time di codice preesistente". Il fatto e' che
molte delle "correzioni" apportate nel frattempo hanno profonde influenze sul
funzionamento del codice esistente. Per questo non vengono inserite nel SP.
La versione 7 del compilatore e' MOLTO piu' conforme e meno bacata della
versione 6 (anche se non ancora 100% conforme) e lo stesso dicasi della sua STL.
La politica di MS e' pertanto: i SP risolvono bachi ma lasciano che continui a
funzionare anche codice che non dovrebbe. Puoi aggiornare il tuo VC6 con i SP
senza grosso impatto sul tuo codice. La nuova dot-release e' piu' conforme, e
non accetta o esegue diversamente codice preesistente che non e' completamente
comliant.


 funzionamento del codice esistente. Per questo non vengono inserite nel SP.
Il problema e' che l'SCL implementata da Dinkumware e' poco conforme
perche' ha dovuto adeguarsi ai limiti di VC++. Non era possibile
renderla piu' standard.
 
Ciao,
Nicola

 renderla piu' standard.
Infatti i principali passi avanti sono basati sul VC7
P.S.:
SOAP (Simple Object Access Protocol), specifica un protocollo per l'esecuzione
di chiamate alle funzionalita' dei web services, e' in fase di standardizzazione
W3G e ha gia' subito un cambio di nome dato che di fatto e' divenuto
responsabilita' del working group che si occupa di XML.
WSDL (Web Services Description Language), e' uno schema XML che descrive le
funzionalita' esposte da un Web Service tramite SOAP.
SDL (Service Description Language), proposto da MS e successivamente soppiantato
da WSDL.
NASSL (Network Accessible Service Specification Language), proposto da IBM e
successivamente soppiantato da WSDL.
UDDI (Universal Description, Discovery, Integration), progetto in corso, basato
su WSDL, con lo scopo di creare un network registry universale per i servizi
(una specie di DNS che risolve le interfacce invece che i nomi).
Links: 
www.uddi.org
, 
http://msdn.microsoft.com/xml/general/wsdl.asp
Anche XSL sta per essere standard: 
www.w3.org/TR/2000/CR-xsl-20001121/



Ci faro' un salto sicuramente.
Sembrano molto interessanti.


 metodi "quasi standard" di prima.
E questo che centra? Nessuno e' obbligato a usare una data tecnologia, anche se
standard. Ma se e' standard chiunque la vuole usare lo puo' fare. Senza
(teoricamente) problemi di compatibilita'.
Nota: non sto difendendo MS. Sto dicendo che, per quello che vedo, le idee che
MS sta portando avanti sono per buona parte ottime e abbondanti e che sta avendo
un grosso riconoscimento da parte persino di suoi concorrenti storici. Questo
non garantisce nulla. Ma credo che sia un segnale da non trascurare.


 distribuirli se proprio non vogliono....
Il problema e' che la M$ ha il monopolio ( o quasi ) dei sistemi 
operativi... Questa e' una situazione di fatto ( molto anomala ) che 
svantaggia tutti tranne Guglielmo Cancelli...
Non e' una soluzione _giusta_, ma la vedo come la soluzione _meno 
sbagliata_ ad una situazione _ingiusta_

 svantaggia tutti tranne Guglielmo Cancelli...
Questo diventa un discorso politico (e mi sa che siamo OT).
Il monopolio non e' un male in se. Lo e' se:
1) riduce le possibilita' di migliorare i prodotti rendendo stagnante il livello
tecnologico
2) permette al monopolista di aumentare i prezzi a piacere e nel contempo
impedire l'ingresso sul mercato di un concorrente con prodotto equivalente ma
meno costoso
Nel caso di MS e' difficile accusarla contemporaneamente di proporre nuove
soluzioni con troppa rapidita' e contemporaneamente di rendere il livello
tecnologico stagnante.
Ed e' difficile accusarla di aumentare i prezzi grazie al monopolio e nello
stesso tempo di impedire la vendita di prodotti concorrenti a prezzo inferiore.
Nota: le due affermazioni vanno prese come "principio". Perche' esistono
documentati episodi singoli in cui MS si e' comportata in maniera "ingiusta"
(anzi: illegale, ed e' stata condannata). Ma si tratta di episodi che non
influiscono sul "big market".


MS sta portando avanti sono per buona parte ottime e abbondanti
Bisogna vedere l'implementazione.
Io mi limito a dire: le idee alla base sono buone, anzi ottime, ma
aspettiamo a vedere l'implementazione. Un ottimo teorico, senza un
ottimo programmatore che genera codice, non produce un buon programma.
I Paperi non mangiano pane platonico infondo.


 scelta di nome n.d.p.), o WSH. Di vere innovazioni non ne ricordo una.
Cosa intendi esattamente per agenti? Perche' io ne sento parlare almeno
dall' '87, ma forse in contesti diversi (certamente non in relazione a
Microsoft).
 
Ciao,
Nicola

 I Paperi non mangiano pane platonico infondo.
E neanche incima :-)


 Non so da dove Andrea derivi questo punto di vista.
Non farmi andare a cercare i vari riferimenti. L'ultima volta l'ho letto meno di
un mese fa su un NG legato a smalltalk (advocacy??).


 mouse via internet ....
Dipende da cosa intendi per universale: la JVM gia' risponde bene a
queste caratteristiche, visto che e' disponibile dal forno microonde
all'IBM 3090 passando per tutte le piattaforme intermedie.
Ciao,
Nicola

 all'IBM 3090 passando per tutte le piattaforme intermedie.
No. La JVM supporta un solo linguaggio e non e' estendibile. L'idea (almeno in
teoria) di .NET e' di essere il piu' possibile indipendente dal linguaggio e di
essere estendibile.
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 essere estendibile.
Cosa intendi per: non e' estendibile? E JNI? Per contro la JVM e'
ottimizzabile per Java, mentre .NET potra solo essere il massimo comun
denominatore tra i linguaggi piu' disparati.
Ciao,
Nicola

 anche per .NET...
In teoria no. Almeno non su Windows. .NET diventera' parte del sistema
operativo. Tieni conto che "sospetto" la .NET redyness di moltissimi prodotti
MS. Incluso, tanto per cambiare, office.


 MS. Incluso, tanto per cambiare, office.
Dipende molto cosa vuol dire diventare parte del sistema operativo. Il
PC IBM aveva il basic in ROM, ma era una ciofeca lo stesso :-)
 
Ciao,
Nicola

 PC IBM aveva il basic in ROM, ma era una ciofeca lo stesso :-)
Vule dire che nelle future versioni di Windows, .NET e Windows saranno
praticamente la stessa cosa. Ovvero quello che ora e' un "runtime" .NET che gira
su piattaforma NT diventera' parte stessa di NT e/o viceversa. Win98 e' Win386
diventato parte di dos o dos diventato parte di Win? Secondo me non e' piu' ne
dos ne win386 ma un nuovo OS in cui sono preponderanti le caratteristiche di
win386 rispetto a quelle di dos. Mi aspetto che nel giro di un lustro avremo una
piattaforma che non e' piu' ne NT ne .NET, ma una cosa nuova le cui
caratteristiche preponderanti saranno quelle di .NET


 caratteristiche preponderanti saranno quelle di .NET
Questa da sola pero' non e' una garanzia di efficienza. Ricordo che anni
fa, discutendo pregi e difetti dell'uso di linguaggi 4GL rispetto a
programmi in Embedded SQL, il mio interlocutore, che aveva esperienza di
grosse applicazioni basate su DB, mi aveva segnalato che le prime
degradavano decisamente peggio alla crescita del numero di utenti a
causa dell'alto numero di system call che effettuavano. E' un tipo di
problema che a mio avviso si presenta anche con linguaggi a byte code
interpretati, o che comunque richiedono un supporto runtime elevato.
Questo lo considero un campanello d'allarme ad esempio rispetto all'uso
di Java (ma in prospettiva probabilmente anche di C#) dal lato server di
applicazioni Web.
Ciao,
Nicola

 applicazioni Web.
Certamente un interpretato puro paragonato ad un compilato nativo e' poco
prestante. Già un p-code interpretato e' meglio, ma un p-code, per definizione,
e' una specie di "macro assembler". E il suo interprete e' quasi certamente
fatto in maniera da chiamare una o più funzioni per eseguere una data
p-istruzione. Pero' esiste un ulteriore passaggio: il JIT compiler. Ora nota
che, in generale, un JIT compiler, non solo riporta il "livello" di esecuzione
al codice nativo ma può anche eseguire delle ottimizzazioni ulteriori rispetto
al compilatore. E questo semplicemente perche', per definizione, puo' (nota che
uso sempre il condizionale) in generale avere una visione più ampia del
programma nel suo insieme (per esempio vede il p-codice delle funzioni chiamate
anche se queste, a livello sorgente, stavano in una differente translation
unit). Quindi, teoricamente, il passaggio tramite p-code può portare ad un
aumento di prestazioni rispetto al compilatore normale. Questa e' per ora solo
ed esclusivamente teoria. Comunque nota che .NET prevede la possibilità di
eseguire il JIT "a priori". Ovvero, pur restando l'obbligo del passaggio tramite
p-code, questo non viene obbligatoriamente interpretato e la compilazione in
codice nativo non avviene obbligatoriamente in run-time.
Mi aspetto che avvenga:
-) per i programmi "under development" che girano sotto debugger, non avviene:
il p-code e' interpretato.
-) per i programmi finiti distribuiti via internet on demand (ovvero le applet),
a runtime con un JIT compiler che compila all'atto della prima esecuzione (e poi
tiene il compilato in cache come minimo fino allo spegnimento della macchina,
salvo carenza di risorse).
-) per i programmi finiti che vengono installati: all'atto dell'installazione


 salvo carenza di risorse).
Costa troppo! Hai mai aspettato che partisse un CGI? Una palla...
Ciao,
Nicola

 Costa troppo! Hai mai aspettato che partisse un CGI? Una palla...
I CGI sono compilati. Impiegano tempo a partire a causa del modo in cui vengono
gestiti dai server HTTP. Già i ASP e i JSP sono meglio. Ma cosa succederà nel
momento in cui il server HTTP sarà esso stesso scritto in C# e funzionante
all'interno di un environment JIT e potrà pertanto chiamare direttamente le
classi da te sviluppate ?
Vedremo.


 direttamente le classi da te sviluppate ?
Che se crasha un cgi si porta appresso tutto il web server ?
Il modello dei processi con un proprio spazio di indirizzamente separato 
l'uno dall'altro ha un costo, ma ha anche uno scopo. Non si risolve il 
problema con una JIT,NET o chi che sia ...

"Goffredo Baroncelli" <gh...@therra.bhome> wrote in message
news:7gnj89...@127.0.0.1...

Il jit fornirà anche codice binario, ma la logica e' sempre quella di un
environment controllato come per un interprete. Non dovrebbe essere facile
crasharlo. E se crasha non crasha il tuo applicativo ma probabilmente tutto il
jit (e il baco non e' tuo ma di MS). A seconda del modo in cui e' fatto, facile
che vada giu' tutto quanto comunque (praticamente e' come avere un baco nel
kernel!). Prova a crashare un browser con uno script (senza activex o estensioni
varie) o a crashare IIS con ASP (senza usare COM, GCI o altri binari). Mica
tanto facile! Dovrebbe persino essere difficile crashare un ambiente Java, ma
non ci ho ancora provato!


 tabella HTML con i dati provenienti da DB (ovvero un loop
Tutto vero. Ma il punto che intendevo io e' quello di principio. Tutti i
problemi citati sono di fatto dovuti a problemi di implementazione non a
problemi di principio.
Mi spiego:
Se partiamo da uno script interpretato e diamo per assunto che l'interprete sia
esente da bachi (che poi questo sia difficile da fare e' un altro discorso)
allora e' possibile definire il linguaggio che viene interpretato in maniera
tale che non sia possibile scrivere, neppure intenzionalmente, uno scropt in
grado di fare danni.
Questa sicurezza si puo' ottenere anche senza bisogno di eseguire l'interprete
in uno spazio di indirizzamento diverso da quello dell'applicazione principale.
Per esempio un linguaggio macro di un SW di word processing puo' essere definito
in maniera tale da non uccidere il word processor (o il SO).
Se lo stesso linguaggio viene poi precompilato in p-code ed eseguito in una VM,
abbiamo un aumento di prestazioni dato che possiamo eseguire la trasformazione
in p-code "a priori", sia che questo significhi che la fa lo sviluppatore sia
che la fa l'installer dello script. Il passaggio a p-code non cambia il livello
di sicurezza. Semplicemente "anticipa" il lavoro di "parsing" del sorgente.
Se lo stesso p-code eseguito dalla VM viene compilato in binario della
piattaforma da un JIT compiler si ottiene un ulteriore aumento delle
prestazioni. Ancora una volta questo non va a scapito della sicurezza anche se
abbiamo, di fatto, del codice binario che viene eseguito all'interno dello
stesso processo principale.
Se esiste un modo, qualunque esso sia, per abbattere il sistema o l'applicativo
ospitante, da parte dello script, sia esso interpretato, p-code eseguito, o
binary eseguito, il problema sta nel design del linguaggio di scripting, nella
definizione dell'environment di esecuzione, o nell'implementazione
dell'interprete, del compilatore p-code, della VM o del JIT. Non nel principio
in se.


piuttosto che con un CGI .... Forse perche' sono abituato ad Apache ...
In "un sistema operativo" come NT anche un CGI e' pericoloso...
e' un problema di debolezza intrinseca della struttura.
Comunque ricordo server NT con IIS/ASP che venivano giu'
semplicemente perche' chi aveva fatto lo script si era
dimenticato di mettere "movenext" nel loop di generazione
tabella HTML con i dati provenienti da DB (ovvero un loop
infinito lato server).
Manco si riusciva piu' a fare lo shutdown del server NT
(NON sto scherzando, NON sto parlando del server WEB: intendo
proprio NT). Unica soluzione spegnere (!)
Chi ha lavorato davvero con IIS/ASP sa quanto e' meglio
se possibile poter avere un server *dedicato* quando si
sviluppa una applicazione.
La necessita' di ripartire da capo e' cosi' frequente che
se si lavora a diversi progetti con server condivisi ci
si pesta continuamente i piedi a vicenda.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 problemi di principio.
E' purtroppo con le implementazione abbiamo a che fare ....
comunque
[rapido riassunto]
sorgente
  |
  v
  compilatore
  |
  v
p-code
  |
  v
  JIT compiler
  |
  v
linguaggio nativo dell'host
Il punto critico secondo me' e' quello del JIT compiler.
se io riesco a generare codice p-code distruttivo ( es: while(1); ) creo un 
qualcosa in grado di buttare giu' il mio ambiente. ( non hai parlato di 
processi indipendenti )
E comunque se so che ho a che fare con p-code che viene trasfromato in 
linguaggio nativo, mi riesce difficile immaginare di non potermi riferire a 
qualche sys-call ( leggi qualche con tutte !! )...


 qualche sys-call ( leggi qualche con tutte !! )...
Se non puoi chiamarla dall'interprete allo stesso modo non puoi chiamarla dalla
VM e neppure dal compilato del JIT.


 dalla VM e neppure dal compilato del JIT.
Basta giocare un po' con gli stack e i buffer overflow ... Figurati lo 
fanno dall'esterno... ma dall'interno e' anche piu' semplice ....

JIT a nativo non aggiunge rischio. 
Il mio codice e' compilato per una VM e per un JIT
Sulla VM il codice e' SEMPRE interpretato. 
Se faccio cose scorrette la VM (teoricamente) se ne accorge.
Sul JIT il controllo (presumibilmente) ci sara' solo a (just) compiled
time.
A questo punto intervengo sul compilato inserendo il mio codice
malevolo. Se prendo possesso  della VM o la mando in crash, va giu'
tutta la macchina.
Su un S.O. classico serio (non MS cioe') questo non succede se un
programma senza diritti di superuser pretende di fare di testa sua.
++++
Il mio programma in "legacy" code lo compilo solo io. Con il JIT lo
compilano tutti (con perdita di tempo globale). Per un cazzabubbolo
internet, scaricato da un milione di persone, abbiamo un milione di
compilazioni.
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

 programma senza diritti di superuser pretende di fare di testa sua.
Non succede se la VM (o il JIT) sono scritti correttamente. Indipendentemente
dal sistema operativo. Posso persino pensare ad un JIT che te lo impedisce e che
e' scritto in DOS! Il sistema operativo (o meglio l'accesso al file system, che
avviene ovviamente tramite OS) entra in gioco solo se usi i file e il tuo
metalinguaggio (che interpreti o JIT copmpili) prevede l'accesso ai file.


file e' accedibile solo dal sistema. 
Presunzione molto forte. 
E poi dove starebbe? Su una partizione apposta?
Se uso troppo office mi si riempe il disco di compilati, e non ho
spazio per salvare il documento stesso?
E comunque il problema adesso e semplicemente una questione di accesso
in memoria.
Il JIT e' in user space o in kernel space? In user space e'
attaccabile, e se crolla il JIT crolla tutto. Non mi piace avere
sistemi critici in user space. Se e' in kernel space abbiamo che il
mio compilato/interpretato e' in una zona pericolosa.
Il JIT e' Cassandra di un sistema instabile per me.


 mio compilato/interpretato e' in una zona pericolosa.
E' esattamente dove sarebbe l'interpretato: in user space! Se cade il JIT
succede quello che succederebbe se cadesse l'interprete! Il JIT non e' altro che
un interprete arricchito con una cache!


succede quello che succederebbe se cadesse l'interprete!
Si, ma qui si parla di rendere il JIT il cuore del S.O.
Questo e' follia (per me).
Spero semplicemente che sia una sparata del Marketing MS, oppure che
come al solito non abbia capito niente.
