[C++] Array Palindromo

[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.