hi, i was wondering if it is possible to send a struct through sockets...

thanks in advance,
nicolas

Dani AI

Generated

Short summary and practical guidance tying together 's follow-up and 's warning.

Because both processes run on the same host you might be tempted to send a struct with a single send(). That can work in a controlled build/test environment, but it is brittle for anything beyond quick, same-build experiments. Differences in type sizes, compiler-inserted padding, 32/64-bit changes, or any pointer members will make the receiver misinterpret data. A safer approach is to define a small, explicit “wire format” and serialize/deserialize each field yourself.

Use fixed-width types (from stdint.h), include a version or message header, and convert integer fields to a canonical byte order before sending. For 64-bit integers provide a helper (htonll/ntohll) — example:

#include <stdint.h>
#include <arpa/inet.h>

static inline uint64_t htonll(uint64_t x) {
#if defined(__BYTE_ORDER__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
    return ((uint64_t)htonl((uint32_t)(x & 0xFFFFFFFF)) << 32) |
           htonl((uint32_t)(x >> 32));
#else
    return x;
#endif
}

Pack fields into a buffer (use memcpy to avoid alignment issues), prefix the record with a fixed header that includes version and payload length, then send. On the receiver read the header first, then loop until the entire payload arrives (TCP is a stream — partial reads happen).

Final tips: never send raw pointers; add a version byte so you can evolve the format; static_assert sizes at compile time; consider well-tested serializers (Protocol Buffers, MessagePack, JSON) for long-term robustness; and use Unix domain sockets for same-host comms if you want lower latency and simpler addressing. These steps keep communication predictable and debuggable while avoiding the fragility of raw struct dumps.

Recommended Answers

All 4 Replies

Yes, you can.
No, it's a bad idea to try.

It's a bad idea because the packing and alignment of the data is dependent on the compiler, and the endian-ness of the data is dependent on your architecture. If there is any variance between the sender and receiver, the receiver could have a hard time understanding what the hell you're talking about.

If your struct contains pointers, then just forget about sending them "as is", because the pointer really won't mean a damn thing to the other machine.

thanks for your answer salem,

so to do this properly i should send the componenets of the struct one by one?

PS:: i didn't mention on my first post that the communication will be in the same machine{by a "client" and a "server" application}

Ideally, you should make the external representation (whether across a network or saved in a file) as implementation neutral as possible, to give the widest possible chance for something else to pick it up and use it.

If you're constraining yourself to the same machine, then it's a judgement call on your part. But at least hopefully you'll be making an informed choice.

thanks salem!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.