hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has joined #ste||ar
hkaiser has quit [Quit: Bye!]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 256 seconds]
K-ballo1 is now known as K-ballo
Yorlik has joined #ste||ar
gdaiss[m] has quit [Quit: You have been kicked for being idle]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 246 seconds]
K-ballo1 is now known as K-ballo
hkaiser has joined #ste||ar
gdaiss[m] has joined #ste||ar
<Yorlik>
What would be the best way to make template specializations depending on the endianness of the host system in C++17?
<hkaiser>
use the std::endian enum class values to specialize things (std::endian::little and std::endian::big)
<Yorlik>
I assume this only works correctly on little endian systems (for a vector of uint8_t, size 8): uint64_t resultnum = *reinterpret_cast<uint64_t*>(vec.data());
<hkaiser>
hpx serialization supports endian-conversions, if needed, btw
<Yorlik>
It's part of a variable length integer compression.
<Yorlik>
I need to AND away illegal data - it's dangerous code but probably pretty fast.
<Yorlik>
hkaiser: It's at the uncompressed packet level before any deserialization happens.
<hkaiser>
Yorlik: I'd suggest to handle endianness on an as low as possible level, that relieves you from even thinking about it
<Yorlik>
Yep. It actually is our lowest level.
<Yorlik>
Every packet we use get's a length compressed integer sequence number.
<hkaiser>
but it makes sense only when handling real types entities, doesn't make sense to do it on a byte stream as you don't know where an entity starts inside that stream
<Yorlik>
It's in the packet header, which also is variable length.
<Yorlik>
The first byte encodes type and sequence number bytecount.,
<hkaiser>
packet headers should always be in a defined endianess
<hkaiser>
regardless of the target system's endianess
<Yorlik>
Yes. That's why I need to make the function depending on the endianness of the sender
<Yorlik>
So we have a defined state in the packet.
<Yorlik>
The buffers lowest byte is the least significant bits of the integer
<hkaiser>
well, then specialize of std::endian::native == std::endian::little or std::endian::native == std::endian::big, whatever you need
<Yorlik>
How would you do that? I'm kinda blocked. The template specialization is not automagically used when I try to invoke the function.
<Yorlik>
like convert(x) is not chosen depending on the host endianness
<Yorlik>
If the specialization is convert<std::endian::native==std::endian::little>(x)
<Yorlik>
ADL won't work here.
<Yorlik>
Would I have to use SFINAE in this case?
<hkaiser>
or do convert_if_needed(x, std::integral_constant<bool, std::endian::native==std::endian::little>{}); and provide two overloads on std::true_type and std::false_type
<hkaiser>
or a simple if constexpr(std::endian::native==std::endian::little) {} else {}
<Yorlik>
IC. I guess my type traits are a bit rusty :)