> Ne pas prendre la responsabilité d'allouer de l'espace mémoire permet de
> laisser au client le choix de l'allocateur, du type de mémoire (automatique ou
> dynamique), etc.
Heu, le gros problème du C c'est que tu dois te coltiner la gestion de la mémoire toi même justement et qu'il est facile de faire des erreurs. Si la fonction gère la mémoire à la place de l'appelant, ça fait beaucoup mois de possibilités d'erreurs.
Après, il y a des cas où utiliser un buffer static ne correspond pas aux besoins de l'appelant mais alors tu fais une variante fonction_r().
Quant à la sois disant perte de performance dûe à l'initialisation, charger un octet en mémoire (ou même 1024 octets) me semble passablement moins couteux que de faire un malloc().
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Sécurité ?
Posté par Krunch (courriel, site web personnel) . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 4.
> laisser au client le choix de l'allocateur, du type de mémoire (automatique ou
> dynamique), etc.
Heu, le gros problème du C c'est que tu dois te coltiner la gestion de la mémoire toi même justement et qu'il est facile de faire des erreurs. Si la fonction gère la mémoire à la place de l'appelant, ça fait beaucoup mois de possibilités d'erreurs.
Après, il y a des cas où utiliser un buffer static ne correspond pas aux besoins de l'appelant mais alors tu fais une variante fonction_r().
Quant à la sois disant perte de performance dûe à l'initialisation, charger un octet en mémoire (ou même 1024 octets) me semble passablement moins couteux que de faire un malloc().
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.