H5CPP doesn't comply with C++11

[steven-varga]

error:
There are if constrexpr ( condition) { } in code base that prevent the code to parse as c++11

workaround: --std=c++17 until conditionally removing the offending constructs

[barcode]

As someone who uses this library and extends it for my own projects (e.g. generating the glue code from h5cpp-compiler with a macro), I would question the reasoning behind making this library c++11 compliant.

Using c++17 reduces the amount of code necessary (e.g. with if constexpr). This improves readability and thus code quality (less code to make mistakes) and maintainability (easier to spot mistakes).
Furthermore this library already depends on c++17 and so do all downstream projects (Upgrading from c++11 to c++17 would be a different issue).

Altogether i don't think it makes a lot of sense to use a standard which is eight years old and would vote for declaring this project as c++17 (at least my fork will stay c++17).

[steven-varga]

And I agree, factually H5CPP never became c++11 compliant. I tried that move and did a run for it: never worked out. However it is not as simple as it looks: someone in some government implied something and this was the consequence: I worked days and nights, then got cancelled. The idea was that some library on some supercomputer didn't take c++17 compilers. Currently on a different but not unrelated project -- once I get my attention back to H5CPP I will yank all awkward c++11 -ishness and even 14-ness from the codebase, and go with the more powerful c++17 -- the way I originally intended this to be. steve July 16, 2019 2:14 AM, "Raphael Grimm" <notifications@github.com (mailto:%22Raphael%20Grimm%22%20<notifications@github.com>)> wrote: As someone who uses this library and extends it for my own projects (e.g. generating the glue code from h5cpp-compiler with a macro), I would question the reasoning behind making this library c++11 compliant. Using c++17 reduces the amount of code necessary (e.g. with if constexpr). This improves readability and thus code quality (less code to make mistakes) and maintainability (easier to spot mistakes). Furthermore this library already depends on c++17 and so do all downstream projects (Upgrading from c++11 to c++17 would be a different issue). Altogether i don't think it makes a lot of sense to use a standard which is eight years old and would vote for declaring this project as c++17 (at least my fork will stay c++17). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#9?email_source=notifications&email_token=ACQTY3ROK3Q56HTRWMTPUQLP7VRMNA5CNFSM4F3STUF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ72ANA#issuecomment-511680564), or mute the thread (https://github.com/notifications/unsubscribe-auth/ACQTY3WPHBNFEC5YBVWQIZDP7VRMNANCNFSM4F3STUFQ).

[barcode]

Ok, this means i will create PRs if I refactor something to c++17 while reading the source.

[steven-varga]

As of 2020 c++17 compilers are catching up; reopen ticket with strong justification if c+11 non-compliance is an issue.