Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 355 — #393
✐
12.4. Operadores no miembros
precedencia, y otra parte es la falta de necesidad a costa del problema inherente.
5. No puede cambiar las reglas de precedencia. Son lo suficientemente difíciles
de recordar como son sin dejar a la gente jugar con ellas.
12.4. Operadores no miembros
En algunos de los ejemplos anteriores, los operadores pueden ser miembros o no,
y no parece haber mucha diferencia. Esto normalmente provoca la pregunta, «¿Cuál
debería elegir». En general, si no hay ninguna diferencia deberían ser miembros,
para enfatizar la asociación entre el operador y su clase. Cuando el operando de la
izquierda es siempre un objeto de la clase actual funciona bien.
Sin embargo, a veces querrá que el operando de la izquierda sea un objeto de
alguna otra clase. Un caso típico en el que ocurre eso es cuando se sobrecargan los
operadores > para los flujos de entrada/salida. Dado que estos flujos son una
librería fundamental en C++, probablemente querrá sobrecargar estos operadores
para la mayoría de sus clases, por eso el proceso es digno de tratarse:
//: C12:IostreamOperatorOverloading.cpp
// Example of non-member overloaded operators
#include "../require.h"
#include
#include // "String streams"
#include
using namespace std;
class IntArray {
enum { sz = 5 };
int i[sz];
public:
IntArray() { memset(i, 0, sz* sizeof(*i)); }
int& operator[](int x) {
require(x >= 0 && x < sz,
"IntArray::operator[] out of range");
return i[x];
}
friend ostream&
operator(istream& is, IntArray& ia);
};
ostream&
operator