Add readCurrentReadPosition in sf::Packet

[1aam2am1]

I have a header in my sf::Packt (saved). He has different length (depending of the type). I do other action depending of the header. I would read current position of reading Packet, because my functions use pointer to data (const void*getData()). I want know, where I should begin read data.

[eXpl0it3r]

sf::Packet is intended as its own protocol. If you want to read raw data directly you'll have to deal with the serialization yourself.

[1aam2am1]

But, if I have:

Send:

sf::Packet packet;

packet << (int); //saved length
packet << string; //saved type of packet
packet.append(somedata, somelength);

//... sending packet
 

Recive:

sf::Packet packet;

//... reciving packet

packet >> (int);
packet >> string;

void* read = packet.getData();
 

From what position should read data added using append?

[Ixrec]

Is it possible sf::Packet::append was meant to be a protected method rather than a public method? There don't seem to be any sf::Packet methods to read "the next n bytes" that 1aam2am1 could be using, and a public append() method for raw bytes doesn't make a lot of sense without an equivalent read method for raw bytes.

[Hiura]

Is it possible sf::Packet::append was meant to be a protected method rather than a public method?

That's indeed possible.

It's true that the `operator >>(char* data)` could be a bit generalised into a `readBytes` that takes as parameter the number of bytes to read. But then, the user would have to store the length in the packet as well so it basically offers no additional feature as writing a null-terminated char sequence and then reading it back.

The question is, should we a) provide a lower level interface like `readBytes`, b) privatise `append` (in SFML 3), or c) provide a higher level mechanism to write/read arbitrary sequence (I'm thinking iterator-like here).

For me, c) doesn't sound really useful in practice as it's trivially done on the user's side with a simple loop and using the other, lower level primitives. Regarding a) and b), I don't really know.

[Ixrec]

My preferred solution would be privatize append() in SFML 3, but also take a few features from SFNUL like the ability to packet-ize arbitrary STL containers, since I believe containers and std::string cover all the legitimate reasons for wanting to read/write a blob of bytes to a packet. But I don't even use SFML packets so my opinion probably doesn't matter much.

[Laurent]

Is it possible sf::Packet::append was meant to be a protected method rather than a public method?

Nop, it was always meant to be public.

a public append() method for raw bytes doesn't make a lot of sense without an equivalent read method for raw bytes

Indeed.

sf::Packet will most likely change a lot in SFML 3, but in the meantime I guess we could add a read function.

[Cruel]

The proposed readCurrentReadPosition isn't sufficient without another method to advance the read position (m_readPos).

I think perhaps it's ideal to merely have one method that does both, something like:

const void* getData(std::size_t sizeInBytes);

Of course, getData() already exists to access packet data from the beginning, so you'd have to find a better name or overload it. Overloading it would perhaps require a second parameter to specify start position (defaulting to 0). Though just naming it something else would perhaps be less confusing for people already using getData().