¿Por qué no debería #incluir <bits / stdc ++. H>?

Publiqué una pregunta con mi código cuya única #includedirectiva era la siguiente:

#include <bits/stdc++.h>

Mi profesor me dijo que hiciera esto, pero en la sección de comentarios me informaron que no debía hacerlo.

¿Por qué?

La inclusión <bits/stdc++.h>parece ser algo cada vez más común de ver en Stack Overflow, quizás algo recientemente agregado a un plan de estudios nacional en el año académico actual.

Me imagino que las ventajas se dan vagamente así:

• Solo necesitas escribir una #includelínea
• No es necesario buscar en qué encabezado estándar está todo

Desafortunadamente, este es un truco perezoso, nombrando un encabezado interno de GCC directamente en lugar de encabezados estándar individuales como <string>, <iostream>y <vector>. Arruina la portabilidad y fomenta hábitos terribles.

Las desventajas incluyen:

• Probablemente solo funcione en ese compilador
• No tiene idea de lo que hará cuando lo use, porque su contenido no está establecido por un estándar
• Incluso actualizar su compilador a su propia próxima versión puede romper su programa
• Cada encabezado estándar debe analizarse y compilarse junto con su código fuente, que es lento y da como resultado un ejecutable voluminoso bajo ciertas configuraciones de compilación

¡No lo hagas!

Más información:

• #include <bits / stdc ++. h> con Visual Studio no se compila
• ¿Cómo funciona #include <bits / stdc ++. H> en C ++?

Ejemplo de por qué Quora es malo:

• ¿Es una buena práctica usar #include <bits / stdc ++. H> en concursos de programación en lugar de enumerar muchas inclusiones?

¿Por qué? Porque se usa como si se suponiera que fuera un encabezado estándar de C ++, pero ningún estándar lo menciona. Entonces, su código no es portátil por construcción. No encontrará ninguna documentación al respecto en cppreference . Así que bien podría no existir. Es producto de la imaginación de alguien :)

He descubierto, para mi horror e incredulidad, que hay un sitio de tutoriales muy conocido en el que cada ejemplo de C ++ parece incluir este encabezado . El mundo está loco. Esa es la prueba.

Para cualquiera que escriba tales "tutoriales"

Deje de usar este encabezado. Olvídalo. No propague esta locura. Si no está dispuesto a entender por qué hacer esto está mal , confíe en mi palabra. No me parece bien que me traten como una figura de autoridad en nada en absoluto, y probablemente estoy lleno de eso la mitad del tiempo, pero haré una excepción solo en este caso. Afirmo que sé de lo que estoy hablando aquí. Confía en mi palabra. Te lo imploro.

PD: Puedo imaginarme bien el abominable "estándar de enseñanza" donde pudo haber tenido lugar esta malvada idea, y las circunstancias que la llevaron. El hecho de que parezca haber una necesidad práctica no lo hace aceptable, ni siquiera en retrospectiva.

PPS No, no había ninguna necesidad práctica. No hay muchos encabezados estándar de C ++ y están bien documentados. Si enseñas, les estás haciendo un flaco favor a tus estudiantes al agregar esa "magia". Producir programadores con una mentalidad mágica es lo último que queremos. Si necesita ofrecer a los estudiantes un subconjunto de C ++ para hacerles la vida más fácil, simplemente produzca un folleto con la lista breve de encabezados aplicables al curso que enseña y con documentación concisa para las construcciones de la biblioteca que espera que los estudiantes usen.

Hay un sitio de Stack Exchange llamado Programming Puzzles & Code Golf . Los acertijos de programación en ese sitio se ajustan a esta definición de acertijo :

un juguete, problema u otro artilugio diseñado para divertir al presentar dificultades que deben resolverse con ingenio o esfuerzo paciente.

Están diseñados para divertir, y no de la forma en que un programador en activo 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 informática recreativa en la que los participantes se esfuerzan por lograr el código fuente más corto posible que implemente cierto algoritmo". En las respuestas del sitio de PP&CG, verá que las personas especifican la cantidad de bytes en sus respuestas. Cuando encuentren una manera de recortar algunos bytes, tacharán el número original y registrarán el nuevo.

Como era de esperar, el golf de código recompensa 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. Funciones indocumentadas. Prácticas de programación no estándar. Hacks espantosos.

Si un programador envía una solicitud de extracción en el trabajo que contiene un código de estilo golf, sería rechazada. Sus compañeros de trabajo se reirían de ellos. Su gerente pasaba por su escritorio para charlar. Aun así, los programadores se divierten enviando respuestas a PP&CG.

¿Qué tiene esto que ver stdc++.h? Como han señalado otros, 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 malos hábitos. No es estándar, por lo que el comportamiento de su programa puede diferir de lo esperado. 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 acertijos 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 la que envían una solución. Para maximizar la velocidad de ejecución, muchos participantes utilizan C ++. Para maximizar la velocidad de codificación, algunos de ellos usan stdc++.h.

¿Es esto una buena idea? Revisemos 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 estándares? No es relevante para un bloque de código cuya vida útil sea inferior a una hora. ¿Tiempo de compilación y tamaño ejecutable? Estos no forman parte de la rúbrica de puntuación del concurso.

Entonces nos quedamos con malos hábitos. Ésta 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 dedicar tiempo a buscar 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 programación competitiva si fomenta malos hábitos como usar stdc++.hy violar otros estándares de codificación. Una respuesta es que la gente lo hace por la misma razón por la que publican programas en PP&CG: algunos programadores encuentran divertido usar sus habilidades de codificación en un contexto similar al de un juego.

Entonces, la cuestión de si se debe usar stdc++.hse 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 usarla.

Esta pregunta pregunta: "¿Por qué no debería #incluir <bits/stdc++.h>?" Me doy cuenta de que se preguntó 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 donde la respuesta puede ser diferente.

De N4606, Borrador de trabajo, Estándar para lenguaje de programación C ++:

17.6.1.2 Encabezados [encabezados]

1. Cada elemento de la biblioteca estándar de C ++ se declara o define (según corresponda) en un encabezado.

2. La biblioteca estándar C ++ proporciona 61 encabezados de biblioteca C ++, como se muestra en la Tabla 14.

Tabla 14 - Encabezados de la biblioteca de C ++

<algorithm> <future> <numeric> <strstream>
<any> <initializer_list> <optional> <system_error>
<array> <iomanip> <ostream> <thread>
<atomic> <ios> <queue> <tuple>
<bitset> <iosfwd> <random> <type_traits>
<chrono> <iostream> <ratio> <typeindex>
<codecvt> <istream> <regex> <typeinfo>
<complex> <iterator> <scoped_allocator> <unordered_map>
<condition_variable> <limits> <set> <unordered_set>
<deque> <list> <shared_mutex> <utility>
<exception> <locale> <sstream> <valarray>
<execution> <map> <stack> <variant>
<filesystem> <memory> <stdexcept> <vector>
<forward_list> <memory_resorce> <streambuf>
<fstream> <mutex> <string>
<functional> <new> <string_view>

No hay <bits / stdc ++. H> allí. Esto no es sorprendente, ya que los encabezados <bits / ...> son detalles de implementación y generalmente llevan una advertencia:

*  This is an internal header file, included by other library headers.
*  Do not attempt to use it directly. 

<bits / stdc ++. h> también lleva una advertencia:

*  This is an implementation file for a precompiled header.

La razón por la que no usamos:

#include <bits/stdc++.h>

se debe a la eficiencia. Permítanme hacer una analogía: Para aquellos de ustedes que conocen Java: Si le preguntaran a su instructor si lo siguiente era una buena idea, a menos que sea un mal instructor, dirían que no:

import java.*.*

La cosa #include ... hace lo mismo básicamente ... Esa no es la única razón para no usarlo, pero es una de las principales razones para no usarlo. Para una analogía de la vida real: imagina que tienes una biblioteca y quieres pedir prestados un par de libros de la biblioteca, ¿reubicarías toda la biblioteca al lado de tu casa? Sería caro e ineficaz. Si solo necesitas 5 libros, entonces solo saca 5 ... No toda la biblioteca .....

#include <bits/stdc++.h>

Parece conveniente al aspecto del programa. Solo necesito escribir una declaración de inclusión y funciona, lo mismo que con mover una biblioteca completa, mira, solo necesito mover una biblioteca completa en lugar de 5 libros, uno por uno. ¿Le parece conveniente, es decir, para la persona que realmente tiene que hacer la mudanza? No tanto, y adivinen qué en C ++ la persona que hará la mudanza será su computadora ... La computadora no disfrutará moviendo toda la biblioteca por cada archivo fuente que escriba:) .....