c++ - ¿Cuándo usar addressof(x) en lugar de & x?
(5)
¿Cómo decido si necesito addressof(x) lugar de &x cuando tomo la dirección de un objeto?
Parece que la pregunta era confusa, así que una aclaración es necesaria:
addressof obviamente pasa por alto la dirección sobrecargada del operador. Ya estoy al tanto de eso.
Lo que quiero saber es:
¿Cómo puedo saber si eso es lo que realmente quiero hacer? (Especialmente cuando dentro de una plantilla, etc.)
¿Hay algún tipo de "regla" que me ayude a determinar cuándo necesito una addressof lugar de & ?
Después de todo, ambos devuelven la "dirección de" el objeto, así que, ¿cuándo uso cuál?
Después de todo, ambos devuelven la "dirección de" el objeto, así que, ¿cuándo uso cuál?
No tiene absolutamente ninguna garantía de que haya un operator& sobrecargado operator& es la "dirección de" el objeto, es probable que no lo sea, o el autor de la clase probablemente no se habría molestado en sobrecargarlo. Podrían haberlo sobrecargado para devolver un tipo diferente, o incluso para devolver el void si están tratando de evitar que las personas tomen su dirección.
Si desea un puntero a un objeto que podría haberse sobrecargado & (por ejemplo, porque su tipo es un parámetro de plantilla, por lo que no sabe), use std::addressof o el documento que su plantilla no admite tipos que no devuelve la dirección real del objeto como el tipo correcto.
Úselo cuando desee saber la dirección real del objeto y no el resultado de una dirección de sobrecarga operator& de un operator& .
Si es un tipo definido por el usuario con un operator& unario sobrecargado y desea su dirección, use addressof .
Yo diría que siempre debe usar & porque, como usted dice, si no lo hace, anula el propósito de la sobrecarga. Por supuesto, a menos que haga algo significativo con la sobrecarga, en cuyo caso necesitaría una addressof (fuera de la clase, dentro de usted solo puede usar this ), pero tiene que estar muy seguro de lo que está haciendo.
Aquí hay más: si desea sobrecargar al operator& fuera de la clase (puede), tiene que usar addressof para devolver la dirección, de lo contrario, se addressof una recursión infinita:
struct Class
{
virtual ~Class() {}
int x;
};
void* operator&(const Class& x)
{
//return &x; <---- infinite recursion
return addressof(x) + 4; //I know this isn''t safe
//but I also know the intrinsics of my compiler
//and platform to know this will actually return
//the address to the first data member
}
Sé que esto no es seguro.
Solo mi opinión:
A menos que seas parte del equipo que diseña la clase y su interfaz, nunca. Personalmente nunca he visto una buena razón para sobrecargar a ese operador. Pero si alguien diseña una clase en la que tenga sentido, y suponiendo que la clase está destinada al consumo público (es decir, la clase no es para uso interno solo en una biblioteca en particular), esperaré que la clase funcione en código normal. que naturalmente espera que & significa "dirección de". Si la clase que sobrecarga al operador no está diseñada de una manera tan sensata, entonces no usaría esa clase, punto. Debido a que o esa clase está rota o no está destinada a ser utilizada fuera de la biblioteca de la que forma parte.
Usted usa std::addressof cuando tiene que hacerlo. Lamentablemente, "cuando tienes que" incluye cada vez que trabajas en un código de plantilla y quieres convertir una variable de tipo desconocido T o T& en un puntero honesto a Dios para la memoria de esa variable.
Debido a que el comité de C ++ permitió tontamente la sobrecarga del operador de referencia (con un propósito poco legítimo), es posible que un usuario cree una instancia de su plantilla con algún tipo de código para el que no puede usar el operador de referencia para obtener un indicador real. std::addressof es una forma de evitar a los usuarios que usan esta característica dudosa de C ++ para hacer lo que el idioma debería garantizar para trabajar.
En resumen, es una solución de biblioteca para una estupidez de lenguaje. Úselo en el código de plantilla en lugar de & si desea asegurarse de que los usuarios no puedan romper su código. Si se puede confiar en que sus usuarios no usen esta característica il-concebida, entonces puede usar & .