On Apr 21, 11:42 am, Wink Saville 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 what I thi
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
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 da
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 runna
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=svn168&r=168&format=side&path=/trunk/configure.ac
I have a few other little fixes (issue 15 and some rpc/tcp fixes) and
so on i w
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.
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 wrote:
> > I'm using protocol buffers in my project (C++), and while I was
> > hunting for me
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 wrote:
> On 03.03.200
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 or , 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.
If they don't have any
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 thi
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
Pro
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 think this is a fairly classic cygwin bug: not using enough $
(EXEEXT)'s in your Makefile(.am)s. The needed patch is likely:
-generated-code/test-full-cxx-output.inc: cxx-generate-packed-data
+generated-code/test-full-cxx-output.inc: cxx-generate-packed-data$
(EXEEXT)
(and one similar change
14 matches
Mail list logo