c++17 compiler test needs -std=c++17

[prlw1]

c++17 compiler test needs -std=c++17

[jtv]

This is the expected behaviour. The configure script used to try and select a C++ version, but it was an ugly can of worms. So I made it the caller's choice.

So, if your compiler compiles an older version of C++ by default, you'll need to pass an option to select a version.

For example: ./configure CXXFLAGS=-"std=c++17"

[prlw1]

Ah: I thought that as you want c++17, you would set that standard via compiler flags, but now I see that you really want >= 17, so don't want to be limited to c++17 if the compiler can do c++20 or more... so notabug

[jtv]

Exactly! Plus, other compilers may have different flags... Like I said, ugly can of worms. :-)

[gdt]

I think this is still buggy. The basic issue is that various compilers have various defaults for std. It would be reasonable to default to adding --std=c++17, and to have an --enable-c++20 that instead sets --std=c++20, and add --enable-foo as needed and tested in the future. Right now, someone with a compiler that supports c++17 but defaults to c++14 will likely get mysterious errors, and this decision pushes surprising work onto everyone that builds this.

[KayEss]

I wonder if it wouldn't be better to detect the availability during the configure step and drop a HAVE_xx macro in the header file -- then there won't be an ODR violation because the capabilities will be fixed.

[gdt]

My impression is that standard practice is to test if the compiler accepts the --std flag you want, and to fail otherwise. Testing for an acceptable std flag and HAVE is certainly a reasonable expansion of that.

[KayEss]

compiler accepts the --std flag you want

This gets messy very quickly across all of the compilers libpqxx supports, which is why it's left to the user to decide what they want

[jtv]

Mixing binaries compiled by different compilers is a bad idea in C++ -unlike with C there is no guarantee that they will be compatible. Yes a few compilers are ABI-compatible with gcc, but even that is thin ice. Different versions of the same compiler aren't necessarily ABI-compatible. The same C++ version on the same version of the same compiler isn't necessarily ABI-compatible depending on compiler options.

So the answer IMO is not "make it easier to do something dangerous," but "if you know what you're doing you're free to do it, but you'll have to know what you're doing." Even if what you want is quite simple, it has to be a decision that you make in your build environment - because there are no standards to protect you from the agony of choice.

As a point of comparison, even autoconf-archive didn't have even a halfway decent solution to this. CMake basically addresses it by dictating versions and options and assuming it knows all compilers intimately. That just doesn't scale - libpqxx has to work on platforms I haven't even heard of.

[jtv]

Perhaps you're right @KayEss that I should go back to doing all the compiler/libpq feature checks at configure time... but it's a royal pain and I was fervently hoping to phase most of them out in favour of simple compile-time checks.

Then again... given that mixing object files built for different C++ versions breaks ABI compatibility, and worse, debug options can break runtime compatibility of memory layouts anyway... perhaps it's just not worth trying to solve this. Perhaps it would be more helpful to try and detect incompatible combinations.

[KayEss]

in favour of simple compile-time checks

I totally get that. It's what I'm doing in my projects and it is nice. But it seems there are also hidden dangers.

You have it harder if you mean to support both cmake and autoconf though -- it means doing these checks twice. You also have to consider what happens when libpqxx is packaged -- it seems right now that's quite likely to break because people using the packaged version have no control over how it was compiled.