ich hab das Gefühl, dass mich C++ verarscht. Ich muss den "==" Operator meiner Klasse überladen, da ich ein vector damit fülle und std::find() ausführen will. Obwohl ich dies gemacht habe, beschwert sich der Kompiler über den fehlenden Operator. Das Beispiel Projekt, welches ziemlich ähnlich aufgebaut ist, lässt sich natürlich problemlos kompilieren und ausführen. Wie passt das zusammen, was mache ich falsch?

Hier der Header:

#pragma once

//#include "GraphicsContext.h"

namespace gl
{
	class Buffer
	{
	protected:
		GraphicsContext& context;
		void* data;
		bool locked;
	public:
		Buffer(GraphicsContext& context, unsigned dataSize);
		virtual ~Buffer();

		void* Lock();
		void Unlock();

		bool Equal(const Buffer& other) const;
		//bool operator ==(const Buffer& op2) const;
	};

	bool operator==(const gl::Buffer& lhs, const gl::Buffer& rhs);
}

Hier die Methode welche std::find ausführt:

void GraphicsContext::RegisterBuffer(Buffer& buf)
	{
		auto iter = std::find<std::vector<Buffer*>::iterator>(buffers.begin(), buffers.end(), buf);
		if (iter != buffers.end())
			buffers.push_back(&buf);
	}

Der Fehler:

Fehler	1	error C2679: Binärer Operator '==': Es konnte kein Operator gefunden werden, der einen rechtsseitigen Operanden vom Typ 'const gl::Buffer' akzeptiert (oder keine geeignete Konvertierung möglich)	c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility	3186	1

Das Beispielprojekt:

#include <iostream>
#include <memory>
#include <vector>
#include <iterator>
#include <algorithm>

using namespace std;

namespace tl
{
class A
{
private:
    int a, b;
public:
	A() {}
    A(int a, int b)
    {
        this->a = a;
        this->b = b;
    }

    bool equal(const A& other) const
    {
        if (a == other.a || b == other.b)
            return true;
        return false;
    }
};

bool operator==(const tl::A& a, const tl::A& b)
{
    return a.equal(b);
}

class B : public A
{
public:
	B(int a, int b) : A(a, b) {}
};

}

tl::B readB()
{
    int a, b;
    cout << "A a: ";
    cin >> a;
    cout << " | b: ";
    cin >> b;
    cout << std::endl;
    return tl::B(a, b);
}

int main()
{
    tl::B t1 = readB();
    tl::B t2 = readB();

    cout << (t1 == t2) << endl;

    vector<tl::A> vec(2);
    vec.push_back(t1);
    vec.push_back(t2);

    auto iter = find<vector<tl::A>::iterator>(vec.begin(), vec.end(), t2);
    if (iter != vec.end())
        cout << "Founded!";
    else
        cout << "Not founded";

    std::cin.get();
}

Ich benutze Visual Studio 2012. Ich hoffe die Definitionen reichen, wenn nicht gibts den Quellcode auch.
Vielen Dank!

Zum Problem: Dein Operator== erwartet einen Buffer, bzw eine Referenz darauf, was syntaktisch beim Aufruf dasselbe ist.

Dein vector hält aber Zeiger auf Buffer Objekte (allein schon wegen den zeigern böse!). Der sucht nun also nach einem operator==(Buffer *, Buffer bzw operator==(Buffer *, Buffer&)

Und wieso lässt du den Compiler die Typen der find Funktion nicht selsbt herleiten?!

Bitte die Fehlermeldung umformatieren, ich möchte nicht immer 300000000 Meter nach rechts scrollen mit dem Browser um was zu lesen.

Oh das wusste ich nicht, keine Absicht. Kann ich leider auch nicht ändern, da ich nicht angemeldet bin, kann ein Moderator vielleicht aushelfen?

Danke für die Erklärung, ich dachte es gäbe nur einen Operator mit Referenzen. Jetzt klappts!

Skym0sh0 schrieb:

Dein vector hält aber Zeiger auf Buffer Objekte (allein schon wegen den zeigern böse!).

Ich weiß, der Kompiler hat wegen irgendwas gemeckert, als ich eine Referenz benutzen wollte. Das muss ich wohl nochmal versuchen.

Rohe Zeiger in Listen (sei es Arrays, Vectoren oder Bäume) sind nicht zu empfehlen, da du die "gezeigten" Objekte manuell löschen musst oder umgekehrt dafür sorgen musst, dass die referenzierten Objekte nicht zu früh gelöscht werden.

Wenn dein vector also den alleinigen Besitz der Objekte innehat, dann nimm std::vector<std::unique_ptr<Buffer>> (oder boost::ptr_vector<Buffer>), wenn die Objekte woanders gehalten werden nimm statt unique_ptr shared_ptr oder weak_ptr je nachdem...

Ein Factory-Pattern würde mir sonst noch einfallen, manchmal muss man einfach einen Kompromiss eingehen.
Obwohl mir das Pattern in C++ nicht so gefällt, in C# lässt sich sowas besonders elegant machen.

Dass du deine Buffer speichern willst/musst ist keine Frage, aber dazu gehört dann auch, dass sie gelöscht werden, wenn sie wegsollen. Das ist am einfachsten und am sichersten mit Smart-Pointern zu lösen, wie gesagt unique_ptr.

Dass sich deine Buffer irgendwo an- oder abmelden ist ein anderes Problem. Und deinen Buffer sollte es auch eigentlich nicht interessieren, wo er gelagert oder registriert ist, da dies die Abhängigkeit signifikant erhöht. Er ist halt semantisch nicht korrelierend mit dem GraphicsContext.

Das GoF-Factory-Pattern würde ich hier nicht nehmen, eher sowas:

class Buffer
{
public:
    Buffer(int x /*, und andere Parameter*/);
    // .....
};

std::shared_ptr<Buffer> createBuffer(std::vector<std::shared_ptr<Buffer>> & contextList, int x /*, und deine anderen CTor Parameter*/)
{
    std::shared_ptr<Buffer> tmp(new Buffer(x, ...));
    contextList.push_back(tmp);
    return tmp;
}

Du kapselst so den Construktor ab, aber hängst deine Bedingungen dran (halt, dass dein objekt direkt in eine Liste geshcoben wird)

Das heißt das GraphicsContext so aussehen würde?

class GraphicsContext
{
private:
	std::vector<std::shared_ptr<Buffer>> buffers;
	//...
public:
	std::shared_ptr<FrameBuffer> createFrameBuffer(/* ... */)
	{
		std::shared_ptr<FrameBuffer> tmp(new FrameBuffer(/* ... */));
		buffers.push_back(tmp);
		return tmp;
	}
	std::shared_ptr<VertexBuffer> createVertexBuffer(/* ... */);
	//...
};

Nein, das Factory-Method Pattern macht was anderes, der Wikipedia Artikel sit da ganz gut...