Thanks for your feedback Kenton! 2009/10/15 Kenton Varda <[email protected]>: > On Thu, Oct 15, 2009 at 11:45 AM, Mika Raento <[email protected]> wrote: >> >> I have the protobuf lite code running on Symbian. > > Neat. > >> >> 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 > Linux/x86).
It's the lite one and I'm indeed compiling in extension_set + it's pulling in more of ustl than my code was using. I'll try to find out the exact size but I'm happy enough with even 100k (the non-lite version size was a show-stopper on Symbian - thanks a lot for the lite version!). > >> >> 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. They aren't, but the extension set unittests require the full library so I needed to get that to compile (and good thing I did as it showed that ustl had a non-compliant string::erase(size_t pos, size_t n) - it had n default to 1 rather than npos, which made symbol lookups fail, bah). > >> >> 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 >> gtest. > > That might not work since the tests will want to pass STL strings between > the two libraries. That's not a problem as gtest doesn't care about the types you use as long as they are comparable (and streamable). > >> >> 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 Hm. You are right. I may want to revisit that. I was hitting a CHECK because of the symbol lookup failure. (I know Google's policy on exceptions and I don't agree :-) - I think even programming errors should not lead to aborts) > >> >> 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? Sure, I agree on it being a lot. Gtest does use a lot more of stl and it needs a much more compliant one. I would not look forward to trying to get it to work with ustl - getting it to work on Symbian at all took me and Wan a long time. I'll try to separate some of my changes to make it easier for other people to get started (at least the mutex ones). Mika --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
