c++ - smart - unique pointer

¿Por qué shared_ptr<T>:: use_count() devuelve un tipo long en lugar de un tipo sin signo?

Question

shared_ptr observers 20.8.2.2.5 Borrador final de C ++ 14 (n4296)

   long use_count() const noexcept;

Devuelve: el número de objetos shared_ptr , *this incluido, que comparte la propiedad con *this , o 0 cuando *this está vacío.

[Nota: use_count() no es necesariamente eficiente. - nota final]

Answer 1

La razón es que el tipo más apropiado para un contador de este tipo es un entero con signo regular, incluso si este contador nunca va a estar por debajo de 0.

¿Por qué un contador debe estar unsigned ? El hecho de que no pueda volverse negativo no es una excusa válida en absoluto dado el significado real actual de unsigned para el idioma.

unsigned para C ++ no significa un "número entero que no puede ser negativo". Para entender por qué esta definición simplemente no tiene sentido, considera que

• La diferencia de dos unsigned es unsigned
• La adición de un unsigned con un signed es unsigned
• Un valor unsigned nunca es mayor que -1

Ninguna de las opciones anteriores tiene sentido si considera que unsigned está unsigned significa "no negativo".

El uso de unsigned para size_t fue un error (ver, por ejemplo, ¿Por qué size_t unsigned? ), Solo parcialmente * excusable porque en la era de 16 bits se consideró que un bit adicional valía la semántica incorrecta que los tipos unsigned tienen en C ++ para este tipo de uso.

Desafortunadamente, ahora el error size_t no se puede arreglar (debido a la compatibilidad con versiones anteriores) pero ¿por qué repetir el mismo error en otra área no relacionada?

Tenga en cuenta que probablemente el gran error que cometió fue simplemente la elección del nombre unsigned (dado su significado real). Si ese tipo hubiera sido nombrado (más apropiadamente) modulo entonces probablemente sería más evidente por qué el uso de un modulo int para el tamaño de una cadena no tiene ningún sentido.

El nombre es irrelevante, lo que cuenta es que semántico y unsigned simplemente tiene la semántica incorrecta para un contador o un tamaño.

(*) Personalmente, no creo que haya sido una razón suficientemente buena ni siquiera en ese entonces. Si 32767 no es suficiente para un tamaño ahora, entonces 65535 no será suficiente muy pronto. Solo un bit (el doble del valor) no era, en mi opinión, un precio aceptable para semejante flexión de la semántica.

EDITAR

He publicado un video en el que discuto con más detalle por qué creo que usar y unsigned type para size_t fue un error de diseño en C ++.

Las diapositivas se pueden descargar desde http://raksy.dyndns.org/unsigned.pdf

Answer 2

Segun esta pagina

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html

El tipo de retorno de use_count está firmado para evitar errores como p.use_count ()> -1 evaluando a falso.

con una referencia a

John Lakos, Diseño de software C ++ a gran escala, sección 9.2.2, página 637, Addison-Wesley, julio de 1996, ISBN 0-201-63362-0.

Básicamente, parece una decisión de grado de niñera, diseñada para desarrolladores de software de primer año.