Open yak1ex opened 1 year ago
Hi, very sorry I missed this issue, I had some difficult circumstances and wasn't following up on github issues.
Yes, I think this is a good idea to support this, and your proposed change doesn't sound too intrusive.
Thanks. I'll make a pull request.
I recognized MDB_VL32 feature has not been officially released yet.
So, offical releases do not have mdb_size_t
.
We can, maybe, employ some metaprogramming technique to detect if the type is defined or not, but using a preprocessor is simple and enough, isn't it?
namespace lmdb {
using mode = mdb_mode_t;
#ifdef MDB_SIZE_MAX
using size_t = mdb_size_t;
#else
using size_t = std::size_t;
#endif
}
Yes I think that seems reasonable, ideally a comment explaining when we'd expect MDB_SIZE_MAX
to be set.
BTW: Will you be testing this with the unreleased VL32 feature? Are you using it for anything now, or planning to?
I do use VL32 for enable copying database files created on Win64 PC to 32-bit ARM device. I can participate in testing modifications required, because I do modification of hoytech/lmdbxx myself anyway.
Sorry for the long hiatus. My use case was solved by another measure, so there is less concern for this issue... I made some work anyway; I created the PR.
@uaply Could you check the https://github.com/hoytech/lmdbxx/pull/15 ?
If
MDB_VL32
is defined, 32bit lmdb lib can handle a db made by 64bit lmdb lib. In this case,mdb_size_t
is not the same asstd::size_t
.One possible modification to handle the situation, add lmdb::size_t like as
then replace
std::size_t
withlmdb::size_t
in places related withmdb_env_set_mapsize()
,mdb_txn_id()
andmdb_cursor_count()
. This situation may be not so often, however, I think this modification should not be harmful for other situations, mdb_size_t = size_t.If this modification is acceptable for you, I will make a pull request in that way. What do you think?