mid - string substring c++>

¿Std:: string es parte de STL?

Question

^{(Cuando digo STL, estoy hablando de la biblioteca de plantillas que gira en torno a contenedores, iteradores, algoritmos y funtores).}
Esta pregunta me vino a la mente después de pensar que una std::string comporta principalmente como un contenedor normal, con funciones de begin y end (incluyendo iterador), una función de size y la posibilidad de usar todos esos para algoritmos STL normales que funcionan en contenedores / se extiende a través de sus iteradores (por ejemplo, transform , sort , find , etc.).

Al mismo tiempo, sin embargo, no es un contenedor en sí mismo, ya que no encaja en la imagen de los contenedores que almacenan datos arbitrarios. Además, opera en los datos contenidos principalmente a través de funciones miembro, como substr , find_first_of , etc., mientras que el contenedor true no hace eso y permite que los algoritmos manejen eso.

Además, el sitio de referencia cplusplus y el estándar C ++ no incluyen std::string junto con los contenedores reales, sino en una categoría distinta.
Sin embargo, en el sitio STL de SGI , basic_string (y, en consecuencia, el string typedef) se mencionan con el otro contenedor y el sitio de referencia basic_string indica que pertenece a la categoría "contenedores".

Ahora mi pregunta es, ¿la string es realmente parte de la STL o es una biblioteca distinta en sí misma?
Y si ahora pertenece al STL, ¿difería en el STL original desarrollado por Stepanov?

Answer 1

Es parte de STL de hecho. Y std :: string es solo basic_string typedef. Es contenedor, especializado (no en c ++ "especialización", que significa :)) para el almacenamiento de datos con semántica de cadenas. Sin embargo, no tengo idea de Stepanov. Vale la pena mencionar que STL es "Biblioteca de plantillas estándar", no solo la subparte de contenedores. Eso incluye algoritmos, secuencias y algunos rasgos.

Answer 2

No hay una respuesta real a esto. Por un lado, std::string se desarrolló completamente independiente de los otros contenedores. Por otro lado, se ha agregado lo suficiente para cumplir con todos los requisitos de un contenedor de acceso aleatorio. Si elige clasificarlo como parte de "STL" o no depende totalmente de usted, al final, solo señala el hecho de que "STL" carece de una única definición acordada, y las posibilidades de que ocurra repentinamente obtener un significado claro es remoto (por decirlo de una manera agradable).

IOW, "STL" es una abreviatura pésima porque la gente lo usa para significar al menos tres cosas diferentes, pero, desafortunadamente, no hay una mejor abreviación con un significado mejor definido, por lo que STL permanece en uso y probablemente continuará hacerlo (y continuar obstruyendo la comunicación) indefinidamente.

Answer 3

No en realidad no. Y sí, más o menos.

Existen diversas definiciones de "STL" , que incluyen:

• El HP / SGI STL real, la biblioteca original, partes de las cuales se basó la Biblioteca Estándar de C ++. Incluyeron contenedores, iteradores y algoritmos. Las cuerdas no fueron parte de esto.

• Las partes de la biblioteca estándar de C ++ que se basaron en la biblioteca SGI STL: contenedores, iteradores y algoritmos. Todavía sin cadenas.

• Toda la biblioteca estándar de C ++. Esta definición no tiene absolutamente ninguna base en lógica o realidad, si se sigue, se incluiría std::string .

Tenga en cuenta que el STL actual se ha desarrollado desde que C ++ fue estandarizado (hace unos 13 años, recuerde), y han adoptado al revés algunas de las cosas que entraron en el estándar, como las cadenas. Esto no significa que estaban originalmente allí en 1998 ... pero ahora están ahí por razones de "compatibilidad".

Resumen

El STL era contenedores, algoritmos e iteradores.

Se adoptaron cadenas y flujos para C ++ 98, y luego se adoptaron hacia atrás para el SGI STL moderno.

Si las cadenas son "parte del STL" o no depende de si usted sigue la lógica y la razón, o si llama a la biblioteca estándar "STL".

Espero que esto ayude.