No support for serializing a single char?

[P@u1]

Hi,

I recognized that sf::Packet offers operator<< and operator>> for
sf::Int8 and sf::Uint8
which are at my platform typedefs for
signed char   and
unsigned char

But if I use
char
Then it won't compile, as it is a different type.

I know that there is support for 0-terminated char-arrays, but that's not what I need.
Laurent could you please add support for char?

[Laurent]

sf::Packet only supports fixed size types (strings are provided only for convenience), you should serialize your char as a Uint8 to make sure that it has the same size on both ends of the socket.

[P@u1]

Isn't char always 1 byte?

What I'm trying to achieve is to take a part of a packet and transfer it to another packet.
And sf::Packet stores it's data in an std::vector<char>.
So it wanted to extract it char-wise, which is not possible.

I more or less solved it by reading to unsigned chars and casting to char, but I'm not 100% sure, if this is portable without problems.

Why there is no operator<< or operator>> for char?

Edit:
That's the code I used:

Code: [Select]


int size;
packet >> size;
if(size == 0)
{
return;
}
char * data = new char[size];
for(int i = 0; i < size; ++i)
{
unsigned char c;
packet >> c;
data[i] = static_cast<char>(c);
}
data_.Append(data, size);
delete[] data;


I can't do it just with a single append, because I can't get the current readpos (as it's private)
Note that the "string" here is not zero terminated and may contain zeros in the middle

[Laurent]

Isn't char always 1 byte?

Yes, but a byte can be more than 8 bits.

Why there is no operator<< or operator>> for char?

Because its size is not constant across platforms. Same for all other native types (int, short, ...).

What I'm trying to achieve is to take a part of a packet and transfer it to another packet.

It seems like a common problem people have. I should make the read position public, or add a custom type for extracting / inserting raw data directly.

[P@u1]

It seems like a common problem people have. I should make the read position public, or add a custom type for extracting / inserting raw data directly.

That's a very good idea!
Thanks

[Nexus]

It seems like a common problem people have. I should make the read position public, or add a custom type for extracting / inserting raw data directly.

Don't GetData() and GetDataSize() already cover most cases? If the user is certain about the internal representation, he can extract the parts himself... Or does the problem only arise at variable-size data, such as strings?

You should probably be careful with the addition of specific operations. When you make the read position public, chances are that soon other users request more features, and you will end up with a bloated stream class

But if you find an elegant approach (like custom type) providing the necessary flexibility, that would be nice. Otherwise, << and >> alone cover many cases and there is no problem of mixing formatted with unformatted input/output.

[Laurent]

Don't GetData() and GetDataSize() already cover most cases?

No, because:

I can't do it just with a single append, because I can't get the current readpos (as it's private)

You should probably be careful with the addition of specific operations. When you make the read position public, chances are that soon other users request more features, and you will end up with a bloated stream class

In fact I think that a Read(char*, size_t) function would be enough. And renaming Append with Write of course.

[Nexus]

In fact I think that a Read(char*, size_t) function would be enough. And renaming Append with Write of course.

Sounds good. I also think Write() should take const char* instead of const void* for symmetry reasons. User code will need a reinterpret_cast, but that makes clear that an object is read byte for byte.

By the way, is it safe to serialize float and double with sf::Packet? As far as I know, the C++ standard doesn't dictate their sizes either...

[Laurent]

By the way, is it safe to serialize float and double with sf::Packet? As far as I know, the C++ standard doesn't dictate their sizes either...

Ah ah
You're right, and this topic has already been discussed here.
See http://www.sfml-dev.org/forum/viewtopic.php?t=5059