Endianness en lenguajes de programación

Question

Bueno, el tema "Endianness" siempre me resultaba un poco confuso, pero nunca me he enfrentado a ningún problema que requiriera siquiera pensar en el comportamiento predeterminado de los escritores/lectores binarios que he usado. Estoy escribiendo un decodificador PNG en C# en este momento. La especificación de formato de archivo PNG establece que todos los números se almacenan en una notación big endian (que me parece muy natural). Sin embargo, me sorprendió mucho cuando me di cuenta de que .NET's BinaryReader/Writer funciona con una pequeña notación endian. Lo que me confundió aún más fue el hecho de que el IO binario de Java funciona con una notación big endian (no soy un programador de Java, así que tal vez estoy equivocado). Entonces comencé a pensar en las siguientes preguntas:

1 - ¿Por qué son las cosas como son? Me refiero a un comportamiento predeterminado de la Biblioteca de clases base. 2 - ¿Por qué no hay forma de elegir una notación preferida cuando se usa System.IO de .NET?

Actualmente estoy usando Jon Skeet'sMiscUtil y funciona como un amuleto (gracias, man =)). Pero sería genial ver esta funcionalidad en una biblioteca de clases base.

Answer 1

Esto se debe a que el código debe ejecutarse lo mejor posible en la plataforma más importante. C# /. NET es de Microsoft y se ejecuta principalmente en plataformas x86. x86 es little-endian, por lo que tiene sentido hacer que la biblioteca sea poco endiablada. Java está hecho por Sun, y Sun SPARC era big-endian, por lo que el estándar Java era big-endian.

Answer 2

El BCL contiene elementos en la clase estática System.BitConverter que le permiten lidiar con la permanencia del sistema. Todos los métodos en BitConverter son esencialmente agnósticos de plataforma como resultado.

Además, el método System.Net.IPAddress.NetworkToHostOrder le permite cambiar la endianidad de grande a pequeño endian, y viceversa.

Answer 3

supongo que se reduce a siempre ser capaz de hacer frente a tanto, independientemente de la plataforma que se encuentra. Preon está tratando de ocultar parte de esa complejidad permitiéndole declarativamente (usando anotaciones) definir la correspondencia entre su representación de datos en memoria y la representación codificada.

Así que si esto es parte de la estructura de datos:

public Image { 
    int width; 
    int height; 
} 

continuación, definir el mapeo a una representación big endian natural sería tan fácil como esto:

public Image { 
    @BoundNumber int width; 
    @BoundNumber int height; 
} 

Sin embargo, si la representación es poco endian, entonces usted puede hacer esto:

public Image { 
    @BoundNumber(byteOrder=LittleEndian) int width; 
    @BoundNumber(byteOrder=LittleEndian) int height; 
} 

En ambos casos, la creación de una Codec para esta estructura de datos es el mismo:

Codec<Image> codec = Codecs.create(Image.class); 

Sé que algunas personas estaban hablando de portar esta a .NET también.