home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

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

   Message 243,132 of 243,242   
   =?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJja to All   
   Re: "Internationalis(z)ing Code - Comput   
   02 Feb 26 21:02:51   
   
   XPost: comp.lang.fortran, comp.lang.c++   
   From: jmj@energokod.gda.pl   
      
   W dniu 24.01.2026 o 04:35, Lynn McGuire pisze:   
   > One of my programmers has been working on converting our Windows user   
   > interface, written in 450,000 lines of C++, from Ascii to Unicode for   
   > two years now.  It was a one year project to start and his latest   
   > estimate is another year to complete.   
      
   I think that this task should be named "rewrite". But I recommended   
   "clean up" instead. In the case "clean up" you have great opportunity to   
   make your app far better than previous. Modern industry approach, is   
   modularity. This is prove in many essential industry branch, and   
   especially in IIww years.   
      
   You can make your app "modular", by simply respect following rules:   
   1. Split your code in to 3 parts:   
   1) Business Logic classes;   
   2) Tool classes;   
   3) Window and widget classes.   
   This is my "programming pattern" which I call TLW "tools-logics-window"   
   pattern, and it replace more specialised MVC "model-view-controler" pattern.   
      
   2. Split your code in to few static libs.   
   NOTE: Do not push any "business logic" in to your libs. Libs must be   
   acted only as "tools". All "business logic" should remain in your core app.   
   NOTE: When you have static libs, then you can develop your libs and   
   prog. simultaneously, because they will not interfere with other   
   projects (other projects can work normally and can be upgraded later).   
      
   3. Split your code in to many dynamically loaded plug-ins.   
   NOTE 1: Create your plug-ins only in 3 cases:   
   1) for file type and network protocol formats (for tool classes);   
   2) for new algorithms (for logic classes);   
   3) for new widgets (for windows classes).   
   Note 2: In many cases one plug-in provide together new widget and new   
   algorithm;   
      
   4. Make your libs and plug-in rest code independent as far as possible   
   and make them to use minimal set of 3rd party libs dependencies.   
   NOTE: This mean that your libs and plug-ins (for tools and logic   
   classes) should not be depended of GUI libs, nor any platform specific   
   libs. In order to do this all build in types and used classes should be   
   renamed. Then, if necessary, renamed type can be easily expanded by make   
   it normal class (with earlier renamed class as a parent).   
      
   NOTE: Above I invent and covered in my monograph under title "Arch.   
   Prog. Nieuprzywilejowanych" (in eng.: "Architecture of Unprivileged   
   Programs"). I publish it in dec. 2024, on my WWW site under URL:   
      
      
      
   One more hint: Buy great and thin Stroustrup book "A Tour of C++ (C++   
   In-Depth Series" - it is all about basic C++ concepts but focused on   
   C++20. Then consider what "C++ modern parts" are worth to apply for your   
   project.   
      
   --   
   Jacek Marcin Jaworski,  Pruszcz Gd., woj. Pomorskie, Polska 🇵🇱, EU   
   🇪🇺;   
   tel.: +48-609-170-742,   najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;   
   , gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;   
   Domowa s. WWW:                             ;   
   Mini Netykieta:         ;   
   Mailowa Samoobrona:             .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

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


(c) 1994,  bbs@darkrealms.ca