Je me dis qu'en tant qu'auteur, je suis relativement bien placer pour user d'un "droit de réponse", que je vous remercie de m'accorder.
J'ai relevé certains commentaires sur lesquels je souhaite revenir, un peu à la manière de carabiniers d'offenbach. Il ne sont peut être pas dans l'ordre et je m'en excuse.
Le cas des valeur numérique
Je précise que je parle bel et bien de valeurs numérique entières constantes dans le livre, mais il faut avouer que, sorti de son contexte comme le cas est présenté ici, cela ne donne vraiment qu'une idée bien piètre de ce qui se trouve dans le livre.
Car je vais bien plus loin que de dire simplement "voici un #define, un static const et une énumération", je dresse aussi la liste des avantages, des dangers éventuels et des inconvénients des différentes techniques.
Forme canonique de Coplien, Rule of big three
J'ai veillé à faire un parallèle très clair entre la forme canonique et la règle des trois grands. J'en ai profité pour parler des (nouvelles!) règles applicables depuis la sortie de C++11 et des pointeurs intelligents. Mais comme l'a fait valoir LM HS, il n'y avait que très peu de ressources, aussi bien en français qu'en anglais, sur les conséquences de certains choix faits en C++11 au niveau de cette règle et de la Forme canonique de Coplien.
La comparaison (M)EC++ et GOTW
(More) Effective C++ et Guru Of The Week sont de véritables références, il n'y a pas lieu de discuter de ce point.
Mais ce sont des références particulièrement pointues qui abordent des points bien précis du C++. L'optique de mon livre est toute autre et tend à rappeler—car je suis sur que tout développeur expérimenté les connait—les principes généraux que l'on a trop souvent tendance à ne pas appliquer parce que "ca sert à rien" selon beaucoup trop de monde.
Pour ma part, j'estime que le fait d'appliquer directement et avec bon sens les principes que je rappelle dans mon livre permet réellement de rendre le développement plus facile, plus évolutif et plus aisément déboggable.
Mon but en écrivant cet ouvrage était réellement de rappeler et d'expliquer correctement ces principes, afin que les développeurs soient en mesure de comprendre quand et comment les appliquer. Cette approche est donc bel et bien totalement différente de EC++!
Coder Proprement
Voilà sans doute un ouvrage qui manque dans ma bibliothèque, car je ne l'ai pas lu. S'il est orienté vers java, il faut dores et déjà se dire qu'il risque, malheureusement, de prendre les restrictions imposées par ce langage comme acquises et définitives.
Il ne s'agit pas de remettre la philosophie imposée par java et par C# en question ici, car ce sont des philosophies tout ce qu'il y a de plus cohérentes. Mais il s'agit de rappeler que C++ a une philosophie différente, plus permissive, imposée par des choix conceptuels différents.
Limiter l'approche orientée objet à la seule philosophie de java (ou de C#) empêche bien souvent de prendre conscience du problème plein et entier tel qu'il se présente, tend à "amputer" la vision que l'on peut avoir du problème de pans entiers de celui ci.
J'ai choisi C++ à dessein, car non seulement sa philosophie est plus permissive, mais il permet aussi de mettre en place des solutions "originales" et élégantes.
# Réponses en vrac
Posté par koala01 . En réponse à la dépêche Coder efficacement, bonnes pratiques et erreurs à éviter. Évalué à 10.
Bonjour,
Je me dis qu'en tant qu'auteur, je suis relativement bien placer pour user d'un "droit de réponse", que je vous remercie de m'accorder.
J'ai relevé certains commentaires sur lesquels je souhaite revenir, un peu à la manière de carabiniers d'offenbach. Il ne sont peut être pas dans l'ordre et je m'en excuse.
Le cas des valeur numérique
Je précise que je parle bel et bien de valeurs numérique entières constantes dans le livre, mais il faut avouer que, sorti de son contexte comme le cas est présenté ici, cela ne donne vraiment qu'une idée bien piètre de ce qui se trouve dans le livre.
Car je vais bien plus loin que de dire simplement "voici un #define, un static const et une énumération", je dresse aussi la liste des avantages, des dangers éventuels et des inconvénients des différentes techniques.
Forme canonique de Coplien, Rule of big three
J'ai veillé à faire un parallèle très clair entre la forme canonique et la règle des trois grands. J'en ai profité pour parler des (nouvelles!) règles applicables depuis la sortie de C++11 et des pointeurs intelligents. Mais comme l'a fait valoir LM HS, il n'y avait que très peu de ressources, aussi bien en français qu'en anglais, sur les conséquences de certains choix faits en C++11 au niveau de cette règle et de la Forme canonique de Coplien.
La comparaison (M)EC++ et GOTW
(More) Effective C++ et Guru Of The Week sont de véritables références, il n'y a pas lieu de discuter de ce point.
Mais ce sont des références particulièrement pointues qui abordent des points bien précis du C++. L'optique de mon livre est toute autre et tend à rappeler—car je suis sur que tout développeur expérimenté les connait—les principes généraux que l'on a trop souvent tendance à ne pas appliquer parce que "ca sert à rien" selon beaucoup trop de monde.
Pour ma part, j'estime que le fait d'appliquer directement et avec bon sens les principes que je rappelle dans mon livre permet réellement de rendre le développement plus facile, plus évolutif et plus aisément déboggable.
Mon but en écrivant cet ouvrage était réellement de rappeler et d'expliquer correctement ces principes, afin que les développeurs soient en mesure de comprendre quand et comment les appliquer. Cette approche est donc bel et bien totalement différente de EC++!
Coder Proprement
Voilà sans doute un ouvrage qui manque dans ma bibliothèque, car je ne l'ai pas lu. S'il est orienté vers java, il faut dores et déjà se dire qu'il risque, malheureusement, de prendre les restrictions imposées par ce langage comme acquises et définitives.
Il ne s'agit pas de remettre la philosophie imposée par java et par C# en question ici, car ce sont des philosophies tout ce qu'il y a de plus cohérentes. Mais il s'agit de rappeler que C++ a une philosophie différente, plus permissive, imposée par des choix conceptuels différents.
Limiter l'approche orientée objet à la seule philosophie de java (ou de C#) empêche bien souvent de prendre conscience du problème plein et entier tel qu'il se présente, tend à "amputer" la vision que l'on peut avoir du problème de pans entiers de celui ci.
J'ai choisi C++ à dessein, car non seulement sa philosophie est plus permissive, mais il permet aussi de mettre en place des solutions "originales" et élégantes.