Subj : Compilers/systems
To : andrew clarke
From : Nil Alexandrov
Date : Tue Feb 07 2023 03:05 pm
Hello, andrew!
Wednesday February 08 2023 06:52, from andrew clarke -> Vitaliy Aksyonov, in URL @OFGHIUrl:
ac> so anyone with that compiler should still be able to build a version
ac> that will run in XP unless you're using a new C++ feature from C++11
ac> or C++20 that VS2012 doesn't support.
I really appreciate Vitaliy's intent/effort to replace malloc() allocations together with the memset/memcpy hacks with the standard C++ constructor workflow but here is the thing. GoldED codebase is based off some "C with classes" version of C++ and those memset/memcpy hacks were the optimization you can apply in pre-c++11 era without the rvalue move semantics.
ac> But for GoldED it shouldn't really be necessary to refactor the code
ac> using C++'s increasingly estoric features. Instead, just using
ac> features from the STL would be a big improvement.
I was saying in that Russian speaking ru.golded echo-conference, that just replacing C-style data structures like single/doubly linked lists, hashes, dynamic arrays, char* strings and friends with std::vector, std::list, std::string, you name it will trash about 20% of the GoldED code. But still, pre-c++11 language has no RVO, so you will have to return objects via the pointer/reference passing as a function argument most of the time, then not even defined memory model! though, GoldED is a single-threaded application, so nobody cares.
To sum up my brain farts, if it were say Husky project with plain-C there would be no question to continue refactoring in old plain C, but here with the OOP C++ style code we would prefer to get at least to C++11 level, otherwise just go ahead and fix delete[]/delete stuff and call it a day.
