feld1[0] = 17.0;
feld1[2] = 5 * feld1[0] * feld[1]+3.0;

möglich sein.

Die double-Daten sollen binär nacheinander in einer Datei liegen, der dateiname wird vom konstruktor eingelesen

Dazu muss ich die Operatoren [] und = passend überladen, mit den Befehlen read, write, e.t.c.

ich habe schon einiges probiert, aber bin mir zum beispiel nicht sicher über die Rückgabewerte der Operatoren...

alles etwas wirr, vielleicht hat hier jemand ja schon sowas gemacht, hier noch etwas code:

[cpp]
class persFeld {

private:
	int n;
	double zahl;
	int index;
	fstream ausgabe;
public:
		persFeld(string Datei);
	void setzElement(int i,double x);
	void erweiterFeld(int i);
	persFeld operator[](int i);
	void operator=(double x);
};

persFeld persFeld::operator[](int i){
	ausgabe.seekg(0);
	ausgabe.read((char*)&zahl,sizeof(double));
	cout << "index: " << i;
	index=i; 
}

void persFeld::operator=(double x){
	setzElement(index,x);
}

persFeld::persFeld(string Dateiname){
	fstream hilf(Dateiname.c_str(),ios::out|ios::app); 
	hilf.close();
 	ausgabe.open(Dateiname.c_str(),ios::out|ios::in);
	n=0;

}

void persFeld::setzElement(int i, double x){
	ausgabe.seekp(i*8);
	ausgabe.write((char*)&x,sizeof(double));
}
[/cpp]

Vielleicht kennt sich hier ja jemand super aus mit Operatorenüberladung und Dateioperationen, damit die zuweisungen von oben klappen...

Danke!!

Zum einen mußt du beim operator [] unterscheiden, ob du lesend oder schreibend darauf zugreifst.

// lesen, daher konstant
double operator[](int i) const;

// schreiben
Proxy operator[](int i);

Du solltest als Rückgabewert für den nicht-konstanten Operator eine sogenannte Proxy-Klasse erzeugen, welche nur dazu dient, den operator = anzubieten.
(Verwende möglichst nicht die selbe Klasse dafür, das ergibt nur ein unnötiges Durcheinander...)
Versuche ersteinmal den lesenden Zugriff hinzukriegen und danach fängst du dann mit der Proxyklasse an. Ich hoffe, du weiß schon was Referenzen sind (und wie man diese sinnvoll einsetzt), denn für den Konstruktor der Proxy-Klasse benötigst du diese...

Und zum anderen mußt du den Zugriff auf die Datei auch einheitlich gestalten bzgl. seekg(i * sizeof(double)) ...

also ich bin auch kein König dadrin, aber ich würde mal die erwarteten "Semantiken" durchgehen: Wie soll der Anwender die operatoren verwenden können ? Und was soll dabei passieren ?

Dann wird vielleicht klarer, wo welche Typen, wo Referenzen und wo Kopien erwartet werden.
Z.B.:

// 1
arr[2] = arr[4] = 4.56;
// 2
double &rd = arr[3];
rd += 1.23;

Außerdem mußt Du Dir ggf. überlegen, wann "persistiert" wird. So kannst Du sowas wie mit der double& eigentlich nur "im Speicher" machen ... aber "irgendwann" muss das Zeug ja auch wieder in die Datei.

Gruß,

Simon2.

class persFeld {
// ...
    class Proxy;
    Proxy operator[](int i);
// ...
};

Damit wir diesen Proxy dort einsetzen können, wo ein double erwartet wird, brauchen wir einen Konvertierungsoperator nach double. Zusätzlich soll die Zuweisung eines double möglich sein. Das realisieren wir mit einem entsprechenden Zuweisungsoperator. Schwierigkeiten ergeben sich dort, wo ein modifizierbares double-Objekt erwartet wird - im einfachsten Falle, wenn wir += -= *= usw. verwenden wollten. Diese Operatoren können wir geeignet überladen. Bei Funktionen, die einen entsprechenden Parameter erwarten, versagt diese Methode allerdings. Abhelfen könnte hier ein Konvertierungsoperator nach double& - das Problem dabei ist, dass wir dann Schreibzugriffe nicht verfolgen können. Man könnte diese Schreibzugriffe im Destruktor auswerten, nur ändert sich dann die Semantik von Ausdrücken möglicherweise in unerwarteter Weise, weil Seiteneffekte erst bei Ende der Auswertung eines Ausdrucks (wenn der Destruktor des Proxies ausgeführt wird) auftreten und nicht an jedem Sequenzpunkt des Ausdrucks. Diese Möglichkeit soll hier nicht weiter verfolgt werden.
Zusätzlich müssen wir uns Gedanken über die Kopiersemantik von Proxies machen. Da er als Rückgabewert einer Funktion (wenigstens des []-Operators) auftreten kann, brauchen wir einen Copy-ctor, der sich logisch normal verhält. Schwieriger ist die Copy-Zuweisung. Haben wir

persFeld a(..);

Dann soll bei

a[i]=a[j];

natürlich der Wert an der Stelle j in der Stelle i gespeichert werden, und nicht etwa der Proxy auf der linken Seite umgebogen werden, um auf die Stelle j zu zeigen. Wir haben also einen Fall, bei dem Copy-Zuweisung und Copy-ctor völlig verschiedene Dinge machen - das muss nicht überraschen: Referenzen selbst sind ja auch nicht zuweisbar. Und so wie Referenzen kann man Proxies nicht in Standardcontainern speichern. Und zum Schluss stellt sich noch die Frage nach const.
Haben wir ein konstantes Feld, könnten wir versucht sein, beim Aufruf des []-Operators gleich den Wert auszulesen und ein double zurückzugeben. Das ist legitim, hat allerdings den unschönen Effekt, dass wir in diesem Fall nicht mehr zwischen dem Ort eines Datums (der durch ein Proxy repräsentiert wird) und dem Wert des Datums unterscheiden können. Haben wir einen normalen Container, kann es sinnvoll sein, Referenzen auf Elemente zu speichern und den Wert erst später zu ermitteln:

const vector<double>& v=...;
const double& x = v[ /* komplexer Ausdruck, den wir nicht ständig neu berechnen wollen */ ];
for ( /* ... */ )
{
   mach_was_mit_x(x);
   mach_was_mit_v(v); // der Inhalt von x ändert sich möglicherweise
}

Wollen wir etwas Derartiges mit unserem Feld machen, müssen wir den eigentlichen Lesevorgang entsprechend verzögern, also muss auch unser konstanter []-Operator einen Proxy zurückgeben. Man könnte versucht sein hierbei mit const Proxy zu spielen.

class persFeld {
// ...
    class Proxy {
// ...
        Proxy& operator=(double); // nur verwendbar, wenn nicht const
        operator double() const; // immer möglich
    };
    Proxy operator[](int);
    const Proxy operator[](int) const;
// ...
};

Das ist allerdings gefährlich, denn nichts hindert uns daran, den vom []-Operator zurückgegeben Proxy einfach noch einmal zu kopieren, und dann mit dieser Kopie zu arbeiten und den Wert doch noch zu verändern. Wir brauchen also eine zweite Klasse, die nur lesend aif den Wert zugreifen kann und unser normaler Proxy ist in diese konvertierbar. Der Vergleich mit Referenzen zeigt wiederum, dass diese Überlegung sinnvoll ist: ein Referenz auf ein konstantes T ist auch nicht einfach die konstante Version einer Referenz auf T - Referenzen selbst sind niemals cv-qualifiziert. Das führt zu der Überlegung, dass die const-Qualifikation eines Proxy-Objekts im Grunde bedeutungslos ist: folglich müssen alle Memberfunktionen (auch der Zuweisungsoperator!) const sein - der Proxy selber wird ja sowieso nicht verändert. Zusammenfasst:

class persFeld {
// ...
    class Proxy;
    class ConstProxy;
    Proxy operator[](int);
    ConstProxy operator[](int) const;
// ...
};

class persFeld::Proxy {
    Proxy(persFeld& f, int i) : feld_(f), index_(i) {}
public:
    // Copy-ctor vom Compiler
    Proxy& operator=(const Proxy& other) const { // const !!
        // um Duplizität zu vermeiden, gibt es nur eine Stelle, an der geschrieben wird (der andere Zuweisungsoperator)
        // und eine Stelle, an der gelesen wird (der Konvertierungsoperator des ConstProxies)
        // überall sonst benutzen wir diese Funktionen
        double v = other;
        return *this = v;
    }
    Proxy& operator=(double) const; // hier den Schreibvorgang implementieren (oder eine entsprechende Funktion von persFeld aufrufen)
    operator double() const;
    // Nach Bedarf noch ein paar Operatoren überladen:
    template<typename T>
    Proxy& operator+=(T rhs) const {
        double v = *this;
        return *this = ( v += rhs );
    }
    // usw.
private:
    persFeld& feld_; // normalerweise bin ich gegen Referenzen an dieser Stelle, hier sind sie mal sinnvoll
    int index_;
    friend class persFeld;
    friend class ConstProxy; // für die Konvertierung
};

class persFeld::ConstProxy {
    ConstProxy(const persFeld& f, int i) : feld_(f), index_(i) {}
public:
    ConstProxy(const Proxy& p) : feld_(p.feld_), index_(p.index_) {}
    // Copy-ctor vom Compiler
    // nicht zuweisbar, da Copy-Zuweisung vom Compiler wegen Referenzmember nicht definiert werden kann
public:
    operator double() const; // hier Lesevorgang implementieren (oder eine entsprechende Funktion von persFeld aufrufen)
private:
    friend class persFeld;
    const persFeld& feld_;
    int index_;
};
inline persFeld::Proxy::operator double() const {
    ConstProxy p( *this );
    return p;
}

inline persFeld::Proxy persFeld::operator[](int i) {
    return Proxy( *this, i );
}
inline persFeld::ConstProxy persFeld::operator[](int i) const {
    return ConstProxy( *this, i );
}

Da sich auch durch den Lesevorgang möglicherweise der innere Zustand des Feld-Objektes ändert, ist dies ein Fall, in dem mutable nützlich werden kann, um so mehr falls man das Ganze noch durch Caching aufwertet.

echt gut, dass ihr sofort auf ne Proxy-Klasse gekommen seid!!
jetzt werde ich mich mal dransetzen, das richtig zu verstehen ^^

auf jeden Fall danke auch camper, für die Mühe, jetzt kann ich mir das zusammenpuzzlen

class persFeld {
// ...
public:
    typedef int size_type;
private:    
    double read(size_type index) const;
    void write(size_type index, double value);
public:
    class reference {
        reference(persFeld& f, size_type i) : feld_( f ), index_( i ) {}
    public:
        void operator=(volatile reference&) volatile; // unterdrückt die Deklaration durch den Compiler, ist aber wegen seiner Signatur kein Kandidat bei der Überladungsauflösung
        reference& operator=(double value)             { feld_.write( index_, value ); return *this; }
        const reference& operator=(double value) const { feld_.write( index_, value ); return *this; }
        operator double() const { return feld_.read( index_ ); }
        template<typename T> reference& operator+=(const T& rhs) { return *this = *this + rhs; }
        template<typename T> reference& operator-=(const T& rhs) { return *this = *this - rhs; }
        template<typename T> reference& operator*=(const T& rhs) { return *this = *this * rhs; }
        template<typename T> reference& operator/=(const T& rhs) { return *this = *this / rhs; }
        template<typename T> const reference& operator+=(const T& rhs) const { return *this = *this + rhs; }
        template<typename T> const reference& operator-=(const T& rhs) const { return *this = *this - rhs; }
        template<typename T> const reference& operator*=(const T& rhs) const { return *this = *this * rhs; }
        template<typename T> const reference& operator/=(const T& rhs) const { return *this = *this / rhs; }

        friend size_type index(const reference& p) { return p.index_; }
        friend persFeld& feld(const reference& p) { return p.feld_; }
    private:
        persFeld& feld_;
        size_type index_;
        friend class persFeld;
    };
    class const_reference {
        const_reference(const persFeld& f, size_type i) : feld_( f ), index_( i ) {}
    public:
        const_reference(const reference& p) : feld_( feld( p ) ), index_( index( p ) ) {}
    private:
        void operator=(volatile const_reference&) volatile; // nicht zuweisbar
    public:
        operator double() const { return feld_.read( index_ ); }

        friend size_type index(const const_reference& p) { return p.index_; }
        friend const persFeld& feld(const const_reference& p) { return p.feld_; }
    private:
        const persFeld& feld_;
        size_type index_;
        friend class persFeld;
    };

    reference operator[](size_type index) { return reference( *this, index ); }
    const_reference operator[](size_type index) const { return const_reference( *this, index ); }

    friend class reference;
    friend class const_reference;
};

das Problem klingt interessant, wenn Sie eine Lösung gefunden haben, bringen Sie sie bitte am Mittwoch zum Prakikum mit. Viel Glück