[C con Clase] Archivo ".in" y estructurar el código en ficheros

Jose Cabrera josmaca en gmail.com
Lun Ene 25 17:52:47 CET 2010


Creo que se envío a medias jeje, a ver yo lo suelo almacenar en carpetas en
include los .h que solo contienen las cabeceras de las funciones con
información de doxygen u otro tipo de comentarios, en src los .cpp que
tienen las implementaciones, en obj los ficheros .o que están
semicompilados, en bin los ejecutables, en lib los .a que basicamente son
agrupaciones de .h, y en doc los ficheros de documentación que genera
doxygen o alguna guia informe etc..
Luego con un fichero Makefile genero todo el proyecto, te incluyo un fichero
makefile por si quieres ver como es, todo esto esta para linux con g++, para
ejecutar el Makefile se ejecuta el comando make dentro de la carpeta donde
este el fichero Makefile

El 25 de enero de 2010 17:43, Jose Cabrera <josmaca en gmail.com> escribió:

> Pues a parte de lo que has dicho, yo crearia un fichero makefile, que es un
> fichero al estilo macro donde almacenas las precompilaciones de cada parte
> que vas creando, de forma que cuando generas el proyecto global solo se
> recompila lo que hayas modificado, tambien te aconsejo que guardes los .h en
> una carpeta (se suele llamar incl
>
> El 25 de enero de 2010 12:58, Vicent <vginer en gmail.com> escribió:
>
>>  Hola a todos.
>>
>> [ Duda 1: Estructurar el código en ficheros ]
>>
>> No tengo experiencia en realizar grandes proyectos en C++. De hecho, hasta
>> ahora todos mis proyectos constaban de un único fichero ".cpp" (la extensión
>> estándar en Visual C++ para código fuente en C++) que contenía todo lo
>> siguiente:
>>
>> - Includes (primero los generales, luego los hechos por terceras personas,
>> y luego los propios)
>> - Declaraciones "using" (por ejemplo:  using std::cin ;)
>> - Definición de constantes globales vía "#define" (por ejemplo: #define
>> PRECISION 0.00000000000001)
>> - Declaración y definición de variables globales (aunque esto lo he
>> trasladado a un archivo externo, como comento en mi segunda duda, más
>> adelante)
>> - Declaración "forward" de estructuras y clases
>> - "Prototipos" de rutinas
>> - Definición de clases y estructuras
>> - Rutina principal
>> - Definición de rutinas
>>
>> Entiendo que tenerlo todo en un único fichero NO es lo normal en un
>> proyecto de tamaño medio, o medio-grande, etc.
>>
>> Mi pregunta es: si quiero separar el código en diversos ficheros, ¿cómo lo
>> hago?
>>
>> Por ejemplo, si quiero dejar en el archivo principal LO MÍNIMO, entiendo
>> que debería tener:
>>
>> - Uno o varios archivos de cabecera (con extensión ".h") que contengan la
>> declaración "forward" y definición de estructuras y clases, así como los
>> "prototipos" de las rutinas.
>> - Archivos ".cpp" con la definición de las rutinas.
>>
>> Y dejaría en el archivo principal todos los "includes" (ahora con nuevos
>> "includes" de los archivos ".h" que he creado), y quizás la declaración de
>> constantes globales, etc. y la rutina principal.
>>
>> Mi duda es en realidad esta: además de estructurar el proyecto en esta
>> serie de archivos, ¿he de hacer algo más para que todo funcione? Es decir,
>> cuando le dé a "compilar" todo, ¿sabe el compilador que las funciones
>> declaradas en #include "mis funciones.h" están en "mis_funciones.cpp", o he
>> de hacer algo más?
>>
>> ¿Sugerencias, ideas, pistas, trucos... relacionados con todo esto?
>>
>> Sé que es una pregunta de novato; espero que podáis ayudarme a tenerlo
>> todo más claro...
>>
>>
>> [ Duda 2: Archivo ".in" ]
>>
>> Y después, una duda tonta, pero por si acaso:
>>
>> En la versión "de andar por casa" de una aplicación "de consola" (de
>> "pantalla negra", quiero decir) que estoy haciendo, he organizado la
>> "entrada" de datos de la manera siguiente:
>>
>> Creo un fichero "datos_iniciales.in" donde declaro unas variables
>> globales y les asigno un valor. El "usuario" (yo mismo, de momento) deberá
>> entrar a ese fichero y modificar el valor de las variables cuando quiera
>> cambiar esos datos iniciales.
>>
>> Después, pongo esto en el código principal:
>>
>> #include "condiciones_iniciales.in"
>>
>> De momento me vale así. Cuando quiera hacer una batería grande de pruebas,
>> cambiando con mucha frecuencia el valor de los datos iniciales, ya lo haré
>> de otra manera.
>>
>> Mi pregunta es: ¿es válido usar ".in" como extensión de fichero? Mi idea
>> es, internamente, nombrar con extensión ".in" los ficheros que contienen
>> datos de entrada, y asignar extensión ".out" a los ficheros donde volcaré
>> datos, resultados, salidas, etc.
>>
>> Entiendo que sí es válido, porque creo haber leído en algún sitio que, en
>> el fondo, la extensión de los ficheros de los que hacemos "include" le da un
>> poco igual a C++.
>>
>> Gracias de antemano por vuestras respuestas.
>>
>> --
>> Vicent
>>
>> _______________________________________________
>> Lista de correo Cconclase Cconclase en listas.conclase.net
>> http://listas.conclase.net/mailman/listinfo/cconclase_listas.conclase.net
>> Bajas: http://listas.conclase.net/index.php?gid=2&mnu=FAQ
>>
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.conclase.net/pipermail/cconclase_listas.conclase.net/attachments/20100125/f2aa447c/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 2171 bytes
Desc: no disponible
URL: <http://listas.conclase.net/pipermail/cconclase_listas.conclase.net/attachments/20100125/f2aa447c/attachment.obj>


Más información sobre la lista de distribución Cconclase