SFML community forums

General => Feature requests => Topic started by: 1aam2am1 on February 27, 2016, 09:03:27 pm

Title: Add readCurrentReadPosition in sf::Packet
Post by: 1aam2am1 on February 27, 2016, 09:03:27 pm: 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.
Title: Add readCurrendReadPosition in sf::Packet
Post by: eXpl0it3r on February 27, 2016, 09:09:50 pm: 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.
Title: Re: Add readCurrendReadPosition in sf::Packet
Post by: 1aam2am1 on February 27, 2016, 09:19:37 pm: 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?
Title: Re: Add readCurrentReadPosition in sf::Packet
Post by: Ixrec on March 28, 2016, 11:19:30 am: 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.
Title: Re: Add readCurrentReadPosition in sf::Packet
Post by: Hiura on March 28, 2016, 03:01:44 pm: Quote
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.
Title: Re: Add readCurrentReadPosition in sf::Packet
Post by: Ixrec on March 28, 2016, 03:42:26 pm: My preferred solution would be privatize append() in SFML 3, but also take a few features from SFNUL (http://en.sfml-dev.org/forums/index.php?topic=13723.0) 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.
Title: Re: Add readCurrentReadPosition in sf::Packet
Post by: Laurent on March 28, 2016, 04:54:58 pm: Quote
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.

Quote
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.
Title: Re: Add readCurrentReadPosition in sf::Packet
Post by: Cruel on July 10, 2016, 09:22:20 am: 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().