You should name it “Gazelle Forever”.
I kid
104649 items (96858 unread) in 19 feeds
Friends
(992 unread)
Build
(67517 unread)
Heads
(712 unread)
News
(27430 unread)
fun
(207 unread)
You should name it “Gazelle Forever”.
I kid
I vote to stick with C for another reason, integration with other languages. If your project is a nice C library, it’s vastly easier for people using other languages, C, Python, whatever, to interface with your library rather than having to re-implement it.
C++ is imo an awful choice for a library because it ends up restricting this to other things written in C++ (unless of course you wrap it up in a C abi but that is messy).
I’d prefer a base in C with a C++ wrapper as required.
GCC 4.5 should get link-time optimization which will hopefully help binary size a lot. ultimately though, i still find myself reaching for C, for the ease of binding to other languages and the smaller size. i still like to keep my code C++ compatible and run it through the C++ compiler occasionally though, just because it’s much stricter on typing.
I have a hard time accepting the comment that C++ compilers aren’t very good at keeping things small. Which compiler have you used? I would agree that C++ nuances are complicated and that you need to read volumes of books to better grasp the details of optimization.
I’ve also been lazily contemplating upb for use in my projects. Since I tend to write my code in strange languages like D and Haskell, I’ll second the other’s comments! I would not mind having a thin C++ wrapper though.
great choice!
Have you checked with the security team about this yet? C++ might reduce the number of potentially unsafe manual casting that goes on in the code, but it also introduces a whole host of (often very subtle) security risks of its own… (For example, see: [chargen.matasano.com] and some of the links there) Depending on how much you’re planning on changing — and depending on your security folks — it might well be faster to tighten up the current codebase than to rewrite it. (It’s been a little while since I looked at the code, and I certainly haven’t tried to do a formal review, but I didn’t notice too many scary things going on in there…)
On a more selfish note — I too was eyeing upb for use in a (pure C) project of mine, and would just as soon see it stay C… So take my comments with a grain of salt.
-sq
assuming the generated C code is good, why not?
thanks!
@Alejandro: Wow, I didn’t realize there was already someone wanting to use upb on an embedded platform! I definitely want to keep supporting your use case if I can. I think the best way forward will be for me to get a C++ to C translator like Comeau C++. Then I can keep writing in C++, but ship C files that you can build with a plain C compiler. Do you think that will work for you?
@Josh: Hi! You mentioned my reason… I work on a CXX-free embedded controller. Moving from ASN.1 to protocol buffer at IPC (hate threads) level thanks to your awesome upb and I was starting to write the Lua bindings to finish the migration integrating the http front-end and some Lua based helpers running inside the controller. So porting ucb to C++ because will hit me… badly
… your implementation is great!. I understand porting it to C++ will save you some lines… but maybe some refactoring can help to reduce the complexity without having to switch to C++? you can do all the bindings you aim keeping it in C… with all it’s current benefits
@Alejandro: If you want to influence my decision, you should tell me why you don’t want me to.
I definitely have resisted, but practical reasons are demanding that I do. But maybe you are thinking of practical reasons that I’m missing.
please don’t :’(