C del siglo XXI, 2ª edición

Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¿Es realmente punk rock

¿Te gusta la línea del partido?

Wilco, "Demasiado lejos"

C es Punk Rock

C sólo tiene un puñado de palabras clave y es un poco tosco en sus perímetros, pero es genial. Puedes hacer cualquier cosa con él. Como los acordes Do, Sol y Re de una guitarra, puedes aprender la mecánica básica rápidamente, y luego pasarte el resto de tu vida mejorando. La gente que no lo entiende teme su potencia y piensa que es demasiado atrevido para ser seguro. Según todas las clasificaciones, es sistemáticamente el lenguaje más popular que no tiene una corporación o fundación que gaste dinero en promocionarlo.¹

Además, el lenguaje tiene unos 40 años, lo que lo hace de mediana edad. Fue escrito por unos cuantos tipos que trabajaban básicamente contra la dirección -losorígenesperfectos delpunk-rock-, peroeso fue en los años 70, y ha pasado mucho tiempo para que el lenguaje se generalizara.

¿Qué hizo la gente cuando el punk rock se generalizó? En las décadas transcurridas desde su aparición en la década de 1970, el punk ciertamente ha llegado desde los márgenes: The Clash, The Offspring, Green Day y The Strokes vendieron millones de discos en todo el mundo (por nombrar sólo a unos pocos), y yo he oído versiones instrumentales ligeras de canciones del spinoff punk conocido como grunge en mi supermercado local. El antiguo vocalista de Sleater-Kinney tiene ahora un popular programa de sketches cómicos que se burla con frecuencia de los punk rockers.² Una reacción a la continua evolución sería adoptar la línea dura y decir que la ola original era punk y que todo lo demás no es más que pop punk fácil para las masas. Los tradicionalistas pueden seguir escuchando sus discos de los 70, y si los surcos están gastados, pueden descargarse una edición digitalmente masterizada. Pueden comprar sudaderas de los Ramones para sus hijos pequeños.

Los de fuera no lo entienden. Algunos de ellos oyen la palabra punk y se imaginan algo salido de los años 70: un artefacto histórico sobre unos chavales que, en aquel momento, estaban haciendo realmente algo diferente. Los punkis tradicionalistas que aún adoran y tocan sus LPs de Iggy Pop de 1973 se divierten, pero refuerzan la impresión de que el punk está osificado y ya no es relevante.

Volviendo al mundo del C, tenemos tanto a los tradicionalistas, que enarbolan el estandarte del ANSI '89, como a los que se mueven al ritmo de lo que funcione y puede que ni siquiera se den cuenta de que el código que están escribiendo no se habría compilado ni ejecutado en los años noventa. Los de fuera no entienden la diferencia. Ven libros aún impresos de los 80 y tutoriales aún en línea de los 90, oyen a los tradicionalistas acérrimos que insisten en seguir escribiendo así hoy en día, y ni siquiera saben que el lenguaje y el resto de sus usuarios siguen evolucionando. Es una pena, porque se están perdiendo cosas estupendas.

Este es un libro sobre romper la tradición y mantener el C punk rock. No me importa comparar el código de este libro con la especificación original de C en el libro de 1978 de Kernighan & Ritchie. Mi teléfono tiene 512 MB de memoria, así que ¿por qué nuestros libros de texto de C siguen dedicando páginas y páginas a las técnicas para recortar kilobytes de nuestros ejecutables? Estoy escribiendo esto en un netbook rojo de gama baja que puede acomodar 3.200.000.000 de instrucciones por segundo; ¿qué me importa si una operación requiere comparar 8 bits o 16? Deberíamos escribir código que podamos escribir rápidamente y que sea legible por nuestros semejantes. Seguimos escribiendo en C, por lo que nuestro código legible pero imperfectamente optimizado seguirá ejecutándose un orden de magnitud más rápido que si hubiéramos escrito un código comparable en cualquier número de lenguajes alternativos e hinchados.

Preguntas y respuestas (o los parámetros del libro)

P: ¿En qué se diferencia este libro C de todos los demás?

R: Algunos están mejor escritos, otros son incluso entretenidos, pero los libros de texto de C son un grupo algo uniforme (he leído muchos de ellos, como C for Programmers with an Introduction to C11; Head First C; The C Programming Language, 1st Edition; The C Programming Language 2nd Edition; Programming in C; Practical C Programming; Absolute Beginner's Guide to C; The Waite Group's C Primer Plus; y C Programming). La mayoría se escribieron antes de que la norma C99 simplificara muchos aspectos del uso, y se nota que algunos de los que ahora están en su enésimaedición se limitaron a pegar unas cuantas notas sobre actualizaciones en lugar de replantearse seriamente cómo utilizar el lenguaje. Todos ellos mencionan que puede haber bibliotecas que tal vez podrías utilizar al escribir tu propio código, pero la mayoría son anteriores a las herramientas de instalación y al ecosistema que tenemos ahora, que hacen que utilizar esas bibliotecas sea fiable y razonablemente portátil. Esos libros de texto siguen siendo válidos y siguen teniendo valor, pero el código C moderno simplemente no se parece mucho al código de muchos de esos libros de texto.

Este libro lo retoma donde lo dejaron, reconsiderando el lenguaje y el ecosistema en el que vive. Aquí se trata de utilizar bibliotecas que proporcionan listas enlazadas y analizadores XML, no de escribir otras nuevas desde cero. Se trata de escribir código legible y con una interfaz de usuario amigable.

P: ¿A quién va dirigido este libro? ¿Necesito ser un gurú de la programación?

R: Tienes experiencia codificando en cualquier lenguaje, quizá Java o un lenguaje de scripting como Perl. No tengo que convencerte de por qué tu código no debe ser una larga rutina sin subfunciones.

El cuerpo del libro presupone un conocimiento básico de C adquirido tras haber pasado tiempo escribiendo código C. Si estás oxidado en los detalles o empiezas de cero, el Apéndice A ofrece un breve tutorial sobre C básico para los lectores que vienen de un lenguaje de scripting como Python o Ruby.

También podría indicarte que he escrito un libro de texto sobre informática estadística y científica, Modeling with Data (Klemens, 2008). Además de muchos detalles sobre el tratamiento de datos numéricos y el uso de modelos estadísticos para describir datos, tiene un tutorial más largo e independiente sobre C, que, naturalmente, creo que supera muchos de los fallos de los antiguos tutoriales de C.

P: Soy programador de aplicaciones, no hacker del núcleo. ¿Por qué debería utilizar C en lugar de un lenguaje de programación rápido como Python?

R: Si eres programador de aplicaciones, este libro es para ti. He leído a gente que afirma que C es un lenguaje de sistemas, lo cual me parece muy poco punk: ¿quiénes son ellos para decirnos lo que podemos escribir?

Las afirmaciones del tipo "Nuestro lenguaje es casi tan rápido como C, pero es más fácil de escribir" son tan comunes que casi son un tópico. Pues bien, C es definitivamente tan rápido como C, y el propósito de este libro es demostrarte que C es más fácil de escribir de lo que los libros de texto de décadas pasadas dan a entender que es. No tienes que llamar a malloc ni meterte de lleno en la gestión de memoria con la mitad de frecuencia que los programadores de sistemas de los años 90, disponemos de facilidades para el manejo de cadenas, e incluso la sintaxis básica ha evolucionado para que el código sea más legible.

Empecé a escribir C en serio porque tenía que acelerar una simulación en un lenguaje de scripting, R. Como tantos otros lenguajes de scripting, R tiene una interfaz C y anima al usuario a hacer uso de ella cada vez que el lenguaje anfitrión es demasiado lento. Al final, tenía tantas funciones que saltaban del script anfitrión al código C que me deshice por completo del lenguaje anfitrión.

P: Está bien que a los programadores de aplicaciones procedentes de lenguajes de scripting les guste este libro, pero yo soy un hacker del núcleo. Me enseñé a mí mismo C en quinto curso y a veces tengo sueños que compilan correctamente. ¿Qué material nuevo puede haber para mí?

R: C ha evolucionado en los últimos 20 años. Como comentaré más adelante, el conjunto de cosas que se nos garantiza que soportan todos los compiladores de C ha cambiado con el tiempo, gracias a dos nuevos estándares de C desde el estándar ANSI original que definió el lenguaje durante tanto tiempo. Quizás puedas echar un vistazo al Capítulo 10 y ver si hay algo que te sorprenda. Algunas secciones de este libro, como el capítulo que aclara conceptos erróneos comunes sobre los punteros(Capítulo 6), cubren material que ha cambiado poco desde la década de 1980.

Además, el entorno ha avanzado. Muchas de las herramientas que cubro, como make y el depurador, puede que ya te resulten familiares, pero he descubierto que otras no son tan conocidas. Autotools ha cambiado por completo la forma en que se distribuye el código, y Git ha cambiado la forma en que se realiza la codificación colaborativa.

P: No puedo evitar darme cuenta de que casi un tercio de este libro no contiene código C.

R: Este libro pretende cubrir lo que los demás libros de texto de C no cubren, y en lo más alto de esa lista están las herramientas y el entorno. Si no utilizas un depurador (independiente o como parte de tu IDE), te estás complicando mucho la vida. Los libros de texto suelen relegar el depurador a un segundo plano, si es que lo mencionan. Compartir código con otros requiere otro conjunto de herramientas, como Autotools y Git. El código no vive en el vacío, y sentí que estaría haciendo un flaco favor escribiendo otro libro de texto más que pretende que todo lo que el lector necesita para ser productivo es la sintaxis del lenguaje.

P: De las muchas herramientas disponibles para el desarrollo en C, ¿cómo elegiste las de este libro?

R: Más que la mayoría, la comunidad C se exige a sí misma un alto nivel de interoperabilidad. Hay muchas extensiones de C proporcionadas por el entorno GNU, IDEs que sólo funcionan en Windows y extensiones del compilador que sólo existen en LLVM. Esta es probablemente la razón por la que los libros de texto del pasado evitaban cubrir las herramientas. Pero en la actualidad existen algunos sistemas que funcionan en cualquier cosa que reconozcamos comúnmente como ordenador. Muchos de ellos son de GNU; LLVM y sus herramientas asociadas están ganando terreno rápidamente, pero aún no son tan frecuentes. Independientemente de lo que estés utilizando, ya sea una máquina Windows, una máquina Linux o una instancia que acabas de obtener de tu proveedor de computación en la nube, las herramientas que cubro aquí deberían ser fáciles y rápidas de instalar. Mencionaré algunas herramientas específicas de la plataforma, pero seré explícito en esos casos.

No cubro ningún entorno de desarrollo integrado (IDE) porque pocos o ninguno funcionan de forma fiable en todas las plataformas (prueba a abrir una instancia de Amazon Elastic Compute Cloud e instalar Eclipse y sus complementos de C), y la elección del IDE está muy influida por las preferencias personales. Los IDE suelen tener un sistema de creación de proyectos, que suele ser incompatible con el sistema de creación de proyectos de cualquier otro IDE. Por tanto, los archivos de proyecto IDE son inutilizables para la distribución de proyectos fuera de situaciones (aulas, ciertas oficinas, algunas plataformas informáticas) en las que todo el mundo está obligado a utilizar el mismo IDE.

P: Tengo Internet y puedo buscar comandos y detalles de sintaxis en un segundo o dos, así que, en realidad, ¿por qué debería leer este libro?

R: Es cierto: puedes obtener una tabla de precedencia de operadores desde la línea de comandos de Linux o Mac con man operator, así que ¿por qué voy a poner una aquí?

Tengo el mismo Internet que tú, y he pasado mucho tiempo leyéndolo. Así que tengo una buena idea de lo que no se habla, y a eso me atengo aquí. Cuando presento una nueva herramienta, como gprof o gdb, te doy lo que necesitas saber para orientarte y hacer preguntas coherentes a tu buscador, y lo que otros libros de texto se han saltado (que es mucho).

Normas: Tantas para elegir

A menos que se indique explícitamente lo contrario, todo lo que aparece en este libro se ajusta a las normas ISO C99 y C11. Para que entiendas lo que eso significa, y para darte algunos antecedentes históricos, repasemos la lista de las principales normas C (pasando por alto las revisiones y correcciones menores).

K & R (hacia 1978)

Dennis Ritchie, Ken Thompson y un puñado de colaboradores más idearon C mientras creaban el sistema operativo Unix. Brian Kernighan y Dennis Ritchie acabaron escribiendo una descripción del lenguaje en la primera edición de su libro, que estableció el primer estándar de facto (Kernighan, 1978).

ANSI C89

Los Laboratorios Bell traspasaron la administración del lenguaje al Instituto Nacional Estadounidense de Normalización (ANSI). En 1989, el instituto publicó su estándar, que introducía algunas mejoras con respecto al K & R. La segunda edición del libro de K & R incluía una especificación completa del lenguaje, lo que supuso que decenas de miles de programadores tuvieran una copia del estándar ANSI en sus escritorios (Kernighan, 1988). La norma ANSI fue adoptada por la Organización Internacional de Normalización (ISO) en 1990 sin cambios importantes, pero ANSI '89 parece ser el término más común (y sería un gran eslogan para una camiseta).

Pasó una década. C se convirtió en la corriente dominante, en el sentido de que el código base de más o menos todos los PC y todos los servidores de Internet estaba escrito en C, que es lo más dominante que puede llegar a ser una empresa humana.

Durante este periodo, C++ se separó y triunfó (aunque no tanto). C++ fue lo mejor que le ha pasado nunca a C. Mientras todos los demás lenguajes añadían sintaxis adicional para seguir la tendencia orientada a objetos y cualquier otro truco nuevo que se les ocurriera a los autores, C se ciñó al estándar. La gente que quería estabilidad y portabilidad utilizaba C, la gente que quería más y más funciones para poder revolcarse en ellas como en húmedos billetes de cien dólares conseguía C++, y todos contentos.

ISO C99

El estándar C sufrió una importante revisión una década después. Se hicieron adiciones para la informática numérica y científica, con un tipo estándar para números complejos y algunas funciones de tipo genérico. Se eliminaron algunas comodidades de C++, como los comentarios de una línea (que originalmente procedían de uno de los lenguajes predecesores de C, BCPL) y la posibilidad de declarar variables en la cabecera de los bucles for. El uso de estructuras se hizo más fácil gracias a algunas adiciones a las reglas sobre cómo se pueden declarar e inicializar, además de algunas conveniencias notacionales. Las cosas se modernizaron para reconocer que la seguridad importa y que no todo el mundo habla inglés.

Cuando piensas en el impacto que tuvo C89 y en que todo el mundo funcionaba con código C, es difícil imaginar que la ISO pudiera publicar algo que no fuera ampliamente criticado; incluso la negativa a hacer cambios sería vilipendiada. Y, efectivamente, esta norma fue controvertida. Hay dos formas habituales de expresar una variable compleja (coordenadas rectangulares y polares), así que ¿por qué la ISO elige una? ¿Por qué necesitamos un mecanismo para entradas de macros de longitud variable cuando todo el código bueno se escribió sin él? En otras palabras, los puristas acusaron a la ISO de venderse a la presión por más funciones.

En el momento de escribir esto, la mayoría de los compiladores admiten C99, con algunas salvedades. Sin embargo, hay una notable excepción a este amplio consenso: Microsoft se niega actualmente a añadir compatibilidad con C99 a su compilador Visual Studio C++. La sección "Compilar C con Windows" cubre algunas de las muchas formas de compilar código C para Windows, por lo que no utilizar Visual Studio es, como mucho, un inconveniente, y que un importante actor del establishment nos diga que no podemos utilizar el C estándar ANSI e ISO no hace sino reforzar el punk rock de todo ello.

C11

Cohibida por las acusaciones de venderse, la ISO hizo pocos cambios serios en la tercera edición de la norma. Conseguimos un medio para escribir funciones de tipo genérico, y las cosas se modernizaron para seguir reconociendo que la seguridad importa y que no todo el mundo habla inglés.

La norma C11 se publicó en diciembre de 2011, pero los autores de compiladores han implementado la compatibilidad con la norma a un ritmo sorprendentemente rápido, hasta el punto de que varios de los principales compiladores ya afirman que la compatibilidad es casi total. Sin embargo, la norma define el comportamiento tanto del compilador como de la biblioteca estándar, y la compatibilidad con la biblioteca, como en el caso de los hilos y los atómicos, es completa en algunos sistemas, pero se está poniendo al día en otros.

La norma POSIX

Ése es el estado de las cosas en lo que respecta al propio C, pero el lenguaje coevolucionó con el sistema operativo Unix, y verás a lo largo del libro que la interrelación es importante para el trabajo diario. Si algo es fácil en la línea de comandos de Unix, probablemente es porque es fácil en C; las herramientas de Unix se escriben a menudo para facilitar la escritura de código C.

Unix

C y Unix se diseñaron en los Laboratorios Bell a principios de la década de 1970. Durante la mayor parte del siglo XX, Bell estaba siendo investigada por prácticas monopolísticas, y uno de sus acuerdos con el gobierno federal de EEUU incluía promesas de que Bell no ampliaría su alcance al software. Así que Unix se cedió gratuitamente para que los investigadores lo diseccionaran y reconstruyeran. El nombre Unix es una marca registrada, originalmente propiedad de Bell Labs y posteriormente intercambiada como una tarjeta de béisbol entre varias empresas.

Las variantes de Unix florecieron a medida que el código era revisado, reimplementado y mejorado de diferentes maneras por diversos hackers. Sólo hace falta una pequeña incompatibilidad para que un programa o script se vuelva insoportable, por lo que la necesidad de cierta estandarización se hizo evidente rápidamente.

POSIX (Interfaz Portátil del Sistema Operativo)

Esta norma, establecida por primera vez por el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) en 1988, proporcionó una base común para los sistemas operativos tipo Unix. Especifica cómo debe funcionar el intérprete de comandos, qué esperar de comandos como ls y grep, y una serie de bibliotecas C que los autores de C pueden esperar tener disponibles. Por ejemplo, las tuberías que los usuarios de la línea de comandos utilizan para encadenar comandos se especifican en detalle aquí, lo que significa que la función popen (abrir tubería) de C es estándar POSIX, no estándar ISO C. El estándar POSIX se ha revisado muchas veces; la versión en el momento de escribir esto es POSIX:2008, y a eso me refiero cuando digo que algo es estándar POSIX. Un sistema POSIX estándar debe disponer de un compilador de C, mediante el comando c99.

Este libro utilizará el estándar POSIX, aunque ya te diré cuándo.

Con la excepción de muchos miembros de una familia de SO de Microsoft, casi todos los sistemas operativos actuales que puedas nombrar están construidos sobre una base compatible con POSIX: Linux, Mac OS X, iOS, webOS, Solaris, BSD; incluso los servidores Windows ofrecen un subsistema POSIX. Y para los SO que se resisten, "Compilar C con Windows" te mostrará cómo instalar un subsistema POSIX.

Por último, hay otras dos implementaciones de POSIX que merece la pena destacar por su prevalencia e influencia:

BSD

Después de que los Laboratorios Bell pusieran Unix a disposición del público para que lo diseccionara, los investigadores de la Universidad de California, Berkeley, introdujeron importantes mejoras, reescribiendo finalmente toda la base de código Unix para producir la Distribución de Software Berkeley. Si utilizas un ordenador de Apple, Inc. estás utilizando BSD con una atractiva interfaz gráfica. BSD va más allá de POSIX en varios aspectos, y veremos algunas funciones que no forman parte del estándar POSIX pero que son demasiado útiles como para dejarlas pasar (sobre todo el salvavidas que es asprintf).

GNU

Son las siglas de GNU's Not Unix, y es la otra gran historia de éxito en la reimplementación y mejora independiente del entorno Unix. La gran mayoría de las distribuciones de Linux utilizan herramientas GNU en todas ellas. Es muy probable que tengas la Colección de Compiladores de GNU (gcc) en tu caja POSIX, incluso BSD la utiliza. De nuevo, la gcc define un estándar de facto que amplía C y POSIX de algunas maneras, y seré explícito cuando haga uso de esas extensiones.

Legalmente, la licencia BSD es ligeramente más permisiva que la licencia GNU. Como algunas partes están muy preocupadas por las implicaciones políticas y comerciales de las licencias, normalmente se pueden encontrar versiones tanto GNU como BSD de la mayoría de las herramientas. Por ejemplo, tanto gcc como clang de BSD son compiladores de C de primera categoría. Los autores de ambos bandos observan de cerca y aprenden del trabajo del otro, por lo que podemos esperar que las diferencias técnicas que existen actualmente tiendan a igualarse con el tiempo.

El aspecto jurídico

La legislación estadounidense ya no tiene un sistema de registro de los derechos de autor: con pocas excepciones, en cuanto alguien escribe algo, está protegido por derechos de autor.

Por supuesto, la distribución de una biblioteca depende de la copia de disco duro a disco duro, y hay una serie de mecanismos habituales para conceder el derecho a copiar una obra protegida por derechos de autor sin apenas complicaciones.

La Licencia Pública GNU (GPL)

Esto permite la copia y el uso ilimitados del código fuente y de su versión ejecutable. Hay una condición importante: Si distribuyes un programa o biblioteca basado en el código fuente de la GPL, entonces debes distribuir el código fuente de tu programa. Ten en cuenta bien que si utilizas tu programa internamente y no lo distribuyes, esta condición no se cumple, y no tienes obligación de distribuir el código fuente. Ejecutar un programa bajo licencia GPL, como compilar tu código con gcc, no te obliga en sí mismo a distribuir el código fuente, porque el resultado del programa (como el ejecutable que acabas de compilar) no se considera basado en gcc ni un derivado de éste. Ejemplo: la Biblioteca Científica de GNU.

La GPL reducida (LGPL)

La LGPL es muy parecida a la GPL, pero estipula explícitamente que si enlazas con una biblioteca LGPL como biblioteca compartida, tu código no cuenta como obra derivada y no estás obligado a distribuir el código fuente. Es decir, puedes distribuir código cerrado que enlace con una biblioteca LGPL. Ejemplo: GLib.

La licencia BSD

Esta licencia requiere que conserves los derechos de autor y los descargos de responsabilidad del código fuente con licencia BSD, pero no requiere que redistribuyas el código fuente. Ejemplo: Libxml2, bajo la licencia MIT similar a la BSD.

Ten en cuenta la cláusula de exención de responsabilidad habitual: no soy abogado, y esto es un resumen lateral de varios documentos jurídicos bastante largos. Lee los propios documentos o consulta a un abogado si no estás seguro de cómo se aplican los detalles a tu situación.

Algo de logística

Segunda edición

Solía ser un cínico y pensar que la gente sólo escribía segundas ediciones para perturbar a todos los que vendían copias usadas de la primera edición. Pero en realidad esta segunda edición no podría haberse producido sin que se publicara la primera, y no podría haberse producido antes (y la mayoría de los lectores del libro están leyendo copias electrónicas de todos modos).

La gran novedad respecto a la primera edición es el capítulo sobre hilos concurrentes, también conocido como paralelización. Se centra en OpenMP y en las variables atómicas y structs. OpenMP no forma parte del estándar C, pero es una parte fiable del ecosistema C, por lo que encaja cómodamente en este libro. Las variables atómicas se añadieron en la revisión de diciembre de 2011 del estándar C, así que cuando este libro salió menos de un año después no había compiladores que las soportaran. Ahora hemos avanzado lo suficiente como para poder escribir este capítulo basándome tanto en la teoría presentada en el estándar como en la práctica de una implementación en el mundo real y en código probado. Véase el capítulo 12.

La primera edición fue bendecida con unos lectores maravillosamente pedantes. Detectaron todo lo que de algún modo podía interpretarse como un error, desde la estupidez que dije sobre los guiones en la línea de comandos hasta las frases cuya redacción podía malinterpretarse incorrectamente en ciertos casos. Nada en este mundo está libre de errores, pero el libro es mucho más preciso y útil como resultado de tantos comentarios estupendos de los lectores.

Otras adiciones a esta edición:

• El Apéndice A proporciona un tutorial básico de C para los lectores que vengan de otro lenguaje. Me resistía a incluirlo en la primera edición porque hay muchos tutoriales de C por ahí, pero el libro es más útil con él que sin él.

• A petición popular, he ampliado considerablemente el debate sobre cómo utilizar un depurador. Consulta "Utilizar un depurador".

• La primera edición tenía un segmento sobre cómo escribir funciones que reciban una lista de longitud arbitraria, por lo que tanto sum(1, 2.2) como sum(1, 2.2, 3, 8, 16) serían válidas. Pero, ¿y si quieres enviar varias listas, como escribir una función de producto punto que multiplique dos vectores de longitud arbitraria, como dot((2, 4), (-1, 1)) y dot((2, 4, 8, 16), (-1, 1, -1, 1))? "Listas múltiples" lo cubre.

• He reescrito el Capítulo 11, sobre la ampliación de objetos con nuevas funciones. El principal añadido es una implementación de tablas virtuales.

• Escribí algo más sobre el preprocesador, con una introducción a la maraña de macros de prueba y su uso en "Macros de prueba", incluida una mención de pasada a la palabra clave _Static_assert.

• Cumplí la promesa que me hice a mí mismo de no incluir un tutorial sobre el análisis sintáctico de expresiones regulares en este libro (porque hay cientos en Internet y en otros libros). Pero sí he añadido una demostración en "Análisis sintáctico de expresiones regulares" sobre el uso de las funciones de análisis sintáctico de expresiones regulares POSIX, que están en un formato relativamente crudo en comparación con los analizadores regex de muchos otros lenguajes.

• La discusión sobre el manejo de cadenas en la primera edición se basaba en gran medida en asprintf, una función similar a sprintf que autoasigna la cantidad necesaria de memoria antes de escribir una cadena en el espacio. Existe una versión ampliamente distribuida por el GNU, pero muchos lectores se vieron limitados para utilizarla, por lo que en esta edición he añadido el Ejemplo 9-3, que muestra cómo escribir una función de este tipo a partir de partes estándar de C.

• Uno de los grandes temas del Capítulo 7 es que microgestionar los tipos numéricos puede causar problemas, así que la primera edición no mencionaba las docenas de nuevos tipos numéricos introducidos en la norma C99, como int_least32_t, uint_fast64_t, etc. (C99 §7.18; C11 §7.20). Varios lectores me animaron a mencionar al menos algunos de los tipos más útiles, como intptr_t y intmax_t, y ahora lo hago cuando procede.

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica nuevos términos, nombres y rutas de archivos, URL y direcciones de correo electrónico. Muchos términos nuevos se definen en un glosario al final de este libro.

Constant width

Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.

Constant width italic

Muestra el texto que debe sustituirse por valores proporcionados por el usuario o por valores determinados por el contexto.

Nota

Este icono significa un consejo, sugerencia o nota general.

Precaución

Este icono indica una advertencia o precaución.

Utilizar ejemplos de código

Este libro está aquí para ayudarte a hacer tu trabajo. En general, puedes utilizar el código de este libro en tus programas y documentación. No es necesario que te pongas en contacto con nosotros para pedirnos permiso, a menos que estés reproduciendo una parte importante del código. Por ejemplo, escribir un programa que utilice varios trozos de código de este libro no requiere permiso. Vender o distribuir un CD-ROM de ejemplos de los libros de O'Reilly sí requiere permiso. Responder a una pregunta citando este libro y el código de ejemplo no requiere permiso. Incorporar una cantidad significativa de código de ejemplo de este libro en la documentación de tu producto sí requiere permiso.

Los ejemplos de código de este título pueden encontrarse aquí: https://github.com/b-k/21st-Century-Examples.

Agradecemos, pero no exigimos, la atribución. Una atribución suele incluir el título, el autor, la editorial y el ISBN. Por ejemplo "21st Century C, 2ª Edición de Ben Klemens (O'Reilly). Copyright 2014 Ben Klemens, 978-1-491-90389-6".

Si crees que el uso que haces de los ejemplos de código no se ajusta al uso legítimo o al permiso concedido anteriormente, no dudes en ponerte en contacto con nosotros en [e-mail].

Libros Safari® en línea

Safari Books Online(www.safaribooksonline.com) es una biblioteca digital a la carta que ofrece contenido experto en forma de libro y vídeo de los autores más destacados del mundo en tecnología y empresa.

Los profesionales de la tecnología, los desarrolladores de software, los diseñadores web y los profesionales empresariales y creativos utilizan Safari Books Online como recurso principal para la investigación, la resolución de problemas, el aprendizaje y la formación en certificación.

Safari Books Online ofrece una serie de combinaciones de productos y programas de precios para organizaciones, organismos públicos y particulares. Los suscriptores tienen acceso a miles de libros, vídeos de formación y manuscritos previos a la publicación en una base de datos en la que se pueden realizar búsquedas completas, de editoriales como O'Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, etc. Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology y docenas más. Para más información sobre Safari Books Online, visítanos en Internet.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-998-9938 (en Estados Unidos o Canadá)
• 707-829-0515 (internacional o local)
• 707-829-0104 (fax)

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en http://bit.ly/21st_century_c_2e.

Para hacer comentarios o preguntas técnicas sobre este libro, envía un correo electrónico a [e-mail].

Para más información sobre nuestros libros, cursos, conferencias y noticias, consulta nuestro sitio web en http://www.oreilly.com.

Encuéntranos en Facebook: http://facebook.com/oreilly

Síguenos en Twitter: http://twitter.com/oreillymedia

Míranos en YouTube: http://www.youtube.com/oreillymedia

Agradecimientos

• Nora Albert: apoyo general, cobaya.
• Jerome Benoit: Consejos Autoconf.
• Bruce Fields, Dave Kitabjian, Sarah Weissman: revisión extensa y exhaustiva.
• Patrick Hall: Erudición Unicode.
• Nathan Jepson, Allyson MacDonald, Rachel Roumeliotis y Shawn Wallace: editorial.
• Andreas Klein: señalando el valor de intptr_t.
• Rolando Rodríguez: pruebas, uso inquisitivo y exploración.
• Rachel Steely, Nicole Shelby y Becca Freed: producción.
• Ulrik Sverdrup: señalando que podemos utilizar inicializadores designados repetidos para establecer valores por defecto.

¹ Este prefacio tiene una deuda evidente y enorme con Punk Rock Languages: A Polemic de Chris Adamson.

² Con letras como "No se puede llegar al cielo con una canción de tres acordes", ¿quizás Sleater-Kinney era post-punk? Por desgracia, no existe una norma ISO del punk a la que podamos recurrir para obtener definiciones precisas de dentro o fuera.