Fehler nach Compiler-Update

Ramanujan

Ich hab MinGW geupdatet, allderdings lässt sich mein Projekt jetzt nicht mehr kompilieren. Es kommt (u.a.) folgender Fehler:

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?

Belli

const - Membervariablen können nicht mutable sein.

Ramanujan

Kann ich das mutable einfach entfernen oder riskiere ich, dass irgendetwas nicht mehr läuft?

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>

Sone

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

Belli schrieb:

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.

Zwar ist die Kombination von mutable und const durchaus eine alberne, aber konkret geht es hier darum, dass mutable und Referenzen nicht zusammengehen, weil mutable dort schlicht nicht notwendig ist -- die Referenz selbst ist eh nicht änderbar, und das, was es referenziert, ist vom cv-Qualifier des umgebenden Objektes nicht betroffen. Das überrascht manche, aber

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

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

ist erlaubt.

Ramanujan

Das bedeutet das keyword mutable überhaupt?

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

Edit:
Ok, mein Programm läuft wieder.

Sone

Ramanujan schrieb:

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?

Ramanujan

Ich hab es noch nicht genau verstanden:

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

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

Sone

Ramanujan schrieb:

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.

Mr X

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

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.

Sone

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

Sone schrieb:

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.

Sone

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.

Mr X

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.

Mr X

Sone schrieb:

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

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.

Mr X

Sone schrieb:

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.

Sone

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

Mr X schrieb:

Genau. Dann passt deine Bemerkung von oben ja auch.

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