Sus pensamientos sobre "Diseño de software de C++ a gran escala"

architecture package-design (10)

Leer los comentarios en Amazon y ACCU sugiere que el libro de John Lakos, el diseño de software de C ++ a gran escala, puede ser el Rosetta Stone para la modularización.

Al mismo tiempo, el libro parece ser muy raro: no muchos lo han leído alguna vez, y no hay copias piratas electrónicas flotando.

¿Entonces, qué piensas?

Curiosamente, "Más gemas de C ++" contiene una versión abreviada (a 88 (!) Páginas) del libro de Lakos, que también se puede examinar (en su totalidad, creo, ya que pertenece a la primera mitad del libro) en línea en los libros de Google. .

Entonces, disfruta a todos los interesados :)

Es un libro excelente y uno importante desde el punto de vista histórico.

Tenga en cuenta que para implementar las prácticas descritas en el libro, necesita considerable disciplina y acuerdo dentro del equipo. Aquí hay algunas cosas a tener en cuenta:

Lakos tiene definiciones precisas para lo que él llama "componentes" y "paquetes". Estas son claves para el diseño a gran escala. Sin embargo, requieren el cumplimiento de las convenciones sobre cómo se nombran los archivos de origen y de cabecera y la secuencia en la que se incluyen. Es una pena que la mayoría de las personas (incluidos los que citan a Lakos) rara vez sigan estas convenciones.
El libro trata sobre C ++, pero los conceptos son más ampliamente aplicables. Sin embargo, debido a que C ++ es un lenguaje tan complejo, una gran parte del libro le enseña cómo usar C ++ de manera efectiva. Si puede superar eso, puede encontrarlo útil incluso si usa otros idiomas.
Algunas de las prescripciones tales como el uso de "espacios de nombre" quizás se consideren ahora polémicas. Muchos creen que los espacios de nombres deberían usarse de forma limitada en C ++.

Está un poco desactualizado (de hecho, estaba desactualizado cuando fue escrito). Si no recuerdo mal, mucho de eso se trataba de reducir las dependencias, lo que probablemente haría ahora con las plantillas.

Aunque esa es probablemente una de las lecciones para aprender en proyectos a gran escala, generalmente no utiliza herramientas y funciones de vanguardia.

Lakos solía trabajar para Mentor Graphics, quien hace el software EDA. Estuvo involucrado en la creación de software EDA en C ++, donde querían usar C ++ de manera eficiente (''no más de 5% de sobrecarga sobre código C'') y resolver cómo crear software en estaciones de trabajo tempranas que realmente tomaría mucho tiempo compilar un gran aplicación C ++.

El libro es bastante bueno: trata una amplia variedad de temas, y Lakos realmente sabía lo que hacía. Realmente proviene de un trasfondo de tener que obtener un código eficiente de un compilador de C ++, así como también de cómo configurar un programa en C ++ para que sea fácil de mantener y compila y enlaces razonablemente rápido.

Creo que Lakos tiene mucha información y le recomendaría que la leyera. Sin embargo, es ''tradicional'' C ++ desde un momento en que las funciones, como las plantillas, estaban ampliamente disponibles. Mi copia no está en venta; ^)

Lo he leído y lo considero un libro muy útil sobre algunos problemas prácticos con grandes proyectos de C ++. Si ya has leído mucho sobre C ++ y conoces un poco sobre el diseño físico y sus implicaciones, es posible que no encuentres mucho de lo que es tremendamente "nuevo" en este libro.

Por otro lado, si su compilación demora 4 horas y no sabe cómo reducirla, obtenga una copia, léala y compárela.

Comenzarás a escribir un código físicamente mejor bastante rápido.

[Editar] Si desea comenzar en algún lugar, y no puede obtener de inmediato el libro, encontré la serie Games From Within en la estructura física útil incluso después de leer el diseño de C ++ a gran escala.

Lo leí hace mucho tiempo, pero recuerdo haber obtenido mucho de él; sin embargo, como MadKeithV señala, eso puede haber sido que yo sabía menos entonces;)

Ciertamente, desde una perspectiva de "cómo reducir el tiempo de construcción", tiene muchas cosas útiles, especialmente para reducir las dependencias de tiempo de compilación, aunque posiblemente parte de esto ya no sea relevante, o incluso posible, dada la cantidad de plantillas que se utilizan. estos días.

Y no, tampoco puedes tener mi copia :)

Pensé que el libro era una buena lectura a finales de la década de 1990. Ya no estaba actualizado, ahora es tan relevante como la guía telefónica de los años cincuenta.

Trabajé con Lakos durante varios años donde trató de implementar estas ideas. También tuve mi proyecto moderno de C ++ que construí de unos 2000 archivos fuente, a gran escala, y he creado algunos más desde entonces. Los tiempos de compilación se reducen fácilmente mediante compilaciones distribuidas en paralelo, utilizando programas como icecream. Cada compilador almacenará en caché los encabezados abiertos, solo haciendo algo realmente escandaloso, cualquier herramienta de compilación moderna como Scon escalará a miles de unidades de traducción sin hacer nada realmente especial, con tiempos de compilación, incluidas pruebas, que lleva un par de minutos desde la limpieza.

Limitar la interfaz de su biblioteca a unos pocos "tipos de vocabulario" (no es el mismo sentido que el concepto OO, quiere decir simplemente usar Int, float, string, char, y un par de otros que no recuerdo) es un consejo extremadamente pobre para escalar cualquier cosa. Su compilación va a buscar una discrepancia de tipos, no quiere esto en tiempo de ejecución solo para que sea más fácil escribir un archivo make.

Y esa es en gran parte la esencia del libro: ¿cómo escribo C ++ para que funcione con herramientas de 1993? Además, el proyecto Mentor Graphic que el libro describe fue un desastre de todas las cuentas. Incluso el libro mismo alude a eso.

Large Scale C ++ se entrega en forma de código fuente; estas son las "dependencias físicas", no las bibliotecas de enlaces (y el libro nunca menciona otras dependencias más importantes como bases de datos, sockets, arquitectura de procesador, etc.).

El libro está lleno de ideas que suenan bien, pero hay maneras mucho mejores de ampliarlas en la práctica. Si desea estudiar grandes bibliotecas de C ++, eche un vistazo a Boost o Xerces y vea lo que hicieron. Realmente están implementando grandes proyectos, no escribiendo sobre ellos.

Quiero agregar a todas estas respuestas que solo es útil para C porque este lenguaje tiene problemas con el infierno del encabezado. Algunos consejos son bastante inútiles hoy en día, como incluir guardias que ahora son hechas por el compilador o la agrupación de encabezados cuando mejor utilizas unas pocas cabeceras precompiladas (una para cada paquete).

Si me preguntas si vale la pena comprar, respondo: solo si eres un principiante en el desarrollo de C / C ++. Los problemas actuales del mundo actual de C ++ (plantillas y plantillas y ya mencioné las plantillas) no se cumplen.

Pero solo miré el libro de nuevo. Me da buenos recuerdos y me dice nuevamente por qué este lenguaje es simplemente absolutamente incorrecto y necesita ser reemplazado.

Sí, de alguna manera, el libro está un poco anticuado y parte del mismo es específico de C ++. No obstante, ofrece muchos consejos útiles sobre cómo manejar la complejidad y el acoplamiento en programas grandes, y la mayoría de sus consejos se aplican a cualquier lenguaje orientado a objetos. También lo encontré muy legible.

Si puede rastrear una copia, estoy seguro de que valdrá la pena leerla. Está en mi lista de los diez mejores libros de programación.

¿El "Diseño de software de C ++ a gran escala" de John Lakos es una joya que provoca la mente (pero que generalmente se pasa por alto)?

Yes .