I look for a crossplatform .ini library. I tried "simpleini" but it's no good at all, it has tons of useless features (like Unicode support) and no basic stuff (like read integer, it can only read strings). I just want to read the "sound volume" from the config file and other trivial things. Preferably I would want it to be identical or almost identical to the Microsoft's ini functions (it's a rare thing to say, but they did it the right way this time).

Also, are you so certain you will never, ever need to save a file path in your config file?

Once file paths come into play, unicode support is a must if you want people with different languages to be able to play your game. You can not even guarantee that a standard system path for that country does not use non-basic-latin characters. I could probably even tweak that stuff on my own quite-english computer.

Yeah, I have bigger problems. And I would not want to add to these problems the need to make "enchancements" for something as simple as ini file parser I just hope there is one that has all I need...

Not simple.

Do you want customizable i/o? Or just read a file stream? But what if you decide to keep your config file in a packed file? You will have to be able to load it from memory... maybe you don't need this I don't know.

Will file paths be stored? Can the user enter their own name anywhere? What about support for save games? What if the person's username on the computer has Japanese characters, and you keep a list of save game files? The paths to those save game files will have Japanese characters in them on any windows system!

Okay, so you want to read strings, and integer values. What about a list of integer values. List of strings? Should it do floating point values too? How is the ini library writer supposed to know what format you want your data in? It's all text anyway - why not just read it and convert it yourself? I don't use boost myself, but here is an example:

Code:

int volume = boost::lexical_cast<int>(someIniFileValueString);

(And wanting cross platform but not unicode... that would mean the library works differently on different systems. Not a good sign for a library. For instance, in linux, unicode is basically automatic because of its favoritism towards utf8.)

Anyway - sorry to not have been more help for what you're looking for, specifically. Hopefully the above arguments help you in a different way though!

Do you want customizable i/o? Or just read a file stream? But what if you decide to keep your config file in a packed file? You will have to be able to load it from memory... maybe you don't need this I don't know.

Will file paths be stored? Can the user enter their own name anywhere? What about support for save games? What if the person's username on the computer has Japanese characters, and you keep a list of save game files? The paths to those save game files will have Japanese characters in them on any windows system!

Okay, so you want to read strings, and integer values. What about a list of integer values. List of strings? Should it do floating point values too? How is the ini library writer supposed to know what format you want your data in? It's all text anyway - why not just read it and convert it yourself? I don't use boost myself, but here is an example:

No, no, no I don't need any of these. I have absolutely simple needs. I want to read a string (latin chars only) and read an integer. Nothing more. I look for extreme simplicity, no need for flexibility in my case.

Preferably by just 2 functions like MS's GetPrivateProfileString() and GetPrivateProfileInt().

I have a cross platform INI Parser built into Paper Engine 2, but it's in straight C and is set up in such a way as to allow developers to loop through sections of the INI, for example, which may prove to be overkill for you(thus, not worth the setup time to integrate it). It also uses Unicode which, in my opinion, is a must for a cross platform INI Parser. The engine's open source, so you're certainly welcome to use it.

Using C++? For ini files I tend to just use boost::property_tree, which kind of support it and you can switch to xml or info format if it's better (actually I use the info format only because I prefer it).

I don't see why you should use a library to read a string from a file, just use std::fstream, grab line by line and parse them... it is even UTF-8 compatible.I can't believe someone actually proposed Boost for this

Obviously, if you ever want to extend this functionality to anything more complex than a list of key-values, using a library makes sense.But actually I've found out that all the serialization libraries are pretty bloated & bad on the internal representation side, so I've ended up writing my own anyway.

I don't see why you should use a library to read a string from a file, just use std::fstream, grab line by line and parse them... it is even UTF-8 compatible.I can't believe someone actually proposed Boost for this

Wow what's with the hate? I explained how I tends to do this.Did you read my full message? It's useful if you already have boost available and you can change to something else (like xml). Boost property tree is about tree structures, not ini files, so you can do more complex organizations if you wish (which is why I use info files which are close to YAML).

It's stupid to say you can't believe a good potential solution is proposed. It's what he asked for. Also, I don't agree with "just use std::fstream, grab line by line and parse them", any way to not having to write parsing code yourself is helping avoiding potential errors. So I don't agree.

Quote

Obviously, if you ever want to extend this functionality to anything more complex than a list of key-values, using a library makes sense.But actually I've found out that all the serialization libraries are pretty bloated & bad on the internal representation side, so I've ended up writing my own anyway.

Boost property tree isn't a "serialization library", it's basically done to setup data (any type you want) in tree-like structure. You can write it in a stream if you want or use it as a dynamic properties container or both. Did you take a look at the 5 minutes tutorial?

Wow what's with the hate? I explained how I tends to do this.Did you read my full message? It's useful if you already have boost available and you can change to something else (like xml). Boost property tree is about tree structures, not ini files, so you can do more complex organizations if you wish (which is why I use info files which are close to YAML).

It's stupid to say you can't believe a good potential solution is proposed. It's what he asked for. Also, I don't agree with "just use std::fstream, grab line by line and parse them", any way to not having to write parsing code yourself is helping avoiding potential errors. So I don't agree.

IF you already have Boost available obviously this makes sense (but honestly I don't like Boost at all), but still this is a problem that is so simple & basic that you should really be able to solve it by yourself in 10 minutes.It should take less time to write that code than to download boost, imo.

So yeah, I'm not against Boost per-se in this case, rather I'm with those who say that the OP should really learn to do this first.

Also sorry, I wasn't hating on you... but I really think that C++ is a dangerous tool, and you should *really* know what you're doing before to kludge libraries together

Boost property tree isn't a "serialization library", it's basically done to setup data (any type you want) in tree-like structure. You can write it in a stream if you want or use it as a dynamic properties container or both. Did you take a look at the 5 minutes tutorial?

Serialization = writing/reading native language objects from a standard language protocol. It doesn't matter if and how you write it down, the serialization part is when you store stuff in a property tree (which not by chance has the same structure as XML), imo.

IF you already have Boost available obviously this makes sense (but honestly I don't like Boost at all), but still this is a problem that is so simple & basic that you should really be able to solve it by yourself in 10 minutes.

Well I think it's even shorter to use boost property tree (if boost is installed and ready) than writing it myself, as I have automatic cast and parsing done in one function, so it's a good tool to me.

Quote

It should take less time to write that code than to download boost, imo.

Yes, I agree. It also requires some additional knowledge about boost and maybe C++ too.

Quote

So yeah, I'm not against Boost per-se in this case, rather I'm with those who say that the OP should really learn to do this first.

I agree it's better to learn how to do it first, but still the question was about a library to not have to do it (again) so to me it's a meta discussion, valid but not answering the question I tried to answer.Anyway I get your point.

Quote

Also sorry, I wasn't hating on you... but I really think that C++ is a dangerous tool, and you should *really* know what you're doing before to kludge libraries together

I see, no offense taken.

Just a side note for readers: boost isn't a library, it's a (huge) set of library that share only one common thing: they are reviewed by very experienced developers. Soon (in relative time...) we will be able to get one library separate from the others.Boost is a label.

Quote

Serialization = writing/reading native language objects from a standard language protocol. It doesn't matter if and how you write it down, the serialization part is when you store stuff in a property tree (which not by chance has the same structure as XML), imo.

I do not agree: I also use the property tree to manipulate dynamic data like if it was json, but in C++ (very useful to bind easily with script data). That's the primary goal of the lib actually, with serialization as a bonus.Anyway it's another subject and not very important.

What I wanted to mean is that boost property tree does something actually simple, compared to boost serialization which, if I understand correctly, is the kind of library you were talking about (which I agree are rarely worth).