Stringa

[Andretti60]

- l'ultima parola non verrà contata in quanto viene cercato come token lo spazio;

Veramente no, strtok() considera il carattere di terminazione alla stessa stregua del carattere di separazione, quindi l'ultima parte della stringa viene sempre riportata.
Piuttosto stiamo attenti ai doppi spazi, strtok() puo' tornare una stringa di lunghezza zero, quindi tmp[strlen(tmp)-1] causa errore.

 

[toni1705]

Per forza, ci sono 2 problemi:

- devi accedere alla posizione 0 di tmp, e non alla posizione i;
- l'ultima parola non verrà contata in quanto viene cercato come token lo spazio;

se immetti infatti "allarme alle amare ", vedrai 3 parole (a patto di accedere a tmp[0]).

come faccio a contare ance l'ultima parola >.<?
--- i due messaggi sono stati uniti ---

Veramente no, strtok() considera il carattere di terminazione alla stessa stregua del carattere di separazione, quindi l'ultima parte della stringa viene sempre riportata.
Piuttosto stiamo attenti ai doppi spazi, strtok() puo' tornare una stringa di lunghezza zero, quindi tmp[strlen(tmp)-1] causa errore.

sono confuso ora :/

 

[Sysken]

Considerando che ogni parola sia separata da un solo spazio:

#include <stdio.h>
#include <string.h>

int num_of_ae(char string[]);

int main(void){
    char string[100];
    printf("\n%s", " >> Frase: ");
    fgets(string, 100, stdin);
    string[strlen(string)-1] = '\0'; 
    int counter = num_of_ae(string);
    printf("\n%s%d", " >> Numero di parole a___e: ", counter);
}

int num_of_ae(char string[]){
    int counter = 0;
    char *subString = strtok(string, " ");
    while(subString != NULL){
        if(subString[0] == 'a' && subString[strlen(subString)-1] == 'e'){
            counter++;
        }
        subString = strtok(NULL, " ");
    }
    return counter;
}

In questo caso il problema deriva dal fatto che fgets memorizza anche il carattere di newline (quindi l'ultima parola risulta essere xyz\n e l'ultimo carattere \n è sicuramente diverso da e), che come puoi vedere nel main, ho sostituito con un carattere di terminazione.

 

[Andretti60]

sono confuso ora :/

Lascia stare, sono io che non ricordavo bene, strtok() non ritorna mai un token di lunghezza zero, per cui puoi mettere quanti spazi vuoi rra una parola e l'altra.

 

[toni1705]

Considerando che ogni parola sia separata da un solo spazio:

#include <stdio.h>
#include <string.h>

int num_of_ae(char string[]);

int main(void){
    char string[100];
    printf("\n%s", " >> Frase: ");
    fgets(string, 100, stdin);
    string[strlen(string)-1] = '\0';
    int counter = num_of_ae(string);
    printf("\n%s%d", " >> Numero di parole a___e: ", counter);
}

int num_of_ae(char string[]){
    int counter = 0;
    char *subString = strtok(string, " ");
    while(subString != NULL){
        if(subString[0] == 'a' && subString[strlen(subString)-1] == 'e'){
            counter++;
        }
        subString = strtok(NULL, " ");
    }
    return counter;
}

In questo caso il problema deriva dal fatto che fgets memorizza anche il carattere di newline (quindi l'ultima parola risulta essere xyz\n e l'ultimo carattere \n è sicuramente diverso da e), che come puoi vedere nel main, ho sostituito con un carattere di terminazione.

ok quindi hai praticamente usano una strlen affinchè legga il numero dei caratteri al penultimo carattere aggiunge un terminatore e a da li
la funzione confronta il primo e ultimo carattere.
e ritorna il contatore giusto?

 

[Sysken]

Quale strlen intendi, quello nel main?

 

[toni1705]

Quale strlen intendi, quello nel main?

si quello nel main. Hai usato string[strlen(string)-1]='\0'
perchè la fgets conta come ultimo carattere il newline.
di conseguenza bisognava specificare che l'ultimo carattere fosse della stringa in modo da poter effettuare il ciclo giusto?

 

[Sysken]

Ho eliminato il carattere finale di newline altrimenti sarebbe stato considerato come un normalissimo carattere, proprio come e, ed è proprio per quello che non considerava l'ultima parola, perchè la condizione dell'if non era mai verificata.

 

[Andretti60]

Oppure, più semplicemente, aggiungi il newline come carattere di separazione nel secondo parametro della strtok(), ricorda che puoi specificare quanti separatori vuoi (non sarebbe male aggiungere anche il tabulatore “ \n\t" )

 

[toni1705]

Oppure, più semplicemente, aggiungi il newline come carattere di separazione nel secondo parametro della strtok(), ricorda che puoi specificare quanti separatori vuoi (non sarebbe male aggiungere anche il tabulatore “ \n\t" )

ottima idea !!!
grazie a tutti !! :D

 

[pabloski]

Penso che riferimento all'architettura ARM abbia contribuito a chiarire molto le idee all'OP. Complimenti per la nozione indispensabile.

In verità quello che ha scritto è davvero importante, soprattutto per capire il perchè c'è gente in giro che parla male del C ( e anche del C++ per estensione ).

Quando ha descritto le stringhe ha fatto emergere il dramma di chi dovrà usare codifiche non ASCII, specialmente UTF-8. Farci i conti è una bella impresa. MS tagliò corto e decise di usare UTF-16 ( anche per altri motivi in verità ) che semplifica i calcoli per la lunghezza e la gestione delle stringhe multibyte.

Altro problema è quello che emerge dall'esempio sull'architettura ARM. Cioè quando scrivi il programma devi fare i conti col processore e come implementa l'accesso ai dati in memoria. In Python ( per citare un linguaggio ) te ne freghi.

E in tutto questo l'OP vedo che non ha molta dimestichezza con l'implementazione delle stringhe in C, cosa che ovviamente gli complica parecchio la vita.

 

[rctimelines]

In verità quello che ha scritto è davvero importante, soprattutto per capire il perchè c'è gente in giro che parla male del C ( e anche del C++ per estensione ).

Quando ha descritto le stringhe ha fatto emergere il dramma di chi dovrà usare codifiche non ASCII, specialmente UTF-8. Farci i conti è una bella impresa. MS tagliò corto e decise di usare UTF-16 ( anche per altri motivi in verità ) che semplifica i calcoli per la lunghezza e la gestione delle stringhe multibyte.

Altro problema è quello che emerge dall'esempio sull'architettura ARM. Cioè quando scrivi il programma devi fare i conti col processore e come implementa l'accesso ai dati in memoria. In Python ( per citare un linguaggio ) te ne freghi.

E in tutto questo l'OP vedo che non ha molta dimestichezza con l'implementazione delle stringhe in C, cosa che ovviamente gli complica parecchio la vita.

Se vuoi aggiungere tue riflessioni sull'implementazione delle stringhe in C sei liberissimo di farlo.. non serve la citazione dei miei commenti perché, se leggi, non si riferisce a quello. Probabilmente sei esperto di linguaggi per computer, ma non interpreti bene l'italiano: pare che le conoscenza dell'OP siano davvero elementari e forse anche non molto corrette, quel riferimento all'architettura ARM pare più una volontà di mettere un mostra conoscenza piuttosto che un aiuto all'OP per quello che vuole fare.. per cui superfluo!

Se poi vogliamo discutere sull'opportunità di cercare un carattere all'interno di un array di caratteri, diciamo che la problematica posta dall'OP la vedo piuttosto distante dalla sua implementazione in un linguaggio particolare e quindi anche dalla modalità di rappresentazione delle stringhe in C o addirittura dalla gestione hardware.

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[pabloski]

pare che le conoscenza dell'OP siano davvero elementari e forse anche non molto corrette, quel riferimento all'architettura ARM pare più una volontà di mettere un mostra conoscenza piuttosto che un aiuto all'OP per quello che vuole fare.. per cui superfluo!

Ovviamente l'OP è fermo alle basi. Citare le caratteristiche dell'architettura ARM non l'avrà sicuramente aiutato a capire come risolvere il suo problema, però può aiutarlo a capire quanto fallaci siano considerazioni del tipo "una stringa è un'insieme di scatole legate tra di loro".

Poi Sysken ha anche descritto come C tratta le stringhe a basso livello, cosa che è fondamentale per chiunque voglia usare le stringhe in questo linguaggio.

Se poi vogliamo discutere sull'opportunità di cercare un carattere all'interno di un array di caratteri, diciamo che la problematica posta dall'OP la vedo piuttosto distante dalla sua implementazione in un linguaggio particolare e quindi anche dalla modalità di rappresentazione delle stringhe in C o addirittura dalla gestione hardware.

Purtroppo no. Se in Python la gestione a basso livello delle stringhe è affare del linguaggio, in C è affare del programmatore. Chiunque abbia programmato in Win32 ricorderà che per le stringhe c'erano due famiglie di funzioni, quelle A ( ascii ) e quelle W ( multibyte ). Se c'aggiungiamo che le architetture di cpu possono complicare ulteriormente la cosa, diventa drammatico. Ovviamente l'OP programmare su x86 e quest'ultima parte non gl'interessa.

Però è sempre buono a sapersi. Anche per lui.

 

[rctimelines]

Ovviamente l'OP è fermo alle basi. Citare le caratteristiche dell'architettura ARM non l'avrà sicuramente aiutato a capire come risolvere il suo problema, però può aiutarlo a capire quanto fallaci siano considerazioni del tipo "una stringa è un'insieme di scatole legate tra di loro".

Poi Sysken ha anche descritto come C tratta le stringhe a basso livello, cosa che è fondamentale per chiunque voglia usare le stringhe in questo linguaggio.



Purtroppo no. Se in Python la gestione a basso livello delle stringhe è affare del linguaggio, in C è affare del programmatore. Chiunque abbia programmato in Win32 ricorderà che per le stringhe c'erano due famiglie di funzioni, quelle A ( ascii ) e quelle W ( multibyte ). Se c'aggiungiamo che le architetture di cpu possono complicare ulteriormente la cosa, diventa drammatico. Ovviamente l'OP programmare su x86 e quest'ultima parte non gl'interessa.

Però è sempre buono a sapersi. Anche per lui.

Se per lui una stringa è un " insieme di scatole" (spero almeno ordinato!) continui a credere che le considerazioni su hardware x86 o ARM, non solo per lui non abbiano alcun significato (figurati se può essere buono a sapersi) ma non sa neppure di cosa state parlando.. gli create solo confusione! questo era il senso del mio commento.. semplicemente!

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[Sysken]

@rctimelines
Non voglio mettere in mostra nessuna mia conoscenza, mi ritengo un dilettante, ho preso di spunto l'architettura ARM solo per chiarire il come venisse gestita una stringa in C, sopratutto denotando come viene effettuato l'acceso ad una locazione.