On 22/07/2023 20:49, PHO wrote:
That could be it I know shared_ptr was there but it did get extended in 17. std::thread has been there for a while but I've not used async/promise in C++ so they must be fairly new. I have async/promise extensively in typescript and I can see why you would want to use it as its one of the least messy ways of dealing with parallelism.On 7/23/23 04:14, Mike Pumford wrote:I can sympathise with not wanting to use C for such a utility but I was a bit surprised you had to go to C++17 to get shared_ptr. That's been in the C++ standard since c++11. And althought I've not done much C++ on NetBSD I certainly didn't need c++17 to use it on linux so if you did on BSD something is odd. You are right about filesystem and I can see why that would be useful for a tool doing as much directory scanning as this probably needs to.I can't recall accurately but maybe it was std::make_shared() that was missing? And yeah I absolutely needed std::async, std::promise, std::thread, and std::filesystem. I didn't want to reimplement them myself.
Give me praise for resisting the temptation of coroutines that requires C++20! Some part of my code is a bit messy because of the lack of coroutines but if I took the path people would throw stones at me in anger!In any other language a 3 year old iteration would be considered obselete and a 6 year old version would be unusable. If you are going to use C++ you might as well use the newer stuff as it makes things so much easier and way less error prone. Its not even like it has any particular impact on code size.
I've used modern C++ on some quite small embedded systems. I couldn't use std::thread but that's because the compiler didn't understand the RTOS threads. I did have a fully compatible replacement though. I think the only bit I had to avoid was the stream IO stuff as the i18n support made things quite bulky. However apart from that the rest is both CPU and code space efficient.
That's not exactly a particularly new compiler so its hardly pushing people forwards unnecessarily. 10-BETA is GCC 10 so that's no issue. Anything apart from the Redhat derived things will be using at least GCC9/10 as well. The Redhat stuff is scarily ancient in its userland. I'd hate to have to develop for it.Yup, actually I developed it on NetBSD 9 with pkgsrc GCC 8 so it surely works on older systems where GCC 8 is available.
Mike