Robert Stewart wrote:
I could make it more helpful; but then it would be called swap_in_place and would be implemented just like Tomas'!
Yours would still be in terms of the endian types.
What inteface would you suggest?
--- typed based --- for (int trial=0; trial != 1000; ++trial) { { ifstream input("array.dat", ios::binary); input.read(reinterpret_cast<char*>(&tmp_array), sizeof(tmp_array)); interface::copy(tmp_array.begin(), tmp_array.end(), array2.begin());
Does this actually swap anything? Doesn't this just copy the data to unswapped objects that *would* swap on access? That's hardly a fair comparison.
array2 is just a plain array<uint32_t, SIZE>. tmp_array is an array<endian<big, uint32_t>, SIZE>. So the conversion/copy happens in interface::copy.
I don't think that's right. The copy is done in interface::copy(), but the conversion (swap) doesn't occur until you read from the endian objects, right?
Not right. The conversion happens inside of interface::copy which is performing a swap-in-place in this example. After the call to interface::copy, array2 is in native-endian format. Both tests convert the disk file to native-endian format in memory, so no other comparison is really necessary after the conversion, other than the memcmp to verify that the conversion worked.
My point is that you need to walk the array summing the values, or something, to read each value at least once. Otherwise, your code merely copies the data as read from disk to the endian objects but doesn't swap any bytes, and yet you compare that to function-based code that does swap.
I think the memcmp does that. terry