Mi estilo personal con C++, siempre tiene que poner declaraciones de clase en un archivo de inclusión, y las definiciones en una .archivo cpp, muy similar a la estipulada en la Loki la respuesta de C++ Archivos de Encabezado, Separación de Código. Ciertamente, parte de la razón por la que me gusta este estilo, probablemente, tiene que ver con todos los años que he pasado de codificación de Modula-2 y Ada, ambos de los cuales tienen un esquema similar, con especificación de los archivos y los archivos de cuerpo.

Tengo un compañero de trabajo, mucho más informado en C++ que yo, que insiste que todos los C++ declaraciones deben, cuando sea posible, incluir las definiciones de la derecha que hay en el archivo de encabezado. Él no está diciendo que esto es una válida alternativa de estilo, o incluso un poco mejor estilo, sino que esta es la nueva universalmente aceptado de estilo que todo el mundo está usando ahora para C++.

Yo no soy tan ágil como yo solía ser, así que no estoy realmente ansiosa por scrabble en este tren de su, hasta que yo vea un poco más de gente hasta allí con él. Así que ¿qué tan común es este modismo realmente?

Sólo para darle un poco de estructura a las respuestas: Es ahora La Manera, muy común, poco común, poco común, o bug-out loco?

  • una de las funciones de la línea (getters y setters) en el encabezado es común. Más que obtendría de una curiosa segundo vistazo. Tal vez para la definición completa de una pequeña clase que sólo es utilizado por otro en la misma cabecera?
  • siempre he puesto todos mis definiciones de clase en los encabezados de tan lejos. sólo definiciones para pimpl clases son las excepciones. yo sólo declarar aquellos en los encabezados.
  • Tal vez él piensa que es el camino, porque eso es lo Visual C++ insiste en que el código escrito. Cuando usted haga clic en un botón, la aplicación se genera en el archivo de encabezado. No sé por qué Microsoft animaría a esto, sin embargo, por las razones que otros han explicado a continuación.
  • Microsoft sería más bien todo programa en C#, y en C#, no hay un «encabezado» vs «cuerpo» de la distinción, es sólo un archivo. Después de haber estado en C++ y C# mundos por un largo tiempo, el C# forma es en realidad mucho más fácil de tratar.
  • Que es de hecho una de las cosas que él señaló. Yo no he escuchado este argumento fuera de él últimamente, pero si mal no recuerdo fue argumentando que Java y C# trabajar de esta manera, y C# era nuevo en el tiempo, por lo que es una tendencia en todos los idiomas pronto será el siguiente
  • Usted puede usar explícita ejecución de plantilla y de exportación explícito de la plantilla de los casos y mover parte de su plantilla de código a los archivos cpp así. Por ejemplo, usted puede tener un archivo cpp que explícitamente se crea una instancia de vector<int> si se utiliza muchas veces en diferentes unidades y, a continuación, evitar el pago de reinstantiation en otras unidades de traducción.

InformationsquelleAutor T.E.D. | 2009-02-24

17 Comentarios

  1. 196

    Su compañero de trabajo está mal, la forma más común es y siempre ha sido la de poner el código en el .archivos cpp (o de cualquier extensión que te gusta) y declaraciones en los encabezados.

    A veces hay un poco de mérito a poner el código en el encabezado, esto puede permitir más inteligente inline por el compilador. Pero, al mismo tiempo, puede destruir sus tiempos de compilación ya que todo el código que tiene que ser procesados cada vez que se incluye el compilador.

    Finalmente, es a menudo molesto tener objeto circular relaciones (a veces se desea) cuando todo el código se encuentra en los encabezados.

    Línea inferior, que estaban a la derecha, está equivocado.

    EDICIÓN: he estado pensando acerca de su pregunta. Hay uno caso de que lo que él dice es verdad. plantillas. Muchos de los nuevos «moderno» las bibliotecas como boost hacer un uso intensivo de las plantillas y, a menudo, son «encabezado sólo.» Sin embargo, esto sólo debe hacerse cuando se trata con plantillas ya que es la única manera de hacerlo cuando se trabaja con ellos.

    EDICIÓN: Algunas personas les gusta un poco más la aclaración, he aquí algunas reflexiones sobre los aspectos negativos de la escritura «encabezado sólo» código:

    Si usted busca alrededor, usted va a ver un buen montón de gente tratando de encontrar una manera de reducir los tiempos de compilación cuando se trata con boost. Por ejemplo: Cómo reducir los tiempos de compilación con el Impulso Asio, que es ver a un 14s compilación de un único archivo de 1K con el impulso incluido. 14s puede que no parezca «explosión», pero sin duda es mucho mayor de lo habitual y puede agregar para arriba muy rápidamente. Cuando se trata de un gran proyecto. Encabezado de sólo hacer las bibliotecas afectar a los tiempos de compilación en una manera mensurable. Acabamos de tolerar porque boost es tan útil.

    Además, hay muchas cosas que no se puede hacer en sólo encabezados (incluso boost ha bibliotecas usted necesita el enlace para ciertas partes, tales como hilos, sistema de ficheros, etc). Un ejemplo Principal es que usted no puede tener simple global de los objetos en el encabezado sólo libs (a menos que se recurra a la abominación que es un singleton) como se ejecuta en múltiples errores de definición. NOTA: C++17 inline variables que van a hacer de este ejemplo en particular factible en el futuro.

    Como un punto final, cuando el uso de impulso como un ejemplo de encabezado de sólo código, un gran detalle a menudo se pierde.

    Boost es de la biblioteca, no a nivel de usuario código. así que no cambia con frecuencia. En el código de usuario, si pones todo en las cabeceras, cada pequeño cambio, hará que usted tenga que volver a compilar todo el proyecto. Esa es una monumental pérdida de tiempo (y no es el caso para las bibliotecas que no cambian de compilar compilar). Al dividir las cosas entre encabezado/fuente y mejor aún, el uso de declaraciones forward para reducir incluye, usted puede ahorrar horas de volver a compilar cuando se suman a través de un día.

    • Estoy bastante seguro de que es donde se está haciendo desde. Whenver esto viene hasta él trae plantillas. Su argumento es más o menos que debe hacer todo el código de esta manera la coherencia.
    • que un pobre argumento de que él está haciendo, se adhieren a sus armas de fuego 🙂
    • Definiciones de la plantilla puede ser en archivos CPP si la «exportación» de palabras clave es compatible. Que un oscuro rincón de C++ que no suele ser incluso implementado por la mayoría de los compila, al mejor de mi conocimiento.
    • Hay también explícita la creación de instancias que le permite no tener todo el código en el encabezado (sólo útil si usted sabe todos los posibles casos que se necesite).
    • Vea en la parte inferior de esta respuesta (la parte superior es un poco complicado) para un ejemplo: stackoverflow.com/questions/555330/…
    • Empieza a ser significativo a este debate en «¡Hurra, no enlazador de errores».
    • Dado que mi pregunta se reducía a lo que el consenso general fue, y esta respuesta parece haber ganado la mayoría de todos los votos emitidos, y aún tengo en el otro se contradicen, lo estoy aceptando.
    • Incluso en la plantilla de los encabezados, es una buena idea para poner en práctica el código en otro encabezado y #include en la parte inferior, justo para separar las cosas.
    • Mejor aún, incluir en la .archivo cpp que específicamente se utiliza la plantilla de implementaciones en lugar de la cabecera. Puedo dividir mis plantillas en una .hpp y una .inl archivo. Otras cabeceras sólo se incluyen las .hpp, y luego el .archivo cpp ha de incluir el .inl. Mejora mi tiempo de compilación de la misma manera como .cpp/.ch separación, causando menos recompilaciones.
    • -1. En realidad no justificar, «sin Embargo, esto sólo debe hacerse cuando se trata con plantillas ya que es la única manera de hacerlo cuando se trabaja con ellos.» En realidad creo que las plantillas de invalidar toda su punto de bibliotecas como boost son casi solamente de cabecera, sin embargo, los tiempos de compilación de no explotar, los ríos no se ha ejecutado con sangre, etc. De hecho, la vida sólo salió, lo que plantea la pregunta, ¿por qué no acaba de código en los encabezados todo el tiempo? Tal vez hay una legítima respuesta a eso, pero todavía no lo había publicado aquí.
    • en realidad, si usted busca alrededor, usted va a ver un buen montón de gente tratando de encontrar una manera de reducir los tiempos de compilación cuando se trata con boost. Por ejemplo: stackoverflow.com/questions/2258967/…, que es ver a un 14s compilación de un único archivo de 1K con el impulso incluido. 14s no puede ser «explotando» a usted, pero sin duda es un mucho más que los típicos y pueden agregar para arriba muy rápidamente. Cuando se trata de un gran proyecto. Encabezado de la biblioteca sólo de hacer efecto de los tiempos de compilación en una manera mensurable. Acabamos de tolerar porque boost es tan útil.
    • además, hay muchas cosas que no se puede hacer en sólo encabezados (incluso boost ha bibliotecas usted necesita el enlace para ciertas partes, tales como hilos, sistema de ficheros, etc). Principalmente, no se puede tener simple global de los objetos en el encabezado sólo libs (a menos que se recurra a la abominación que es un singleton) como se ejecuta en múltiples errores de definición.
    • un punto final, se perdió un gran detalle. Boost es biblioteca, no a nivel de usuario código. así que no cambia con frecuencia. En el código de usuario, si pones todo en los encabezados. Cada pequeño cambio, hará que usted tenga que volver a compilar el todo de proyecto. Esa es una monumental pérdida de tiempo (y no es el caso para las bibliotecas que no cambian de compilar compilar). Al dividir las cosas entre encabezado/fuente y mejor aún, el uso de declaraciones forward para reducir incluye, usted puede guardar horas de volver a compilar cuando se suman a través de un día.
    • se debe añadir que para su respuesta, entonces.
    • si usted insiste 🙂
    • Objeto Circular relaciones son posibles en el encabezado sólo el código, haciendo uso correcto de las interfaces, creo.
    • Ha sido un tiempo, pero sí, tienes razón en que mediante declaraciones forward y fuera de línea de las definiciones de algunas de las funciones, usted puede tener relaciones circulares en el encabezado sólo las bibliotecas. Voy a ajustar ese aspecto de mi respuesta 🙂
    • Nuevamente me pregunto si es posible para reducir las dependencias interfaces adecuadas para que el tiempo de compilación es soportable. En un encabezado de la biblioteca sólo de o en un (cerca de) encabezado solo ejecutable. Y la reducción de dependencias es una buena cosa, de todos modos …
    • Es ficticio pero bueno, es otra razón por la que quieres colocar el código en los archivos de encabezado, por lo general, tienen un proyecto llamado SnippetsCpp en la que puse fragmentos para referencia posterior, por ejemplo: draw_rectangle.h, fibonacci_algo.h. A continuación, en el main.cpp he incluido todos mis archivos de encabezado y mostrar un menú para que el usuario escoja la que demo para ejecutar. La idea es incluir archivos de cabecera con fragmentos que se ve menos feo que incluyendo archivos cpp, me puede decir su opinión sobre si está bien con «mi enfoque»?

  2. 147

    El día C++ codificadores de acuerdo en La Manera, los corderos se acuesta con los leones, los Palestinos abrazar a los Israelíes, y los gatos y los perros se les permite casarse.

    La separación entre .h and .archivos cpp es principalmente arbitrario en este punto, un vestigio de las optimizaciones del compilador pasado de largo. A mi ojo, declaraciones pertenecen en el encabezado y definiciones pertenecen en el archivo de implementación. Pero, eso es sólo el hábito, no la religión.

    • «El día C++ codificadores de acuerdo en El Camino …» habrá un solo C++ programador de la izquierda!
    • Y no va a ser de mí, porque no siempre puedo hacer mi mente.
    • Pensé que ya están de acuerdo en la forma, en la declaración .h y definiciones .cpp
    • Todos somos ciegos y C++ es un elefante.
  3. 25

    Código en los encabezados es generalmente una mala idea, ya que obliga a la recompilación de todos los archivos que incluye el encabezado cuando se cambia el código en lugar de las declaraciones. Asimismo, ralentizar la compilación ya que tendrás que analizar el código en cada archivo que incluye el encabezado.

    Una razón para tener el código en los archivos de encabezado es que es necesario por lo general para la palabra clave inline para que funcione correctamente y cuando el uso de plantillas que se estancias en otros archivos cpp.

    • «las fuerzas de la recompilación de todos los archivos que incluye el encabezado cuando se cambia el código en lugar de las declaraciones» creo que esta es la más genuina de la razón; también va con el hecho de que las declaraciones en las cabeceras de cambiar con menos frecuencia que la aplicación en .c archivos.
  4. 19

    Lo que podría ser la de informar a usted compañero de trabajo es una noción de que la mayoría del código de C++ debe ser de plantilla para permitir la máxima facilidad de uso. Y si es con plantilla, entonces todo lo que se necesita para estar en un archivo de encabezado, por lo que el código de cliente puede ver y crear instancias de ella. Si es suficientemente bueno para el Impulso y la STL, es suficientemente bueno para nosotros.

    No estoy de acuerdo con este punto de vista, pero puede ser de dónde viene.

    • Creo que tienes razón acerca de esto. Cuando hablamos de que él está siempre con el ejemplo de plantillas, donde más o menos tenía para ello. No estoy de acuerdo con el «tener», pero mis alternativas son bastante complicados.
    • para la plantilla de código que usted necesita para poner la aplicación en el encabezado. La ‘exportación’ de palabras clave permite un compilador para apoyar la separación de la declaración y la definición de las plantillas, pero el apoyo para la exportación es prettymuch inexistente. anubis.dkuug.ns/jtc1/sc22/wg21/docs/documentos/2003/n1426.pdf
    • Un, encabezado, sí, pero no tiene que ser el mismo encabezado. Ver desconoce la respuesta a continuación.
    • Eso tiene sentido, pero no puedo decir que me he encontrado con que estilo de antes.
  5. 13

    Creo que su compañero de trabajo es inteligente y que también son correctas.

    Las cosas más útiles que he encontrado que poner todo en las cabeceras es que:

    1. Sin necesidad de escribir & sincronización de los encabezados y fuentes.

    2. La estructura es simple y no circular dependencias de la fuerza de la programacion para hacer un «mejor» estructura».

    3. Portátil, fácil de incorporar para un nuevo proyecto.

    Estoy de acuerdo con la compilación problema de tiempo, pero creo que debe observar que:

    1. El cambio de archivo de origen es muy probable que para cambiar los archivos de encabezado que conduce a la totalidad del proyecto de compilar de nuevo.

    2. Compilación de velocidad es mucho más rápido que antes. Y si usted tiene un proyecto para ser construido con un tiempo largo y de alta frecuencia, es posible que indica que el diseño del proyecto tiene fallas. Separar las tareas en los diferentes proyectos y el módulo puede evitar este problema.

    Por último sólo quiero apoyar a su compañero de trabajo, solo que en mi personal punto de vista.

    • +1. No hay uno, sino que tenía la idea de que en un encabezado único proyecto largos tiempos de compilación puede ser un indicio de demasiado dependencias que es un mal diseño. Buen punto! Pero esas dependencias ser removido a un punto en que el tiempo de compilación es realmente corto?
    • Me encanta la idea de la «mona» para obtener una mejor información sobre las malas decisiones de diseño. Sin embargo, en el caso de solamente de cabecera vs compilado por separado, si nos conformamos con la idea de terminar con una sola unidad de compilación y enormes tiempos de compilación. Incluso cuando el diseño es realmente genial.
    • En otras palabras, la separación entre la interfaz y la implementación es en realidad una parte de su diseño. En C, que son necesarios para expresar sus decisiones en la encapsulación a través de la separación en la cabecera y en la implementación.
    • Estoy empezando a preguntarme si hay algún inconveniente en que todos simplemente colocar encabezados por completo como lenguas modernas de hacer.
  6. 12

    A menudo me voy a poner trivial funciones miembro en el archivo de encabezado, que les permita estar en línea. Pero para poner el cuerpo entero de código de allí, sólo para ser coherente con las plantillas? Que la llanura de frutos secos.

    Recuerde: Un tonto consistencia es el hobgoblin de las mentes pequeñas.

    • Sí, yo también. La regla general yo uso parece ser algo a lo largo de las líneas de «si cabe en una sola línea de código, lo deje en el encabezado».
    • ¿Qué sucede cuando una biblioteca proporciona el cuerpo de una plantilla de clase A<B> en un archivo cpp y, a continuación, el usuario quiere un A<C>?
    • Yo no he estado de manera explícita, pero las clases de plantilla debería ser definida en los encabezados para que el compilador puede ejemplificar con lo que los tipos de necesidades. Eso es un requisito técnico, no una elección estilística. Creo que el problema en la pregunta original es que alguien decidió que si era bueno para las plantillas, que era bueno para las clases regulares también.
  7. 6

    Como Tuomas dijo, su cabecera debe ser mínima. Para ser completa, voy a ampliar un poco.

    Yo personalmente uso 4 tipos de archivos en mi C++ proyectos:

    • Público:
    • Reenvío de encabezado: en el caso de las plantillas, etc, este archivo de obtener el reenvío de las declaraciones que aparecerá en la cabecera.
    • Encabezado: este archivo incluye el envío de cabecera, si los hubiere, y declarar todo lo que deseo ser público (y define las clases…)
    • Privado:
    • Privado encabezado: este es un archivo de encabezado reservado para la implementación, que incluye la cabecera y declara las funciones auxiliares /estructuras (Pimpl, por ejemplo, o predicados). Saltar si no es necesario.
    • Archivo de origen: incluye el encabezado privado (o de cabecera si no hay ningún encabezado privado) y define todo (no de plantilla…)

    Además, tengo la pareja esta con otra regla: no defina lo que usted puede declarar hacia delante. Aunque claro, yo soy razonable allí (utilizando Pimpl en todas partes es bastante complicado).

    Significa que yo prefiero un delantero de declaración a través de una #include directiva en mi encabezados siempre que puedo salir con ellos.

    Finalmente, también el uso de una regla de visibilidad: limitar los alcances de mi símbolos tanto como sea posible para que no contaminen el exterior ámbitos.

    Poner del todo:

    //example_fwd.hpp
    //Here necessary to forward declare the template class,
    //you don't want people to declare them in case you wish to add
    //another template symbol (with a default) later on
    class MyClass;
    template <class T> class MyClassT;
    
    //example.hpp
    #include "project/example_fwd.hpp"
    
    //Those can't really be skipped
    #include <string>
    #include <vector>
    
    #include "project/pimpl.hpp"
    
    //Those can be forward declared easily
    #include "project/foo_fwd.hpp"
    
    namespace project { class Bar; }
    
    namespace project
    {
      class MyClass
      {
      public:
        struct Color //Limiting scope of enum
        {
          enum type { Red, Orange, Green };
        };
        typedef Color::type Color_t;
    
      public:
        MyClass(); //because of pimpl, I need to define the constructor
    
      private:
        struct Impl;
        pimpl<Impl> mImpl; //I won't describe pimpl here :p
      };
    
      template <class T> class MyClassT: public MyClass {};
    } //namespace project
    
    //example_impl.hpp (not visible to clients)
    #include "project/example.hpp"
    #include "project/bar.hpp"
    
    template <class T> void check(MyClass<T> const& c) { }
    
    //example.cpp
    #include "example_impl.hpp"
    
    //MyClass definition

    El salvavidas aquí es que la mayoría de las veces en el encabezado de reenvío es inútil: sólo es necesario en caso de typedef o template y también lo es la implementación de la cabecera 😉

  8. 5

    Para agregar más diversión que usted puede agregar .ipp los archivos que contienen la implementación de la plantilla (que está incluido en .hpp), mientras que .hpp contiene la interfaz.

    Aparte de templatized código (dependiendo del proyecto, este puede ser de mayoría o de minoría de archivos) hay normal código y aquí es mejor separar las declaraciones y definiciones. Proporcionan también hacia adelante-declaraciones donde sea necesario – esto puede tener un efecto sobre el tiempo de compilación.

    • Eso es lo que me llevó a hacer con definiciones de plantilla demasiado (aunque no estoy seguro de si se utiliza la extensión de la misma…ya ha pasado un tiempo).
  9. 5

    Por lo general, cuando se está escribiendo una nueva clase, voy a poner todo el código en la clase, así que no tengo que buscar en otro archivo para que.. Después de todo lo que está trabajando, se me rompe el cuerpo de los métodos en el archivo cpp, dejando los prototipos en el hpp de archivo.

  10. 4

    Si esta nueva forma es realmente La Manera, hemos estado corriendo en dirección diferente en nuestros proyectos.

    Porque tratamos de evitar todas las cosas innecesarias en los encabezados. Que incluye el evitar la cabecera de la cascada. Código en los encabezados probablemente tenga alguna otra cabecera, para ser incluido, el cual tendrá otro encabezado y así sucesivamente. Si nos vemos obligados a utilizar plantillas, tratamos de evitar tirar basura encabezados con plantilla cosas demasiado.

    También utilizamos «puntero opaco»-patrón cuando sea aplicable.

    Con estas prácticas que podemos hacer rápidamente genera que la mayoría de nuestros compañeros. Y sí… el cambio de código o de los miembros de la clase no va a causar grandes reconstrucciones.

    • «Puntero opaco», o PIMPL como todo el mundo lo llama aquí.
  11. 4

    Yo personalmente hacer esto en mis archivos de encabezado:

    //class-declaration
    
    //inline-method-declarations

    No me gusta mezclar el código de los métodos en la clase como me resulta un dolor de mirar las cosas rápidamente.

    Yo no pondría TODOS los métodos en el archivo de encabezado. El compilador (normalmente) no ser capaz de poner en línea a los métodos virtuales y (probablemente) sólo en línea pequeño métodos sin bucles (total depende del compilador).

    Haciendo los métodos de la clase es válido… pero a partir de una readablilty punto de vista no me gusta. Poniendo los métodos en el encabezado significa que, cuando sea posible, se obtendrá entre líneas.

  12. 2

    Mi humilde opinión, tiene el mérito SÓLO si él está haciendo plantillas y/o metaprogramación. Hay un montón de razones ya mencionadas que limite los archivos de cabecera para que sólo las declaraciones. Son sólo eso… encabezados. Si desea incluir el código, compilarlo, como una biblioteca de enlace de arriba.

  13. 2

    Puse a todos a la aplicación de la definición de la clase. Quiero tener el doxygen los comentarios fuera de la definición de la clase.

    • Yo sé que es tarde, pero downvoters (o simpatizantes) de atención a comentario ¿por qué? Esto parece una declaración razonable para mí. Hacemos uso de Doxygen, y la cuestión, sin duda, vino arriba.
  14. 2

    Creo que es absolutamente absurdo poner TODO de su función de definiciones en el archivo de encabezado. Por qué? Debido a que el archivo de encabezado se utiliza como la interfaz PÚBLICA de la clase. Es el fuera de la «caja negra».

    Cuando usted necesita ver a un clase a referencia de cómo usarlo, usted debe buscar en el archivo de encabezado. El archivo de encabezado debe dar una lista de lo que puede hacer (comentado para describir los detalles de cómo utilizar cada función), y debe incluir una lista de las variables miembro. NO DEBE incluir CÓMO cada función individual es implementado, debido a que un barco de carga de información innecesaria y sólo satura el archivo de encabezado.

  15. 1

    No que realmente depende de la complejidad del sistema, y las convenciones?

    Por el momento estoy trabajando en una red neuronal simulador que es increíblemente complejo, y la aceptación de estilo que se espera que yo uso es:

    Las definiciones de clase en clase.h

    Código de la clase en classnameCode.h

    el código ejecutable en classname.cpp

    Este se divide el usuario creado simulaciones del desarrollador-construido clases base, y funciona mejor en la situación.

    Sin embargo, me sorprendería ver a la gente hacer esto, por ejemplo, en una aplicación de gráficos, o cualquier otra aplicación que el propósito no es proporcionar a los usuarios con una base de código.

    • ¿Qué es exactamente la distinción entre el «código de la Clase» y «código Ejecutable»?
    • Como he dicho, es un simulador neuronal: El usuario crea ejecutable simulaciones en las que se basan en un gran número de clases que actúan como las neuronas, etc. Así que nuestro código es simplemente clases que realmente no pueden hacer nada por sí mismos, y el usuario que crea el código ejecutable que hace el simulador de hacer cosas.
    • Por lo general, no podía decir «en realidad no puede hacer nada por sí mismo», para la gran mayoría (si no la totalidad) de la mayoría de cualquier programa? Estás diciendo que el «principal» código va en el cpp, pero nada más lo hace?
    • En esta situación es un poco diferente. El código que escribimos es, básicamente, una biblioteca, y el usuario construye su simulaciones en la parte superior de este, que en realidad son ejecutables. Piense en ello como openGL -> tienes un montón de funciones y objetos, pero sin un archivo cpp que se pueden ejecutar de ellos son inútiles.
  16. 0

    Código de la plantilla debe ser en sólo encabezados. Aparte de que todas las definiciones excepto inline debe ser en .cpp. El mejor argumento para que este sería el ets de la biblioteca de implementaciones que siga la misma regla. Usted no está en desacuerdo std lib desarrolladores estarían a la derecha con respecto a este.

    • Que stdlibs? GCC libstdc++ parece (AFAICS) para poner casi nada en src & casi todo en include, si es o no «debe» ser en un encabezado. Así que no creo que este sea un fiel/útil citación. De todos modos, no creo que stdlibs son mucho de un modelo para el código de usuario: son, obviamente, escrito por altamente cualificados programadores, pero para ser usa, no se lee: se abstraen de alta complejidad que la mayoría de los programadores no necesitan pensar, necesita feo _Reserved __names en todas partes para evitar conflictos con el usuario, comentarios & separación están por debajo de lo que te aconsejo, etc. Son ejemplares en un camino estrecho.
  17. 0

    Creo que su compañero de trabajo es el correcto mientras él no entra en el proceso de escribir el código ejecutable en el encabezado.
    El equilibrio adecuado, creo yo, es seguir el camino indicado por GNAT Ada donde el .anuncios de archivo da perfectamente adecuada definición de interfaz del paquete para sus usuarios y para su niño.

    Por la forma en que Ted, ha tenido usted un vistazo a este foro a la reciente cuestión de la Ada de la unión a los CLIPS de la biblioteca que escribí hace varios años y que no es más disponibles (en el caso de las páginas Web están cerrados). Incluso si se hace a un viejo Clips versión, esta unión podría ser un buen ejemplo de arranque para alguien dispuesto a utilizar los CLIPS motor de inferencia dentro de un Ada 2012 programa.

    • Lol. 2 años más tarde, esta es una manera extraña de obtener de alguien. Voy a ver si todavía tengo una copia, pero lo más probable es que no. Lo hice para una clase de IA para que yo pudiera hacer mi código en Ada, pero intencionalmente puesto que el proyecto CC0 (esencialmente sin copyright) en la esperanza de que alguien descaradamente tomar y hacer algo con él.

Dejar respuesta

Please enter your comment!
Please enter your name here