To avoid endless debates about the interface without clearifying the basic
concept I do introduce all possible methods I know (for C) with explaining
all pro and cons I know. I hope this is the best I can do.
+--X8X8---+
| [_] I do not vote|
| [_] pointer to a public structure|
| [_] private struct |
| [_] pointer to a private struct |
| [_] lame handle |
+--X8X8---+
a) pointer to a public structure
Program have to allocate a struct on stack, heap or statically
(or lame_open has to do this) and have to release this at the end.
The structure of this struct is well known, every element can be
accessed via read and write.
All lame functions get as first argument a pointer to this struct.
Interface is peeking and poking this structure.
+ source code compatible with the current version (you only need to
recompile, if you have all the sources)
- problems while extending, reording, changing structure
removing, changing, promoting elements of this structure
(this can be avoid with more or less effort until a given degree, but
this also will hinder development, and finally it goes wrong)
- problems when compiler will change binary structure representation
- problems when structure must be extended
- problems when changing the libmp3lame.so due to the points mentioned
above
- the are some ambiguous situations (example: VBR_q=0: quality=standard
or quality=0)
- error handling is more difficult (who is the guilty?)
Note: Changing an interface not become easier in the future.
Note: If necessary a wrapper can be written to support the old interface.
b) private struct
Program have to allocate a struct on stack, heap or statically.
The structure of this struct is not known, so access is possible, but
only with obvious very dirty methods.
All lame function get as first argument a pointer to this struct.
Interface are well defined function calls.
- problems when the struct must be enlarged
o rest see c)
c) pointer to a private struct
Program calls lame_open and gets back a pointer to a structure.
The structure of this struct is not known, so access is possible, but
only with obvious very dirty methods.
All lame function get as first argument this struct pointer.
Interface are well defined function calls.
- not source code compatible with the current version
+ no problems changing the internal structure. You can do nearly
everything
+ no problems changing the shared lib without recompiling all programs
+ no compiler representation problems
+ structure can be extended without any problem
+ well defined interface with the possibilty of error handling
Note: UNIX/C buffered FILE I/O works in this way:
fopen/fread/fwrite/fputs/fclose/setvbuf/fseek/...
d) lame handle
Program calls lame_open and gets back an integer value. This value is
an index into an internal lame table.
Access to this internal table is also only possible via obvious very dirty methods.
All lame function get as first argument this integer value.
Interface are well defined function calls.
o first see c)
+ better anonymization of the structure
+ needs not the trick of mapping two different structures in API and
Lame
- a little bit less error checking is possible (first parameter is an
int, here you can pass a lot of trash: 44100/1050 )
Note: POSIX unbuffered I/O works in this way:
open/read/write/close/lseek/dup/dup2
Good operating Systems also hiding the internal structure by
memory protection (Kernel/User space).
Hope this helps.
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
