Der Beispielcode für C++11 ist

// int -> string 
  { 
    int const i = 10; 
    string s = to_string(i); 
    cout << s << endl; 
  }

Ansonsten musst du dich etwas klarer ausdrücken, deine Frage ist ziemlich mehrdeutig.

Edit: Da du ja explizit nach** char -Arrays** fragst: Mittels der Methode c_str() bekommt man einen nullterminierten C-String welcher den gleichen Inhalt hat wie das string -Objekt.

Falls du ein modifizierbares char -Array haben willst, kannst du auch das &str[0] -Idiom verwenden. Und falls du tatsächlich ein echtes char -Arrayobjekt brauchst, definiere selbiges und nutze snprintf um die Zahl hineinzuschreiben.

ich glaube er hat z.b. ein 32 bit integer und will daraus ein char[4] machen um z.b. die einzelnen bytewerte zu verarbeiten... Jedenfalls würde ich das draus interpretieren

memcpy dürfte reichen:

int i = 2234;

	unsigned char arr[sizeof(int)];

	std::memcpy(arr, &i, sizeof(arr)); // benötigt <cstring>

Natürlich ist es auch möglich Bitshifts zu verwenden:

int i = 2234;

	unsigned char arr[sizeof(int)];

	// Die Schleife wird vom Compiler geunrolled.
	for( unsigned c = 0; c != sizeof(arr); ++c )
		arr[c] = i >> c*CHAR_BIT; // benötigt <climits>

int foo = 7;
	reinterpret_cast<char*>(&foo)[0]=9;
	cout << foo;

template <typename T> // hier evtl nur fundamentaltypen zulassen
union Serializer
{
    T value;
    char [sizeof(T)] data;
};

Ich schließe die Frage gleich mal an:
Union böse oder gangbar?

Ein Klugscheißer würde einwenden, dass es undefiniertes Verhalten ist. Ich würde daraufhin einwenden, dass es in jeder bekannten Implementierung wie gewünscht funktioniert und daher eine gute Methode ist.

Oder einfach casten und direkt auf dem Original arbeiten?

int foo = 7;
	reinterpret_cast<char*>(&foo)[0]=9;
	cout << foo;

Das versteh ich nicht ganz... warum [0]=9?

Ein Klugscheißer würde einwenden, dass es undefiniertes Verhalten ist.

Warum?

Ein Klugscheißer würde einwenden, dass es undefiniertes Verhalten ist.

Warum?

Wenn ich das nicht falsch verstanden habe, dann dürfte das 9.5.1 sein:

§9.5.1 schrieb:

In a union, at most one of the non-static data members can be active at any time, that is, the value of at most one of the non-static data members can be stored in a union at any time.

Übersetzt also in etwa:
In einem Union darf nur auf das zuletzt beschriebene Member lesend zugegriffen werden.

Das steht dort nicht (oder jedenfalls kann diese Überstzung leicht missverstanden werden). Dort steht nur, dass wenn auf diesen Speicherbereich zugegriffen wird, der gelesene Zustand derjenige ist, der zum zuletzt beschriebenen (=aktiven) Member gehört. Ob dieser Zugriff legal ist oder nicht, wird in diesem Absatz überhaupt nicht diskutiert - dafür empfiehlt ein Blick in 3.10/10. Der Absatz ist deswegen nicht überflüssig: ohne diese Klarstellung wäre nämlich nicht klar, auf welchen gespeicherten Typ sich 3.10/10 beziehen soll.

In einem Union darf nur auf das zuletzt beschriebene Member lesend zugegriffen werden.

Falsch. Wo steht etwas von lesen?

Der entscheidende Teil des Standards der es nämlich zu erlauben scheint ist strict aliasing.

§3.10/10 schrieb:

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
— a char or unsigned char type.

Ich frage mich dennoch ob die Zeigerarithmetik definiert ist, da doch kein Arrayobjekt existiert...

Ich würde daraufhin einwenden, dass es in jeder bekannten Implementierung wie gewünscht funktioniert

GCC kann hier durchaus gruselige Optimierungen durchführen.

Edit: Zu spät.

SeppJ schrieb:

Oder einfach casten und direkt auf dem Original arbeiten?

int foo = 7;
	reinterpret_cast<char*>(&foo)[0]=9;
	cout << foo;

keiner hier mag Referenzcasts?

int foo = 42;
    auto& foo_as_chars = reinterpret_cast<char(&)[]>(foo);

finde ich viel sprechender in Hinblick auf das, was im Anschluss damit gemacht wird.

btw,

SeppJ schrieb:

Oder einfach casten und direkt auf dem Original arbeiten?

int foo = 7;
	reinterpret_cast<char*>(&foo)[0]=9;
	cout << foo;

keiner hier mag Referenzcasts?

int foo = 42;
    auto& foo_as_chars = reinterpret_cast<char(&)[]>(foo);

finde ich viel sprechender in Hinblick auf das, was im Anschluss damit gemacht wird.

Seit wann gibts es denn Referenzen auf Arrays of unknown Bound? Kann man die ueberhaupt irgendwie gueltig initialisieren, mal abgesehen von Casts?

Seit wann gibts es denn Referenzen auf Arrays of unknown Bound? Kann man die ueberhaupt irgendwie gueltig initialisieren, mal abgesehen von Casts?

Schon immer. Genauso wie du z.B. Referenzen auf noch nicht definierte Klassen haben kannst.

extern int array[];
int (&ref)[] = array;
int array[4]; // decltype(ref) ist immer noch int(&)[] - der referenzierte Typ wird also nicht nachträglich vollständig

Ich habe auch eine solche extern-Deklaration ohne Bounds noch nie gesehen. Hat das Ganze irgendeinen praktischen Nutzen?

Du kannst stehts ein array-to-pointer decay durchfüren und den Zeiger auf das erste Element erhalten. Damit kannst du auch direkt auf die Arrayelemente per Subscript-Operator zugreifen:

extern int arr[];
	arr[5] = 3;

Gibt dir zwar ggf. einen Linker-, nicht aber einen Compilerfehler. Du kannst also (teilweise eingeschränkt) damit arbeiten.

Das Ganze könnte vielleicht nützlich werden wenn du von ÜE A auf ein Array in ÜE B zugreifen willst, aber unabhängig von der genauen Größe bleiben willst. Einen konkreten Anwendungsfall kenne ich nicht.

Ich habe auch eine solche extern-Deklaration ohne Bounds noch nie gesehen.

Ich auch nicht.

Kellerautomat schrieb:

Hat das Ganze irgendeinen praktischen Nutzen?

Vermutlich nicht. Die wenigen denkbaren Anwendungsfälle, die mir einfallen, kann man genauso gut auch anders lösen. Abgesehen von unique_ptr<foo[]> kommen solche Arrays wahrscheinlich nur sehr selten vor. Und selbst diesen Anwendungsfall hätte man recht problemlos anders lösen können, wenn es das Sprachfeature nicht gäbe.

das sog. "type punning" mittels Unions in C++ (11) wird aber von anderen aufgrund dieses Satzes als nicht konform angesehen (auch wenn im Standard nicht explizit von UB die Rede ist - aber es ist ja alles UB was eben nicht im Standard steht ;-):
http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-undefined
http://stackoverflow.com/questions/2310483/purpose-of-unions-in-c-and-c
http://stackoverflow.com/questions/6136010/is-using-an-union-in-place-of-a-cast-well-defined

Und auch unter union vs reinterpret_cast wird es als UB beschrieben.

Oder doch einfach nur ein Mythos?

Hallo Camper,

das sog. "type punning" mittels Unions in C++ (11) wird aber von anderen aufgrund dieses Satzes als nicht konform angesehen (auch wenn im Standard nicht explizit von UB die Rede ist - aber es ist ja alles UB was eben nicht im Standard steht ;-):
http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-undefined
http://stackoverflow.com/questions/2310483/purpose-of-unions-in-c-and-c
http://stackoverflow.com/questions/6136010/is-using-an-union-in-place-of-a-cast-well-defined

Und auch unter union vs reinterpret_cast wird es als UB beschrieben.

Oder doch einfach nur ein Mythos?

Ich habe mich nur auf das konkrete Zitat bezogen, dass für sich genommen nicht ausreicht, um UB zu begründen. Zu der allgemeinen Problematik des type-punnings (mit oder ohne union) will ich damit nicht Stellung genommen haben. Der Fall char/unsigned char ist allerdings speziell und immer erlaubt.

Ich würde daraufhin einwenden, dass es in jeder bekannten Implementierung wie gewünscht funktioniert

GCC kann hier durchaus gruselige Optimierungen durchführen.

Mein Punkt war: Eben nicht. Soweit ich weiß garantiert der GCC, dass das wie gewünscht funktioniert. Aber ich mag gerade nicht das GCC-Handbuch durchpflügen.