Ce que tu me decrit la, c'est exactement la List de java.
Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.
D'un autre côté, en C++, quand tu utilises un objet de classe vector, tu as deux accès possibles :
1) v.at(i), où v renverra une exception si tu fais un dépassement, et
2) v[i], où aucune exception ne sera levée, mais qui va bien plus vite en terme de latence d'accès aux éléments du vecteur.
Il n'y a donc pas de réelle « bonne façon de faire » pour des tableaux dynamiques. Parce que les exceptions c'est très bien, c'est très pratique et tout, mais à en foutre partout, on finit par plomber les perfs à cause des indirections, de l'effet « goto » qui force à se référer plus ou moins constamment à la doc (« le "goto" c'est maaaaaaaaaaaaaaal, fais plutôt des exceptions ! »), etc.
[^] # Re: Code le toi même
Posté par lasher . En réponse à la dépêche Sortie de Moonlight 1.0. Évalué à 3.
Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.
D'un autre côté, en C++, quand tu utilises un objet de classe vector, tu as deux accès possibles :
1) v.at(i), où v renverra une exception si tu fais un dépassement, et
2) v[i], où aucune exception ne sera levée, mais qui va bien plus vite en terme de latence d'accès aux éléments du vecteur.
Il n'y a donc pas de réelle « bonne façon de faire » pour des tableaux dynamiques. Parce que les exceptions c'est très bien, c'est très pratique et tout, mais à en foutre partout, on finit par plomber les perfs à cause des indirections, de l'effet « goto » qui force à se référer plus ou moins constamment à la doc (« le "goto" c'est maaaaaaaaaaaaaaal, fais plutôt des exceptions ! »), etc.