C++: ¿usar auto o typedef?

Odio hacer una pregunta intencionalmente subjetiva aquí, pero no tengo a nadie más para preguntar esto directamente ...C++: ¿usar auto o typedef?

Estoy tratando de "liderar con el ejemplo" en mi equipo adoptando más conceptos modernos de C++ en el nuevo código que escribo. Mis compañeros de trabajo son un poco tímidos con las plantillas y se quejan de tener que escribir unique_ptr<Foobar> o shared_ptr<Foobar> en vez de solo Foobar* cuando utilizo algunas clases que he creado recientemente (los métodos de fábrica devuelven unique_ptr sy yo almaceno listas de estos objetos en vectores usando shared_ptr).

Me torcieron el brazo y me convencieron para convertirlos en algo más fácil de escribir, por ejemplo FoobarUniquePtr.

Pero ahora estoy en un lio de const-correctness con estos typedefs. Tendría que definir typedefs adicionales para cada tipo const y non const, y const const_FoobarUniquePtr no parece expresar correctamente la semántica const.

Entonces, para mi pregunta, ¿tendría sentido dejar de usar estos typedefs y en su lugar empujar auto a mis compañeros de equipo cuando se quejan de tener que escribir los punteros inteligentes con plantillas? También estoy abierto a otras alternativas.

Fuente

2012-02-16 Bret Kuhns

+1 por intentar hacer que tus compañeros de trabajo utilicen prácticas más modernas. – Nick

¿Cuál es el problema con 'unique_ptr ' o 'const unique_ptr '? – Useless

parece que el auto fue creado solo para este tipo de cosas. es un buen atajo que te permite simplemente poner el auto en lugar de averiguar exactamente qué tipo necesitas usar para la variable. cuando preguntas si tiene sentido, bueno, es parte del estándar de lenguaje y usarlo de esta manera me suena 'correcto'. Pero, por supuesto, podrían surgir algunas preferencias personales, ya que supongo que algunos podrían argumentar que preferirían ver el tipo explícito en cualquier lugar que se utilice y no confiar en el auto. Pero más allá de las preferencias personales, parece un uso válido. – Nerdtron

En general, auto hace su vida mucho más fácil.

Si no está enviando en arquitecturas esotéricas (y no tiene planes de hacerlo pronto), la respuesta debería ser "use auto siempre que pueda".

Fuente

2012-02-16 13:55:32 x10

Esto no siempre es un buen consejo (aunque eso también se aplica a este comentario). A veces, la intención del programador puede estar oculta o, en casos excepcionales, puede suceder algo inesperado, y será difícil de rastrear si está utilizando un compilador malvado de compilador de mensajes de error como GCC o MSVC. – rubenvb

@rubenvb Estoy de acuerdo. Herb Sutter declaró recientemente en su discurso de apertura en GoingNative 2012 que siempre deberíamos usar 'auto' excepto cuando queremos hacer conversiones de tipo. Espero que sea intencionalmente sensacional. Por ahora, solo estoy usando auto para cosas como los iteradores de STL, donde a nadie realmente le importa el tipo y todos saben lo que será de todos modos. Si el nombre del método en sí mismo transmite el comportamiento/intención del tipo (especialmente si el tipo de devolución es parte de un parámetro de plantilla), podría vivir con alguien que use 'auto', pero no lo haría de manera predeterminada. –

Supongo que debe definir todas las variaciones que pueda necesitar.

Consigue que tus amigos vean la presentación de Bjarne Stoustrup y lean algunos de los blogs en C++ 11. En cuanto a las plantillas, compre algunos de los libros en la lista de libros y "coincedentialmente" colóquelos en su escritorio para comenzar la discusión.

Incluso puede escribir algunas presentaciones de PowerPoint y presentarlas a los miembros de su equipo para crear una cultura de investigación.

Bjarne Stroustrup: C++11 Style

lista de libros: https://stackoverflow.com/tags/c%2b%2b/info

Fuente

2012-02-16 14:17:55 Damian

Gracias por el consejo. Casualmente, ya estoy haciendo todo esto. Acabo de terminar de ver todas las notas principales de GoingNative 2012, así como "C++ y más allá", y algunas otras que pude encontrar en línea. Recientemente compré "Modern C++ Design", pero ese código de plantilla probablemente no va a ganar a mis compañeros de trabajo, al menos no hasta que yo mismo escriba algo y mis compañeros de trabajo capten la flexibilidad. También he estado haciendo mis propias presentaciones sobre const-correctness, semántica de propiedad (y semántica de movimiento), Lambdas, y luego una presentación de popurrí de las características de C++ 11. –

tendría que definir typedefs adicionales para cada const y no const tipo

... lo que provocará una explosión combinatoria como Aumenta el número de lugares donde un const encaja en el tipo. Explique a sus colegas que la cantidad de trabajo que realiza aumenta exponencialmente porque están luchando contra el idioma en lugar de usarlo. Y sí, use auto cuando corresponda.

Fuente

2012-02-16 14:21:47

Cuando creo una nueva clase una de las primeras cosas que hago es:

class MyClass 
{ 
public: // Typedefs 
    typedef std::shared_ptr<MyClass> Ptr; 
    typedef std::shared_ptr<const MyClass> ConstPtr; 
};

A continuación, el usuario de mi clase puede usarla como:

MyClass::Ptr pMyClass = std::make_shared<MyClass>();

La razón por la que los agrego a la clase como typedefs públicos es odio para contaminar el espacio de nombres global.

Fuente

2012-02-16 14:34:10

Había considerado ese enfoque.Mi único problema con su 'MyClass :: ConstPtr' es que lo leería como si' ptr' fuera 'const', no el objeto' MyClass'. No se me ocurre una convención de nomenclatura que transmita adecuadamente lo que el lenguaje proporciona con facilidad, por lo que me inclino por evitar el typedefs y simplemente usar el lenguaje. –

Respuesta

Cuestiones relacionadas