Newsgroup: it.comp.lang.c++
Titolo: Operatore di assegnamento e classe derivate

L'operatore di assegnamento non viene ereditato, no? (tra l'altro, mi pare
che, se non ne viene creato esplicitamente uno, venga creato
automaticamente, almeno quello per copia, no').Quindi se lo ridefinisco in
una classe derivata, quando uso come operando un riferimento alla classe
base, quale viene chiamato? Se dichiaro nella funzine base l'operatore come
virtual non cambia molto, dato che non è ereditato, no?
Inoltre, nella derivata, che parametri può accettare? Oltre ad un oggetto
dello stesso tipo, gli posso fare accettare anche un ogetto della classe
base, etc..?
--
Marco Iannaccone     
marc...@tin.it
ICQ: 18748121           Tolkien
"I've... seen things you people wouldn't believe. Attack ships on fire off
the shoulder of Orion.
I watched C-beams... glitter in the dark near the Tanhauser Gate. All
those... moments will be lost... in time..., like... tears... in... rain."
FAQ it.comp.lang.c: 
http://www.programmazione.it/linguaggi/c/itcomplangc.htm
FAQ it.comp.lang.c++: 
http://www.programmazione.it/linguaggi/c/lang_faq.htm

base, etc..?
-------------------------------------------
  Paolo Marotta
 
http://web.tiscalinet.it/paolo_marotta/
-------------------------------------------

 T& T::operator=(const T&)     // forse il const non c'e`.
Normalmente c'č. E io lo metterei anche nel tipo restituito. O no?
EMG

 ha scritto nel
messaggio news:39C88534...@flashnet.it...

Libero di farlo, ma considera questo esempio
(un poco 'esotico' ma č il primo che mi č venuto
 in mente)
class foo
{
  private:
    int i;
  public:
    foo(int ii = 0)
    : i(ii) {  }
    const foo& operator=(const foo& f)
    {
      i = f.i;
      return *this;
    }
};
int main()
{
  {
    foo x;
    ( x = foo(77) ) = foo(88);
  }
  {
    int x;
    ( x = int(7) ) = int(88);
  }
}
Manlio Perillo

Se non erro, la tua e` la stessa motivazione che fornisce
Scott Meyers quando consiglia di ritornare un T& e non un
const T&. Scott Meyers afferma che e` anche vero che fino ad
ora non ha mai trovato un caso reale in cui la cosa sia necessaria.
Onestamente io non vedo situazioni reali in cui la cosa sia
plausibile e preferisco ritornare un const T&.
Consideratelo un approccio conservativo (e restrittivo) per avvisare
l'utente che se fa qualcosa di strano sono cavoli suoi!
Paolo



Il C++ cerca di rendere i tipi user-defined il più
possibile simili ai built-in.
Per questo ho riportato anche l'esempio con un intero.
Se con int funziona, dovrebbe funzionare anche con una mia classe.
Manlio Perillo


Il C++ cerca di rendere i tipi user-defined il più


 Manlio Perillo
Andrea
--
----------------------------------------------------------------
 <\___/>  Andrea        email: agriff at tin dot it
 / . . \  "6502"          irc: _6502_@EFNET#italia
(  (")  ) Griffini   homepage: 
http://www.netservers.com/~agriff
Sent via Deja.com 
http://www.deja.com/
Before you buy.

Dove lo dice?
In "Effective C++" edito da addison wesley


                                 // i1, then i3 to i1!
Ho letto questa stessa istruzione giusto ieri citata come esempio
di lampante "undefined behaviour". La condanna deriva dal fatto che
sono vietate scritture multiple su uno stesso dato elementare senza
che nel frattempo sia intervenuto un sequence point.
Sotto questa luce anche istruzioni come a=a=0; non sono semplicemente
inutili ma sono fonte di problemi potenziali seri.
Un esempio famoso che conoscevo come semplice "giochino" e che
questa interpretazione dichiara invece illegale e' il seguente:
   a^=b^=a^=b;
che e' conosciuto come un modo di scambiare due variabili intere
senza usare variabili di appoggio (una contorsione assolutamente
inefficiente e inutile, ma simpatica).
Gli stessi limiti sono, a quanto ho capito, presenti anche nel C.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

senza usare variabili di appoggio
Tecnica, tra l'altro, non portabile, visto che su alcune piattaforme
non viene eseguito lo scambio correttamente.
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

 di lampante "undefined behaviour".
Quindi, alla fine, avevo ragione io che conviene mettere const il valore
restituito dall'assignment operator oppure no?
EMG

restituito dall'assignment operator oppure no?
Secondo me non conviene.
Almeno non mi sembra corretto, se il risultato dell'operazione puo'
essere ancora un lvalue.


 essere ancora un lvalue.
D'accordo, ma se poi i costrutti cosě ottenuti (senza alcuna
segnalazione) ricadono nell'"undefined behavior" allora cosa conviene
fare? Come programmazione difensiva almeno non sarebbe bene metterci il
const?
EMG

inefficiente e inutile, ma simpatica).
basterebbe un
a^=b;
b^=a;
a^=b;
xche' e' inefficente ed inutile ? Se devi usare dei registri di
microprocessore la cosa puo' essere molto efficente e molto utile

fare? 
Be', ma mica e' cosi' meccanico.
Se ci si mette nelle condizioni di "undefined behaviour", non e' colpa
della struttura dati, e' colpa del programmatore ;)


const?
Il problema dell'undefined behaviour riguarda solo i tipi nativi.
Con un tipo utente infatti l'espressione
   (a=b)=c;
viene tradotta in
   (a.operator=(b)).operator=(c);
che non ha nessun problema relativo ai sequence point.
Certamente e' vero che la regola "fare nelle tue classi quello
che fanno gli int" non e' applicabile in questo caso (fra le
altre cose si tratta di un errore gia' presente nelle "errata"
di "Effective C++ CD"; per mia pigrizia non avevo verificato).
Io non trovo nessun vincolo filosofico al fatto che il valore
di ritorno di una assegnazione possa essere nuovamente assegnato
e per questa ragione restituisco un non-const reference.


microprocessore la cosa puo' essere molto efficente e molto utile
Ribadisco : NON e' una tecnica portabile, esistono sistemi in cui
queste operazioni non danno dei risultati corretti.


queste operazioni non danno dei risultati corretti.
Discutevo dell'efficenza e dell'utilita' ...
e poi dove NON sarebbe portabile ? Lo xor NON dovrebbe soffrire del problema
signed/unsigned ?

e per questa ragione restituisco un non-const reference.
Vero, ma onestamente preferisco un approccio piu` difensivo.


signed/unsigned ?
Questo in effetti me lo domando anche io... per quello
che ne so (se si separano le tre assegnazioni) la cosa
dovrebbe funzionare se le due variabili sono dello stesso
tipo intero.
In ogni caso a me sembra solo un simpatico giochino senza
alcuna utilita' reale.


>microprocessore la cosa puo' essere molto efficente e molto utile
Proprio la famiglia x86 ha problemi sul numero di registri e quindi a volte
per scambiare tra loro due registri piuttiosto che appogiarsi alla memoria (
o ad un terzo registro ) conviene il triplo xor...
Certo concordo che queste sono piu' tecniche da assembler, o da
programmatori di compilatori, che da C++...

programmatori di compilatori, che da C++...
Meglio lasciare cadere questa discussione sempre piu' offtopic.
Se qualcuno che scrive compilatori ti sente dire che il triplo xor
e' un sistema furbo di fare gli swap su x86 ti viene a cercare a
casa armato di randello :)))
Mi incuriosisce una cosa... e' qualcosa che hai pensato da solo o
qualcuno ti ha depistato ?


>signed/unsigned ?
Consulta le faq di comp.lang.c.
