On Fri, 19 Mar 2004 15:18:50 +0000 "Nuno Lucas" <[EMAIL PROTECTED]> wrote: > I don't think there is the need to go so far. What I believe is in separation > of the os.c file for the diferent platforms supported. > A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will >make the code for each port more readable and easy to set new ports > (for example, ifdefing the incompatible code in os_win.c and adding a os_wince.c). > When compiling for windows, the os_mac.c and os_unix.c would simply be >ifdefed out, like when using SQLITE_OMIT_AUTHORIZATION and the auth.c file. > I didn't do this to the WinCE port because I think a port should be the closest >possible to the original, including the design, making it very simple >to use a program like WinMerge to update the sources to a new version. >For WinCE I had to also to implement atof() (for some WinCE versions), and >having it on a separate os_wince.c file would make the code cleaner.
So, what you want to do basically falls in maintaining ports, but internally in SQLite codebase, isn't it? Actually, I don't care specific breed of Windows, but only have concern on the aspect (you can associate it with aspect-oriented programming) that they have same characteristics in necessary interfaces (ANSI/wide). Therefore I thought it would be advantage for SQLite to extract and abstract this aspect, ANSI/wide, to adapt it to unknown future platforms. If you only care about problems of short-range, just port and let it go, but I believe it won't produce maintainable and reusable code. My own usage model of SQLite is, I incorporate SQLite as source code in my C++ codebase of an application with UNICODE defined. Since UNICODE is defined all over SQLite code, to match Windows API and SQLite const char* zFilename interface and make it pass through the compiler, I have to modify os.c to add 'A' postfix to all file-handling APIs. Because I only use source code of SQLite, I can agree with your somewhat light-weight solution. However, SQLite is provided in binary .dll form, too. For users of .dll, only one dll for all Windows and unchanged interfaces would be some kind of merit, at least I'd thought so looking sqlite.org for years. I would like to hear the opinion of the designer himself on this point. If you assume ANSI/wide version APIs coexistence in SQLite is too fat and takes in a few unwanted kilobytes of code memory which is too big in embeded platform, then there should be a macro like LEAN_FILE_API or something to remove unwanted part from resulted binary, but it is only for Windows Embedded developers, not for mainstream desktop/server Windows developers. -- KL --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
