Newsgroup: it.comp.os.linux.ubuntu
Titolo: Sviluppare in C++ per Linux

Ciao,
vorrei sviluppare un progetto in C++ per Linux. Quali strumenti mi 
consigliate di utilizzare (possibilmente visuali)?
Vorrei sviluppare in un ambiente più integrato possibile conviene 
restare sulla piattaforma linux o è meglio utilizzare altri programmi ed 
altri S.O.?
Grazie.

Il 26/05/20 13:07, Higrom ha scritto:

Posso dire che sei hai di questi dubbi già in partenza ti vedo messo 
male... ?


Sto imparando adesso (iniziando in pratic) il C++ e mi piacerebbe fare 
alcuni programmi per linux. Preferirei partire con un ambiente semplice, 
a riga di comando, compilazioni etc. prefererei di no, inizialmente almeno.
Personalmente non ci vedo niente di male. ;)


P.S: anche le maschere di interefaccia temo non sia poi possibile 
realizzarle senza un ambiente integrato e visuale. ;)

Il 26/05/20 13:07, Higrom ha scritto:

puoi provare con glade e poi il codice lo scrivi con codeblock.
entrambi dovrebbero essere sui repository ufficiali
gcc dovrebbe gia essere installato altrimenti lo installi.
buona fortuna.
 
-- 
grigio

Il 26/05/20 13:07, Higrom ha scritto:

comunque se gia conosci l'argomento su wwindows puoi provare sta roba qua
 
https://code.visualstudio.com/Download
 
 
-- 
grigio


Code::blocks
 
 
-- 
Le banche hanno risposto a Conte sul "prestare
con amore". Hanno detto che per loro è solo sesso.
 


temo invece che ti dovrai adattare.
ma sei sicuro di volerlo fare in c++ che non conosci? la curva di 
apprendimento è ripida e per le applicazioni desktop con gui si usano 
altre piattaforme (es. electron, 
https://www.electronjs.org/
).
 

Il 26/05/20 15:29, rootkit ha scritto:

tu come al solito hai la calamita per le cagate e la merda in generale
electron UN SUCCESSONE.... STRAROTFL!
ma perchè non la smetti di voler fare sempre il primo della classe 
quando sei solo alle elementari.
cazzo se togliamo la tua fonte di informazione primaria(google) sei il 
nulla assoluto.
 
 
-- 
grigio


Purtroppo il progetto originale, dal quale vorrei prendere spunto, è 
stato realizzato in C++ (*.hpp, *.cpp).
Anch'io preferirei un linguaggio più semplice, suggerimento che terrò 
presente per altri, eventuali, usi. ;)

 sei il nulla assoluto.
 
Però ha ragione, il C++ soprattutto se si vuole andare su
programmi con interfaccia grafica è un 8000, se posso
prendere a prestito un'immagine montanara. Ancora non so
come ho fatto ad acquisire quel minimo di conoscenza che
ho, e che valuterei nel 25% di un programmatore decente,
anni di sbattimento e insuccessi. Forse non sarò una cima
ma ancora devo trovare qualcuno che dica che è una cosa
semplice. Il solo fatto di essere totalmente responsabili 
della memoria è un ostacolo che capisce solo chi ha dovuto 
affrontarlo per problemi non banali.



QtCreator come ambiente e Qt come framework per le interfacce
grafiche (puoi crearle usando solo il C++ usando QWidget).
 
Se devi imparare il C++ pero' puoi sempre usare QtCreator
come ambiente senza usare il Framework Qt. E la strada e' lunga
e piena di soddisfaz...frustrazioni. :-D

 altri S.O.?
 
Di fatto da questo punto di vista il sistema operativo dove sviluppi è
ininfluente. La differenza la fa il sistema operativo per cui vuoi sviluppare,
ovvero la piattaforma di destinazione. Se la piattaforma di destinazione è
Linux, allora ti conviene lavorare sotto Linux (anche se Qt permette uno
sviluppo quasi multipiattaforma). Differentemente, se la destinazione è
Windows, ti conviene usare quella di piattaforma (e tra gli IDE, oltre a quelle
multipiattaforma che ho citato prima, si aggiungono C++ Builder e Visual
Studio)
 
Enrico

 caricare via codice e che ti disegna l'interfaccia)
 
A scanso di equivoci vorrei specificare che con Qt puoi scrivere
l'interfaccia tutta via codice senza tool visuali (che a mia
opinione crerano poi codice schifoso e non impari ad avere piu'
controllo sui risultati). Questo usando QWidget e classi derivate.
Una volta imparato a usare i layer si ottengono buoni risultati.
E naturalmente il concetto di signal e slot per qualsiasi QObject.
E il riusltato e' praticamente cross platform con una sola base
di codice. Certo, c'e' moc di mezzo, ma vabbe'.
 
Ma se deve imparare il C++ c'e' un bel po' di strada da fare
prima...QtCreator va bene lo stesso. Devo dire che per essere
gratuito e' ottimo ed impari ad usare da subito un ambiente
multipiattaforma.
 

 non banali.
 
Ma e' anche un vantaggio, proprio perchè ne hai il controllo.
E per certe applicazioni e' fondamentale.
Che C++ sia una montagna pero' e' vero, con le ultime poi
da C++11 a C++20...ma anche restando a C++03. pero' s'impara
molto di piu', anche se ti devi fare un bel mazzo.

 solo chi ha dovuto affrontarlo per problemi non banali.
 
deve esserci una necessità concreta per lavorare a gestione manuale. al 
giorno d'oggi oltre ad essere un ostacolo è per lo più un inutile 
rischio: esistono linguaggi anche compilati nativi (non sto parlando 
quindi jvm, .net runtime o simila) che oltre a gestire la memoria in modo 
automatico hanno controllo stretto a compile time anziché a runtime.
 


Ma tu che cazzo ne sai?
Io a leggere la tua risposta ti vedo male!

 automatico hanno controllo stretto a compile time anziché a runtime.
 
Questa cosa e` interessante.
Mi fai un esempio?
Quale linguaggio compilato ha un
controllo "stretto" compile time?
 
bye,
 
-- 
 
piergiorgio


ultimamente sto vedendo rust.
https://www.rust-lang.org/
 
 

 compile time anziché a runtime.
 
Io ne farei a meno, magari. Ma per esempio, il programma 
su cui sto lavorando ora ha certamente un overflow in 
scrittura tra le varie "new" perché farcisco 
abbondantemente di assert ogni 4-5 linee e i torni non 
contano :D Se provo a compilarlo in modo debug, manco a 
dirlo i simboli inseriti fanno sparire il problema per i 
noti motivi. E allora ho trovato un programma che prova a 
fare controlli migliori, drmem, ma anche così non riesco a 
individuare dove. A quanto ne so è il programmatore che 
deve farsi carico di evitare overflow e puntatori 
invalidi, se c'è un altro sistema, ma ovviamente sempre in 
C++ ben venga.
 
Sul resto stendo un pietoso velo (per me). Gli standard 
successivi al 2003 per me sono buio totale e non riesco a 
convincermi che sia qualcosa di diverso dal parto di menti 
che hanno pochissimo contatto con i problemi reali, 
proprio perché sono grandissimi cervelloni.


 invalidi, se c'è un altro sistema, ma ovviamente sempre in C++ ben venga.
 
Questo e` un "noto" problema del C++, per
cui molti lo evitano.
 
Il fatto e` che il C++ maschera _parzialmente_
la gestione della memoria, per cui e` facile
fare errori ed e` difficile trovarli.
 
Forse conviene andare un gradino in basso, cioe`
C (dove e` facile fare errori, ma non troppo
difficile trovarli), oppure uno o due in alto
(qualunque linguaggio piu` "moderno").
 
bye,
 
-- 
 
piergiorgio

 problemi reali, proprio perché sono grandissimi cervelloni.
 
 
Io ho provato da me, purtroppo dove lavoro non sono
cosi' "innovativi". Mi sembra ci siano alcune cose utili
altre ulteriori sofisticazioni non necessarie.
 
Una cosa importante e' il multithreding ora inserito
nella stl. Francamente pero' confesso anche io che
se non devo aggiornarmi per lavoro non ho ne' il
tempo ne' le energie. anche perche' era gia' complesso
prima, e ora, anche se provi a studiare, se certe funzionalità
non le usi quotidianamente non le ricordi, almeno io
non le ricordo.
r-value references, lambda expression, le regole
di risoluzione di "auto" diverse da quelle dei template che tra
l'altro ora permettono di confezionare costrutti
piu' incompresibili ancora...ecc..ecc... c'e' da sclerare.
 

 controllo "stretto" compile time?
 
A parte Rust, Go (che "incorpora" un GC nel compilato), Objective C e Swift
(che usano una tecnica chiamata Automatic Reference Counting introdotta in
Clang da Apple)
 
Enrico

 ancora...ecc..ecc... c'e' da sclerare.
 
 
Mi fai sentire meno solo, grazie :)
 
 
-- 
Ieri ho fatto la spesa ed è stato come la prima
volta che ho fatto sesso. E' stato meraviglioso,
è durato poco e ho speso 50 euro.
 

 Mi fai sentire meno solo, grazie :)
 
Il fatto è che continuano a mantenere qualsiasi compatibilità
con il passato. E fanno bene, è necessario.
In altri casi ci sono delle funzionalità che non sono compatibilita'
con il passato ma sono li' perche' anche se la soluzione piu' moderna
da scegliere nel 99% dei casi non è la migliore, o non va proprio bene
per quell'1% rimanente e allora ok, teniamoci tutto 'sto giudame.
 
Ma a questo punto assurdo bisognerebbe che i compilatori, con
opportuni flag, iniziassero a deprecare (con warning o error a scelta)
costrutti non considerati "moderni", in modo che si formi una
generazione di programmatori che usino cio' che i cervelloni
ritengono "best practice" e che i vecchi tendano ad aggiornarsi.
 
Altrimenti, giovani, vecchi, esperti e novizi continueranno
a risolvere i problemi nelle millemila maniere possibili,
tutte magari funzionanti ma non tutte moderne o ottimali,
riusabili, solide e bla bla bla.
 
Se si leggono i testi sacri c'e' pieno di "lo puoi fare
ma è quasi sempre da evitare perche' e' meglio cosi..."
 
Leggi sul multithreading incluso nella STL che quasi
in ogni caso e' meglio usare i task invece dei thread
con tanto di "rationale" perfettamente spiegata.
 
E cosi' per un sacco di altri aspetti.
 
Bene...allora sarebbe l'ora che i compilatori siano
in grado di svolgere un'analisi statica del codice e
che ti segnalino ANCHE questi aspetti stilistici.
 
I puntatori non andrebbero piu' usati nel 99% dei casi?
Allora cagami il cazzo perche' io usi gli smartpointer,
pur lasciandomi libero di usare i puntatori classici
sopprimendo a mio giudizio la segnalazione.
Magari invece, se non lo so, vado a vedere cosa sono
questi smartpointer e magari, piano piano, acquisisco
uno stile di scrittura moderno.
 
Uno che non sa nulla di C++ e che deve imparare oggi
ha una montagna indistinta davanti di possibilità
e va a finire che ognuno impara a scrivere le stesse cose
a modo suo o dell'azienda in cui lavora mischiando vecchio e
nuovo a muzzo. (Visto ovunque di persona)
 
Cazzo, tra un po' non e' piu' programmazione ma e' letteratura!
 
 
 

 mischiando vecchio e nuovo a muzzo. (Visto ovunque di persona)
 
ma infatti non ha senso. il c++ o ci sono vincoli architetturali 
mandatori altrimenti non ha senso adottarlo ne impararlo. alla luce del 
fatto che ci sono altri linguaggi compilati che offrono le stesse 
performance, lo stesso footprint, stessa portabilità, stesso tutto ma con 
aderenza ai paradigmi più coerente, migliore espressività, maggiore 
controllo a compile time (che vuol dire più sicurezza e meno bug). se vai 
a vedere fra i software di sistema a parte quelli a molto basso livello 
non è praticamente più adottato.
 


Si, per il gigante che e' diventato ci vorrebbero dei vincoli
ma anche lo strumento automatico che li verifica altrimenti
sei del gatto, non e' umano infatti rispettarli a memoria
a meno che non siano 4 cazzate che non risolvono il problema.
 
Francamente non ne so molto degli altri lunguaggi compilati
alternativi, e soprattutto il loro ecosistema, framework,
compilatori, librerie (immagino possano bindare a quelle per il C/C++)
Forse di riferisci a R?
 
Sul fatto che non si usi praticamente piu' a parte per sw a bassissimo
livello pero' non concordo, almeno per mia esperienza diretta.
E' usato ancora anche per applicativi Desktop per dire, e anche
in diversi annunci di lavoro continua ad essere richiesto.
 
Fino ad ora, non ho avuto occasione di vedere usata alcuna alternativa
nelle aziende, a parte altri linguaggi ma che appunto, non sono
un'alternativa ma vanno meglio per altri scopi.
 
Ci sono anche fior di linee guida per applicazioni mission critical
e relativi prodotti per l'analisi statica e anche dinamica di
codice C++.
 
Mi perdo altre alternative oltre R?

 Mi perdo altre alternative oltre R?
 
fra quelle che conosco io go, rust. ma anche swift, objective-c.
in go è scritto praticamente tutto ciò che riguarda i container, da 
docker a kubernetes.
 

 Mi perdo altre alternative oltre R?
 
Go.
Rust.
Swift.
Objective-C.
 
Ma anche:
D (che nonostante tutto è più vivo di quanto si pensi).
Pascal/Object Pascal/Delphi (sì, è vivo e lotta con noi).
 
Oppure (che ok che non ci fai roba di sistema, ma non hanno nulla da invidiare
a C++):
Java.
C#.
 
R di fatto non è considerato un linguaggio di programmazione, ma un linguaggio
di analisi statistica, e anche qui soffre parecchio la concorrenza di Python
 
Enrico

 C#.
 
ok ma questi però hanno l'astrazione di un runtime environment.

 ok ma questi però hanno l'astrazione di un runtime environment.
 
Per questo dicevo che con C# e Java non ci fai roba di sistema. Che poi,
tenendo conto che tutti e due compilano AOT, dovrei capire fino a che punto
ci si può spingere
 
Enrico


Fortran?
Compilato anche lui. Anche lui non ci fai roba di sistema, ma se ci metti R...

 letteratura!
 
Ho provato in tutti i modi a evolvermi un po' ma ho perso
da tempo la poca elasticità mentale che avevo. A me
servirebbe qualcosa che mi facesse vedere come si è
arrivati a quella certa soluzione, un problema pratico che 
è inelegante risolvere altrimenti, e solo dopo dare il
nome al costrutto. Non capirò mai robe come espressioni
lambda e tanto altro. Anche perché per me non è più parte
del mio ex-lavoro, e da tempo scrivo solo programmini per
mio uso quando non trovo qualcosa di già fatto. Mi sa che
resterò al livello in cui sono, basso.


 Compilato anche lui. Anche lui non ci fai roba di sistema, ma se ci metti R...
 
Se devo essere preciso, R non l'ho tirato dentro io, io mi sono limitato a dire
quali sono le alternative a C/C++ e quali a R...
 
Enrico

 Enrico
 
Buono a sapersi,
Ciao!

 resterò al livello in cui sono, basso.
 
E' normale direi, se non e' uno strumento di lavoro che
mastichi tutti i giorni ed inoltre ci vorrebbe anche
un ambiente di persone che tendono, anche con calma,
ad aggiornarsi e usare le cose nuove.
 

 e inadatti, come giiustamente scrivi, a software di sistema.
 
Non è che perché non ci puoi scrivere software di sistema[1] significa che non
sono ottime alternative. Per intenderci, Java ha prestazioni comparabili a C++,
tanto che di fatto è diventato l'alternativa per antonomasia al linguaggio di
Stroustrup
 
Enrico
[1] Che poi bisognerebbe anche capire cosa significa questa classificazione, di
fatto quello che proprio non ci puoi fare è scrivere device driver

 Sta facendo anche lui la fine di R, ovvero Python lo sta soppiantando
 
Ma come prestazioni?
Non ci sono grosse differenze?
Avevo avuto a che fare con un codice in fortran anni fa che
faceva calcoli piuttosto complessi di taratura parametrica
e blablabla, niente di complicato a livello di programmazione
comunque.
E ricordo che compilandolo con gcc/gfortran, si otteneva un
eseguibile che andava come una lumaca rispetto allo stesso
codice compilato con ifort, la versione proprietaria intel del
compilatore fortran.
E i tempi in gioco alla fine erano troppo diversi: parliamo
di giorni... Ovvero il compilato da ifort produceva risultati
accettabili molto molto prima del corrispondente gfortran.
Tieni conto che si trattava di un grosso ciclo ripetuto al-
l’infinito: tanto più gira, tanto più trova valori migliori.
 
 
Python da quel poco che ho capito è parecchio più semplice,
soprattutto a livello di input/output e interazione col sistema.
Mi ripropongo sempre di impararlo un po’, ma per ora è rimasto un
proposito.
Ma siamo sicuri che in ambito di calcolo numerico, che è poi
quello del fortran, python sia altrettanto prestante?
 
 
 
PS.
Chiedo una curiosità visto che siamo in tema di compilati e
compilatori... E magari sapete rispondermi.
La maggiore velocità che avevo constatato usando il compilatore
ifort di intel rispetto a gnu/gfortran, era ottenuta su una
macchina con processore intel.
Secondo voi, si ottiene comunque un identico vantaggio usando
il compilatore intel su un PC basato tipo su uno dei nuovi AMD
Ryzen, tanto per fare un esempio?
 
Intendo: il vantaggio di quel compilatore proprietario era
dovuto al fatto che lavorava su un processore dello stesso
produttore intel, oppure sfrutta possibilità che sono presenti
parimenti anche sui processori AMD?

 Non ci sono grosse differenze?
 
In teoria sì, Python è molto più lento rispetto a Fortran. In pratica, grazie
all'uso di librerie tipo NumPy, la differenza di prestazioni è notevolmente
mitigata (siamo sull'ordine di 1/2 secondi di differenza), tanto da rendere
la questione in secondo piano rispetto alla scelta del linguaggio e della
piattaforma. Di più non ti so dire, da questo punto di vista sono solo un mero
spettatore (ovvero non uso né Fortran, né Python per il calcolo scientifico, ma
mi baso su quanto leggo in giro a riguardo)
 
Enrico

 antonomasia al linguaggio di Stroustrup
 
java però rispetto ai compilati nativi perde parecchi punti quando usi i 
container. tira su un castello che in un container ha pochissimo senso, 
con un footprint esagerato, inutili configurazioni e complicazioni nel 
monitoraggio. 
 

 container.
 
Il mio Java è differente ;)
Se tiri in mezzo i container, mi viene in mente che stai parlando di
un'archittettura a microservizi. In questo caso, lo sviluppatore medio usa
Spring Boot che è la morte, proprio per i motivi che citi. Purtroppo, il
maggior problema nell'ecosistema di Java è lo sviluppatore, che ha imparato
tecniche di programmazione tempo addietro e non si è mai evoluto (un mantra
del programmatore Java medio è "che ti importa di mantenere un uso basso della
memoria, Java la gestisce in automatico")
 
Enrico
P.S. non capisco quali sarebbero le complicazioni di monitoraggio di
un'applicazione Java che gira in un container...

 di un'applicazione Java che gira in un container...
 
per esempio rispondere alla fatidica domanda: quanta memoria sta usando 
il programma? di fatto non si può sapere: se controlli il container non 
hai il dato corretto, se controlli la jvm nemmeno. il problema è che la 
jvm la memoria del container tende a occuparla tutta (o comunque per 
ovvie ragioni la si configura perché la occupi tutta, visto che è tutta 
sua) e d'altra parte il gc di java fino a che l'occupazione non si 
avvicina al limite max heap non interviene. quindi vedi inesorabilmente 
un dente di sega tendente al massimo a prescidere senza avere un dato 
attendibile dell'uso effettivo.
 
 
 

 il programma?
 
Oddio, a ragionarci sopra, per come l'hai messa, mi sembra un problema comune
a qualsiasi applicazione che gira in un container, a prescindere se si tratta
di una applicazione scritta in Java o in un altro linguaggio. Che poi,
personalmente, prenderei come buona la memoria utilizzata dal container tutto,
perché di fatto diventano un ambiente unico. Se poi ne sta consumando troppa,
Docker permette di limitare la memoria utilizzata dal container, così come
Podman
 
Enrico