If you don't care about the API, why not just use protobuf-c from C++?
If you take away the accessor API, I don't see what C++ gets you.
It's true that the enum descriptor could probably be eliminated... i
was mostly paralleling the c++ api... BUT I like it, cause it could be
useful for language
On Apr 21, 11:42 am, Wink Saville w...@google.com wrote:
Maybe I'll do this too:) But could you give me some insight on how you
use the enum descriptor, maybe I'm missing something. All I want to
do is have a structure defined and be able to serialize and deserialize
that structure. That's
Frankly I'm surprised so many people care about the generated code
size - I'm generally much more interested in speed.
For example, I suspect your C unpack() could be optimized quite a bit
by using a custom allocator. Another example: probably the only
change I'm likely to make to protobuf-c in
I appreciate this, as i've been wanting to see some benchmarks between
the implementations for a long time. Of course, as a C advocate (i'm
the author of protobuf-c), I'm hoping (and frankly expecting) that
it'll win in the size AND speed category.
I also like the style of separating the test
Large complex systems are exactly why LDFLAGS and CFLAGS are better...
you can set them ONCE and build the entire system to another
location. do you really want to do --lib-a=$PREFIX --lib-b=$PREFIX
for 50 libraries for 50 packages?
- dave
On Mar 4, 1:31 am, Antony Dovgal t...@daylessday.org
Perhaps you could use protobuf-c which uses global variables for its
metadata and hence has no leaks upon unload (as long as you free all
your messages of course).
- dave
On Mar 4, 4:08 am, Ivan Kharin korsar.ak...@gmail.com wrote:
I'm using protocol buffers in my project (C++), and while I
Well, it seems like all your technical problems will be solved by my
configure check -- which will nicely tell the user that the need to
install protobuf or modify their CFLAGS/LDFLAGS.
I'm sorry that you prefer a custom option to the standard automake
solution- as a maintainer [*], i disagree.
I have made a patch; i hadn't committed (or fully tested) it yet. --
but so it can be reviewed i committed it:
http://code.google.com/p/protobuf-c/source/diff?spec=svn168r=168format=sidepath=/trunk/configure.ac
I have a few other little fixes (issue 15 and some rpc/tcp fixes) and
so on i
Apparently (via private correspondence), using machine/endian.h
instead of mach/endian.h worked -- so i added that to the list of
endianness-detection headers.
I dunno if there's some sort of FAQ on xcompiling protobuf, but there
is a general problem that the protoc_c compiler must be runnable
It seems like you should be using
CXXFLAGS=-I/my/install/path/include \
LDFLAGS=-L/my/install/path/lib \
./configure
instead.
--with-libdir is fairly ambiguous with --libdir (a standard automake
option which defines where to put libraries, rather than where to look
for them).
Perhaps
Without the actual config.log it's hard to tell what's going on. You
may send it to me privately if you want.
If you have a working endian.h or mach/endian.h, we shouldn't need
to run a test program. but i have never written an iphone app, so i
have really no idea if they have such a header.
protobuf-c now has an rpc implementation, check it out:
http://code.google.com/p/protobuf-c/wiki/RPC_System
On Feb 10, 10:19 am, sagar.i...@gmail.com wrote:
any plans on extending this to C?
looking for a simple cross-language client-server library.
I guess i should mention a few design features of the protobuf-c api:
- completely introspectable
- able to wrap into another application's main-loop
I think those features should make it easy to write a language binding
to it.
I am considering someday improving it to be able to create a
13 matches
Mail list logo
