Uso de typedef fuerte como una alternativa más ligera a la biblioteca Boost Parameter?

Question

A menudo utilizo la utilidad de tipo de letra fuerte de Boost para mejorar la seguridad de mis programas. Por ejemplo, escribiendo código como este:

BOOST_STRONG_TYPEDEF(int, X) 
BOOST_STRONG_TYPEDEF(int, Y) 
BOOST_STRONG_TYPEDEF(int, Width) 
BOOST_STRONG_TYPEDEF(int, Height) 

struct Rect { 
    Rect(X x, Y y, Width w, Height h); 
}; 

// Usage: 
Rect rect(X(10), Y(20), Width(800), Height(600)); 

La fuerte typedef aquí mejora la legibilidad y la seguridad de código. (El compilador informará de un error si los argumentos se proporcionan en el orden equivocado, lo cual no habría sido el caso si los argumentos eran todos int.)

Mis preguntas son:

• ¿Está bien use BOOST_STRONG_TYPEDEF para este propósito? (La documentación es very brief.)
• ¿Existen razones importantes para preferir la biblioteca de parámetros de refuerzo en su lugar?

Answer 1

punto de vista técnico:

• que funciona
• que añade seguridad de tipos

En términos prácticos:

no recomendaría la creación de nuevos tipos sólo por el bien de una función única de parámetros (a menos que sea una enumeración específica de esta función), los tipos deben impregnar la aplicación para evitar que los moldes se utilicen una y otra vez.

Si se utilizan los tipos X, Y, Width y Height en toda la aplicación, entonces no sólo no habrá ningún molde, pero su aplicación será mucho más seguro y mucho mejor documentado también (sí ... Soy un tipo monstruo).

Ahora, con respecto a Boost.Parameters, esto es completamente diferente.

Boost.Parameters se pueden (posiblemente) agregar cuando ya tiene tipos instalados. Honestamente, aunque nunca vi la necesidad. Cuando las funciones crecen de forma tan inmanejable que se requiere que Boost.Parameters las llame, debe corregir las funciones, no aumentar el desorden.

Answer 2

El uso de BOOST_STRONG_TYPDEF está creando un nuevo tipo, mientras que la biblioteca de parámetros de refuerzo es para dar nombres a los parámetros. Te permite ser más explícito con tus funciones. Por ejemplo (a partir de la documentación impulso)

#include <boost/parameter/preprocessor.hpp> 

namespace graphs 
{ 
    BOOST_PARAMETER_FUNCTION(
     (void),    // 1. parenthesized return type 
     depth_first_search, // 2. name of the function template 

     tag,     // 3. namespace of tag types 

     (required (graph, *)) // 4. one required parameter, and 

     (optional    // four optional parameters, with defaults 
     (visitor,   *, boost::dfs_visitor<>()) 
     (root_vertex,  *, *vertices(graph).first) 
     (index_map,   *, get(boost::vertex_index,graph)) 
     (in_out(color_map), *, 
      default_color_map(num_vertices(graph), index_map)) 
    ) 
) 
    { 
     // ... body of function goes here... 
     // use graph, visitor, index_map, and color_map 
    } 
} 

le permite decir explícitamente lo que se espera, casi en un diseño por el contrato tipo de camino. Sin embargo, creo que esto complica la legibilidad de su código lo suficiente como para que no valga la pena hacerlo.

Personalmente, prefiero usar BOOST_STRONG_TYPEDEF, ya que crea un nuevo tipo "que se puede usar para unir funciones o parámetros de plantilla" (nuevamente desde la documentación de impulso).