Thomas Pöchtrager

> I have removed all size_t maybe two months ago, along removing the possibility to replace ImVector by user's implementation (or std::vector). It made the code much shorter, actually faster,...

> That still leads to lots of signed/unsigned casting in the code and in user's code, with higher warning settings that sort of casting never ends to spread. I initially...

> Yes they do. It makes it really tedious to maintain 32+64 bits code with high level of warnings. > (I was referring to the stb library not std) Yes,...

> But both i and Size are 'int' I don't understand why they would need a cast at all. int < int is valid. That static-overflow warning wouldn't even apply...

> If it follows inlining this way I don't quite understand why we don't have warnings everywhere in the code every ten lines. It definitely looks like a backend warning,...

Better not, because I use https://code.google.com/p/ios-toolchain-based-on-clang-for-linux/ for compiling stuff for iOS, so I can't test it with xcode, sorry.

It's because of wrong headers, see https://github.com/mz2/boostoniphone/issues/6

You could try to find the missing tools here: https://github.com/orgs/apple-oss-distributions/repositories?type=all. I am not sure if all of them are open source though.

Thank you for your feedback. I am not sure if `-arch arm64e` is doing what it's supposed to do. The latest linker warns about an `incompatible arm64e ABI compiler`. $...

Seems like you must use Apple's LLVM/Clang version due to `lto_codegen_hide_symbols` not being present in upstream LLVM/Clang. wget https://opensource.apple.com/tarballs/clang/clang-800.0.42.1.tar.gz tar xf clang-800.0.42.1.tar.gz cd clang-800.0.42.1 mkdir build cd build cmake ../src...