🚀 go-pugleaf

On Jul 30, 10:09 pm, Falk Tannhäuser <tannhauser86549s...@free.fr>
wrote:
> James Kanze schrieb:

> > On Jul 30, 12:27 am, Falk Tannhäuser <tannhauser86549s...@free.fr>
> >>    // Find global character statistics and key length
> >>    std::map<unsigned char, unsigned> stat;

> > Seulement curiosité, mais est-ce qu'il y a une raison pour
> > std::map, plutôt que :
> >     std::vector< unsigned > stat( UCHAR_MAX + 1 ) :
> > (ce que j'aurais fait). En fin de compte, ton « indice »,
> > c'est bien un petit entier non-négatif, ce qui correspond à
> > l'utilisation classique de vector (voire même un tableau de
> > type C

> Non, pas de raison particulière, sauf que je n'avais pas envie
> de me prendre le choux :-) La version avec std::vector ou
> tableau doit bien être plus performant (moins d'allocations
> dynamiques, temps d'accès O(1) contrairement à O(log N) pour
> std::map) et prendre moins de mémoire, mais vu la faible
> quantité de données à traiter la différence reste
> imperceptible.

Je ne pensais pas particulièrement à la performance. C'est juste
qu'en mon esprit, la collection par défaut, c'est std::vector.
Je ne m'en écarte que s'il y une raison : le fait que l'indice
ne soit pas un type entier, par exemple, ou que les indices
potentielles sont telles que ça risque de dépasser une
utilisation raisonable de la mémoire (p.e. des numéros de
sécurité sociale, traités comme des entiers).

Mais c'est peut-être simplement une vieille habitude de ma
part. Dans le cas qui nous intéresse, les indices sont des
caractères, qui conceptuellement ne sont pas des entiers.
Seulement, j'ai tellement travaillé dans l'informatique de bas
niveau que je n'arrive pas toujours à en faire l'abstraction ;
je n'oublie jamais que les caractères sont des entiers.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34