[SDL] Re: SDL_Config: call for comments
koshmaar at poczta.onet.pl
Thu Jul 7 04:58:32 PDT 2005
> Please either drop the SDL_ prefix, or use the less restrictive LGPL
> license. AFAIK all other SDL_* libraries use the LGPL, so it would be
> confusing if SDL_Config used a different library.
Ups, sorry everyone, _of_course_ it ought to be written "LGPL", not "GPL". I see it made a lot of confusion, so sorry once again (stupid typos :-/).
> > // It controls what version of function definitions will be compiled
> > - those with or without default values. // Not _cplusplus because
> > someone may want to use C version in C++ project #define PLAIN_C,
> > C_PLUS_PLUS
> To cooperate with other libraries, please use a prefix on all
> preprocessor symbols your library uses.
Ok, good point.
> If you want separate interfaces for C and C++,
Honestly, the last thing I would want, it would be seperate interfaces for C and C++. There are just some syntactic sugars in C++, that would be good to support, if user is compiling in C++. If he's not, then sorry.
>a better approach would
> be to write the C++ interface as a layer on top of the C library. Or
> just make it a C++ library.
That's interesting - probably eventually I'll write wrapper class around this library, so that user could parse config files in OOP way, ie.
CFG_File config("settings.cfg"); // opens and parses file "settings.cfg"
config.OpenGroup("Video"); // selects "Video" group
bool fullscreen = config.ReadBool("fullscreen", true); // second argument is default value, which will be returned when such entry wasn't found
>> // What string version use in function definitions and internally,
>> when parsing #define USE_C_STRINGS, USE_STD_STRINGS,
>Which unicode strings would that be? std::wstring in UTF16?
>std::string in UTF8? Custom unicode string class? Other?
That's difficult question - I don't have any real experience in coding with Unicode, but:
1. Coding my self unicode string class would be nothing more than forcing open door, similiar to rewritting STL, and I'm not even feeling up to it, nor I have will to do it.
2. Probably it will look like this:
If you're programming in C, then library will be using standard C functions for operating on const chars *.
If you're programming in C++, then you will be given a choice:
- you use std::string with standard ASCII
- you use std::wstring with UTF16
- you may also use const chars *, if you really want to :-)
> > Hmmm... quite many, right? :-) Do you think someone would want to use
> > this level of customizeability, knowing that none of them will change
> > external library behavior even a bit, only internal implementation
> > would be different, and interface would change slightly in some cases
> > (strings that would be returned)? Or would it be better just to stick
> > with those options that are available natively in plain C?
> Stick to customization options that actually matter.
Ok, good advice.
> > 1 -Iif _cplusplus isn't defined, simply don't compile functions that
> > operate on bools. 2 - This code will tell you all:
> > #ifdef _cplusplus #define BOOL bool #else #define BOOL int #endif
> > Which one do you like more? Is there any third (better) way?
> Just use 'int' in a C library.
That was also my favourite :-)
> I don't like global state, so I would prefer the ability to open
> multiple configuration files, even if I never use it.
Hmmm, it looks like other people also think like that. The reason I was against it, is that it would bloat library a little, and made using it less easy, ie. you would have to pass to nearly every function one struct more, which would identify file you are working on.
> > 4. This one is easy: will you want to use such library? :-) If
> > there's no interest, there's no need to write it, simple.
> Not if it's GPL. Maybe if it's LGPL. I have no own code to handle
> configuration files, so I would only switch if there is a compelling
> reason to switch to your library.
Yes, I say once again: that GPL was my (stupid) mistake.
Well, anyway, that's great - there's already one person who might use it! :-)
> BTW, one cool feature would be to automatically store configuration
> files in the correct place on various platforms.
> ~/.application/filename for Linux, ~/Library/Preferences/filename on OS
> X, ~/Application Data/application/filename on Windows, or something like
> that. Of course not everyone will agree on what the correct place to
> store preferences on each platform is.
> Rainer Deyke - rainerd at eldwood.com - http://eldwood.com
Hmmm, good idea, but there are 3 reasons why it probably won't be added:
1. This library was meant to be rather low-level, so if you want such higher-level behaviour - you should write it by yourself.
2. Generally on all platforms, for flexibility's and clearness sake, when you say "open file abcd.cfg", it means: open file abcd.cfg in respect to current working directory.
3. I have no experience in progamming anything on platforms other than win32 :-(
Anyway, thx a lot for comments!
More information about the SDL