Hay un sitio de Stack Exchange llamado Programming Puzzles & Code Golf . Los rompecabezas de programación en ese sitio se ajustan a esta definición de rompecabezas :
un juguete, problema u otro dispositivo diseñado para divertirse presentando dificultades para ser resueltas por ingenio o esfuerzo paciente.
Están diseñados para divertir, y no de la manera en que un programador que trabaja podría divertirse con un problema del mundo real que se encuentra en su trabajo diario.
Code Golf es "un tipo de competencia de programación de computadoras recreativas en la que los participantes se esfuerzan por lograr el código fuente más corto posible que implemente un cierto algoritmo". En las respuestas en el sitio PP&CG, verá que las personas especifican el número de bytes en sus respuestas. Cuando encuentren una manera de reducir algunos bytes, tacharán el número original y registrarán el nuevo.
Como es de esperar, el golf de código premia el abuso extremo del lenguaje de programación. Nombres de variables de una letra. Sin espacios en blanco. Uso creativo de las funciones de la biblioteca. Características indocumentadas. Prácticas de programación no estándar. Hacks espantosos.
Si un programador presentó una solicitud de extracción en el trabajo que contiene un código de estilo de golf, sería rechazada. Sus compañeros de trabajo se reirían de ellos. Su gerente pasaría por su escritorio para conversar. Aun así, los programadores se divierten enviando respuestas a PP&CG.
¿Con qué tiene que ver esto stdc++.h
? Como otros han señalado, usarlo es perezoso. No es portátil, por lo que no sabe si funcionará en su compilador o en la próxima versión de su compilador. Fomenta los malos hábitos. No es estándar, por lo que el comportamiento de su programa puede diferir de lo que espera. Puede aumentar el tiempo de compilación y el tamaño del ejecutable.
Todas estas son objeciones válidas y correctas. Entonces, ¿por qué alguien usaría esta monstruosidad?
Resulta que a algunas personas les gusta programar rompecabezas sin el código golf . Se reúnen y compiten en eventos como ACM-ICPC, Google Code Jam y Facebook Hacker Cup, o en sitios como Topcoder y Codeforces. Su rango se basa en la corrección del programa, la velocidad de ejecución y la rapidez con que presentan una solución. Para maximizar la velocidad de ejecución, muchos participantes usan C ++. Para maximizar la velocidad de codificación, algunos de ellos usan stdc++.h
.
¿Es esta una buena idea? Veamos la lista de desventajas. ¿Portabilidad? No importa, ya que estos eventos de codificación utilizan una versión específica del compilador que los concursantes conocen de antemano. Cumplimiento de normas? No es relevante para un bloque de código cuya vida útil es inferior a una hora. ¿Tiempo de compilación y tamaño ejecutable? Estos no son parte de la rúbrica de puntuación del concurso.
Entonces nos quedamos con malos hábitos. Esta es una objeción válida. Al usar este archivo de encabezado, los concursantes evitan la oportunidad de aprender qué archivo de encabezado estándar define la funcionalidad que están usando en su programa. Cuando escriben código del mundo real (y no lo usan stdc++.h
) tendrán que pasar tiempo buscando esta información, lo que significa que serán menos productivos. Esa es la desventaja de practicar con stdc++.h
.
Esto plantea la pregunta de por qué vale la pena participar en la programación competitiva si fomenta malos hábitos como usar stdc++.h
y violar otros estándares de codificación. Una respuesta es que las personas lo hacen por la misma razón por la que publican programas en PP&CG: a algunos programadores les resulta agradable usar sus habilidades de codificación en un contexto similar a un juego.
Entonces, la cuestión de si usar stdc++.h
se reduce a si los beneficios de la velocidad de codificación en un concurso de programación superan los malos hábitos que uno podría desarrollar al usarlo.
Esta pregunta es: "¿Por qué no debería #incluir <bits/stdc++.h>
?" Me doy cuenta de que se hizo y respondió para hacer un punto, y la respuesta aceptada pretende ser la única respuesta verdadera a esta pregunta. Pero la pregunta no es "¿Por qué no debería #incluir <bits/stdc++.h>
en el código de producción?" Por lo tanto, creo que es razonable considerar otros escenarios en los que la respuesta puede ser diferente.
using namespace std;
en algún lugar.