const std::string operator[](const std::string &key){return data_map_[key];}
  	const std::string operator[](const int &index)const{return values_[index];}

data_map_ ist hierbei die genannte map und values_ ein std::vectorstd::string
der quasi nur die werte der map beinhaltet.

Der Zugriff über den int-Index und auch der über den string funktionieren wie
gewollt, aber wenn ich beide operatoren in der klasse lasse, bekomme ich:

error: ISO C++ says that const std::string libdb::db_row::operator\[\](const int&) const' andconst std::string
libdb::db_row::operator[](const std::string&)' are ambiguous even though the
worst conversion for the former is better than the worst conversion for the latter

Der Aufruf bei dem der Fehler auftritt ist:

std::string name=res[0][0];

Es liegt also afaik daran, dass er aus int nen std::string machen kann.
Ich hab denn mal statt std::string const char* genommen, aber da bekam ich
in der umgekehrte Situation einen Fehler.
Wisst Ihr woran es nun liegt; oder viel eher, wie ich dieses Problem umgehen kann?

const std::string operator[](const std::string &key){return data_map_[key];}
const std::string operator[](const int &index)const{return values_[index];}

damit Hasst du: instanz[const int & index] und instanz[std::string &key] realisiert.

also ein res[0] liefert dir ein std::string zurueck (ich nehm an res ist vom typ db_row oder ? )
ein res[0][0] -> ist also ain std::string[0] = eine referenz auf nen char
std::string name=res[0][0]; ist also ne zuweisung eines chars an nen std::string.

Ist dass den definiert ? und wenn, dann ist es sicher nich was zu erwartest ^^

Was ist denn dein uebergeordnetes object(resultset) fuer mehrere rows ?
das muesste ja dann nen operator ala:

db_row & operator[](unsigned int index);
const db_row & operator[](unsigned int index) const;

haben. wein dein res obejct von dem typ waer, muesste es funktionieren.

Noch was anderes (const unsigned int & ) macht kaum sinn ....
wenn ich es nicht veraendern darf, macht ne referenz als rueckgabe logisch keinen sinn
ne kopie von int mittels ner referenz zu vermeiden auch nicht, weil referenz und int wahrscheinlich die selbe groesse haben ...
das der compiler da was mehr optimiert, ist eher auch unwahrscheinlich, wenn ers kann und inlined wird er auch ohne referenz erkennen das er direkt auf die variable ohne probs zugreifen kann ...

nimm lieber (unsigend int index)

und deinen key bei (std:string & key) darf er veraendern ???

Ciao ...

Zur Frage: Tut mir leid der Aufruf war missverständlich.
Wie du schon sagst, es gibt ein result objekt, dass einen operator[] hat:

typedef db_row row_t;
row_t operator[](const int index)const{return *(result_[index]);}

Der Aufruf erklärt sich wie folgt:

result_t res = db->get_result();
std::string name=res[0][0];

res ist also vom typen dessen namen laut typedef result_t ist.
mit [0] bekomm ich nun ein row objekt.
Auf dieses wernde ich nun [0] an und bekomme dann das ergebnis aus dem
vector bzw der map.

Und die const zurückgabe macht doch sinn

neee, erstmal reden wir ueber eine Parameter uebergabe, ned zurueckgabe ^^

Im xxx(const int param) macht das const auch kein sinn, weil:
wir sind bei c++ (hoffentlich) also macht der compiler von deinem param eine kopie. Diese kopie hat nen scope solange die funktion laeuft, und wird dann einfach weggeworfen. deinem aufrufendem programm isses also voellig wuerscht, was du innerhalb mit nem parameter machst, es bekommt davon soweiso nix mit, also kannst dir das const da auch sparen ^^

deine Rueckgabeparameter
const std::string xyz();
machen aber auch nich viel sinn ^^
es gibt keinen grund, warum der zurueckgegebene string const sein soll!
du bekommst ja (c++ !) ne kopie von irgendwas. Die intigritaet deiner Klasse schuetzt du damit nicht, weil dadurch das es ne kopie ist, deine klasse (also die instanz eher) ueberhaupt nicht davon beeinflusst wird.
Und moderne kompiler sind intelligent genug da zu optimieren, so das dir das const auch keinen laufzeitvorteil bringt.

nen std::string test = myclass.xyz(); verhinderst du sowieso nich ^^

Dein bestreben, const sicher zu schreiben in ehren, aber an den stellen bringt es dir gar nix ^^

sinn wuerde es bei sowas machen:

const std::string & get_irgendwas() const;

row_t operator[](const int index)const{return *(result_[index]);}

besser:

row_t operator[](unsigned int index)const{return *(result_[index]);}

oder hasst du negative indizies ? wenn du ne klasse wie ein array aufbauen willst sollt es sich auch an die Array Regeln halten ...

Ich sag nich das es falsch ist, es sieht nur komisch aus ^^

Aber zu deinem eigentlichen problem:

result_t res = db->get_result();
std::string name=res[0][0];

schreib mal:
result_t res = db->get_result();
row_t myrow = res[0];
std::string name = myrow[0];

und schau mal wo es da knallt ....

Ciao ...

Und die const zurückgabe macht doch sinn

neee, erstmal reden wir ueber eine Parameter uebergabe, ned zurueckgabe ^^

Japp meinte ich eigntlich auch -.-

RHBaum schrieb:

Im xxx(const int param) macht das const auch kein sinn, weil:
wir sind bei c++ (hoffentlich) also macht der compiler von deinem param eine kopie. Diese kopie hat nen scope solange die funktion laeuft, und wird dann einfach weggeworfen. deinem aufrufendem programm isses also voellig wuerscht, was du innerhalb mit nem parameter machst, es bekommt davon soweiso nix mit, also kannst dir das const da auch sparen ^^

ACK

RHBaum schrieb:

deine Rueckgabeparameter
const std::string xyz();
machen aber auch nich viel sinn ^^
es gibt keinen grund, warum der zurueckgegebene string const sein soll!
du bekommst ja (c++ !) ne kopie von irgendwas. Die intigritaet deiner Klasse schuetzt du damit nicht, weil dadurch das es ne kopie ist, deine klasse (also die instanz eher) ueberhaupt nicht davon beeinflusst wird.
Und moderne kompiler sind intelligent genug da zu optimieren, so das dir das const auch keinen laufzeitvorteil bringt.

ACK

RHBaum schrieb:

nen std::string test = myclass.xyz(); verhinderst du sowieso nich ^^

Dein bestreben, const sicher zu schreiben in ehren, aber an den stellen bringt es dir gar nix ^^
sinn wuerde es bei sowas machen:
const std::string & get_irgendwas() const;

So war es mal, bevor ich lange zeit nach diesem Fehler suchen musste,
und deswegen den code schon zerreissen musste und diverse male umgebaut habe,
dennoch danke

RHBaum schrieb:

Ich sag nich das es falsch ist, es sieht nur komisch aus ^^

Japp, das stimmt schon, wie gesagt ich habs nicht wieder in den Urzustand
gebracht, weil ich erst das Problem beheben will...

Aber zu deinem eigentlichen problem:

result_t res = db->get_result();
std::string name=res[0][0];

schreib mal:
result_t res = db->get_result();
row_t myrow = res[0];
std::string name = myrow[0];

Naja, wie erwartet, dass Gleiche wie vorher:
( keine ahnung warum mein gcc manchmal deutsch spricht ... )

example.cpp:36: Fehler: ISO C++ besagt, dass diese mehrdeutig sind, auch wenn die schlechteste Umwandlung für das erste besser ist als die schlechteste Umwandlung für das zweite:
database_result.hpp:68: Anmerkung: Kandidat 1: const std::string& libdb::db_row::operator[](int) const
database_result.hpp:61: Anmerkung: Kandidat 2: const std::string& libdb::db_row::operator[](const std::string&)

man bemerke :
std::string name=row["user"];
funktioniert.

die genannte fehlerhafte Zeile macht folgendes (wie zuvor gesagt ):
std::cout<<res[i][0]<<"\n";
//also kommt es beim benutzen von zahlen zur mehrdeutigkeit..
oder wie du es wollest:
row_t row=res[0];
std::string name=row[0];
//auch hier das Gleiche

achja: japp ich "hasse" negative indizies, habe aber natürlich keine=>
deshalb japp unsinged

#include <iostream>
#include <string>

struct Foo
{
    std::string operator[](const std::string&) { return "string operator[](const string&)"; }
    std::string operator[](int) const { return "string operator[](int) const"; }
};

int main()
{
    Foo foo;
    std::cout << foo[0];                         // mehrdeutig
    std::cout << foo[(const char*)0];            // wählt die erste überladung
    std::cout << const_cast<const Foo&>(foo)[0]; // wählt die zweite überladung
}

ein konstanter integraler ausdruck mit dem wert 0 kann implizit in einen pointer umgewandelt werden (und std::string hat einen nicht expliziten ctor, der ein const char* nimmt). diese konvertierung hat schon viel kopfzerbrechen gekostet.
was können wir nun tun, um die mehrdeutigkeit aufzulösen?
offenbar würde es z.b. helfen, eine 3. nicht-const überladung, die ein int nimmt, zu haben - und so die konvertierung in const Foo& zu vermeiden:

struct Foo
{
    std::string operator[](const std::string&) { return "string operator[](const string&)"; }
    std::string operator[](int arg)
    {
        // um duplizität zu vermeiden, könnten wir hjier die const variante aufrufen per
        // return const_cast<const Foo&>(*this)[arg];
        return "string operator[](int)";
    }
    std::string operator[](int) const { return "string operator[](int) const"; }
};

eine weitere variante wäre es, die implizite konvertierung in pointer zu unterdrücken. dazu müssen wir etwas tiefer in die trickkiste greifen: implizite konvertierungen finden nicht für argumente statt, deren typ durch typ deduktion ermittelt wurde. wir brauchen also ein template. um nun nicht mehr mmögliche argumenttypen als erlaubt zu haben, greifen wir auf SFINAE (hier mit boost::enable_if) zurück, um unerwünschte instantiierungen zu unterdrücken:

#include "boost/utility/enable_if.hpp"
#include "boost/type_traits/is_same.hpp"

struct Foo
{
    template<typename T>
    typename boost::enable_if_c
        <
            boost::is_same<std::string,T>::value || boost::is_same<const char*,T>::value,
            std::string
        >::type operator[](const T&) { return "template operator[]"; }
    std::string operator[](int) const { return "string operator[](int) const"; }
};

das ist nat. schon ein bisschen heftiger und in diesem falle wohl mit kanonen auf spatzen geschossen.

offensichtlich sind hier implizite konvertierungen im spiel. schauen wir uns das noch einmal an:

Das dachte ich mir auch, aber ich dachte halt das es am int liegt,
sprich, ich wusste nicht mehr ob der std::string c-tor der einen size_t bekommt,
vorher als erstes nen char* argument haben muss.
Aber das es an der 0 welche als const char* gesehen werden kann, darauf kam ich nicht.
also danke erstmal für deine erklärung und beispiele.
Die boost lösung find ich interessant und werd ich mir mal einfach so genauer anschaun, die mit dem nicht const operator werden ich dann wohl verwenden.
leider kann ich das heute nicht mehr testen, aber ich gehe mal davon aus, dass
es dann gehen sollte.
Somit danke für die Hilfe, es hat mir echt richtig Kopfzerbrechen bereitet...