Newsgroup: it.comp.lang.c++
Titolo: saluto, presentazione e richiesta consiglio

Un saluto a tutti,
mi sono appena iscritto al ng:
mi presento: mi chiamo Federico e ho 45 anni, di questi una buona parte
l'ho trascorsa nell'informatica, prima con PASCAL, COBOL, CLIPPER, e poi
con PHP, affiancando l'attivita' di sviluppatore con quella di
sistemista/risolutore di problemi/parafulmine.
Ora, "nel mezzo del cammin" ( almeno, lo spero!) e stanco dei browser di
cui non ci si puo' fidare nel modo piu' assoluto (in quel campo lo
standard e'... "ognuno ha il suo"), ho deciso di riprendere in mano
C/C++ e QT per rinnovarmi un po', e per non impazzire del tutto.
e' da tempo che tento di imparare da solo il C++ dai libri (ne ho
collezionato un bel po' (si, li ho anche letti ;-) )), ma alla fine ho
deciso di tenerli solo come consultazione e di prendere in mano un
progetto, magari messo in sospeso dallo sviluppatore, o, meglio ancora,
abbandonato del tutto, che potesse servirmi da "palestra".
Gia', buona idea, almeno a prima vista: ma dove trovarne uno con le
caratteristiche adatte?
cioe':
0) OpenSource
1) C++ multipiattaforma Linux/Windows (anche solo Linux andrebbe bene,
almeno per ora)
2) Gui, ma non solo, usando le QT 4/5
3) interazione con i db (MySql in primis)
4) possibilmente di tipo "gestionale"
(Ma ^sopprattutto^)
- scritto BENE: che rispetti non tanto l'identazione, piuttosto la
filosofia del linguaggio.
 
... e per questo ho bisogno di una indicazione: ho guardato su
sourceforge (se conoscete altri siti simili ben vengano), ma a parte i
primi 4 punti, quello che mi preoccupa di piu' e' il punto 5: Come capirlo?
 
Altri metodi per imparare veramente non ne conosco.
 
Saro' grato a quanti di voi mi daranno una mano.
 
A risentirci presto.
 
Federico.

Il 10/11/2012 08:38, Federico Braghieri ha scritto:
 > Gia', buona idea, almeno a prima vista: ma dove trovarne uno con le
 > caratteristiche adatte?
 > cioe':
 > 0) OpenSource
 > 1) C++ multipiattaforma Linux/Windows (anche solo Linux andrebbe bene,
 > almeno per ora)
 > 2) Gui, ma non solo, usando le QT 4/5
 > 3) interazione con i db (MySql in primis)
 > 4) possibilmente di tipo "gestionale"
 > (Ma ^sopprattutto^)
 > 5) scritto BENE: che rispetti non tanto l'identazione, piuttosto la
 > filosofia del linguaggio.
 
Un consiglio: se ti interessa il software gestionale, non cercare di 
usare il C++; se ti interessa il C++, non cercare di usarlo per fare 
software gestionale.
Il C++ e' poco usato per scrivere software gestionale, e sara' sempre 
meno usato a tale scopo. Le suoi settori applicativi preferiti sono il 
software di sistema (sistemi operativi, driver, DBMS, interpreti, ecc.) 
e il software tecnico/scientifico (CAD, CAM, CAE, GIS, ecc.).
Se ti interessa il software gestionale, le architetture del presente e 
del futuro sono il Web, la JVM, e il .NET Framework.
Comunque, se ti interessa un progetto che soddisfa i requisiti 0, 1, e 
5, scrivimi in privato (togli".nospam").
 
-- 
 
Carlo Milanesi
http://carlomilanesi.wordpress.com/
 

 e il software tecnico/scientifico (CAD, CAM, CAE, GIS, ecc.).
 
Aggiungo due importanti settori applicativi per il C++: il software 
embedded e i videogiochi fotorealistici.
Il software embedded e' ancora oggi dominato dal C, soprattutto sulle 
piattaforme a 8 bit, ma sulle piattaforme a 16 o piu' bit il C++ viene 
usato sempre piu' spesso, e quindi e' il linguaggio del futuro.
Per quanto riguarda i videogiochi, e' in corso la tendenza, soprattutto 
per i produttori non molto grandi, ad adottare un "motore" scritto da 
altri, e realizzare la logica applicativa in un linguaggio di piu' altro 
livello, come Java o C#. Quindi, in tale settore, il C++ e' il 
linguaggio del passato e del presente, ma, eccetto per i pochi che 
scrivono gli engine, non ha un grande futuro.


> Il C++ e' poco usato per scrivere software gestionale
 
Come avevo scritto nel mio intervento:
"...stanco dei browser di cui non ci si puo' fidare nel modo piu'
assoluto..."
E' per questa ragione (e per altre meno importanti) che ho scelto
scientemente il C++: non conosco un linguaggio ( a parte il C) piu'
standard in assoluto ( e, fatti gli opportuni distinguo,
multipiattaforma e che mantenga una efficenza elevata)
Il fatto, poi, che il c++ non venga utilizzato, o sia il meno
utilizzato, per scrivere sw gestionale, in un'ottica di formazione mi
sembra dovrebbe essere l'ultimo dei motivi da prendere in considerazione
(v.a.d.: ovvio che l'aereo e' il piu' veloce, ma se dovessi fare un
reportage di viaggio devo scegliere un mezzo di trasporto piu' adeguato!).
Se volessi "facilitarmi la vita" mi scaricherei un sw gia' fatto (magari
opensource). In effetti per l'utilizzo personale, ne sto gia'
utilizzando alcuni.
Il problema e' che non mi e' mai piaciuta la "pappa pronta".
Altrimenti invece del programmatore, farei altro.
Per quanto riguarda poi l'utilizzo di strumenti gia' pronti, sempre in
considerazione del mio scopo finale ( che non e' il programma, ma
imparare l'utilizzo del linguaggio), credo siano piu' che inutili: direi
dannosi. Un po' come abituarsi all'IDE preferito, e poi trovarsi in una
realta' dove si utilizza solo vi o emacs.
Posso capire il discorso in una realta' di produzione, ma non in una
realta' di "formazione".
 
Comunque grazie della(e) risposte.
 
Federico.
 
 
 

 realta' di "formazione".
 
Non ho mai suggerito di usare prodotti gia' funzionali, ma solo di 
scegliere lo strumento di programmazione piu' adatto per il compito.


 Che cosa significa "v.a.d."?
 
Vale A Dire.
Federico.

 scegliere lo strumento di programmazione piu' adatto per il compito.
Colpa mia, evidentemente ho capito male.
 
Federico
 
 

 quello che vorrei fare/diventare.
 
Qui e' off-topic, ma consentitemi una breve osservazione.
PHP e shell-script, come anche Perl, sono ottimali per progetti 
relativamente semplici, in cui una o due persone lavorano a un progetto 
per meno di un anno. Se questo e' il tuo obiettivo, continua cosi'.
Se invece vuoi cimentarti in grandi progetti, in cui ci sono tre o piu' 
programmatori, o che richiedono piu' anni di sviluppo, allora ritengo 
opportuno adottare altri linguaggi. I piu' utilizzati (per software 
gestionale) sono Java, C#, Python, e Ruby. I primi due hanno anche buone 
prestazioni computazionali.



Ti posso dare regione per progetti semplici  su PHP e shell script ma 
non su Perl
Perl non ha niente da invidiare a Java,C#,ecc..
 


Ci sono ottime eccezioni.
Facebook, twitter, Google+, tra tanti, usano principalmente PHP, comunque sono
su uno stack LAMP.
Ruby è un giocattolo, io non ci farei mai nulla.
Su C# per fare qualsiasi cosa boh, son gusti, ma io, a meno che non sia 
costretto, non lo sceglierei mai come linguaggio di programmazione (e mi piace
pure un po', eh).
Perl è un linguaggio che non sceglie più nessuno per un nuovo progetto, visto
che ci sono ottimi replacement (come Python).
Ciao!

solo compilatore, o fanno assunzioni non portabili sull'architettura target. 
 
Son d'accordo che il C++ non è molto portabile di suo... ed in effetti inizialmente Federico ha parlato di accoppiarlo con le QT.
A mio avviso le QT sono un "cuscinetto" spettacolare di compatibilità/astrazione del Sistema Operativo , dei DBMS, del FileSystem, delle Interfacce di Rete , etc...
Non dico che grazie alle QT il C++ si presta ad un approccio RAD, ma rispetto alla "lentezza" di creazione dal C++ puro gli danno un bel boost.
Infatti le GUI si creano molto velocemente e sono particolarmente versatili.
Il modulo QtSql ti permette di astrarti rispetto al motore SQL sottostante e scambiare eventualmente al volo e a runtime da MySQL a SQLite in maniera totalmente trasparente agli oggetti che utilizzano il DB.
Per quanto riguarda poi le chiamate "specifiche" dei sistemi operativi quali per la gestione delle interfacce di rete, i mutex, i thread ecc esistono delle astrazioni QT che interagiscono in maniera identica su tutte le piattaforme Win/Linux/Mac. Inoltre, internamente per il FS viene utilizzata la notazione Unix anche su Win e le librerie QT fanno le adeguate conversioni per Win.
Grazie QtScript poi, è possibile implementare dentro il proprio Software anche un'interprete di linguaggio ECMAScript (Javascript like per intenderci) ed esporre una parte degli oggetti C++ interni oppure delle'API degli stessi come oggetti per lo Script, in modo da poter definire non delle semplici "macro" ma degli script in piena regola, una caratteristica che può ritornare utile in diversi campi d'applicazione, tipo un gestionale.
Per quanto riguarda il processo "lento" di compilazione con il sistema a PlugIn delle QT è possibile realizzare un Software Modulare, ed all'occasione ricompilare SOLO il modulo Fixato e non tutto! Questo inoltre ti permette di creare PlugIn successivamente o anche di terze parti senza andare a modificare il codice che lo utilizza: Vecchio codice utilizza Nuovo codice(...e ditemi se questo non è elegante!).
Poi grazie al sistema Signal/Slot il tutto diventa molto più intuitivo e interessante, una volta entrati nell'ottica.
 
Direi che può bastare, altrimenti divento noioso... già ho scritto troppo per essere una risposta.
Anche se ci tengo a precisare che tutto questo è solo la punta dell'iceberg...!
P.S.: Nativo per Maemo e compatibile anche con Android! ...e concludo!

 P.S.: Nativo per Maemo e compatibile anche con Android! ...e concludo!
 
 
-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
 

 
 
Per qualunque approfondimento o getting started io consiglio la documentazione ufficiale:
http://qt-project.org/doc/qt-4.8/
 
 
Nello specifico per il modulo QtScript:
http://qt-project.org/doc/qt-4.8/qtscript.html
 
 
Esperienza mia personale, non spendete soldi a libri su Qt, perchè la documentazione ufficiale è spettacolare... inoltre esistono board dedicate alle Qt dove scambiare idee e chiedere consigli.
 
Ad un novizio consiglierei di usare l'IDE QtCreator (comodo per l'autocompletamento, il refactoring e il setup dei progetti) tramite l'SDK che include il designer per la UI, lo strumento per le traduzioni e una guida interattiva, oltre ad un SDK Maintenence tool che ti permette di stare aggiornato con l'ultima official stable release (attualmente la 4.8.1, lasciate perdere per ora le Qt5...) e i pacchetti aggiuntivi come la documentazione, i sorgenti, gli esempi e le tool chain per la compilazione sulle diverse piattaforme.


Grazie mille delle segnalazioni, le metto nei segnalibri per 
appena avrò tempo di guardarle
ciao
CCCP



 
Grazie per le ottime info!
 
Senti ma per quanto riguarda la programmazione tramite Qt su Android, io 
sapevo che si stava sviluppando una libreria che si chiama Necessitas ma 
che è ancora in versione beta.
Poi ultimamente ho sentito che un'altra società ha rilevato dalla 
Trolltech le Qt (che prima erano della Nokia) e adesso vuole 
ufficialmente portarle su piattaforma Android.
 
In buona sostanza, se volessi sviluppare su Android usando le Qt, oggi 
cosa dovrei usare, non volendo rischiare di cominciare per poi perdere 
tempo su qualcosa ancora in beta version?
 
Maurus
 


Che io sappia le Qt della Troltech sono passate a Nokia e poi a Digia, e non sò delle intenzioni di di quest'ultima a proposito di Android... ma io personalmente mi sono rivolto al progetto della comunity KDE Necessitas 
http://necessitas.kde.org/
 ,che in data odierna è alla beta1 anche molto stabile per essere una beta (per i miei gusti!).
Necessitas è composto da un'applicazione android che si assicura di far trovare nei path del dispositivo il porting delle librerie Qt da parte dello stesso progetto by KDE. 
Per quanto riguarda il cominciare, parti dalla Necessitas SDK 
http://necessitas.kde.org/necessitas/necessitas_sdk_installer.php
 che si integra perfettamente dentro QtCreator e ti permette di fare il deploy per i test direttemente sul tuo dispositivo! Informazioni utili sull'installazione/configurazione/issue/etc 
http://community.kde.org/Necessitas/InstallSDK
 .
Ancora il nostro progetto è acerbo sul piano mobile e qundi non posso darti molti suggerimenti a riguardo, dato che ho fatto giusto delle "prove tecniche di trasmissione" in questo settore! Comunque considerati i tempi di rilascio delle varie release più o meno stabili della alpha, penso che la beta non tarderà a maturare! La roadmap e i tempi attuali del nostro progetto sono molto compatibili, poi le tue necessità io non le conosco e potrebbero non andarti bene... comunque io gli darei lo stesso un'occhiata!

 Poi grazie al sistema Signal/Slot [...]
 
Premetto che chiamo "gestionale" un'applicazione software contenente 
almeno 50 distinte operazioni di inserimento, aggiornamento, o 
cancellazione dati (senza contare le estrazioni dati) su un DBMS.
 
Da come viene presentato qui, il sistema di programmazione QT (che per 
la sua completezza e invasivita' puo' essere visto piu' come una 
estensione del sistema di programmazione C++, invece che come una 
semplice libreria) sembra idoneo anche per scrivere applicazioni gestionali.
 
Ma mi risulta che quasi nessuno usi il C++ a tale scopo, almeno per 
nuovi progetti.
 
Secondo voi (poe84it e chiunque legga questo post), in quali condizioni 
(piattaforma, tipo di applicazione, personalità ed esperienza del 
programmatore, ecc.) e' preferibile sviluppare un'applicazione 
gestionale in C++ rispetto ad un altro sistema o linguaggio di 
programmazione?


A mio avviso dipende come mastichi e pasticci il C++! Io credo di districarmi abbastanza bene, e seppur essendo il C++ un linguaggio fortemente tipicizzato e abbastanza prolisso, con le Qt io mi ritrovo tanta bella pappa pronta! Soprattutto per i motivi elencati in una mia risposta precedente!
Ovvio che le Qt ti offrono la possibilità di andare sia su di una collina che su la luna. Se il tuo progetto si trova nel mezzo nessuno ti vieta di usare anche solo un 10% dell'infrastruttura che le Qt offrono. Per dirette una, io ancora non ho un lato 3D nel mio progetto attuale, ma siccome le Qt mi permettono di fare 3D non significa che io sia obbligato! Altri progetti che ho terminato non erano gestionali e non richiedevano accesso a DBMS e anche se Qt lo offre non l'ho utilizzato! È una pizza su cui puoi mettere 1 solo condimento o tutti! A te la scelta migliore per l'occasione!

 Ovvio che le Qt ti offrono la possibilità di andare sia su di una collina che su la luna. Se il tuo progetto si trova nel mezzo nessuno ti vieta di usare anche solo un 10% dell'infrastruttura che le Qt offrono. Per dirette una, io ancora non ho un lato 3D nel mio progetto attuale, ma siccome le Qt mi permettono di fare 3D non significa che io sia obbligato! Altri progetti che ho terminato non erano gestionali e non richiedevano accesso a DBMS e anche se Qt lo offre non l'ho utilizzato! È una pizza su cui puoi mettere 1 solo condimento o tutti! A te la scelta migliore per l'occasione!
 
quindi quando vai a linkare il solo necessario, le QT 
diventano fortemente modulari, in modo da rimanere leggere 
(sugli eseguibili) ?


 Ovvio che le Qt ti offrono la possibilità di andare sia su di una collina che su la luna. Se il tuo progetto si trova nel mezzo nessuno ti vieta di usare anche solo un 10% dell'infrastruttura che le Qt offrono. Per dirette una, io ancora non ho un lato 3D nel mio progetto attuale, ma siccome le Qt mi permettono di fare 3D non significa che io sia obbligato! Altri progetti che ho terminato non erano gestionali e non richiedevano accesso a DBMS e anche se Qt lo offre non l'ho utilizzato! È una pizza su cui puoi mettere 1 solo condimento o tutti! A te la scelta migliore per l'occasione!
 
Il problema non è il linguaggio, è il paradigma.
Quasi nessuno usa più il "fat client" per svariati motivi che non sto a
descrivere (difficoltà di aggiornamento, eccessiva latenza nelle operazioni
di routine, decentralizzazione delle competenze, etc.)
 
Ciao!

Il fat client però può essere utile nelle situazioni in cui un approccio web o rende il tutto limitante, tipo se hai a che fare con hardware specifico per esempio, come uno scanner di barcode o una tavoletta grafica o una stampante di etichette! E poi chi ha detto che è difficile da aggiornare un fat client? La logica vera e propria la inserisci in una libreria e l'esecutivo semplicemente la linka e magari prima di avviare controlla nel repository degli aggiornamenti se c'è una versione aggiornata delle varie librerie, questo virtualmente ti permetterebbe anche, unito ad un'architettura modulare, di poter effettuare gli aggiornamenti anche a programma avviato, scarichi dalla memoria il/i modulo/i della/e libreria da aggiornare,  aggiorni, e ricarichi! Questo approccio per un'applicazione long run potrebbe essere auspicabile!
 
Eccessiva lentezza? In alcuni casi potrebbe essere il contrario...!
 
Per quanto riguarda la decentralizzazione anche posso dissentire, perché nulla vieta di poter richiamare delle routine remote sul server della tua app e delegare l'operazione...! Ovviamente parlo per progetti di certe dimensioni/peculiarità. Se un gestionale è per uso singolo, tipo gestione piccolo magazzino, potrebbe essere molto comodo farlo in C++ o .Net se non semplicemente un db in office(libre office! :D), per un gestionale che magari richiede livelli di accesso, modelli complessi, inter-comunicazione tra diverse istanze o macchine, real-time ecc un architettura client/server con procedure remote e un fat/thin client, ma anche web, potrebbe essere più comoda!
 
Chi conosce i design pattern sa che esistono anche gli anti pattern, vale a dire le abitudini o pratiche rischiose se non dannose! Una di queste viene chiamata "the golden hammer"se il tuo unico strumento è il martello allora hai a che fare solo con dei chiodi!
Questo per dire che in base alle necessità bisogna scegliere e valutare i Pro e i contro di molte tecniche, tecnologie e soluzioni! Altrimenti avremmo o solo app locali o solo app web per singolo campo di applicazione! Ma si vedono giochi in locale e giochi web, social in web e social in locale, gestionali in web e in locale!
Questo ovviamente vale tanto nell'informatica quanto in tutti gli aspetti della vita personale e professionale.
Ora, io non voglio fare né il maestrino né essere incoerente, il mio unico scopo è condividere punti di vista e esperienze.

 scopo è condividere punti di vista e esperienze.
 
Infatti, anch'io dico le mie.
Non dico che come dici te non si può fare: è il modo in cui si è fatto per anni.
Poi si è smesso, però! ;) Non è un complotto o cosa, semplicemente si va verso
il sistema che da meno problemi sia in sviluppo che in produzione sotto ogni
qualsiasi punto di vista si possa pensare.
Oltretutto, oltre ai problemi di carico, sicurezza e complessità che ho citato
sopra, ancora non ho scritto la parte fondamentale: prende cento volte il tempo
necessario per lo sviluppo (il numero l'ho tirato a caso, ma è molto molto
di più) per avere praticamente nessuna feature aggiuntiva.
 
Ciao!

Un saluto a tutti e un ringraziamento: ho letto tutti gli interventi e 
devo riconoscere che ho imparato qualche cosa (molte, a dire la verita') 
che non sapevo.
La frase "il c++ non e' molto portabile" di Carlo Mlanesi, mi ha 
distrutto un mito.
anche "L'efficienza del codice generato e' del tutto irrilevante nei 
programmi gestionali" mi ha dato da pensare: secondo me il codice 
(almeno quello in "Produzione") dovrebbe essere "il piu' performante 
possibile" (frase che non vuole dire nulla in se', se non si 
constestualizza nel progetto corrente). Convinzione che non mi ha mai 
lasciato.
Volevo solo precisare che il mio intento primario non e' (o era) 
(solo)quello di sviluppare un "gestionale": in realta' ( ma e' evidente 
che se nessuno degli intervenuti l'ha capito e' colpa della mia 
esposizione) il fine ultimo era quello di imparare il C++ e 
contestualmente le librerie (anche se definirle semplicemente "librerie" 
mi sembra un poco riduttivo) QT.
Il perche' era indicato, ma anche in questo caso non sono stato chiaro: 
^offrirmi^ un'alternativa dell'ambiente web in cui uno standard (se non 
altro a livello di comportamento del browser) assoluto non c'e' ancora.
La tipologia di applicazione ("gestionale", appunto), l'avevo scelta in 
quanto e' quella che si avvicinava a quanto fatto finora ( in php, in 
vbasic, in COBOL, in Verastream, in ...).
Esplorare le varie possibilita' di interfacciare C++ con un DB era ed e' 
una cosa che mi interessa(va) molto.
Anche sviluppare in Android (ma evitando java) e' interessante
(Tra l'altro avevo gia' sentito parlare del progetto Necessitas, ma, 
allora, mi mi sembrava un po' in "alto mare" per approfondirlo).
L'affermazione che il C++ non sia il linguaggio piu' adatto per un 
gestionale, che "c'e' di meglio" (ma, se e' per questo, a qualunque cosa 
"c'e' di meglio", ma questa e'... metafisica), insomma, ^potrebbe^ anche 
trovarmi d'accordo.
MA, in ottica ^didattica^ (quella alla quale sono maggiormente 
interessato, cioe'), e', forse al contrario, un'incentivo a proseguire 
su questa strada.
Almeno IMHO.
 
Ciao e grazie a tutti.
 
Federico.
 
On 10/11/2012 8.38, Federico Braghieri wrote:
 > Un saluto a tutti,

 Perl č un linguaggio che non sceglie piů nessuno per un nuovo progetto, visto


 
 
Ancora non capisco il concetto. Hanno dovuto risolvere dei problemi che 
normalmente non si hanno perché, appunto, sono colossi.
E quindi? Fatto sta che non hanno scelto altre tecnologie.
 
Ciao!