2010-06-21 30 views
14

Estoy intentando algo como esto:¿Pueden los operadores de asignación de C++ ser funciones gratuitas?

Foo & operator=(Foo & to, const Bar &from); 

Pero estoy recibiendo este error:

E2239 'operator =(Foo &, const Bar &)' must be a member function 

¿Existen limitaciones en la que los operadores pueden/no pueden ser definidas como funciones gratuitos, y si es así , ¿por qué?

Respuesta

22

El operador de asignación debe ser una función miembro no estática y debe tener exactamente un parámetro:

An assignment operator shall be implemented by a non-static member function with exactly one parameter (C++03 13.5.3/1).

operator(), operator[], y operator-> también debe implementarse como funciones miembro no estáticos.

Clase específica operator new y operator delete (y sus variantes) deben ser implementadas como métodos estáticos (tenga en cuenta que estos son implícitamente estáticos, incluso si no se declaran con la palabra clave static).

+2

¿Alguna otra razón para hacerlo? Tiene sentido para el operador = ser una función miembro, después de todo, es una de las 'tres 'funciones de control de copia (concretamente copy constructor, operator = y destructor). Pero, ¿por qué para otros? – zoujyjs

+1

@zoujyjs los operadores deben tener acceso a las variables miembro internas (posiblemente privadas). Las funciones gratuitas no tendrán dicho acceso. – iheanyi

+0

@iheanyi Pero podemos definir la función libre como un amigo de la clase –

-1

No puede.

La razón, creo, tiene que ver con el constructor de copias. Tienen una semántica muy similar, y no se puede definir un constructor de copia fuera de una clase como otro constructor. Entonces, no querían separar a los gemelos muy separados (para evitar la paradoja de los gemelos :).

P.S. Lo que es una pena en C++, es que no se puede agregar un miembro a la clase existente. No hay una razón de bajo nivel para eso. Si fuera posible, podría desacoplar dependencias de encabezado y cpp al no declarar funciones privadas en el encabezado de definición de clase.

+5

Si lo que está diciendo es agregar miembros después de que se complete la definición de la clase, ciertamente hay razones para eso. No puede agregar miembros virtuales más adelante porque para cuando la definición de la clase esté completa, el compilador DEBE saber qué tan grande es el objeto (¡incluido vtable!). Agregar miembros no virtuales fuera de la definición de clase haría que 'privado' no tenga sentido porque cualquiera podría agregar miembros que examinaron/modificaron datos privados. En el contexto de C++ como un todo, rompería gran parte de lo que estaban tratando de lograr. –

+0

Bueno, primero podría ser bueno para agregar miembros públicos. Segundo, más importante aún, solo requeriría un "amigo" o algún tipo de declaración directa en la definición de la clase, lo que ayudaría a desacoplar las dependencias. –

+0

No sigo su punto acerca de la 'vergüenza' en C++. Si realmente quiere 'agregar' algo a una clase existente, ¿por qué no simplemente crear una subclase? En cambio, si lo que pretendía es 'modificar' la clase original después de haber sido implementada por completo, no creo que esa sea la forma en que funciona C++. – Diaz

Cuestiones relacionadas