Python. Sto creando una gui.

pabloski

Utente Èlite
2,707
782
Io cerco prima gli esempi ufficiali e li provo. Lo stesso ho fatto per sdl2, tempo fa, ma non moltissimo.

Ti risparmi un sacco di mal di testa. Perchè, siamo onesti, non sempre quello che si trova su internet è corretto e/o veritiero. Però è strano che gli esempi ufficiali ti diano problemi o addirittura non compilino. Del resto SDL non è una libreria amatoriale, ma è molto usato pure in ambito professionale.

Certo, Red Hat sta spingendo al massimo wayland

Magari fosse solo Redhat. Pure il mondo BSD sta migrando a Wayland. Figurati che ho una macchina FreeBSD che gira su Wayland+Sway.

Poi c'è Canonical che da anni sta cercando di introdurre un suo server grafico al posto di Xorg

Che io sappia, il progetto Mir è stato ufficialmente abbandonato. Viene ancora sviluppato, in privato, da alcuni ingegneri di Canonical, con a capo Alan Griffiths. Di fatto è un compositor Wayland ormai. E il suo unico scopo è supportare UBPorts, il fork di Ubuntu Touch ( anch'esso abbandonato ). Considerando che Intel ha deciso, qualche anno fa, di rimuovere tutte le patch per il supporto a Mir nel suo driver grafico, direi che il progetto è defunto.

Sway è un'ottima cosa se parliamo di wayland dato che rende disponibile un window manager svincolato sia da Gnome che da Kde, giusto per mantenere un certo grado di libertà, ciò che ha consentito a Linux di crescere.

Il capo del progetto Sway ha fatto un favore gigantesco alla comunità. Da un lato Sway, il tiling manager clone di i3...e personalmente è il genere di window manager che preferisco. De gustibus. Dall'altro Wlroots, il compositor Wayland, che sta rendendo possibile la nascita di un bel numero di progetti che non siano Mutter o KWin.

Non voglio parlare di sicurezza, oramai ti bucano dappertutto, anche se ce l'hai spento il pc, ti arriva spam per posta ordinaria dicendoti che non potevano farlo tramite computer perchè è spento.

Vabbè, però non siamo autorizzati ad usare software insicuro by design.

Io non sono contro wayland, ma non è completo nè ottimizzato.

Anni fa. Del resto il punto di Wayland è che non si occupa di disegnare gli elementi grafici. Lo lascia fare ai client, come meglio credono. Richiede una frazione dello sforzo necessario per sviluppare e mantenere Xorg e si integra perfettamente nei meccanismi implementati in-kernel ( evdev, drm e kms ).

Cioè, i 10 anni sono stati usati in massima parte per smembrare Xorg, portare alcuni dei suoi meccanismi nel kernel, trasformare Xorg in un server root-less e tante altre cose. Il tutto senza che fosse necessario riscrivere i millemila programmi che girano sotto X.

Insomma, lo stanno ancora sviluppando, da più di dieci anni.

Dieci anni per realizzare una transizione lenta ed indolore. Non dimentichamo che gli stessi ingegneri che sviluppavano Xorg hanno realizzato Wayland. C'hanno messo 10 anni, perchè volevano una transizione non dirompente ( tipo quella avvenuta con KDE 4 ).

Spero che tutti quelli che ci fanno i soldi con Linux capiscano che Linux non è un sistema operativo commerciale ed è meglio per tutti che non lo diventi, mica Microsoft e Google campano d'aria.

Oddio, non che le due cose siano mutuamente esclusive. Cioè nessuno impedisce ad un tizio pazzo di creare da zero il suo compositor. E infatti esiste Arcan https://arcan-fe.com/about/

Per la cronaca, potrebbe essere quello che ti serve :D
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Ti risparmi un sacco di mal di testa. Perchè, siamo onesti, non sempre quello che si trova su internet è corretto e/o veritiero. Però è strano che gli esempi ufficiali ti diano problemi o addirittura non compilino. Del resto SDL non è una libreria amatoriale, ma è molto usato pure in ambito professionale.

Magari fosse solo Redhat. Pure il mondo BSD sta migrando a Wayland. Figurati che ho una macchina FreeBSD che gira su Wayland+Sway.

Che io sappia, il progetto Mir è stato ufficialmente abbandonato. Viene ancora sviluppato, in privato, da alcuni ingegneri di Canonical, con a capo Alan Griffiths. Di fatto è un compositor Wayland ormai. E il suo unico scopo è supportare UBPorts, il fork di Ubuntu Touch ( anch'esso abbandonato ). Considerando che Intel ha deciso, qualche anno fa, di rimuovere tutte le patch per il supporto a Mir nel suo driver grafico, direi che il progetto è defunto.

Il capo del progetto Sway ha fatto un favore gigantesco alla comunità. Da un lato Sway, il tiling manager clone di i3...e personalmente è il genere di window manager che preferisco. De gustibus. Dall'altro Wlroots, il compositor Wayland, che sta rendendo possibile la nascita di un bel numero di progetti che non siano Mutter o KWin.

Vabbè, però non siamo autorizzati ad usare software insicuro by design.

Anni fa. Del resto il punto di Wayland è che non si occupa di disegnare gli elementi grafici. Lo lascia fare ai client, come meglio credono. Richiede una frazione dello sforzo necessario per sviluppare e mantenere Xorg e si integra perfettamente nei meccanismi implementati in-kernel ( evdev, drm e kms ).

Cioè, i 10 anni sono stati usati in massima parte per smembrare Xorg, portare alcuni dei suoi meccanismi nel kernel, trasformare Xorg in un server root-less e tante altre cose. Il tutto senza che fosse necessario riscrivere i millemila programmi che girano sotto X.

Dieci anni per realizzare una transizione lenta ed indolore. Non dimentichamo che gli stessi ingegneri che sviluppavano Xorg hanno realizzato Wayland. C'hanno messo 10 anni, perchè volevano una transizione non dirompente ( tipo quella avvenuta con KDE 4 ).

Oddio, non che le due cose siano mutuamente esclusive. Cioè nessuno impedisce ad un tizio pazzo di creare da zero il suo compositor. E infatti esiste Arcan https://arcan-fe.com/about/

Per la cronaca, potrebbe essere quello che ti serve :D
Non ho mai parlato di internet, ma solo di esempi ufficiali. E non dobbiamo dimenticarci che sto sempre parlando di python, che non è nato per gestire la grafica.

Tornando a wayland, qui è vero che in giro si trovano bufale di ogni genere, e quelli che a tutti i costi spingono il nuovo linux game. A tutt'oggi, per uno uso serio di Linux o *BSD, Xorg è l'unica scelta. Io consiglerei senza nessun dubbio Xorg, che non è stato per niente abbandonato se non da Red Hat, invece di wayland. Tra vent'anni, quando sarà un po' più pronto per un uso serio, vedremo.

Mir è un progetto di Canonical per rimpiazzare Xorg. Dato che nessuno se lo filava, ne ha rallentato lo sviluppo. Oggi lo sta riproponendo come un complemento di wayland, per fornirgli un server. Alla fine mi viene solo il mal di testa da tutta questa confusione, sia da parte di Canonical che da parte dei sviluppatori di wayland che da tutti quelli che ci speculano sopra o lo spingono per passione. Canonical prima e Red Hat (ora di IBM) poi cercano da sempre di portare Linux verso le loro voglie, che sono soltanto di un tipo. E purtroppo quelle voglie li rendono ciechi della realtà, di quello che gli altri stanno facendo e la loro bramosia potrebbe anche portare alla scomparsa di Linux. Voglio aggiungere che Gnome in un certo senso è di Red Hat, quindi risulta semplice capire certe scelte fatte dai sviluppatori di Gnome.
Meglio rimanere con Xorg.
 

pabloski

Utente Èlite
2,707
782
A tutt'oggi, per uno uso serio di Linux o *BSD, Xorg è l'unica scelta.

BSD si. Ma Linux no. Wayland è stabile e perfettamente funzionante. Semmai qualche bug ce l'ha Mutter.

Io consiglerei senza nessun dubbio Xorg, che non è stato per niente abbandonato se non da Red Hat, invece di wayland. Tra vent'anni, quando sarà un po' più pronto per un uso serio, vedremo.

Wayland è pronto oggi. Considera che lo sto usando correntemente da mesi. E francamente non vedo problemi. I programmi che non hanno ancora il supporto a Wayland, girano grazie a XWayland.

Meglio rimanere con Xorg.

Difficile dato che è in hard maintanance mode, cioè correggono solo i bug. Ma lo sviluppo si è di fatto fermato.
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Termino il mio esperimento con python+opengl mentre stavo codificando i box (che non erano nel mio programma una entità differente in quando ogni widget possedeva una opzione su come comportarsi quando la finestra del programma cambiava di dimensione). Il motivo è che in certi punti del programma se indento ulteriormente con spazi o tab il programma non se ne accorge ma noto degli errori visivi. Pazienza, comunque ho ottenuto ciò che volevo anche se parzialmente. Dimenticavo, non ho usato thread.
 

pabloski

Utente Èlite
2,707
782
Il motivo è che in certi punti del programma se indento ulteriormente con spazi o tab il programma non se ne accorge ma noto degli errori visivi.

Nell'interfaccia o nel codice del programma? Se è il secondo, purtroppo Python è molto suscettibile in fatto di spazi e tab. E parecchi editori non fanno un buon lavoro in tal senso. Alla fin fine finisci col dover usare un'IDE per Python, tipo PyCharm.

p.s. oggi mi sono ricordato di un progetto che potrebbe interessarti, dato che è un'UI cross-platform from scratch https://github.com/vlang/ui

E' l'UI creata apposta per affiancare il linguaggio V. Quest'ultimo pure merita un'occhiatina https://vlang.io/
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Nell'interfaccia o nel codice del programma? Se è il secondo, purtroppo Python è molto suscettibile in fatto di spazi e tab. E parecchi editori non fanno un buon lavoro in tal senso. Alla fin fine finisci col dover usare un'IDE per Python, tipo PyCharm.

p.s. oggi mi sono ricordato di un progetto che potrebbe interessarti, dato che è un'UI cross-platform from scratch https://github.com/vlang/ui

E' l'UI creata apposta per affiancare il linguaggio V. Quest'ultimo pure merita un'occhiatina https://vlang.io/
Purtroppo nel codice. Se allo stesso punto scrivo una parola a c****, proprio quella, python riconosce l'errore.

Ma a questo punto perchè usare il linguaggio v e non il c (che non conosco, conosco solo python)?
Post automatically merged:

Python ha anche problemi con i... cicli. È molto difficile che si verifichino, ma non è da escludere a priori.
 
Ultima modifica:

pabloski

Utente Èlite
2,707
782
Ma a questo punto perchè usare il linguaggio v e non il c (che non conosco, conosco solo python)?

Non so se si hai esperienza di C. Ma il C è l'Assembly dei linguaggi moderni. Passare da C ad un linguaggio come V, Rust, Go, è come passare da Assembly a C++.

Poi, se guardi sul sito, spiega cos'ha V, quali caratteristiche prende dagli altri linguaggi e cosa offre in più. Ad esempio, in C puoi solo sognare di programmare in multithreading usando un paradigma come quello CSP ( implementato da Go e V ). E la differenza è mostruosa.
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Non so se si hai esperienza di C. Ma il C è l'Assembly dei linguaggi moderni. Passare da C ad un linguaggio come V, Rust, Go, è come passare da Assembly a C++.
Se non erro il C è stato per molto tempo l'alternativa facile all'Assembly. Poi è stato inventato il c++ e tutti sono impazziti per le classi. Io, e ripeto che non sono un programmatore e conosco solo python, odio le classi e se potessi eviterei tutti i linguaggi di programmazione che ne fanno uso, da c++ a java a python, praticamente tutti oggigiorno. Per me, andando a naso, il c è l'unico vero linguaggio di programmazione. E non è che significa usare un linguaggio limitato. Per esempio, Gnome viene programmato essenzialmente in c. Gnome 2 solo in c, e per anni è stato il miglior D.E. di Linux. E senza nessuna limitazione. La programmazione mi ha sempre affascinato, e solo recentemente ho deciso di provarci. Ho sempre sentito parlare bene di python e della sua facilità rispetto ad altri linguaggi, e per molti versi è vero, ed è per questo che lo scelsi tra i linguaggi che non necessitano di compilazione. Ora mi pare che anche i programmi in Java possono essere lanciati senza prima compilati.
 
Ultima modifica:

pabloski

Utente Èlite
2,707
782
Se non erro il C è stato per molto tempo l'alternativa facile all'Assembly.

Il C fu creato dagli ingegneri dei Bell Labs per soddisfare un'esigenza pratica, ovvero scrivere Unix in modo che fosse portabile su decine di architetture hardware, senza dover impazzire con l'Assembly.

In questo è riuscito alla perfezione. Ma considera che uno dei suoi creatori, Dennis Ritchie, disse: "C is crap"!

Per cui, gli autori erano ben consapevoli delle evidenti limitazioni del linguaggio, in particolare nel fornire un modello di programmazione lacunoso e una semantica ambigua ( ricordiamo che il C è pieno di undefined behaviours ).

Cioè si nota che è stato progettato e scritto da ingegneri e non da matematici. Ma è servito per quel che è servito. Addirittura s'è mangiato l'intero mondo informatico e ha condizionato pure i linguaggi a venire.

odio le classi e se potessi eviterei tutti i linguaggi di programmazione che ne fanno uso

Sei in buona compagnia, visto che tutti i linguaggi di nuova concezione non implementano il paradigma OOP o lo implementano in maniera molto differente.

Per esempio in Go non hai le classi. Ma funzioni associate a delle struct, sulle quali operano. Ottieni un risultato simile a quello dell'OOP, ma in maniera totalmente differente e con molti meno problemi.

E Rust stessa cosa.

Per esempio, Gnome viene programmato essenzialmente in c. Gnome 2 solo in c

Azz questa è un'altra delle costrizioni imposte da Redhat. Perchè gli ingegneri Redhat, sono in massima parte conoscitori del C. Ma obiettivamente, non è un'idea brillante scrivere pezzi di codice così importanti in C.

Ora mi pare che anche i programmi in Java possono essere lanciati senza prima compilati.

Java non è compilato, è jitted. Anche se, di recente, hanno introdotto un compilatore AOT.
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Per cui, gli autori erano ben consapevoli delle evidenti limitazioni del linguaggio, in particolare nel fornire un modello di programmazione lacunoso e una semantica ambigua ( ricordiamo che il C è pieno di undefined behaviours ).
Ho letto qualcosa sugli undefined behaviours che sembrano colpire sia il c che il c++ (che somma a quelli di c i propri). Mi sembra che ciò possano avvenire solo se il programmatore ritiene di non prestare attenzione in ogni passaggio del codice. Sono consapevole che in un listato di migliaia di righe gli errori sono sempre possibili. Ma a questo punto anche l'assembly soffre dello stesso problema. Mi chiedo, dato che gli errori sono sempre possibili, non spetta al compilatore segnalare dove si presenta l'errore? Ho fatto una prova, stesso codice in c e in python:
C
C:
int main()
{
    int x = 25, y = 0;
    int z = x / y;
    printf("Hello World!");
    return 0;
}
Python:
Python:
x = 25
y = 0
z = x/y
print("Hello World!")
Il programma in c stampa a terminale:
Eccezione in virgola mobile
Il programma in python stampa a terminale:
Traceback (most recent call last):
File "python3.py", line 4, in <module>
z = x/y
ZeroDivisionError: division by zero
 

pabloski

Utente Èlite
2,707
782
Ho letto qualcosa sugli undefined behaviours che sembrano colpire sia il c che il c++ (che somma a quelli di c i propri). Mi sembra che ciò possano avvenire solo se il programmatore ritiene di non prestare attenzione in ogni passaggio del codice.

No, il problema è la vaghezza del modello di programmazione del C. Per esempio, il fatto che il concetto di array ( e vale lo stesso per le stringhe ) sia vago, ovvero che abbia una sua sintassi nel linguaggio, ma che possa essere manipolato pure tramite aritmetica dei puntatori, conduce ai tipici buffer overflow.

Fare

C:
int a[4] = {1, 2, 3, 4};
int *ptr = a + 4;

printf("%d\n", *ptr);

in qualsiasi linguaggio con un modello di programmazione ben definito, non sarebbe ammesso. Invece in C puoi andare a pescare un valore che va oltre il limite dell'array e leggere ovviamente quello che c'è in quella locazione di memoria. Ovviamente nessuno può prevedere cosa ci sarà in quella locazione. Da cui il concetto di undefined behavior.

Stesso discorso quando si cerca di accedere alla locazione di memoria 0. Oppure, più banalmente, il fatto che non sia prescritto cosa fare in caso di divisione per zero ( a parte andare in segfault, ma questa è una decisione dei compilatori non dello standard C ).

Ma a questo punto anche l'assembly soffre dello stesso problema.

Hai voglia. Da cui la necessità di creare un'assembly portabile, ovvero il C.

Mi chiedo, dato che gli errori sono sempre possibili, non spetta al compilatore segnalare dove si presenta l'errore?

Certo. Ma il compilatore non è intelligente, non è un programmatore che va a leggere il codice. Se il modello di programmazione del linguaggio ( il modello teorico ) impone tali e tanti vincoli, da rendere impossibile specificare operazioni in maniera ambigua, allora il compilatore può essere realizzato in modo da stanare i bug. Ed è quello che è stato fatto col linguaggio Rust.

Ho fatto una prova, stesso codice in c e in python:
C
C:
int main()
{
    int x = 25, y = 0;
    int z = x / y;
    printf("Hello World!");
    return 0;
}
Python:
Python:
x = 25
y = 0
z = x/y
print("Hello World!")
Il programma in c stampa a terminale:
Eccezione in virgola mobile
Il programma in python stampa a terminale:
Traceback (most recent call last):
File "python3.py", line 4, in <module>
z = x/y
ZeroDivisionError: division by zero

Esattamente quello che dicevo sopra. Il compilatore deve inventarsi un modo per colmare la lacuna del modello teorico. Cioè nel modello del C non c'è scritto cosa fare in caso di divisione per zero. E ogni compilatore fa come gli pare. Ovviamente il programmatore si ritroverà a non sapere, in certe circostanze, con quale compilatore sarà compilato il suo programma e come verranno trattati quegli errori.

Tant'è che per programmi grandi, tipo il kernel Linux, i programmatori impongono l'uso di uno specifico compilatore. Almeno sanno a cosa vanno incontro.
 
  • Like
Reactions: fabio93

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
in qualsiasi linguaggio con un modello di programmazione ben definito, non sarebbe ammesso. Invece in C puoi andare a pescare un valore che va oltre il limite dell'array e leggere ovviamente quello che c'è in quella locazione di memoria. Ovviamente nessuno può prevedere cosa ci sarà in quella locazione. Da cui il concetto di undefined behavior.

Stesso discorso quando si cerca di accedere alla locazione di memoria 0. Oppure, più banalmente, il fatto che non sia prescritto cosa fare in caso di divisione per zero ( a parte andare in segfault, ma questa è una decisione dei compilatori non dello standard C ).
Ok, è tutto chiaro.
Però, negli anni in cui fu inventato il c, scrivere come in assembly ma molto più velocemente e con meno errori era da ritenersi quasi un miracolo. Quindi oggi, a causa della complessità dei programmi, meglio usare un linguaggio che eviti tutta una serie di errori causati da "undefined behavior" del programmatore :asd: .
Post automatically merged:

No, il problema è la vaghezza del modello di programmazione del C. Per esempio, il fatto che il concetto di array ( e vale lo stesso per le stringhe ) sia vago, ovvero che abbia una sua sintassi nel linguaggio, ma che possa essere manipolato pure tramite aritmetica dei puntatori, conduce ai tipici buffer overflow.
Da quel poco che ho letto sia l'array che il puntatore fanno riferimenti ad allocazioni di memoria. Dato che non conosco il c, penso che se esiste è per permettere di creare codice che il solo array, per esempio, non potrebbe essere scritto. Del resto, quando ho dato uno sguardo all'assembly, tutto fa riferimento a indirizzi di memoria. E l'assembly non è nemmeno il linguaggio ultimo, il linguaggio macchina.
 
Ultima modifica:

pabloski

Utente Èlite
2,707
782
Però, negli anni in cui fu inventato il c, scrivere come in assembly ma molto più velocemente e con meno errori era da ritenersi quasi un miracolo.

Si. Ma esistevano già altri linguaggi "migliori", tipo Ada. Il problema è che non consentivano di scrivere sistemi operativi.

Da quel poco che ho letto sia l'array che il puntatore fanno riferimenti ad allocazioni di memoria.

Ed è così ovunque...sotto il cofano. Ma un altro paio di maniche è dare al programmatore due chiavi di tipo differente, da usare con la stessa serratura. E' la semantica dei puntatori che non si presta a lavorare in sicurezza sugli array.

Dato che non conosco il c, penso che se esiste è per permettere di creare codice che il solo array, per esempio, non potrebbe essere scritto.

Certamente. Ma un linguaggio formalmente corretto, non ti dà due modi per fare la stessa cosa, dove ognuno supporta vincoli ed operazioni diverse.

Pure nell'ambito degli stessi puntatori, consentire ad un puntatore void di accedere i dati puntati da un puntatore int, è un disastro.

p++ significa una cosa se p = int*, ma significa un'altra cosa se p = void*

Del resto, quando ho dato uno sguardo all'assembly, tutto fa riferimento a indirizzi di memoria. E l'assembly non è nemmeno il linguaggio ultimo, il linguaggio macchina.

l'Assembly, a parte feature dei vari assemblatori, è la trasposizione mnemonica del linguaggio macchina
 

BrutPitt

Utente Attivo
443
408
Il C fu creato dagli ingegneri dei Bell Labs per soddisfare un'esigenza pratica, ovvero scrivere Unix in modo che fosse portabile su decine di architetture hardware, senza dover impazzire con l'Assembly.

In questo è riuscito alla perfezione. Ma considera che uno dei suoi creatori, Dennis Ritchie, disse: "C is crap"!
Pare (e dico pare) che questa sia una storica "fake news".
Nel senso che a domanda provocatoria diretta: "se il C fosse una schifezza" (o qualcosa del genere), Ritchie non si prese la briga di smentire, ma rispose con la famosa frase: “C is quirky, flawed, and an enormous success.”, che voleva esternare piu' un certo senso di ammirazione e stima per il prorpio "figlio".
Ovviamente fu una manna per i detrattori del C: in primis il fatto che non avesse smentito l'affermazione insita nella domanda... e poi quella frase: "Il C e' eccentrico, imperfetto e di enorme successo" ... si era facilmente trasformata in: "il C e' strambo, difettoso, e (nonostante questo) ha un enorme successo".
Da li', che Dennis Ritchie avesse affermato che il C era una schifezza, il passo fu breve.
E' giusto una curiosita che riporto come tale (un ricordo dell'epoca, fine anni 80... e gia' all'epoca si dibatteva su cio'), perche' ovviamente non e' dato sapere quale sia la realta'... e fa parte ormai della leggenda.


No, il problema è la vaghezza del modello di programmazione del C. Per esempio, il fatto che il concetto di array ( e vale lo stesso per le stringhe ) sia vago, ovvero che abbia una sua sintassi nel linguaggio, ma che possa essere manipolato pure tramite aritmetica dei puntatori, conduce ai tipici buffer overflow.

Fare

C:
int a[4] = {1, 2, 3, 4};
int *ptr = a + 4;

printf("%d\n", *ptr);

in qualsiasi linguaggio con un modello di programmazione ben definito, non sarebbe ammesso. Invece in C puoi andare a pescare un valore che va oltre il limite dell'array e leggere ovviamente quello che c'è in quella locazione di memoria. Ovviamente nessuno può prevedere cosa ci sarà in quella locazione. Da cui il concetto di undefined behavior.

Mi verrebbe da risponderti con un'altra citazione di Ritchie:
"Se fai il cast di un puntatore a un intero lui diventa un intero...
Se fai il cast di un puntatore a una struttura lui diventa una struttura...
... fai del puntatore un tuo amico"

E anche con una citazione da fumetto Marvell:
"Da un grande potere derivano grandi responsabilita'"

Ricordiamoci che il C nacque in un periodo in cui ogni singola istruzione era preziosa (i cicli di clock erano meno di 1000/s e una singola istruzione spesso comprendeva piu' cicli), epoca in cui si preferiva (era quasi obbligatorio) usare lo "<<1", o sommare due volte un float (i coporcessori matematici si acquistavano... a parte), piuttosto che moltiplicare per DUE... (una delle poche ottimizzazioni ottenibile dai compilatori era esplicitamente dichiarare una variabile con lo specificatore "register" nel codice)
In quest'epoca il C permetteva di incrementare direttamente l'indirizzo per scorrere un'area di memoria (stringhe, array, matrici..)... invece che
  • incrementare un indice
  • sommare l'indice all'indirizzo di memoria
per poi accedere a quell'indirizzo.
In quest'ottica, inserire un controllo sull'incremento di un indice, sarebbe costato ulteriormente sulle performance... oltre che rielaborare il concetto dei puntatori.
Si e' semplicemente scelto di offrire "potenza" a discapito della "sicurezza", lasciando la responsabilita' di questa potenza, nelle mani di chi la utilizzasse (da qui la citazione Marvell).
Non so se c'erano linguaggi migliori (bisognerebbe stabilire "migliore", in che ambito), c'erano sicuramente linguaggi piu' sicuri... ma molti preferirono che il loro programma fosse piu' veloce , e in ques'ottica scelsero il C.

Il C++ ha portato, parzialmente, un rimedio a certe mancanze... anche se in modo indiretto e solo in un secondo momento, attraverso la Standard Template Library: l'uso di contenitori "standard" permette la verifica del buffer overflow, anche se solo in modalita' DEBUG.
(ovviamente nulla, rispetto a linguaggi con un solido Garbage Collection e gestione delle eccezioni)

Certo, oggi il C, come il C++ (di cui si porta dietro l'eredita'), rimane "strambo" e "imperfetto"... e dato che la potenza di calcolo e' abbondante ed i compilatori ottimizzano il codice anche meglio di come lo si possa scrivere... ha un po' meno successo di allora, ma e' ancora molto seguito, nonostante abbia piu' di 40 anni.

Se non erro il C è stato per molto tempo l'alternativa facile all'Assembly. Poi è stato inventato il c++ e tutti sono impazziti per le classi. Io, e ripeto che non sono un programmatore e conosco solo python, odio le classi e se potessi eviterei tutti i linguaggi di programmazione che ne fanno uso, da c++ a java a python, praticamente tutti oggigiorno.

Personalmente, la "liberta'" che offre il C/C++ non riesco (non son riuscito) a sostituirla con altri linguaggi... e pensare che considero il C++ troppo puntiglioso (a volte) per alcuni versi.
Ricordo che resistetti alcuni anni, con tutto me stesso, non volendo ammettere che quella del C++ fosse un'evoluzione "indispensabile".
Alla fine cedetti.
I vantaggi sono innegabilmente maggiori degli svantaggi, per es. nella creazione di nuovi tipi di dati:
  • Immagina che in OpenGL volessi creare un nuovo tipo di dato Vettore3D,con 3 componenti (x,y,z), ma non sai se utilizzerai interi, singola o doppia precisione [er questi componenti... o forse tutti e tre i tipi, all'intero del tuo programma: puoi creare una classe, che in base alla dichiarazione del momento diventi specifica. (classe modello)
  • Ed ancora, poter usare gli stessi operatori (+,-,*,/) sul nuovo dato Vettore3D, senza doverti occupare dei singoli componenti interni: x,y,z. (overload operatori)
  • O gestire il vettore solo in un quadrante dello spazio cartesiano... non riscrivendo tutto... ma creando un nuovo tipo di dato Vettore3D_quadrante, "figlio" di Vettore3D (ereditarieta'), che limita la funzionalita' della classe "genitore" solo a quel quadrante... continuando ad aver disponibili ebtrambi gli oggetti per due usi diversi.

(E' solo un ipotetico esempio... fatto su due piedi)
Certo, tutto cio' si fa anche in C, attraverso altri metodi, ma la classe (l'oggetto) e' un'astrazione piu' vicina al nostro modo di gestire le informazioni, quindi diventa piu' gestibile e meglio leggibile (se scritta bene)... ergo meno soggetta ad errori... ed anche flessibile (facilmente riutilizzabile senza dover riscrivere pezzi di codice).

Inutile dire che ci son linguaggi che gestiscono gli oggetti con potenzialita' diverse rispetto al C++.
Migliori?
Molto probabilmente...
 
Ultima modifica:
  • Like
Reactions: clessidra e fabio93

Entra

oppure Accedi utilizzando

Hot: Quale crypto per il futuro?

  • Bitcoin

    Voti: 125 46.0%
  • Ethereum

    Voti: 110 40.4%
  • Cardano

    Voti: 40 14.7%
  • Polkadot

    Voti: 15 5.5%
  • Monero

    Voti: 17 6.3%
  • XRP

    Voti: 26 9.6%
  • Uniswap

    Voti: 7 2.6%
  • Litecoin

    Voti: 16 5.9%
  • Stellar

    Voti: 16 5.9%
  • Altro (Specifica)

    Voti: 41 15.1%