Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Add readCurrentReadPosition in sf::Packet  (Read 7081 times)

0 Members and 1 Guest are viewing this topic.

1aam2am1

  • Newbie
  • *
  • Posts: 13
    • View Profile
Add readCurrentReadPosition in sf::Packet
« 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.
« Last Edit: March 02, 2016, 06:18:53 pm by 1aam2am1 »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Add readCurrendReadPosition in sf::Packet
« Reply #1 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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

1aam2am1

  • Newbie
  • *
  • Posts: 13
    • View Profile
Re: Add readCurrendReadPosition in sf::Packet
« Reply #2 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?

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Add readCurrentReadPosition in sf::Packet
« Reply #3 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.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Add readCurrentReadPosition in sf::Packet
« Reply #4 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.
SFML / OS X developer

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Add readCurrentReadPosition in sf::Packet
« Reply #5 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 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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Add readCurrentReadPosition in sf::Packet
« Reply #6 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.
Laurent Gomila - SFML developer

Cruel

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Add readCurrentReadPosition in sf::Packet
« Reply #7 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().
« Last Edit: July 10, 2016, 09:24:38 am by Cruel »