Alternative flags and encoding support

[zauguin]

Provides the functionality of #72 with the sqlite_config interface.

Fixes #71

[aminroosta]

@zauguin Use the same name as sqlite.

enum class Encoding {
  ANY = SQLITE_ANY,
  UTF8 = SQLITE_UTF8,
  UTF16 = SQLITE_UTF16
};

[aminroosta]

@zauguin Use an enum for flags instead of int.

enum class Flags {
  OPEN_READONLY = SQLITE_OPEN_READONLY,
  OPEN_READWRITE = SQLITE_OPEN_READWRITE,
  OPEN_CREATE = SQLITE_OPEN_CREATE,
  OPEN_NOMUTEX = SQLITE_OPEN_NOMUTEX,
  OPEN_FULLMUTEX = SQLITE_OPEN_FULLMUTEX,
  OPEN_SHAREDCACHE = SQLITE_OPEN_SHAREDCACHE,
  OPEN_PRIVATECACH = SQLITE_OPEN_PRIVATECACH,
  OPEN_URI = SQLITE_OPEN_URI
};

[zauguin]

For a enum class operator | isn't defined, so this leads to quite some boilerplate. Do need operator& too?

[aminroosta]

@zauguin I didn't know that, Is there a workaround for this limitation?
No we don't need operator &.

[aminroosta]

@zauguin I just tested a hackish way, let me know what you think

enum class test { A = 1, B = 2, C = 4 };

test operator|(const test& a, const test& b) {
  test ret;
  ret = static_cast<test>(static_cast<int>(a) | static_cast<int>(b));
  return ret;
};

int main() {
  test c = test::A | test::B;
  cout << static_cast<int>(c) << endl; // prints 3 as expected :-)
}

[zauguin]

Thanks, I integrated it.

[aminroosta]

@zauguin rename this to zVfs same as sqlite documentation.

[aminroosta]

Make the default encoding for this constructor UTF16, this changes the behavior we had in previous versions.
@zauguin

[zauguin]

I don't really understand this comment. By default the encoding is ANY, so in line 434 we select encoding UTF16.

[aminroosta]

@zauguin You are right, my mistake :-)

[aminroosta]

@zauguin Looks very good to me, please add a unit test and update documentation.
Thanks for the great work you have done with these recent PRs 😉

[zauguin]

This will hit the same Visual C++ bug as #94.
To implement the work-around I would refactor the conversion into a separate method. Then we could make it a little bit more generic. Is there interest in wstring and u32string support?

[aminroosta]

@zauguin I thinks its better to keep it simple, std::string & std::u16string are enough :-)

[zauguin]

I only add tests for read-only, I don't know anything about the other ones, but there is no reason why they shouldn't work.

[zauguin]

@aminroosta What do you think about omitting OPEN_? It looks a bit redundant. If you prefer to keep it we might move it to the class name: OpenFlags::READONLY looks better than Flags::OPEN_READONLY

[aminroosta]

@zauguin OpenFlags::READONLY looks better, I'm for it 😉
BTW do you think we should make a new release after this PR?

[zauguin]

Right now I'm working on std::variant support and I would really like to see this in the next release, especially for supporting functions with different argument types, but apart from that, go for it.