I'm using the enet network library to make my game utilize both TCP and UDP.
The site explicitly states that Enet is a UDP networking library. For TCP you will have to use something else.
Is there a reason why you don't use SFML, do you need certain features?
If you only need to serialize standard C++ scalar types then std::stringstream should be fine. That class' interface is exactly what you appear to want sf::Packet's to be.
Why
std::stringstream? I would serialize data over network as binary data and not text, otherwise you're quickly wasting a lot of bandwidth.
Although you can use stringstreams for binary data, you'll have to use the
read() and
write() functions, which are not only less convenient than
<< and
>>, but also don't provide a portable binary format.
"converting to bytes" sounds like you want to do serialization. sf::Packet has absolutely nothing to do with serialization.
If you'd want to use sf::Packet with something else than sfml-network, you'd have to implement the sf::Packet protocol yourself, which is not recommended, since that protocol is an internal detail, which could change any time.
Not necessarily. As far as I've understood Honorabl3, he wants to use
sf::Packet because it provides a conversion between formatted data (integers, double, bool, etc) and a byte array. In that way,
sf::Packet does provide some kind of serialization, it just does not guarantee anything about the internal format or its stability over different SFML versions. Those limitations, however, are not an inherent obstacle as long as you're aware of them.
When looking at Enet, it seems to provide
only low-level packet functions, which forces the user to re-invent the wheel. The idea of using an existing abstraction is thus standing to reason. The
sf::Packet class does not provide a sophisticated streaming API, but it has the functions
getData(),
getSize() and
append() which allow conversion between formatted data types and byte arrays.