Abbruch bei Zugriff auf STL vector Element. Warum?

314159265358979

3 ist nicht nur unnötig, sondern sogar potentiell Gefahr für Danling Pointers, falls einer der Strings neu allozieren muss.

pyhax

Wie macht man es denn richtig? (Wenn man std::string verwenden will und die Lib)

Richtig wäre, bei jedem Aufruf .c_str() anzuhängen.

Lustig wäre, folgenden Wrapper zu verwenden:

template <typename Container>
struct cstrings {
  cstrings(Container& c) : c(c){}
  const char* operator[](size_t at) const { return c[at].c_str(); }
  Container& c;
};
typedef cstrings<std::vector<std::string> > cstring_vector;

int main()
{
  std::vector<std::string> string_vector = {"a", "b", "c"};
  cstring_vector cstr(string_vector);
  puts(cstr[1]);
}

pyhax

Aber ich denke die Lib will einen std::vector haben

pyhax schrieb:

Aber ich denke die Lib will einen std::vector haben

Komisch. std vector und C-Strings?

volkard

pyhax schrieb:

Wie macht man es denn richtig? (Wenn man std::string verwenden will und die Lib)

Da bin ich jetzt auch mal gespannt, wie man hier wider die Lib programmieren soll.

pyhax

Oder einen pointer?

pumuckl

Die Frage ist doch hauptsächlich, was die Lib mit der Sammlung von C-Strings anfängt und wie du vor und zwischen den Lib-Aufrufen die C-Strings erstellst/manipulierst. Je nachdem würde ich eine simple Wrapperklasse für C-Strings schreiben, einen Container, der die Dinger verwaltet, und eine Möglichkeit, aus dem Container den benötigten std::vector<char*> zu holen.

krümelkacker

pumuckl schrieb:

Die Frage ist doch hauptsächlich, was die Lib mit der Sammlung von C-Strings anfängt [...]

Falls die Lib-Schnittstelle wirklich so aussieht:

void irgendeine_lib_funktion(vector<char*> const& param);

und sich diese Funktion die Zeiger weder "irgendwo anders" über den Funktionsaufruf hinaus speichert, noch über sie die Zeichenketten ändern will, dann würde ich wahrscheinlich auch temporär einen solchen Vektor anlegen und ihn per reinterpret_cast mit Zeigern befüllen, die ich über string::c_str von string-Objekten bekomme, die lang genug leben. Das ist zwar unschön, aber was soll man auch groß anders machen, mit so einer Schnittstelle?

Dass dann in einer Klasse zu kapseln, wie Pumuckl vorschlägt, klingt auch nicht doof.

krümelkacker schrieb:

....reinterpret_cast mit Zeigern befüllen, die ich über string::c_str von string-Objekten bekomme, die lang genug leben.

Jo, das deren Destruktor dann selbstverständliche Sachen macht...
Wenn mich aber nicht alles täuscht, nimmt man da nicht const_cast (oder ich kapier nich' was du machen willst)?