Feature request: add minimum clang/gcc compiler versions to README.md

[wdconinc]

In the README.md, the text currently reads:

Compiler: sqlpp23 makes use of C++23 and requires a recent compiler and standard library.

Since C++23 adoption in compilers does not happen in a single version, it would be useful to add to this statement 1) which C++23 features are the primary language features that are used in comparison with sqlpp11, and 2) which minimal gcc and/or clang versions are known to work with sqlpp23.

I understand that (1) is a moving target, and once C++23 is used for one reason, it is free to be used for other C++23 language features too. But it would still help to assess this for other compilers that cannot be listed under (2).

[MeanSquaredError]

1. One C++23 feature that comes to mind is that sqlpp23 uses "deducing this". However I don't really think that it makes sense to maintain a list of C++23 features used in sqlpp23, because such a list is really difficult to keep up-to-date.

2. Listing minimal supported versions of GCC/Clang probably makes more sense than listing used C++23 features, but I think there hasn't been extensive testing/checking of various GCC/Clang versions against sqlpp23.

The earliest version of GCC that I've used with sqlpp23 was g++ (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7) and it worked just fine (if we ignore various bugs/limitations of sqlpp23 that have been fixed later).

If you want to use sqlpp23 as module(s), it gets more complicated. You need GCC 15.2 or newer, but there are also requirements for the other programs. You need CMake 4.0 or newer + Ninja generator (earlier versions of CMake or the generic Unix Makefiles generator will not work).

I am not sure about the minimum required version for Clang (as I am a GCC user). I think that Clang 18 starting from a certain subversion should be able to compile sqlpp23 projects. And I am more or less sure that pretty much any version of Clang 19 should be able to compile sqlpp23 project just fine.

For modules again it gets more complicated and you need Clang 21 (not sure about earlier versions). You also need CMake 3.28 or newer and again the Ninja generator.

Also I am experimenting with Xmake at the moment and it seems to be a good alternative to CMake if you want to use sqlpp23 as module(s). But you will probably need the bleeding edge version of Xmake if you decide to use that build system.

[rbock]

+1 to the above.

We also know that MSVC 19.42.34435.0 is sufficient for building without modules.

The minimal version is unknown, but we can report known working versions. For use with modules it is (not very prominently) documented here:

As of September 2025 (version 0.67), this is still evolving, but all tests build and pass with modules using either

    clang++-20.1.2
    g++-15.2

We could move something like this to the main README.

[MeanSquaredError]

+1 to what @rbock said.

We could move something like this to the main README.

Adding the info to the README indeed makes sense, and it probably also makes sense to keep the modules-specific part in modules.md too, and also add there a bit of info about the versions of the other programs (CMake and Ninja) because for modules usage these requirements are a bit stricter than for the headers usage.

[wdconinc]

I was playing around with adding a CI workflow for a matrix of gcc and clang versions, with and without modules. See wdconinc#2 and in particular https://github.com/wdconinc/sqlpp23/actions/runs/18013675480/job/51252884917?pr=2.

The output is indicating some platform failures, but I assume some are to be expected.

Let me know if you would like me to contribute this as a PR. It is not as fine-grained on the minor versions, but right now it has gcc 14 and clang 18-21 (other versions not supported or not available on the ubuntu-24.04 platform in GitHub Actions, in particular not gcc-15).

[wdconinc]

The issues with libc++ are the likely all the same: libc++ doesn't have std::ranges::views::enumerate needed in

sqlpp23/tests/core/usage/statement/select.cpp

Lines 80 to 83 in edddb39

	for ([[maybe_unused]] const auto& [index, row] :
	db(select(foo.id).from(foo)) | std::ranges::views::enumerate) {
	// do something with index and row
	}

See also https://godbolt.org/z/84xqE8qae, llvm/llvm-project#73617

[MeanSquaredError]

A bit of googling shows that libc++ seems to be notorious for its bad support for ranges. Do you know of a web page/document that lists the subset of std::ranges supported by libc++?

I can prepare a PR that replaces the call to std::views::enumerate with calls to std::views::filter and/or std::views::transform, but I am not sure if libc++ actually supports those.

[MeanSquaredError]

It seems that this page https://libcxx.llvm.org/Status/Cxx23.html lists the libc++ support for the various C++23 features.

[wdconinc]

I can prepare a PR that replaces the call to std::views::enumerate with calls to std::views::filter and/or std::views::transform, but I am not sure if libc++ actually supports those.

wdconinc#3 fixes the enumerate issues with a zip on iota. Now passes for clang >= 19, with libc++, without modules (still fails with modules).

[MeanSquaredError]

Oh, it seems that you posted your message at the same time as I submitted the PR. My solution was to wrap the offending code in #ifndef _LIBCPP_VERSION.

But I think that your solution is fine too, so I don't mind it being used instead. Or maybe both should be added to the test.

[MeanSquaredError]

Now thinking about it, adding both tests won't hurt. So why don't you create a PR too?

[wdconinc]

Now thinking about it, adding both tests won't hurt. So why don't you create a PR too?

Let's get your PR merged first. It'd only result in a merge conflict now.

[rbock]

Thanks for the detailed analysis, the intense discussion, and the PRs resulting from it! Much appreciated.