[spnda]

adds the <cstdlib> include required for malloc, free, and posix_memalign.

also fixed two other includes to use the correct C++ headers instead of the C headers

[dougbinks]

adds the include required for malloc, free, and posix_memalign

Could you let me know what the compile error output is and on which compiler?

also fixed two other includes to use the correct C++ headers instead of the C headers

The C++ headers are no more correct than the C headers, and they have a higher compile time cost. I would prefer to remain with the C headers.

[spnda]

Could you let me know what the compile error output is and on which compiler?

It's Clang 23.1.0. This is the output when compiling from the main branch:

/opt/homebrew/opt/llvm/bin/clang++ -DENKITS_TASK_PRIORITIES_NUM=3 -I/path/to/project/build/cmake-release/_deps/enkits-src/src -march=native -fsanitize=address -pthread -std=c++11 -stdlib=libc++ -O3 -DNDEBUG -arch arm64 -fcolor-diagnostics -MD -MT _deps/enkits-build/CMakeFiles/enkiTS.dir/src/TaskScheduler.cpp.o -MF _deps/enkits-build/CMakeFiles/enkiTS.dir/src/TaskScheduler.cpp.o.d -o _deps/enkits-build/CMakeFiles/enkiTS.dir/src/TaskScheduler.cpp.o -c /path/to/project/build/cmake-release/_deps/enkits-src/src/TaskScheduler.cpp
/path/to/project/build/cmake-release/_deps/enkits-src/src/TaskScheduler.cpp:204:16: error: use of undeclared identifier 'malloc'
  204 |         pRet = malloc( size_ );
      |                ^~~~~~
/path/to/project/build/cmake-release/_deps/enkits-src/src/TaskScheduler.cpp:208:22: error: use of undeclared identifier 'posix_memalign'
  208 |         int retval = posix_memalign( &pRet, align_, size_ );
      |                      ^~~~~~~~~~~~~~
/path/to/project/build/cmake-release/_deps/enkits-src/src/TaskScheduler.cpp:221:5: error: use of undeclared identifier 'free'
  221 |     free( ptr_ );
      |     ^~~~

The C++ headers are no more correct than the C headers, and they have a higher compile time cost. I would prefer to remain with the C headers.

When compiling C++ the C++ specification technically does not guarantee that the C headers exist. It's a technicality and realistically not something to worry about, however it is technically not standard code. Also, yes they might incur a slightly higher cost, but they all quickly boil down to this (this is from <cassert>):

#if __cplusplus < 201103L && defined(_LIBCPP_USE_FROZEN_CXX03_HEADERS)
#  include <__cxx03/cassert>
#else
#  include <__config>

// <assert.h> is not provided by libc++
#  if __has_include(<assert.h>)
#    include <assert.h>
#    ifdef _LIBCPP_ASSERT_H
#      error "If libc++ starts defining <assert.h>, the __has_include check should move to libc++'s <assert.h>"
#    endif
#  endif

#  if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
#    pragma GCC system_header
#  endif
#endif // __cplusplus < 201103L && defined(_LIBCPP_USE_FROZEN_CXX03_HEADERS)

And in the example of <cstdlib> it just includes <stdlib.h> and then defines the aliases into the std:: namespace. It's just good practice C++, but I can still revert that part if you really want.

[dougbinks]

It's Clang 23.1.0. This is the output when compiling from the main branch:

Thanks, that's helpful.

It's just good practice C++

I am not a big fan of what most C++ people call good practice, and enkiTS is partially a reaction to that. Adding extra cruft over long established functions to add them to a namespace does not seem to be a real advantage in practical terms. cstdint on the most widely used compiler in my field (MSVC) pulls in yvals_core.h which is ~2000 lines long for example.

I can still revert that part if you really want.

Yes please.

Many thanks for the PR and speedy responses.

[dougbinks]

Merged, many thanks.