¿Práctica mala del tipo de alcance de clase?

Question

¿Es una mala práctica declarar un typedef en el alcance de clase? ¿Es mejor declararlos para cada función para asegurarse de que nadie incluye ese archivo y luego crea algo con el mismo nombre?

Por ejemplo

typedef std::vector<int>::size_type vec_int; 

serían útiles en algunos de mis cabeceras como en algunas clases hay muchas funciones que utilizan este tipo, pero por otro lado me tendrían que ponerlo en la cabecera, wouldn ¿Yo? ¿O podría ponerlo en la parte superior del archivo fuente?

Answer 1

Yo diría que simplemente mantenga el alcance al mínimo; con eso, haz lo que sea más limpio.

Si lo usa para una función, guárdelo en el alcance de esa función. Si lo usa para varias funciones, conviértalo en un typedef privado. Y si espera que otros lo usen (quizás fuera de utilidad), hágalo público.

En código:

namespace detail 
{ 
    // By convention, you aren't suppose to use things from 
    // this namespace, so this is effectively private to me. 

    typedef int* my_private_type; 
} 

void some_func() 
{ 
    // I am allowed to go inside detail: 
    detail::my_private_type x = 0; 

    /* ... */ 
} 

void some_other_func() 
{ 
    // I only need the typedef for this function, 
    // so I put it at this scope: 
    typedef really::long::type<int>::why_so_long short_type; 

    short_type x; 

    /* ... */ 
} 

typedef int integer_type; // intended for public use, not hidden 

integer_type more_func() 
{ 
    return 5; 
} 

class some_class 
{ 
public: 
    // public, intended for client use 
    typedef std::vector<int> int_vector; 

    int_vector get_vec() const; 

private: 
    // private, only for use in this class 
    typedef int* int_ptr; 
}; 

Esperemos que da una idea de lo que quiero decir.

Answer 2

Los tipos de rango de clase son perfectamente correctos, y no pueden entrar en conflicto con nada fuera del alcance de la clase.

La librería estándar se ha asociado con typedefs ámbito de clase (value_type, pointer, reference, iterator, const_iterator etc, etc).