Ungetestet.

std::string s = (std::istringstream() << std::hex << reinterpret_cast<std::intptr_t>(ptr)).str();

Ungetestet.

Muss doch ein ostringstream sein?

Muss doch ein ostringstream sein?

Rate doch mal, wer von euch beiden wohl Recht hat. Und dann probier's zur Sicherheit nochmal aus.

std::string s = (std::istringstream() << std::hex << reinterpret_cast<std::intptr_t>(ptr)).str();

Ohne es jetzt ausprobiert zu haben: Brauchen wir keinen lvalue auf der linken Seite vom operator<<?

Ohne es jetzt ausprobiert zu haben: Brauchen wir keinen lvalue auf der linken Seite vom operator<<?

Das temporäre Objekt ist ja nicht konstant. Das ist doch diese komische Sonderklausel, die genau solche Konstrukte erlaubt.

@Hacker: Ich hoffe, du hast inzwischen ausprobiert und herausgefunden, dass du richtig rum gedacht hast . Dummerweise funktioniert beides nicht, da am Ende kein stringstream mehr rauskommt.

Edit: Zu spät.

Bashar schrieb:

Ohne es jetzt ausprobiert zu haben: Brauchen wir keinen lvalue auf der linken Seite vom operator<<?

Das temporäre Objekt ist ja nicht konstant. Das ist doch diese komische Sonderklausel, die genau solche Konstrukte erlaubt.

Meinst du weil der operator<< in dem Fall eine Memberfunktion ist? Wusste ich gar nicht, und jetzt kommt mir diese Klausel auch ziemlich unlogisch vor.

Meinst du weil der operator<< in dem Fall eine Memberfunktion ist?

Ja.

Wusste ich gar nicht, und jetzt kommt mir diese Klausel auch ziemlich unlogisch vor.

Ja, die ist ein bisschen komisch.

SeppJ schrieb:

Hacker schrieb:

Muss doch ein ostringstream sein?

Rate doch mal, wer von euch beiden wohl Recht hat. Und dann probier's zur Sicherheit nochmal aus.

Ich dachte, Mac-User machen nie was falsch, und der Computer hat ein eingebautes Erkennungssystem dass jeglichen unschönen oder gar falschen Code oder unschönes Design automatisch durch das bestmögliche ersetzt...

#include <iostream>
#include <sstream>
using namespace std;

int f=1;

class var
{

};

ostream &operator<< (ostream &os, var &v )
{
        return os<< &f ;
}

int main()
{
string s;
        var v;

        stringstream str;
        str << hex<< v;
        str >> s;

cout<< hex << &f << endl; // Zur Kontrolle
cout<<"Speicheradresse der Variable f in hex: " << s<<endl;

        return 0;
}

Das funktioniert:

#include <iostream>
#include <sstream>
using namespace std;

int f=1;

class var
{

};

ostream &operator<< (ostream &os, var &v )
{
        return os<< &f ;
}

int main()
{
string s;
        var v;

        stringstream str;
        str << hex<< v;
        str >> s;

cout<< hex << &f << endl; // Zur Kontrolle
cout<<"Speicheradresse der Variable f in hex: " << s<<endl;

        return 0;
}

Was zum Teufel ist das für ein Scheiß?

Das einfachste, schnellste Ergebnis wäre das hier:

int a;
std::string speicheradresse(boost::lexical_cast<std::string>(&a));

Was zum Teufel ist das für ein Scheiß?

Hab ich mir genau in diesem Moment auch gedacht.

http://en.cppreference.com/w/cpp/string/basic_string/to_string

Das unterstützt mein Compiler nicht. Außerdem ist lexical_cast schneller, wetten?

1. Dann nimm nen besseren Compiler.

Ich hab den GCC.
Es gibt mit Abstand nichts besseres.
Aber wo gibt es den MinGW mit dem neuesten GCC 4.7 (32-Bit, wenn möglich) zum download? Ich hab 4.6.1 :gespannt:

GCC 4.6.2 und auch 4.7 schrieb:

Fehler: »to_string« ist kein Element von »std«

Also das versteh' ich jetzt echt nicht.
Auszug aus meiner include/c++/bits/basic_string.h:

inline string
  to_string(int __val)
  { return __gnu_cxx::__to_xstring<string>(&std::vsnprintf, 4 * sizeof(int),
					   "%d", __val); }

Und sogar das hier gibt dieselbe Fehlermeldung, auch mit -std=c++0x usw.

#include <bits/basic_string.h>

Keine Ahnung was da los ist..

Naja, ich werd wohl noch länger warten müssen..

Wie kann ich denn nun eine Speicheradresse in einen String bzw. konstante Zeichenkette schreiben?

Naja, so einfach die Frage auch war, hab ich in den ganzen 19 Antworten keine Lösung gefunden))))

Wie kann ich denn nun eine Speicheradresse in einen String bzw. konstante Zeichenkette schreiben?

Hä? Das wurde jetzt mitunter mehrmals vorgemacht!

Das liegt daran, dass to_string beim MinGW nicht dabei ist, warum auch immer. :p

Tja, werd deswegen wohl oder übel auf Linux umsteigen müssen fürs Entwickeln....