Location: Toronto, Ontario
Remote: Yes and Hybrid
Willing to Relocate: No
Technologies: C/C++, FPGA, SystemVerilog, AI ML Inference, AI Compiler, Hardware Architecture, Python, CMake/general infrastructure
Résumé/CV: https://www.linkedin.com/in/petercdmclean
Email: peter at mcl.ean.email
Mixed hardware/software experience. Experience in technical leadership role. Looking primarily in AI compiler area but am open to other roles.
You can inherit from bit_array and create a pseudo bitfield:
class mybits_t : bit::bit_array<17> {
public:
// slice a 1 bit sized field
// returns a proxy reference to the single bit
auto field1() {
return (*this)(0, 1);
}
// slice a 3 bit sized field
// returns a proxy reference to the 3 bits
auto field2() {
return (*this)(1, 4);
}
};
mybits_t mybits(7);
assert(mybits.field1() == 1);
mybits.field1() = 0;
assert(static_cast<int>(mybits) == 6); //no implicit cast to integers, but explicit supported
There is minimal overhead depending on how aggressively the compiler inlines or optimizes*
Only similar by a little bit. Bitset misses the mark in so many ways.
bit_array can be compile time storage (ala bitset) or dynamic at construction time. There is also bit_vector which is entirely dynamic
Critically though, is that the type/library is built on a proxy iterator/pointer that lets you do certain things with STL or the bit algorithms that you cannot otherwise do with bitset.
But back to the bitfields idea. The bit array backing storage is configurable through templates so you will be able to know for certain exactly how much stack or heap your type will take up