On Tuesday, October 31, 2023 8:23:28 AM MDT Salih Dincer via Digitalmars-d- learn wrote: > On Tuesday, 31 October 2023 at 10:24:56 UTC, Jonathan M Davis > > wrote: > > On Tuesday, October 31, 2023 4:09:53 AM MDT Salih Dincer via > > > > Digitalmars-d- learn wrote: > >> Hello, > >> > >> Why isn't Endian.littleEndian the default setting for read() in > >> std.bitmanip? > > > > Why would you expect little endian to be the default? The > > typical thing to do when encoding integral values in a > > platform-agnostic manner is to use big endian, not little > > endian... > > Because when we create a structure with a Union, it does reverse > insertion with according to the static array(bytes) index; I > showed this above.
I fail to see what the situation with the union has to do with anything. Sure, you can convert between an array of bytes and an int with a union if you want to, but what that does is going to be dependent on your local architecture. read and its related functions in std.bitmanip are architecture-independent. So, they will convert from little endian or big endian regardless of what your local architecture is. You would typically use it on ranges of bytes that come from the network or from serialized data. The most common scenario there is likely to be that they'll be in big endian, because that's what platforma-independent binary formats typically do, but you can explicitly tell read that the range is in little endian if your range of bytes happens to be in little endian. Both scenarios can occur, and it supports both. It just defaults to big endian, because that's the more common scenario when dealing with binary formats. > I also have a convenience template like this: > ```d > template readBytes(T, bool big = false, R) > { // pair endian version 2.0 > import bop = std.bitmanip; > > static if(big) > enum E = bop.Endian.bigEndian; > else > enum E = bop.Endian.littleEndian; > > auto readBytes(ref R dat) > => bop.read!(T, E)(dat); > } > ``` > Sorry to give you extra engage because I already solved the > problem with readBytes(). Thank you for your answer, but there is > 1 more problem, or even 2! The read() in the library, which is > 2nd function, conflicts with std.write. Yeah, there are many > solutions to this, but what it does is just read bytes. However, > you can insert 4 ushorts into one ulong. > > Don't you think the name of the function should be readBytes, not > read? Because it doesn't work with any type other than ubyte[]! D's module system makes it so that names do not need to be unique across modules, and this is not the only case in Phobos where multiple modules use the same function name. It's easy enough to import only the functions you're using or to rename them via the import if you happen to be importing from multiple modules containing functions with the same name. E.G. if you want to do std.bitmanip : readBytes = read; then you can. - Jonathan M Davis