Added define C++20

[Jamaika1]

I use C++17. VVENC and X265 aren't optimized for C++20.

[bradh]

The project is c++20, see top level CMake configuration. You can build dependencies with other build chains though.

[Jamaika1]

I know that. This is for those who build in static gcc. Then there will be no this function.

[bradh]

It looks like this will break decoding on big endian machines - it'll silently produce corrupted results.

[Jamaika1]

This is true, but I am not able to convert std::edian to c++17.
https://stackoverflow.com/questions/71003780/standard-compliant-host-to-network-endianess-conversion

[bradh]

What is the real problem with C++-20?

What doesn't work in vvenc or x265? You say "not optimised", but I'm not sure why standards compatibility would affect optimisation. If it does, can you build those with different build chains and just use a linker option?

[Jamaika1]

For GNUC 11.5.0/15.0.0 in C++20 I only enabled some -Wxxx warnings. It should be -Wextra -Wall. They fixed lot in X265 after complaints but there's always something.
https://github.com/brechtsanders/winlibs_mingw/releases/download/11.5.0posix-12.0.0-ucrt-r1/winlibs-x86_64-posix-seh-gcc-11.5.0-mingw-w64ucrt-12.0.0-r1.zip
for %%f in ("%~dp1*.cpp") do g++.exe -std=gnu++20 -static -march=x86-64-v3 -ftree-vectorize -g0 -O3 -fPIC -mavx2 -mpclmul -maes -mbmi2 -mfma -mf16c -Wcomment -Wformat -Wshift-negative-value -Wsign-compare -Wtype-limits -Warray-bounds -Wparentheses -Wlogical-not-parentheses -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -D_WIN32_WINNT_WIN7=0x0601 -DEXPORT_C_API=1 -DX265_NS=x265 -DLINKED_10BIT=1 -DLINKED_12BIT=1 -DX86_64=1 -DHIGH_BIT_DEPTH=0 -DX265_DEPTH=8 -DX265_ARCH_X86=1 -c %%f -o %%~nf.o

frameencoder.cpp: In member function 'virtual void x265_10bit::FrameEncoder::processRowEncoder(int, x265_10bit::ThreadLocalData&, int)':
frameencoder.cpp:1736:16: warning: '++' expression of 'volatile'-qualified type is deprecated [-Wvolatile]
 1736 |         curRow.completed++;
      |         ~~~~~~~^~~~~~~~~

sao.cpp: In member function 'void x265_12bit::SAO::rdoSaoUnitCu(x265_12bit::SAOParam*, int, int, int)':
sao.cpp:1242:66: warning: arithmetic between different enumeration types 'x265_12bit::SAO::<unnamed enum>' and 'x265_12bit::SAOType' is deprecated [-Wdeprecated-enum-enum-conversion]
 1242 |     X265_CHECK(sizeof(PerPlane) == (sizeof(int32_t) * (NUM_PLANE * MAX_NUM_SAO_TYPE * MAX_NUM_SAO_CLASS)), "Found Padding space in struct PerPlane");
      |                                                        ~~~~~~~~~~^~~~~~~~~~~~~~~~~~
common.h:113:37: note: in definition of macro 'X265_CHECK'
  113 | #define X265_CHECK(expr, ...) if (!(expr)) { \
      |                                     ^~~~

scalinglist.cpp: In member function 'bool x265_12bit::ScalingList::checkDefaultScalingList() const':
scalinglist.cpp:207:41: warning: arithmetic between different enumeration types 'x265_12bit::ScalingList::<unnamed enum ' and 'x265_12bit::ScalingList::<unnamed enum>' is deprecated [-Wdeprecated-enum-enum-conversion]
  207 |     return defaultCounter != (NUM_LISTS * NUM_SIZES - 4); // -4 for 32x32
      |                               ~~~~~~~~~~^~~~~~~~~~~

In file included from framedata.h:29,
                 from cudata.cpp:27:
cudata.h: In member function 'bool x265::CUData::setQPSubCUs(int8_t, uint32_t, uint32_t)':
cudata.h:274:112: warning: array subscript 5 is above array bounds of 'void (* [5])(uint8_t*, uint8_t)' {aka 'void (* [5])(unsigned char*, unsigned char)'} [-Warray-bounds]
  274 |     void     setQPSubParts(int8_t qp, uint32_t absPartIdx, uint32_t depth)                    { s_partSet[depth ((uint8_t*)m_qp + absPartIdx, (uint8_t)qp); }
      |                                                                                                 ~~~~~~~~~~~~~~~
In file included from framedata.h:29,
                 from cudata.cpp:27:
cudata.h:177:15: note: while referencing 'x265::CUData::s_partSet'
  177 |     cubcast_t s_partSet[NUM_FULL_DEPTH]; // pointer to broadcast set functions per absolute depth
      |               ^~~~~~~~~

[fancycode]

I don't see how changing a C++ file here fixes compilation problems in x265.

[Jamaika1]

Warming for vvenc. In theory for c/c++23 and older everything should work.

In file included from MCTF.cpp:52:
../Utilities/NoMallocThreadPool.h: In lambda function:
../Utilities/NoMallocThreadPool.h:163:31: warning: implicit capture of 'this' via '[=]' is deprecated in C++20 [-Wdeprecated]
  163 |     nonconst->m_cond.wait( l, [=] { return !m_intBarrier.isBlocked(); } );
      |                               ^
../Utilities/NoMallocThreadPool.h:163:31: note: add explicit 'this' or '*this' capture

Compatible with MSVC only

CommonDef.h:571:62: warning: ignoring attributes on template argument 'void(void*, int, const char*, va_list)' {aka 'void(void*, int, const char*, char*)'} [-Wignored-attributes]
  571 | extern std::function<void( void*, int, const char*, va_list )> g_msgFnc;
      |                                                              ^
In file included from dtrace_next.h:52,
                 from AdaptiveLoopFilter.cpp:54:
../Utilities/MsgLog.h:101:57: warning: ignoring attributes on template argument 'void(void*, int, const char*, va_list)' {aka 'void(void*, int, const char*, char*)'} [-Wignored-attributes]
  101 |   std::function<void( void*, int, const char*, va_list )> m_msgFnc{};
      |                                                         ^

If the user went too far and used ffmpeg c/c++23 with lcevc
v-novaltd/LCEVCdec#10

[silverbacknet]

As was said before, just build libheif with C++20 and anything else with C++17 or C++98 or Rust or whatever it needs. There's absolutely no reason you must to build every dependency with the same toolchain.

[Jamaika1]

Interesting. Only from what I understand how to combine .dll files of different codecs in different c/c++ languages ​​in gcc? It's not possible in static.
I don't use Rust because I don't know how to use it. I assume like nasm.

https://stackoverflow.com/questions/63491270/is-it-possible-to-compile-a-project-with-two-different-language-standards
Here's a bigger problem from c98 to c23.

[kmilos]

It's not possible in static

Why not? Build each dependency individually/separately as static with their own C++ standard level and link them to libheif statically. The only problem could arise if the API itself of some library uses some specific C++level features...

[silverbacknet]

You're afraid of something that doesn't apply here. The biggest blocker in mixing compilers is allocating memory in a library and freeing it outside the library, or vice versa, or in using standard library components allocated in one in the other. This is incredibly bad form and is very rarely seen in any kind of modern code, for this exact reason. (You normally even get away with that if it's the same compiler just targeting different standards.)

libheif communicates with its libraries entirely through a C interface, so no C++ features can cross without absurd efforts, and the libraries are all reasonable enough to own their own memory. Private data structures don't get passed around willy-nilly, mostly only the raw decoded data pointers.

So it's perfectly fine to compile the codec libraries completely separately from libheif, even mixing MSVC and GCC if you want -- at worst, you might get a linker error if their standard libraries are too different -- but everything GCC will always work.

(Unfortunately there's a lot of older code where ownership is passed to another component that might have a completely different idea of how allocation works. Avisynth was a prime example, because "of course everyone would use VC6 forever," and it was very painful to make it compiler-agnostic without breaking compatibility.)