STL VS C++ Format

As a reminder (you've probably seen this, but maybe not everyone), I am still accepting bug bash reports, if anyone is super excited about trying out the code.

There are indeed bugs, but it's getting close to handling the entire Standard Library. I'm still accepting STL Modules Bug Bash reports, if you can find novel bugs (see the tracking issue microsoft/STL#1694 for known bugs).

Standard Library Modules are coming soon. You can experiment with them (and report issues) by following the instructions at https://github.com/StephanTLavavej/STL/wiki/Standard-Library-Modules-Bug-Bash .

C++23 Standard Library Modules were just officially accepted into the Working Paper. My bug bash for the implementation-in-progress was successful, with many great bugs reported (and most worked around, to the limit of my ability in the library). VS 2022 17.4 Preview 1, released today, contains more fixes for named modules. I'm now close to having a PR prepared for review - just need to add automated testing and do some setup work (as we need to ship a new directory with new files). I can't promise anything yet, but I am very tentatively hopeful that we'll be able to merge this for 17.5.

Agreed - I'm running the Standard Library Modules Bug Bash until end of day today, but I'll continue to accept bug reports afterwards (and will hopefully have time to create a full PR for modules soon).

They should! If you use MSVC as one of your compilers, can you try my upcoming implementation of Standard Library Modules? My bug bash is running for another week, and getting bug reports will help us fix issues in the compiler and library so modules will be usable sooner. (That is, bugs that affect import std; will likely affect people writing their own named modules too.)

If you use MSVC, can you help me test them in the modules bug bash I'm running for the next 2 weeks?

Continuation passing monads form the basis of a perfectly valid and usable software architecture and programming pattern.

In the case of ostream and operator<<, this pattern reduces the number of intermediate objects that would otherwise be constructed.

If you object to iostream on religious or stylistic grounds, there's always fmt which is more like Go or Python string interpolation.[0]

0. https://fmt.dev

GitHub repo: fmtlib/fmt

cmake_minimum_required(VERSION 3.5) project(knn_cpp CXX) # Set up C++ version and properties include(CheckIncludeFileCXX) check_include_file_cxx(any HAS_ANY) check_include_file_cxx(string_view HAS_STRING_VIEW) check_include_file_cxx(coroutine HAS_COROUTINE) set(CMAKE_CXX_STANDARD 20) set(CMAKE_BUILD_TYPE Debug) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # Copy data file to build directory file(COPY ${CMAKE_CURRENT_SOURCE_DIR}/iris.data DESTINATION ${CMAKE_CURRENT_BINARY_DIR}) # Download library usinng FetchContent include(FetchContent) FetchContent_Declare(matplotplusplus GIT_REPOSITORY https://github.com/alandefreitas/matplotplusplus GIT_TAG origin/master) FetchContent_GetProperties(matplotplusplus) if(NOT matplotplusplus_POPULATED) FetchContent_Populate(matplotplusplus) add_subdirectory(${matplotplusplus_SOURCE_DIR} ${matplotplusplus_BINARY_DIR} EXCLUDE_FROM_ALL) endif() FetchContent_Declare( fmt GIT_REPOSITORY https://github.com/fmtlib/fmt.git GIT_TAG 7.1.3 # Adjust the version as needed ) FetchContent_MakeAvailable(fmt) # Add executable and link project libraries and folders add_executable(${PROJECT_NAME} main.cc) target_link_libraries(${PROJECT_NAME} PUBLIC matplot fmt::fmt) aux_source_directory(lib LIB_SRC) target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}) target_sources(${PROJECT_NAME} PRIVATE ${LIB_SRC}) add_subdirectory(tests)

Good catch, thanks! Fixed now. This explains why the difference was kinda low compared to another benchmark: https://github.com/fmtlib/fmt?tab=readme-ov-file#compile-tim....

> This is from C++23, right?

std::println is, yes.

> I wonder how available this is within compilers

https://en.cppreference.com/w/cpp/compiler_support says clang, gcc, and msvc all support it, though I don't know how recent those versions are off the top of my head.

In my understanding, with this specific feature, if you want a polyfill for older compilers, or to use some more cutting-edge features that haven't been standardized yet, https://github.com/fmtlib/fmt is available to you.

{fmt} has internal buffering but it's not yet exposed to users. There is a feature request for it: https://github.com/fmtlib/fmt/issues/2354. FILE buffering is not too bad but it can be easily optimized: https://www.zverovich.net/2020/08/04/optimal-file-buffer-siz....

Automatic use of operator<< when that exists was present in fmt until version 9.0.0. In version 9 you could use FMT_DEPRECATED_OSTREAM to opt in the old behaviour, but this too was removed in version 10.0.0. Now there is no way to automatically use operator<<.

You can install it https://github.com/fmtlib/fmt

Additionally, if you like low level stuff, check out libfmt (https://github.com/fmtlib/fmt) - not a big project, not difficult to understand. Or something like simdjson (https://github.com/simdjson/simdjson).