To: devmail@infomedia.it From: Andrea Griffini Subject: Array associativi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Salve... Vi scrivo per esprimere il mio disappunto relativamente all'articolo "Array Associativi" comparso sul numero di Luglio/Agosto di DEV. In particolare ho trovato che: - L'articolo mostra una soluzione alquanto ingenua della problematica dal punto di vista dell'algoritmo proposto (ricerca sequenziale), fornendo poi direzioni di investigazione discutibili (ordinamento tramite qsort e uso della ricerca dicotomica con bsearch). Le implementazioni di array associativi sono spessissimo basate su tecniche di hashing e nell'articolo non se ne fa menzione alcuna. L'impressione netta e' che chi ha scritto l'articolo non abbia mai implementato realmente array associativi. - La soluzione proposta che si basa su overload dell'operatore di accesso a elemento di array e' sicuramente interessante ma la parte di gestione dell'operatore di preincremento e' totalmente errata. Oltretutto l'operatore che viene definito agisce sull'intero vettore e non sull'elemento; tutta la parte relativa all'operatore '++' che viene descritta nell'articolo non viene in realta' mai utilizzata dal codice di esempio mostrato. A parte questa svista grossolana, anche l'idea di incrementare l'ultimo elemento a cui aveva acceduto l'operatore "[...]" e' a mio parere molto bizzarra: in genere nella programmazione object-oriented una delle cose a cui bisogna prestare attenzione e' la presenza di "effetti collaterali" non espliciti nelle chiamate di metodi/operatori. Che l'operatore di accesso ad elemento di array cambi l'elemento "corrente" su cui agiscono altri operatori e' alquanto pericoloso. - Il codice di esempio utilizza anche tecniche decisamente poco eleganti quali la riallocazione di un vettore ad ogni aggiunta di un elemento. Questo e' il genere di cose che a mio parere non bisognerebbe insegnare a chi si avvicina alla programmazione. Riassumendo ho trovato che l'articolo non fosse di grande aiuto per chi volesse apprendere come si implementa un array associativo, per chi volesse comprendere come si programma in C++ o per chi volesse vedere in genere come si programma. La cosa mi e' molto spiaciuta perche' DEV e' una rivista che in molte altre occasioni ho trovato veramente interessante: io ho iniziato a programmare qualche anno fa (ai tempi dell'Apple ][) e DEV e' il tipo di rivista che mi sarebbe sicuramente piaciuto avere per le mani. Andrea Griffini ---------------------------------------------------------- From: Matteo Baccan Reply-To: baccan@infomedia.it To: Andrea Griffini Subject: Re: Array associativi Organization: Infomedia X-mailer: FoxMail 2.1 [en] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <19990723065913.CEUK11176.fep03-svc@ntserver.cannobio.net> >Salve... > >Vi scrivo per esprimere il mio disappunto relativamente all'articolo >"Array Associativi" comparso sul numero di Luglio/Agosto di DEV. >In particolare ho trovato che: Ho rigirato le osservazioni a Andrea Frosini, l'autore dell'articolo Matteo Baccan DEV and Login Technical Writer ---------------------------------------------------------- To: agriff@tin.it From: "Andrea T.M. Frosini" Subject: Subject: Array associativi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Salve, le sue righe hanno evidenziato l'errore commesso nella gestione dell'overload dell'operatore ++. Nell'esempio proposto, non ho prestato attenzione al "non" uso dell'overload dell'operatore ++ che, essendo pensato per lavorare su di un oggetto, non ha significato su di un reference al membro di tipo intero della classe CArAssoc. Per l'esempio, ritengo appropriata la scelta didattica di usare un vettore come struttura dati poiche' essa e' estremamente intuitiva. In apertura articolo ho menzionato una possibile gestione a liste, ma non la gestione hash poiche' essa non e' tipica del bagaglio algoritmico del lettore a cui l'articolo si riferisce. Al fine di evitare di spostare l'attenzione del lettore su lati tecnici secondari dell'argomento, ho optato per le scelte implementative che mi sono parse maggiormente comprensibili al lettore, e per le quali sono richieste minori conoscenze tecniche. E' cosi' giustificato l'uso della coppia malloc/realloc al posto delle classiche new/delete[], unitamente ad una gestione piu' efficiente come ad esempio il caching di memoria. Cordiali Saluti, Andrea Frosini.