[C++] funzione che restituisce un array

[BlackCaesar]

Ho scritto il codice seguente per prova che prende 3 interi in input, li inserisce in un array e poi stampa il contenuto dell'array. Il problema è che quando stampo l'array il primo elemento è giusto mentre gli altri due no.
La funzione restituisce un puntatore int che è il nome dell'array.

#include <iostream>
using std::cout;
using std::cin;
using std::endl;

int *initArray(int, int, int);

int main()
{
	int a = 0;
	int b = 0;
	int c = 0;
	cout << "Insert 3 integers: ";
	cin >> a;
	cin >> b;
	cin >> c;
	
	int *arr = initArray(a, b, c);

	for (int i = 0; i < 3; i++)
		cout << "Array element " << i << " = " << arr[i] << endl;

	return 0;
}

int *initArray(int a, int b, int c)
{
	int myArray[] = {0, 0, 0};
	myArray[0] = a;
	myArray[1] = b;
	myArray[2] = c;
	for (int i = 0; i < 3; i++)
		cout << "The element " << i << " in the function is: " << myArray[i] << endl;
	return myArray;
}

Qualcuno può dirmi cosa sbaglio?

[BlackCaesar]

Ho risolto.
Per chi è interessato: l'array locale alla funzione se è allocato staticamente viene distrutto al termine della stessa, invece se viene allocato dinamicamente non viene distrutto perché la deallocazione dev'essere esplicita.
Quindi il codice va modificato come segue:

int *initArray(int a, int b, int c)
{
	int *myArray = new int[3];
	myArray[0] = a;
	myArray[1] = b;
	myArray[2] = c;
	for (int i = 0; i < 3; i++)
		cout << "The element " << i << " in the function is: " << myArray[i] << endl;
	return myArray;
}

[Sempre Recidivo]

Scusa, ma solitamente e' sbagliato allocare qualcosa ad un livello e distruggerlo ad un'altro.

Quello che allochi a livello x, dovresti distruggerlo allo stesso livello.
In questo caso la funzione e' inutile.
Corretta sitatticamente ma sbagliata logicamente.

In C i puntatori sono importanti, ma ancora piu' importante e' la loro gestione e quella della memoria, almeno finche' si gestisce manualmente.

[BlackCaesar]

Guarda io ho letto un articolo in un forum di programmazione dove uno aveva il mio stesso problema e dicevano che l'unico modo per risolverlo è questo. Il mio libro dice la stessa cosa, ovvero che per restituire un array da una funzione lo devi allocare dinamicamente e poi distruggerlo all'esterno. Non vedo altre alternative, anche perché si fa la stessa cosa con gli oggetti, se una funzione restituisce un tipo personalizzato lo allochi dinamicamente e restituisci un puntatore a quell'oggetto (perché tanto lo utilizzi all'esterno e quindi comunque l'oggetto originario o una copia la devi avere in memoria). Quando hai finito di usarlo lo butti via con delete. Anche il Java fa così in versione automatizzata, ovvero se crei un oggetto all'interno di un metodo e poi lo restituisci, quell'oggetto continua ad esistere finché non è più puntato da niente (solo che là la gestione dei puntatori è mascherata) e poi il garbage collector lo cancella.

La funzione che ho postato è inutile perché è un esempio costruito per esporre il problema che avevo non perché mi servisse di fatto.

[Sempre Recidivo]

...
(solo che là la gestione dei puntatori è mascherata) e poi il garbage collector lo cancella.
...

Non me lo nominare nemmeno che mi viene l'orticaria.
La memoria mia me la gestisco io.

La mia non era una legge, ma una regola che solitamente si adotta.
Memoria allocata al livello x distrutta allo stesso livello, serve per semplificare il codice, in programmi semplici non noti la differenze ma quando le cose si fanno complesse avere puntatori a memoria e non sai dove hai allocato la memoria .... bo, io mi trovo bene alla mia maniera.

Comuque per il tuo caso, solitamente se devi riempire un vettore con alcuni elementi, passi il puntatore al vettore e gli elementi, cosi' li inserisci.

[BlackCaesar]

Si lo so, ti ripeto che era una funzione di esempio, potevo farne una sulla somma di matrici. Se fai la somma di due matrici non è il massimo passare la matrice somma direttamente alla funzione come argomento, di solito la crei all'interno della funzione e la restituisci (restituisci un puntatore all'array). In questo caso serve fare quello che ho detto io.
Cmq nemmeno nel C++ sai dove alloca la memoria, perché alla fine quello lo fa il sistema operativo, tu programmi su indirizzi virtuali, poi basta che scrivi delete e il nome di uno dei puntatori all'oggetto allocato dinamicamente e sei a posto, libera la memoria e ciao, il dove sia posto l'oggetto è sempre mascherato.

Cmq tutti i linguaggi moderni, compreso il C#, prendono la piega di impiegare un garbage collector, alla fine il programmatore non si deve preoccupare di risolvere problemi legati alla gestione della memoria ma deve concentrarsi a risolvere il problema legato al suo programma (anche se anche io apprezzo la libertà di poter deallocare la memoria da me). Se poi tu sei particolarmente interessato alla gestione della memoria potresti buttare via direttamente il sistema operativo così tu puoi divertire a scrivere gli overlay da te

[Sempre Recidivo]

Si lo so, ti ripeto che era una funzione di esempio, potevo farne una sulla somma di matrici. Se fai la somma di due matrici non è il massimo passare la matrice somma direttamente alla funzione come argomento, di solito la crei all'interno della funzione e la restituisci (restituisci un puntatore all'array).
In questo caso serve fare quello che ho detto io.

No.

Cmq nemmeno nel C++ sai dove alloca la memoria, perché alla fine quello lo fa il sistema operativo, tu programmi su indirizzi virtuali, poi basta che scrivi delete e il nome di uno dei puntatori all'oggetto allocato dinamicamente e sei a posto, libera la memoria e ciao, il dove sia posto l'oggetto è sempre mascherato.

No.

Se usi MFC e gli oggetti, non usi ne new ne delete ma oggetti con costruttore e distruttore, che naturalmente non e' la garbage collector.

Cmq tutti i linguaggi moderni, compreso il C#, prendono la piega di impiegare un garbage collector,

Neanche, al massimo i linguaggi di alto livello, il c e' un linguaggio per tutti i livelli.

...
alla fine il programmatore non si deve preoccupare di risolvere problemi legati alla gestione della memoria ma deve concentrarsi a risolvere il problema legato al suo programma (anche se anche io apprezzo la libertà di poter deallocare la memoria da me).

Anche qui un ci siamo, puoi fare cosi' quando le risorse che utilizzi ( il sistema ) sono molto maggiori di quello che ti serve.

...
Se poi tu sei particolarmente interessato alla gestione della memoria potresti buttare via direttamente il sistema operativo così tu puoi divertire a scrivere gli overlay da te

Io prevalentemente programmo schede embedded, dove ogni singolo byte di memoria fa la differenza e il pericolo di non deallocare la memoria e' uno dei piu' grossi reati, e si, sulle mie schede il sistema operativo me lo sono scritto da me.

Poi fai come vuoi.

[BlackCaesar]

Si ho capito ragazzo che tu sei skillato, ma tu non puoi venirmi a tirare fuori delle API di Microsoft per il c++ e pretendere che faccia i programmi con quelle che l'ho appena imparato le MFC non so in pratica nemmeno cosa siano.

Cmq la roba della somma di matrici tu come la fai?

[y.a.f.ake]

Non per intromettermi, ma

La mia non era una legge, ma una regola che solitamente si adotta.

Non mi risulta , il codice di sopra mi pare corretto.
Nella programmazione esistono delle robe che dovrebbero sempre accompagnare una funzione e che si chiamano precondizioni,postcondizioni e documentazione di una funzione; se lì c'è scritto che la funzione ti restituisce un buffer che è tua cura deallocare, non vedo dove sia il problema, l'importante è che sia documentato e noto al programmatore.
Anzi portare come esempio roba della microsoft è controproducente, lì ti restituiscono o si prendono buffer che non sai se te ne devi sbarazzare o no o che gli passi e non sai che fine fanno

[Sempre Recidivo]

Non per intromettermi, ma

Non mi risulta , il codice di sopra mi pare corretto.
Nella programmazione esistono delle robe che dovrebbero sempre accompagnare una funzione e che si chiamano precondizioni,postcondizioni e documentazione di una funzione; se lì c'è scritto che la funzione ti restituisce un buffer che è tua cura deallocare, non vedo dove sia il problema, l'importante è che sia documentato e noto al programmatore.

Non ho mai detto che e' sbagliata, a me hanno insegnato che quello che allochi al livello x tendenzialmente, preferibilmente, [altro avverbio a caso], lo deallochi allo stesso livello, per una maggiore pulizia del codice, poi certo che la documentazione e frizzi e lazzi, ma non stavo discutendo di quello.

Dopotutto lo stile di programmazione ognuno ha il suo, figurati uno di Milano s'era ridefinito gli if con la notazione when

Anzi portare come esempio roba della microsoft è controproducente, lì ti restituiscono o si prendono buffer che non sai se te ne devi sbarazzare o no o che gli passi e non sai che fine fanno

Be' solitamente con MFC di buffer espliciti non ne trovi, sono tutti oggetti che si allocano e si liberano da soli, tranne ovviamente quando li gestisci a runtime, allora, come ho detto mi rimane oltremodo comodo gestire la memoria allo stesso livello ( sempre che non la gestica con costruttor/destructor ).

Tutto beninteso salvo casi particolari, chesso' come il goto, odiatissimo ma alle volte necessario.

[BlackCaesar]

Il goto necessario????? Ma se hanno inventato le strutture di controllo proprio per non doverlo usare mai. Guarda c'è un teorema che dice che qualsiasi problema è risolvibile con un linguaggio che metta a disposizione una struttura decisionale e una iterativa, quindi il goto magari può risultare più immediato ma la cosa è gestibile equivalentemente in un altro modo.

[y.a.f.ake]

Il goto necessario????? Ma se hanno inventato le strutture di controllo proprio per non doverlo usare mai. Guarda c'è un teorema che dice che qualsiasi problema è risolvibile con un linguaggio che metta a disposizione una struttura decisionale e una iterativa, quindi il goto magari può risultare più immediato ma la cosa è gestibile equivalentemente in un altro modo.

Vabbè credo intendesse necessario non in C++, bensì quando si programma a basso livello e si integrano parti di codice scritte in C con altre scritte in asm.

Non ho mai detto che e' sbagliata, a me hanno insegnato che quello che allochi al livello x tendenzialmente, preferibilmente, [altro avverbio a caso], lo deallochi allo stesso livello, per una maggiore pulizia del codice, poi certo che la documentazione e frizzi e lazzi, ma non stavo discutendo di quello.

Ma non è questione di stile, è proprio che ci sono casi in cui è necessario che ci siano delle funzioni builder.
E poi non si sta parlando di parecchi livelli di passaggio ma solo uno, la funzione builder può benissimo essere intesa come una malloc od una new più complicata, in quel modo l'ha usata BlackCaesar e così si usa.

[LarsenB]

Ma non è questione di stile, è proprio che ci sono casi in cui è necessario che ci siano delle funzioni builder.
E poi non si sta parlando di parecchi livelli di passaggio ma solo uno, la funzione builder può benissimo essere intesa come una malloc od una new più complicata, in quel modo l'ha usata BlackCaesar e così si usa.

Anzi, lavorando ad oggetti, specie se si scrivono librerie usate da terze parti, spesso è proprio la normalità quello di creare e restituire le istanze attraverso metodi di classi "factory", per esempio per avere oggetti singleton, oppure semplicemente per nascondere l'implementazione del costruttore all'utilizzatore finale