see i m writing one avi demuxer library. In which i have exported multiple API to do different functionality. NOw when 1st time one aviopen() is called with i/p filename, i parse whole file & save some info in some structure which i have malloc. now when again any API is called for that file should use that structure's info & do some work.
i DO NOT want to expose those structure to library user. even i DO NOT want no give him the pointer of that structure. In that case how can i keep the track of that structure???
i also want to give multiple file support in my library so if any application wants to open more than one file at a time then he can do that.
so here how can i maintain handle of each opened file for allocated structure?
An opaque pointer is the usual way to implement this.
If you don't want to pass a pointer at all for some reason, you could keep a global ("private") array/hash of your structures, and give your users an index in that global container (could be a plain int). That's much more work (and much more failure-prone and potentially racy) than just handing out opaque pointers though.
Related
I have a piece of code using a FILE* file with a fwrite:
test = fwrite(&object,sizeof(object),1,file);
I want to serialize some internal data structure with an indexing structure (so, I'm using neither Google's Protobuf nor Cap'n Proto, since that is a custom data structure with some specific indexing requirements). Now, inside my project, I want to use Google Test in order to test the serialization, in order to check that what it has been serialized it could be deserialized and easily retrieved, too. In the testing phase, I want to pass to fwrite a FILE* object which is not a file, but a handler to some allocated main memory, so that no file is procuded, and that I can directly check the main memory for the results of the serialization. Is it possible to virtualize the FILE* and to write directly into the main memory? I would like to keep fwrite for writing data structures for performance reasons, without being forced to write two different methods for serialization (Sometimes i'm writing on the fly with no further memory occupation for transcoding). Thanks in advance.
One way is to create a dynamic library with all those fopen/fwrite functions (that would do something for your magic filename and fall back to the original ones otherwise) and load it with LD_PRELOAD. To fall back to the originals, resolve them with "dlsym" and RTLD_NEXT.
Another way is to include a special header at the top of the library/test which would have a statement like "#define fopen my_fopen". Inside the file with the implementation of "my_fopen" you need to put "#undef fopen" before including original "stdio.h". This approach will only work for your source code files that include the header but will not hook the functions for the binary libraries that you link.
fopencookie did the job I was looking for.
http://man7.org/linux/man-pages/man3/fopencookie.3.html
Can I Create FILE Instance (FILE*) by byte[ ] data (on Memory)? Don't Write file.
(C, Linux)
I Need for 'MiniSEED' format data parsing by offical MiniSEED Library.
These Library is supported parsing 'MiniSEED' format packet Data that was written in file.
But I Need to parsing 'MiniSEED' data in Byte[] array directly. don't create real file.
(because I must get 'MiniSEED' data by realtime TCP Packet, continuously
and These Library support only way to parse data by written file.)
So I try to solve the problem Created FILE Instance by byte[] data directly.
I think this solution is best way without changing the library as an easy way.
You can create a FILE handle from in-memory data in Linux, because the Linux C libraries do support fmemopen() from POSIX.1-2008.
Calling fmemopen(buffer, size, "r") yields a read-only FILE handle to an in-memory object containing size bytes at buffer.
However, I don't understand why you'd need such a thing.
The official Mini-SEED library does provide function msr_unpack() (and msr_unpack_data()) to parse Mini-SEED data records.
The functions you are probably looking at using, ms_readmsr() and ms_readtraces() (or their thread-safe variants ms_readmsr_r() and ms_readtraces_r(), just read each record from the file, passing each to msr_unpack() (and in case of traces, to mst_addmsrtogroup() or mstl_addmsr()).
In other words, the library does support parsing in-memory data. Your assertion that it only supports parsing files is clearly incorrect.
The man pages describing the library functions do not seem to be available on the net, but if you download libmseed sources, you can read the library function man pages using man -l libmseed/doc/[function].3.
As a compromise, you might use mmap to create a direct mapping between the memory and the file. This will allow you to update the contents directly (by accessing the memory) and the library may access the same data through the file interface. Under Unix systems, depending upon the size of the data, the file may not actually need to be written to disk. It may reside in the kernel's cache structure for faster access (this happens by default: nothing extra you need to do).
No, there's no portable, standard way of creating a FILE * that represents an in-memory stream of bytes.
The typical solution is to instead make the read and write function(s) hookable, so that instead of hard-coding e.g. read() you make the library call an (optionally) application-supplied function.
I've looked to some open source Libraries in some places. And, I've realized which that Libraries are basically a great stack of structs. I've seen few methods.
Why does C written libraries uses so much structs? What's the basis behind this? This, for me, looked like a attempt to simulate object orientation, 'cause a fast searching told me that each struct is "instantiated" by the using program to make something, per example, in some Desktop enviroments for linux that I've seen that each window was a struct in the used GUI library.
Anyway, the question is that.
Structs are a great way to organize data. And data is fundamental, as Fred Brooks knew decades ago:
Show me your flowcharts and conceal your tables, and I shall continue
to be mystified. Show me your tables, and I won't usually need your
flowcharts; they'll be obvious.
Object-oriented programming doesn't have to be merely simulated in C, it can be realized. For example, did you know that inside your structs you can store function pointers which operate on those same structs, and then you are a little bit closer to C++'s classes?
Also consider extensibility: even a function taking many arguments may be improved by taking a single struct, because then its signature does not need to change when a new argument is added.
Finally, C does not have multiple return values from a single function call. But it can return a struct, which is about the same thing. C is a lot about building your own tools from the raw language, and being able to stash a bunch of related data and/or functions together in one place is a good building block.
With or without object orientation, structures are a useful way to group aggregate data into a single symbol. You can copy the structure wherever you like without having to write out all the members each time, and this makes the structure easier to change if you have to.
It also makes it easier to reference certain members using pointer arithmetic, if you're careful (see sockaddr).
Same argument as with arrays.
Simply put, there's no reason not to use structures.
Structures are useful while retrieving data using a pointer. Because single pointer is enough for complete bunch of data with in a structure.
One, it keeps the APIs clean. Instead of passing N separate arguments to a function, you pass a single argument containing N members.
Two, it allows the library to hide implementation details from the programmer. For example, the C FILE type abstracts away some details of stream I/O, details which vary from implementation to implementation. We don't need to know those details, so they're not exposed to us; we just use the FILE type to pass that information around.
How can I make a copy of a tree data structure in memory to disk in C programming language?
You need to serialize it, i.e. figure out a way to go through it serially that includes all nodes. These are often called traversal methods.
Then figure out a way to store the representation of each node, together with references to other nodes, so that it can all be loaded in again.
One way of representing the references is implicitly, by nesting like XML does.
The basic pieces here are:
The C file I/O routines are fopen, fwrite, fprintf, etc.
Copying pointers to disk is useless, since the next time you run all those pointer values will be crap. So you'll need some alternative to pointers that still somehow refers disk records to each other. One sensible alternative would be file indexes (the kind used by your C I/O routines like fseek and ftell).
That should be about all the info you need to do the job.
Alternatively, if you use an array-based tree (with array indexes instead of pointers, or with the links implied by their position in the array) you could just save and load the whole shebang without any further logic required.
Come up with a serialization (and deserialization) function. Then run it and send the output to a file.
HI all. I am trying to make little program that reads data from file which has name of user and some data for that user. I am new on C , and how can i calculate this data for its user?line by line reading and adding each char in array? And how can I read line? is there any function?
And how can I use this each line users like object?I will make calculation for specific user.
You can use fgets to read a line at a time from the file.
Then you can parse the fields out and add them to an array or some other data structure. Just keep in mind if you use an array then you need to know ahead of time how many entries the file may contain - for example, no more than 1000. Otherwise you will need to use a data structure that can dynamically allocate memory such as a linked list, vector, etc.
Try this site, i often use it for reference.
http://www.cprogramming.com/tutorial/cfileio.html
Play around with file i/o and get use to the functions and then you will be able to make what you want.
Everything you need is in stdio.h. (Link is to a C++ website but the entire C i/o system is usable in C++; hence the documentation)