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.

Best Regards, Nil
--- GoldED+/LNX 1.1.5
 * Origin: -=NIL BBS=- (1:16/101)

.