[C++] Array Palindromo

[GhL]

Salve a tutti. Devo realizzare un programma che verifichi se un array di caratteri è palindromo oppure no.

L'idea iniziale è quella di confrontare il primo indice con l'ultimo utilizzando due cicli for e così via. Il problema che ho riscontrato è che il programma mi valuta solo l'ultimo confronto effettuato e non l'intero array.

questo è mio codice per adesso:

 
int confronta() {
    int n=6;
    char pal[]={'a','b','c','c','b','a'};
    bool v;
    int i, j;
    for (i=0; i<n/2; i++) {
        for (j=n-1; j>=n/2; j--) {
            if (pal[i]==pal[j]) {
                v=true;
            }
        }
    }
    if (v==true) {
        cout << "Palindroma";
    }
    else if (v==false){
        cout << "No palindroma";
    }
    return 0;
}

[oregon]

Non devi usare due cicli, è sbagliato e ne basta uno

[Eduadie]

Oltre al consiglio che ti è stato dato da Oregon, l'errore sta che anche se c'è nel mezzo dell'array due elementi che non rispettano la condizione palindroma comunque non viene "notificata" al tuo programma perchè come hai detto tu tiene conto solo dell'ultimo controllo.
Un suggerimento potrebbe essere quello di ragionare per negazione e cioè controllare se l'i-simo elemento non è uguale al suo opposto nell'array e nel caso settare v a false mentre farlo partire di default a true.

Magari se v diventa false interrompere il ciclo con un break.

[cisco87]

Io l'ho fatto per un colloquio passato un programma del genere e quindi so che uno degli approcci corretti/apprezzati e' scrivere una funzione che ritorni l'array/stringa reversed e poi comparare le 2 stringhe e vedere se sono uguali

Nel tuo caso comunque tu setti sempre v a true, e mai a false e non controlli mai se v sia gia' settato a false prima di ri-settarlo a true

[M.A.W. 1968]

Io l'ho fatto per un colloquio passato un programma del genere e quindi so che uno degli approcci corretti/apprezzati e' scrivere una funzione che ritorni l'array/stringa reversed e poi comparare le 2 stringhe e vedere se sono uguali

Non so dove e come tu abbia sostenuto codesto colloquio, ma in tutta franchezza, presentandosi con una "soluzione" del genere nella multinazionale in cui lavoro o nelle altre che conosco, il risultato sarebbe solo un secco e anticipato "Si accomodi... le faremo sapere".

Non si vede per quale arcano motivo si debba avallare, sia pure in sede di colloquio, una funzione che spreca il doppio di spazio e circa il quadruplo di tempo di esecuzione rispetto alla più ovvia soluzione in-place, che non richiede storage aggiuntivo eccetto al più un puntatore o un indice ausiliario, e richiede unicamente n/2 confronti, dove n è la lunghezza della stringa data.
La "soluzione" prospettata è semplicemente un disastro, n operazioni per copiare la stringa invertita, seguite da altri n confronti entro la strcmp() o simili, e lo storage aggiuntivo necessario per la seconda (inutile) copia della stringa... qui parliamo proprio di ABC, caratteristiche elementari del codice esplicitamente e oggettivamente misurabili in termini di complessità e metriche comuni (function points, McCabe, Halstead...), non certo di discutibili questioni stilistiche o funzioni di libreria sulle quali da anni si polemizza nella comunità dei teorici.

Per il topic in particolare, si veda anche questo thread.

[cisco87]

Non so dove e come tu abbia sostenuto codesto colloquio, ma in tutta franchezza, presentandosi con una "soluzione" del genere nella multinazionale in cui lavoro o nelle altre che conosco, il risultato sarebbe solo un secco e anticipato "Si accomodi... le faremo sapere".

Non si vede per quale arcano motivo si debba avallare, sia pure in sede di colloquio, una funzione che spreca il doppio di spazio e circa il quadruplo di tempo di esecuzione rispetto alla più ovvia soluzione in-place, che non richiede storage aggiuntivo eccetto al più un puntatore o un indice ausiliario, e richiede unicamente n/2 confronti, dove n è la lunghezza della stringa data.
L'altra "soluzione" è semplicemente un disastro, n operazioni per copiare la stringa invertita, seguite da altri n confronti entro la strcmp() o simili, e lo storage aggiuntivo necessario per la seconda (inutile) copia della stringa... qui parliamo proprio di ABC, caratteristiche elementari del codice esplicitamente e oggettivamente misurabili in termini di complessità e metriche comuni (function points, McCabe, Halsted...), non certo di discutibili questioni stilistiche o funzioni di libreria sulle quali da anni si polemizza nella comunità dei teorici.

Per il topic in particolare, si veda anche questo thread.

Meno male allora che non ho applicato per la multinazionale per la quale lavori

Se mi permette il motivo e' molto semplice, una funzione deve svolgere una sola operazione e solo quello deve essere il motivo per il quale questa deve essere modificata (Clean code, Bob C. Martin et al.)

Questo facilita lo Unit Testing, e il riutilizzo.

Secondo il mio punto di vista, e di gente tipo Uncle Bob o Martin Fowler, la chiarezza del codice, lo scrivere brevi e chiare funzioni e' molto piu' importante della velocita' con il quale il codice viene eseguito. Fare l'upgrade per migliorare la potenza di calcolo costa molto meno di un codice poco chiaro e difficilmente mantenibile.

Come vede al mondo ci sono molti punti di vista, ed e' possibile crescere confrontandosi civilmente senza il tavernello sulla scrivania che genera pensieri che possono essere ritenuti offensivi.

[cisco87]

Aggiungo un quote che tanti potrebbero trovare utile:

"Premature optimization is the root of all evil"
Donald Knuth, che non lavorava per una multinazionale pero' ha vinto un premio Turing

[M.A.W. 1968]

Non è francamente possibile trincerarsi dietro la scusa che il codice per il confronto in-place sia meno leggibile o manutenibile della soluzione più farraginosa. Non caso Fowler e tutta la banda dei "modernist" dell'agile programming sono molto malvisti nella comunità del software engineering, è sufficiente cercare qualche articolo in merito sull'organo ufficiale dell'AICA, giusto per restare alla provinciale Italietta: non c'è legge di Moore che possa emendare una scelta algoritmica così inefficiente, laddove esiste un'alternativa banale (e perfettamente leggibile, il contrario è tutto da dimostrare).

Quanto alle "offese", mah. Qui si giudicano e si confrontano metriche, soluzioni, idee e punti di vista asseverati nella comunità del software engineering, con un occhio di riguardo al mondo dei sistemi critici, dal quale il mainstream ha tutto da imparare, fatti salvi i relativi fattori di costi e tempi. Di altre cose, civilmente, non me ne frega alcunché.

E no, questa non è certo una ottimizzazione prematura: è solo la differenza tra pensare da informatico, o buttare lì la prima soluzione che viene in mente. E' esattamente la stessa differenza che intercorre tra un bubblesort e il quicksort.

[cisco87]

Beh io non ho mai incontrato nessuno che utilizzasse i testi di C. Martin e Fowler come compagni di avventura, oltretutto ho cercato articoli riguardanti Fowler su http://www.aicanet.it/search?SearchableText=fowler e non esce alcun risultato. Siamo sicuri che qualche volta non sia il caso di ammettere che si e' stati troppo precipitosi nell'inviare una risposta o tacere?

Comunque lei ha un cervello molto limitato e un comportamento molto saccente e fastidioso, che si denota anche dall'uso di termini come "italietta", ma a chi deve dimostrare cosa?

[M.A.W. 1968]

Il fatto è che semplicemente non esistono giustificazioni per presentare un codice così scadente, etichettandolo addirittura come "corretto e apprezzato". Ho già apportato argomentazioni più che sufficienti per la mia obiezione, che è peraltro assolutamente autoevidente e oggettiva: ti sei posto in una posizione decisamente ridicola già in partenza, difendendo l'indifendibile e in seguito tirando in ballo le vacue stupidaggini agile, con una simpatica arrampicata sugli specchi. Pare evidente che ti mancano le basi di software engineering necessarie a comprendere quanto ho velocemente affermato.

Quanto agli articoli AICA, Ghezzi e Monga su "Mondo Digitale" (questo era il link originale, citato anche in questi lucidi, purtroppo non più valido, il che non è certo un problema mio, che ho letto il cartaceo!) hanno demolito le pretese del movimento agile già molti anni fa, e non sono certo i soli. Ma temo che semplicemente tu non sia interessato a capire la reale collocazione delle idee di Fowler, Beck e soci nel più ampio panorama dell'engineering, probabilmente anche per la mancanza di basi o di reale necessità. In fondo, nel mainstream "everything goes", per citare Feyerabend.

PS: Le mie risposte non sono mai precipitose. Ma vanno lette e meditate con attenzione e senza ridicoli personalismi. Scardinare le credenze erronee è parte del mio mestiere.