Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 524 — #562
✐
Apéndice A. Estilo de codificación
errores cuando se compile con una implementación conforme al Estándar C++ (no
todos los compiladores soportan todas las características del lenguaje). Las sentencias
que deberían causar errores de compilación están comentadas con //! de modo
que se pueden descubrir y probar fácilmente de modo automático. Los errores
descubiertos por el autor aparecerán primero en la versión electrónica del libro
(www.BruceEckel.com) y después en las actualizaciones del libro.
Uno de los estándares de este libro es que todos los programas compilarán y enlazarán
sin errores (aunque a veces causarán advertencias). Algunos de los programas,
que demuestran sólo un ejemplo de codificación y no representan programas completos,
tendrán funciones main() vacías, como ésta:
int main() {}
Esto permite que se pueda enlazar el programa sin errores.
El estándar para main() es retornar un int, pero C++ Estándar estipula que si
no hay una sentencia return en main(), el compilador generará automáticamente
código para return 0. Esta opción (no poner un return en main()) se usa en el
libro (algunos compiladores producen advertencias sobre ello, pero es porque no son
conformes con C++ Estándar).
A.2. Nombres de fichero
En C, es tradición nombrar a los ficheros de cabecera (que contienen las declaraciones)
con una extensión .h y a los ficheros de implementación (que generan
alojamiento en memoria y código) con una extensión .c. C++ supuso una evolución.
Primero fue desarrollado en Unix, donde el sistema operativo distingue entre
mayúsculas y minúsculas para nombres de ficheros. Los nombres originales para
los ficheros simplemente se pusieron en mayúscula: .H y .C. Esto, por supuesto, no
funcionaba en sistemas operativos que no distinguen entre mayúsculas y minúsculas
como DOS. Los vendedores de C++ para DOS usaban extensiones hxx y cxx, o
hpp y cpp. Después, alguien se dio cuenta que la única razón por la que se puede
necesitar un extensión diferente es que el compilador no puede determinar si debe
compilarlo como C o C++. Como el compilador nunca compila ficheros de cabecera
directamente, sólo el fichero de implementación necesita una distinción. Ahora,
en prácticamente todos los sistemas, la costumbre es usar cpp para los ficheros de
implementación y .h para los ficheros de cabecera. Fíjese que cuando se incluye un
fichero de cabecera C++, se usa la opción de no poner extensión al nombre del fichero,
por ejemplo: #include
A.3. Marcas comentadas de inicio y fin
524
Un tema muy importante en este libro es que todo el código que puede ver en
el libro ha sido sido verificado (con al menos un compilador). Esto se consigue extrayendo
automáticamente los listados del libro. Para facilitar esta tarea, todos los
listados de código susceptibles de ser compilados (al contrario que los fragmentos,
que hay pocos) tienen unas marcas comentadas al principio y al final. Estas marcas
las usa la herramienta de extracción de código ExtractCode.cpp del Volumen 2
de este libro (y que se puede encontrar en el sitio web www.BruceEckel.com) para
extraer cada listado de código a partir de la versión en texto plano ASCII de este
libro.
✐
✐
✐
✐