home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   GOLDED      GoldED Public Release discussion.      2,690 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,011 of 2,690   
   Nil Alexandrov to andrew clarke   
   Compilers/systems   
   07 Feb 23 15:05:16   
   
   REPLY: 3:633/267 63e2abf5   
   MSGID: 1:16/101 63e2b37d   
   CHRS: LATIN-1 2   
   TZUTC: -0500   
   TID: hpt/lnx 1.9.0-cur 14-08-16   
   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)   
   SEEN-BY: 1/120 123 4/0 15/0 16/101 18/0 200 50/109 80/1 88/0 90/0   
   SEEN-BY: 90/1 92/1 103/705 104/117 105/81 106/201 116/116 120/340   
   SEEN-BY: 123/0 25 131 170 180 200 755 3001 129/305 135/300 138/146   
   SEEN-BY: 153/757 7715 154/10 218/700 221/1 6 222/2 226/30 227/114   
   SEEN-BY: 229/110 111 112 113 114 206 307 317 400 424 426 428 452 470   
   SEEN-BY: 229/664 700 230/152 240/1120 250/1 261/38 100 266/512 275/100   
   SEEN-BY: 275/1000 280/464 5555 282/1038 1056 292/854 299/6 301/1 113   
   SEEN-BY: 301/123 812 317/3 320/219 322/757 335/364 341/66 342/11 200   
   SEEN-BY: 396/45 460/58 463/68 467/888 633/280 712/848 1321 801/161   
   SEEN-BY: 801/188 189 194 197 900/0 100 102 105 106 108 902/0 7 10   
   SEEN-BY: 902/19 25 26 27 100 3634/0 12 27 57 119 5000/111 5001/100   
   SEEN-BY: 5005/49 5015/46 5020/828 846 1042 4441 5030/49 5054/8 5058/104   
   SEEN-BY: 5064/56 5075/128 5083/444 5090/958   
   PATH: 16/101 261/38 153/7715 3634/12 5020/1042 301/1 80/1 90/1   
   PATH: 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca