Torna indietro   Hardware Upgrade Forum > Software > Programmazione

BOOX Picco: l'ebook reader minuscolo è una genialata, e si può attaccare allo smartphone
BOOX Picco: l'ebook reader minuscolo è una genialata, e si può attaccare allo smartphone
BOOX ha portato sul mercato Picco, un e-reader da 3,97 pollici che pesa 58 grammi e si aggancia al retro dello smartphone con un anello magnetico. Lo abbiamo usato con Pixel 11 Pro XL e iPhone 18 Pro per capire se un formato così ridotto regga la prova della lettura quotidiana
AMD EPYC Venice: dentro Zen 6, i SoC a 256 core e la sfida al costo della memoria
AMD EPYC Venice: dentro Zen 6, i SoC a 256 core e la sfida al costo della memoria
A Las Vegas AMD ha svelato i dettagli architetturali delle CPU EPYC di sesta generazione, note con il nome in codice Venice. Nuovi core Zen 6 e Zen 6c costruiti a 2 nanometri, fino a 256 core per socket, 16 canali di memoria, interfaccia PCI Express 6.0 e un'intera famiglia di proposte che va da Venice SP7 a Verano. Senza dimenticare la memoria, oggi la voce di costo più pesante in un server: AMD risponde con CXL 3.1 e con la tecnologia software MEXT, che porta la memoria flash dentro la gerarchia della DRAM.
HONOR Pad X9 Max recensione, schermo ultra large a meno di 400 euro
HONOR Pad X9 Max recensione, schermo ultra large a meno di 400 euro
HONOR Pad X9 Max mette un pannello IPS da 13 pollici con risoluzione 2,5K e refresh a 120 Hz davanti a una batteria da 10.100 mAh e a quattro altoparlanti. Il listino parte da 399,90 euro, per un progetto molto chiaro e ambizioso: schermo ampio, buon audio e giornate lontano dalla presa, a un prezzo che non pesa sul portafoglio
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 05-10-2009, 22:35   #1
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
[c++] problema new delete e vector

allora, ho del codice preesistente che suppongo crei dei memory leak, volevo dargli una sistemata ma ho trovato qualche problema, questo è il codice:

Codice:
[...]

				unsigned shape_count = 0;
				vector<double*> pvec, svec, cvec, fmvec, fsdvvec;
				vector<double> avec;

				//for all points of contour
				for (; cont; cont = cont->h_next)
		  		{
[...]
					{
[...]
						double *feature = new double[3];
						double *color = new double[3];
						double *position = new double[2];

						compute_shape_feature(points, shape_num_point, shape_per, shape_area, feature, position, newFeatures, subImageMargin, startP, endP);
						compute_color_feature(imgN, position, color);


[...]

//QUESTA DICHIARAZIONE L'HO MESSA IO, E' CORRETTO COME ALLOCO IL VETTORE E COME LIBERO LA MEMORIA?
				  		GlcmMatrix *directionalGLCM[4];
				  		directionalGLCM[0] = new GlcmMatrix(GlcmLevel, WindowSize, 1, 0);
				  		directionalGLCM[1] = new GlcmMatrix(GlcmLevel, WindowSize, 1, -1);
				  		directionalGLCM[2] = new GlcmMatrix(GlcmLevel, WindowSize, 0, 1);
				  		directionalGLCM[3] = new GlcmMatrix(GlcmLevel, WindowSize, 1, 1);
[...]

				  		//free the memory
						for (int k = 0; k < 4; k++)
						{
							delete directionalGLCM[k];
						}



						#ifdef DEBUG
						cout << endl << "Shape " << shape_count << "------------------" << endl;
						cout << "Contour's points: " << shape_num_point << endl;
						cout << "Perimeter: " << shape_per << endl;
						cout << "Area: " << shape_area << endl;
						cout << "Feature: " << feature[0]  << " " << feature[1] << " " << feature[2] << endl;
						cout << "Color: " << color[0]  << " " << color[1] << " " << color[2] << endl;
						cout << "Center Position: " << position[0] << " " << position[1] << endl;
						#else
						cout << ".";
						pvec.push_back(position);
						cvec.push_back(color);
						svec.push_back(feature);
						avec.push_back(shape_area);
						#endif

						//[red]memory leak!!! SE LO DECOMMENTO MEMORIZZA NEL FILE SOLO L'ULTIMO INSIEME DI VALORI RIPETUTO TANTE VOLTE QUANTE ESEGUE IL CICLO[/red]
						//delete [] feature;
						//delete [] color;
						//delete [] position;

					}
		  		}
[...]

				cout << "ok" << endl;

				vector<double*>::iterator its = svec.begin(), itc = cvec.begin(), itp = pvec.begin();
			    vector<double>::iterator ita = avec.begin();

			    //append to file
			    fprintf(pFile, "%s\n", fname.str().c_str());
		    	fprintf(pFile, "%d\n", shape_count);

			    while(its != svec.end())
			    {
			    	fprintf(pFile,"%f\n", *ita);
			    	fprintf(pFile, "%f %f\n", (*itp)[0], (*itp)[1]);
			    	fprintf(pFile, "%f %f %f\n", (*its)[0], (*its)[1], (*its)[2]);
			    	fprintf(pFile, "%f %f %f\n", (*itc)[0], (*itc)[1], (*itc)[2]);
			    	its++; itc++; itp++; ita++;
			    }
come ho scritto anche nel codice, se provo a fare il delete, tutti i gruppi di valori del file sono uguali, se lascio tutto commentato invece funziona tutto bene (anche se credo crei memory leak, in quanto ogni cosa con new poi ha bisogno del delete...).
Ho provato anche a dichiarare questi:
Codice:
						double *feature = new double[3];
						double *color = new double[3];
						double *position = new double[2];
come semplici vettori, togliendo quindi i new e i delete:
Codice:
						double feature[3];
						double color[3];
						double position[2];
ma il problema non cambia.

Ho anche provato a spostare fuori da ciclo sia le dichiarazioni delle variabili (prima dell'ingresso del ciclo) e il loro delete (dopo la fine del ciclo), ma il risultato non cambia.
E' corretto lasciar le cose così?
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 01:03   #2
Ikon O'Cluster
Registered User
 
Iscritto dal: May 2009
Messaggi: 300
Il codice che hai scritto è frammentario... per quanto ne so quelle classi potrebbero contenere campi allocati dinamicamente e non prevedere un distruttore. Io ti consiglio di prestare più attenzione e valutare bene se è davvero necessario l'uso della memoria dinamica. A questo punto una programmazione meticolosa dovrebbe ridurre al minimo i danni. Ad ogni modo uno strumento come "valgrind" dovrebbe darti una mano ad individuare la magagna!
Ikon O'Cluster è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 08:49   #3
tomminno
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 3306
Solo una domanda perchè non usi vector al posto di gestire manualmente gli array?

Per chiarire i tuoi dubbi: hai usato vector<double*>, se fai il delete degli array poi chiaramente non hai più i valori a disposizione nel vector. Devi deallocare tutti gli elementi solo dopo averli usati.
Ti consiglierei di usare vector<double> al posto di vector<double*>
tomminno è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 09:56   #4
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
Quote:
Originariamente inviato da Ikon O'Cluster Guarda i messaggi
Il codice che hai scritto è frammentario... per quanto ne so quelle classi potrebbero contenere campi allocati dinamicamente e non prevedere un distruttore. Io ti consiglio di prestare più attenzione e valutare bene se è davvero necessario l'uso della memoria dinamica. A questo punto una programmazione meticolosa dovrebbe ridurre al minimo i danni. Ad ogni modo uno strumento come "valgrind" dovrebbe darti una mano ad individuare la magagna!
no le classi non hanno campi allocati dinamicamente
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 09:59   #5
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
Quote:
Originariamente inviato da tomminno Guarda i messaggi
Solo una domanda perchè non usi vector al posto di gestire manualmente gli array?

Per chiarire i tuoi dubbi: hai usato vector<double*>, se fai il delete degli array poi chiaramente non hai più i valori a disposizione nel vector. Devi deallocare tutti gli elementi solo dopo averli usati.
Ti consiglierei di usare vector<double> al posto di vector<double*>
non ho scritto io quella parte di codice, ma potrei cambiarlo, chi l'ha scritto penso l'abbia scritto così in modo da poter fare il push di un vettore intero, senza farlo elemento per elemento.

Ma lasciandolo così, con solo quello che vedete dato che il resto è apposto, crea memory leak non deallocare quei tre vettori double, o va bene?
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 13:08   #6
tomminno
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 3306
Quote:
Originariamente inviato da czar Guarda i messaggi
non ho scritto io quella parte di codice, ma potrei cambiarlo, chi l'ha scritto penso l'abbia scritto così in modo da poter fare il push di un vettore intero, senza farlo elemento per elemento.
Sarebbe?
Dal codice si vede che quegli array sono valorizzati da compute_shape_feature, usare un vector è molto più comodo.

Quote:
Ma lasciandolo così, con solo quello che vedete dato che il resto è apposto, crea memory leak non deallocare quei tre vettori double, o va bene?
Certo che crea leak, ma li devi deallocare dopo averli usati, per come hai messo te le delete li cancelli prima di usarli.
Chiaro che così non funziona.
tomminno è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 13:50   #7
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
credo di aver capito.
Ma considerando il fatto che il file viene scritto alla fine del programma e che poi questo termini, SE alla chiusura del programma tutta la memoria che occupava viene liberata, credo sia inutile fare il delete (questo però avviene alla chiusura del programma?)

Un altro consiglio, mi conviene spostare all'interno del primo for la scrittura del file in modo da avere cicli in meno?
Io suppongo di si.
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 14:31   #8
Ikon O'Cluster
Registered User
 
Iscritto dal: May 2009
Messaggi: 300
Quote:
Originariamente inviato da czar Guarda i messaggi
credo di aver capito.
Ma considerando il fatto che il file viene scritto alla fine del programma e che poi questo termini, SE alla chiusura del programma tutta la memoria che occupava viene liberata, credo sia inutile fare il delete (questo però avviene alla chiusura del programma?)
Tu fai sempre la delete... aspettare la chiusura del programma non è una soluzione saggia. Se tu stessi realizzando un server o una applicazione con tempi di esecuzione lunghi, rischieresti di sprecare molta memoria.
Ikon O'Cluster è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 15:43   #9
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
Quote:
Originariamente inviato da Ikon O'Cluster Guarda i messaggi
Tu fai sempre la delete... aspettare la chiusura del programma non è una soluzione saggia. Se tu stessi realizzando un server o una applicazione con tempi di esecuzione lunghi, rischieresti di sprecare molta memoria.
e spostando la scrittura del file dentro il ciclo for, risparmierei tempo rispetto a com'è adesso che uso un while per scrivere il file, giusto?
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 16:54   #10
Ikon O'Cluster
Registered User
 
Iscritto dal: May 2009
Messaggi: 300
Sinceramente non ho capito! Adesso cicli N volte il for ed M volte il while. Ottieni N*M scritture del file. Ovvio che se lo metti fuori dal while ne fai solo N, ma devi vedere se puoi farlo. Se quel while esiste ci sarà un motivo no?
Ikon O'Cluster è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 17:16   #11
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
Quote:
Originariamente inviato da Ikon O'Cluster Guarda i messaggi
Sinceramente non ho capito! Adesso cicli N volte il for ed M volte il while. Ottieni N*M scritture del file. Ovvio che se lo metti fuori dal while ne fai solo N, ma devi vedere se puoi farlo. Se quel while esiste ci sarà un motivo no?
si in effetti il motivo della sua esistenza c'è, in pratica dentro il for (eseguito diciamo N volte) c'è un if che non ho scritto e se un valore è minore di una soglia allora va in "continue". Altrimenti si fa il blocco di codice che ho scritto e incrementa un contatore (shape_count, che alla fine sarà pari alle M volte del while) che ho omesso per evitarvi di annoiarvi a leggere tutto il codice.
In pratica quel while esiste per scrivere in testa agli elementi del file, il numero totale di shape_count.
Pensavo quindi di fare il conto degli shape_count prima, in modo da non dovermi trascinare troppe variabili da deletare, e scrivere il file direttamente nel ciclo for, invece che fuori.
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 18:02   #12
Ikon O'Cluster
Registered User
 
Iscritto dal: May 2009
Messaggi: 300
Se il tuo problema è ottimizzare le vie in linea di principio sono:

1) Evitare il più possibile operazioni di I/O
2) Evitare il più possibile allocazione dinamica
3) Cercare di ridurre il più possibile le operazioni all'interno dei cicli
Ikon O'Cluster è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 21:55   #13
czar
Member
 
Iscritto dal: Nov 2004
Città: Roma e Palermo
Messaggi: 204
perfetto grazie

un ultima cosa, questa allocazione/deallocazione è corretta vero? (nell'oggetto non ci sono tipi dinamici)

Codice:
				  		GlcmMatrix *directionalGLCM[4];
				  		directionalGLCM[0] = new GlcmMatrix(GlcmLevel, WindowSize, 1, 0);
				  		directionalGLCM[1] = new GlcmMatrix(GlcmLevel, WindowSize, 1, -1);
				  		directionalGLCM[2] = new GlcmMatrix(GlcmLevel, WindowSize, 0, 1);
				  		directionalGLCM[3] = new GlcmMatrix(GlcmLevel, WindowSize, 1, 1);
[...]

				  		//free the memory
						for (int k = 0; k < 4; k++)
						{
							delete directionalGLCM[k];
						}
czar è offline   Rispondi citando il messaggio o parte di esso
Old 06-10-2009, 22:47   #14
Ikon O'Cluster
Registered User
 
Iscritto dal: May 2009
Messaggi: 300
Si è corretto...

Ultima modifica di Ikon O'Cluster : 06-10-2009 alle 23:01.
Ikon O'Cluster è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


BOOX Picco: l'ebook reader minuscolo è una genialata, e si può attaccare allo smartphone BOOX Picco: l'ebook reader minuscolo è un...
AMD EPYC Venice: dentro Zen 6, i SoC a 256 core e la sfida al costo della memoria AMD EPYC Venice: dentro Zen 6, i SoC a 256 core ...
HONOR Pad X9 Max recensione, schermo ultra large a meno di 400 euro HONOR Pad X9 Max recensione, schermo ultra large...
Lenovo ThinkPad X1 Carbon Gen 14: il business ultraleggero si rinnova dall’interno Lenovo ThinkPad X1 Carbon Gen 14: il business ul...
Jabra Evolve3 85: le cuffie sia per l'intrattenimento che per il lavoro Jabra Evolve3 85: le cuffie sia per l'intratteni...
Elon Musk anticipa le caratteristiche de...
Caos Grok Build: le app create con l'IA ...
ChatGPT abbandona le vecchie modalità vo...
Claude adatta un modello alle GPU AMD in...
Stangata alla pirateria da Nintendo: col...
Cisco potenzia AI Defense: arriva l'inte...
Basta cambiare pasta termica: la nuova i...
Aura Ink 10: la cornice E-Ink si rifà il...
Auto cinesi bandite dalle caserme tedesc...
Addio criogenia: il prototipo di compute...
iPhone e iPad possono ora emulare la PS3...
SMS falso dell'INPS: l'app da scaricare ...
Da 120 a 520 qubit: il nuovo chip IBM Ni...
Gemini Decisions API: Google sfida OpenA...
City e-bike in carbonio a un prezzo mai ...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 13:46.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v