Newsgroup: it.comp.lang.c++
Titolo: Mi consigliate cosa continuare a studiare... please?!?

Ciao a tutti,
da agosto scorso ho iniziato a studiare la programmazione strutturata ed ho 
appena iniziato le classi.
I testi che ho letto sono:
Linguaggio C di A. Bellini e A Guidi
Introduzione alla prg. in C++ di C. Padovani
Fondamenti di C++ di H. Schildt (solo una parte)
C++ Fondamenti di prg. di Deitel (solo il prmio libro fino alle classi)
Il mio obbiettivo finale sarebbe quello di realizzare applicazioni 
gestionali, database via Web e/o altro.
La domanda che e vi pongo e'...
Mi conviene continuare lo studio delle classi (I libro Deitel) e poi le 
tecniche avanzate del C++ (II libro Deitel),
o mi conviene fermare e passare allo studio di un'altra lingiuaggio 
piattaforma tipo C# o simile?
Cosa mi consigliate? 

 piattaforma tipo C# o simile?
Io ti consiglio uno fra Python e Ruby, preferibilmente il primo.

 Io ti consiglio uno fra Python
Me l'avevano consigliato anche a me di passare a Python. Ho fatto alcune 
lezioni ma ho dovuto smettere, rischiavo di collassare dalle risate. 
Python è demenziale (((((((((-:

 Python è demenziale (((((((((-:
O stai trolleggiando oppure sei molto confuso. Secondo me entrambe
-- 
Marco KLN 

 O stai trolleggiando oppure sei molto confuso. Secondo me entrambe
Nessuna delle due.
1) sto lurkando da alcuni giorni
2) oramai ho le idee chiare: riprendere a studiare il C ed il C++ dopo 10 
anni
Ciao,


Io sono indeciso se proseguire con C# o Java e senza dimenticare SQL!

 Io sono indeciso se proseguire con C# o Java e senza dimenticare SQL!
SQL è una cosa completamente trasversale.
Io per parte mia posso dirti che sia MS che Sun stanno investendo in
modo massiccio su Ruby e su Python...
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 O stai trolleggiando oppure sei molto confuso. Secondo me entrambe
Era già stato sgamato come troll qualche tempo fa.
Allora se ne era uscito con alcune divertenti sparate su Ada, Andrea
l'aveva un po' inchiodato e allora era sparito.


 Era già stato sgamato come troll qualche tempo fa.
?????????????????????????????????????

 Capisco cosa intendi (...) si può fare tanto.
Quoto tutto al 1000%!

 l'ho usata mai. Stringi stringi, con poco si può fare tanto.
Se a questo aggiungi i template per quei casi dove l'ereditarieta' non
aiuta di strada ne puoi fare moltissima e hai una marcia in piu', a
livello di linguaggio puro, rispetto a Java e C#.
Ciao,
Nicola

gestionali, database via Web e/o altro.
Se vuoi scrivere applicazioni gestionali, faresti bene ad approfondire
altri argomenti, prima che la programmazione in s�. Certo, se sei a
digiuno di programmazione, ti conviene imparare un linguaggio, ma
programmare un'applicazione gestionale � fattibile agevolmente con
qualsiasi linguaggio di alto livello (non sto quindi considerando il
C) e ancor pi� agevolmente usando un linguaggio di altissimo livello
(come Python, per esempio). Bada che con "alto" e "altissimo" non
intendo implicare un bel nulla sulla qualit� del linguaggio in s�, ma
piuttosto mi riferisco alla "altezza" della macchina virtuale del
linguaggio, rispetto al cuore fisico del sistema. Un linguaggio come
Python astre maggiormente che C++, a sua volta pi� "alto" di C.
Per chi vuol scrivere un'applicazione gestionale � fondamentale
conoscere il modo in cui vanno strutturati i dati, le propriet� dei
motori transazionali, i linguaggi di interrogazione e molto altro, a
volte specifico del db che userai. C'� una marea di libri sulla
progettazione delle basi di dati. Ti consiglio di procurartene
qualcuno. Per quel che riguarda la programmazione Web, si tratta pi�
che altro di nozioni tecniche, che si acquisiscono una volta scelta la
tecnologia da usare. Nella maggiorparte dei casi, si tratta di
implementare una logica model-view-controller, quindi avrai sempre il
model, che astrae gli attori del tuo problema, la view, un template di
presentazione e il controller, la parte pi� succosa che amalgama il
tutto con la logica applicativa. Se sei a digiuno, ti servir� studiare
molti argomenti, prima di diventare produttivo. In linea di massima,
il C++ non � il linguaggio usato per applicazioni gestionali e
tantomeno per applicazioni Web. Normalmente l'ho visto usare per
processi server macina-dati, obbligati ad avere performance ottimali.
Il linguaggio di gran lunga usato, oggigiorno, per le applicazioni Web
(specie in campo "enterprise", parola che piace usare ai manager) �
Java. La piattaforma � J2EE o meglio JEE. Non � il linguaggio migliore
del mondo, ma esiste una cosa chiamata "mercato", con la quale, ahim�,
bisogna spesso fare i conti. Per le applicazioni gestionali, il campo
� un po' pi� aperto e, laddove non si punti ad avere un'interfaccia
web (moda abbastanza comune da molti anni a questa parte e nel qual
caso si torna a Java), posso consigliarti, su piattaforma Win32,
Delphi.

 Se vuoi scrivere applicazioni gestionali (cut)
Complimenti per il post, molto sintetico ma chiarissimo. Mi intrometto 
nel discorso per alcune considerazioni, frutto di dialogo tra colleghi. 
Motivo del contendere potremmo chiamarlo: <<SQL vs. C++>>.
Un mio collega sostiene <<a spada tratta>> la "bellezza" dell'SQL per la 
gestione di DBase, in quanto:
- è IL più efficiente
- è semplice
- è insostituibile nelle grosse banche dati
Io controbatto questo:
- C++ teoricamente DEVE essere più efficiente, perché gli SQL sono 
scritti in C++
- alla fine C++ è anche più semplice... perché SQL fila liscio se non ci 
sono problemi, ma se un applicativo segna qualche problema il codice SQL 
è assolutamente criptico, incomprensibile, ostico
- è vero che SQL potrebbe essere insostituibile nelle grosse banche dati, 
ma dal punto di vista del mercato (che come giustamente dici tu è il 
nostro "padrone") quanti DBase sono poi così giganteschi da necessitare 
di un linguaggio a così alto livello?
Ho una sensazione... l'attuale vantaggio di SQL deriva dal fatto che i 
sui algoritmi (ad esempio un banale "sort") sono ottimizzati al massimo 
dal punto di vista teorico, laddove (ad esempio...) col C/C++ molti 
ancora si accontentano di un <<bubble sort>>, per non stare tanto a 
menare il can per l'aia, come si suol dire.
Mi farebbe MOLTO piacere sentire il tuo parere su questi ragionamenti. 
Ciao e buona giornata,

 Motivo del contendere potremmo chiamarlo: <<SQL vs. C++>>.
Non ha senso fare confronti tra SQL e C++. SQL è un linguaggio di 
interfaccia, non di programmazione.
E.

 interfaccia, non di programmazione.
Anche i suoi avi (DBase I, II, III...) lo erano, poi arrivò Clipper. 
Alcuni mesi fa ho provato VisualBasic 2005 (free nel sito Microsoft) ed 
avevo query SQL lunghe 3 righe. Forse è difficile capire dove finisce un 
linguaggio di interfaccia ed un linguaggio di programmazione ad altissimo 
livello.

 Motivo del contendere potremmo chiamarlo: <<SQL vs. C++>>.
Come ti è stato già detto, questo tipo di confronto non ha senso. Sono
due linguaggi distinti. Oltretutto, due paradigmi distinti (l'uno è
dichiarativo, l'altro imperativo). Evito di commentare il resto di ciò
che scrivi, perché non ho sinceramente capito qual è il punto della
questione tra te e i tuoi colleghi (né sono interessato a saperlo,
quindi non affrettarti a specificarlo). Voglio solo puntualizzare due
cose che, leggendo il tuo post, mi hanno fatto sorridere: 1) in ambito
professionale, avere a che fare con database "giganteschi" è
tutt'altro che raro - chiunque lavori in certi contesti, sa bene che
arrivare a diverse decine di milioni di record è possibile; 2) credo
che per qualsiasi uso serio delle strutture dati, non si possa
prescindere dagli algoritmi più performanti, quindi immagino che il
bubble sort sia da destinare agli esamucoli universitari da primo
anno. Gli stessi per i quali si richiede normalmente aiuto in un ng,
sperando nella pappa pronta. In ambito professionale, invece, a non
voler menare il can per l'aia, come tu dici, si resta approssimativi e
incompetenti.

 due linguaggi distinti.
Beh... visto che me l'avere detto in due, allora il problema è semplice: 
non l'ho capito e/o non riesco a capirlo. Io la vedevo così:
1) mi serve un DBase (esempio stupido... un'agenda telefonica)
2) che faccio? uso un Dbase SQL e poi <<programmo>> una maschera (ad 
esempio VisualC++) + libreria SQL?
3) mi studio campi e record e metto su due righe di C++
Poi... dall'esempio stupido il fattore di scala a questo punto è 
<<ininfluente>> (agenda telefonica... banca dati Telecom).
Naturalmente non ti chiedo di spiegarmelo! La mia testa, ahimè... è 
famosa per quanto è dura! (':
Ciao e grazie,

 Naturalmente non ti chiedo di spiegarmelo!
Anche perché non saprei sinceramente *che cosa* spiegarti.

 3) mi studio campi e record e metto su due righe di C++
Allora il tuo problema è: "usare un database esterno o gestire i dati 
direttamente da codice?"
L'alternativa non è SQL/C++, perchè il database può non essere SQL e il 
codice può non essere C++, la questione qui è a monte. Usare il database 
è vantaggioso se devi gestire molte informazioni (ad esempio più della 
RAM disponibile) oppure se pensi che il database sia destinato a 
rimanere in vita a lungo (è più facile aggiornare la tecnologia 
utilizzata se i dati sono ben separati dal codice).
Dopo che hai fatto questa scelta puoi decidere quale database utilizzare 
  e quale linguaggio di programmazione.
E.

   e quale linguaggio di programmazione.
Quello che scrivi è MOLTO MOLTO MOLTO interessante: tu spieghi molto 
bene. Provo a ipotizzare un progetto di massima, più verosimile.
Supponiamo voglia gestirmi il C/C. Seguendo il tuo ragionamento, comincio 
a pensare al DBase: escluderei SQL (non ho tantissimi dati...), la 
portabilità nel tempo potrebbe essere utile, non ho grandi esigenze di 
efficienza... sarebbe corretto pensare ad un banalissimo file 
ASCI? ...più portatile di così si muore. per gestirlo mi verrebbe 
spontaneo pensare al C, perché in C ASCII anche se cambio S.O. me lo 
trasporto; i calcoli non è che siano così semplici ed il C è molto 
potente (numeri molto grandi per il conteggio degli interessi); in 
passato (con esperienze analoghe) con DBIII + Clipper ho avuto grossi 
problemi di precisione. Mettiamola così:
- un piccolo menu (entrate, uscite, browse, stampa)
- carta e penna per studiarmi campi e record
- una piccola maschera di entrate ed uscite
- qualche chiamata al disco per in/out
- una routinetta per la stampa
Ecco... non sembra sia tutto naturale e semplice? Dimmi naturalmente dove 
sto sbagliando... Ciao e grazie.

 sto sbagliando... Ciao e grazie.
Non dico che stai sbagliando. Dipende da quello che vuoi ottenere. Se il 
tuo scopo, ad esempio, è imparare a programmare direi che può essere un 
buon progetto. Altrimenti ti consiglio di guardare i prodotti già pronti 
per fare quello che ti serve.
E.

 In ASCII non hai le lettere accentate. Sei sicuro che non ti servano?
Uh...? Perché no...? Non ho a disposizione 0-255 caratteri?
Ciao,


No, l'ASCII codifica i caratteri da 0 a 127.
E.

 No, l'ASCII codifica i caratteri da 0 a 127.
Dunque, se ho capito bene, non puoi memorizzare in un file ASCII i codici 
ASCII estesi?


In un file puoi memorizzare tutto quello che vuoi. Sta a te poi 
interpretare i codici che ci hai messo. Estensioni all'ASCII ce ne sono 
molte, dovresti sceglierne una. Ad esempio la ISO-8859-15 (a memoria!) 
dovrebbe contenere tutti i caratteri della tastiera italiana.
E.

 Barry


Il fatto che SQL non sia turing-equivalente dovrebbe far venire dei
sospetti sul confronto "sql vs c++".Il confronto e' da evitare per
definizione.
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 206 days.
You should really try it!
http://www.malcom-mac.com/nemo

 livello.
Solo se uno non ha le minime conoscenze di linguaggi formali. Quelle 
che per dire in università vengono date al primo anno.
-- 
There's ways to amuse yourself while doing things and thats how I look 
at efficency.
Donald Knuth

 ASCII estesi?
Puoi, ma è un'informazione *esterna* al file. Per cui se per esempio 
usi la codifica 'standard' di windows per salvare e un'altra codifica 
per leggere, hai già perso la portabilità. Questo non è infrequente 
cambiando OS.
Potrebbe anche essere che Windows ad un certo punto cambi codifica 
standard. Etc etc ect.
-- 
If you optimize everything, you will always be unhappy.
Donald Knuth

 menare il can per l'aia, come si suol dire.
Non è proprio questo il problema. Anche perchè chi si accontentasse del 
bubble sort in C++ farebbe bene a prendere conoscenza dell'esistenza 
della STL.
Proseguendo il thread si è poi capito cosa vuoi intendere. Ovvero non 
vuoi un confronto 'astratto' fra SQL e C++. Vuoi sapere per una piccola 
applicazione cosa vuoi fare.
IMHO la strada più semplice passa comunque per SQL. Scrivere lo schema 
è banale, idem le interrogazioni. Poi prendi un linguaggio di alto 
livello (o al limite usi un motore di interrogazione grafica) e hai 
finito. Mi dicono che Delphi sia particolarmente comodo per questo 
genere di cose (io preferisco altro, ma a te potrebbe piacere).
In C++ è tutto più didattico. Fai tutto a mano, scrivi più codice. 
Probabilmente impari di più. Ma se è qualcosa che vuoi 'vendere' prima 
o poi...
-- 
I have never designed a language for its own sake.
Niklaus Wirth

 bastare.
No, non possono bastare. Tipicamente il problema è che se usi gli 
interi hai di fatto una rappresentazione in virgola fissa che 
probabilmente non basta.
I float/double sono sconsigliatissimi per la matematica finanziaria, in 
quanto *non* si vogliono errori di arrotondamento se appena possibile. 
In Python userei i Decimal, in C++ dovrei pensare a quale libreria 
usare. Forse i razionali di gmp, ma piàù perchè quelli li conosco che 
perchè li consideri la migliore delle scelte.
-- 
Any inaccuracies in this index may be explained by the fact that it has 
been sorted with the help of a computer.
Donald Knuth

 basta.
Perché no? Il tuo conto in banca è un numero intero di centesimi. Non 
puoi fare un pagamento con una risoluzione più alta del centesimo. Usare 
i float sarebbe molto pericoloso (perché non di garantisce la 
correttezza dei risultati) usare i razionali sarebbe del tutto 
insensato, in questo contesto.
E.


-- 
Let us change our traditional attitude to the construction of programs. 
Instead of imagining that our main task is to instruct a computer what 
to do, let us concentrate rather on explaining to human beings what we 
want a computer to do. (Donald Knuth)

 tutti i valori decimali (nemmeno quelli con la stessa virgola). 
No, non c'è nessun problema del genere. Quello che fai è memorizzare il 
numero di centesimi. La rappresentazione binaria/decimale non ha nessun 
ruolo qui.
E.

 nessun ruolo qui.
E invece ha *precisamente* ruolo. E' un problema stranoto, btw. Non è 
che si sono inventati i BCD perchè volevano essere inefficienti 
aggratis. Se metti insieme rappresentazione binaria *e* virgola fissa 
stai creando una bomba per gli errori.
Per dire, se hai 3 valori decimali in virgola fissa rappresenti solo 
numeri frazionari che sono somma di 0.5, 0.25 e 0.125.
Che sarebbe a dire: 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.825
Renditi conto che l'errore (relativo) in queste condizioni è 
*allucinantemente alto*. E infatti per fare calcoli finanziari non si 
usa questa strada, che porta ad errori molto più gravi di quelli che 
hai con la virgola mobile (che pure porta errori).
Rendiamoci conto per esempio che facendo matematica finanziaria con i 
classici fixed point *non* puoi avere un tasso d'interesse del' 1.2%. 
Non lo puoi semplicemente rappresentare. Sarà o dell'1.125% o del 
1.25%. Capisci che è un limite inaccettabile avere un sistema software 
che impedisce al sistema azienda determinate politiche per puri motivi 
tecnici.
-- 
The most important thing in the kitchen is the waste paper basket and 
it needs to be centrally located.
Donald Knuth

 stai creando una bomba per gli errori.
I BCD servono se devi rappresentare numeli decimali *con la virgola*, ma 
in questo caso bisogna rappresentare solo numeri interi. Se vuoi 
rappresentare numeri interi non ci sono problemi di approssimazione. 
Meglio di così non mi so spiegare, forse dovresti rileggere i messaggi 
precedenti.
E.

 messaggi precedenti.
E' irrealistico fare conti finanziari assumendo che tutte le grandezze 
siano intere. Semplicemente. Per cui per fare conti di quel tipo si 
rende necessaria anche qualche altra rappresentazione.
Mi pareva che si stesse parlando di un codo per gestire finanza 
personale, no?
-- 
Science is what we understand well enough to explain to a computer. Art 
is everything else we do.
Donald Knuth

 personale, no?
Di conti correnti, per la precisione.
E.

 Che sarebbe a dire: 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.825
No, se hai tre valori decimali in virgola fissa moltiplichi tutti i
numeri per mille in ingresso e li dividi per mille in uscita. Il
problema principale diventa la gestione del fattore moltiplicativo.
L'aspetto piu' banale e' che nella moltiplicazione naif il risultato
e' scalato due volte, mentre nella divisione il fattore moltiplicativo
si elide. Bisogna anche fare attenzione al fatto che la presenza del
fattore aumenta la probabilita' di overflow ed infine e' possibile che
motiplicazione e divisione tra interi non siano sufficientemente
precise, anche se ti riservi qualche cifra decimale di margine.
La mia libreria rappresentava i soldi scalati di un fattore 10000 su
interi a 64 bit, che venivano convertiti in long double (80 bit) per
moltiplicazione e divisione. Per ovviare al problema dell'overflow il
fattore 10000 era ripartito tra i due termini a monte
dell'operazione.
L'aspetto che non gestivo, ma non mi era stato chiesto, e' la
selezione del criterio di arrotondamento.
Ciao,
Nicola

 risultati devono essere interi (in centesimi).
Il punto è che i calcoli *non* sono approssimati volta per volta, 
tipicamente. D'altra parte non si capirebbe altrimenti perchè tirare a 
mano roba di tutti i tipi quando basterebbero gli interi.
Ci sono spesso e volentieri precise leggi su come e quando 
approssimare. Il che vuole dire che tu non puoi perdere precisione se 
non in determinati momenti (quando la legge te lo consente).


 mano roba di tutti i tipi quando basterebbero gli interi.
Vabbè, lascio perdere, non capisco.
E.

 Vabbè, lascio perdere, non capisco.
Potrei essere pure io a non capire quello che tu dici e rispondo 
ovviamente in base a quello che capisco.
-- 
"Python makes us extremely productive, and makes maintaining a large 
and rapidly evolving codebase relatively simple." (Mark Shuttleworth)