Newsgroup: it.lavoro.informatica
Titolo: Linguaggio Go

Cosa ne pensate del linguaggio Go?

Lo spacciano per linguaggio con curva di apprendimento poco ripida, per 

vostra esperienza è così? Secondo voi quanto ci vuole ad essere 

mediamente produttivi, partendo da un buon background C, Python, Java, 

Kotlin, un po' meno Scala?


 le differenze



chi avrebbe dovuto farlo?

è lo stesso discorso che sento fare su icoli, dove chiedono perché non 

hanno fatto un'unica distribuzione di linux, casualmente la propria 

adottata. la risposta è ovvia e sotto gli occhi di tutti: perché in questo 

mondo non c'è nessuna entità unica che decide, c'è molteplicità di 

esigenze e (vivaiddio) pluralismo di idee.

spiace che in questo pluralismo alcuni non ci si trovino a proprio agio, 

ma nessuno ti obbliga a imparare un nuovo linguaggio se non ne senti 

l'esigenza. 



però in una carriera lavorativa che dura decine di anni in questo ambiente 

turbolento ci si deve adattare a così tanti cambiamenti che è normale 

revisionare periodicamente le proprie competenze in rapporto con le nuove 

esigenze. se non si accetta questo vuol dire si è sbagliato mestiere ed 

era meglio andare a fare il contabile. 



pochi giorni, sul serio. go potrà apparire poco elegante ma su alcuni 

aspetti è di una semplicità sconcertante rispetto agli altri linguaggi, 

vedi ad esempio la programmazione concorrente.


 al parco, mica siamo tutti dei topi da pc o da biblioteca



beh magari tu usi il tuo tempo libero per formarti su strumenti di lavoro, 

non io. le conoscenze sui linguaggi le ho acquisite applicandoli sul 

campo. e se qualche volta ho fatto sacrificio, i.e. per preparare un esame 

di certificazione oppure arrivare pronto ad un colloquio, è stato per un 

periodo di tempo limitato, due settimane, un mese al massimo. 


 l'esigenza. 



Senza contare che proprio il fatto che siano linguaggi C-like elimina tantissima complessità e li rende da apprendere estremamente veloci, almeno fino a un livello 'sopravvivenza'.



-- 

Ciao!

Luca


 non mi hai detto se quel che auspico è tecnicamente fattibile.



ho pietà per il tuo essere cringe, ma non te ne approfittare. 


 intendo, non come librerie, in quel caso sarebbe ovvio



https://gprivate.com/62otr



 mondo si parli una sola lingua, l'inglese per esempio



L'esperimento produsse l'Esperanto....vuoi mettere?!?!



-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.



“Alles hat ein Ende, nur die Wurst hat zwei”




 prima in basso sotto la folle e tutte le altre marce sopra?



E' vero anche il contrario....



 TV.



mi sa che con questo ragionamento sei andato in testacoda. è ovvio che un 

sistema di trasmissione televisivo necessiti di uno standard, ma 

esattamente come era standard il sistema pal lo sono anche il dvb-t, dvb-

t2, mpeg-2 e mpeg-4. questo dimostra che standardizzare non rende 

necessariamente una soluzione più stabile e/o duratura. 

detto questo, non vedo il nesso con la faccenda in questione. 


 era meglio andare a fare il contabile.



Contabili cui oggigiorno è spesso richiesto di avere qualche infarinatura anche 

di programmazione (o almeno conoscenza SQL) :-)





-- 

Questa email è stata esaminata alla ricerca di virus dal software antivirus Avast.

www.avast.com



 infarinatura anche di programmazione (o almeno conoscenza SQL) :-)



però se è fortunato se la cava con excel 97 :-)


 java e c++




quoto totalmente



fosse nato qualche anno prima oggi forse sarei uno sviluppatore Go 

invece che Java



se avessi la palla di cristallo e la certezza di non finire sotto a un 

ponte, salterei immediamente a lavorare per un'azienda che adotta Go, 

anche a costo di ripartire dal basso, ma non me lo posso permettere, né 

in termini di soldi né di etá


   



Nota, da c++23 sara deprecato il supporto



https://en.cppreference.com/w/cpp/memory
  (sez. GC)



E nota:

char* (in generale i pointers) non sono per compatibilita verso il basso

Il design del linguaggio, che piaccia o meno, e' quello di fornire 

costrutti di base su cui costruire

Ed in questo caso i pointers (come i tipi integral) sono indispensabili









-- 

|___|




 devi avere a che fare con codice poco recente



che diamine c'entrano i container con il bisogno o meno di utilizzare i 

puntatori?


 sai cos'è un container?



chiedo scusa, intendo una cosa diversa. 

per me il container è questo:

https://www.docker.com/resources/what-container/


in tutti i linguaggi che conosco vector, array, map, etc... sono 

comunemente detti collection.


 fare con codice poco recente



Vero, ma faccio un appunto tanto per non fraintendere

Un vector od una list,ad esempio, non sono  builtin

ma sono costruiti usando i tipi base

Senza i pointers sarebbe impossibile utilizzando il linguaggio stesso

Poi e' ovvio che per l'utilizzatore e' meglio usare vector che l'array 

builtin ma e' un altro discorso

In altri linguaggi un vector c++ e' builtin oppure (come in java) e' 

costruito nella lib std ma non e' costruito usando codice del linguaggio 

  (sarebbe impossibile)

Infatti e' costruito in C o C++

Per design invece C++ usa gli oggetti di base come quelli del C per cui 

i puntatori sono indispensabili





-- 

|___|




 Infatti e' costruito in C o C++



no.



https://github.com/openjdk/jdk17u-dev/tree/master/src/java.base/share/


classes/java/util




 Ed in questo caso i pointers (come i tipi integral) sono indispensabili



Aggiungo poi chi ha detto che la stl sia sempre diponibile

(o desiderabile)?



Si puo' volere usare il C++ per alcune funzionalita' del

linguaggio, in piu' rispetto al C, anche in ambienti senza stl.




 non so perchè lo chiami builtin visto che è della stdlib



Array buildin suppongo tipo



    char a[4];



compri'?







Grazie a chi ha risposto.



Nei giorni scorsi per esercizio mi sono dilettato a scrivere un semplice 

sistema di monitoraggio casalingo, banale, un exporter che espone delle 

metriche (i dati di consumo elettrico da uno Shelly EM) a un 

Prometheus/Grafana. Pur partendo praticamente da zero ci ho messo una 

sciocchezza.



Confermo che è un linguaggio veramente semplice da acquisire.


Il 05/01/23 10:50, rootkit ha scritto:


Ma figurati

Prendi ad esempio Vector



nel costruttore fa questo



  this.elementData = new Object[initialCapacity];



usa l'array builtin

senza di esso non sarebbe possibili costruire un vector



e l'array builtin e' codice C



Per le liste usa



  final Node<E> newNode = new Node<>(null, e, f);



usa new

che e' qualcosa di simile  a std::shared_ptr<T>

in pratica un pointer





-- 

|___|




 assurdo





Quella sui moduli c'e voluto un po

Si vede che usare un nuovo paradigma (nuovo per la filosofia del 

linguaggio) ci vuole tempo

Ma C++ non e' perfetto,e' un linguaggio che si e' evoluto nel tempo



-- 

|___|




 così



Non ho mai affermato il contrario



-- 

|___|




 e l'array builtin e' codice C



le istruzioni builtin vengono compilate prima in istruzioni bytecode e 

successivamente in linguaggio macchina dal compilatore jit. in quale 

momento di preciso vedresti il codice c?


Il 09/01/23 01:23, rootkit ha scritto:


IL runtime non e' scritto in C?



-- 

|___|





cosa c'entra il runtime, stiamo parlando di compilazione.

ripeto la domanda, dove vedi l'implementazione c di quel codice.


 ok, non hai niente da dire



ah, su questo non ti si può certo dare torto.


Il 09/01/23 13:55, rootkit ha scritto:


Il compilatore java e' un compilatore in un linguaggio macchina virtuale

Questo comporta che le funzioni vicino all'hw possono essere demandate 

al linguaggio macchina virtuale e come ricaduta al runtime quando quell' 

linguaggio macchina sara eseguito

Anche il buon vecchio C, pur essendo il compilatore generatore di codice 

nativo,ha bisogno dell' assembler

Pensiamo alle svc ad esempio

Alla fin fine,chi piu chi meno, non se puo fare a meno (dell' assembler)





-- 

|___|




 fare a meno (dell' assembler)



insomma un panegirico per non rispondere alla domanda. come tutti sanno le 

parti di java implementate esternamente sono metodi marcati "native", che 

infatti fanno riferimento a librerie native dinamiche che a loro volta 

avranno i loro sorgenti c, c++, assembly, rust (*) o quello che ti pare. 

le istruzioni builtin sono direttamente tradotte dal compilatore e non 

hanno sorgenti in altro linguaggio.





(*) sì anche rust: 
https://docs.rs/jni/latest/jni/



Il 12/01/23 01:04, rootkit ha scritto:


Ok, mi fa piacere che anche Rust supporta la jni

E per quando riguarda java almeno vector e list non hanno bisogno di essa

Ma altri si, ad esempio la open()



   private native void open0(String name) throws FileNotFoundException;



che viene chiamata da un file per la open() pubblica







-- 

|___|




    private native void open0(String name) throws FileNotFoundException;

             ^^^^^^



se tu leggessi quello che scrivono gli interlocutori le discussioni 

sarebbero più sensate.




Il 16/01/23 10:53, rootkit ha scritto:


premesso che quella definizione l'ho presa da 

https://github.com/openjdk/jdk17u-dev/blob/master/src/java.base/share/classes/java/io/FileInputStream.java


riga 215

non capisco la tua battuta sicuramente umoristica



-- 

|___|




 riga 215 non capisco la tua battuta sicuramente umoristica



la "battuta" vuole semplicemente dire che se tu leggessi i messaggi a cui 

rispondi ti accorgeresti che ho già scritto io quali sono in java i metodi 

implementati esternamente. quindi confuti la mia affermazione con un 

esempio che la conferma. non è che così ne venga fuori una discussione 

molto brillante. 


Il 18/01/23 10:14, rootkit ha scritto:


Va bene,se lo dici tu



-- 

|___|




 Cosa ne pensate del linguaggio Go?



ricevuto da linkedin ieri: Staff Engineer, Londra (remoto) Monzo Bank (é 

seria, non é la solita criptominchia) Mid-Senior level sviluppatore Go 

£140,000 - £180,000 plus stock options and other benefits



sinceramente Mid-Senior stipendi cosí alti non li ho mai visti.. sará 

che sono un po' fuori dal giro




 £140,000 - £180,000 plus stock options and other benefits 



O e` Staff Engineer, o e` Mid-Senior Level. Non puo` essere lo stesso salario per tutti e due i ruoli. 

E quel salario e` sicuramente per Staff Engineer. Di certo non per mid-senior. Se e` per SE, e` assolutamente entro gli standard londinesi del 2022-23. 

Non molto distante peraltro dal mio, che lavoro da anni da remoto, e molto lontano da Londra. 

Ormai, in UK, si arriva a sfondare facilmente i £110-120K se si hanno le giuste capacita`.


 Cosa ne pensate del linguaggio Go? 



Personalmente, lo detesto. Da me si usa Python, Go, Kotlin, Java e C#. Di sicuro le review di codice Go sono le piu` fastidiose. 

Python e Kotlin, a mio parere, lo battono a mani basse. In un precedente posto di lavoro, un intero team e` tornato indietro, addirittura da Go a Java. Brutta esperienza, ma non ho molti dettagli a riguardo.



sarebbe interessante invece capire dov'è che hanno battuto il muso. su 

servizi containerizzati ad esempio lo vedo quantomeno competitivo; per 

dire rispetto a java/kotlin + vertx perde per il throughput (richieste al 

secondo) ma vince a mani basse per la latenza, questo vuol dire che in un 

ambiente facilmente scalabile come k8s si raggiungono di norma risultati 

migliori con go che con vertx (e vertx è decisamente il più performante 

fra i framework della jvm).




 performante fra i framework della jvm).



per concludere il discorso che mi è rimasto in canna: python è un 

linguaggio molto versatile e la sua dinamicità lo rende imbattibile in 

tutti gli ambiti di scripting (io lo uso molto per scrivere moduli di 

ansible, ad esempio) ma è inusabile dove si richiedono un minimo di 

performance. 



sulla "bellezza" e leggibilità di go se ne può discutere, non è ad oggetti 

e non è certo il più puro nell'implementare un paradigma, però una volta 

entrati nella sua logica (e non è impegnativo arrivarci) non è a mio 

avviso difficile da leggere. premesso che da noi non lo usano (ma lo 

stiamo valutando) a me capita sovente di andare a spulciare il codice di 

progetti open source anche complessi, come i network plugin di kubernetes, 

e riesco anche a contribuire con il debug. con java, che per la cronaca 

conosco da una vita, per via della cronica abitudine a sovraingegnerizzare 

spacciandola per eleganza, ci rinuncio proprio.


sarebbe interessante invece capire dov'è che hanno battuto il muso.



Eh, lo so, ma non ricordo i dettagli. Quando ho iniziato a lavorare per quell'azienda, il team stava gia` completando la transizione da Go a Java, c'era gia` una storia molto lunga alle spalle. Mi avevano accennato qualcosa una sera a cena, ma non ricordo. Comunque era per il servizio FaaS di una piattaforma di cloud computing, quindi in un contesto in cui le performance contano parecchio.



Il linguaggio in se` a me fa letteralmente cagare. Stiamo valutando di sbatterlo fuori, perche` tra Python e Kotlin, riusciamo a fare tutto cio` che serve, ma purtroppo c'e` uno zoccolo duro che resiste. Fare review di quel codice mi fa venire i conati di vomito. Codice buono, eh? Ma e` il linguaggio che mi disgusta (e lo dico da C-ista).



Python per me e` usabilissimo anche in contesti diversi dallo scripting. Hai ragione sulle performance, ma io ho lavorato per quasi due anni come Pythonista per un'azienda di assicurazioni, con microservizi e AWS lambda. Per noi andava benissimo.


 > char* (in generale i pointers) non sono per compatibilita verso il basso 



Invece si`. Non sono li` per questioni di design del linguaggio: 
https://www.stroustrup.com/bs_faq2.html#pointers-and-references




"C++ inherited pointers from C, so I couldn't remove them without causing serious compatibility problems".


 nativo,ha bisogno dell' assembler 



Non e` affatto vero. Cosa vieta di avere un compilatore che generi direttamente opcode nativi? Spiega.


 O e` Staff Engineer, o e` Mid-Senior Level.



io ho riportato quello che scrivono, poi non ho verificato di persona, 

le mie conoscenze di Go sono ridicole


 Non e` affatto vero. Cosa vieta di avere un compilatore che generi direttamente opcode nativi? Spiega.



le svc



-- 

|___|




 "C++ inherited pointers from C, so I couldn't remove them without causing serious compatibility problems".





ti sei risposto da solo



-- 

|___|




 io ho riportato quello che scrivono



Non e` sicuramente quello che hanno scritto. Ripeto che 140K-180K non puo` essere il salario per un mid-senior, neanche a Londra. E` sicuramente un salario per SE. 

Go non c'entra.


 le svc 



Uh? :D LOL... 


 ti sei risposto da solo 



Non ho fatto nessuna domanda, per cui non aspettavo nessuna risposta. Era un'affermazione e tu sei confuso:



"i pointers non sono per compatibilita verso il basso" (enoquick)

"I couldn't remove them without causing serious compatibility problems" (Stroustrup)



Sei nel torto.


 Go non c'entra.



https://www.linkedin.com/jobs/view/3443551606



 
https://www.linkedin.com/jobs/view/3443551606




Ecco, appunto.


 Ecco, appunto.



?



in effetti è diretta a staff engineer.


 ?



Che c'e`? Vuoi che te lo rispiego?



con enoquick non penserai mica di cavartela così a buon mercato? non basta 

mica l'evidenza, negarla senza pudore è il suo sport preferito.


 Che c'e`? Vuoi che te lo rispiego?



c'é scritto tutto quello che ho riportato



io ti do ragione che dietro le quinte le cose son diverse, ma piú di 

dire "quello é ció che hanno scritto su LinkedIn" non posso aggiungere, 

non vado a verificare e non ho maggiori informazioni in dettaglio



a meno che LinkenIn ti faccia vedere cose diverse da quelle che fa 

vedere a me..


Il 27/01/23 12:07, Una mamma ha scritto:


i pointers fanno parte del design di c++ quindi e' inutile che rigiri la 

frittata a tuo uso e consumo

E Stroustrup lo conferma



-- 

|___|




Il 29/01/23 03:17, rootkit ha scritto:


io non nego niente,se travisate i miei scritti non e' colpa mia



-- 

|___|




 Uh? :D LOL...





gli svc (o syscall) non sono supportati da c e c++  quindi occorre usare 

l'assembler

sia che si faccia generare al compilatore o fare routine esterne sempre 

l'assembler occorre

Fatto parte che includere la generazione delle syscall al compilatore e' 

una pessima idea (e non ci vuole molto ad immaginare il perche)







-- 

|___|




 c'é scritto tutto quello che ho riportato 



Si`, ma il punto e` che hai capito cazzi per mazzi. 



Hai scritto: "sinceramente Mid-Senior stipendi cosí alti non li ho mai visti."



Quello e` un annuncio *per Staff Engineer*, e "mid-senior" e` nell'ambito di SE. 



Uno SE e` un ruolo molto alto, dal punto di vista tecnico, nelle tipiche gerarchie anglosassoni che vedono ruoli come Principal Engineer, Head of Engineering, etc...



Quale "dietro le quinte le cose son diverse"? 



E` come se io leggessi "cercasi incursore biondo, $1mln l'anno" e pensassi "cazzo, uno stipendio di $1mln l'anno per un biondo non l'ho mai visto". 


 i pointers fanno parte del design di c++ quindi e' inutile che rigiri la 



Ma neanche per sogno. Stroustrup afferma chiaramente che l'unico motivo per cui esistono in C++ e` perche` ereditati dal C e rimasti per compatibilita`. Lui li avrebbe rimossi volentieri e lo dice pure. 


 io non nego niente



E` quello che hai fatto e ora, ovviamente, ora lo stai negando. Perche` per te e` piu` facile fare la figura del fesso che dire "scusate, ho detto una cazzata".


 l'assembler 



Ma che cazzo stai dicendo! Non sai di cosa stai parlando!! Tu sei veramente tanto tanto (ma tanto) confuso!!


 E` quello che hai fatto e ora, ovviamente, ora lo stai negando. Perche` per te e` piu` facile fare la figura del fesso che dire "scusate, ho detto una cazzata".



ma va ..





-- 

|___|




 Ma neanche per sogno. Stroustrup afferma chiaramente che l'unico motivo per cui esistono in C++ e` perche` ereditati dal C e rimasti per compatibilita`. Lui li avrebbe rimossi volentieri e lo dice pure.



ma che ti piaccia o no fanno parte del design

se non gli piacevano poteva anche non metterli ma non e' stato cosi

scelta sua

Con i se non si fanno i fatti

Che piaccia o no o che si sia pentito dopo non cambia la situazione





-- 

|___|




Il 29/01/23 12:17, Una mamma ha scritto:


ma davvero ?

allora dimmi un compilatore c che genera lui stesso le svc (basta uno)

Ma anche se lo trovassi non significa che sia la regola

gcc visto che e' open si puo affermare con certezza che non genera le 

svc (vengono demandate alla glibc tramite una routine con assembler 

inline tramite una roba di questo genere:



ENTRY (syscall)

	movq %rdi, %rax		/* Syscall number -> rax.  */

	movq %rsi, %rdi		/* shift arg1 - arg5.  */

	movq %rdx, %rsi

	movq %rcx, %rdx

	movq %r8, %r10

	movq %r9, %r8

	movq 8(%rsp),%r9	/* arg6 is on the stack.  */

	syscall			/* Do the system call.  */

	cmpq $-4095, %rax	/* Check %rax for error.  */

	jae SYSCALL_ERROR_LABEL	/* Jump to error handler if error.  */

	ret			





  )



Poi dimmi dove sta nello std C/C++ la chiamata ad una svc

visto che sono confuso







-- 

|___|




 ma che ti piaccia o no fanno parte del design 



NONEEEEEEEE... non e `cosi`. I puntatori non sono parte del design del C++. Sono stati EREDITATI dal C e sono li` solo per COMPATIBILITA` con il C. Stroustrup lo ha detto bene e tu sei nel torto. Trallallero. Trallalla`.


 ma va .. 



... a cagare, vai vai.


 Ma anche se lo trovassi non significa che sia la regola 



ROTFL :D Hai paura di essere smerdato, eh? :) 



Ma figurati se mi metto a farti le ricerchine. Io ti rispondo sul principio: la presenza di un assembler NON e` un requisito. Punto. Come sempre, sei confuso.


 Quello e` un annuncio*per Staff Engineer*, e "mid-senior" e` nell'ambito di SE.



adesso ho fatto 1+1, grazie



sinceramente, stando fuori dal mercato, non ho mai visto un annuncio per 

staff engineer, e senza googolarlo non saprei manco cosa sia


 NONEEEEEEEE... non e `cosi`. I puntatori non sono parte del design del C++. Sono stati EREDITATI dal C e sono li` solo per COMPATIBILITA` con il C. Stroustrup lo ha detto bene e tu sei nel torto. Trallallero. Trallalla`.





Ma per favore, C++ e' nato per avere compatibilita con il C aggiungendo 

la OOP (all' inizio si chiamava C with Classes ma guarda un po)

Quindi fa parte del design

Essere compatibile (non all 100% ma quasi) con il C fa parte del design



Metti che voglio fare un java++, affermo che i pointers sono cattivi e 

non vorrei metterli ma li devo mettere per compatibilita con il java 

esistente

Che piaccia o no in questo nuovo linguaggio java++ i pointers fanno 

parte del design





-- 

|___|




 ... a cagare, vai vai.



dopo di te



-- 

|___|




Il 30/01/23 08:09, Una mamma ha scritto:


La presenza di un assembler e' un requisito

Lo std offre pure il tag asm (opzionale) per l'assembler inline, o 

adesso neanche lo std ti piace pur di non contraddirti ?

Ma visto che il linguaggio non ha le svc in qualche modo vanno implementate

O il compilatore le genera (ma in pratica nessuno lo fa) o vengono 

costruite in asm

Non si scappa





-- 

|___|




 ma qui lascio la parola a voi



in java tutte le variabili di tipi non primitivi sono reference, che non 

sono puntatori e nemmeno gli assomigliano allorché non ti danno nessun 

tipo di accesso alla memoria dove è allocato l'oggetto referenziato. anche 

perché l'oggetto referenziato in memoria può essere spostato in qualsiasi 

momento (e viene spostato più volte nel suo ciclo di vita).


 che non sono puntatori e nemmeno gli assomigliano" non mi ci fa trovare



sto parlando delle reference di java.

alle reference di java si applica l'aritmetica dei puntatori? no.

le reference di java possono puntare a posizioni di memoria arbitrarie? 

no.

se non ti ci ritrovi amen.




 Ma per favore, C++ e' nato per avere compatibilita con il C 



LOL :D :D :D



"in generale i pointers) non sono per compatibilita verso il basso" (enoquick)



I puntatori, in C++, esistono per compatiblita` verso il basso, come ti e` stato spiegato piu` volte, NON per questioni di design del linguaggio. 



In sostanza, Stroustrup i puntatori non li voleva. E` stato obbligato a supportarli senno` i fessi come te avrebbero cominciato a battere i pugnetti sul tavolo.


 La presenza di un assembler e' un requisito 



Nope. Niente affatto. Ti sbagli.


 Nope. Niente affatto. Ti sbagli.





E' un  requisito opzionale:





https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf






questo e' lo std del c99:



J.5.10 The asm keyword

1 The asm keyword may be used to insert assembly language directly into 

the translator

output (6.8). The most common implementation is via a statement of the form:

asm ( character-string-literal );









-- 

|___|





mi è arrivata oggi una offerta per senior devops eng da 170k chf a basilea 

(on site, no remoto) ambito finance.

peccato che fra i desiderata c'è "german understanding at any level" sennò 

ci facevo un pensierino, almeno provarci. la job description calza quasi a 

pennello.




 ma qui lascio la parola a voi



ma guarda un po, ma certo che ha i pointers

Controllati, ma sempre pointers sono,almeno da come li vede il programmatore

Internamente saranno degli handler ma dal punto del programmatore non 

cambia





-- 

|___|




Il 31/01/23 05:11, Una mamma ha scritto:


Ma guarda un po, e allora perche lo aveva chiamato C with classes ?

Se voleva fare un linguaggio nuovo rompendo il C lo avrebbe chiamato con 

un altro nome.

Poi dare dei fessi a chi secondo te usa i puntatori non ha alcun senso

E te lo rispiego

Se volessi fare un java++ mantenendo la compatibilita con il classico 

java poi non mi vengo a lamentare che alcune future presenti nel java 

classico non fanno parte del design perche non mi piacciono

Che piacciano o no fanno parte del design altrimenti non  le metto e non 

lo chiamo java++





-- 

|___|




 saranno degli handler ma dal punto del programmatore non cambia



ma certo, proprio dal punto di vista del programmatore non cambia nulla.



infatti è noto che il programmatore può fare con le reference di java 

quello che si fa comunemente con i puntatori: può usare l'aritmetica dei 

puntatori ad esempio per scorrere gli array; può castare qualsiasi 

reference a qualsiasi tipo; può copiare pezzi di memoria in posizioni 

arbitrarie; può assegnare ad una reference un valore arbitrario, i.e. 

l'address dell'n-esimo elemento di un array.




Il 31/01/23 16:05, rootkit ha scritto:


Puntatore: un oggetto che contiene un riferimento diretto od indiretto 

ad un altro oggetto (di solito contiene un indirizzo)



Chi ha mai detto che un puntatore deve per forza avere l'aritmetica ?



char x[]="abc";



char*const p=x;



++p; //errore - p e' un puntatore costante



*p='b'; //ok



In C l'aritmetica dei puntatori e' solo usata per gli array ed usarla 

fuori da questo contesto con relativo accesso e' un UB



int x=4;

int* p=&x;

++p;

*p=6; //UB

int y=*p; //UB



Questo per dire che non e' obbligatorio che un linguaggio se implementa 

i puntatori deve fornirne anche l'aritmetica



Per esempio PERL ha i puntatori ma non l'aritmetica su di essi (vengono 

chiamati riferimenti nella terminologia PERL ma in sostanza sono puntatori)































-- 

|___|




 non li usi



sempre la mia regola aurea: un periodo che comincia con "basta fare" o 

"basta che" prelude quasi sempre ad una stronzata.





Secondo me vale molto di più al tempo passato: "bastava che"

è indice di puntini, puntini. Nel caso specifico, "bastava fare"

va anche oltre.

Tutto sommato al tempo presente potrebbe anche andare, purchè

non sia la solita scusa per mascherare la propria ignoranza

o scaricare le proprie responsabilità su altri.








 E' un requisito opzionale: 



Ah ah ah ah ah ah... o e` un requisito, o e ` opzionale. Tu parlavi di assembler, non di uso della keyword "asm". Sei il solito cialtrone :D




 mi è arrivata oggi una offerta per senior devops eng da 170k chf a basilea 



Immagino tu conosca bene l'inglese. Nel caso, puoi trovare lavori simili a quello anche in Inghilterra e, rebus sic stantibus, un bel 100% remoto dall'Italia.


 ma guarda un po, ma certo che ha i pointers 



Ma smettila di scrivere stupidaggini!!!


 un altro nome. 



Infatti lo ha chiamato C++. Ma tu ci tieni cosi` tanto a fare la figura del fesso, sparandoti nei piedi ad ogni post che scrivi? 

Poi che cazzo c'entra il nome? 

Stroustrup ha detto precisamente che i puntatori in C++ esistono per compatibilita` con il C e che non avrebbe potuto rimuoverli senza causare problemi di compatibilita`. 

Tu, invece, asserivi che la compatibilita` non c'entra. 

Mettici una pietra sopra: sei confuso. 


 In C l'aritmetica dei puntatori e' solo usata per gli array 



No. In C, l'aritmetica dei puntatori e` usata per i puntatori, non per gli array. Array e puntatori, in C, sono cose DIVERSE. E` solo che i nomi degli array spesso *decadono* in puntatori al loro primo elemento (ad eccezione di tre casi che tu sicuramente conoscerai... LOL :D — guardatelo come corre a cercare :D)


 non li usi



Usarli non e' certo un obbligo anche se in C non usarli la vedo dura





-- 

|___|




 No. In C, l'aritmetica dei puntatori e` usata per i puntatori, non per gli array. Array e puntatori, in C, sono cose DIVERSE. E` solo che i nomi degli array spesso *decadono* in puntatori al loro primo elemento (ad eccezione di tre casi che tu sicuramente conoscerai... LOL :D — guardatelo come corre a cercare :D)





E' inutile che giri le parole a tuo uso e consumo

Quando ho affermato che i puntatori vengono usati solo per gli array e' 

vero

Ora arrivi a spaccare il capello in due facendo intendere che non sappia 

la differenza tra puntatore ed array



Ma per favore







-- 

|___|




 Mettici una pietra sopra: sei confuso.



A me risulta che abbia solo affermato che fanno parte del design







-- 

|___|




Il 01/02/23 10:29, Una mamma ha scritto:


Si,si

intanto vai a mangiare m... va che visto che spari solo cazzate

La keyword asm implica che il C ha bisogno dell'assembler

Quello delle svc era solo un esempio



-- 

|___|




 Non ha senso 



Non ha senso quel che scrivi tu. A parte il fatto che quando un puntatore punta ad un array, e` un puntatore ad array, e l'incremento e` tanto quanto la dimensione dell'array; l'aritmetica dei puntatori prescinde totalmente dalla presenza o meno di un array. L'aritmetica dei puntatori prescrive soltanto che, dato T* p, p + x significa puntatore alla posizione di memoria che dall'indirizzo di p avanza di x * sizeof(T). Punto.


 la differenza tra puntatore ed array 



Se affermi quanto sopra, non la sai.


 A me risulta che abbia solo affermato che fanno parte del design 



A te risultano cose non vere e ti e` stato riportato esattamente cosa ha detto Stroustrup.


 La keyword asm implica che il C ha bisogno dell'assembler 



No, fesso. Semplicemente e` un ausilio che viene dato a chi voglia iniettare codice asm direttamente nel sorgente. Non c'entra assolutamente un cazzo di niente con la presenza o meno di un assembler. Guarda che la keyword asm esisteva gia` in Turbo Pascal e Turbo C un miliardo di anni fa, ed io stesso ne ho fatto abbondante uso. 



Vatti a nascondere, che e` meglio.


 vero 



Mica tanto...


 responsabilità su altri.



spesso chi usa questa espressione è per parlare di una situazione 

complessa ignorandone la complessità. infatti poi segue baggianata che nel 

merito della questione non sta ne in cielo ne in terra.




 Vatti a nascondere, che e` meglio.



e' un una keyword (opzionale) riconosciuta dallo std

Non e' una estensione proprietaria del C



-- 

|___|




 Non ha senso quel che scrivi tu. A parte il fatto che quando un puntatore punta ad un array, e` un puntatore ad array, e l'incremento e` tanto quanto la dimensione dell'array; l'aritmetica dei puntatori prescinde totalmente dalla presenza o meno di un array. L'aritmetica dei puntatori prescrive soltanto che, dato T* p, p + x significa puntatore alla posizione di memoria che dall'indirizzo di p avanza di x * sizeof(T). Punto.



In C e' cosi

Poi accedi  p + x senza che p punti ad un array o x > sz dell'array hai 

un UB

Per questo non ha senso, io ho scritto cosi

Non ho scritto che non  si puo fare





-- 

|___|




 Se affermi quanto sopra, non la sai.



Non girare la frittata,puntatori con offset,era inteso questo (era nel 

contesto della tua affermazione)

PS: progetto sw in C e C++ da decenni e non so una cosa basilare del C 

come i puntatori

Non fare ridere i polli

Denigrare son capaci tutti







-- 

|___|




 Mica tanto...



Era nel contesto della affermazione della babysitter



E ovvio che un pointer lo si puo usare anche con un non array (tipi 

semplici,funzioni e strutture)

Vai a rileggerti i suoi post, non venire da me







-- 

|___|




 Non e' una estensione proprietaria del C 



E 'sti cazzi non ce lo aggiungi? Non c'entra assolutamente niente con la presenza o meno di un assembler o con il requisito o meno di un assembler. 

Sei confuso.


 Non ho scritto che non si puo fare 



Hai scritto, come sempre, scemenze, e continui, come al solito, ad arrampicarti sugli specchi.


 come i puntatori 



Non lo sai e lo hai dimostrato.


 Vai a rileggerti i suoi post, non venire da me 



Perche` non ci dai un taglio e la finisci di fare la figura da fesso? 

Sei confuso sull'argomento e ti sei incartato. Punto.


 A te risultano cose non vere e ti e` stato riportato esattamente cosa ha detto Stroustrup.





Si,si

Almeno informati prima di sparare cazzate

E per tua norma quello che S. aveva affermato sui puntatori del C 

occorreva prenderlo nel contesto del discorso

Un po come tutte le frasi





According to Stroustrup, "the name signifies the evolutionary nature of 

the changes from C".[31] This name is credited to Rick Mascitti 

(mid-1983)[22] and was first used in December 1983. When Mascitti was 

questioned informally in 1992 about the naming, he indicated that it was 

given in a tongue-in-cheek spirit. The name comes from C's ++ operator 

(which increments the value of a variable) and a common naming 

convention of using "+" to indicate an enhanced computer program.





Nel 1979, Bjarne Stroustrup, a Danish computer scientist, began work on 

"C with Classes", the predecessor to C++.[20] Th



https://en.wikipedia.org/wiki/C%2B%2B






il C with classes era nato nel 1979 (era un compilatore che produceva 

codice C)

Il nome C++ fu una idea di Rick Mascitti nel 1983

Quindi smettila di sparare cazzate





-- 

|___|




Il 02/02/23 19:08, Una mamma ha scritto:


Se serve (la keyword asm) per scrivere in assembler vuol dire dipendere 

dall'assembler

Tra l'altro i compilatori C di solito non producono linguaggio macchina 

direttamente

Producono assembler e chiamano un assemblatore (gcc fa cosi e anche altri)

Le svc non si possono codificare in C, quindi o le si fa produrre al 

compilatore (pessima idea) o si scrivono in asm

La gestione degli interrupt in un kernel idem (il C non conosce il 

concetto di interrupt,ad esempio per abilitarli/disabilitarli occorre 

l'assembler)

Alcune routine vengono scritte in assembler direttamente per questioni 

di performance pur avendo una interfaccia C

Se questo non e' dipendere dall'assembler non so cosa dire





-- 

|___|




 Hai scritto, come sempre, scemenze, e continui, come al solito, ad arrampicarti sugli specchi.





E si,enoquick e' quello che scrive sempre scemenze

La solita storiella per chi non ha niente da controbattere

Buona Vita, va ad accudire i pargoli











-- 

|___|




 Non lo sai e lo hai dimostrato.



Infatti quello che avevo scritto era questo:



Puntatore: un oggetto che contiene un riferimento diretto od indiretto 

ad un altro oggetto (di solito contiene un indirizzo)



Chi ha mai detto che un puntatore deve per forza avere l'aritmetica ?



char x[]="abc";



char*const p=x;



++p; //errore - p e' un puntatore costante



*p='b'; //ok



In C l'aritmetica dei puntatori e' solo usata per gli array ed usarla 

fuori da questo contesto con relativo accesso e' un UB



int x=4;

int* p=&x;

++p;

*p=6; //UB

int y=*p; //UB



Questo per dire che non e' obbligatorio che un linguaggio se implementa 

i puntatori deve fornirne anche l'aritmetica



Per esempio PERL ha i puntatori ma non l'aritmetica su di essi (vengono 

chiamati riferimenti nella terminologia PERL ma in sostanza sono puntatori)











Dai, avanti, trovami gli errori





Ma ad attaccarsi a pezzi di frasi fuori dal contesto  son capaci tutti





-- 

|___|




Il 02/02/23 19:11, Una mamma ha scritto:


Puntatore: un oggetto che contiene un riferimento diretto od indiretto 

ad un altro oggetto (di solito contiene un indirizzo)



Chi ha mai detto che un puntatore deve per forza avere l'aritmetica ?



char x[]="abc";



char*const p=x;



++p; //errore - p e' un puntatore costante



*p='b'; //ok



In C l'aritmetica dei puntatori e' solo usata per gli array ed usarla 

fuori da questo contesto con relativo accesso e' un UB



int x=4;

int* p=&x;

++p;

*p=6; //UB

int y=*p; //UB



Questo per dire che non e' obbligatorio che un linguaggio se implementa 

i puntatori deve fornirne anche l'aritmetica



Per esempio PERL ha i puntatori ma non l'aritmetica su di essi (vengono 

chiamati riferimenti nella terminologia PERL ma in sostanza sono puntatori)













Questo e' quello che avevo scritto

Trova gli errori













-- 

|___|




Il 02/02/23 19:15, enoquick ha scritto:


ma guarda, la cara babysitter fa le figure da cioccolataio ed ovviamente 

ignora il post

Non avevo dubbi





-- 

|___|




 Tra l'altro i compilatori C di solito non producono linguaggio macchina 



Falso. 



Non sai assolutamente NIENTE.


 La solita storiella per chi non ha niente da controbattere 



No, no, e` la solita storiella, la tua, di chi non sa niente.


 In C l'aritmetica dei puntatori e' solo usata per gli array ed usarla 



FALSO. 



Io posso usare l'aritmetica anche su un tipo primitivo che occupi piu` di un byte, per esempio. Nulla mi vieta di accedere ad ogni byte di un double, per esempio.

Sei confuso.


 ma guarda, la cara babysitter fa le figure da cioccolataio ed ovviamente 



Ma smettila di fare la figura del cretino. Ma non ti vergogni neanche un po'? Poi "babysitter" de che?? Di cosa parli? ROTFL :D 

Guarda che tutto era nato dal fatto che ti sei incartato prima dicendo che i puntatori non sono li` per compatibilita`, poi contraddicendoti. E ora vorresti fare lo splendido appellandoti al nome del linguaggio? Ma vatti a nascondere!


 La keyword asm implica che il C ha bisogno dell'assembler 



Niente affatto. Tu non sai un cazzo di come un compilatore produce codice. E` evidente.


 Non sai assolutamente NIENTE.





ma per favore



-- 

|___|




Il 04/02/23 08:52, Una mamma ha scritto:


Tu puoi anche fare una rapina se vuoi

Ma questo significa violare la legge

Questo per fare capire che c'e una bella differenza tra quello che puoi 

fare e quello che e' lecito (che in informatica violando significa avere 

un UB od un signal)

Comunque anche spaccando un double in bytes il risultato dello 

spacchettamento e' una area di memoria che puo essere vista come un 

array di bytes



union {

d double;

char a[sizeof(double)];

};





ma anche

double d=...

char* p = (char*) d



alla fin fine p e' come se puntasse al primo elemento di un array di 

char grande sizeof(double)  / sizeof(char)

E poiche sizeof(char) e' sempre 1 il tutto e' equivalente a sizeof(double)





Mi sa che il confuso sei tu









-- 

|___|




 Guarda che tutto era nato dal fatto che ti sei incartato prima dicendo che i puntatori non sono li` per compatibilita`, poi contraddicendoti. E ora vorresti fare lo splendido appellandoti al nome del linguaggio? Ma vatti a nascondere!



Te lo spiego di nuovo

I pointers fanno parte del design del C++

Non mi risulta di avere affermato  il contrario,ma se lo avessi fatto 

dipende dal contesto della frase cioe dipende da come doveva essere intesa

Tanto per non dare dubbi lo ripeto

I pointers fanno parte della progettazione del linguaggio C e C++

E per quanto riguarda il nome la figura del cioccolataio che prima 

insulta senza informarsi l'hai fatta tu

Non scaricare le tue colpe sul sottoscritto

Io te lo avevo solo fatto notare e non mi atteggio da splendido





-- 

|___|




Il 04/02/23 08:50, Una mamma ha scritto:


ma tu lo sai, evidentemente sei un grande guru del C

Il sottoscritto che scrive anche codici di analisi di linguaggi oltre 

agli studi universitari invece non sa una ceppa

Ma adesso arriva il  guru esperto di compilatori che mi viene ad 

affermare stronzate come l'implementazione delle svc al compilatore.

Notare che fai confusione tra l'asm (il linguaggio) e l'assemblatore che 

e' il compilatore, cioe il produttore di codice macchina

Il sottoscritto non ha mai scritto che il C ha bisogno di un 

assemblatore ma dell'assembler (il linguaggio) anche se i compilatori C 

in pratica ne fanno uso

(Per tua curiosita anche il preprocessore di solito e' un  programma 

separato)

Il che e' anche ovvio, e' la filosofia unix specializzare i programmi.

E nel blocco della keyword asm si scrive in asm oppure direttamente in 

codice macchina se viene accettato

E visto che secondo te un compilatore puo inglobare le svc gli facciamo 

inglobare anche gli interrupt ed in generale tutte quelle cose 

dipendenti dall' HW  non previsti dal linguaggio (mi vengono in mente 

anche i semafori e gli atomic)

Tutto bello, peccato che lo non fa nessuno e si puo ragionevolmente 

capirne i motivi

Rende il sistema piu rigido e di piu difficile manutenzione oltre a non 

separare la progettazione di basso livello di un sw dal compilatore

Infatti alcune di queste cose sono state inglobate nella std library e 

non nel linguaggio stesso

Altre sono di libera scrittura perche servono sono agli sviluppatori di 

kernel o di sistemi embedded ma nessuno mette queste cose in un 

compilatore per i motivi citati sopra

Si chiama flessibilita

La filosofia C e' quella di fornire una macchina std basilare per cui il 

linguaggio fornisce solo quelle cose strettamente indispensabili come i 

tipi semplici,gli array,le struct,le union,le funzioni e lo stack (che 

viene gestito dal compilatore)

Il resto non serve, e' demandato alla libreria std o al singolo progettista

Cose che in altri linguaggi come l'I/O,lo heap o la gestione stringhe 

fanno parte del linguaggio stesso in C no (e neanche in C++)









-- 

|___|




Il 05/02/23 10:33, enoquick ha scritto:


CORREZIONE

char* p = (char*) &d;





-- 

|___|




 array di bytes 



Si`, sto cazzo! Il punto non era questo. Il punto e` che hai affermato che l'aritmetica dei puntatori si usa solo con gli array, il che e` FALSO. F-A-L-S-O. Punto.


 A no, si scrive in asm ma non significa dipendere da esso 



Eh no, ciccino. Una cosa e` l'Assembly, una cosa e` l'Assembler, una cosa e` la parola chiave "asm" che, ti ripeto, non implica AFFATTO l'utilizzo di un assembler. Serve semplicemente ad iniettare codice asm inline, esattamente come si faceva 20-30 anni fa, con sistemi proprietari come Delphi/C++ Builder. Io stesso, come gia` detto, l'ho ampiamente usato per libreria di gestione del mouse (interrupt 0x33), di interfacciamento al sistema operativo (interrupt 0x21), e per funzioni BIOS di vario tipo (interrupt 0x10). 

Sei C-O-N-F-U-S-O.


 Te lo spiego di nuovo 



Te lo spiego di nuovo: i puntatori esistono in C++ per mera compatibilita` con il C, come affermato da Stroustrup, non per design specifico del C++. Tu hai detto che NON sono li` per compatibilita`. E` inutile che ti arrampichi sugli specchi continuando a fare la figura del cretino.


 ma tu lo sai, evidentemente sei un grande guru del C 



Certo che lo sono. Rispetto a te sono Albert Einstein. 

Ma quale "codici di analisi di linguaggi"... ma smettila, ma a chi vuoi darla a bere?

Tu non sai un cazzo ne` di C, ne` di C++ ed e` chiarissimo da cio` che scrivi. Sei un chiacchierone da bar.


 Te lo spiego di nuovo: i puntatori esistono in C++ per mera compatibilita` con il C, come affermato da Stroustrup, non per design specifico del C++. Tu hai detto che NON sono li` per compatibilita`. E` inutile che ti arrampichi sugli specchi continuando a fare la figura del cretino.



ma se era nato come estensione del C aggiungendo le classi mi dici come 

fanno i pointers a non essere presenti ?

Romperebbe una grossa compatibilita con il C

E poi i pointers sono importanti per un linguaggio che vuole anche 

essere vicino all'hw

Persino Rust, che e' un linguaggio recente, ha i pointers



-- 

|___|




 Si`, sto cazzo! Il punto non era questo. Il punto e` che hai affermato che l'aritmetica dei puntatori si usa solo con gli array, il che e` FALSO. F-A-L-S-O. Punto.



double d=...

char* p=(char*) &d;

p non e' un puntatore al primo elemento di un array di sizeof(double) / 

sizeof(char) elementi ?

Se p non punta ad un array a cosa punta ?

E non mi venire a dire che punta ad un double perche e' tipo char*

Aspetto risposta













-- 

|___|




Il 07/02/23 11:12, Una mamma ha scritto:


Libero di pensarla come vuoi

Ma non e' denigrando che avrai ragione









-- 

|___|




 Se p non punta ad un array a cosa punta ? 



Qui esce il C-ista storico che c'è in me.

Risposta: a una locazione di memoria (tipicamente un byte) che si trova a quell'indirizzo. 

Cosa ci sia prima, cosa ci sia dopo, è tua responsabilità saperlo, al fine di evitare enormi casini (a meno che tu quei casini non li stia cercando apposta, e qui la mia memoria va ai vettori di interrupt).

Questo è un po' il motivo per cui in quasi tutti i linguaggi moderni sono scomparsi e tendenzialmente non si usa più la micidiale accoppiata malloc/free. All'aumentare della complessità, aumentano i potenziali problemi.


 Se p non punta ad un array a cosa punta ?



punta ad un char. tuttalpiù dal codice si evince che è il primo byte di un 

double. di array non c'è traccia.


 Ma non e' denigrando che avrai ragione 



Denigrare? Tu ti denigri da solo. Il fatto che tu non sappia assolutamente niente ne` di C ne` di C++ lo dimostri in ogni messaggio che scrivi. 

Ovvio che sono libero di pensarla come voglio. Non sei mica tu che mi autorizzi :D


 Romperebbe una grossa compatibilita con il C 



Ma la smetti di scrivere stronzate? Eri TU che avevi affermato che i puntatori non sono li` per compatibilita`. Sono IO che affermavo il contrario e che ti riportavo una frase di Stroustrup in cui si diceva che i puntatori sono stati ereditati dal C e non avrebbe potuto rimuoverli se non rompendo la compatibilita`. 

Ahhhh... ti piace fare 'sti giochini eh? 

Tu affermavi che i puntatori non sono li` per compatibilita` ma sono una scelta progettuale precisa. FALSO. Una cosa e` EREDITARE, una cosa e` PROGETTARE.


 NO, sto affermando una cosa del genere 



Stai affermando stronzate, arrampicandoti sugli specchi come sempre. 



Quello che avevi affermato e` che l'aritmetica dei puntatori si usa solo con gli array. FALSO (come tutto cio` che scrivi). L'aritmetica dei puntatori prescinde totalmente dalla presenza o meno di un array. Quali UB, quali segfault. Tu ce li hai nella testa!!!


 Risposta: a una locazione di memoria (tipicamente un byte) che si trova a quell'indirizzo. 



Ovvio. E si puo` navigare da quella locazione in poi, come si vuole. Gli array non c'entrano assolutamente una mazza. L'array e` un tipo built-in preciso in C. Lo sfido ad entrare su qualunque gruppo di discussione sul C ed affermare "l'aritmetica dei puntatori si usa solo con gli array". Verrebbe massacrato. 



L'espertone di C e C++ di 'sto cazzo.


 Se p non punta ad un array a cosa punta ? 



Non sai un cazzo. Sbagli anche la terminologia. Non sai neanche usare il linguaggio tecnico. "Puntare ad un array", in C, significa una cosa; "puntare al primo elemento di un array" significa UN'ALTRA cosa. E quello a cui stai puntando nel tuo esempio NON e` un array. Smettila di scrivere puttanate e vatti a studiare il linguaggio per una buona volta.


 Ovvio. E si puo` navigare da quella locazione in poi, come si vuole. Gli array non c'entrano assolutamente una mazza. L'array e` un tipo built-in preciso in C. 



Ma di fatto, anche a questa definizione si potrebbe fare qualche precisazione.

C è un linguaggio di livello molto basso, per cui è vero che il compilatore poi ti agevola nella trattazione di tipi complessi, ma il principio base è che tu hai sempre a che fare con un vettore (in senso matematico) di bytes contigui. In questo senso va vista la logica dei puntatori: se sai cosa stai facendo, con puntatori e casting puoi fare delle cose molto ma molto carine; per converso, le union (che io, all'epoca, ci ho messo una vita a capire) sfruttano questa cosa proprio per consentirti nello stesso momento di vedere modi differenti lo stesso gruppo di bytes contigui.


 C è un linguaggio di livello molto basso, per cui è vero che il compilatore poi ti agevola nella trattazione di tipi complessi, ma il principio base è che tu hai sempre a che fare con un vettore (in senso matematico) di bytes contigui.



Non capisco quale sarebbe la precisazione. I vettori, a livello matematico, sono un'altra cosa (
https://it.wikipedia.org/wiki/Vettore_(matematica)
) e l'array NON e` un vettore a livello matematico, ma un tipo built-in preciso in C. Una cosa e` dire "puntatore ad array di T", una cosa e` dire "puntatore a T". Il fatto che esistano byte contigui in memoria e` ovvio, altrimenti non avrebbe senso l'aritmetica dei puntatori, ma cio` non vuol dire che "l'aritmetica dei puntatori si usa solo con gli array". Chi afferma una cosa del genere, NON conosce il C.


 Una cosa e` dire "puntatore ad array di T", una cosa e` dire "puntatore a T". 



Qui è la precisazione. Secondo la Bibbia, e salvo che nel frattempo non siano intervenute modifiche (son 20 anni che non pratico C) un array altro non è che un vettore matrice contiguo di elementi dello stesso tipo T, tendenzialmente allocato e liberato in modo eslicito, e un 'puntatore a un array di T' (*) non esiste perché è un puntatore al primo elemento del vettore matrice, e nessuno ti impedisce, con l'aritmetica dei puntatori, di spostarlo in avanti o indietro.



NB. Io mi riferisco esplicitamente a C, non a C++, dove sono stati introdotti i reference e tutta una serie di belle cosucce successive per cui mi sono accorto che le mie conoscenze acquisite da Lippman oggi sono superate.



(*) Esempio: in C una stringa è un insieme contiguo di elementi di tipo char, e nel momento in cui definisco char* stringa = "nel mezzo del cammin"; sto dicendo che stringa è un puntatore al primo elemento del vettore matrice.


Il 08/02/23 01:40, Luca Menegotto ha scritto:


Certo che e' una area di memoria come per qualunque oggetto allocato

Al tipo di oggetto mi riferivo:





Puoi scegliere:



tipo semplice

array

vector

map

list

altro



A te la scelta

-- 

|___|




Il 08/02/23 03:05, Una mamma ha scritto:


definizione di array in C:



N elementi consecutivi di tipo T



quel char* punta ad un  area di memoria di sizeof(double)/sizeof(char) 

elementi consecutivi



Se starnazza come una anatra e salta come un'anatra che cosa e?





-- 

|___|




Il 08/02/23 02:52, rootkit ha scritto:


Devo prendere atto che non conosci la mentalita del C

E' vero che p punta ad un char ma in realta punta anche al primo 

elemento di un array di char di N elementi con N = 

sizeof(double)/sizeof(char)

Occorre capire queste sottigliezze:





int* p=malloc(sizeof(int) * 10);





p punta ad un int od ad un array di 10 int   1)

Concettualmente e'  la stessa cosa di sopra







1) d'ora in avanti quando scrivo p punta ad un array e' sempre inteso p 

punta al primo elemento di un array





















-- 

|___|




Il 08/02/23 06:49, Luca Menegotto ha scritto:


finalmente qualcuno che ci capisce qualcosa

Basta pensare alla definizione di array in C





-- 

|___|




Il 08/02/23 10:58, Una mamma ha scritto:


L'aritmetica dei puntatori sei libero di usarla come vuoi in C

Nessuno te lo impedisce

Ma un conto e' essere nella legge un altro violarla

Se non si viola la legge l'aritmetica dei puntatori e' usata solo per 

gli array

Non importa se un array sia allocato sullo stack o sull' heap, violare 

questa regola e' un UB

Lo std C poi mette altre restrizioni, come e' lecito puntare (ma non 

accedere) all'elemento successivo all'ultimo elemento di un array

IL resto e' UB









-- 

|___|




Il 08/02/23 02:58, Una mamma ha scritto:


Ma fatti un esame di coscienza prima di sparare simili cavolate



-- 

|___|




 elementi consecutivi



e perché solo sizeof(double)/sizeof(char)? da lì in avanti sono tutti 

consecutivi. 


 (*) Esempio: in C una stringa è un insieme contiguo di elementi di tipo char, e nel momento in cui definisco char* stringa = "nel mezzo del cammin"; sto dicendo che stringa è un puntatore al primo elemento del vettore matrice.



No, stai dicendo che l'array di caratteri DECADE in puntatore al suo primo elemento. Questo e` uno dei tre casi specifici in cui il nome di un array DECADE in puntatore al primo elemento. In C, array e puntatori sono due cose DIVERSE, cosi` come puntatori ad array di T e puntatori a T sono due cose DIVERSE.


 Certo che e' una area di memoria come per qualunque oggetto allocato 



Non e` questo il punto. Tu hai affermato che l'aritmetica dei puntatori si usa solo con gli array. E` FALSO.


 punta al primo elemento di un array 



Perche` non sai di cosa parli. In C, puntare ad un array e puntare al primo elemento di un array sono due cose BEN DIVERSE. Vatti a studiare il linguaggio.


 finalmente qualcuno che ci capisce qualcosa 



LOL :) Infatti ha scritto una cazzata.


 gli array 



FALSO. F-A-L-S-O.


 Ma fatti un esame di coscienza prima di sparare simili cavolate 



Ma fattelo tu, un esame di coscienza, BUFFONE. Continui a sparare cretinate, incartandoti e pestando merdoni da giorni a questa parte. Una persona con un briciolo di cervello avrebbe chiuso la questione con un "scusa, hai ragione, ho scritto una minchiata". Tu no, prosegui per giorni e giorni e giorni facendo una figuraccia da MINCHIONE. 



Guarda che io vinta non te la do. Non ti lascio passare certe cazzate. Mettiti l'anima in pace.


 delle cose molto ma molto carine; 



ma questo è un altro discorso. certo, in c i puntatori sono weakly typed e 

ci puoi fare sostanzialmente quello che vuoi.


 Concettualmente e'  la stessa cosa di sopra



"concettualmente" direi proprio no. cambierei avverbio. dal punto di vista 

teorico dire che sono la stessa cosa è roba da far rivoltare il povero 

dennis ritchie nella tomba. 


 ci puoi fare sostanzialmente quello che vuoi.



Appunto, questo era il nocciolo del mio discorso. Non è da oggi che lo so, come comunicatore valgo pochissimo.



(*) Eh sì, io ho l'edizione, seconda, italiana curata da Jackson libri. La mia copia originale è finita a casa di qualcuno e non è più tornata...


 In C, array e puntatori sono due cose DIVERSE, cosi` come puntatori ad array di T e puntatori a T sono due cose DIVERSE.



Ecco, qui stiamo dicendo la stessa cosa. Credo che siamo d'accordo che in C una stringa è un insieme contiguo di caratteri terminato da \0 (anche perché non lo dico io, lo dice la bibbia...); ebbene, detto che "nel mezzo del cammin" è un vettore di caratteri di 21 (se faccio bene i conti) elementi, nel momento in cui ci metto prima char *stringa = sto dichiarando un puntatore al primo elemento del vettore e a questo punto nessuno mi impedisce di utilizzare ++stringa o --stringa. Sarebbe stato differente se avessi utilizzato char stringa[21] e poi l'avessi correttamente inizializzata.




Ecco, qui stiamo dicendo la stessa cosa



Ma neanche per sogno. Vedi sopra. Ma se il C non lo conoscete, perche` parlate?


un puntatore altro non è 



Ma cosa c'entra la definizione di puntatore? Ma siamo davvero a questi livelli? La premessa fondamentale dell'aritmetica dei puntatori e` che ci sia un'area "navigabile" — e grazie al cazzo! — ma questo non vuol dire "l'aritmetica dei puntatori di usa solo con gli array", come vorrebbe farla passare quel chiacchierone, buffone, sparapalle, espertone di C del mio sottopalle. Ti sei ficcato in questa discussione con i "eh, precisiamo qua, precisiamo la`, i puntatori ad array di T non esistono", buttandola ancora di piu` in caciara.


 Non e` che ti sei spiegato male, hai detto una cosa errata. E` diverso. 



Aggiungo, UN'ALTRA VOLTA, che in C gli array DECADONO in puntatori al loro primo elemento, a meno di 3 circostanze specifiche.


 >Ecco, qui stiamo dicendo la stessa cosa



Non so che dirti. Brian Kernighan e Dennis Ritchie, a pagina 123 e seguenti della mia edizione la seconda, edita da Jackson) distinguono molto rigorosamente tra array e puntatori e come (pagina 125, citando testuali parole e ricordando che viene definito int a[10], *pa;. pagina 123) "Poiché il nome di un vettore è sinonimo del suo primo elemento, l'assegnamento pa = &a[0] può essere scritto anche nella forma pa=a;"


Il giorno giovedì 9 febbraio 2023 alle 16:08:19 UTC+1 Luca Menegotto ha scritto:





Mi rispondo da solo. Corretto è così:



#include <stdio.h>



int main()

{

int a[] = {1, 2, 3};

int b[][3] = {

    {1, 2, 3},

    {4, 5, 6},

    {7, 8, 9}

    };



int *p = a;

int (*q)[3] = &a;

int (*r)[3] = b;



printf("%p %p\n", q, q+1);

printf("%p %p\n", p, p+1);

printf("%i\n", *r[0]);



return 0;

}



Per poter usare correttamente quei puntatori, devo indicare il tipo e la dimensione del vettore cui punteranno.

NB. r punta al primo elemento del vettore di vettori (dell'array di array) b.




Il 08/02/23 13:56, rootkit ha scritto:


perche accedervi sarebbe un UB



-- 

|___|




 Perche` non sai di cosa parli. In C, puntare ad un array e puntare al primo elemento di un array sono due cose BEN DIVERSE. Vatti a studiare il linguaggio.



Non me ne frega una cippa se e' una cosa differente

Per risparmiare parole con chi vuole fare la maestrina come te (manco 

fossimo alle elementari) ho appunto spiegato il mio pensiero

Se ci fosse da specificare una differenza lo espliciterò





-- 

|___|




 dennis ritchie nella tomba.



Direi proprio di no

E te lo dice proprio la dichiarazione del main



int main(int argc,char** argv);



Il secondo argomento e' un array di pointers a char

Come puoi vedere argv non e' dichiarato come array anche se si puo 

scrivere char* argv[]

E' la stessa cosa





E se non ti convince basta questo codice:





void print_char_array(const char* p,size_t n) {

	while(n--) {

		print("%c",*p++);

	}

	print("\n");

}



char a[]="abc";

print_char_array(a,strlen(a));



char* p=malloc(3);

memcpy(p,"abc",3);

print_char_array(p,3);



union {

	double d;

	char ad[sizeof(double);

}



d=10;

print_char_array(ad,sizeof(double));





char* pd=(char*) &d;

print_char_array(pd,sizeof(double));



















-- 

|___|




 Non e` questo il punto. Tu hai affermato che l'aritmetica dei puntatori si usa solo con gli array. E` FALSO.



Fammi un esempio in cui usarla che non sia un array (in modo lecito 

ovviamente)



-- 

|___|




 Tu affermavi che i puntatori non sono li` per compatibilita` ma sono una scelta progettuale precisa. FALSO. Una cosa e` EREDITARE, una cosa e` PROGETTARE.







I pointers fanno parte del design del C++

Non mi interessa se sono per compatibilita o meno

E' indifferente rispetto al design





-- 

|___|




Il 08/02/23 16:59, Una mamma ha scritto:


Trallallero trallalla





Inizio a non dormirci la notte per questo



Ma prendila con filosofia invece che stare li a giocare a fare la maestrina











-- 

|___|




 "Poiché il nome di un vettore è sinonimo del suo primo elemento, l'assegnamento pa = &a[0] può essere scritto anche nella forma pa=a;"



Cazzo c'entra? Non e` quello di cui si sta parlando. Io invece lo so che dirti. Dallo standard del linguaggio C:

"Except when it is the operand of the sizeof operator, or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue.".




 perche accedervi sarebbe un UB 



Falso. 


 Mi rispondo da solo. Corretto è così: 



Bene. Mi fa piacere che tu ti sia convinto che i puntatori ad array esistono.


 Non me ne frega una cippa se e' una cosa differente 



E invece te ne deve fregare, se vuoi parlare di C, con cognizione di causa. Gia`, si tratta di enoquick. Parlare di cognizione di causa nel tuo caso fa ridere.


 print_char_array(a,strlen(a)); 



Bravo. Hai scoperto l'acqua calda: a decade in puntatore al primo elemento. 



Capra incompetente.


 ovviamente) 



Te ne ho gia` fatti un miliardo, CAPRA.


 Non mi interessa se sono per compatibilita o meno 



Ma chi cazzo se ne frega cosa interessa a te. La cosa importante e` cosa e` vero e quel che affermi tu e` FALSO.


 Ma prendila con filosofia invece che stare li a giocare a fare la maestrina 



Giocare a fare la maestrina? Senti chi parla, l'espertone di C di 'sto cazzo che, di fronte a continui merdoni che pesta, non sa fermarsi e ammettere di aver sbagliato. Capra incompetente, ignorante e arrogante.


 Giocare a fare la maestrina? Senti chi parla, l'espertone di C di 'sto cazzo che, di fronte a continui merdoni che pesta, non sa fermarsi e ammettere di aver sbagliato. Capra incompetente, ignorante e arrogante.



Guarda che finora nessuno, a parte te, ha scritto che ho pestato merdoni

E se permetti le tue accuse non le ritengo molto obiettive





-- 

|___|




 Falso.



fammi  un programmino cosi e vedi il voto che ottieni da me







Te lo faccio io proprio perche sono bravo, ma almeno sono consapevole



int x=...



int* p=&x;

*++p=...



quello che c'e oltre x verra sporcato se si e' sfortunati

se invece si e' fortunati si avra un bel segfault



Comunque se tu programmi in questo modo non mandarmi curriculum di 

assunzione













-- 

|___|




 E invece te ne deve fregare, se vuoi parlare di C, con cognizione di causa. Gia`, si tratta di enoquick. Parlare di cognizione di causa nel tuo caso fa ridere.



Non me ne frega una cippa nel  contesto di questa discussione

Sei tu che ti fai le pippe mentali su queste cose

Io no



-- 

|___|




 Capra incompetente.



Beee





-- 

|___|




Il 09/02/23 17:39, Una mamma ha scritto:


Finora mi risulta che l'unica persona che ha postato del codice sia il 

sottoscritto

Comunque se mi sbaglio postami il codice



-- 

|___|




 Ma chi cazzo se ne frega cosa interessa a te. La cosa importante e` cosa e` vero e quel che affermi tu e` FALSO.



Non mi interessa in quanto avevo solo affermato che i pointers fanno del 

design

Sono li perche S. una mattina si e' alzato male e quindi ha deciso di 

metterli ?

Affari suoi, ma fanno parte del design visto che li ha messi





-- 

|___|




 int (*q)[] = &a; 



Uhm... però, se uso questo costrutto, a me la compilazione fallisce miseramente alla riga



printf("%p %p\n", q, q+1);



con messaggio: "invalid use of array with unspecified bounds". L'unico modo è, come ho scritto nel messaggio successivo, è specificare la dimensione dell'array. 




 Uhm... però, se uso questo costrutto, a me la compilazione fallisce miseramente alla riga



Ovvio. Devi specificare quanto e` lungo, altrimenti come la risolve l'aritmetica su quel puntatore?? 



Ti ripeto la domanda: ti sei finalmente convinto che i "puntatori ad array di T" esistono? E non solo i "puntatori a T"?


 design 



Falso. 


 Comunque se mi sbaglio postami il codice 



Vattelo a cercare. Studiatelo e poi torna.


 Ma certo che e' un puntatore sciocchina 



Non *e`* un puntatore IDIOTA, il nome di un array *DECADE* in puntatore. Non capisci un cazzo!!!


 trattare come un array



Ma smettila di scrivere stronzate e di svicolare come tuo solito!! Il punto non e` se un'area di memoria contigua *la si puo` trattare come un array*. Grazie al cazzo che l'aritmetica dei puntatori la puoi solo utilizzare su dati presenti in un'area di memoria contigua. Tu avevi affermato UN'ALTRA cosa, da analfabeta funzionale quale sei. Hai scritto che l'aritmetica dei puntatori si usa SOLO con gli array e questo e` F-A-L-S-O. Chiaro? F-A-L-S-O. Schiaffatelo nella tua testolina messicana: F-A-L-S-O. 



Io posso benissimo usare l'aritmetica dei puntatori, COME TI HO GIA` SCRITTO PIU` VOLTE, sull'area di memoria allocata per un double — che NON e` un array. Tu te ne esci con "eh, ma la memoria in cui e` allocato il double *puo` essere trattata come un array*" e questa e` una cosa DIVERSA, e che si meriterebbe un "e grazie al cazzo! Come la usi l'aritmetica dei puntatori se non su memoria contigua?". 



Non sai usare il linguaggio tecnico e quando scrivi merdate, accusi gli altri di non capire quel che tu volevi dire. Sei veramente senza speranza.


 assunzione 



Si`, continua a sognare e masturbarti. Poi svegliati pero`.


 Guarda che finora nessuno, a parte te, ha scritto che ho pestato merdoni 



A me sembra che siano in molti, qui dentro, a ritenere che tu scriva minchiate, ma poi che argomento sarebbe? Io conosco il C e il C++ e affermo, con cognizione di causa, che pesti merdoni sia sul C che sul C++. Uno che parla di "puntatore ad array" come "puntatore al primo elemento di un array" come lo definisci se non capra incompetente? E poi ti risponde "non mi interessa, io intendo quello". Oltre che ignorante, anche arrogante. Lo sai perche` fai lo sbruffone arrogante qui dentro? Perche` o non c'e` nessuno che ha le competenze specifiche per contestarti, o perche` a nessuno interessa di perdere tempo con un arrogante stracciapalle come te che ogni volte che sbaglia non chiede scusa ma si arrampica sugli specchi, o ti lascia perdere come si lascia perdere lo scemo del villaggio. Vuoi una conferma di questo? Prova a dire le tue minchiate in un gruppo come comp.lang.c o comp.lang.c++ e poi vediamo con quante ossa rotta esci fuori. 

Se prendi bacchettate sulle orecchie qui dentro, dove ci sono quattro gatti, figurati li`.


Il 10/02/23 12:51, Una mamma ha scritto:


invece che fare argomentazioni tecniche ecco gli insulti



-- 

|___|




Il 10/02/23 12:43, Una mamma ha scritto:


Postalo, perche io di tuo non  ne ho trovato

Non so dove sia



-- 

|___|




 Non sai usare il linguaggio tecnico e quando scrivi merdate, accusi gli altri di non capire quel che tu volevi dire. Sei veramente senza speranza.





Beeee



-- 

|___|




 Non *e`* un puntatore IDIOTA, il nome di un array *DECADE* in puntatore. Non capisci un cazzo!!!





All'esterno di una funzione sciocchina

all'interno come e' il caso di main (visto che e' una funzione) viene 

visto come puntatore

Dentro una funzione sia ha solo un pointer e basta

Sta al programmatore gestirlo

Cara la mia sciocchina che spara delle cose ovvie come fossero il non 

plus ultra











-- 

|___|




 Falso.



Vero or Falso = Vero

Quindi ho vinto io





-- 

|___|




Il 10/02/23 12:55, Una mamma ha scritto:


Le scusanti sono come i buchi dei didietri

Tutti ne hanno uno

E comunque anche se fosse vero che qualche volta avrei preso qualche 

cantonata (che comunque puo capitare a tutti) non  e' una dimostrazione

Le dimostrazioni le devi fare sull'ambito dell'attuale thread, non 

tirare fuori un supposto passato



-- 

|___|




 Ti ripeto la domanda: ti sei finalmente convinto che i "puntatori ad array di T" esistono? E non solo i "puntatori a T"?



Per la verità, io mi sono invece convinto che T può essere anche un vettore finito, e a quel punto viene considerato alla stregua di un long o di un double. A mio avviso è proprio quel che dimostra il fatto di dover specificare esattamente la lunghezza di ciò che viene riferito.


 invece che fare argomentazioni tecniche ecco gli insulti 



Smettila di fare la vittima. Le argomentazioni, e tante, ti sono state date. Tu non sai di cosa stai parlando. Punto. Se non hai niente da dire, taci.


 Postalo, perche io di tuo non ne ho trovato 



Vattelo a cercare.


 Il codice 



Sei tu che blateri, non io, incompetente. Il codice e` stato gia` postato, ma ad uno che conosce il C non serve il codice per capire che l'area di memoria occupata da un double e` perfettamente "navigabile" usando l'aritmetica dei puntatori. 



void print_double_bytes(double d) {

  unsigned char *p = (unsigned char*)&d;

  for (size_t i=0; i<sizeof d; i++) {

    printf("%.2x", *(p+i)); 

  }

  printf("\n");

}



Adesso, mi raccomando, escitene con "eh, ma *(p+i) si puo` scrivere come p[i] quindi l'area si puo` trattare come un array". Non c'e` nessun array di mezzo. La notazione con parentesi quadre e` solo per evitare verbosita`. C'e` solo un double, nessun array. 



La frase "l'aritmetica dei puntatori si usa solo con gli array" e` palesemente FALSA e ti farebbe ridere dietro da chiunque, di C, capisca anche solo un briciolo, ovvero molto piu` di te.


 design del nuovo java comprendere anche le future del classico



No, FESSO. Il design riguarda gli aspetti NUOVI. Cio` che erediti e` solo ereditato, non progettato. Non sai un cazzo di niente. Non sei manco capace di ragionare.


 All'esterno di una funzione sciocchina 



Ma stai zitto, IDIOTA! ZITTO! Si tratta di array che DECADONO in puntatori. Non sai manco di che cazzo stai parlando. 


 cantonata 



Ma stai zitto. Sei stato smerdato 100 volte e ancora parli? Impara a chiuderla li` con uno "scusate, ho scritto una cazzata", quando pesti un merdone. "Se fosse vero"? Ha ha ha... *E`* vero. Hai preso cantonate moltissime volte e continui a prenderle. Solo che anziche` stare zitto, ti imbarchi in imprese donchisciottesche contro i mulini a vento. Sei patetico.


 Per la verità, io mi sono invece convinto che T può essere anche un vettore finito, e a quel punto viene considerato alla stregua di un long o di un double.



Vedo che usi la tecnica di enoquick: spari una cazzata e poi ti lanci in ghirigori enormi per non ammettere di averla sparata. Cosa c'entra l'array finito? Ma poi, tu, hai mai visto un array infinito? Che cosa diavolo significa "viene considerato alla stregua di un long o di un double"?



Ti sei convinto o no che il C possiede i "puntatori ad array", cosa che tu dicevi non esiste? Esattamente come possiede i puntatori a funzione, peraltro? Rispondi alla domanda.


 Smettila di fare la vittima. Le argomentazioni, e tante, ti sono state date. Tu non sai di cosa stai parlando. Punto. Se non hai niente da dire, taci.



Nessuna vittima,solo pura logica

I fatti non si fanno con i quaraquaqua

IL codice, fammi vedere il codice

E' quello che serve se vuoi fare valere la tua tesi

E non tirare fuori la puttanata di andare a vedere ...

Non funziona cosi, posta il codice

Poi ne possiamo discutere





-- 

|___|




 Vattelo a cercare.



Non c'e

Quindi posta



-- 

|___|




 La frase "l'aritmetica dei puntatori si usa solo con gli array" e` palesemente FALSA e ti farebbe ridere dietro da chiunque, di C, capisca anche solo un briciolo, ovvero molto piu` di te.

Non rispondo neanche a questo

Basta quello che ho risposto sopra









-- 

|___|




Il 10/02/23 17:06, Una mamma ha scritto:


Ma quali,ma non spararne

Sei per caso il lavapiatti londinese degli array non contigui in C ?

O sempre lui che aveva affermato che  un return di una variabile di un 

tipo non semplice in java e' piu efficiente di C++ perche C++ fa la 

copia  (cosa non vera) ?

Se sei lui tanti auguri









-- 

|___|




Il 10/02/23 17:04, Una mamma ha scritto:


Forse c'e una cosa che ti sfugge

Design in inglese significa progetto (o progettare come verbo to design)

Quindi quando progetto un linguaggio se voglio includere future gia 

presenti in un  altro quelle inclusioni fanno parte della progettazione 

del nuovo linguaggio che voglio fare

Posso anche affermare che sono li per compatibilita verso quell'altro 

linguaggio ma non cambia il risultato

Sempre di design si tratta

Tenere una compatibilita verso un altro linguaggio e' una scelta, non un 

obbligo

Se voglio farlo e' perche quel linguaggio l'ho progettato cosi





-- 

|___|




 Ma stai zitto, IDIOTA! ZITTO! Si tratta di array che DECADONO in puntatori. Non sai manco di che cazzo stai parlando.



Sempre sciocchina:





se ti scrivo una funzione cosi



void f(int* p) {





}





quel p punta al primo elemento di un array o ad un solo int ?



Messo cosi non si puo sapere anche se si suppone (notare si suppone) che 

sia un solo int (ma potrebbe essere un int che fa parte di un array) 

perche un parametro di numero elementi non e' passato

Ma il puntatore da solo non puo dare queste informazioni







-- 

|___|




 Nessuna vittima,solo pura logica 



Ma quale logica. Quale??? Tu che parli di logica? A cosa ti serve il codice? Sei incapace di capire la descrizione di un concetto? Ti si deve per forza fare il disegno? FAI PENA.


 Quindi posta 



Invece c'e` e te lo vai a cercare. Il fatto che tu voglia vedere del codice e` che non sia capace di capire un concetto semplicemente descritto la dice lunga su quanto tu conosca il linguaggio C e su quanto tu sia abituato a discuterne con chi ci capisce. 


 Quel p punta ad un array di unsigned char con sizeof(double) elementi 



STO CAZZO. Quel p non punta AFFATTO ad un array di unsigned char! Ti ripeto, ANCORA UNA VOLTA, che in C, "puntare ad un array di T" e "puntare a T" sono due cose BEN diverse. 

E` la differenza, che tu NON sai, tra int *p e int (*p)[..]

Vai a studiare le basi del linguaggio.



Tu hai affermato "l'aritmetica dei puntatori si usa solo con gli array". E` falso. 


 Ma quali,ma non spararne 



Ma cosa stai dicendo! Stai delirando! Fatti curare!!!!


 Design in inglese significa progetto (o progettare come verbo to design) 



Lo so meglio di te cosa significa quel sostantivo e quel verbo in inglese. 

La progettazione del C++ riguarda solo gli aspetti NUOVI del linguaggio. Gli aspetti ereditati non sono progettati, sono solo ereditati.

Guarda che io certe cretinate non te le lascio passare quindi per quante volte ripeterai la stessa sciocchezza, altrettante troverai la mia confutazione. 

I puntatori, in C++, esistono SOLO per compatibilita` con il C, non perche` espressamente progettati per il C++, quindi mettiti l'anima in pace. 

Te lo ha detto anche l'inventore del linguaggio.


 quel p punta al primo elemento di un array o ad un solo int ? 



Ma cosa cazzo c'entra?? Ma lo vedi che non capisci un cazzo di niente? 



Si sta parlando del fatto che i nomi degli array DECADONO in puntatori al primo elemento. Vai a studiare le basi del linguaggio!!


 Vedo che usi la tecnica di enoquick: spari una cazzata e poi ti lanci in ghirigori enormi per non ammettere di averla sparata. Cosa c'entra l'array finito? Ma poi, tu, hai mai visto un array infinito? Che cosa diavolo significa "viene considerato alla stregua di un long o di un double"? 



No. Se leggi bene cosa ho detto, significa che definito un puntatore int (*p)[3];, che può puntare a un vettore di tre interi e SOLO a un vettore di tre interi (e questo è vero, e in questo hai ragione), de facto a questo puntatore può riferirsi alternativamente a un singolo elemento [vettore di tre interi] o a un vettore di elementi [vettore di tre interi], nel qual caso punterà in modo predefinito al primo elemento e su quale potrò usare l'aritmetica dei puntatori. Non posso sapere a priori, solo osservando il puntatore, a cosa sta puntando, se oggetto singolo o vettore, né, qualora  questo qualcosa sia un vettore, quale sia la dimensione del vettore (questo intendo quando non finito). 



Che poi, ricordo male o è possibile fare una roba del genere?



 p = (int(*)[3]) alloc(100 * sizeof(int));




Non posso sapere a priori, solo osservando il puntatore, a cosa sta puntando



"Non posso sapere" chi? Di chi parli?? Il compilatore lo sa eccome. Ha il contesto necessario a capire di quanto il puntatore deve avanzare. 


...

per cui preciso che quando scemoquick scrive "quando dico puntatore ad array intendo puntatore al primo elemento dell'array" lascia trasparire tutta la sua incompetenza sul C. In C, le definizioni sono rigorose e non le si puo` usare a cazzo di cane: puntatore ad array di T e` una cosa, puntare a T e` UN'ALTRA cosa. 


 Ma quale logica. Quale??? Tu che parli di logica? A cosa ti serve il codice? Sei incapace di capire la descrizione di un concetto? Ti si deve per forza fare il disegno? FAI PENA.



ma l'hai postato quindi non hai resistito alle miei pressioni

Ed e' inutile che continui con gli insulti

A me non fanno ne caldo ne freddo



-- 

|___|




Il 10/02/23 20:53, Una mamma ha scritto:


Quando avevo scritto questo messaggio non l'avevi ancora postato



-- 

|___|




 "Non posso sapere" chi? Di chi parli?? Il compilatore lo sa eccome. Ha il contesto necessario a capire di quanto il puntatore deve avanzare.



Ho usato la prima persona singolare. E io non sono un compilatore. E il compilatore sa di quanto deve avanzare o indietreggiare, con l'aritmetica, ma non se è in zona ben sicura e delimitata (il b di cui sopra) o nell'ignoto; in questo secondo caso, penso tu sia d'accordo che si va incontro a problemi.


Il 10/02/23 20:57, Una mamma ha scritto:


In un post precedente avevo scritto che in  C qualunque area di memoria 

contigua puo essere trattata come un array

E tu non hai obiettato su questo

Ma andiamo indietro un attimo





Tu hai scritto:

*(p+i)



ma guarda un po

questo puo essere scritto come p[i]

Infatti il compilatore traduce p[i] in *(p + i)

Ma questo e' anche il modo in cui si indicizzano gli array

Ma non si e' obbligati ad usarli su un array ma vale su qualunque puntatore



void f(int *p) { //f non sa niente su cosa viene passato - f vede solo 

un puntatore

	p[1]=10; //stessa cosa di *(p + 1)=10

}



int v[]={1,2];

f(v);

printf("%d\n",v[1]);  //stampa 10



int* m=malloc(sizeof(int) * 2);

m[0]=1; //e' lecito - viene convertito in *(m + 0)=1;

m[1]=2; //e' lecito - viene convertito in *(m + 1)=2;

f(m);

printf("%d\n",m[1]);  //stampa sempre 10



Gia questo farebbe sorgere un dubbio

Perche mai trattare un puntatore ed un array indicizzando si ha lo 

stesso risultato ?

E' perche e' possibile trattarli nello stesso modo in questo caso ?

Perche sono la stessa cosa,il nome di un array (v in questo caso) non e' 

altro che il puntatore al primo elemento

Lo so,lo so ora inizierai a tirare tutte le super cazzole che il famoso 

K&R afferma che un array viene convertito in puntatore ma sono due cose 

differenti

Non e' cosi, il K&R e' stato scritto in una epoca in cui i puntatori 

costanti non esistevano per cui non si poteva affermare che v e' un 

puntatore altrimenti, e giustamente,qualcuno avrebbe fatto notare che su 

v non posso fare v++ (una operazione aritmetica) come su qualunque 

puntatore

Ed allora si sono inventati il concetto di array che decade in puntatore

Ma oggi i puntatori costanti esistono (la keyword const e'stata 

introdotta in C++ e poi adottata dal C ma ben dopo il K&R)

per cui questa cosa dell'array che decade in puntatore e' semplicemente 

fuorviante

Il nome di un array e' semplicemente un puntatore costante al primo elemento

In C si scrive T*const <name>;//puntatore di tipo T costante, non e' il 

nome di un array

int*const p;

++p //errore p e' un puntatore costante

int v[]={0};

++v; //errore - v e' un puntatore costante

E cosi tutto torna

Un puntatore ad un array non e' altro che un puntatore indiretto: in C 

si scrive T**

Dopo questo basta anche fare un programma equivalente per convincersi



union {

	double d;

	unsigned char v[sizeof(double)];

};



e poi usare lo stesso ciclo for che hai scritto su v;





oppure double* d=malloc(sizeof(double));

*d=10;

unsigned char* p=(unsigned char*) d;

e poi fare il solito ciclo su p





Tutto torna

Basta semplicemente ricordarsi che qualunque area di memoria contigua 

puo essere vista come un array in C

Ed ecco perche lo spazio di memoria occupato da un double lo posso 

vedere come un array di unsigned char di sizeof(double)/sizeof(unsigned 

char) elementi (sizeof(unsigned char) e' sempre 1 per cui basta 

sizeof(double))

Semplice

Altrimenti se non  fosse cosi si arriverebbe al punto di farsi 

supercazzole mentali per trovare le varie eccezioni,cosa che stai facendo tu

Invece il C e' semplice ed elegante, almeno nei concetti base





-- 

|___|




Il 10/02/23 21:02, Una mamma ha scritto:


Ma non decadono una mazza

il nome di un array e' un puntatore costante al primo elemento quando 

voglio fare accesso o copiarlo in un puntatore

Ora verrai a sparare che questo e' scritto nella bibbia del C, ed e' vero

Ma quella bibbia e' vecchia ed obsoleta

Oggi e' possibile vedere la cosa in modo differente

E la cosa e' piu logica e pratica





-- 

|___|




 per cui preciso che quando scemoquick scrive "quando dico puntatore ad array intendo puntatore al primo elemento dell'array" lascia trasparire tutta la sua incompetenza sul C. In C, le definizioni sono rigorose e non le si puo` usare a cazzo di cane: puntatore ad array di T e` una cosa, puntare a T e` UN'ALTRA cosa.





NB

Quando ho scritto quella frase era solo per sintetizzare la scritta

Non che non sappia la differenza come vuoi fare intendere (in malafede)

Dal punto di vista pratico quante volte capita di usare un pointer ad un 

array reale ?

Non so te,ma per me e' raro usare una future di questo tipo in un 

programma reale

E credo che sia cosi in generale

E vai con le pippe mentali

Ti avevo gia scritto che non e' con gli insulti che ottieni le tue 

ragioni, ma con la logica

Impara a discutere in  modo civile,prima di tutto





-- 

|___|




Il 10/02/23 21:00, Una mamma ha scritto:


L'eredita stessa fa parte del design

Non me lo obbliga il dottore ad ereditare future da un altro linguaggio

Se lo voglio fare e' perche la progettazione del linguaggio e' quella di 

contenere quelle future





-- 

|___|




 L'eredita stessa fa parte del design 



LOL :) Che era esattamente cio` che tu negavi. Si finisce sempre d'accapo con te, scemoquick. Avevi affermato che i puntatori non sono li` per compatibilita` con il C. Lo sono, invece, e Stroustrup ne da` conferma. Non fanno parte della progettazione del C++ per se, ma sono solo ereditati dal C. Punto. Basta. A cuccia. Fai silenzio.


 array reale ? 



Quello che capita o non capita di usare *a te* e` assolutamente irrilevante. Il punto e` che il C supporta i puntatori ad array di T e i puntatori a T, per cui non si puo` parlare dei secondi usando la terminologia dei primi. I puntatori ad array si usano eccome in C, tutte le volte che vuoi, guarda un po', allocare dinamicamente array di array!!


 Ma non decadono una mazza 



Dacci un taglio e vai a STUDIARE! I nomi degli array DECADONO in puntatori al loro primo elementi in tutti i casi tranne 3 casi specifici: l'uso dell'operatore address-of (&), l'uso di sizeof e l'inizializzazione con uno string literal. 



"The way that array names "decay" into pointers is fundamental to their use in C and C++" (Stroustrup: 
https://www.stroustrup.com/bs_faq2.html
)



Guarda che il cosiddetto "array decay" e` descritto nello standard del linguaggio stesso:



"Except when it is the operand of the sizeof operator or the unary & operator, or is a

string literal used to initialize an array, an expression that has type ‘‘array of type’’ is

converted to an expression with type ‘‘pointer to type’’ that points to the initial element of

the array object and is not an lvalue."



Uno dei tanti link sull'argomento (ma ti basta googlare "array decay"):

https://64.github.io/cpp-faq/decay/




Oltretutto, esiste anche std::decay. 



Ed anche oggi hai imparato qualcosa di nuovo!


 stesso risultato ? 



Ottieni lo stesso risultato UN PAR DE CAZZI! 

Io potrei voler allocare dinamicamente, per esempio, uno spazio vettoriale di tuple di dimensione 3, quindi posso benissimo dichiarare:



#include <stdio.h>

#include <stdlib.h>



int main() {

    double (*v)[3] = malloc(100 * sizeof *v);



    for (int i=0; i<100; i++) {

        v[i][0] = rand() % 10;

        v[i][1] = rand() % 10;

        v[i][2] = rand() % 10;

    }



    puts("[");

    for (int i=0; i<100; i++) {

        printf("\t[%5.2f, %5.2f, %5.2f]\n", v[i][0], v[i][1], v[i][2]);

    }

    puts("]");



    return 0;

}



Snip tu tutto il resto che non ho neanche letto perche` e` sicuramente la solita montagna di cazzate. Ma a chi pensi di fare lezioncine tu?



La cosa che ti devi ficcare in testa e` che, in C, esistono puntatori ad array di T e puntatori a T, sono due cose ben diverse, e i nomi degli array DECADONO in puntatori al loro primo elemento. 


 Quando avevo scritto questo messaggio non l'avevi ancora postato 



Certo che si`, invece, idiota. Bastava cercare.


 ma l'hai postato quindi non hai resistito alle miei pressioni 



Ha ha ha ha! Tu fare pressioni a me? :D :D :D tu non saresti in grado di premere manco il bottone dell'ascensore! Il tuo problema e` che sei talmente incompetente sul C e talmente incapace di ragionare in maniera astratta, che hai necessariamente bisogno di un disegno. E l'altro problema che hai e` che pur facendoti un disegno, continui a non capire. Guarda, io vorrei davvero vedere che razza di codice di merda scrivi nella vita di tutti i giorni. Spero davvero che tu programmi per hobby e non a livello professionale.


in questo secondo caso, penso tu sia d'accordo che si va incontro a problemi.



Non c'entra un cazzo con quanto si stava dicendo. Che fai, come scemoquick, che svicoli? Torniamo al punto: ti sei convinto o no che i puntatori ad array di T, in C, esistono, e sono cosa ben diversa da un puntatore a T? Si` o no. Non esistono alternative.


 LOL :) Che era esattamente cio` che tu negavi. Si finisce sempre d'accapo con te, scemoquick. Avevi affermato che i puntatori non sono li` per compatibilita` con il C. Lo sono, invece, e Stroustrup ne da` conferma. Non fanno parte della progettazione del C++ per se, ma sono solo ereditati dal C. Punto. Basta. A cuccia. Fai silenzio.



Ma che negavo

Ma se ho sempre specificato che la compatibilita fa parte del design



-- 

|___|




Il 11/02/23 17:56, Una mamma ha scritto:


si si

Attieniti alla ufficialita cosi rimani piu confuso

E si vede visto che non hai ancora capito cosa e' un array in C

Vedere un array come l'ho spiegato e' invece piu semplice

Un array e' un puntatore costante con due eccezioni rispetto ad un 

puntatore classico

La sizeof ritorna la size dell'area di memoria puntata ed ha 

l'inizializzazione multipla (quella con le graffe)

Visto cosi diventa tutto molto piu chiaro quando si usa l'array





-- 

|___|




 La cosa che ti devi ficcare in testa e` che, in C, esistono puntatori ad array di T e puntatori a T, sono due cose ben diverse, e i nomi degli array DECADONO in puntatori al loro primo elemento.





Ma certo,il K&R specifica questo, e la puo anche vedere cosi

Ma il tuo ragionamento su quel double non  sta in piedi



-- 

|___|




 Quello che capita o non capita di usare *a te* e` assolutamente irrilevante.



Non e' irrilevante

Prendi un bel po di programmi C (ad esempio open source da linux) e fai 

una statistica su quante volte viene usato un pointer al primo elemento 

ad un array e quante volte viene usato il tuo caro puntatore ad array 

(che poi non e' altro che un banale T**)

Ti accorgerai che il primo caso e' molto piu usato







  Il punto e` che il C supporta i puntatori ad array di T e i puntatori 

a T, per cui non si puo` parlare dei secondi usando la terminologia dei 

primi. I puntatori ad array si usano eccome in C, tutte le volte che 

vuoi, guarda un po', allocare dinamicamente array di array!!



A parte le cose ovvie dinamicamente si alloca un area di memoria e basta

E' il programmatore che da un senso al tipo di struttura dati che 

quell'area di memoria conterra  non il linguaggio





-- 

|___|




 Ha ha ha ha! Tu fare pressioni a me? :D :D :D tu non saresti in grado di premere manco il bottone dell'ascensore! Il tuo problema e` che sei talmente incompetente sul C e talmente incapace di ragionare in maniera astratta, che hai necessariamente bisogno di un disegno. E l'altro problema che hai e` che pur facendoti un disegno, continui a non capire. Guarda, io vorrei davvero vedere che razza di codice di merda scrivi nella vita di tutti i giorni. Spero davvero che tu programmi per hobby e non a livello professionale.



Ma intanto hai postato, quindi la pressione ha funzionato

Poi puoi anche atteggiarti da splendida ma sono affari tuoi







-- 

|___|




 Certo che si`, invece, idiota. Bastava cercare.



ma va la che non c'era nessun codice

era solo spiegato a parole e a casa mia quello non e' codice

Al massimo pseudo codice



-- 

|___|




  T, in C, esistono, e sono cosa ben diversa da un puntatore a T? Si` o no. Non esistono alternative.



Se tu non avessi la bava alla bocca, sapresti che ti ho risposto di sì tre messaggi fa.




 Ma se ho sempre specificato che la compatibilita fa parte del design 



NO. Hai affermato che i puntatori non sono li` per compatibilita`, smentendoti due messaggi dopo. Vergognati. Non te le faccio passare le tue cazzate.


 Un array e' un puntatore costante 



NO! Un array, come afferma lo standard del linguaggio, DECADE in puntatore al primo elemento, ad eccezione di tre circostanze specifiche. 



Vai a studiare, CAPRA.


 Ma il tuo ragionamento su quel double non sta in piedi 



Certo che sta in piedi, e tu, sul C, sei confuso fino alle ossa.


 A parte le cose ovvie dinamicamente si alloca un area di memoria e basta 



Falso. L'aritmetica dei puntatori si basa sulla conoscenza del tipo puntato, altrimenti, IDIOTA, come farebbe un compilatore a produrre codice per avanzare del numero corretto di locazioni di memoria?



Se hai int *p e compi p+5, il compilatore sa benissimo di dover emettere codice per saltare dall'indirizzo p all'indirizzo p + 5*sizeof(int).



Non sai un cazzo!!!


 ma va la che non c'era nessun codice 



Il codice era li`, IDIOTA.


 Se tu non avessi la bava alla bocca, sapresti che ti ho risposto di sì tre messaggi fa.



La bava alla bocca la fate venire tu e scemoquick continuando a ripetere minchiate e non riuscendo ad ammettere che vi sbagliate. Patetici buffoni ignoranti e arroganti. Non sapete un cazzo e continuate ad intervenire. Andate a studiarvi le basi del linguaggio, chiacchieroni da bar.


 progettazione del linguaggio e' quella di contenere quelle future



è un ragionamento ad minchiam. un conto è implementare una feature 

ispirandosi un altro linguaggio e un conto è ereditarla perché si nasce 

compatibili con quel linguaggio e si vuole mantenere questa compatibilità. 



per dire: il go ha implementato molte feature, fra cui i puntatori, 

ispirandosi a linguaggi esistenti, ma non c'è nessuna esigenza di 

compatibilità. queste sono pure scelte di design. il c++ invece nasce per 

essere compatibile con c ed è in ragione di questa compatibilità che ha i 

puntatori. quindi non è una scelta di design ma una scelta forzata da 

esigenze di compatibilità con c.




 Allora usa il verbo "punta", non "si riferisce". Altro che monsieur de La Palice, buffone arrogante che non sei altro. 



Io uso quel che mi aggrada, e se la cosa ti fa sbroccare, non è ne ho intenzione che diventi problema mio.

Dal momento che parti a insulti e che no ho alcuna intenzione di seguirti su questa strada, mi fermo qui.

Buona vita.


 per dire: il go ha implementato molte feature, fra cui i puntatori, 



Torno a bomba per una domanda: Root, a tuo avviso, qual è l'ambito applicativo migliore per GO? e dove davvero non ha senso?


Il 12/02/23 04:36, rootkit ha scritto:


Se voglio fare un nuovo linguaggio che sia compatibilite in alcune 

future con qualche altro linguaggio e' una scelta non un obbligo

Fa comunque parte della progettazione del nuovo linguaggio

E progettazione significa design in inglese



-- 

|___|




 Non sai un cazzo!!!



Ma va ?

Spari delle ovvieta come fossero cadute dal cielo facendo credere (in 

malafede) che il sottoscritto non le sappia

Ma la malloc non sa niente di cosa vuoi farne di quell'area di memoria 

restituita

Infatti restituisce un void*



-- 

|___|




 Il codice era li`, IDIOTA.



si,si , ci credo



-- 

|___|




 Certo che sta in piedi, e tu, sul C, sei confuso fino alle ossa.



Solo parole,niente fatti



-- 

|___|




Il 12/02/23 03:45, Una mamma ha scritto:


Guarda che il K&R l'ho avuto fin dagli anni 80 del secolo scorso 

(purtroppo lo prestai ad un amico perche voleva imparare il C ma non 

l'ho piu riavuto indietro,peccato)

Io ti ho dato una mia interpretazione di array, non che non  so cosa 

dice lo std

Proprio perche so cosa dice lo std che posso fare delle mie 

interpretazioni personali



-- 

|___|




 NO. Hai affermato che i puntatori non sono li` per compatibilita`, smentendoti due messaggi dopo. Vergognati. Non te le faccio passare le tue cazzate.



Ma va la



-- 

|___|




 Io uso quel che mi aggrada



Certo, se vuoi fare la figura del minchione incompetente. 


 future con qualche altro linguaggio e' una scelta non un obbligo 



"feature", non "future". 

La necessita` di mantenere la compatibilita` con il vecchio linguaggio costituisce impossibilita` di scelta. I puntatori sono li` perche` ereditati, non perche` progettati esplicitamente per il C++. Mettiti l'anima in pace. Ma poi, tutto questo e` il tuo solito svicolare per una tangente che NULLA a che vedere con la tua frase iniziale, e cioe` che i puntatori non sarebbero in C++ per compatibilita`, cosa palesemente FALSA (come tutto cio` che scrivi peraltro).


 Spari delle ovvieta 



Non sono ovvieta` per uno, come te, che NON SA la differenza tra "puntatore ad array di T" e "puntatore a T". 



La malloc() non c'entra una beata minchia di niente. Quel che conta e` il tipo del puntatore, che il compilatore conosce ed usa per compiere la corretta aritmetica. 



Vai a studiare, CAPRA!


 allocare un array di array occorrono strane cose



Ma quando mai, DEFICIENTE! Vatti a rileggere il thread!


 Io ti ho dato una mia interpretazione di array



La tua "intepretazione di array" tientela per te. Non serve interpretare una mazza di niente. Hai affermato "non decade una mazza", ti ho riportato quel che dice lo standard del C a riguardo di cio` che viene chiamato "array decay", ti ho postato un link a std::decay, ma niente... "ah si si, appellati all'ufficialita` cosi` resti piu` confuso!" risponde il buffone ignorante. Ma vatti a nascondere!!!


 Ma va la 



"char* (in generale i pointers) non sono per compatibilita verso il basso" (enoquick, 5 gennaio)

"C++ e' nato per avere compatibilita con il C aggiungendo" (enoquick, 31 gennaio)



Vergognati, buffone.


 Vai a studiare, CAPRA!





Gia fatto, fin dagli anni 80 del secolo scorso

Scrivevo codice C su macchine unix quando linux non esisteva ancora

Fai un po tu



-- 

|___|




 Certo, se vuoi fare la figura del minchione incompetente.



I minchioni sono tanti, milioni di milioni

Minchioni qualita

Tutti minchioni sono, l'unico guru e' ....

Gli altri non sanno una mazza





-- 

|___|




Il 12/02/23 12:07, Una mamma ha scritto:


Va be, visto che un qualcosa di logico non sei riuscita a tiralo fuori 

ma solo insulti credo di dover fare come il buon Menegotto

Pace,vita e prosperita

Inutile  perdere tempo in questo modo



-- 

|___|




Il 12/02/23 12:09, Una mamma ha scritto:


Certo che me la tengo per me

Io ho fatto un ragionamento sperando in un certo stimolo (non al bagno 

ma intellettuale)

Cercare di vedere le cose da un'altra prospettiva

Buona vita



-- 

|___|




 Vergognati, buffone.





Prima tu



-- 

|___|




Il 12/02/23 12:01, Una mamma ha scritto:


C++ non e' compatibile al 100% con C

Includere o non includere una funzionalita dal linguaggio precedente non 

e' una scelta di design?





-- 

|___|




 mi fai un piacere.



io ne ho un'opinione positiva. sul linguaggio sembrerà strano ma apprezzo 

il fatto che non è a oggetti, il che ti leva un bel po' di overthinking (o 

seghe mentali) di progettazione. non ha classi, ma ha struct e interfacce 

e si possono agganciare metodi alle struct.




 Fai un po tu 



Quello che "faccio io" e` basato su quello che scrivi: sei confuso e ti mancano capacita` di ragionamento minime.


 Gli altri non sanno una mazza 



No, no, ci sono tantissimi di competenti su C e C++ nel mondo. Siete tu e Menegotto che DIMOSTRATE di non sapere una mazza.


 Va be, visto che un qualcosa di logico non sei riuscita a tiralo fuori 



Eh si`, certo, credici. Rileggiti il thread. Il problema e` che tu, le cose logiche, non sei in grado di comprenderle. Sono io che perdo tempo con nel cercar di lavare la testa all'asino.


 Cercare di vedere le cose da un'altra prospettiva 



Ma quale stimolo! Ma quale "altra prospettiva". La prospettiva secondo cui un puntatore ad array di T equivale ad un puntatore a T? La prospettiva secondo la quale "l'aritmetica dei puntatori si usa solo con gli array"? Le tue "prospettive" sono fallaci, FALSE e palesemente ERRATE.


 Lo afferma lo stesso S. nel suo libro 



Niente affatto. Stroustrup afferma il contrario di quel che affermi tu. Te l'ho anche dimostrato.


 e' una scelta di design? 



No. Stroustrup non aveva scelta.


 tu e Menegotto che DIMOSTRATE di non sapere una mazza.



Però va fatto un bel distinguo, netto. I due nomi che hai

postato non sono nemmeno lontanamente paragonabili.












 postato non sono nemmeno lontanamente paragonabili.



Ascolta me, lascia perdere. 


 applicativo migliore per GO? e dove davvero non ha senso?



io vedo che è molto usato per il software di base, tipo tutto l'ecosistema 

di kubernetes è scritto in go. adatto anche a scrivere backend web 

performanti e applicazioni client da command line. 

imho non ha senso in applicazioni desktop grafiche.


 Ascolta me, lascia perdere.



Ma "ascolta me", cosa? Ahoooo... svegliati Menecagotto! Hai sparato una montagna di cazzate e sei incapace di ammettere che hai sbagliato. Hai dimostrato di NON sapere cosa sia un puntatore ad array, dicendo che, semplicemente, in C non esiste (LOL!).



Ascolta me: vergognati.


 postato non sono nemmeno lontanamente paragonabili.



Ma cosa me ne dovrebbe mai fregare dei nomi? Se dicono le stesse cose, che differenza farebbe il nome? A me interessano gli argomenti, e gli argomenti presentati da Menegotto dimostrano incompetenza sul C. Punto. Per non parlare di enoquick, ma ormai alle sue scemenze ci si e` abituati qui dentro. 



L'argomento del Menegotto (entrando a gamba tesa e volendo "precisare"... LOL) sarebbe che in C parlare di "puntatore ad array di T" e parlare di "puntatore a T" sarebbe la stessa cosa, perche` se allochi memoria dinamicamente, sei tu programmatore che sai quanti elementi hai allocato, e quindi un int *p puo` puntare sia ad 1 elemento, "che ad un vettore di n elementi". 



E` S-B-A-G-L-I-A-T-O.



Quando, in C, si parla di "puntare", si tiene in considerazione il dato del tipo puntato, per cui puntare-a-T e` ben diverso che puntare-ad-array-di-T perche`, ma questo e` ovvio a chiunque conosca un briciolo di C, l'aritmetica dei puntatori DEVE tener presente la dimensione del tipo puntato per funzionare correttamente. Quello che il programmatore puo` o non puo` sapere non c'entra una ceppa. C'entra il dato conosciuto dal compilatore nel momento in cui genera il codice per saltare a una certa locazione di memoria. 



Il Menegotto, poi, messo di fronte alle sciocchezze che scrive, se ne viene fuori con i "riferirsi", "uso il linguaggio che piu` mi aggrada", "cerco sinonimi per non appesantire il discorso", e altre cazzate colossali che servono solo a buttarla in caciara e non sputare fuori un semplice "scusa, ho sbagliato, hai ragione". 



PATETICO.















Cosa dovrei lasciar perdere esattamente? E perchè mai?






 di kubernetes è scritto in go. adatto anche a scrivere backend web 



Non per backend web. Solo per cose di bassissimo livello, come appunto Docker, Kubernetes, etc. Per i backend web, il modello proposto da Go, che e` fondamentalmente quello del vecchio C, crea solo problemi. Se lavori su una MSA, hai bisogno di poter modellare il tuo bounded context seguendo DDD, etc... prova a farlo in Go, ti spari un colpo in testa.


 Cosa dovrei lasciar perdere esattamente? E perchè mai?



Perché io, nella mia carriera, di personaggi del genere ne ho incontrati parecchi.

Sono intrinsecamente tossici. L'unica soluzione - e qui ammetto il mio errore originale - è lasciarli perdere in partenza.


 Perché io, nella mia carriera, di personaggi del genere ne ho incontrati parecchi. 



Ma quale carriera :D Carriera de che? Scrivere due lineette di codice in croce? Il tuo errore originale e` stato quello di intervenire su un argomento su cui non sai NULLA. Anche io, nella mia carriera, ho incontrato diversi personaggi del tuo genere, ovvero gente che apre bocca tanto per farlo, che fa danni e che, quando viene messi davanti ai propri errori, non sa riconoscerli.



Guarda, io ascolto volentieri i tuoi consigli ("lasciar perdere"),

però vorrei capire perché: Cosa intendi per "intrinsecamente tossici" o

"personaggio del genere"?



Se mi spieghi, allora potrò decidere se seguire i tuoi consigli,

altrimenti potrebbero sembrare banalmente tuoi pregiudizi.




 Guarda, io ascolto volentieri i tuoi consigli ("lasciar perdere"), 



No, non farlo.



???

Cambiato opinione?












 Cambiato opinione?



No. Ma è ovvio che, pur basandosi su lunga esperienza, si tratta di una mia personalissima opinione, e l'ultima risposta che il tale mi ha dato, pur sapendo che non gli avrei risposto, la rafforza, ove ce ne fosse stato bisogno.

Però ognuno ha il pieno diritto di pensarla differentemente da me. 



Ah, ti anticipo già che a questo messaggio il tale mi risponderà con insulti di vario genere e specie.


 Non sai un cazzo. Sbagli anche la terminologia. Non sai neanche usare il linguaggio tecnico. "Puntare ad un array", in C, significa una cosa; "puntare al primo elemento di un array" significa UN'ALTRA cosa. E quello a cui stai puntando nel tuo esempio NON e` un array. Smettila di scrivere puttanate e vatti a studiare il linguaggio per una buona volta.



E va be, un'ultima risposta poi farai tu

Quel puntatore punta,per me, al primo elemento di un array,cosi ti 

accontento come terminologia

Ma visto che insisti che quel puntatore non punta ad un array a che punta ?

A casa mia quel puntatore punta ad un'area di memoria  grande 

sizeof(double) e composta da unsigned char consecutivi, quindi e' un 

array di unsigned char

Poi fai tu

PS: il linguaggio tecnico lo conosco bene, e' che mi rompo le palle 

scrivere le spippolate ovvie

Ti ho solo accontentato per questa volta





-- 

|___|




 No. Stroustrup non aveva scelta.





Ovviamente, la mafia del C e' dura a morire, e' molto potente

Quando Don Ciccio (il Boss della mafia del C all'epoca) venne a sapere 

che un certo S. aveva in mente di progettare un nuovo linguaggio lo ha 

minacciato di doverlo rendere per forza compatibile con il C altrimenti 

la sua famiglia avrebbe avuto dei problemi

E' un po come quelli che non pagano l'assicurazione

Poi con il tempo la mafia del C e' andata avanti

Quando seppe della progettazione di un altro linguaggio chiamato Oak (o 

giu di li) che poi sarebbe diventato java,anche li doveva  essere un 

syntax C like, altrimenti ... (Be' hai capito)

Idem perfino con MS quando progetto' C# (tanto per capire quanto sia 

potente la mafia del C)

Ed ora signori e signorine, ecco il vero motivo per cui il C e' tra i 

linguaggi piu usati sul pianeta

E' la mafia del C che obbliga a questo,il TIOBE index e' truccato

E' molto potente questa mafia, si dice che persino Biden e Trump non 

sarebbero stati eletti se prima non avessero recitato a chi di dovere un 

brano tratto dal mitico K&R prima edizione (brano da imparare a memoria 

ovviamente)

Ed una volta entrati alla casa bianca mostrare una copia del K&R sul 

proprio comodino vicino al letto per almeno una settimana altrimenti 

...(e' come per l'assicurazione) tanto per ricordare chi comanda







-- 

|___|




 Ah, ti anticipo già che a questo messaggio il tale mi risponderà con insulti di vario genere e specie.



Ti stai insultando da solo, continuando a fare la figura del peracottaro. Sei intervenuto in una discussione su un argomento su cui non sai nulla, per fare "precisazioni" strampalate, usando un linguaggio non-tecnico strampalato e facendo figure barbine. Ovviamente, ora cerchi l'uscita drammatica per salvare la faccia. Stai zitto e basta no? Non sarebbe meglio?


 Quel puntatore punta,per me, al primo elemento di un array



Non si tratta di "opinioni". Non esiste "per me", "per te". La programmazione in linguaggio C non e` questione di opinioni. La cosa ti e` stata gia` spiegata una dozzina di volte, ma non la comprendi 1) perche` ti mancano le capacita` piu` basiche di comprensione 2) perche` non hai mai studiato a fondo il linguaggio C. 



Te lo rispiego l'ultima volta e fai il favore di andartele a studiare 'ste cose. Ti consiglio il tutorial sui puntatori del buon Ted Jensen. Un'ottima risorsa. 



In C, una cosa e` int *p, e una cosa e` int (*p)[n]. Il secondo NON e` un puntatore al primo elemento di un array di int, ma un PUNTATORE AD ARRAY DI n INT. Significa che l'aritmetica su quel puntatore usera` sizeof(array-di-n-int) e non di sizeof(int). Te lo vuoi schiaffare nella testa una volta per tutte che, in C, una cosa e` un array, una cosa e` un puntatore, una cosa e` un puntatore-a-T e una cosa e` un puntatore-ad-array-di-T? Capire questi concetti e` FONDAMENTALE per saper programmare in C. 



L'allocazione dinamica della memoria o quello che il programmatore saprebbe o non saprebbe della memoria allocata non c'entrano una beata mazza di niente. 



Buon studio. 


 Ovviamente, la mafia del C e' dura a morire



Tu sei un caso psichiatrico. Ascolta un consiglio: fatti curare.


 Tu sei un caso psichiatrico. Ascolta un consiglio: fatti curare.



E tu non non hai senso dell'umorismo

Che sei un  robot ?





-- 

|___|




Il 14/02/23 04:06, Una mamma ha scritto:


Invece che continuare a giocare alla professoressa del so tutto io e gli 

altri non sanno una cippa per cui e' giusto insultarli rispondi a quello 

che ho affermato

E' o no un puntatore al primo elemento di un array ?

E se non lo e' a cosa punta ?



-- 

|___|




 S.non era obbligato a basarsi sul C, e'stata una sua scelta 



Ovvio, quel giorno poteva anche andarsene al mare. Invece ha deciso che avrebbe creato un linguaggio con compatibilita` verso il basso con il C, e quindi DOVEVA implementare i puntatori. Non e` stata una SCELTA, e` stato un OBBLIGO dovuto alla necessita` principale di essere compatibile verso il basso.



Tu ti rendi conto che tutta questa sequela di elucubrazioni folli da parte tua e` partita dal fatto che hai affermato che i puntatori NON sono nel C++ per compatibilita` verso il basso, vero? Cosa che ti viene smentita dalla mano stessa di Stroustrup.



Continuerai ancora a replicare, continuando a fare figuracce, o ti fermi qui?


 E se non lo e' a cosa punta ? 



Ti e` stato spiegato. Ti e` stato postato il codice. Ti e` stato fatto il disegno. Ma davvero tu hai delle capacita` di comprensione cosi` lacunose? Fatti vedere da uno bravo, ragazzo.



Se dichiari int *p e se dichiari int (*q)[], quel q NON E` un puntatore al primo INT di un array, e` un PUNTATORE AD ARRAY DI INT. 



Questo codice:



#include <stdio.h>

#include <stdlib.h>



int main() {



    double (*v)[3] = malloc(100 * sizeof *v);



    printf("%ld\n", sizeof v);

    printf("%ld\n", sizeof *v);



    return 0;

}



genera, sulla mia macchina, 8 e 24. Chiediti il perche`. VAI A STUDIARE, PORCODDIO!!!!!


 } 



Guarda che non sono "gli altri" che non sanno un cazzo. SEI TU CHE NON SAI UN CAZZO!!!! VAI A STUDIARE!!! MANAGGIAASSANGENNARO!


Il 14/02/23 12:00, Una mamma ha scritto:


Non e' questo a cui mi riferivo

E smettila di considerare i tuoi interlocutori come degli ignoranti

Io so benissimo la differenza tra un puntatore ad un array ed un 

puntatore ad un primo elemento di un array

E' inutile che fai finta di postare codice su cui non ho mai messo parola



-- 

|___|




 Continuerai ancora a replicare, continuando a fare figuracce, o ti fermi qui?



-- 

|___|




 I puntatori si 



E di quello si stava parlando. Punto. Il resto delle tue cazzate (struct e puttanate varie) stanno a zero. Si sa benissimo che il C++ non e` al 100% compatibile con il C. Non e` questo il punto. La questione era se i puntatori, in C++, sono rimasti per un'esplicita scelta progettuale. No, non c'era scelta. La necessaria compatibilita` con il C non lasciava scelta. 

PUNTO. 



Ora dacci un taglio con le tue elucubrazioni stupide che servono solo a stracciare le palle.


 E smettila di considerare i tuoi interlocutori come degli ignoranti 



Non "i miei interlocutori", TE e quell'altro. E lo sai perche`? Perche` DIMOSTRATE di essere degli IGNORANTI con quello che scrivete. 



No, tu la differenza tra puntatore ad array e puntatore al primo elemento di un array non la conosci affatto, cosi` come non conosci la differenza tra puntatore ed array, altrimenti non staresti a stracciare le palle da settimane confondendo le acque con puttanate e buttandola in caciara. Non hai idea che in C esiste un fenomeno chiamato "array decay", te l'ho dovuto insegnare io ("eh, no, non decade una mazza... bla bla"), non hai idea della differenza tra pointer-to-array-of-T e pointer-to-T.  E fai pure lo sborone arrogante... "non mandarmi il CV"... ma vai a cagare e vai a nasconderti! VATTI A STUDIARE LE BASI!!!


Il 14/02/23 15:02, Una mamma ha scritto:


Pretendo, visto le varie offese alla mia persona, una risposta 

sull'argomento che ha a che fare  sull'argomento aritmetica su puntatori 

che non puntano al primo elemento di un array

Altro, non mi ci metto a seguire le tue elucubrazioni







-- 

|___|




 che non puntano al primo elemento di un array 



Non esiste nessun argomento "aritmetica su puntatori che non puntano al primo elemento di un array". Mettiti l'anima in pace e VAI A STUDIARE.


l'argomento aritmetica su puntatori 



...pero`, visto che mi sento in uno stato d'animo molto magnanimo, ti prometto che se sei in grado di formulare una risposta che abbia un capo e una coda, con un linguaggio tecnico corretto, ti rispondo. Pensa un po' a che punto si arriva!


 .... ti prometto che se sei in grado di formulare una risposta



e.c.: "una domanda". La tua confusione e` contagiosa :)


Il 15/02/23 02:35, Una mamma ha scritto:


Beata pazienza

Hai sempre offeso la mia persona basato sul nulla  ma non  hai risposto 

alla domanda e continui ancora a svicolare nonche ad offendere





double d=...;

unsigned char* p=(unsigned char*) &d



A che punta p ?

1) Ad un singolo unsigned char

2) Ad un double

3) Al primo elemento di un array formato da un unsigned char

4) Al primo elemento di un array formato da sizeof(double) unsigned char

5) Al primo elemento di un array formato da un numero sconosciuto di 

elementi ma di tipo unsigned char

6) Ad una funzione

7) A una struct

8) A una union

9) Ad un array

10) A una misteriosa struttura

11) ad una area di memoria che non e' una struttura conosciuta

12) altro



basta solo premere un tasto numerico o due per rispondere











-- 

|___|




 A che punta p ?



ancora? cristo che palle.

lo dice la definizione, un puntatore contiene l'address di un'altra 

variabile dello stesso tipo. quindi punta ad un unsigned char.



che sia il "primo elemento di un array" è una cosa che ti racconti te 

nella tua testa per spiegarti in modo figurato l'aritmetica dei puntatori, 

niente di male per carità ognuno in testa sua si fa i film che vuole, ma 

non puoi mica scartavetrare lo scroto agli altri sostenendo che è un 

concetto formalmente corretto. lì non ci sono array e un double non è un 

array di unsigned char. 




Allora, ascolta enoquick, perche` oggi mi sento in uno stato di grazia: ti chiedo innanzitutto scusa degli insulti. Hai ragione, non servono. Ma devi capire una cosa: quando una persona continua a ribadire gli stessi concetti per giorni, settimane, dopo che l'errore nei suoi ragionamenti gli e` stato spiegato 1, 10, 100 volte, ammetterai che la pazienza scappa anche a Gandhi. Se ci aggiungi che tu, poi, lo fai in maniera spocchiosa ed arrogante, capirai che l'insulto ci sta tutto (non "basato sul nulla", ma "basato sul fatto che continui a scartavetrare i coglioni da tempo senza riuscire ad ammettere che hai torto").

Pero` hai ragione: evitiamo gli insulti e concentriamoci sul punto tecnico. 



Lo sai che cosa succedera`, adesso che mancano gli insulti? Che non cambiera` niente: la discussione sara` esattamente la stessa, con me che cerchero` di insegnarti concetti fondamentali sul C, e tu che continuerai a cercare di divincolarti portando la discussione su temi che NULLA hanno a che vedere con la questione originale. Stai a guardare, eh?



Dunque: 



double d=...;

unsigned char* p=(unsigned char*) &d



In quel codice, tutto quello che c'e` e` un double e un puntatore ad un unsigned char.



Punto. 



Non c'e` nessun array. Perche` ci sia un array, devi definirlo come array. 

Il fatto che la memoria occupata da quel double *possa essere vista* come un array e` tutto un altro discorso. Tanto e` vero che la notazione p[1] serve solo a semplificare la notazione *(p+1) — ma p e` sempre un puntatore, non un array.



Affermare "l'aritmetica dei puntatori funziona solo sugli array" e` errato, perche` l'array e` un tipo specifico del C, e quando una variabile di quel tipo manca nel codice, l'aritmetica dei puntatori e` ugualmente utilizzabile. Come detto piu` e piu` volte in questo thread, l'aritmetica dei puntatori prescinde totalmente dalla presenza o meno di un array. 



Allora tu fai il furbastro e aggiungi: "eh, ma se un array e` una sequenza di dati contigui e quel double e` una sequenza di byte, allora quel double e` un array di byte". Sbagliato. E` un sillogismo errato e confusionario. Anche un'automobile la posso vedere come una grossa scatola di scarpe con quattro grosse rotelle Haribo. Quel double e` un double, e nel codice non esiste alcun array.



Se quello che stai cercando di affermare e` che l'aritmetica dei puntatori vale solo laddove ci sia memoria puntabile tramite avanzamenti del puntatore, allora stai semplicemente buttando fuori un'ovvieta` che piu` ovvia non si puo`. La premessa dell'aritmetica dei puntatori e` che quell'aritmetica si possa compiere!



Hai affermato "per per un puntatore ad array e` un puntatore al primo elemento di un array", ed anche questo e` sbagliato. E bada che questo e` un errore che non farebbe neanche una persona con 1 anno di esperienza in C. Un puntatore ad array e` una cosa; un puntatore al primo elemento di un array, UN'ALTRA cosa. Anche questo ti e` stato profusamente spiegato con codice, disegnini, nonche` riferimenti allo standard del linguaggio (che tu ritieni aumenti la confusione nelle persone e vorresti "interpretare"... pensa un po' te).



Hai affermato che "il nome di un array e` un puntatore costante" e che "non decade una mazza" ed anche questo e` sbagliato. Ti ho dimostrato che il nome di un array decade nel puntatore al suo primo elemento in tutti i casi meno tre specifici. Si chiama "array decay" e, come dice Stroustrup, e` fondamentale comprenderlo per scrivere codice C e C++ corretto. Se quello che affermi tu fosse vero, in questo codice:



int a[] = {1, 2, 3};

int b[] = {1, 2, 3, 4};



"sizeof a" sarebbe il sizeof di un puntatore costante a int, ovvero sizeof(int*), ovvero 8 byte sulla mia macchina. Invece non e` cosi`. Vale 12.

E "sizeof b" vale 16. Chiediti il perche`. 



Quando scrivi char a[] = "abc", quel "abc" NON e` un char*, ma un array di caratteri, del tutto equivalente a {'a', 'b', 'c', '\0' }.



Ora, mi raccomando, continua a rispondere con i tuoi "ho detto la stessa cosa", i "volevo dire", i "secondo me", i "interpreto lo standard", ecc..


Il 15/02/23 15:15, rootkit ha scritto:


Mi stupisco che una persona che non e' che sia esperta viene a fare le 

pulci pretendendo in modo arrogante di avere ragione a chi ne sa piu di 

lui invece che dare una semplice opinione

Poi,non sei obbligato a seguire ed in piu la cara guru del C ha sempre 

svicolato sulla risposta

Essendo stato,senza motivo, offeso piu volte da quella signora pretendo 

le giuste risposte

E poi e' la signorina che ha iniziato non io

L'aritmetica dei puntatori in C ha senso usarla solo con gli array

In tutti gli altri casi  non ha senso, al contrario delle sparate della 

cara signora

Ed infatti non mi ha fatto vedere nessun esempio concreto che quello che 

afferma sia vero, continua a svicolare ed offendere

E non puo neanche farlo un esempio sensato perche non esiste

Quindi invece che venire a fare sparate di questo tipo magari impara 

qualcosa sul C prima







-- 

|___|




 







In C un  array per utilizzarlo non  si e'  obbligati a dichiararlo

Questo perche un array non e' solo un tipo che e' possibile dichiarare, 

e' anche una definizione (un area di memoria di N elementi di tipo T 

contigui)

Ecco perche ha senso vedere come array una determinata area di memoria 

del tipo T che voglio (basta che il puntatore sia di tipo T*)

Le scuse sono accettate



[CUT]





-- 

|___|




 Ed infatti non mi ha fatto vedere nessun esempio concreto 



Ti ho fatto una caterva di esempi: descritti e in codice. Il problema e` che o non vuoi o non hai una competenza sul C tale da farti comprendere quegli esempi. 



Mi spiace, ma se non sei in grado di capire quel che ti viene detto, non e` una mia responsabilita`.


 In C un array per utilizzarlo non si e' obbligati a dichiararlo 



Continui a mancare il punto. Un array e` un tipo specifico del C, con una semantica specifica. Ed e` proprio in virtu` di quel tipo e semantica che un puntatore-ad-array-di-T e` una cosa, e un puntatore-a-T e` un'altra cosa. 



Quoto dal messaggio precedente: 

"Allora tu fai il furbastro e aggiungi: "eh, ma se un array e` una sequenza di dati contigui e quel double e` una sequenza di byte, allora quel double e` un array di byte". Sbagliato. E` un sillogismo errato e confusionario. Anche un'automobile la posso vedere come una grossa scatola di scarpe con quattro grosse rotelle Haribo. Quel double e` un double, e nel codice non esiste alcun array.

Se quello che stai cercando di affermare e` che l'aritmetica dei puntatori vale solo laddove ci sia memoria puntabile tramite avanzamenti del puntatore, allora stai semplicemente buttando fuori un'ovvieta` che piu` ovvia non si puo`. La premessa dell'aritmetica dei puntatori e` che quell'aritmetica si possa compiere!"



Le affermazioni:

"L'aritmetica dei puntatori si usa solo con gli array" e` sbagliata. 

"Un puntatore ad array e` un puntatore al suo primo elemento" e` sbagliata.

"Il nome di un array e` un puntatore costante" e` sbagliata. 



Continui a sbagliare. Ti consiglio di ristudiare i concetti di base. Tranquillo, che il pisello non ti si accorcia se lo fai.




Il 15/02/23 18:24, Una mamma ha scritto:


Ti ho gia dato esauriente risposta

Faccio qualche aggiunta



T* p;



++p; //p ora punta all'elemento successivo

p = p + 3; //p ora punta all'elemento 4 passi piu avanti dall'inizio



p = p - N



Ora, quale e' quella struttura per cui ha senso avere operazioni di 

questo genere ?

Ce ne solo una in C e si chiama array

Perche un array non e' solo una dichiarazione,e' anche una visione del 

programmatore

Se non accetti questo fatto occorrerebbe dare un senso a quello che 

punta p sia come singolo che come struttura

E la cosa bella e' che il senso lo ha,ed e' logico e coerente

Lasciamo il tutto alla magia o diamo un senso alle cose ?



Altro esempio:





struct S {

	//alcuni dati

	T codes[1];

};





Questo e' un  modo per avere una struttura con dati di numero variabile 

in coda tutti di tipo T





struct S* p=malloc(sizeof(struct S) + sizeof(T) * K);   // ora p punta 

ad una struttura con in coda K + 1 elementi di tipo T





p->codes[0]=...

p->codes[1]=...  //nonostante l'array sia stato dichiarato di un solo 

elemento questo codice e' corretto e non va fuori memoria se K > 0

p->codes[2]=...  //idem per K > 1

....





Se si dovesse accettare che un array lo si e' solo per dichiarazione 

quel p->codes[1]=... non sarebbe logicamente valido perche l'array codes 

ha un solo elemento

Ma non e' cosi, questo codice e' valido e viene comunemente usato per 

problemi di questo tipo



































-- 

|___|




 



L'aritmetica sui puntatori non e' imposta dal linguaggio solo su 

determinate strutture

Si puo usare sempre, il linguaggio non lo impedisce

Ovviamente un conto e' usarla con senso logico e corretto, altro fare 

pasticci





[CUT]





La

-- 

|___|




 tutti gli altri casi  non ha senso, 



quindi in pratica: con il tuo esempio dove non esistono array (non l'hai 

mica smentito) volevi dimostrare che la tua affermazione "punta al primo 

elemento di un array" non ha senso? ben venga, ma fai pace con te stesso. 



 





L'array c'e ma non lo vedi come dichiarazione

Questo e' il C, non e' java

In C l'array non e' solo una dichiarazione di un tipo ma anche un 

concetto mentale (un' area di memoria di N elementi di tipo T contigui)



Se sai cose e' una union:



union {

	double d;

	unsigned char v[sizeof(double)];

};





assert(&d == &(v[0])) //i due indirizzi coincidono



Adesso l'array lo vedi

La dichiarazione di questa struttura puo essere abbreviata con questo 

codice equivalente



double d=...;

unsigned char* p=(unsigned char*) &d;

e poi iterare con p come su v



Ma se un array avesse senso solo se dichiarato come chiamiamo la 

struttura (mentale) a cui punta p ?

Per me la si puo chiamare anche pincopallo

Pincopallo ha la stessa semantica degli array sull'uso  ma non e' un array

Benissimo,ma se ti capita di fare un esame di C all'universita o alle 

medie superiori, spiega al prof che cosa e' un pincopallo mi raccomando

Nonche il cambio dei libri sul C che includano la nuova struttura

Oltre a struct,union ed array includiamo anche pincopallo



Pensavo che dopo gli array non contigui (che non esistono in C,gli array 

sono sempre contigui per specifica dello std) di averle viste tutte





-- 

|___|




++p; //p ora punta all'elemento successivo



Dato quello che hai scritto, non esiste nessun "elemento successivo". 

Esiste solo un puntatore, il quale potrebbe benissimo puntare ad un solo elemento:



int a = 2;

int *p = &a;



Dove sarebbe l'elemento successivo? Tutto quello che si deduce, da un puntatore, e` che e`... un puntatore. 



E` solo quando allochi memoria dinamicamente che POTRESTI avere "elementi successivi". 



Ma veniamo al punto che ti smentisce: tu affermi "l'aritmetica dei puntatori si usa solo con gli array". E` sbagliato. La frase corretta e` "l'aritmetica dei puntatori si usa solo per navigare, avanti e indietro, su una porzione di memoria", il che e` abbastanza ovvio. Quella porzione di memoria, pero`, potrebbe benissimo non contenere ALCUN array.



Te lo dimostro: immagina di leggere pacchetti da una sorgente esterna. Ti arrivano blocchi da 8K che devi interpretare. Sai solo che tipo di dati possano arrivarti, ma in quale ordine lo ignori. Il "parsing" del blocco si basa su identificatori di cio` che segue: per esempio, nel caso tu stia decomprimendo con algoritmo di Huffman, potrebbe dirti che quello che stai per leggere e` l'albero binario usato durante la compressione o magari c'e` alcun albero: bene, lo leggerai e avanzerai il puntatore di tanti byte quanti ne occupa l'albero. Poi, pero`, leggi un identificatore che ti dice che quello che segue nel buffer e` un codice di Huffman, quindi lunghezza e bit, quindi allocherai memoria per il tipo:



typedef struct {

  short int length;

  unsigned char bits[64];

} huffman_code_t, *huffman_code_ptr;



E tratterai, a quel punto, il puntatore avanzato per aritmetica, come un huffman_code_ptr, per il quale allocherai memoria sizeof(huffman_code_t), leggerai il valore nel buffer, e aumenterai il puntatore di 1. E cosi` via, di volta in volta usando l'identificatore incontrato per sapere come castare il "puntatore cursore", avanzato per aritmetica, su un tipo specifico legato all'identificare, e usando come scalare il sizeof di quel tipo. 



Dove lo vedi l'array? E` solo una sequenza eterogenea di dati: [header del file compresso][albero di compressione][identificatore][codice di Huffman][identificatore][codice di Huffman] etc... 



Ti potrei fare altri esempi, per esempio un buffer che contenga legal entities e persone associate, in maniera variabile: [type_id][legal entity][type_id][person][type_id][person][type_id][legal entity]... etc... Non esiste nessun array, eppure l'aritmetica dei puntatori si usa benissimo. 



La frase "l'aritmetica dei puntatori si usa solo con gli array" e` ERRATA.






 L'aritmetica sui puntatori non e' imposta dal linguaggio solo su determinate strutture 



Infatti. Ma questo e` l'opposto di quello che avevi scritto tu: "l'aritmetica dei puntatori si usa solo con gli array". Mettiti d'accordo con te stesso. 


 struttura (mentale) a cui punta p ? 



p non punta ad alcuna "struttura mentale". Tu stai considerando solo un caso specifico, ovvero quando la memoria contiene una sequenza di T contigui, ma l'aritmetica dei puntatori si puo` applicare anche laddove la struttura della memoria sia eterogenea. Non serve che esista un array. Come gia` detto almeno DIECI volte qui dentro, l'aritmetica dei puntatori prescinde totalmente dalla presenza o meno degli array, il che non vuol dire affatto che NON si usi laddove ci sia un array allocato dinamicamente.


Posto un altro esempio per spiegare perche` si e` in errore quando si afferma "l'aritmetica dei puntatori si usa solo con gli array":



#include <stdio.h>

#include <stdlib.h>

#include <string.h>



void write_buffer(void *p, const char *pattern) {

    void *cursor = p;

    for (size_t i=0; pattern[i]; i++) {

        if (pattern[i] == 'd') {

          double d = (double)(rand() % 50) / (rand() % 5 + 1);

          memcpy(cursor, &d, sizeof d);

          cursor = (double*)cursor + 1;

          printf("d = %5.2f\n", d);

        } else if (pattern[i] == 'i') {

          int i = rand() % 50;

          memcpy(cursor, &i, sizeof i);

          cursor = (int*)cursor + 1;

          printf("i = %d\n", i);

        }

    }

}



void read_buffer(void *p, const char *pattern) {

    void *cursor = p;

    for (size_t i=0; pattern[i]; i++) {

        if (pattern[i] == 'd') {

          double d;

          memcpy(&d, cursor, sizeof d);

          cursor = (double*)cursor + 1;

          printf("d = %5.2f\n", d);

        } else if (pattern[i] == 'i') {

          int i;

          memcpy(&i, cursor, sizeof i);

          cursor = (int*)cursor + 1;

          printf("i = %d\n", i);

        }

    }

}



size_t size_to_alloc(const char *pattern) {

    size_t total = 0;

    for (size_t i=0; pattern[i]; i++) {

        if (pattern[i] == 'd') {

            total += sizeof(double);

        } else if (pattern[i] == 'i') {

            total += sizeof(int);

        }

    }

    return total;

}



int main() {

    const char *pattern = "ididddiiididiididddiiididi";



    void *p = malloc(size_to_alloc(pattern));



    printf("\nWriting...\n");

    write_buffer(p, pattern);



    printf("\nReading...\n");

    read_buffer(p, pattern);



    return 0;

}



Output sulla mia macchina:



Writing...

i = 33

d = 12.00

i = 15

d = 43.00

d = 12.00

d = 24.50

i = 12

i = 27

i = 40

d =  2.25

i = 26

d = 20.00

i = 22

i = 36

d =  2.75

i = 17

d =  9.67

d = 10.00

d =  7.67

i = 35

i = 29

i = 2

d =  5.50

i = 19

d =  4.25

i = 6



Reading...

i = 33

d = 12.00

i = 15

d = 43.00

d = 12.00

d = 24.50

i = 12

i = 27

i = 40

d =  2.25

i = 26

d = 20.00

i = 22

i = 36

d =  2.75

i = 17

d =  9.67

d = 10.00

d =  7.67

i = 35

i = 29

i = 2

d =  5.50

i = 19

d =  4.25

i = 6



L'aritmetica dei puntatori prescinde totalmente dalla presenza di un array.


 elemento di un array" non ha senso? ben venga, ma fai pace con te stesso.



Be`, dai, non e` nuovo a queste contraddizioni. Ha affermato che i puntatori, in C++, non esistono per compatibilita` verso il basso, poi si e` smentito due messaggi dopo. 



Purtroppo non ha sufficiente esperienza con il C per capire quel che sto dicendo, ma e` una cosa molto comune, soprattutto tra i vecchi programmatori, che pensano di aver visto tutto e di sapere tutto. Persino su una cosa banale come l'array decay, lui crolla. Ha affermato "il nome di un array e` un puntatore costante" e che "non decade una mazza". Quindi, secondo lui, quando si scrive: 



int a[] = {1, 2, 3};

size_t x = sizeof a;



Per lui x dovrebbe contenere la dimensione di un puntatore costante a int, ovvero sizeof(int). Cosa non vera. Proprio perche` in questo caso il nome dell'array NON decade in puntatore al primo elemento. Capire la differenza tra array e puntatori e` fondamentale in C.



Lui si sforza di vedere array dove non ci sono e ignora gli array dove ci sono. :shrug:


 



Vediamo un po se ho capito bene:





struct S {

	int typeid;

	long legal_entity;

};



struct S* s=malloc(sizeof(struct S));

int* p1=&(s->typeid);

++p1; //il typeid e' visto come un array di un solo elemento ma ora p1 

punta a legal_entity se non ci sono buchi tra typeid e legal_entity

long v = *((long *) p1)); //ora v contiene il valore di legal_entity



In pratica ogni volta che si usa una operazione aritmetica tra puntatore 

ed intero si passa a puntare all'elemento successivo (tanti bytes in 

avanti a seconda della size del tipo puntato) dell'array di cui fa parte T

E ricordo che in C/C++ puntare subito oltre all'ultimo elemento di un 

array non e' un UB, e' legale farlo (e' solo illegale accedervi)

Poi quel puntatore nessuno mi obbliga a vederlo dello stesso tipo T, 

faccio un cast e inizio con un nuovo array anche di un solo elemento





Comunque nella pratica non farei un codice di questo tipo (forse solo in 

casi molto particolari) perche non portabile

Tra typeid e legal_entity protrebbero esserci buchi (tecnicamente 

padding) dovuto all'allineamento alla word dei vari campi della struttura

Oppure, per essere sicuro uso una struttura packed



struct __attribute__((__packed__)) S {

};



Ma non e' portabile, quel __attribute__ e' per gcc









-- 

|___|




 Comunque nella pratica non farei un codice di questo tipo 



Ti si sta cercando di spiegare il concetto che l'aritmetica dei puntatori non necessita della presenza di array. La portabilita` non c'entra.


 >> variabile dello stesso tipo. quindi punta ad un unsigned char. 



Esatto, e PUNTO. Punta a quello e basta. Ha avuto il coraggio di dire che ++p punta all'elemento successivo. Quale elemento successivo?



Se io ho:



T a;

T* p = &a;



Quale elemento successivo esiste in memoria? Pur di sostenere il suo punto di vista balzano che l'aritmetica dei puntatori si usa solo con gli array, e` capace di finire in questi assurdi. Tutto quello che si puo` dire di ++p e` che punta alla locazione di memoria che segue il blocco di memoria in cui risiede quel T. Punto.



In un'area di memoria contenente un int, seguito da un double, seguito da un int, seguito da un double, un int *p che punti all'int iniziale, a quale "elemento successivo" dovrebbe mai puntare con un ++p? Non esiste un nuovo int. Esiste un double, che si puo` leggere con un (double *), il quale, incrementato di 1, non punta al "double successivo", ma ad un int, ecc... ecc... 



Quale programmatore serio avrebbe mai il coraggio di dire: eh, vabbe`, ma quella memoria e` una sequenza di array di 1 elemento: int[1], double[1], int[1], double[1]. Ma anche se si dicesse una cosa del genere (cosa che farebbe ridere anche le pietre), comunque l'incremento del puntatore di 1 non porta ad un nuovo elemento dello stesso tipo.



Il fatto e` che quello che dice non sta ne` in cielo ne` in terra, e la cosa preoccupante e` che e` del tutto incapace di rendersene conto.


 Ti si sta cercando di spiegare il concetto che l'aritmetica dei puntatori non necessita della presenza di array. La portabilita` non c'entra.



Era solo una precisazione

Se non l'avessi scritto qualcuno avrebbe potuto farmelo notare e poi 

tirare fuori la solita storiella che il sottoscritto non conosce il padding

Meglio mettere le mani avanti quando mi ricordo di farlo



-- 

|___|




 p non punta ad alcuna "struttura mentale". Tu stai considerando solo un caso specifico, ovvero quando la memoria contiene una sequenza di T contigui, ma l'aritmetica dei puntatori si puo` applicare anche laddove la struttura della memoria sia eterogenea. Non serve che esista un array. Come gia` detto almeno DIECI volte qui dentro, l'aritmetica dei puntatori prescinde totalmente dalla presenza o meno degli array, il che non vuol dire affatto che NON si usi laddove ci sia un array allocato dinamicamente.





Se accetti il concetto che un array puo essere anche una costruzione 

mentale del programmatore ti accorgerai che quando usi una aritmetica su 

un pointer l'area di memoria corrispondente e' sempre vista come un 

array anche di un solo elemento (e' legale avere un array con un 

elemento solo) se necessario



int* p=....

++p; //punta all'int successivo



Poi il programmatore ci pensa bene, li c'e un long non un int

OK

long* pl=(long*) p;

// e si va avanti, per il programmatore prima di fare il cast li c'era 

un array con un solo int (questo perche ha usato operator ++ sul 

pointer) quindi p punta una posizione oltre l'ultimo elemento di un 

array (perfettamente legale in C)

L'array e' finito, ora il programmatore vede l'elemento corrente come un 

long (o il primo elemento di un  array di long)









-- 

|___|




Meglio mettere le mani avanti quando mi ricordo di farlo



Si chiama coda di paglia :) E c'e` un motivo :)


 array (perfettamente legale in C) 



Perfettamente legale ma non punt all'elemento successivo. 



Ma scusa, tu pensi davvero di poter usare un argomento del genere parlando di C?

"Quello che sto leggendo e` un array; ah no, e` un valore singolo; eh be`, allora era un array di un solo elemento". Ma una cosa del genere dove l'hai vista scritta mai? Dove l'hai letta? Dove l'hai imparata? Come ti viene in mente di pensarla? 



Incredibile.


 Si chiama coda di paglia :) E c'e` un motivo :)





Non c'e nessuna incongruenza

E' perfettamente dimostrato sopra



-- 

|___|




Ma se per te non e' un array alla visione del programmatore che dichiara int* p=malloc(sizeof(int) * N); lui vede una sequenza contigua di N int. Che nome gli dai a questa struttura ?



Ancora? Continui a non capire. Io non ho mai affermato che l'aritmetica dei puntatori non si usi su array allocati dinamicamente. Io sto ribattendo alla tua affermazione "l'aritmetica dei puntatori si usa SOLO con gli array". Cosa palesemente FALSA. Hai bellamente ignorato un intero programma che ti ho postato e che ti dimostra che sei in errore. Ma non preoccuparti, non sfuggi, te lo riposto.



In questo codice, quale array ci vedi? Avanti, spiegalo. 


    const char *pattern = "idididididididididididid";



    void *p = malloc(size_to_alloc(pattern));



    printf("\nWriting...\n");

    write_buffer(p, pattern);



    printf("\nReading...\n");

    read_buffer(p, pattern);



    return 0;

}



Stai scrivendo un mare di roba o imprecisa, o errata. Io ti invito calorosamente a ristudiarti i concetti di base del linguaggio. Il tuo e` un vero caso di effetto Dunning-Kruger.


 Stai scrivendo un mare di roba o imprecisa, o errata. Io ti invito calorosamente a ristudiarti i concetti di base del linguaggio. Il tuo e` un vero caso di effetto Dunning-Kruger.





In alloc(const char* pattern) il programmatore vede pattern come un 

puntatore ad un elemento di un array di char ed esce quando trova \0

Dove sta la cosa strana ?

Perche pattern non dovrebbe essere visto cosi ?



Tra l'altro nel main() pattern (che non e' il pattern in alloc,sono due 

cose differenti)

viene dichiarato come puntatore ad una stringa  (quindi puntatore al 

primo elemento) e mi risulta che una stringa  non sia altro che un array 

di char con un elemento in piu che e' lo \0 finale che il compilatore 

aggiunge in automatico



Infatti:



const char s[]="abc";



sizeof(s) ritorna 4





Dove sta la cosa strana ?



Tra l'altro fare

const char* p="abc";

e' equivalente a

const char s[]="abc";

p = s;

con la differenza che in questo caso l'array ha un nome, nel primo caso 

no (p non e' un array)







-- 

|___|




viene dichiarato come puntatore ad una stringa 



"Puntatore a stringa" non esiste, in C. E se definisci una stringa come un "array di char", allora stai ricadendo nello stesso error: "Puntatore a stringa" significherebbe "puntatore ad array di char". NON E` COSI`. Una cosa e` puntatore-ad-array-di-char, una cosa e` puntatore-a-char. Compi continuamente gli stessi errori. E` incredibile. 



In ogni caso, non e` `pattern` al centro della questione, ma la memoria allocata. Non svicolare. 



Quale array vedi in:



void *p = malloc(sizeof(double) + sizeof(int) + sizeof(double) + sizeof(int));



Spiega.


 Spiega.



Io  vedo un void* e basta,perche mai dovrei vedere un array ?

E' il programmatore che usera il void* della malloc a decidere cosa fare



-- 

|___|




Io vedo un void* e basta,perche mai dovrei vedere un array ?



Vatti a studiare il codice che ho postato. Su su, fai muovere la gambine e torna solo dopo che l'hai capito.


 Vatti a studiare il codice che ho postato. Su su, fai muovere la gambine e torna solo dopo che l'hai capito.





Tu hai postato una malloc e basta

Cosa devo vedere da una malloc ?



Oltre all'esempio dell'int32 che non hai commentato ecco qui due vere 

bellezza:







char s[]="ab\FF\FF\FF\FF";



questa e' una stringa, penso che fino a qui non ci siano dubbi

Ma il programmatore puo fare di piu

Puo vedere una sequenza composta da 3 array di tipi diversi tra gli 

stessi array

Il primo array ha due elementi di tipo char { 'a','b'}

Il secondo array ha due elementi di tipo int16_t { -1,-1}

Il terzo e' un array composto da un  solo elemento di tipo char { '\0'}





Oppure una stringa pascal che puo essere vista in almeno tre modi:





struct pascal_string __align__(packed) {

	size_t sz;

	char a[1]; //la vera size dipende  sz

};





char string_pascal[]={'\0','\2','a','b'};  //una stringa pascal in cui 

la lunghezza e' un int16_t in big endian





char string_pascal=[]="\0\2ab";  //i primi due caratteri formano la 

lunghezza sempre int16_t in big endian



Ora,queste sono modi differenti di trattare una stringa pascal anche se 

gli ultimi due in realta sono la stessa cosa (sono 2 array)

IL programmatore puo, negli ultimi due casi, spezzare l'array o la 

stringa C come desidera



struct pascal_string* ps=malloc(7);



memcpy(ps,"\0\0\0\2ab"); //inizializza la stringa pascal ad ab - assume 

che un  size_t occupi 4 bytes e l'architettura sia big endian



size_t sz=ps->sz; //modo classico per ottenerne la size



size_t sz1=*((size_t*) ps); //modo piu complicato ma sempre valido 

rispetto alle assunzioni fatte



char* pc=ps->a; //modo classico per vedere l'inizio dei caratteri della 

stringa



char* pc1=(char*) (((size_t*) ps) + 1); //modo complesso per vedere 

l'inizio dei caratteri della string ma sempre valido

Il programmatore vede l'inizio dell'area di memoria della struct come un 

array di size_t e con un solo elemento perche usa un RI



E questi giochetti si possono fare per qualunque memoria si tratti, heap 

stack o globale

Non c'e differenza nel trattamento



Notare come tutto torna e non ci sia incongruenza in quello che ho spiegato

Al contrario tuo che assumi che solo il ritorno di una malloc puo essere 

usata come un array e che non possa esistere un array con un elemento 

solo, almeno come vista da parte del programmatore (chissa perche poi)

Mettiti in testa che il C e' un  assembler portabile, si puo fare quasi 

tutto quello che si fa in assembler (ovvero tutto tranne le syscall,la 

gestione degli interrupt,i memory lock e forse qualche altra cosa che 

ora non mi viene in mente)



































-- 

|___|




Al contrario tuo che assumi che solo il ritorno di una malloc puo essere

usata come un array e che non possa esistere un array con un elemento

solo



Ma cosa cazzo stai dicendo! Non hai capito una mazza di quello che ho scritto! 



Mettitelo TU in testa che in C le cose NON funzionano come pensi, e vatti a studiare i concetti di base, che sei bello confuso. 



Continui a scrivere mare di cazzate e a ripeterti il mantra del "tutto torna", quando non torna un bel niente nei tuoi ragionamenti. Purtroppo e` chiaro che non hai le capacita` per capire quel che gli altri scrivono, non hai le competenze di base per parlare di C, ti piace per partire per tangenti che NULLA hanno a che vedere con gli argomenti trattati, e saresti in grado di far perdere la pazienza pure a Gandhi. 



Sei nel torto piu` marcio, ma ti lascio perdere, perche` fai ridere e veramente non ne vale la pena. 






 





Disse la volpe guardando l'uva

E prima di andare a dormire studia quel codice che ho postato l'ultima e 

la penultima volta

Cosi potrai apprendere cose che non ti immaginavi possibile fare in C





-- 

|___|




 siamo tutti dei topi da pc o da biblioteca



no vabbè ma imho non stai volendo vedere l'eterogeneità 

mostruosa di esigenze e di risorse che esiste qua fuori.

Non sto dicendo che qualche teoria impedisca che un giorno 

non possa emergere un linguaggio simile, semplicemente che 

al momento pare davvero molto lontano.

E nel frattempo accadrà altro di più urgente (come l'ascesa 

delle IA, che renderanno urgente imparare ad interfacciarsi 

con esse per delegare compiti ripetitivi).



circa le distribuzioni di linux (sono un linuxiano dal 2017 

e mai tornerei indietro), alla sua enorme "variabilità 

biologica" che crea problemi di apprendimento, si associa 

però una caratteristica positiva : è un incubo per chi 

sviluppa malware, non sai mai che cavolo di macchina andrai 

a infettare, con che componenti, configurata come etc. È 

immunità "naturale" questa :D :D :D





-- 

1) Resistere, resistere, resistere.

2) Se tutti pagano le tasse, le tasse le pagano tutti

MarioCPPP




 hai capito ora?



 del C per cui i puntatori sono indispensabili



 





non so se esista ancora, il vecchio C aveva la keyword 

__emit (opcode) per bypassare l'assembler e generare codice 

macchina embedded. Forse era un'estensione, non ricordo. 

Credo siano passati 33 anni dall'ultima volta che ho provato 

a usarla (con esiti variamente catastrofici).



Chiaramente è tra i costrutti MENO PORTABILI in assoluto, e 

ha senso solo se cuci un programma addosso ad un processore 

specifico, anche peggio dei blocchi asm {}.



 "naturale" questa :D :D :D



questo è un assunto abbastanza sbagliato, basti vedere i ransomware quanti 

problemi si fanno quando attaccano una macchina linux.



ma a parte questo, io dico la vastità delle distribuzioni linux 

rappresenta un problema solo per chi si fa la sega mentale di porselo. 

nessuno ha veramente il bisogno di provarne più di una, e tantomeno una al 

di fuori delle 4/5 principali, se lo fa è solo perché ha voglia e tempo di 

farlo. di contro l'estrema vivacità dell'ecosistema non produce solo 

entropia ma anche progetti di eccellenza assoluta.