I've got some bindings for Nanopb I'll like to contribute to Deimos:

Original C project: http://koti.kapsi.fi/jpa/nanopb/

My D Bindings: https://github.com/Abscissa/nanopb

On 2012-11-01 06:38, Nick Sabalausky wrote:
> I've got some bindings for Nanopb I'll like to contribute to Deimos:
>
> Original C project: http://koti.kapsi.fi/jpa/nanopb/
>
> My D Bindings: https://github.com/Abscissa/nanopb

You should have a short description of the C project as well.

-- 
/Jacob Carlborg

On Thu, 01 Nov 2012 09:07:39 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-01 06:38, Nick Sabalausky wrote:
> > I've got some bindings for Nanopb I'll like to contribute to Deimos:
> >
> > Original C project: http://koti.kapsi.fi/jpa/nanopb/
> >
> > My D Bindings: https://github.com/Abscissa/nanopb
> 
> You should have a short description of the C project as well.
> 

(From the C project's website:)

Nanopb is an ANSI-C library for encoding and decoding messages in Google's Protocol Buffers format with minimal requirements for RAM and code space. It is primarily suitable for 32-bit microcontrollers.

Why pb and exi chose to use little endian to encode numbers, I wonder. Isn't big endian faster to read?

On 2012-11-01 11:37, Kagamin wrote:
> Why pb and exi chose to use little endian to encode numbers, I wonder.
> Isn't big endian faster to read?

Isn't little endian standard when sharing the bytes, i.e. transferring across networks?

-- 
/Jacob Carlborg

On 01-11-2012 12:59, Jacob Carlborg wrote:
> On 2012-11-01 11:37, Kagamin wrote:
>> Why pb and exi chose to use little endian to encode numbers, I wonder.
>> Isn't big endian faster to read?
>
> Isn't little endian standard when sharing the bytes, i.e. transferring
> across networks?
>

No, that's actually big endian.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 2012-11-01 14:04, Alex Rønne Petersen wrote:

> No, that's actually big endian.

Right, I always get these endians mixed up.

-- 
/Jacob Carlborg

On Thursday, 1 November 2012 at 10:37:19 UTC, Kagamin wrote:
> Why pb and exi chose to use little endian to encode numbers, I wonder. Isn't big endian faster to read?

You avoid having to flip the byte order at the application level on the prevalent (at least in the domain where protobuf is used) architectures that way.

David

On Thursday, 1 November 2012 at 15:23:35 UTC, David Nadlinger wrote:
> You avoid having to flip the byte order at the application level on the prevalent (at least in the domain where protobuf is used) architectures that way.

Yes for platform native numbers, but not for ULEB - which is platform-independent and is read by the same (source) code on all platforms AFAIK. I see no gain for little endian platform here: registers work the same on BE and LE platforms. One could even say ULEB is intentionally incompatible with any platform so that you don't mess things up in homogeneous environment writing native ints into stream (which will break in heterogeneous environment). This was a design choice for exi to use ULEB for strings too instead of utf8.