Well, I need to create a format for test app which must contain questions, answers, variansts and IMAGES.
How should I read an image? And where to save it? In char*?

Thanks.

I'd just use one of the avialable libs for handling images. These typically provide you with some struct or object, so you don't really have to care about the internal representation of the images.

If you really want to do it yourself, yes, an array of (unsigned) char's may be a good start.

IF you want to do this yourself then you need to understand the structure. http://www.wotsit.org/

kornerr - as dmail points out, the answer might depend on what kind of images you need, how you're planning on using them, or what language you're programming in.

But if you're programming in a language like C/C++, Perl or Python, libraries like GTK+ 2.0 have built-in support for most standard file types - you just say "read_file()" (for example, something like "gdk_pixbuf_new_from_file()").

If you're programming in Java or C#, the standard libraries have built-in support for reading, displaying and manipulating standard graphics file formats.

So please consider Hko's suggestion and see if your programming language has a library that supports your file format.

I'm not the OP, but the question got me curious.

If you're using C and can only use the standard libraries, are you limited to reading image files as binary streams using, say, fopen() and fread()?

Hi -

I'm not sure I understand your question. I think you're asking:

Q: Does the standard C library (libC) provide an API for parsing and displaying image files?

A: No: the standard library provides APIs for file access (read (), fread (), getc(), etc), but you would either have to use an additional library (libpng or GTK+, for example) or write your own parser.

Once you've parsed the file, then you'd then have to use yet another library (SDL, Xlib, GTK+, Qt, etc) to actually display it.

Does that help?

Yes, that's exactly my question. Your answer helps a lot. Thanks.

Yes, though I'd rather use the syscalls open(2) and read(2) for binary data. Note that fopen(3) and fread(3) actually call open(2) and read(2) behind the scenes.

Is there any reason for that? Looks to me that dealing with file pointers (FILE *) is easier than file descriptors.

You're right - stdio *is* easier. And more efficient (in terms of functionality, and overall system throughput).

"Stdio" ("fopen()", "fprintf()" and friends) is an abstraction on top of the underlying OS I/O capabilities. The biggest advantage it brings to the table is "buffered I/O", but there are also many other benefits to using stdio instead of the low-level read/write file interface.

If you look forward into the "Standard I/O" section of this PDF, it's got some interesting discussion of the subject:
http://www.google.com/url?sa=U&start...es/class24.ppt