3 ms·
Interestingly, the idea of hashing over the bytes of a data structure would be possible in C++, but it is non-idiomatic and instead one would use hash functions
by blub 8y ago
Interestingly, the idea of hashing over the bytes of a data structure would be possible in C++, but it is non-idiomatic and instead one would use hash functions for each type and in the case of a struct the individual members would be accessed to build the hash value.
The idea of using bytes is error-prone, but now that you mentioned it, pretty typical of the C mindset.
Of course C++ also has some of these cultural biases. I think they're an important reason why unsafe code continues to be written.
- pjmlp 8y agoIn C++, it depends from which tribe you came from. The safe programming tribe, which I include myself, usually refugees from Wirth languages, makes use of C++ abstractions and type safety to deal with unsafety, including type driven development. Meaning heavy use of templates, type wrappers, STL (or standard library if you prefer) data types, pre-processor only for #include and yes some meta-programming as well. Then there is the tribe of C refugees, whose C++ compiler was forced on them due to a platform SDK, usually eschew anything standard. Might write some C++ like code due to interop with the SDK APIs and that's it. Naturally there are a few tribes in-between, but these are the two major groups.
- bluecalm 8y agoI object to reinterpreting bytes of one object as object of another type being C mindset. Yes, this is done sometimes if you really need it (compression being one example) but it's not really something you write everyday in C and doing it to calculate hash is just lazy.
- amluto 8y agoExcept that hashing a block of memory is likely to be much faster than hashing individual fields once there are more than a couple fields. IMO the right solution would be a special annotation on a struct that says “I want the logical value of this struct to uniquely determine the bytes of the struct’s in-memory representation.” Of course, adding such an attribute without nasty edge cases may be tricky.
- Tarean 8y agoBut this mostly matter for arrays and then an alternative optimization might be to store it as a structure of arrays. This doesn't need the padding and is more simd friendly.
- blub 8y agoThe C mindset is one of always looking for optimisations and thinking at the bit & byte level. The above solution flows naturally...
- jibal 8y ago"Interestingly, the idea of hashing over the bytes of a data structure would be possible in C++, but it is non-idiomatic" Because it's not conformant. Those possible C++ programs are broken.
- blub 8y agoI was making a point about language culture and decision making. Conformance is a property of the code, the programmer's decision process is the really interesting thing here to me and I was arguing that such a solution is not unusual for C, but it would be for C++ , where a programmer would avoid it not because it's not conformant, but because it looks odd. pjmpl further clarified that it depends on the type of C++ programmer - I agree.
- jibal 8y agoNon conformant code doesn't become an idiom, because it's broken. If you want to wrap that in a cultural framework, go ahead, but it rather misses the point. > I was arguing that such a solution is not unusual for C You may have asserted that (funny how people call their unsupported assertions "arguments"), but you're wrong if so. Again, it's broken, in C just as much as C++. You wrote > instead one would use hash functions for each type and in the case of a struct the individual members would be accessed to build the hash value. But this is just as much true in C as C++, because hashing pad bytes is wrong. In fact, C programmers are probably more aware of this than C++ programmers.