Newsgroup: it.comp.lang.c++
Titolo: Puntatori

Salve, 
ho una domanda stupida da fare :
per esempio :   
  int* x=new int[100];
x è quindi un vettore di interi.Posso usarlo in questo modo :
x[0]=23;
x[1]=44;
.
.
.
.
x[99]=3465;
a questo punto voglio estendere la capacità di x.
Cioè voglio ad esempio poter usare anche x[120]=38746;
Diciamo che voglio fare in modo che x sia un vettore di 200 elementi ,
cosa dovrei fare , qualcosa del genere ?:
int* y=&(x[100]);
y=new int[100];
in effetti cio funziona (almeno credo), ma non c'è una sintassi che
eviti di usare una variabile temporanea ?

 a questo punto voglio estendere la capacità di x.
Usa il tipo std::vector al posto del puntatore ad int:
#include <vector>
...
std::vector < int > x;
EMG

 eviti di usare una variabile temporanea ?
No, e neppure una che ti eviti di copiare esplicitamente
tutti i contenuti dell'array.  std::vector, invece, puo`
spesso fare sofisticate ottimizzazioni (il costo di N
inserzioni e` ammortizzato a O(N) per un numero di
inserzioni N sufficientemente elevato; usare puntatori
e array dinamici con un allungamento, ad esempio, di
100 alla volta, fa si` che il costo di N inserzioni
sia O(N quadro)).
E` improbabile che tu ti trovi mai nella tua vita
professionale in una situazione in cui std::vector
non e` chiaramente la soluzione migliore rispetto
all'uso di new[].
Alex

eviti di usare una variabile temporanea ?
usa std::vector<>
Paolo

 dovrò vedere come funziona  <vector>.
Buon lavoro, in un caso come nell'altro.  Non sara` poco (anzi,
sara` una quantita` enorme, direi mostruosa, di lavoro, soprattutto
se bisogna aggiungerci anche la necessita` di capire bene alcuni
dei concetti piu` elementari del C++, come il perche` e il percome,
nella sequenza:
    tipo *puntatore = espressione1;
    puntatore = espressione2;
non faccia la benche` minima differenza cosa sia espressione1 se
priva di side-effects).
Alex

 dovrò vedere come funziona  <vector>.
Ecco, è meglio che usi vector. E poi non c'è da vedere come è implementato
ma solo usarlo.
---------
#include <vector>
using namespace std;
vector<int> e(3);    // dichiaro un vettore di 3 int
// lo usi a piacere...
e[2]=e[0]+e[1];
e.resize(6); // lo espandi a piacere
//...
int n=e.size(); // vedi quanti elementi ha
Ciao,
Raffaele

suggerirei di non usarlo.  Che tu non capisca la totale inutilita`,
senz'altro non sono un esperto di c++ e la cosa non mi interessa. Mi
interessava fare un programma sulle reti neurali e l'ho fatto. 
Cio significa che mi sono messo a leggere libri sul c++ man mano che
mi serviva fare qualcosa.Ho imparato a usare le classi, ho imparato a
usare classi template ecc.. Tutto in pochi mesi: e' ovvio che non
sappia alcune cosette sui puntatori.Ho cominciato a usarli non per poi
andare sulle news e offendere, ma perche' ho letto (sul benedetto
Herbert Schildt..)che l'uso dei puntatori sveltisce notevolmente
l'esecuzione del programma. A quanto pare fare *(x++) è meglio che
fare c[1] ... e che è meglio usare un puntatore triplo invece che
usare array del tipo *v[x][y] .Se qualcuno mi chiede come allocare
memoria per int ***********x glielo dico (e' banale) ma poi non
l'offendo.Quindi se dico che non uso una cosa perchè e' oscura e'
perche non so quali operazioni superflue fa .Dato che la ricerca
mediante algoritmi genetici dei pesi delle connessioni tra neuroni è 
abbastanza onerosa in termini di prestazioni , capirai che sono
costretto a usare costrutti di basso livello.
Ho solo chiesto particolari sul c++ a qualcuno piu' esperto (non che
io mi ritenga un esperto) e mi fa piacere che tu mi abbia risposto, ma
dirmi che non dovrei usarlo .... e' esagerato ... chi ti credi di
essere ? ne saprai piu di me sul c++ ma non puoi venirmi a dire di non
usarlo. Sto imparando come avrai fatto anche tu. O sei nato imparato ?

 usarlo. Sto imparando come avrai fatto anche tu. O sei nato imparato ?
Non posso certo IMPORTI di non usarlo, ma altrettanto certamente,
posso DIRTELO, cioe` SUGGERIRTELO.  Tocchera` poi a te trarre o
meno beneficio dai suggerimenti.  Ma non stupirti se, chiedendo
in rete dei suggerimenti, ne ricevi.
Se le tue esigenze in fatto di prestazioni sono poi cosi` stringenti
come ora spieghi, puo` ben darsi che il C++ costituisca la scelta
migliore -- ma solo se usato bene, secondo le modalita` che ti
ho brevemente spiegato.  Se segui ciecamente Schildt, allora stai
pagando tutto il costo della complessita` e difficolta` del C++,
senza trarne i veri benefici.
Quanto a come ho imparato io, sono un tipo insolito: io imparo
soprattutto dai libri.  Poi, certo, anche dalla pratica, ma mi
do` alla pratica solo dopo avere assorbito abbastanza libri su
di un dato argomento, che non e` piu` concepibile un errore
concettuale come quello che hai compiuto verso l'inizio di
questo thread.  No problem, siamo tutti diversi e ognuno impara
meglio a modo suo (chi leggendo, chi sperimentando, chi seguendo
corsi, ecc ecc); ho collaborato fattivamente con "praticoni"
di tutti i tipi, e anche con tizi anche piu` "teoreti" di me.
Raramente, pero`, la collaborazione e` fattiva se l'altro ha
la coda di paglia, e prende le motivate critiche come offese;
non sono particolarmente interessato all'eufemismo e ai giri
di parole -- io dico pane al pane, vino al vino.
Lo faccio quando mi pagano (e bene) per le mie consulenze,
figurati te se non lo faccio quando i consigli li do` gratis!-)
Alex

 usarlo. Sto imparando come avrai fatto anche tu. O sei nato imparato ?
Ciao,
fai bene ad imparare man mano che studi, tutti abbiamo fatto così. Per
quanto
riguarda i puntatori e l'efficienza vorrei darti qualche suggerimento: io ho
scritto
un prog. abbastanza complesso di creazione/estrazione di mesh tetraedrali a
risoluzione variabile (si tratta di visualizzazione volumetrica di dati di
densità in 3D)
e l'estrazione doveva essere abbastanza veloce da consentire la
manipolazione
in tempo reale.
L'ottimizzazione principale è stata data dalla struttura dati utilizzata:
niente può velocizzare
di più di una struttura dati ben progettata.
Le ottimizzazioni tipo *p++ anziché v[i] per iterare vanno bene, sul
puntatore triplo non
sono daccordo. Usa pure vector<> tranquillamente, e anche tutte le altre
strutture dati
della libreria standard, perché sono almeno veloci come i costrutti
primitivi.
Il vector<> è implementato con un normale vettore, e l'operatore [] non
genera codice
aggiuntivo. Puoi iterare anche sui vector:
-----------------------cut-here-------------------------------
#include <iostream>
#include <vector>
using namespace std;
int main(int argc, char* argv[])
{
    vector<int> v(10);
    vector<int>::iterator vi;
    vector<int>::const_iterator vic;
    for(vi=v.begin(); vi<v.end(); ++vi)
        *vi = vi-v.begin();
    for(vic=v.begin(); vic<v.end(); ++vic)
        cout << *vic << endl;
    return 0;
}
-----------------------cut-here-------------------------------
Nel prog. d'esempio vi è un iteratore (tipo un puntatore, e se guardi
l'implementazione è la stessa cosa) a vettore di interi. Puoi assegnarlo,
iterare, ecc come nel primo for.
vic invece è un iteratore const, cioè non puoi modificare ciò che punta ma
solo leggere. Il suo utilizzo consente al compilatore di ottimizzare meglio,
e a te di evitare errori nel programma grazie ad un type checking più forte.
Vedi anche 
www.sgi.com/Technology/STL
 per un'implementazione (la migliore
per me) della libreria standard ed il suo manuale.
Ciao e in bocca al lupo col C++.
Raffaele (RDA)

figurati te se non lo faccio quando i consigli li do` gratis!-)
Allora accetta un suggerimento , non ti voglio costringere sia chiaro,
non darmi più consigli, sprecheresti il tuo prezioso tempo o la tua
esultanza.
D'altra parte quello che ho chiesto mi è stato chiarito meglio e senza
'motivate critiche' da altri.
Ciao.Enzo.

 esultanza.
Ok, *PLONK*.  Non ci vuole molto a settare il mio newsreader in modo
da non vedere piu` nulla che tu posti.  Se poi tu dovessi postare cose
particolarmente offensive, disinformazioni gravissime quali gia` piu` volte
hai postato, ecc, ecc, fido sugli altri amici per rintuzzarle e/o farmi
sapere
(tu, invece, sei pregato di NON insozzare la mia mailbox, grazie).
Ho dedicato parecchio tempo ed energia ai tuoi specifici problemi, come
spesso faccio su questo gruppo.  _Mediamente_, ricevo, come unico
compenso, espressioni di gratitudine (e non sempre: molti, una volta avuto
l'aiuto che gli serviva sul momento, poi se ne fregano).  Sarai, penso,
giustamente orgoglioso di avere stabilito il nuovo record negativo in
questo campo.
Tieniti caro Schildt: vi meritate a vicenda.
Alex

usarlo. Sto imparando come avrai fatto anche tu. O sei nato imparato ?
Non credo che consigliarti di evitare un certo costrutto sia una
offesa, se avessi seguito il NG per un po' di tempo avresti capito
il perche` del consiglio. Un conto e` studiare new/delete, un altro
utilizzarlo in applicazioni reali, il consiglio era tutto a tuo
vantaggio...
Paolo


Guarda che non mi ha consigliato solo di non usare new e delete,mi ha
consigliato di non usare il C++!!! Se uno da di questi consigli non
può che farlo malignamente.E poi leggi il suo ultimo follow-up a me
diretto , ha sputato + veleno che poteva.E poi non sono l'unico che ha
avuto questa reazione.
Ciao.Enzo.

seconda edizione?
Il libro di bruce eckel e` ottimo, tra l'altro questo mese e`
sul cd distribuito con la rivista dev.
Paolo

avuto questa reazione.
Nonostante il fatto che io sia in parte d'accordo con te riguardo al
tono altezzoso di Alex ti posso assicurare che dal punto di vista
tecnico i suoi consigli (per quando parla di cose che conosco)
sono molto validi. In altre parole non si tratta di pura arroganza
(anche se indubbiamente l'arroganza c'e').
Dal mio punto di vista i tuoi commenti mostrano come tu abbia idee
abbastanza confuse su molti punti chiave (dai puntatori, alla memoria
dinamica alla scrittura di codice performante alle reti neurali).
Io sono un fautore della costruzione "dal basso" e non sono convinto
che si possa arrivare ad usare bene cose come std::vector se non si
hanno le idee chiare su come la cosa e' implementata (almeno a
grandi linee).
Ad una persona con idee confuse come le tue onestamente mi sentirei
anche io di sconsigliare per il momento l'uso del C++; l'unico modo
che avresti di usarlo in maniera corretta e' mandando a memoria una
serie impressionante di "dogmi" abbastanza incomprensibili.
Ad esempio anche nella matematica noi dopotutto impariamo l'algebra
astratta e gli spazi funzionali solo *dopo* aver imparato a contare.
Nota che questo e' solo il mio punto di vista che a quanto pare non
e' molto condiviso. Ad esempio c'e' chi sconsiglia di imparare il
C se si vuole imparare il C++.
La mia idea e' che per imparare *superficialmente* il C++ la
conoscenza *superficiale* del C e' un impedimento ma per una
conoscenza *approfondita* vale il contrario: una conoscenza
*profonda* del C e' un'ottima buona base per acquisire una
conoscenza *profonda* del C++.
Non c'e' nulla di male ad avere le idee confuse su argomenti che
non sono in effetti cosi' banali. Inoltre nel mondo attuale della
programmazione c'e' una quantita' di "fumo" incredibile e
spesso si viene colpiti a tradimento da fonti che a prima vista
appaiono autorevoli (es. libri o riviste del settore).
In verita' non so se invidiare chi entra ora nel mondo della
programmazione (e' meglio perdersi in un bosco in cui non ci
sono indicazioni o in uno in cui ci sono indicazioni che in
una percentuale non trascurabile sono errate ?)
La fuori c'e' un sacco di gente che e' molto interessata alle
tue 80000+60000 e che e' pronta a dirti di tutto pur di
portartele via.
Io sono convinto che comprendere *a fondo* la programmazione
ad oggetti senza aver compreso *a fondo* le strutture,
l'allocazione dinamica e i puntatori a funzione e'
impossibile. E' come tentare di costruire un castello su
colonne di sabbia; come studiare l'algebra delle matrici
senza saper contare.
Il mio consiglio e' di chiarirsi prima bene le idee sui
fondamenti. Non so se il C++ e' il linguaggio piu' adatto
per questo scopo.
Assolutamente senza malignita'
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

Andrea
Enzo.

 impossibile.
Secondo me sono due livelli di astrazione differenti per cui ci si può
benissimo occupare di uno senza avere conoscenza dell'altro.
EMG

benissimo occupare di uno senza avere conoscenza dell'altro.
Effettivamente la mia frase non e' corretta; manca una precisazione.
  Io sono convinto che comprendere *a fondo* la programmazione
  ad oggetti in C++ senza aver compreso *a fondo* le strutture,
  l'allocazione dinamica e i puntatori a funzione e'
  impossibile.
Inoltre, come ho detto all'autore del primo posting, se anche fosse
possibile usare correttamente il C++ senza queste conoscenze di
base lo sforzo mnemonico su una serie di astrusi dogmi lo renderebbe
qualcosa di terribile (un paio di esempi: perche' i metodi virtuali
hanno un overhead di tempo e di spazio ? perche' e' taboo la
sequenza: "base *p=new derived[1]; delete[] p;" ?)
Secondo me il C++ non e' e non vuole essere un linguaggio OO "puro" e
distante dal "metallo" della macchina. Se qualcuno ha paura dei
byte allora, a mio parere, il C++ non e' un linguaggio da considerare.
----------------------------------------------------------------
 <\___/>  Andrea        email: agriff at tin dot it
 / . . \  "6502"          irc: _6502_@EFNET#italia
(  (")  ) Griffini   homepage: 
http://www.netservers.com/~agriff
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 byte allora, a mio parere, il C++ non e' un linguaggio da considerare.
Non è questione, secondo me, di paure ma di utilizzare gli strumenti
giusti al momento giusto. E puntatori/new[]/delete[] al posto di
std::vector non è in generale la via corretta.
EMG

byte allora, a mio parere, il C++ non e' un linguaggio da considerare.
Il newbbie non ha bisogno di capire quanti byte occupa un int o un
double (per'altro dipendenti dalla piattaforma).
Paolo

di std::vector non è in generale la via corretta.
Anche io sono profondamente convinto che, quando possibile, l'uso
di std::vector sia da incoraggiare al massimo.
Stroustrup mi convince addirittura quando dice che a volte anche usare
cose come std::map quando in realta' quello che serve e' un
sottoinsieme delle funzionalita' (es. una hash table) non e'
qualcosa di terribilmente sbagliato.
In fondo se l'implementazione e' comunque accettabile come tempi di
risposta, e' gia' pronta, ultratestata e standard (quindi conosciuta
e gestibile da qualunque programmatore C++) e magari il template
relativo e' gia' stato istanziato per altre ragioni ... beh ... allora
sarebbe veramente da maniaci implementare una class hash-table ad hoc
solo per il (piccolo) overhead di tempo e di occupazione che
l'ordinamento di std::map implica.
Purtroppo pero' STL non fornisce tutte le possibili interpretazioni
e in casi reali ci sono spessissimo problemi per cui "la pappa
pronta" non c'e'.
Avere le idee chiare su come funzionano puntatori/new[]/delete[]
e' secondo me una marcia in piu' notevole.


Paolo


possibile alla larga".
La curiosita` e` importante, ma sapere come e` codificato un float
non ti insegna a programmare!
Paolo
-------------------------------------------
  Paolo Marotta
 
http://web.tiscalinet.it/paolo_marotta/
-------------------------------------------

 e' secondo me una marcia in piu' notevole.
Ma io sono d'accordo su questo. Non sono d'accordo sul fatto che uno che
inizia debba avere subito a che fare con queste problematiche.
EMG

inizia debba avere subito a che fare con queste problematiche.
Hmmm... ti credo sulla fiducia. Non ho grandi esperienze di
didattica.
Ma realmente conosci qualche programmatore/ice che abbia fatto il
percorso di apprendimento che dici tu ? Che sia cioe' partito dai
template per arrivare ai byte ?


non ti insegna a programmare!
Si... ma quasi quasi sembra che sia una colpa.
Comunque la mia idea e' che la *programmazione* ad oggetti non e'
un sistema per EVITARE la conoscenza; ma un sistema per ORGANIZZARLA
e, grazie all'ordine, ad ESTENDERLA. La cosa che mi ha stupito
maggiormente quando ho iniziato a programmare ad oggetti (Borland
Pascal 5.5) e' stata la dimensione e la complessita' funzionale dei
programmi che riuscivo a scrivere a parita' di tempo.
Oserei dire decuplicata.
Anche la programmazione strutturata non elimina i GOTO, piuttosto
li organizza e permette di scrivere con molti meno sforzi un numero
di GOTO incredibilmente superiore in maniera molto piu' sicura e
veloce.
In questa posizione filosofica pero' non ho molta compagnia...


 template per arrivare ai byte ?
Magari dai template no ma sicuramente dai tipi base e loro operatori e
poi i tipi più semplici della libreria standard si.
EMG

 In questa posizione filosofica pero' non ho molta compagnia...
Veramente io ho trovato tutto il tuo messaggio altamente condivisibile.
EMG

e' che e' anche decisamente vasto (forse troppo).
In effetti, piccolo non e`!


In questa posizione filosofica pero' non ho molta compagnia...
Non sono sicuro di capire... e se intuisco bene effettivamente non
mi trovi molto d'accordo.


e` un linguaggio la cui filosofia e` impedirti di fare(ti) male!
Appunto. Per questo secondo me e' importante non usarlo
(leggi non apprenderlo) come si userebbe Visual Basic.


-------------------------------------------
--
