Rework entire code for correctness and potential bug fixes

[piotr-topnotch]

Reworked minio-cpp to in order to:

1. Fix all the bugs caused by implicit conversions to bool.
2. Defaulted constructors and destructors.
3. Explicit override indicators of virtual functions.
4. Enhanced copy elision and enabled move construction.
5. Improved const correctness. Only the functions that mutate objects take mutable references.
6. NULL => nullptr transition, as the required language level is C++17 already.
7. Fixed a number of the lack of default initialization value bugs.
8. Enforced -Wall -Wextra -Wconversion and fixed the relevant uncompilable sites.

The scope of the changes is limited to what is allowed by the requirement to leave the API unchanged. Nonetheless, a follow-up pass removing converting constructors is highly recommended.

[HJLebbink]

LGTM, Large and absolutely needed update., much appreciated. I ran the tests on WSL2. But I'm in no position to predict the impact on upstream projects that use this repo. @harshavardhana @balamurugana, or anyone in such position, could you please have a look. I need these changes for a POC. @piotr-topnotch if there is no resolution for this PR in the coming weeks, could you please consider to fork to prevent a stall our other efforts.
Note, the PWTODO will need updates but please not in this PR.

[balamurugana]

Initial review.

Please fix CI failures.

[kobalicek]

@piotr-topnotch I think this needs Windows fixes as well.

I assume this is the first PR that doesn't introduce API breaks? Because all the passing of stuff via value (like std::string, etc...) that has to go away. I would suggest std::string_view for everything that doesn't need to be retained (that would be a good start) and then I guess we will have to evaluate the API one by one to make it nicer.

Thinking of jumping into this after I finish the stuff I'm working on.

[piotr-topnotch]

I assume this is the first PR that doesn't introduce API breaks?

Except for the explicit operator bool() which is the root of most problems here, that's precisely the goal here. More fixes are pending, but let's do it one step at a time.

Moreover, I spoke to @kannappanr and he agreed to treat the removal of all the implicit conversions as bugfixes, even if these changes would break comparability at the user end. As the user experience has priority, this enables much deeper rework.

[piotr-topnotch]

But I'm in no position to predict the impact on upstream projects that use this repo.

Thank you, @HJLebbink. @kannappanr authorized breaking changes if that improves user experience and can help fix bugs. There shouldn't be many in this PR, but there are more issues requiring our attention, e.g. implicit conversions.

[piotr-topnotch]

Please fix CI failures.

Sure; I didn't know we have a linter in the CI loop. It's good news and the fixes will be promptly delivered.

[astrocox]

Not sure if you have easy access to a Windows dev environment. If not, lmk, I might be able to take a look at the CI failures this weekend.

[HJLebbink]

Not sure if you have easy access to a Windows dev environment. If not, lmk, I might be able to take a look at the CI failures this weekend.

@astrocox I wanted to contact you: have you been able to compile and link this project in the past on WSL2 or on native Windows? I and @piotr-topnotch have such win boxes, but use WSL most of the time. For community support, windows native support would be a very good thing to have.

[astrocox]

Not sure if you have easy access to a Windows dev environment. If not, lmk, I might be able to take a look at the CI failures this weekend.

@astrocox I wanted to contact you: have you been able to compile and link this project in the past on WSL2 or on native Windows? I and @piotr-topnotch have such win boxes, but use WSL most of the time. For community support, windows native support would be a very good thing to have.

Native windows, after my changes from #108 ! You can check the windows build pipeline for the steps to install dependencies. Locally I have tested it with cl.exe and clang-cl.exe, but the GH actions build is using the regular MSVC cl.exe compiler. If you're using an IDE like Clion, it's pretty easy to set up two different cmake profiles that use Visual Studio and WSL as their respective toolchain.

There are still a lot of compiler warnings to clean up on windows, but I think some Windows support is better than none 🙂

[kobalicek]

I can extend GH actions workflow to use a much larger matrix of various configurations (OS / compiler)

[piotr-topnotch]

There are still a lot of compiler warnings to clean up on windows, but I think some Windows support is better than none 🙂

Build support for MSVC is now confirmed. The Windows warnings you can see will be fixed as a part of this PR.