[SDL] Re: SDL_Config: call for comments

[Koshmaar]

> 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,
>> USE_UNICODE_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!

Koshmaar