🚀 go-pugleaf

In article <4davqq$4ni@h20-hrze.uni-duisburg.de> sg102ne@e45-hrze.uni-duisburg.de (Nepomuck) writes:

   Bei Verwendung von Klassen mit "const"-Methoden bin ich auf ein Problem
   gestossen, fuer das ich derzeit keine Loesung habe:

   Angenommen, ich habe eine Klasse A definiert, welche einige
   "const"-Methoden zum Abfragen von bestimmten Eigenschaften definiert. 
   Anfaenglich sind mir diese Methoden schnell genug, aber nach einiger
   Zeit stelle ich fest, dass ich aus Effizienzgruenden mehrere
   Repraesentationen der internen Daten meiner Klasse A benoetige, und dass
   meine Klasse A beim Aufruf einer der Abfragefunktionen einen Repraesentations-
   wechsel der Daten vornehmen muss. Weil ich die Abfragefunktionen oft aufrufen
   moechte, moechte ich die neuen Repraesentation der Daten in A speichern.
   Dabei entsteht das Problem, dass die urspruenglichen "const"-Methoden
   ploetzlich nicht mehr "const" sein koennen, obwohl sich an ihrer
   Funktionalitaet eigentlich nichts aendert.

   Beispiel:

   Eine Klasse "complex" fuer komplexe Zahlen speichert zunaechst nur
   Real- und Imaginaerteil der Zahlen. Abgefragt werden sollen aber auch Polar-
   koordinaten (z.B. mittels zweier Methoden complex::Winkel() und
   complex::Betrag()). Normalerweise koennten diese Funktionen als "const"
   deklariert werden, aber ich moechte erreichen, dass die zeitaufwendige
   Umrechnung in Winkel und Betrag nur beim ersten Aufruf der zugehoerigen
   Funktionen geschieht. Das Problem dabei ist, dass die Funktionen jetzt nicht
   mehr als "const" deklariert werden koennen. Ich moechte allerdings auch
   nicht grundsaetzlich zu jeder komplexen Zahl Winkel und Betrag von
   vornherein schon im Konstruktor-Aufruf berechnen, weil es Programmteile geben
   kann, die die Funktionen "Winkel()" und "Betrag()" gar nicht aufrufen.

   Gibt es eine Moeglichkeit, dafuer zu sorgen, dass Winkel() und Betrag()
   trotzdem als "const" deklariert werden?  Ansonsten entsteht naemlich das
   Problem, dass in saemtlichen Klassen, die ein Objekt der Klasse
   "complex" als Member-Variable beinhalten und "Winkel()" oder "Betrag()"
   aufrufen, die aufrufenden Methoden ebenfalls nicht mehr als "const"
   deklariert werden koennen. 

Ja, Du kannst die entsprechende Member-Variable als 'mutable' deklarieren

---
#include <iostream.h>
#include <math.h>

#define MUTABLE 1

class Complex {
 public:
  Complex(double r,double i) : real_(r), imag_(i), valid_(false) {}

  double Betrag() const {
    if (!valid_) {
#ifdef MUTABLE
      betrag_=sqrt(real_*real_+imag_*imag_);
      valid_=true;
#else
      Complex* nc_this=(Complex*)this;
      nc_this->betrag_=sqrt(real_*real_+imag_*imag_);
      nc_this->valid_=true;
#endif
    }
    return betrag_;
  }

 private:
  double real_,imag_;
#ifdef MUTABLE
  mutable bool valid_;
  mutable double betrag_;
#else
  bool valid_;
  double betrag_;
#endif
};

int main()
{
  Complex c(1.1,2.3);
  double w=c.Betrag();
  w=c.Betrag();
}
---
Falls der Compiler dieses Feature noch nicht unterstuetzt, hilft nur (*)
die Holzhammermethode, d.h. den 'this' Pointer entsprechend zu casten.

        Enno

(*) Ich nehme dabei stillschweigend an, dass ein Compiler der 'mutable'
    nicht unterstuetzt auch keinen 'const_cast' Support hat.

enno@inferenzsysteme.informatik.th-darmstadt.de (Enno Sandner) wrote:
[Erläuterung von mutable]

>---
>Falls der Compiler dieses Feature noch nicht unterstuetzt, hilft nur (*)
>die Holzhammermethode, d.h. den 'this' Pointer entsprechend zu casten.

Es gibt auch noch den folgenden schmutzigen Trick:

class CLASS
{
public:
   CLASS()
     {me = this;}
   void SetData(int d) const
     {me->data=d;}
private:
   int   data;
   CLASS *me;
};

Joachim

"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden 
koennen."                       - Bertolt Brecht - Das Leben des Gallilei

sg102ne@e45-hrze.uni-duisburg.de (Nepomuck) writes:


>Bei Verwendung von Klassen mit "const"-Methoden bin ich auf ein Problem
>gestossen, fuer das ich derzeit keine Loesung habe:

>Angenommen, ich habe eine Klasse A definiert, welche einige
>"const"-Methoden zum Abfragen von bestimmten Eigenschaften definiert. 
>Anfaenglich sind mir diese Methoden schnell genug, aber nach einiger
>Zeit stelle ich fest, dass ich aus Effizienzgruenden mehrere
>Repraesentationen der internen Daten meiner Klasse A benoetige, und dass
>meine Klasse A beim Aufruf einer der Abfragefunktionen einen Repraesentations-
>wechsel der Daten vornehmen muss. Weil ich die Abfragefunktionen oft aufrufen
>moechte, moechte ich die neuen Repraesentation der Daten in A speichern.
>Dabei entsteht das Problem, dass die urspruenglichen "const"-Methoden
>ploetzlich nicht mehr "const" sein koennen, obwohl sich an ihrer
>Funktionalitaet eigentlich nichts aendert.

>Beispiel:

>Eine Klasse "complex" fuer komplexe Zahlen speichert zunaechst nur
>Real- und Imaginaerteil der Zahlen. Abgefragt werden sollen aber auch Polar-
>koordinaten (z.B. mittels zweier Methoden complex::Winkel() und
>complex::Betrag()). Normalerweise koennten diese Funktionen als "const"
>deklariert werden, aber ich moechte erreichen, dass die zeitaufwendige
>Umrechnung in Winkel und Betrag nur beim ersten Aufruf der zugehoerigen
>Funktionen geschieht. Das Problem dabei ist, dass die Funktionen jetzt nicht
>mehr als "const" deklariert werden koennen. Ich moechte allerdings auch
>nicht grundsaetzlich zu jeder komplexen Zahl Winkel und Betrag von
>vornherein schon im Konstruktor-Aufruf berechnen, weil es Programmteile geben
>kann, die die Funktionen "Winkel()" und "Betrag()" gar nicht aufrufen.

>Gibt es eine Moeglichkeit, dafuer zu sorgen, dass Winkel() und Betrag()
>trotzdem als "const" deklariert werden?  Ansonsten entsteht naemlich das
>Problem, dass in saemtlichen Klassen, die ein Objekt der Klasse
>"complex" als Member-Variable beinhalten und "Winkel()" oder "Betrag()"
>aufrufen, die aufrufenden Methoden ebenfalls nicht mehr als "const"
>deklariert werden koennen. 

>Vielen Dank fuer jede Hilfe,

>- Michael -
>sg102ne@e45-hrze.uni-dortmund.de

Kenne das Problem:
Einfach in den const-Methoden vom this-Zeiger das const 'wegcasten', dann mit
dem Resultat auf die Klassenelemente zugreifen. Beispiel:

double complex::Betrag() const
{
// 'this' ist hier vom Typ 'const complex *', also:
  ((complex *)this)->abs = hypot(real, imag);

// noch Winkel berechnen und evtl. Flag 'Betrag-Winkel vorhanden' setzen

  return abs;
}

Manche Compiler (z.B. Borland) stellen dafuer sogar eingebaute Operatoren
zur Verfuegung, Beispiel Borland: 'const_cast'.

Gruss,
Karsten
  
--
(  Email: Karsten.Baensch@hrz.tu-chemnitz.de                                ( 
 ) WWW:   http://www.tu-chemnitz.de/~kba/baensch.html                        )
(  Phone: (+49-) 0371/531-1252                                              ( 
 ) Mail:  Technical University, Computing Services, 09107 Chemnitz, Germany  )

sg102ne@e45-hrze.uni-duisburg.de (Nepomuck) wrote:

>Gibt es eine Moeglichkeit, dafuer zu sorgen, dass Winkel() und Betrag()
>trotzdem als "const" deklariert werden?  Ansonsten entsteht naemlich das
>Problem, dass in saemtlichen Klassen, die ein Objekt der Klasse
>"complex" als Member-Variable beinhalten und "Winkel()" oder "Betrag()"
>aufrufen, die aufrufenden Methoden ebenfalls nicht mehr als "const"
>deklariert werden koennen. 
>
>Vielen Dank fuer jede Hilfe,
>
>- Michael -
>sg102ne@e45-hrze.uni-dortmund.de
>
>
>
>

Eine gute Moeglichkeit waere, anstatt des Bool-Wertes, den Winkel und Betrag 
zu speichern. Das kostet zwar Speicherplatz, und die beiden Werte muessen 
immer mitaktualisiert werden, aber u.U. kann das immer noch die beste 
Loesung sein. In jedem Fall rate ich aber von Precompiler-Einsatz ab 
(#ifdef oder Makros).

mfG


-- 



  ___                                 o   o
 <o-o>                                 \!/                             #8-)
 (`-')                               0(o o)0 
+-"-"----------------------------oo0O--(_)--O0oo--------------------------+
! Andrzej Trembilski                            Diese Nachricht besteht   !
! (06151) 155  -101 -163                        zu 100% aus chlorfrei     !
! trembils@igd.fhg.de             .oo0O         gebleichten, recyclebaren,!
! http://www.igd.fhg.de/~trembils {   }   O0oo. gluecklichen Elektronen.  !
+----------------------------------\ (----{   }---------------------------+
                                    \_)    ) /
                                          (_/