I need to use .desc files to enable the reading of serialized protocol-buffer messages and their conversion to JSON (using jansson).
This is because the protocol-buffer message formats will change much more frequently than the C code. The .desc files will be a runtime input to the executable.
I've found https://github.com/Sannis/protobuf2json-c but my reading of this is that it needs C code to be generated. In particular the ProtobufCMessage needs to exist for the message being decoded, and I cannot see a way of making a ProtobufCMessage (from /usr/include/google/protobuf-c/protobuf-c.h) without generating C code.
Have I missed something here, or will I need to write new code?
I'm not familiar with the .desc extension but I'm guessing from the context that it is a file containing a protobuf FileDescriptorProto, defined in google/protobuf/descriptor.proto.
To do what you want, you will most likely need to use the Protobuf C++ or Java library, each of which defines a class DynamicMessage which has the ability to emulate arbitrary message types based on descriptors. You can then combine this with any Protobuf-JSON library that is based on the standard Protobuf reflection interfaces. (You can also write your own JSON converter pretty easily; use the TextFormat class (found in both the C++ and Java Protobuf libs) as a template.)
My understanding is that protobuf-c does not currently contain an equivalent to DynamicMessage.
Related
I have a valid encoded ASN1 binary blob, which I want to modify.
Moreover, I don't have the encoded ASN1's definitions file, but I know it's structure (e.g. let's say it's a sequence that contains few integers and an octet string).
Therefore I'd prefer to modify the encoded binary by iterating over the sequence and it's fields, modify them by setting new values and encoding the new modified binary blob.
How can i do that? i.e. How can I parse the encoded ASN1 binary, modify it and re-encode it in C language? Is there any library that is able to do that?
I'm developing a software module in C for Windows. This is important to note because (in general) many library are Linux oriented and had trouble with building them for Windows.
Thanks.
I used asn1c for this in a past project. You do need the specification: asn1c generates a decoder and encoders based on it. Sounds like in your case it wouldn't be hard to write it.
It will work on Windows. The FAQ claims the compiler now requires GCC and cannot be compiled with MSVC though. You can get GCC for Windows from www.mingw.org or Cygwin.
As you can see above,I want to know how library functions (like printf) are made in C. I am using the borlandC++ compiler.
They are defined in lib files (***.lib), header files only have prototypes.
Lib files cannot be read in text editors.
So, please let me know how they could read?
C is a compiled language, so the C source code gets translated to binary machine-language code.
Because of that, you can't see the actual source code of any given library you have.
If you want to know how it works, you can see if it's an open source library, find the source code of the particular revision that generated the version you're using, and read it.
If it's not open source, you could try decompiling - use a tool that tries to guess what the original source code could have been like for generating the machine code your library has. As you can guess, this is not an accurate process - compiling isn't an isomorphic process - and, as you probably wouldn't have guessed, it could be illegal - but I'm not really sure what conditions it depends on, if any.
I want a program that C program with a C++ form application using together in the same project.
for example:
When I clicked a button send entered text to C program. entered text to inside textBox in a C++ form app.
C program will save the text to computer with file operations.
so simply example:
textBox1="hello world"
button=clicked
string^ message = textBox->Text;
writerFunction(message);
void writerFunction(char m[50])
{
FILE *fp;
fp = fopen("text.txt","a");
fprintf(fp,"%s",m);
fclose(fp);
}
It looks like you are using C++ .NET (managed c++)
I'm guessing this from pointer operator. In standard c++
you would use '*' instead of '^'.
Please correct my if I'm wrong there.
Two options.
you are using managed c++ so you can call Win32 API but you will make your work harder. If you still intrested please check this link. It will get you started.
http://www.codeproject.com/Articles/9714/Win-API-C-to-NET
But I'd suggest you to use c++ .NET approach to save the string in file. Google will find many examples for you.
One to start:
http://msdn.microsoft.com/en-us/library/19czdak8.aspx
if you want to use old style c++ you can mix c and c++ without any problems. You will need to import libs to your project.
Libraries:
C
- stdio.h examples here (http://en.m.wikipedia.org/wiki/C_file_input/output)
C++
-ofstream: Stream class to write on files
-ifstream: Stream class to read from files
-fstream: Stream class to both read and write from/to files.
More details here: http://www.cplusplus.com/doc/tutorial/files/
Windows API
- you can use win32 API by importing header
Windows.h
Few examples here (http://www.daniweb.com/software-development/c/threads/31282/windows-api-functions-to-read-and-write-files-in-c)
Good luck. If you need more info please let me know.
The simplest way is just embed your C code in C++. It should work, unless any platform specific thing barrier you.
If you do need to have two (or more) programs and if they should run as two different processes in the OS, you should use a proper inter process communication technique. I know nothing about .Net stuff. However, you may use pipes, shared memory, memory mapped files and even sockets work too.
Or else, you can create a dynamic library based on C and call the function in your C++ form application.
What is the preferred library for parsing XML data in Pure C?
The canonical XML parsing library for C is libxml2.
Two popular choices are expat and libxml2.
Here is a list of libraries for multiple languages, including C:
http://www.xml.com/pub/rg/XML_Parsers
Not 'the preferred library', but there's also http://www.minixml.org/.
Mini-XML is a small XML library that
you can use to read and write XML and
XML-like data files in your
application without requiring large
non-standard libraries. Mini-XML only
requires an ANSI C compatible compiler
(GCC works, as do most vendors' ANSI C
compilers) and a 'make' program.
Mini-XML supports reading of UTF-8 and
UTF-16 and writing of UTF-8 encoded
XML files and strings. Data is stored
in a linked-list tree structure,
preserving the XML data hierarchy, and
arbitrary element names, attributes,
and attribute values are supported
with no preset limits, just available
memory.
VTD-XML is the one you should look into, if you want a combination of ease of use, performane and efficiency
You can consider miniML-Parser, a simple and tiny XML parser library in C. It is specifically developed for embedded applications in mind.
It is extremely easy to use: You need to call only one API to parse your XML data
It has a very small footprint: The parser uses only 1.8 kB1 of code memory. Hence, you can use it in very small embedded applications.
It is a validating XML parser.
It also extracts the content of XML data and converts it to its specified data type.
It comes with a tool to generate the source code from XML schema file, instead of manually writing XML tree structure in C.
Disclosure: I'm author of this miniML-Parser
Is there a way to point Ruby FFI to a header file instead of writing attach_function calls? A header file basically has the same exact information.
temp_convert.rb:
attach_function :temp_convert, [:float], :float
temp_convert.h:
float temp_convert(float temp);
Because C header files are written in C but Ruby interpreters only interpret Ruby. Also, the header files might not even be available at runtime.
There has been talk about automatically generating attach_function calls from headers. However, as I hinted at above, this basically means that you must implement a full C compiler (well, the full front half of one, to be precise). At the moment, the Ruby implementers are more focused on making Ruby run as fast as C to alleviate the need to use FFI in the first place than writing their own C compiler (which is a non-trivial undertaking even though you only need to do the lexing, parsing, semantic analysis and typing parts, not the actual code generation or optimization).
As Jörg says, implementing a header scanner means implementing quite a bit of the C compiler, to get everything right.
One thing you might like to try to ease the pain is the FFI Swig Generator. It uses swig to generate the FFI interface. It still means you need to do a bit of work, which can boil down to a cut'n'paste job to generate the swig input file for simple interfaces.