¿Usaría C hoy para un proyecto de software? [cerrado]

En caso afirmativo, ¿dónde y por qué lo usarías?

En caso negativo, proporcione una explicación de por qué C no es aceptable para usted.

C es un gran lenguaje para la programación del sistema

Usaría C si implementara algunos controladores de hardware. Y usaría C si implementara mi propio kernel del sistema operativo o mi propia máquina virtual.

Es un lenguaje muy bueno para hacer cosas de bajo nivel si tiene que lidiar con hardware o API de sistema operativo de bajo nivel para Windows API, Linux, Mac OS X, Solaris, etc. Los sistemas integrados generalmente tienen un buen soporte para C con un compilador + kit de desarrollo.

Sí, por supuesto. Usaría C para escribir piezas críticas del sistema o partes de comunicación de bajo nivel. Por ejemplo, usaría C para escribir NIF en el proyecto Erlang solo porque es la herramienta adecuada (tm) para este tipo de trabajo. O usaría C para escribir partes similares (XS) en el proyecto Perl.

Yo uso C profesionalmente, casi todos los días. De hecho, C es el lenguaje de más alto nivel en el que programo regularmente.

Cuando uso C: escribo código de biblioteca de bajo nivel que tiene el requisito de ser lo más eficiente posible. Mi código de pegamento está escrito en C, los bucles computacionales internos están escritos en ensamblador.

Por qué uso C: es mucho más simple manejar estructuras de argumento complejas y condiciones de error que en el ensamblado, y la sobrecarga de rendimiento para ese tipo de verificación de condiciones antes de comenzar el cálculo real a menudo es insignificante. Debido a que C es un lenguaje simple y bien especificado, me resulta fácil trabajar con el equipo del compilador en el trabajo para mejorar la generación de código cada vez que veo código compilado con riesgos de rendimiento inaceptables.

La portabilidad es otra gran virtud de C. Mi código de pegamento se comparte entre múltiples implementaciones específicas de hardware de las bibliotecas en las que trabajo, lo que realmente simplifica la aparición de soporte para nuevas plataformas. La mayoría de las plataformas no tienen una máquina virtual o un intérprete para el lenguaje del mes. Algunas plataformas no tienen un buen compilador de C ++. Hay muy pocas plataformas que carecen de un compilador de C utilizable (y, dado que tengo una buena relación de trabajo con nuestro equipo de compilación, por lo general no me resulta difícil obtener el soporte que necesito).

Sí, usaría C en un sistema incrustado con recursos limitados. me puede usar C ++ porque facilita la promoción de interfaces sólidas entre los componentes de software, pero solo si todos los ingenieros que trabajan en el proyecto entienden que C ++ es fácil de usar incorrectamente, lo que lleva a un tamaño de código hinchado (las funciones virtuales y las plantillas son ejemplos de cosas a evitar )

También vi a un programador de C ++ tratando de crear un objeto de 10K en una pila de 1K, no es una buena idea.

Trabajo principalmente con el hipervisor Xen, las diversas bibliotecas que presenta y el kernel de Linux. En ocasiones, tengo que escribir un controlador de dispositivo (o volver a escribir uno para que las máquinas virtuales nxx puedan compartir un solo dispositivo, como un HRNG). C es mi idioma principal y estoy bastante contento con eso.

¿Intentaría escribir un programa de hoja de cálculo con él? De ninguna manera. Cada herramienta tiene sus aplicaciones, y estoy feliz de tener muchas herramientas.

Me encanta C, pero no trato de golpear los tornillos con un martillo.

Si C es una opción sensata para un nuevo proyecto, seguro. Si no, usaré otra cosa.

Lo haría para algunos proyectos. Definitivamente lo haría si tuviera que implementar un sistema integrado, por ejemplo, para el controlador de un avión autónomo. Incluso podría bajar el nivel en algunas partes con el ensamblaje.

Si se ajusta al proyecto, no tengo ningún problema.

Si desea desarrollar una aplicación web, hmm, probablemente no (o necesitaría ver una justificación muy sólida y respaldada por hechos).

También lo usaría de otros proyectos desarrollados principalmente con otros idiomas cuando se identifique claramente un cuello de botella y se pueda implementar una optimización utilizando código nativo. Por ejemplo, una solución de Java que necesita realizar cálculos intensivos para una representación avanzada (por ejemplo, un motor de representación o algo así). Puede usar una implementación Java por defecto si no es una plataforma compatible, pero proporcionar una implementación compilada de forma nativa de C para algunas plataformas compatibles y obtener un buen aumento del rendimiento.

Cada idioma tiene un nicho de uso decente. Con frecuencia me encuentro implementando cosas en lenguajes de nivel superior, y luego gradualmente las llevo a C-land si necesito que sean de mayor rendimiento o incluso simplemente más portátiles. Hay compiladores de C para casi todo lo que existe, y si escribe en una API que está disponible universalmente (como POSIX), puede ser muy útil.

Lo que a menudo digo a la gente que está interesada en el aprendizaje de la programación de hoy es para asegurarse de que en algunos momento aprendan C y se sientan cómodos con ella. Puede encontrarse en circunstancias donde lo necesita. En más de una ocasión, tuve que compilar un pequeño programa de "reinicio rápido" enlazado estáticamente, y usar scp para ponerlo en un disco RAM en un servidor donde el subsistema de disco desapareció por completo. (¿Servidores baratos, baratos, sin redundancia en línea y solo la capacidad de cargar un pequeño programa? C es el camino a seguir).

Además, aprender a trabajar en C sin dispararse en el pie puede contribuir significativamente a la capacidad de escribir de manera eficiente en otros idiomas y entornos. Al menos esa ha sido mi experiencia.

Aunque ciertamente no lo uso para todo, o incluso para la mayoría de las cosas, tiene su lugar y es bastante universal: así que sí, lo he usado en el pasado y lo usaré en el futuro (aunque no saber cuándo en este momento).

Sí, lo hago todo el tiempo.

Si no llama a ninguna biblioteca, el código generado desde C no requiere soporte del sistema operativo. También le brinda un control preciso sobre el lenguaje de máquina generado. Por lo tanto, es excelente para escribir controladores u otro código que se encuentre en los espacios del kernel, y otras situaciones restringidas como muchos tipos de sistemas integrados funcionan. También es el idioma principal para proyectos de código abierto con los que trabajo, como X Windows, GTK + y Clutter.

Si bien puede hacer todo en C, puede hacerlo en C ++, a menudo los mecanismos de C ++ hacen que escribir código sea más rápido y fácil. Me encanta OOP y la forma en que las clases de C ++ encapsulan la funcionalidad, y me encanta RAII. El uso cuidadoso de la invocación automática del destructor cuando un objeto se sale del alcance elimina la mayoría de las pérdidas de memoria y recursos que son la perdición de la programación en C. El STL es básicamente una biblioteca gigante de algoritmos y estructuras de datos altamente optimizados; si quisieras usarlos desde C, deberías escribirlos tú mismo o comprarlos en algún lugar.

Desafortunadamente, por razones que no entiendo, el sistema de tiempo de ejecución en Linux requiere una biblioteca especial de objetos compartidos (equivalente a DLL en Windows, dylib en Mac) para ejecutar cualquier C ++, y no se encuentra cuando ejecuta un programa en C. Así que no puedo hacer uno de mis trucos favoritos de Mac y Windows, que es escribir un objeto compartido basado en C ++ con una API basada en C, y llamarlo desde un programa en C.

Así que aquí está mi proceso de toma de decisiones:

1. ¿Estoy trabajando en una situación restringida como un controlador de dispositivo? Usar C.
2. ¿Estoy escribiendo una biblioteca de Linux que alguien más tendrá que usar? Usar C.
3. ¿Estoy trabajando dentro del código que ya está escrito en C? Usar C.
4. ¿Estoy escribiendo una biblioteca de Mac o Windows, o una biblioteca de Linux que solo usaré? Escriba las partes internas en C ++, pero solo exponga una interfaz C para evitar el frágil problema de la interfaz binaria.
5. Utiliza C ++.

Una cosa buena es que debido a que C ++ puede compilar C, si realmente necesita un control detallado sobre el código generado para una situación particular, puede escribir C para eso y C ++ para el resto, y compilarlo todo con el compilador de C ++ .

Sí, pero depende del proyecto. C es muy bueno para algunos proyectos de bajo nivel o parte de la solución más grande.

P.ej. Para la lógica de negocios está bien, pero no para la interfaz de usuario.

si tiene que ser ambos

• rápido y
• portátil

entonces uso C. Quizás C ++.

Sí, de hecho lo he hecho recientemente!

Me gusta programar en C. Hago la mayor parte de mi programación en Python, pero hay momentos en que necesito un código rápido y realmente disfruto de la elegancia que proviene de la simplicidad del lenguaje.

El proyecto en el que estoy trabajando ahora es una base de datos que, como pueden imaginar, es crítica para el rendimiento. En este momento estoy usando C y algo de Python, pero eventualmente será predominantemente, si no completamente C.

¡Si!

C es un lenguaje de bajo nivel y hay una situación en la que C es casi la única opción, como si uso C para programar microcontroladores, o si juntamos un código para interactuar con dispositivos de puertos clásicos como Parallel, Serial o incluso Modem.

Si. Pasé la mayor parte de mi carrera programando C ++, pero ahora escribo la mayor parte de mi código en Ruby y si necesito rendimiento o acceso a cosas de bajo nivel, escribo una extensión C. ¡Es el futuro hombre!

Usaría C si estuviera escribiendo un sistema operativo. Dado que eso no va a suceder en los próximos veinte años, a menos que toque la lotería y no tenga nada más que hacer que hacer mi propia distribución de Linux increíble, probablemente me limitaré a C #, Java, Python, etc., etc. No usé C en mucho tiempo, pero siempre disfruté usarlo; Sin embargo, creo que en estos días mi cabeza está tan envuelta alrededor de OO si tengo que volver a hacerlo, me tomaría un poco volver a rodar.

C ++ es portátil a través de plataformas y dispositivos integrados como microcontroladores. (C ++ se puede compilar en C, por lo tanto, microcontroladores).

C es incluso portátil (como funciones foráneas) a otros lenguajes. Por lo tanto, si programo bibliotecas de bajo nivel, entonces quiero más compatibilidad que C ++.

Haskell es portátil a través de plataformas (ARM llegará pronto) pero NO dispositivos integrados como microcontroladores. Su velocidad es comparable a C y C ++; pero debido a que es funcional, utiliza un recolector de basura en lugar de una pila de tiempo de ejecución, por lo tanto, puede ser más rápido y más lento que C en diferentes momentos (recolección de basura) y en diferentes situaciones (continuaciones en lugar de llamadas de subrutina).

Elijo el lenguaje más abstracto posible, porque la velocidad del programa no difiere sino el tiempo de desarrollo y la tasa de errores. C y C ++ difieren mucho, pero no desde el punto de vista de Haskell.

No prefiero otros idiomas, aunque conozco uno o dos a mano. ... excepto en algunos casos, bueno, bash .

Los sistemas integrados con frecuencia no tienen más que unos pocos kilobytes de RAM y quizás un par de docenas de kilobytes de memoria flash, con una velocidad de reloj del procesador de unos pocos MHz. C es la única opción que tiene sentido en un entorno de metal desnudo.