🚀 go-pugleaf

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