¿Por qué el código en la mayoría de las implementaciones de STL es tan intrincado?

Question

El STL es una pieza fundamental del mundo de C++, la mayoría de las implementaciones derivan de los esfuerzos iniciales de Stepanov y Musser.

Mi pregunta es dada la criticidad del código, y es una de las fuentes principales para que las personas vean ejemplos de C++ bien escrito para asombro y propósitos de aprendizaje: ¿Por qué son tan desagradables las diversas implementaciones de la STL? a - ejemplos enrevesados ​​y generalmente buenos de cómo no escribir código C++ desde un punto de vista estético.

Los siguientes ejemplos de código no pasarán la revisión de código en los lugares en los que he trabajado por razones que varían desde nomenclatura variable, diseño, macros y usos de operadores que requieren más que un simple vistazo para descubrir qué está ocurriendo realmente .

template<class _BidIt> inline 
bool _Next_permutation(_BidIt _First, _BidIt _Last) 
{ // permute and test for pure ascending, using operator< 
_BidIt _Next = _Last; 
if (_First == _Last || _First == --_Next) 
    return (false); 

for (; ;) 
    { // find rightmost element smaller than successor 
    _BidIt _Next1 = _Next; 
    if (_DEBUG_LT(*--_Next, *_Next1)) 
     { // swap with rightmost element that's smaller, flip suffix 
     _BidIt _Mid = _Last; 
     for (; !_DEBUG_LT(*_Next, *--_Mid);) 
     ; 
     _STD iter_swap(_Next, _Mid); 
     _STD reverse(_Next1, _Last); 
     return (true); 
     } 

    if (_Next == _First) 
     { // pure descending, flip all 
     _STD reverse(_First, _Last); 
     return (false); 
     } 
    } 
} 


_Ty operator()() 
    { // return next value 
    static _Ty _Zero = 0; // to quiet diagnostics 
    _Ty _Divisor = (_Ty)_Mx; 

    _Prev = _Mx ? ((_Ity)_Ax * _Prev + (_Ty)_Cx) % _Divisor 
     : ((_Ity)_Ax * _Prev + (_Ty)_Cx); 
    if (_Prev < _Zero) 
     _Prev += (_Ty)_Mx; 
    return (_Prev); 
    } 

Tenga en cuenta que no estoy criticando la interfaz, ya que está muy bien diseñada y es aplicable. Lo que me preocupa es la legibilidad de los detalles de implementación.

A preguntas similares se han planteado anteriormente:

Is there a readable implementation of the STL

Why STL implementation is so unreadable? How C++ could have been improved here?

Nota: El código presentado anteriormente se toma de MSVC 2010 algoritmo de cola o cabeceras.

Answer 1

Acerca de los nombres de variables, los implementadores de bibliotecas deben usar convenciones de nombres "locas", como los nombres que comienzan con un guión bajo seguido de una letra mayúscula, porque dichos nombres están reservados para ellos. No pueden usar nombres "normales", porque pueden haber sido redefinidos por una macro de usuario.

Sección 17.6.3.3.2 "nombres globales" § 1 establece:

Ciertos conjuntos de nombres y firmas de función son siempre reservados a la aplicación:

• Cada nombre que contiene una doble subrayado o comienza con un guión bajo seguido de una letra mayúscula que se reserva para la implementación para cualquier uso.

• Cada nombre que comienza con un guión bajo está reservado a la implementación para usarlo como un nombre en el espacio de nombres global.

(Tenga en cuenta que estas reglas prohíben a los guardias de cabecera como __MY_FILE_H que he visto muy a menudo.)

Answer 2

Los nombres de variables por la razón de que este es el código de la biblioteca estándar, y se debe utilizar nombres reservados para detalles de implementación en encabezados. Lo que sigue debe no romper las bibliotecas estándar:

#define mid 
#include <algorithm> 

cabeceras biblioteca Así estándar no pueden usar mid como nombre de variable, por lo tanto, _Mid.El STL era diferente, no era parte de la especificación del lenguaje, se definió como "aquí hay algunos encabezados, úselos como lo hará"

Su código o el mío, por otro lado, no serían válidos si _Mid utilizado como nombre de variable ya que es un nombre reservado - se permite la puesta en práctica de hacerlo:

#define _Mid 

si se siente como él.

Layout - meh. Probablemente tengan una guía de estilo, probablemente la sigan, más o menos. El hecho de que no coincida con mi guía de estilo (y por lo tanto, fallaría mi revisión del código) no es nada para ellos.

Operadores que son difíciles de resolver, ¿a quién le cuesta? El código debe escribirse para las personas que lo mantienen, y GNU/Dinkumware/quien probablemente no quiera dejar que las personas pierdan en las bibliotecas estándar que no pueden descifrar el *--_Next de un vistazo. Si usa ese tipo de expresión, se acostumbrará, y si no lo hace continuará teniendo dificultades.

Yo le daré, sin embargo, que la sobrecarga operator() es un galimatías. [Editar: Lo entiendo, es un generador congruente lineal, hecho muy genéricamente, y si el módulo es "0" eso significa simplemente usar el envolvente natural del tipo aritmético.]

Answer 3

Sospecho que parte de la razón es que el código en el STL está altamente optimizado. El tipo de código que se implementa tiene un rendimiento mucho más importante que la legibilidad. Debido a que son tan ampliamente utilizados, tiene sentido hacerlos lo más rápido posible.

Answer 4

Las implementaciones varían. libc++ por ejemplo, es mucho más fácil para los ojos. Todavía hay un poco de ruido de guión bajo. Como otros han notado, desafortunadamente se requieren los caracteres de subrayado iniciales. Aquí está la misma función en libC++:

template <class _Compare, class _BidirectionalIterator> 
bool 
__next_permutation(_BidirectionalIterator __first, _BidirectionalIterator __last, _Compare __comp) 
{ 
    _BidirectionalIterator __i = __last; 
    if (__first == __last || __first == --__i) 
     return false; 
    while (true) 
    { 
     _BidirectionalIterator __ip1 = __i; 
     if (__comp(*--__i, *__ip1)) 
     { 
      _BidirectionalIterator __j = __last; 
      while (!__comp(*__i, *--__j)) 
       ; 
      swap(*__i, *__j); 
      _STD::reverse(__ip1, __last); 
      return true; 
     } 
     if (__i == __first) 
     { 
      _STD::reverse(__first, __last); 
      return false; 
     } 
    } 
} 

Answer 5

Neil Butterworth, que figura ahora como "anon", proporciona un enlace útil en su respuesta al pliego de cuestionar "Is there a readable implementation of the STL?". Citando su respuesta allí:

Hay un libro de la biblioteca de plantillas de C++ estándar , co-escrito por los diseñadores STL originales Stepanov & Lee (junto con PJ Plauger y David Musser), que describe una posible implementación, completa con el código - ver http://www.amazon.co.uk/C-Standard-Template-Library/dp/0134376331.

Consulte también las otras respuestas en ese hilo.

De todos modos, la mayor parte del código STL (por STL I significa el subconjunto similar a STL de la biblioteca estándar de C++) es código de plantilla, y como tal debe ser solo de encabezado, y como se usa en casi todos los programas paga para tener ese código lo más corto posible.

Por lo tanto, el punto de equilibrio natural entre concisión y legibilidad está mucho más lejos en el extremo de concisión de la escala que con el código "normal". Además, la biblioteca estándar es donde la vista independiente del sistema del código de la aplicación está conectada al sistema subyacente, utilizando todo tipo de cosas específicas del compilador que usted como desarrollador de aplicaciones debería evitar.

Saludos & HTH.,

Answer 6

para añadir en lo que se ha dicho ya, el estilo que se ve es el estilo de GNU. ¿Feo? Tal vez, eso está en el ojo del espectador. Pero es un estilo estrictamente definido, y hace que todos los códigos se vean de manera similar, a diferencia de los que se resisten a acostumbrarse.