In trying to learn how to use libid3, since there sems to be no documentatio. I am looking at soure trying to figure out how to use it. The first problem is the practically every call uses a pointer to a "struct id3_file" . Now, the problem is that there is no definition for id3_file structure in any .h file. I finally found it in file.c, a source file. How the hell are you supposed to use it in your app when the prototype is in a package source file?
Seems that something is really broken here.
tj
Hi tj :)
* tj 999alfred@comcast.net dixit:
The first problem is the practically every call uses a pointer to a "struct id3_file" . Now, the problem is that there is no definition for id3_file structure in any .h file. I finally found it in file.c, a source file. How the hell are you supposed to use it in your app when the prototype is in a package source file?
Well, it is called encapsulation. You use a pointer to the structure. You can use a pointer to an incomplete type, this is not a problem under C, AFAIK. Moreover, using this technique you are sure that nobody outside your source file is going to dereference the pointer. You have full encapsulation of the structure internals. This way, Rob can change the entire definition of the structure internals, change the implementation of the methods and you don't have to rewrite a line of code that uses libid3tag (or whatever). Thas a very good practice, object oriented. If you want to see another clear example, I have a small library containing a object oriented implementation (in C) of a multipurpose container, using the same techniques.
Seems that something is really broken here.
Not at all. I would have provided something like:
typedef struct id3_file *ID3_FILE;
not more, for use in programs, thus occulting even the fact that this is a pointer. Now it is an object ;) I think that Rob is a good designer if he uses this kind of constructs. Without the above typedef, you can use the pointer to store a value, not more, not less, and you can pass it to functions, use it to store returned values, etc... Under C, all pointers share the same representation. The only problem (without the typedef above) is that you cannot do pointer arithmethic, so you cannot have arrays of id3_file structs, etc... This is the only flaw I see in this kind of code, and if you want encapsulation, that's the price to pay ;)
Anyway, I wouldn't use arrays of structs, I will use array of pointers, so you have pointer arithmethic and all that shit without exposing the internals of your structs.
Hope this helps :)
Raúl Núñez de Arenas Coronado
Duh, makes all the sense in the world. My head is somewhere it shouldn't be :-). Got a big deadline and I am in panic mode :-(.
One more question, to build for Stongarm processor does configure support --host= arm ? Using PXA255
tj
DervishD wrote:
Hi tj :)
- tj 999alfred@comcast.net dixit:
The first problem is the practically every call uses a pointer to a "struct id3_file" . Now, the problem is that there is no definition for id3_file structure in any .h file. I finally found it in file.c, a source file. How the hell are you supposed to use it in your app when the prototype is in a package source file?
Well, it is called encapsulation. You use a pointer to the structure. You can use a pointer to an incomplete type, this is not a problem under C, AFAIK. Moreover, using this technique you are sure that nobody outside your source file is going to dereference the pointer. You have full encapsulation of the structure internals. This way, Rob can change the entire definition of the structure internals, change the implementation of the methods and you don't have to rewrite a line of code that uses libid3tag (or whatever). Thas a very good practice, object oriented. If you want to see another clear example, I have a small library containing a object oriented implementation (in C) of a multipurpose container, using the same techniques.
Seems that something is really broken here.
Not at all. I would have provided something like:
typedef struct id3_file *ID3_FILE;
not more, for use in programs, thus occulting even the fact that this is a pointer. Now it is an object ;) I think that Rob is a good designer if he uses this kind of constructs. Without the above typedef, you can use the pointer to store a value, not more, not less, and you can pass it to functions, use it to store returned values, etc... Under C, all pointers share the same representation. The only problem (without the typedef above) is that you cannot do pointer arithmethic, so you cannot have arrays of id3_file structs, etc... This is the only flaw I see in this kind of code, and if you want encapsulation, that's the price to pay ;)
Anyway, I wouldn't use arrays of structs, I will use array of pointers, so you have pointer arithmethic and all that shit without exposing the internals of your structs.
Hope this helps :)
Raúl Núñez de Arenas Coronado
Hi Tj :)
* tj 999alfred@comcast.net dixit:
Duh, makes all the sense in the world. My head is somewhere it shouldn't be :-). Got a big deadline and I am in panic mode :-(.
Oh, sorry, I know what deadline's are :(
One more question, to build for Stongarm processor does configure support --host= arm ? Using PXA255
I don't have the slightest idea. I'm afraid I'm not a configure guru :(( Anyway, if your 'uname -m' says 'arm', configure should work (if you have the appropriate cross compiling tools, of course).
Good luck, tj. And take the deadline easy.
If I can help you, drop me a note.
Raúl Núñez de Arenas Coronado
tj, try this link: http://www.mars.org/mailman/public/mad-dev/2002-January/000439.html
-
Arty -
DervishD -
tj