digitalmars.D - Deimos submission - Nanopb
- Nick Sabalausky (3/3) Oct 31 2012 I've got some bindings for Nanopb I'll like to contribute to Deimos:
- Jacob Carlborg (4/7) Nov 01 2012 You should have a short description of the C project as well.
- Nick Sabalausky (6/15) Nov 01 2012 (From the C project's website:)
- Kagamin (2/2) Nov 01 2012 Why pb and exi chose to use little endian to encode numbers, I
- Jacob Carlborg (5/7) Nov 01 2012 Isn't little endian standard when sharing the bytes, i.e. transferring
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/11) Nov 01 2012 No, that's actually big endian.
- Jacob Carlborg (4/5) Nov 01 2012 Right, I always get these endians mixed up.
- David Nadlinger (5/7) Nov 01 2012 You avoid having to flip the byte order at the application level
- Kagamin (11/14) Nov 01 2012 Yes for platform native numbers, but not for ULEB - which is
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
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/nanopbYou should have a short description of the C project as well. -- /Jacob Carlborg
Nov 01 2012
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> On Thu, 01 Nov 2012 09:07:39 +0100 Jacob Carlborg <doob me.com> wrote:On 2012-11-01 06:38, Nick Sabalausky wrote:(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.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/nanopbYou should have a short description of the C project as well.
Nov 01 2012
Why pb and exi chose to use little endian to encode numbers, I wonder. Isn't big endian faster to read?
Nov 01 2012
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
On 01-11-2012 12:59, Jacob Carlborg wrote:On 2012-11-01 11:37, Kagamin wrote:No, that's actually big endian. -- Alex Rønne Petersen alex lycus.org http://lycus.orgWhy 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?
Nov 01 2012
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
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
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