Puntatori: array di dimensione variabile di stringhe di dimensione nota

deckard

il 02 ott 2018, 18:10

29 risposte

29 Risposte - Pagina 2

D
deckard
Utente Attivo
Iscritto da
nov, 2017
Messaggi:
91
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 12:53
oregon ha scritto:
... eccezion fatta per una questione ...
Ovvero?
Scusa, devo aver fatto un pasticcio... comunque ti ho scritto dopo... l'eccezion fatta era sulla riallocazione della dimensione "riga..."
O
oregon
Super Famoso
Iscritto da
nov, 2011
Messaggi:
21552
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 12:54
deckard ha scritto:

Secondo me sto sbagliando a passare i riferimenti alla realloc…

.
Cioè? A cosa ti riferisci?
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 13:02
Fai bene a studiare i meccanismi, ma faresti ancora meglio a 'incapsularli' in qualcosa che puoi usare.
nel merito spesso non si usa la riallocazione, ma proprio la allocazione di nuovo spazio, con copia dei dati precedenti, e rilascio della memoria precedente
D
deckard
Utente Attivo
Iscritto da
nov, 2017
Messaggi:
91
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 13:31
+m2+ ha scritto:
Fai bene a studiare i meccanismi, ma faresti ancora meglio a 'incapsularli' in qualcosa che puoi usare.
nel merito spesso non si usa la riallocazione, ma proprio la allocazione di nuovo spazio, con copia dei dati precedenti, e rilascio della memoria precedente
Ciao +m2+,
sì capisco. Ma la copia non comporta un rallentamento dell'operazione: in tale situazione devi allocare (e non espandere) e in più fare la copia che ha un costo computazionale. Non credi?

Ma sapresti farmi un esempio, nell'orientamento che sto cercando di approcciare? io sto fallendo nella realloc!!!

Grazie davvero!
O
oregon
Super Famoso
Iscritto da
nov, 2011
Messaggi:
21552
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 13:34
Perché non mostri il codice che fallisce con la realloc?
D
deckard
Utente Attivo
Iscritto da
nov, 2017
Messaggi:
91
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 13:38
oregon ha scritto:
Perché non mostri il codice che fallisce con la realloc?
Non volevo abusare della gentilezza.
Tra un attimo te lo mostro. Rispondo a una persona.

Grazie Oregon. Spero un giorno di poter ricambiare o diventare utile per qualcun'altro.
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 14:00
Certo che allocare ha un costo.
ma ti sei mai chiesto cosa faccia realloc?
D
deckard
Utente Attivo
Iscritto da
nov, 2017
Messaggi:
91
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 14:33
+m2+ ha scritto:
Certo che allocare ha un costo.
ma ti sei mai chiesto cosa faccia realloc?
Tutto ha un costo, io mi riferivo in particolar modo alla copia. Realloc suppongo che espanda (minor costo che riallocare ex novo tutta una maggior memoria). Probabilmente, essendo la tua domanda, credo, retorica, suppongo che anch'essa effettui una copia. In effetti ad essa si passa un puntatore. Immagino tuttavia che se riesce ad allocare in modo contiguo la copia non sia necessaria.

Sbaglio di molto? Vi ringrazio davvero tutti, perché anche le domande, il dubitare e porre "critiche" è davvero importante.

Siete tutti davvero preziosi. Spero un giorno, sul tema C, poter essere a mia volta essere di aiuto a qualcuno.

Grazie

deckard

Utente Attivo

Iscritto da: nov, 2017

Messaggi:: 91

Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota

03 ott 2018, 14:54

oregon ha scritto:
Perché non mostri il codice che fallisce con la realloc?

Ciao Oregon,
ecco il "mio" codice...


    char **arrayStringhe;
    char *temp;
    int n = 3;
    int i;
    arrayStringhe = (char **)malloc(n * sizeof(char *));
    for(i=0; i<n; i++)
        arrayStringhe[i] = (char *)malloc(80 * sizeof(char));

        int righe = 0;

    while(1==1)
    {

        printf("Nominativo: ");
        gets(arrayStringhe[righe]);
        if(arrayStringhe[righe][0] == 'e')
        {
            printf("exit...");
            break;
        }

        righe++;

        if((righe % n)==0)
        {
            printf("Ridimensione la dimensione "riga" *arrayStringhe...\n");
            temp = (char *)realloc(*arrayStringhe, sizeof(char *)*10);
            *arrayStringhe = temp;
            printf("Nuova dimensione %d\n", sizeof(*arrayStringhe));
        }


    }

Tieni conto che al di là dell'errore (causa ignoranza) che certo ci sarà, il programma dovrebbe poi adattare il test del modulo per sapere quando sarebbe necessario il successivo ridimensionamento. Inolte, al momento non è riportato il rilascio della memoria...
Il ragiornamento, errato certamente, è che la dimensione riga per me è *arrayStringhe...

Grazie di cuore.

AldoBaldo
Molto attivo
Iscritto da
giu, 2017
Messaggi:
560
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 16:42
M2: "nel merito spesso non si usa la riallocazione, ma proprio la allocazione di nuovo spazio, con copia dei dati precedenti, e rilascio della memoria precedente"

Dov'è il vantaggio rispetto a usare realloc()? (che, magari, viene implementata dalle "teste d'uovo" con qualche trucco per migliorare l'efficienza...)
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 16:50
deckard ha scritto:
+m2+ ha scritto:
Certo che allocare ha un costo.
ma ti sei mai chiesto cosa faccia realloc?
Tutto ha un costo, io mi riferivo in particolar modo alla copia. Realloc suppongo che espanda (minor costo che riallocare ex novo tutta una maggior memoria). Probabilmente, essendo la tua domanda, credo, retorica, suppongo che anch'essa effettui una copia. In effetti ad essa si passa un puntatore. Immagino tuttavia che se riesce ad allocare in modo contiguo la copia non sia necessaria.

Sbaglio di molto?
ti stai avvicinando: nel momento in cui, nello heap, c'è già allocato qualcosa in più, realloc non fa altro che malloc+memcpy.
Solo in certi, rarissimi, casi il sistema operativo supporta la creazione di una paginazione virtuale "figlia", che consente di aumentare lo spazio senza ricopiare.
Mentre, in realtà, ciò è quasi sempre necessario.

"Nel mondo normale", cioè prima di allocare della memoria, bisognerebbe avere un'infarinatura su cosa sia, la memoria, e come venga allocata.
Lo step successivo è di studiare proprio il sorgente di malloc, realloc e così via, in modo da vedere, in concreto, come la "teoria" viene mappata nella realtà.
---
Versione breve: se allochi dinamicamente qualsiasi altra cosa, durante l'esecuzione del programma, realloc non fa miracoli diversi da alloca-e-copia-e-libera.
Questo, sia detto tra di noi, provoca la classica frammentazione interna la quale può, a seconda di quanto è evoluto il sistema operativo, determinare l'esaurimento della RAM disponibile, per il singolo processo, a cagione della parcellizzazione dei blocchi vuoti.
Ciò, normalmente, non accadeva (un tempo), e non accade (oggi) per i processi a 64bit, mentre può accadere, e in generale capita, per quelli a 32 eseguiti WOW
D
deckard
Utente Attivo
Iscritto da
nov, 2017
Messaggi:
91
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 18:32
+m2+ ha scritto:
deckard ha scritto:
+m2+ ha scritto:
Certo che allocare ha un costo.
ma ti sei mai chiesto cosa faccia realloc?
Tutto ha un costo, io mi riferivo in particolar modo alla copia. Realloc suppongo che espanda (minor costo che riallocare ex novo tutta una maggior memoria). Probabilmente, essendo la tua domanda, credo, retorica, suppongo che anch'essa effettui una copia. In effetti ad essa si passa un puntatore. Immagino tuttavia che se riesce ad allocare in modo contiguo la copia non sia necessaria.

Sbaglio di molto?
ti stai avvicinando: nel momento in cui, nello heap, c'è già allocato qualcosa in più, realloc non fa altro che malloc+memcpy.
Solo in certi, rarissimi, casi il sistema operativo supporta la creazione di una paginazione virtuale "figlia", che consente di aumentare lo spazio senza ricopiare.
Mentre, in realtà, ciò è quasi sempre necessario.

"Nel mondo normale", cioè prima di allocare della memoria, bisognerebbe avere un'infarinatura su cosa sia, la memoria, e come venga allocata.
Lo step successivo è di studiare proprio il sorgente di malloc, realloc e così via, in modo da vedere, in concreto, come la "teoria" viene mappata nella realtà.
---
Versione breve: se allochi dinamicamente qualsiasi altra cosa, durante l'esecuzione del programma, realloc non fa miracoli diversi da alloca-e-copia-e-libera.
Questo, sia detto tra di noi, provoca la classica frammentazione interna la quale può, a seconda di quanto è evoluto il sistema operativo, determinare l'esaurimento della RAM disponibile, per il singolo processo, a cagione della parcellizzazione dei blocchi vuoti.
Ciò, normalmente, non accadeva (un tempo), e non accade (oggi) per i processi a 64bit, mentre può accadere, e in generale capita, per quelli a 32 eseguiti WOW
Ciao +m2+,
grazie per la tua esauriente spiegazione, fornendo anche supporti e approfondimenti. Sicuramente andrò a studiarmi le implementazioni. Provo a dare un sintesi del tuo pensiero: quando si ha necessità di immagazzinare quantità di grandi quantità di informazioni (di un tipo di informazioni) conviene allocare inizialmente la memoria con un taglio plausibilmente sufficiente e poi se necessario riallocare e copiare i dati precedentemente immagazzinati? Oppure conviene allocare, in modo ragionevole, in modo statico la memoria, ad esempio il nostro array di stringhe, e se necessario passare ad allocare dinamicamente una nuova porizione di meria su cui copiare e continuare la roccolda dei dati ancora non memorizzati? Oppure non ha alcuna differenza?

Infine, non so, se ti è capitato di vedere il codice che ho postato poco precedentemente - il quale mi dà errore - in cui tento di fare la realloc della dimensione riga del puntatore a puntatore. Nel caso dove sabglio?

Che dire? Infinite grazie!
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 18:45
deckard ha scritto:
... Provo a dare un sintesi del tuo pensiero: quando si ha necessità di immagazzinare quantità di grandi quantità di informazioni (di un tipo di informazioni) conviene allocare inizialmente la memoria con un taglio plausibilmente sufficiente e poi se necessario riallocare e copiare i dati precedentemente immagazzinati? Oppure conviene allocare, in modo ragionevole, in modo statico la memoria, ad esempio il nostro array di stringhe, e se necessario passare ad allocare dinamicamente una nuova porizione di meria su cui copiare e continuare la roccolda dei dati ancora non memorizzati? Oppure non ha alcuna differenza?
Sei proprio fuori strada.

Se hai a che fare con "qualcosa" di cui non conosci la dimensione precisa, e neppure puoi stimarla con un grado ragionevole di precisione, ALLORA non ti conviene usare una struttura rigida, come un vettore (più o meno riallocato alla bisogna), bensì una struttura dati inerentemente dinamica.

SE invece puoi stimare - ragionevolmente - PUOI usare vettori.

Esempio: devi memorizzare gli studenti di una certa classe.
Potresti supporre siano 20, 30, quindi potresti allocare un vettore inizialmente di dimensione 100 ed essere ragionevolmente sicuro di non doverlo riallocare, se non in caso eccezionale.

Se invece devi memorizzare che so l'elenco degli studenti non vaccinati di un certo comune, difficilmente adotterai questa strategia, bensì (ad esempio) una lista, in cui allochi i singoli elementi uno alla volta.
Prestazioni minori, certo, ma niente "sbattimento".

"una volta" (con i processi a 8 o 16 bit) il problema era più sentito, coi 32 bit si è attenuato notevolmente, coi 64 ancor più.
ma continua a esistere e combattere insieme a noi

Infine, non so, se ti è capitato di vedere il codice che ho postato poco precedentemente - il quale mi dà errore - in cui tento di fare la realloc della dimensione riga del puntatore a puntatore. Nel caso dove sabglio?
Ehhh... non te la prendere, ma mi sono autoimposto di NON fare più questo genere di considerazioni.
Parecchi utenti la prendono malissima.
Meglio il quieto vivere.

PS non è un fatto personale che ti riguarda, non averne a male
D
deckard
Utente Attivo
Iscritto da
nov, 2017
Messaggi:
91
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 19:16
+m2+ ha scritto:
deckard ha scritto:
... Provo a dare un sintesi del tuo pensiero: quando si ha necessità di immagazzinare quantità di grandi quantità di informazioni (di un tipo di informazioni) conviene allocare inizialmente la memoria con un taglio plausibilmente sufficiente e poi se necessario riallocare e copiare i dati precedentemente immagazzinati? Oppure conviene allocare, in modo ragionevole, in modo statico la memoria, ad esempio il nostro array di stringhe, e se necessario passare ad allocare dinamicamente una nuova porizione di meria su cui copiare e continuare la roccolda dei dati ancora non memorizzati? Oppure non ha alcuna differenza?
Sei proprio fuori strada.

Se hai a che fare con "qualcosa" di cui non conosci la dimensione precisa, e neppure puoi stimarla con un grado ragionevole di precisione, ALLORA non ti conviene usare una struttura rigida, come un vettore (più o meno riallocato alla bisogna), bensì una struttura dati inerentemente dinamica.

SE invece puoi stimare - ragionevolmente - PUOI usare vettori.

Esempio: devi memorizzare gli studenti di una certa classe.
Potresti supporre siano 20, 30, quindi potresti allocare un vettore inizialmente di dimensione 100 ed essere ragionevolmente sicuro di non doverlo riallocare, se non in caso eccezionale.

Se invece devi memorizzare che so l'elenco degli studenti non vaccinati di un certo comune, difficilmente adotterai questa strategia, bensì (ad esempio) una lista, in cui allochi i singoli elementi uno alla volta.
Prestazioni minori, certo, ma niente "sbattimento".

"una volta" (con i processi a 8 o 16 bit) il problema era più sentito, coi 32 bit si è attenuato notevolmente, coi 64 ancor più.
ma continua a esistere e combattere insieme a noi

Infine, non so, se ti è capitato di vedere il codice che ho postato poco precedentemente - il quale mi dà errore - in cui tento di fare la realloc della dimensione riga del puntatore a puntatore. Nel caso dove sabglio?
Ehhh... non te la prendere, ma mi sono autoimposto di NON fare più questo genere di considerazioni.
Parecchi utenti la prendono malissima.
Meglio il quieto vivere.

PS non è un fatto personale che ti riguarda, non averne a male
Ciao +m2+,
comprendo la tua posizione. Ma con me puoi stare tranquillo. Prendersela a male? Se ami la conoscenza devi desiderare di ascoltare e comprendere il pensiero di chi ha più esperienza e maggiori conoscenze delle proprie.
Quando mi riferivo alle liste era per semplificare il ragionamento relativo al ridimensionamento. Provengo comunque dalla programmazione OO.

Quando dici:
+m2+ ha scritto:
Se invece devi memorizzare che so l'elenco degli studenti non vaccinati di un certo comune, difficilmente adotterai questa strategia, bensì (ad esempio) una lista, in cui allochi i singoli elementi uno alla volta.
Prestazioni minori, certo, ma niente "sbattimento".
A proposito di moli di dati non facilmente stimabili a priori, intendi alloco di "un'unità dati" e poi a ogni dato da aggiungere alloco nuovamente con "un'unità dati" in più ricopiando i dati precedenti? Scusa se mi esprimo in modo molto semplicistico.

Sto ripensando alle strutture dati complesse, per le quali si pensa di poter stimare in modo abbastanza precisamente l'ordine di grandezza della quantità di memoria necessaria, ma per quelle locazioni che, eventualmente, rimangono vuote al momento di una necessaria persistenza su disco andranno comunque a "pesare". Altro mondo si aprirà quando dovrò capire come rendere persistente una struttura che usa puntatori... Ad esempio se non ricordo male in C in una struttura (struct) posso avere solo un membro la cui dimensione non sia definita a compile time... In quel caso ho un po' le idee ancora non chiarissime. Ma un passo per volta, quando sarà il momento, nel caso, mi farò vivo

Grazie!
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Puntatori: array di dimensione variabile di stringhe di dimensione nota
03 ott 2018, 19:48
deckard ha scritto:
...
Ti servono degli approfondimenti sulle strutture dati, in particolare le liste

Devi accedere o registrarti per scrivere nel forum

29 risposte