Programación en C en 2011 [cerrado]

Hace muchas lunas corté el código C para vivir, principalmente mientras mantenía un servidor POP3 que soportaba una amplia gama de sistemas operativos (Linux, * BSD, HPUX, VMS ...).

Estoy planeando pulir el óxido de mis habilidades en C y aprender un poco sobre la implementación del lenguaje al codificar un FORTH simple en C.

Pero me pregunto cómo (¿o si?) Han cambiado las cosas en el mundo C desde 2000. Cuando pienso en C, pienso ...

1. comp.lang.c
2. ANSI C siempre que sea posible (pero C89 como C99 no es tan ampliamente compatible)
3. gcc -Wall -ansi -pedantic en lugar de herramientas de análisis estático
4. Emacs
5. Etiquetas
6. Autoconf + make (y vea el punto 2 para obtener información sobre VMS, HP-UX, etc.)

¿Puede alguien que ha estado escribiendo en C durante los últimos once años decirme qué (si algo ;-)) ha cambiado con los años?

(En otras noticias, santa mierda, he estado haciendo esto durante más de una década).

Es realmente difícil para mí pensar en el pasado como "Wow, ¿cómo era la programación en C hace 10 años?", Pero puedo hablar sobre algunas cosas que sé que estoy haciendo de manera diferente.

• Si bien, por lo general, aún puede convocar a alguien como Peter Seebach en comp.lang.c para obtener ayuda sobre un error particularmente tonto que sospecha que podría estar relacionado con el lenguaje, la mayoría si no todas las preguntas de programación en C obtienen respuestas excepcionales en Stack Overflow.

• El análisis estático sigue siendo algo doloroso. La férula (al menos hasta donde yo sé) no trata tan bien con C99, los gráficos de cobertura todavía son un poco difíciles de visualizar. Las advertencias de GCC han "mejorado" bastante (entre comillas porque eso depende de a quién le pregunte).

• Valgrind es el santo de todos los verificadores de errores de memoria y generalmente le señala problemas en su código que ninguna herramienta de análisis estático podría / podría encontrar. No es 100% perfecto, pero no creo que pueda serlo. Muy rara vez tengo que tocar GDB en estos días, lo que (nada personal) está bien para mí. La herramienta de macizo Valgrind también es un buen perfilador de montón.

• Siempre hay nuevas extensiones en GCC, algunas de ellas sutiles , por lo que es una buena idea si la portabilidad es una gran preocupación. Para el programador novato / oxidado, a veces es fácil confundir extensiones con funciones de lenguaje 'ocultas'.

• CCAN ha surgido (piense en CPAN, pero para C) y está comenzando a despegar. Hay muchas gemas útiles allí, incluida una adaptación de TAP, que es una herramienta de prueba increíble. Las cadenas en C todavía apestan, pero la cantidad y calidad de las bibliotecas para ayudar a lidiar con ellas seguramente ha aumentado en los últimos diez años.

• SCons y CMake están aumentando en popularidad para la configuración de compilación. Autoconf / Automake / Libtool todavía se usan ampliamente, pero muchas personas se sienten demasiado limitadas por M4. Aún así, si ese es el sistema que le gusta usar, el archivo macro de Autoconf todavía está vivo y bien.

• Obviamente, hay más editores disponibles hoy. Todavía tengo que encontrar un "IDE" que no se interpuso en mi camino cuando trabajé con C, pero eso es probablemente porque soy un viejo evangelista, bebedor de sanka bebedor por simplicidad.

En general, sin embargo, no diría que la vida (en lo que respecta a C) es incluso muy diferente de lo que era hace 10 años. Pero, en muchos sentidos, en realidad es un poco más fácil. Sin embargo, es difícil atribuir eso a las herramientas sobre la experiencia.

glib podría ser la "nueva biblioteca estándar". Ofrece gran parte de lo que muchos consideran fuera del estándar: redes y subprocesos independientes de la plataforma, estructuras de datos de contenedores, etc. Por supuesto, no es aplicable en todas partes, pero si puede usarlo, ahorra mucho tiempo.

1. StackOverflow ;)
2. Utilizo C principalmente para escribir firmware para los microcontroladores de Microchip, y dado que su compilador está basado en GCC, uso C99 (pero no me vuelvo loco con las características adicionales, principalmente para restringir el alcance de las variables de bucle y las matrices dinámicas en la pila). Cuando escribo extensiones de Python, me quedo con C89 en caso de que alguien necesite compilarlo con MSVC. No sé lo que todos los demás usan.
3. Férula (obras en C89, C99 no), y el analizador estático de Clang - aunque, dado que ambos ahogo en el código firmware macro-pesado, que no tienen una gran cantidad de experiencia con ellos. En realidad, muchas de las cosas de LLVM son bastante interesantes para un geek de C.
4. Bien, esto es solo cebo de guerra santa: P
5. Nunca usé Ctags, pero soy parcial con Doxygen.
6. Dios, odio Autoconf. Lo odio mucho Nunca, nunca he logrado crear una bola de barro Autoconf desde cero. Si un proyecto ya tuviera uno, terminaría bastardando lo que sea que esté allí. Si estoy escribiendo algo nuevo, despotricar y delirar y buscar alternativas, aunque estoy condenado si encuentro una con la que me quede. La última vez que pasé por este ciclo, me decidí por SCons, que podría usar nuevamente.

2) y 3) han cambiado. C99 es mainstream, C90 se está volviendo cada vez más obsoleto. gcc -Wall -std=c99 -pedantic.

Aparte de eso, los dos cambios más notables que aún no se abordan en otras respuestas son:

• C11. ISO 9899: 2011.
• MISRA-C: 2004.

El lenguaje de programación C llegó a los 2 o 3 principales lenguajes de programación en el diario del Dr. Dobb en su estudio / encuesta más reciente.

En cuanto a la implementación de un lenguaje, C se usa para implementar un nuevo lenguaje que se está creando en Google, llamado Go (golang.org).

No he seguido el grupo usenet de C en los últimos años. Visito su canal Freenode IRC a menudo. Es activo y frecuentado por muchos.

Se están escribiendo nuevos programas en C, pero no reciben la publicidad como lo hubieran recibido si este año fuera, digamos, 1999.

Estos son algo que viene a la cima de la mente. Podría haber muchos más, pero espero que te hayas mantenido en contacto con tu sombrero de programador, aunque es posible que no hayas frecuentado el modelo C del sombrero :)

Creo que el soporte C99 es mejor de lo que sospechas. Visual Studio no lo admite, pero cualquier otro compilador que se me ocurra lo admite (con, quizás, algunas omisiones aquí y allá). Si no necesita compatibilidad con VS, entonces diría que vaya con C99, ya que es mucho más agradable escribir que C89 IMHO.