my_htons - funktioniert das immer?

Dafür gibt es bereits fertige Funktionen die zusammen mit der socket API ausgeliefert werden.

cooky451

memcpy schrieb:

afaik ist reinterpret cast böse

Noja, der erste geht schon klar. Der zweite eher nicht mehr. Aber das Alignment ist hier z.B. nicht garantiert.

Hacker schrieb:

reinterpret_cast erzeugt ggf. undefiniertes Verhalten. Zum Beispiel hier:
auto _= [](){};//Pumuckls liebling
      void* ptr = reinterpret_cast<void*>(&_);
      (*reinterpret_cast<decltype(_)*>(ptr))();

Das ist doch schlicht ein Slicing-Problem, sollte jedem klar sein.

camper

Hacker schrieb:

314159265358979 schrieb:

Wegen Forenposts wurden Leute schon rechtlich belangt, deshalb sollte man Foren meiden.

Na und? Prostitution ist auch verboten. Trollen ist verboten. In New York ist es verboten, einen Elch in der Badewanne schlafen zu lassen oder Frauen hinterherzugucken. Trotzdem macht es jeder.

Ethon_ schrieb:
Hacker schrieb:
reinterpret_cast erzeugt ggf. undefiniertes Verhalten. Zum Beispiel hier:
auto _= [](){};//Pumuckls liebling
      void* ptr = reinterpret_cast<void*>(&_);
      (*reinterpret_cast<decltype(_)*>(ptr))();
Das ist doch schlicht ein Slicing-Problem, sollte jedem klar sein.
Undefiniert ist undefiniert. Einen Funktionszeiger zu void* zu konvertieren wird vom Standard nicht berücksichtigt (ich hätte hier auch explizit eine globale Funktion nehmen können).

Verstehe ich nicht.

cooky451

Eine Lambda ist keine Funktion, auch wenn man sie konvertieren kann.

Hacker schrieb:

Undefiniert ist undefiniert. Einen Funktionszeiger zu void* zu konvertieren wird vom Standard nicht berücksichtigt (ich hätte hier auch explizit eine globale Funktion nehmen können).

De facto wird es berücksichtigt, auch wenn das Verhalten nicht garantiert ist. Siehe dazu Abschnitt:

n3376 5.2.10/8 schrieb:

Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning of such a conversion is implementation-defined, except that if an implementation supports conversions in both irections, converting a prvalue of one type to the other type and back, possibly with different cvqualification, shall yield the original pointer value.

Zudem hast du Pi's Kommentar nicht verstanden, denk da noch mal drüber nach.

cooky451

Hacker schrieb:

Stopp. Pis kommentar war doch nur Troll, oder hat er eine subtile Aussage gemacht? Die ich nicht blicke?

Jo.

Hacker schrieb:

Aber void* ist doch kein Object-Pointer? Ich dachte, ein Object-Pointer ist ein Zeiger auf eine Instanz einer Klasse?

Nein.

n3376 3.9.2/3 Erster Satz schrieb:

The type of a pointer to void or a pointer to an object type is called an object pointer type.

pumuckl

Hacker schrieb:

Ich dachte, ein Object-Pointer ist ein Zeiger auf eine Instanz einer Klasse?

"object"s sind im Standardese alles, was Speicher belegt. Objektpointer sind damit Poitner auf irgendwas im Speicher, oder schlichtweg Speicheradressen, im Gegensatz zu Funktiosadressen/Memberfunktionsadressen.

krümelkacker

Hacker schrieb:

Prostitution ist auch verboten.

Was'n das für ne Aussage? Auf welche Gesetzgebung beschränkst du dich da denn?

Ich finde solche Funktionen wie htons, die sowohl 'nen int fressen als auch wieder ausspucken irgendwie sinnfrei. Es sind doch nur Zahlen. Klingt so, als ob da jemand Daten in ein struct packen und direkt senden will, als sei da irgend ein Layout garantiert. Pfui.

knivil

die sowohl 'nen int fressen als auch wieder ausspucken irgendwie sinnfrei

Wat dat denn fuer 'ne Argumentation? Dann findest du Funktionen, die einen double fressen und wieder ausspucken auch sinnfrei? sin, cos, tan, ... Darueber hinaus: Der PC kennt keine Zahlen.

krümelkacker

knivil, htos soll zur Kodierung/Dekodierung eingesetzt werden. Da geht's also um Mappings zwischen Ganzzahlen und Byte-Sequenzen. In der Sprache C++ haben wir Ganzzahltypen für Ganzzahlen und so etwas wie char[] oder ähnliches für Byte-Sequenzen. Eine Funktion zur Kodierung/Dekodierung die ints frisst und ints ausspuckt, lädt nur dazu ein, so etwas zu schreiben:

struct chunk
{
  char id[4];
  uint32_t size;
};

int main()
{
  ...
  chunk c = {{'R','I','F','F'}, host2le(99)}; // le = little endian
  file.write(reinterpret_cast<char*>(&c),sizeof c);
  ...
}

und das ist generell böse, weil der Compiler beim Layout solcher Typen Lücken einfügen darf (Padding).

Ich wär eher für so etwas wie

template<class OctetOutputIter>
void write_int16le(OctetOutputIter & oo, unsigned short x)
{
  *oo++ = x & 0xFFu;
  *oo++ = (x >> 8) & 0xFFu;
}

Da gibt's sicherlich auch lustige C++ Bibliotheken, die das angenehmeer gestalten, mich ein Binärformat in einer EDSL ausdrücken lassen und automatisch ein solches struct portabel serialisieren können mit ein bissel Metaprogramming.