On Thu, Oct 15, 2009 at 11:45 AM, Mika Raento <mi...@iki.fi> wrote:
> I have the protobuf lite code running on Symbian.
> It's around 100k
> which although large by the platform standards, I can live with.
Is this the lite library or the full one? I'd suggest focusing on the lite
library only. You can even drop extension_set.cc from it if you don't need
extensions, in which case it should be very small (the .so is ~65k on
> I'm using ustl (as OpenC, Nokia/Symbian's STL implementation, requires
> a large installation package), which is a bare-bones STL
> implementation. I've augmented it with the missing standard methods
> that protobuf wants.
The lite library hardly contains any STL (especially if you remove
extension_set) other than strings.
> The Symbian libc lacks a number of functions (strtoll, snprintf) which
> can be implemented more-or-less reasonably (using native functions for
> strtoll and APR's vsnprintf).
I'm pretty sure strtoll and snprintf are not used by the lite library, as it
does not include strutil.cc.
> Now for the tricky bits:
> 1. I use gtest but I _am_ using OpenC with that (as I don't mind
> installing extra dependencies for running unittests on my handsets).
> This means that I want to compile protobuf with a different STL than
That might not work since the tests will want to pass STL strings between
the two libraries.
> 2. Aborting on errors is not a nice mechanism for end-user programs
> that potentially deal with corrupt files (battery-powered devices with
> FAT fs...) so I've reimplemented GOOGLE_(D)CHECK in terms of Symbian
> exceptions (I know protobuf isn't exception safe but I'm thinking I
> can deal with the occasional memory leak)
All of the CHECKs are checking things which indicate *programmer* errors.
Corrupt input should *not* trigger any CHECKs (if it did, it would be a
security problem!). So with correctly-written code, you should never have a
problem with these -- and if your code is not correct, basic testing should
reveal it quickly. Also, you should build your releases with NDEBUG
defined, which will make all the DCHECKs go away entirely.
The problem with exceptions is that the library is not exception-safe --
you'll probably get memory leaks or objects left in inconsistent states if
you try to throw exceptions.
> To play nicely with 1 I would like to have all the STL types and
> functions be typedefs/using declarations in another namespace which
> could be redirected, prob. through config.h. This affects both the
> library code and the generated code.
This is a lot to ask just to be able to compile gtest more easily. Does
gtest really need a lot of stuff that isn't in ustl?
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at