🚀 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.