Have you looked at protobuf-c at all? Maybe it comes closer to your needs? On Mon, Sep 28, 2009 at 3:48 PM, Andrzej Zawadzki <a.zawad...@gmail.com>wrote:
> I think safe WinCE protobuf usage is currently impossible due to two > main reasons: > 1. Assumption done in protobuf implementation that memory allocation > will never fail. > 2. Lack of default throwing new implementation on the platform. > > The first issue is a general one, not connected exclusively to Win CE > port. One would need to either reach std::bad_alloc exception safety > or add necessary error code handling. I don't have the necessary > knowledge about the library internals to assess whether such a change > is feasible at all. However, at first glance it seems that the library > would only require a detailed review and not a complete rewrite to > reach exception safety. > Well, one problem here is that inside Google we run with C++ exceptions disabled. So, adding try/catch blocks to the code may cause it to not compile in our environment, which would be a non-starter. We'd have to implement all exception safety in terms of stack variables with intelligent destructors, which might be unwieldy. Another problem is that because we don't use C++ exceptions, people making changes in the future will probably break exception safety. Policing this will be hard. How would we test this? On the bright side, presumably we'd only have to look at the lite runtime, which makes things much easier. > Solution c) requires that all the vectors, strings, hash_maps etc. are > parametrized with an additional typedefed template parameter. By > default, it can be std::allocator or a custom one if needed. > Additionally, "new" calls would need to be changed to some > custom_new_operator(type, params) calls (also with platform specific > implementation). The compiler would in turn produce different versions > of the pb.* files for WinCE and "normal" systems. On WinCE you could > have std::basic_string<char, some_throwing_allocator>, on Win/Lin/Mac/ > whatever: a plain std::string. > This won't fly. Changing every string to some other type will obviously break all current users, and they are not going to appreciate using some new string type instead since it's probably not interoperable with other code. That said, I think that if you're using the lite runtime and don't use extensions, and you're careful about what you call, you could get away with your only STL use being strings in generated classes. We could consider adding a ctype option for an alternate string representation that works better for you, although this is still rather invasive. protobuf-c may be the way to go... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
