std::string zwingt einen zum kopieren, rohe Strings bieten da performantere Optionen.

Warum sind die fstream Konstruktor-Parameter const char*'s und keine const std::string&'s?

Tradition. Weil es auch nicht soo weh tut, ein .c_str() dranzuhängen.
Vielleicht wird es ja mal geändert und string zusätzlich angeboten.

std::string zwingt einen zum kopieren, rohe Strings bieten da performantere Optionen.

Deswegen schrieb ich ja std::string&. Wie das weniger performant sein soll, musst du mir erst mal erklären.

volkard schrieb:

Tradition.

Na toll. Ich bin zwar noch nicht lange dabei, aber dennoch will mir kein Zeitpunkt in der Entwicklung von C++ einfallen, in dem std::string& nicht sinnvoller gewesen wäre. Nachliefern wäre ja zudem auch nie ein Problem gewesen.
(Zumal Visual Studio das längst implementiert hat, die g++ Fehlermeldung die ich gerade lesen musste kam schon überraschend.)

Deswegen schrieb ich ja std::string&. Wie das weniger performant sein soll, musst du mir erst mal erklären.

ifstream in("c:/autoexec.bat")//performant mit char*

Und Du willst erstmal das in einen std::string kopieren, also strlen, new, strcpy oder memcpy, delete zusätzlich für gar nichts.

Na toll. Ich bin zwar noch nicht lange dabei, aber dennoch will mir kein Zeitpunkt in der Entwicklung von C++ einfallen, in dem std::string& nicht sinnvoller gewesen wäre.

Damals als die Disketten noch aus Holz waren, da haben wir sehr aus Performance geachtet.

Für string spricht meiner Menung nach etwas ganz anderes, also nur das .c_str() weglassen zu dürfen. Ich denke, begin/end-Paare wären generell besser als Nullterminierte Strings, auch unten im Betriebssystem. Bald kann ein BS guten Gewissens open() mit begin/end anbieten.

Und Du willst erstmal das in einen std::string kopieren, also strlen, new, strcpy oder memcpy, delete zusätzlich für gar nichts.

Zumindest ein Konstrukt wie

ifstream(const std::string& s, ...)
{
  ifstream(s.c_str(), ...);
}

wäre doch sehr hilfreich, das dürfte nun wirklich nicht auf die Performance gehen.

volkard schrieb:

Für string spricht meiner Menung nach etwas ganz anderes, also nur das .c_str() weglassen zu dürfen.

Na ich wäre schon glücklich damit.
Aber begin/end Paare? Scheint mir auch nicht das Gelbe vom Ei zu sein..

volkard schrieb:

Und Du willst erstmal das in einen std::string kopieren, also strlen, new, strcpy oder memcpy, delete zusätzlich für gar nichts.

Zumindest ein Konstrukt wie

ifstream(const std::string& s, ...)
{
  ifstream(s.c_str(), ...);
}

wäre doch sehr hilfreich, das dürfte nun wirklich nicht auf die Performance gehen.

Ja, geht meinetwegen in Ordnung. Aber es ist nur, damit Du statt

ifstream in((name+"."+ext).c_str());

jetzt

ifstream in(name+"."+ext);

schreiben darfst, oder?

cooky451 schrieb:

Aber begin/end Paare? Scheint mir auch nicht das Gelbe vom Ei zu sein..

Och, man könnte std::string performant übergeben. Und man bräuchte nicht so oft strlen aufzurufen. Und vor allem kann man als Anwender "strings" auf Fremdspeicher vom Tokenizer liefern lassen und so Sachen. fnsplit kann echte "strings", begin/end-Paare liefern, ohne daß auf den Fremdspeicher geschrieben werden muß und ohne daß Daten kopiert werden müssen.

Vielleicht wird es ja mal geändert und string zusätzlich angeboten.

Das ist bei C++11 tatsächlich so.

Deswegen schrieb ich ja std::string&. Wie das weniger performant sein soll, musst du mir erst mal erklären.

Naja, wenn der Compiler die Referenz über nen Zeiger implementiert hast du bei der Variante mit const std::string& ne doppelte Indirektion :p

volkard schrieb:

Ich bin zwar noch nicht lange dabei, aber dennoch will mir kein Zeitpunkt in der Entwicklung von C++ einfallen, in dem std::string& nicht sinnvoller gewesen wäre.

Och, std::string ist toll, aber auch kein Allheilmittel...

volkard schrieb:

Ich denke, begin/end-Paare wären generell besser als Nullterminierte Strings, auch unten im Betriebssystem. Bald kann ein BS guten Gewissens open() mit begin/end anbieten.

Stimmt, Ranges sind einfach was elegantes

Naja, wenn der Compiler die Referenz über nen Zeiger implementiert hast du bei der Variante mit const std::string& ne doppelte Indirektion :p

Das glaube ich weniger
Ich weiß nicht, ob ich dich richtig verstanden habe, aber so:

class MyInt
{
public:
  MyInt()
  {
    m_int = new int;
    *m_int = 5;
  }
  ~MyInt()
  {
    delete m_int;
  }
  const int* pointer()
  {
    return m_int;
  }
private:
  int *m_int;
};

class MyStream
{
public:
  MyStream(const int* p)
  {
    std::cout << *p << std::endl;
  }
  MyStream(MyInt& p)
  {
    MyStream(p.pointer());
  }
};

Ist da nichts doppelt.

dot schrieb:

Och, std::string ist toll, aber auch kein Allheilmittel...

Ne, aber wenn es das schon gibt, sollten die Standardfunktionen den Typ doch zumindest entgegennehmen, wenn er sich geradezu aufdrängt.

Ist da nichts doppelt.

Doch, bei der ersten Variante greifst du direkt über den pointer zu, bei der zweiten musst du zuerst auf p zugreifen und den pointer zu bekommen um dann über den pointer zuzugreifen

cooky451 schrieb:

Ist da nichts doppelt.

Doch, bei der ersten Variante greifst du direkt über den pointer zu, bei der zweiten musst du zuerst auf p zugreifen und den pointer zu bekommen um dann über den pointer zuzugreifen

Aber nur ein mal (nicht dauerhaft, danach gibt's ja einen eigenständigen Zeiger, doppelte Indirektion heißt für mich int**.) Zudem wird das bestimmt wegoptimiert.

Aber nur ein mal (nicht dauerhaft, danach gibt's ja einen eigenständigen Zeiger, doppelte Indirektion heißt für mich int**.)

Was heißt danach gibts einen Zeiger, ich seh da nur einen Zugriff über den Zeiger!?

cooky451 schrieb:

Zudem wird das bestimmt wegoptimiert.

In dem trivialen Beispiel evtl., aber so sicher ist das im Allgemeinen nicht.