Some optimizations and bug fixes

[KOLANICH]

No description provided.

[SRombauts]

Hi @KOLANICH, I've noticed that you reported a lot of issues and proposed some improvements. Thank you for your time!

For your Information, I am no more actively developing this library, but I welcome any help you can provide for improving it!

Cheers!

[SRombauts]

Could you perhaps separate this into multiple more specific merge request?

I feel this would help me integrate the parts I am the more confident in!

Cheers!

[KOLANICH]

Could you perhaps separate this into multiple more specific merge request?

I can, but not all of the commits. Some of them depend on each other and If I separated them there will be merge conflicts.

I also wonder if we should drop Travis CI. It is dead, they use ultra-obsolete Docker images.

Is this yours? I propose to

1. make that repo synced with this one
2. drop Travis support and setup GitLab CI instead of Travis one. Do you know any good and AUTOMATICALLY UPDATED to the latest versions of everything Docker images for that?

[SRombauts]

Yes, it's also mine repo on Gitlab, and I have actually been using Gitlab CI at my previous job, but right now I don't have the time to switch.

If I recall correctly, Travis is in fact now providing more recent Ubuntu images, it might be a matter of proper config at the top of the Travis yaml config file

[KOLANICH]

but right now I don't have the time to switch.

So if I created a PR with .gitlab-ci.yml, you would have accepted it, would you?

If I recall correctly, Travis is in fact now providing more recent Ubuntu images, it might be a matter of proper config at the top of the Travis yaml config file

Yes, they have introduced

dist: xenial

in 2018 after bionic has been released and xenial has become obsolete.

[SRombauts]

Hi @KOLANICH, I somehow missed your last comment... sorry for not answering!

I am going to cherry pick some of your commits, starting by simple things.

Regarding your most disruptive changes, yes it would be nice to simply throw every old compilers and platform, but that's rarely how things works in most companies; Ubuntu 18.04 is more recent then what I used at work until recently and at home.
We do also often use Debian or other distros.

So we could instead for a new v3 branch for instance, with disruptive changes, or requesting a much more recent setup (CMake & C++ version)

This (as much as other considerations) that I am not wiling to just drop Github, but I indeed would gladly add a gitlab-ci Yaml file

Thanks again for your time!

[KOLANICH]

Regarding your most disruptive changes, yes it would be nice to simply throw every old compilers and platform

I don't even know which of them is the most disruptive. I have rewritten the most of the template code in the way it doesn't require any variadic templates, is it was initally. pure and const attrs are supported by GCC-like compilers for quite a while (unfortunately const attr in c++17 syntax ([[const]], and even [[gnu:const]], unlike [[pure]], but [[pure]] is unsuitable for our needs, we need const) is not supported at all), so using them is not expected to be disruptive. IMHO the most disruptive is requiring the latest CMake introducing FetchContent (IMHO even with it CMake does damn bad, we need something like conan.io, but without any large dependencies, like python).

[KOLANICH]

oops, here is the error (though causing no harm in most of cases). Should be !defined(SQLITECPP_PURE_FUNC)

[maxbachmann]

Is it intended to drop support for compilers lower than c++11? (I do exactly the same for binding using enable_if in my project, so it's no problem for me, but I do not know whether there are still people with older compilers) and while I think the use of sqlite3_bind_parameter_index is a cool addition, but it should completely replace the current functionality, since at least I definetly do have a use case for the initialisation using a variadic template

[SRombauts]

Yes @maxbachmann, my intention is to drop support for compiler older than C++11.
I could start a new version 3.x of SQLiteCpp and I would do keep a branch for maintenance as needed.

[maxbachmann]

@SRombauts yes it probably makes sence to drop the support in a major release :)

[SRombauts]

Closing this one since it has been mostly merged by pieces by now.
Thanks again!