g++ -O1 -g3 -Wall -c -fmessage-length=0 -o src\matrix.o ..\src\matrix.cpp
In file included from ..\src\include/cpplapack.h:179:0,
from ..\src\matrix.h:18,
from ..\src\matrix.cpp:10:
..\src\include/_dsymatrix-/_dsymatrix.hpp:9:23: Fehler: Referenz »m« kann nicht als »mutable« deklariert sein [-fpermissive]

Folgende Code-Zeile ist Schuld:

mutable long const& m; //!< matrix row size

Ich möchte anmerken, dass _dsymatrix.hpp Teil einer benutzen Bilbiothek und nicht von mir ist. Von daher bin ich recht verwundert, warum sich das Programm nicht mehr kompilieren lässt. Hat irgendwer Lösungsvorschläge?

Edit:
Es gibt noch weitere Fehler und zwar der Art:

..\src\matrix.cpp:559:26: Fehler: es gibt keine Argumente für »clock«, die von einem Templateparameter abhängen, weshalb eine Deklaration von »clock« verfügbar sein muss [-fpermissive]

In jener Zeile steht folgendes:

timeMultiply_t0 = clock();

Inkudiert hab ich in jener Datei folgendes:

#include <math.h>
#include <cstdlib>
#include <iostream>
#include <stdlib.h>
#include <fstream>

const - Membervariablen können nicht mutable sein.

Das Problem ist die Referenz, nicht das const. Das

struct a
{
        mutable int& i;
        a(int&i):i(i){}
};

liefert den gleichen Fehler.

struct A {
  A(int &x) : x(x) { }
  int &x;
};

int main() {
  int n = 1;
  A const a(n);
  a.x = 2;
}

ist erlaubt.

Den Fehler mit clock() hab ich gefunden:
ich musste noch <time.h> inkludieren

Edit:
Ok, mein Programm läuft wieder.

Das bedeutet das keyword mutable überhaupt?

Das hab ich erklärt.
Übrigens lieber <ctime> enbinden. Ok?

@seldon: Mich überrascht das kein bisschen. Was ist daran merkwürdig?

Was bedeutet "cv-qualifiziert"?
Was ist der Unterschied zwischen logischer und physikalischer constness?

[Hab es jetzt mit ctime statt time.h gemacht]

Was bedeutet "cv-qualifiziert"?

Tut mir Leid.
Also, diese Funktion ist cv-qualifiziert:

class foo
{
    void bar() const {} //Kennste doch, oder?
};

Ramanujan schrieb:

Was ist der Unterschied zwischen logischer und physikalischer constness?

Ein Objekt ist physikalisch const, wenn sein Speicher komplett geschützt ist.
Ein Objekt ist nur logisch const, wenn es zwar logisch gesehen nach dem Aufruf einer Funktion immer noch gleich ist, sein Speicher aber evt. verändert wurde.

mutable ist dazu da, die physikalische constness auszuheben und daraus eine logische constness zu machen - so, dass selbst in cv-qualifizierten Membermethoden mutable Member verändert werden können. Diese Member sind aber nach aussen hin const.

Das heißt, dass auch in konstanten Methoden diese Member verändert werden können. Mit dem Unterschied von logischer und physischer Constness würde ich das jetzt nicht in Verbindung bringen. [EDIT: Ok, das passt schon. Hatte da eine andere Definition von physischer Constness im Kopf, nämlich die tatsächliche Unmöglichkeit der Veränderung des Wertes (Read-Only-Speicher, z.B.)]

Sone schrieb:

mutable ist dazu da, die physikalische constness auszuheben und daraus eine logische constness zu machen - so, dass selbst in cv-qualifizierten Membermethoden mutable Member verändert werden können.

Das heißt, dass auch in konstanten Methoden diese Member verändert werden können. Mit dem Unterschied von logischer und physikalischer Constness würde ich das jetzt nicht in Verbindung bringen.

Findest du? Find ich nicht.

HIer wieso:

Wenn es keine mutable Member gibt, ist der Speicher der Klasse ja geschützt, damit ist das Object physikalisch const. Wenn es mutable Member gibt, existiert theoretisch nur noch die logische constness- der speicher kann teilweise auch für const-Objekte verändert werden.

Hatte da eine andere Definition von physischer Constness im Kopf, nämlich die tatsächliche Unmöglichkeit der Veränderung des Wertes (Read-Only-Speicher, z.B.)

Und das ist die meinige
P.S.: Das mit den Funktionen ist soweit ich sehe quatsch. Ich hab da selbst was durcheinander gebracht.
Die Funktion ist halt logisch const, wenn sie (wie ich sagte) nur den logischen Wert des Objektes nicht verändert, jedoch den physikalischen.
Eine Funktion ist dagegen physikalisch const, wenn sie das Objekt gar nicht verändert.

Mr X schrieb:

Sone schrieb:

mutable ist dazu da, die physikalische constness auszuheben und daraus eine logische constness zu machen - so, dass selbst in cv-qualifizierten Membermethoden mutable Member verändert werden können.

Das heißt, dass auch in konstanten Methoden diese Member verändert werden können. Mit dem Unterschied von logischer und physikalischer Constness würde ich das jetzt nicht in Verbindung bringen.

Findest du? Find ich nicht.

HIer wieso:

Wenn es keine mutable Member gibt, ist der Speicher der Klasse ja geschützt, damit ist das Object physikalisch const. Wenn es mutable Member gibt, existiert theoretisch nur noch die logische constness- der speicher kann teilweise auch für const-Objekte verändert werden.

Während Du das geschrieben hast, habe ich da noch eine Anmerkung in meinen Beitrag hineineditiert. Hatte eine andere Definition von phyischer/logischer Konstanz im Kopf. Allerdings muss man bei deiner Definition eines bedenken: Es ist möglich, den Speicherinhalt (wenn auch nur mit üblen Hacks) zu verändern, selbst wenn das Objekt physisch Konstant ist.

Allerdings muss man bei deiner Definition eines bedenken: Es ist möglich, den Speicherinhalt (wenn auch nur mit üblen Hacks) zu verändern, selbst wenn das Objekt physisch Konstant ist.

Das wusste ich nicht. Erzähl.

Hatte da eine andere Definition von physischer Constness im Kopf, nämlich die tatsächliche Unmöglichkeit der Veränderung des Wertes (Read-Only-Speicher, z.B.)

Und das ist die meinige
P.S.: Das mit den Funktionen ist soweit ich sehe quatsch. Ich hab da selbst was durcheinander gebracht.
Die Funktion ist halt logisch const, wenn sie (wie ich sagte) nur den logischen Wert des Objektes nicht verändert, jedoch den physikalischen.
Eine Funktion ist dagegen physikalisch const, wenn sie das Objekt gar nicht verändert.

Nun, ich dachte eher, du definierst es so:
physische Konstanz: Der Speicherinhalt bleibt unverändert.
logische Konstanz: Das Objekt "sieht" von außen gleich aus.

Mr X schrieb:

Allerdings muss man bei deiner Definition eines bedenken: Es ist möglich, den Speicherinhalt (wenn auch nur mit üblen Hacks) zu verändern, selbst wenn das Objekt physisch Konstant ist.

Das wusste ich nicht. Erzähl.

Ohne es getestet zu haben:

const int i = 5;
int* p = (int*)&i;
*p = 6;
std::cout << i;

Das _kann_ ein Exception auslösen, muss es aber nicht. Hängt vom Compiler/Laufzeitumgebung ab. Es kann auch 6 rauskommen.

Das gleiche kannst Du auch in cv-Methoden tun, indem du den this-Zeiger castest. Das dabei eine Ausnahme geworfen wird, halte ich übrigens für eher unwahrscheinlich.

Sone schrieb:

Hatte da eine andere Definition von physischer Constness im Kopf, nämlich die tatsächliche Unmöglichkeit der Veränderung des Wertes (Read-Only-Speicher, z.B.)

Und das ist die meinige
P.S.: Das mit den Funktionen ist soweit ich sehe quatsch. Ich hab da selbst was durcheinander gebracht.
Die Funktion ist halt logisch const, wenn sie (wie ich sagte) nur den logischen Wert des Objektes nicht verändert, jedoch den physikalischen.
Eine Funktion ist dagegen physikalisch const, wenn sie das Objekt gar nicht verändert.

Nun, ich dachte eher, du definierst es so:
physische Konstanz: Der Speicherinhalt bleibt unverändert.
logische Konstanz: Das Objekt "sieht" von außen gleich aus.

Ja, so definiere ich es. Für Objekte. Für Funktionen wie oben.

Mr X schrieb:

Sone schrieb:

Hatte da eine andere Definition von physischer Constness im Kopf, nämlich die tatsächliche Unmöglichkeit der Veränderung des Wertes (Read-Only-Speicher, z.B.)

Und das ist die meinige
P.S.: Das mit den Funktionen ist soweit ich sehe quatsch. Ich hab da selbst was durcheinander gebracht.
Die Funktion ist halt logisch const, wenn sie (wie ich sagte) nur den logischen Wert des Objektes nicht verändert, jedoch den physikalischen.
Eine Funktion ist dagegen physikalisch const, wenn sie das Objekt gar nicht verändert.

Nun, ich dachte eher, du definierst es so:
physische Konstanz: Der Speicherinhalt bleibt unverändert.
logische Konstanz: Das Objekt "sieht" von außen gleich aus.

Ja, so definiere ich es. Für Objekte. Für Funktionen wie oben.

Genau. Dann passt deine Bemerkung von oben ja auch.

const int i = 5;
int* p = (int*)&i;
*p = 6;
std::cout << i; //Ausgabe: 5

Dasselbe bei meinem Hack:

int const a(5);

        memset(const_cast<void*>(reinterpret_cast<void const*>(&a)), 0, sizeof (a));

        std::cout << a << '\n'; // 5

Mr X schrieb:

Genau. Dann passt deine Bemerkung von oben ja auch.

Puah, schön dass das jetzt endlich geklärt ist

Cool! Der GCC macht es irgendwie komisch, er ignoriert die Anweisung komplett:

const int i = 5;
int* p = (int*)&i;
*p = 6;
std::cout << i; //Ausgabe: 5

Dasselbe bei meinem Hack:

int const a(5);

        memset(const_cast<void*>(reinterpret_cast<void const*>(&a)), 0, sizeof (a));

        std::cout << a << '\n'; // 5

Das sieht so aus, also hat er die Konstante wegoptimiert. Ich probiers mal selbst aus.

class FrameworkBla
{
        mutable size_t counter;

        FrameworkBla():
        counter(0) {}

        void eine_Logisch_Konstante_Funktion() const
        {
                ++counter;//Hier wird counter verändert, obwohl die Instanz ja const ist! Ohne mutable wird es also einen einfachen semantischen Fehler geben.
                ........
        }
};

Notiz an mich: Dringend meinen GCC updaten.

#include <iostream>

struct C {
	int i;
	C() : i(5) {}
	void foo() const {
		C* c = (C*)this;
		c->i = 6;
	}
};

int main() {
	C c;
	c.foo();
	std::cout << c.i;
}

Nochmal um das klarzustellen: Auf keinen Fall benutzen! Das ist UB und sehr unelegant.