SQL Connector Module

[Niely]

Hello

A lot of games, and other applications of which the developing can be made easier and more productive using SFML, still require a database (for storing scores, or other data).

But SFML doesn't have an option, feature, or module to connect easily to a (My)SQL-database.
It'd be nice if SFML would have this, because I personally like the style of SFML more than the one of other libraries, and than the developer ain't forced to bloat his program with loads of different libraries; but can stick to a few, or even just one or two.

Maybe, this could be a handy feature for in the (far) future?

Thanks for reading,

[eXpl0it3r]

Getting such code right, efficient and then maintain it all is a lot of work that I don't see our team is having.
Then you need to start thinking of what to support. MySQL, PostgreSQL, SQLite, etc...
Honestly there are a ton of very good, well maintained and iften quite modern libraries out there, that do a way better job than we ever could.

If you're afraid of using libraries, then C++ is not really the place to be...

[Jesper Juhl]

I don't think this fits in with a "multimedia library". And besides, there are already many libraries available that let you access databases. Why would SFML need to duplicate their functionality? Just use other libs for DB stuff.

[Mario]

Yep, I agree. While having a simple and built-in database interface would be nice, it's really too much work to do and not really "edge case" implementation variety wise.

I often thought about a simple class to load and save settings in some way (possibly JSON or INI). While this wouldn't be as mighty as a full DBI, it would fit a lot better within the scope achievable right now and would also be more than enough for most common tasks or problems. Plus it wouldn't add more (significant) dependencies to SFML, considering there are many header only or minimalistic implementations out there.

[Niely]

Getting such code right, efficient and then maintain it all is a lot of work that I don't see our team is having.
Then you need to start thinking of what to support. MySQL, PostgreSQL, SQLite, etc...
Honestly there are a ton of very good, well maintained and iften quite modern libraries out there, that do a way better job than we ever could.

If you're afraid of using libraries, then C++ is not really the place to be...

Well, it's not that I'm afraid of using them (however, sometimes the building and adding to VS can be a real pain). But because I'm still a very beginner in C++ I don't think using tons of libraries are good for learning purposes, If I'd be able to understand the pure code after the libraries, and I'd know what's under the hood, I'd learn more from the language. SFML allows me to inspect that, other's would be harder.

But I understand that such a module indeed would be to much work.
I think I'll go with SQLAPI or maybe even MySQL-Connector/C++.

[zsbzsb]

I would really suggest that you choose a library like CppDB which will give you an abstraction over your database backend. That way you can easily change your actual DB provider without changing your own code.

[Jesper Juhl]

I often thought about a simple class to load and save settings in some way (possibly JSON or INI).

No need to add anything to SFML for something like that. There are many existing good options available for something like that.
IMHO some good options are:
Libconfig : http://www.hyperrealm.com/libconfig/
PicoJSON : https://github.com/kazuho/picojson

[Satus]

PicoJSON : https://github.com/kazuho/picojson

+1 to PicoJSON, I use it in my projects and it is very simple yet powerful.

[SpeCter]

My personal favorite and pretty similar to picojson is:
https://github.com/nlohmann/json

[Mario]

No need to add anything to SFML for something like that. There are many existing good options available for something like that.
IMHO some good options are:
Libconfig : http://www.hyperrealm.com/libconfig/
PicoJSON : https://github.com/kazuho/picojson

Yep, picojson is what I've had in mind as well and since it's so easy to add, I didn't bother with it so far - there are more important things.

My personal favorite and pretty similar to picojson is:
https://github.com/nlohmann/json

Wow, didn't know that library. How does it compare to picojson (performance/memory footprint)? This looks very easy and intuitive to use, essentially what I've had in mind (since picojson wants you to check types etc. first).

[SpeCter]

To be honest, I can't really say how they compare in performance/memory footprint. For what I do/did with the libraries I can only say that they were more than fast enough.

The reason I switched to the nlohmann modern json was purely a syntax decision. It just felt more natural to use.