www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deimos submission - Nanopb

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
Oct 31 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Nov 01 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Nov 01 2012
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
Why pb and exi chose to use little endian to encode numbers, I 
wonder. Isn't big endian faster to read?
Nov 01 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 01 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Nov 01 2012
parent Jacob Carlborg <doob me.com> writes:
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
Nov 01 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Nov 01 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
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.
Nov 01 2012