geht Folgendes bzw. würdet ihr es empfehlen?

class A
{
public:
    const B& GetB() const
    {
        // recht viel Code
    }

    B& GetB()
    {
        // duplicate code wäre unschön, also:
        return const_cast<B&>(static_cast<const A*>(this)->GetB());
    }
};

oder hat das irgendwelche Nachteile?

geht Folgendes

Ja.

würdet ihr es empfehlen?

Nein (das würde implizieren, dass ich es für gut empfinde).

Ernsthafte Alternativen kenne ich in C++ allerdings keine, manchmal (eigentlich nie, habe selten setter, schon gar nicht so komplizierte) mache ich es dann so wie du gezeigt hast.

Ich vermisse in C++ etwas wie

inout B GetB() inout
{
    // recht viel Code
}

Würde ich die Suche jetzt in eine eigene Funktion auslagern, hätte ich doch dasselbe Problem wieder? Meine Suche ist nicht Mal binär, sondern iterativ. Und der Schleifeniterator ist eben auch const oder nicht-const.

Kennst du std::find?

Die Antwort in deinem Fall ist also: Schreib dir deinen eigenen Iterator + Const-Iterator. Die dort auftretende Codeduplikation kannst du mit Templates lösen.

Ich hab irgendwo mal gelesen, dass man das sogar so machen soll

Joa, ich glaube die Empfehlung kommt von Scott Meyers - Effective C++. Obwohl er es so macht:

return const_cast<B&>( static_cast<const A&>( *this ).get() );

Normalerweise denkt man ja eher umgekehrt, also so:

class Foo
{
	Bar x;
public:
	Bar& getX()
	{
		return this->x;
	}

	const Bar& getX() const
	{
		return this->getX();
	}
};

Aber das ist nicht wirklich const-correct, da die const Version nicht dann aufgerufen wird, wenn man es erwartet (und umgekehrt). Wer die Begründung genau wissen will, dem zitiere ich das hier vom Meyers.

Die Methode oben würde ich schon empfehlen, in eine Funktion abkapseln kann man ja immer noch. Ich weiss auch nicht was daran hässlich oder unschön sein soll? Ist halt besser als redundanter Code...

Skym0sh0:
Das wäre doch einfach Endlosrekursion, oder? In der const-Variante ist der this-Zeiger doch immer noch const, also wird auch wieder die const-Variante aufgerufen.

Wenn der Scott Meyers das empfiehlt, kann die Methode ja nicht so falsch sein. Wunderbar, vielen Dank!

find_if kenne ich, das wäre aber auch nicht kürzer. Ich würde dennoch redundanten Code erzeugen, den ich ungern zwei Mal schreiben würde, egal wie kurz er ist (kann ja auf Dauer noch länger werden, dann muss ich trotzdem zwei Mal anpassen).

Ein getter ist eine Zeile lang. Nicht mehr und nicht weniger.

Und ob man unter:

Containter::iterator it = std::find_if(container.begin(), container.end(), [whatEver](Object& obj)
{
    return obj.whatEver == whatEver;
});
return it == container.end() ? nullptr : &*it;

jetzt einen Einzeiler verstehen muss, würde ich auch anzweifeln.

Gerne kann mir jemand aber auch den Vorteil zu:

BOOST_FOREACH(Object& obj, container)
{
    if(obj.whatEver == whatEver)
        return &obj;
}
return nullptr;

erklären, letzteres erscheint mir nämlich kürzer und lesbarer.

geht Folgendes bzw. würdet ihr es empfehlen?

Wenn das so Sinn macht mit der Überladung, 2mal ja.

Und ob man unter [...] jetzt einen Einzeiler verstehen muss, würde ich auch anzweifeln.

Deine Funktion ist auch kein typischer Getter, sondern ein Sucher. "get" heisst "gib mir" -- entsprechend ist die Erwartung, dass man das Gewünschte auch bekommt. Bei dir hingegen kann der zurückgegebene Wert ungültig sein.

Ja, im weiten Sinne könnte man vieles als Getter sehen, z.B. auch operator[] ... Die Frage ist, wo du die Grenze ziehst. Nicht alles, was etwas zurückgibt, ist ein Getter, sonst wird der Begriff bedeutungslos. Ich versuchte mit meinem Post nur zu erklären, was Shade Of Mine wahrscheinlich meinte.