Vos reflections sur «La conception de logiciels C ++ à grande échelle»

En lisant les critiques sur Amazon et ACCU, on peut lire que le livre de John Lakos, Conception de logiciels C ++ à grande échelle, pourrait être la pierre de Rosetta pour la modularisation.

Dans le même temps, le livre semble être très rare: peu de lecteurs l’ont lu, et aucun exemplaire électronique pirate ne circule.

Alors qu’est-ce que tu en penses?

Je l’ai lu et je le considère comme un livre très utile sur des problèmes pratiques liés aux grands projets C ++. Si vous avez déjà lu beaucoup de choses sur le C ++, et si vous en savez un peu plus sur la conception physique et ses implications, vous ne trouverez peut-être pas ce qui est terriblement “nouveau” dans ce livre.

Par contre, si votre version prend 4 heures et que vous ne savez pas comment la réduire, obtenez-en une copie, lisez-la et intégrez-la.

Vous commencerez à écrire du code physiquement mieux rapidement.

[Edit] Si vous voulez commencer quelque part, et que vous ne pouvez pas immédiatement saisir le livre, j’ai trouvé la série Games From Within sur la structure physique utile même après avoir lu la conception C ++ à grande échelle.

Fait intéressant, “More C ++ Gems” contient une version abrégée (à 88 (!) Pages) du livre de Lakos, qui peut également être consulté (entièrement, je crois, car il appartient à la première moitié du livre) en ligne sur Google books. .

Alors, profitez de tout le monde intéressé 🙂

Lakos travaillait pour Mentor Graphics, qui fabrique des logiciels EDA. Il était impliqué dans la construction de logiciels EDA en C ++, où ils souhaitaient utiliser efficacement C ++ (pas plus de 5% de code C par rapport au code C) et comment construire des logiciels sur les premières stations de travail. grande application C ++.

Le livre est une bonne lecture – il aborde une grande variété de sujets, et Lakos connaissait vraiment ses affaires. Il a vraiment besoin de disposer d’un code efficace à partir d’un compilateur C ++, ainsi que de configurer un programme C ++ afin qu’il soit maintenable et qu’il comstack et lie assez rapidement.

Je pense que Lakos a beaucoup de perspicacité, et je vous recommande de le lire. Cependant, il s’agit de C ++ «trad» à une époque où les fonctionnalités telles que les modèles étaient largement disponibles. Ma copie n’est pas à vendre ^)

Je pensais que le livre était une bonne lecture à la fin des années 1990. Il était obsolète à l’époque, maintenant à peu près aussi pertinent que l’annuaire téléphonique des années 1950.

J’ai travaillé avec Lakos pendant plusieurs années où il a essayé de mettre en œuvre ces idées. J’ai aussi eu mon projet C ++ moderne que j’ai construit avec environ 2000 fichiers sources, à grande échelle, et j’en ai construit quelques autres depuis. Les temps de construction sont facilement réduits par des builds parallèles dissortingbués, utilisant des programmes comme icecream. Chaque client mettra en cache les en-têtes ouverts – ce n’est qu’en faisant quelque chose de vraiment scandaleux qu’un outil de construction moderne tel que Scons s’adaptera à des milliers d’unités de traduction sans faire quelque chose de spécial.

Limiter l’interface de votre bibliothèque à quelques “types de vocabulaire” (pas le même sens que le concept OO, il signifie simplement utiliser Int, float, ssortingng, char, et quelques autres, je ne m’en souviens pas) est un conseil extrêmement difficile à mettre à l’échelle n’importe quoi. Votre build va chercher une incompatibilité de type, vous ne le voulez pas à l’exécution juste pour faciliter l’écriture d’un fichier make.

Et c’est en grande partie l’essentiel du livre: comment écrire en C ++ pour qu’il fonctionne avec les outils de 1993? De plus, le projet Mentor Graphic décrit dans le livre était un désastre pour tous les comptes. Même le livre lui-même y fait allusion.

Large Scale C ++ est livré sous forme de code source – ce sont les “dépendances physiques”, pas les bibliothèques de liens (et le livre ne mentionne jamais d’autres dépendances plus importantes comme les bases de données, les sockets, l’architecture de processeur, etc.).

Le livre regorge d’idées qui sonnent bien, mais il existe de bien meilleurs moyens de les mettre en pratique. Si vous souhaitez étudier les grandes bibliothèques C ++, consultez Boost ou Xerces et voyez ce qu’ils ont fait. Ils mettent vraiment en œuvre de grands projets, sans écrire à leur sujet.

Est-ce que «la conception de logiciel C ++ à grande échelle» par John Lakos est une gemme (mais généralement négligée) qui suscite la reflection?

Oui

C’est un peu dépassé (en fait, il était obsolète au moment de la rédaction). Si je me souviens bien, il s’agissait en grande partie de réduire les dépendances que vous feriez probablement maintenant avec les modèles.

Bien que ce soit probablement l’une des leçons à tirer des projets à grande échelle, vous n’utilisez généralement pas de fonctions et d’outils de pointe.

C’est un excellent livre et un livre important du sharepoint vue historique.

Notez que pour mettre en œuvre les pratiques décrites dans le livre, vous avez besoin d’une discipline et d’un accord considérables au sein de l’équipe. Voici quelques points à noter:

  1. Lakos a des définitions précises de ce qu’il appelle “composants” et “packages”. Celles-ci sont essentielles pour la conception à grande échelle. Cependant, ils nécessitent le respect des conventions relatives à la manière dont les fichiers source et en-tête sont nommés et la séquence dans laquelle ils sont inclus. Il est dommage que la plupart des gens (y compris ceux qui citent les Lakos) suivent rarement ces conventions.

  2. Le livre est tout au sujet de C ++ mais les concepts sont plus largement applicables. Cependant, C ++ étant un langage si complexe, une grande partie du livre vous apprend à utiliser C ++ efficacement. Si vous réussissez, vous pouvez le trouver utile même si vous utilisez d’autres langues.

  3. Certaines des prescriptions telles que l’utilisation des “espaces de nommage” peuvent être considérées comme controversées maintenant. Beaucoup pensent que les espaces de noms doivent être utilisés de manière limitée en C ++.

Oui, à certains égards, le livre est un peu daté et certains sont spécifiques à C ++. Néanmoins, il offre de nombreux conseils utiles sur la gestion de la complexité et du couplage dans les grands programmes, et la plupart de ses conseils s’appliquent à tout langage orienté object. Je l’ai également trouvé très lisible.

Si vous pouvez retrouver une copie, je suis sûr que vous en trouverez la peine. C’est dans ma liste des dix meilleurs livres de programmation.

Je l’ai lu il y a longtemps, mais je m’en souviens beaucoup; Cependant, comme MadKeithV l’a fait remarquer, c’est peut-être parce que j’en savais moins;)

Certainement, du sharepoint vue de la réduction de la durée de compilation, il y a beaucoup de choses utiles, en particulier pour réduire les dépendances de compilation, même si certaines ne sont plus pertinentes, voire même possibles. ces jours-ci.

Et non, vous ne pouvez pas avoir ma copie non plus 🙂

Je veux append à toutes ces réponses qu’il n’est utile que pour C, car ce langage présente des problèmes avec l’en-tête de l’en-tête. Certains conseils sont plutôt inutiles aujourd’hui, comme l’inclusion de gardes qui sont maintenant effectués par le compilateur ou le regroupement des en-têtes lorsque vous utilisez mieux quelques en-têtes précompilés (un pour chaque paquet).

Si vous me demandez si cela vaut la peine d’acheter, alors je réponds: Seulement si vous êtes débutant en développement C / C ++. Les problèmes actuels du monde C ++ actuel (modèles et modèles et déjà mentionné des modèles) ne sont pas réunis.

Mais je viens de regarder le livre à nouveau. Cela me donne de bons souvenirs et me dit encore une fois pourquoi cette langue est tout simplement si mauvaise et doit être remplacée.