Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123321 > unrolled thread

"Internationalis(z)ing Code - Computerphile"

Back to article view | Back to comp.lang.c++

Contents

  "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-23 21:35 -0600
    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-24 04:46 +0000
      Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-01-24 10:11 -0600
    Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-25 17:13 +0000
      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-25 15:21 -0600
        Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-01-26 01:00 +0100
          Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-01-26 15:04 +0000
        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-26 01:42 +0000
          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-26 00:45 -0600
            Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-01-26 14:17 +0200
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-26 16:50 -0600
          Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-01-26 09:07 +0100
            Re: "Internationalis(z)ing Code - Computerphile" Paavo Helde <eesnimi@osa.pri.ee> - 2026-01-30 14:56 +0200
              Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-01-30 14:37 +0100
            Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-30 20:28 +0000
              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-01-31 12:50 +0100
                Re: "Internationalis(z)ing Code - Computerphile" G <g@nowhere.invalid> - 2026-01-31 18:50 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-01-31 16:10 -0600
                    Re: "Internationalis(z)ing Code - Computerphile" ImperiusDamian <dgwrightauthor@gmail.com> - 2026-01-31 21:08 -0500
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-01 09:06 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2026-02-02 11:18 +0100
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-02 21:23 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2026-02-03 10:33 +0100
                            Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 21:29 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-01 11:18 +0100
                      Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-02-01 08:28 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-01 09:42 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-01 11:35 +0100
                    Re: "Internationalis(z)ing Code - Computerphile" James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-01 12:21 -0500
                      Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-01 23:01 +0100
                        Re: "Internationalis(z)ing Code - Computerphile" James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-01 19:11 -0500
                          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-02 04:31 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-02 11:27 +0100
                            Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-02 12:49 +0200
                              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-02 13:14 +0100
                                Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-02 16:07 +0100
                            Re: "Internationalis(z)ing Code - Computerphile" James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-02 09:36 -0500
                              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-02 16:01 +0100
                                Re: "Internationalis(z)ing Code - Computerphile" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-02 16:19 +0100
        Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-26 22:47 +0000
          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-26 16:51 -0600
          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-27 05:17 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-01-27 06:45 +0000
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-01-27 01:46 -0600
                Re: "Internationalis(z)ing Code - Computerphile" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-27 00:14 -0800
                  Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-01-27 15:22 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-27 12:33 -0800
                Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-01-27 11:04 +0200
                  Re: "Internationalis(z)ing Code - Computerphile" Gary Scott <garylscott@sbcglobal.net> - 2026-01-27 08:35 -0600
            Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-01-27 15:21 +0000
    Re: "Internationalis(z)ing Code - Computerphile" Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-31 02:06 +0000
    Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-02 21:02 +0100
      Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-02 21:13 +0100
      Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-02 21:25 +0000
      Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-03 10:54 +0200
        Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-03 10:44 +0100
          Re: "Internationalis(z)ing Code - Computerphile" Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-03 09:47 -0500
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-03 16:02 +0100
              Re: "Internationalis(z)ing Code - Computerphile" Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-04 08:45 -0500
          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-03 21:32 +0000
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-03 22:56 +0100
              Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 00:15 +0000
                Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-04 09:37 +0100
        Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-03 17:28 -0600
          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 00:14 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-03 20:17 -0600
              Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-04 04:57 +0000
                Re: "Internationalis(z)ing Code - Computerphile" Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-04 08:54 -0500
                  Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:43 -0600
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:09 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 15:47 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 22:35 +0000
            Re: "Internationalis(z)ing Code - Computerphile" scott@slp53.sl.home (Scott Lurndal) - 2026-02-04 15:44 +0000
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:53 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:10 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-05 12:10 +0200
                Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-07 09:23 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:25 -0600
          Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-04 14:24 +0200
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-04 16:57 +0100
            Re: "Internationalis(z)ing Code - Computerphile" 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-02-04 17:16 +0100
              Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:57 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:11 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 16:55 -0600
              Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-05 12:24 +0200
          Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-04 19:20 +0000
            Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-04 17:07 -0600
              Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-05 07:23 +0000
                Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 09:14 +0000
                  Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 16:01 -0600
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 22:30 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 20:22 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-06 04:50 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 23:52 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Harold Stevens <wookie@aspen.localdomain> - 2026-02-06 04:24 -0600
                Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-05 12:02 +0200
                  Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-05 18:38 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-13 17:21 -0600
                Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-05 11:13 +0100
                Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-05 15:58 -0600
                  Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-07 19:15 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-07 20:34 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-08 08:58 +0000
                        Re: "Internationalis(z)ing Code - Computerphile" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-08 04:07 -0800
                          Re: "Internationalis(z)ing Code - Computerphile" Michael S <already5chosen@yahoo.com> - 2026-02-08 15:39 +0200
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-08 23:35 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:33 -0600
                        Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-10 20:55 +0000
                          Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-10 18:57 -0600
                            Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-11 05:57 +0000
                              Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-11 14:32 +0100
                                Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-11 20:46 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:29 -0600
                      Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-10 06:10 +0000
                    Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-09 15:32 -0600
                      Re: "Internationalis(z)ing Code - Computerphile" Thomas Koenig <tkoenig@netcologne.de> - 2026-02-10 06:07 +0000
                      Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-10 20:17 +0000
                        Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-10 20:07 -0600
                          Re: "Internationalis(z)ing Code - Computerphile" Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-11 05:54 +0000
                            Re: "Internationalis(z)ing Code - Computerphile" David Brown <david.brown@hesbynett.no> - 2026-02-11 14:42 +0100
      Re: "Internationalis(z)ing Code - Computerphile" Lynn McGuire <lynnmcguire5@gmail.com> - 2026-02-03 17:32 -0600

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#123421

W dniu 4.02.2026 o 13:24, Michael S pisze:
> at very least, anything related to speed
> that C++ can do, C can do as well, but I would be very surprised if
> there no other options beyond C

There is also FreePascal:

<https://www.freepascal.org>

But I am unsure if it has templates, but I am sure that D it has.

-- 
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;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW:                             <https://energokod.gda.pl>;
Mini Netykieta:         <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona:             <https://emailselfdefense.fsf.org/pl>.

[toc] | [prev] | [next] | [standalone]

#123426

On 2/4/2026 10:16 AM, 🇵🇱Jacek Marcin Jaworski🇵🇱 wrote:
> W dniu 4.02.2026 o 13:24, Michael S pisze:
>> at very least, anything related to speed
>> that C++ can do, C can do as well, but I would be very surprised if
>> there no other options beyond C
> 
> There is also FreePascal:
> 
> <https://www.freepascal.org>
> 
> But I am unsure if it has templates, but I am sure that D it has.

Nope.  I moved from Turbo Pascal to C in 1987 and never looked back.

Lynn

[toc] | [prev] | [next] | [standalone]

#123431

On Wed, 4 Feb 2026 16:57:40 -0600, Lynn McGuire wrote:

> On 2/4/2026 10:16 AM, 🇵🇱Jacek Marcin Jaworski🇵🇱 wrote:
>>
>> There is also FreePascal:
>>
>> <https://www.freepascal.org>
>>
>> But I am unsure if it has templates, but I am sure that D it has.
>
> Nope. I moved from Turbo Pascal to C in 1987 and never looked back.

In a language where functions and classes are first-class objects, you
don’t need templates.

[toc] | [prev] | [next] | [standalone]

#123425

On 2/4/2026 6:24 AM, Michael S wrote:
> On Tue, 3 Feb 2026 17:28:35 -0600
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> On 2/3/2026 2:54 AM, Michael S wrote:
>>> On Mon, 2 Feb 2026 21:02:51 +0100
>>> 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> wrote:
>>>    
>>>> 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.
>>>>   
>>>
>>> It seems to me that industry trend in GUI programming is to stay as
>>> far away from C++ as possible.
>>> JS is a king.
>>> C#, Swift, Kotlin are second choice.
>>> Even Java is still used for new development in this feild, despite
>>> technically being almost as unsuitable as C++.
>>> But C++ is strictly legacy, no new, from scratch GUI development is
>>> done in this language for something like 15 years.
>>>
>>> Of course, the statement above is "at large". The world is a big
>>> place and one can always find one developer or one hundred or ten
>>> thousands that make unusual sub-optimal choices.
>>
>> I am swinging huge datasets for simulation models from 1 MB to 1,000
>> MB. Nothing besides C++ has the oomph and speed to make this happen.
>>
>> Lynn
>>
> 
> I am not sure what "swinging" means in this context and whether other
> languages can do it or not (at very least, anything related to speed
> that C++ can do, C can do as well, but I would be very surprised if
> there no other options beyond C).
> But all that sounds off topic.
> The topic is user interface code (a.k.a. GUI) rather than "swinging".
> C++ used to be a popular choice for coding user interfaces, but it
> ceased to be popular long time ago.

My variant of "swinging" means to load an entire dataset into memory 
which used to be very common for desktop software like mine.

Lynn

[toc] | [prev] | [next] | [standalone]

#123436

On Wed, 4 Feb 2026 16:55:28 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> On 2/4/2026 6:24 AM, Michael S wrote:
> > On Tue, 3 Feb 2026 17:28:35 -0600
> > Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> >   
> >> On 2/3/2026 2:54 AM, Michael S wrote:  
> >>> On Mon, 2 Feb 2026 21:02:51 +0100
> >>> 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> wrote:
> >>>      
> >>>> 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.
> >>>>     
> >>>
> >>> It seems to me that industry trend in GUI programming is to stay
> >>> as far away from C++ as possible.
> >>> JS is a king.
> >>> C#, Swift, Kotlin are second choice.
> >>> Even Java is still used for new development in this feild, despite
> >>> technically being almost as unsuitable as C++.
> >>> But C++ is strictly legacy, no new, from scratch GUI development
> >>> is done in this language for something like 15 years.
> >>>
> >>> Of course, the statement above is "at large". The world is a big
> >>> place and one can always find one developer or one hundred or ten
> >>> thousands that make unusual sub-optimal choices.  
> >>
> >> I am swinging huge datasets for simulation models from 1 MB to
> >> 1,000 MB. Nothing besides C++ has the oomph and speed to make this
> >> happen.
> >>
> >> Lynn
> >>  
> > 
> > I am not sure what "swinging" means in this context and whether
> > other languages can do it or not (at very least, anything related
> > to speed that C++ can do, C can do as well, but I would be very
> > surprised if there no other options beyond C).
> > But all that sounds off topic.
> > The topic is user interface code (a.k.a. GUI) rather than
> > "swinging". C++ used to be a popular choice for coding user
> > interfaces, but it ceased to be popular long time ago.  
> 
> My variant of "swinging" means to load an entire dataset into memory 
> which used to be very common for desktop software like mine.
> 
> Lynn
> 

Then I wonder what languages are *not* able to do it?
Please name a few.
Personally, I can't recollect any popular (or semi-popular) language
like that, apart from those (VB6) that never graduated into 64-bit
world.

[toc] | [prev] | [next] | [standalone]

#123422

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

> I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. 
>   Nothing besides C++ has the oomph and speed to make this happen.

Speed differences between compiled languages are reltively small.
But Fortran (where I am reading this) can certainly do so.  A pity
you missed out on Fortran's development in the last 35 years.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123427

On 2/4/2026 1:20 PM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> 
>> I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
>>    Nothing besides C++ has the oomph and speed to make this happen.
> 
> Speed differences between compiled languages are reltively small.
> But Fortran (where I am reading this) can certainly do so.  A pity
> you missed out on Fortran's development in the last 35 years.

We will see.  When I finish converting the 800,000 lines of F77 code to 
C++ in my calculation engine, I will run a timing test using my 659 + 
100 = 759 benchmark files.  I just restarted this project after a year 
or two of working on customers problems and demands.

I have over 100,000 lines of F77 converted to C++ now and the input 
parser of my chemical data regression tool is fully working.

If interested, this is what we do (8 MB PDF):
    https://www.winsim.com/media/diiw_brochure.pdf

Lynn

[toc] | [prev] | [next] | [standalone]

#123428

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 2/4/2026 1:20 PM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> 
>>> I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
>>>    Nothing besides C++ has the oomph and speed to make this happen.
>> 
>> Speed differences between compiled languages are reltively small.
>> But Fortran (where I am reading this) can certainly do so.  A pity
>> you missed out on Fortran's development in the last 35 years.
>
> We will see.

We will not see, because you made the decision to switch to C++
instead of gradually introducing modern Fortran features in your
code.  There will be no benchmark to test against.

> When I finish converting the 800,000 lines of F77 code to 
> C++ in my calculation engine, I will run a timing test using my 659 + 
> 100 = 759 benchmark files.  I just restarted this project after a year 
> or two of working on customers problems and demands.

That could be interesting.  With such a conversion test, it would
also be interesting to see how many bugs were uncovered in the
conversion process, and how many new ones were introduced.  You
may know the first number (although I totally understand if you don't
want to share), but you may never know the second one.

Do you use tools like valgrind and sanitizers?

> I have over 100,000 lines of F77 converted to C++ now and the input 
> parser of my chemical data regression tool is fully working.

Parsers are a field where Fortran does not shine, although allocatable
characters have made this much easier.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123432

On Thu, 5 Feb 2026 07:23:41 -0000 (UTC), Thomas Koenig wrote:

> Parsers are a field where Fortran does not shine, although
> allocatable characters have made this much easier.

On a *nix system, it is usual to delegate common janitorial tasks
(like parsing) to open-source libraries that already handle such jobs.

[toc] | [prev] | [next] | [standalone]

#123440

On 2/5/2026 3:14 AM, Lawrence D’Oliveiro wrote:
> On Thu, 5 Feb 2026 07:23:41 -0000 (UTC), Thomas Koenig wrote:
> 
>> Parsers are a field where Fortran does not shine, although
>> allocatable characters have made this much easier.
> 
> On a *nix system, it is usual to delegate common janitorial tasks
> (like parsing) to open-source libraries that already handle such jobs.

Parsing is not just looking at input.  It is also about converting that 
input and storing it properly in the proper data storage areas in the 
dataset.

Lynn

[toc] | [prev] | [next] | [standalone]

#123441

On Thu, 5 Feb 2026 16:01:05 -0600, Lynn McGuire wrote:

> On 2/5/2026 3:14 AM, Lawrence D’Oliveiro wrote:
>>
>> On a *nix system, it is usual to delegate common janitorial tasks
>> (like parsing) to open-source libraries that already handle such
>> jobs.
>
> Parsing is not just looking at input. It is also about converting
> that input and storing it properly in the proper data storage areas
> in the dataset.

Look at common parser libraries. They are designed to deal with
precisely these sorts of issues.

Here <https://textx.github.io/Arpeggio/latest/> is one I have used.

[toc] | [prev] | [next] | [standalone]

#123443

On 2/5/2026 4:30 PM, Lawrence D’Oliveiro wrote:
> On Thu, 5 Feb 2026 16:01:05 -0600, Lynn McGuire wrote:
> 
>> On 2/5/2026 3:14 AM, Lawrence D’Oliveiro wrote:
>>>
>>> On a *nix system, it is usual to delegate common janitorial tasks
>>> (like parsing) to open-source libraries that already handle such
>>> jobs.
>>
>> Parsing is not just looking at input. It is also about converting
>> that input and storing it properly in the proper data storage areas
>> in the dataset.
> 
> Look at common parser libraries. They are designed to deal with
> precisely these sorts of issues.
> 
> Here <https://textx.github.io/Arpeggio/latest/> is one I have used.

I can tell that you have never worked on a large software package.  You 
do not rip it up just to modernize a section of the code.

Lynn

[toc] | [prev] | [next] | [standalone]

#123444

On Thu, 5 Feb 2026 20:22:37 -0600, Lynn McGuire wrote:

> I can tell that you have never worked on a large software package.
> You do not rip it up just to modernize a section of the code.

Stop trying to cast aspersions on those offering advice.

If it can replace a bunch of code you have to rewrite anyway, it
should be worth it.

[toc] | [prev] | [next] | [standalone]

#123445

On 2/5/2026 10:50 PM, Lawrence D’Oliveiro wrote:
> On Thu, 5 Feb 2026 20:22:37 -0600, Lynn McGuire wrote:
> 
>> I can tell that you have never worked on a large software package.
>> You do not rip it up just to modernize a section of the code.
> 
> Stop trying to cast aspersions on those offering advice.
> 
> If it can replace a bunch of code you have to rewrite anyway, it
> should be worth it.

Nope.  The existing algorithm works.  There are way more pressing 
matters to fix.

Lynn

[toc] | [prev] | [next] | [standalone]

#123447

In <10m3j9e$3on86$1@dont-email.me> Lynn McGuire:

> On 2/5/2026 4:30 PM, Lawrence D’Oliveiro wrote:

[Snip...]

> I can tell that you have never worked on a large software package.  You 
> do not rip it up just to modernize a section of the code.

+1

As I noted elsewhere in another thread ,,,

Greybeard quants like me operated on 3 simple maxims:

1. Anything that works is better than anything that doesn't.
2. If it ain't broke, don't fix it.
3. If it breaks, don't ignore it.

-- 
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss (404) GoogleGroup (404 http://twovoyagers.com/improve-usenet.org/).

[toc] | [prev] | [next] | [standalone]

#123433

On Thu, 5 Feb 2026 07:23:41 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> 
> Parsers are a field where Fortran does not shine, although allocatable
> characters have made this much easier.

Another field where Fortran "does not shine" is handling of huge
uni-dimensional arrays. But 1GB is small enough, here Fortran shall be
comfortable.
 

[toc] | [prev] | [next] | [standalone]

#123437

["Followup-To:" nach comp.lang.fortran gesetzt.]
Michael S <already5chosen@yahoo.com> schrieb:
> On Thu, 5 Feb 2026 07:23:41 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> 
>> Parsers are a field where Fortran does not shine, although allocatable
>> characters have made this much easier.
>
> Another field where Fortran "does not shine" is handling of huge
> uni-dimensional arrays.

Why?

If you are referring to pre-Fortran-90 days, you are also 35
years in the past :-)

A bit more verbiage than required (usually, I would expect people
to put their kind numbers into modules):

module my_kinds
  use iso_fortran_env, only: real64, int64
  implicit none
  private
  public :: ik, rk
  integer, parameter :: ik = int64, rk = real64
end module my_kinds

program main
  use my_kinds
  implicit none
  integer(ik) :: sz
  real(rk), allocatable, dimension(:) :: array
  read (*,*) sz
  allocate(array(sz))
end program main

works just fine.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#123480

On 2/6/2026 2:48 PM, David Jones wrote:
> Thomas Koenig wrote:
> 
>> Radey Shouman <shouman@comcast.net> schrieb:
>>
>>> The size of the integer type was specified to be the same as the
>>> size of the real type.  The real type need not be 32-bit floating
>>> point, but that is certainly the way to bet.
>>
>> A famous counter-example: Cray's 64-bit REALs.
> 
> And the Univac's 36 bit reals.

I miss the Univac 1108 36 bit reals and integers.  They were perfect for 
1 ppm (1e-6) calculations, good for most of our calculations. 
Unfortunately, we had to walk away from the Univac 1108 in 1981 ? due to 
its 1 megaword addressing limit.  We had already moved to a Prime 450 in 
1977 and a Prime 750 in 1980 ? for our software development.

Double precision in 64 bit reals takes you to 1e-15 calculations 
generally.  That is actually a problem for some iterative calculations 
as the delta variable goes too small and must be tested for routinely.

Lynn

[toc] | [prev] | [next] | [standalone]

#123435

On 05/02/2026 08:23, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 2/4/2026 1:20 PM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>
>>>> I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
>>>>     Nothing besides C++ has the oomph and speed to make this happen.
>>>
>>> Speed differences between compiled languages are reltively small.
>>> But Fortran (where I am reading this) can certainly do so.  A pity
>>> you missed out on Fortran's development in the last 35 years.
>>
>> We will see.
> 
> We will not see, because you made the decision to switch to C++
> instead of gradually introducing modern Fortran features in your
> code.  There will be no benchmark to test against.
> 

There would probably be speed improvements in simply converting from old 
Fortran to re-written old Fortran - most re-writes offer plenty of scope 
for improving the structure and algorithms of old code simply because 
you have better knowledge of the real-world usage of the code, and you 
can turn old "layers of patches and modifications" code into more 
streamlined code.  Then there are more modern editors, linters, 
debuggers, etc., that let you write code in different ways (without 
losing track of what you are doing) than you could with ancient tools. 
Then there are more modern compilers that do a much better job of 
optimisation, especially tuning for running on more modern processors. 
And you can re-write the code with a view to efficiency on modern 
processors (such as by different choice of data types, consideration of 
cache, etc.).  All that comes before using a more modern language standard.

Without knowing anything about the code, the company, the programmers, 
the future plans, etc., it is totally impossible for others to guess if 
a re-write to C++ or modern Fortran would be best - I assume that Lynn 
and colleagues have that knowledge and made the best choice.  But I 
would be confident that speed comparisons from a re-write in C++ to the 
old Fortran code would not give a fair comparison of the languages here.

[toc] | [prev] | [next] | [standalone]

#123439

On 2/5/2026 1:23 AM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 2/4/2026 1:20 PM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>
>>>> I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
>>>>     Nothing besides C++ has the oomph and speed to make this happen.
>>>
>>> Speed differences between compiled languages are reltively small.
>>> But Fortran (where I am reading this) can certainly do so.  A pity
>>> you missed out on Fortran's development in the last 35 years.
>>
>> We will see.
> 
> We will not see, because you made the decision to switch to C++
> instead of gradually introducing modern Fortran features in your
> code.  There will be no benchmark to test against.
> 
>> When I finish converting the 800,000 lines of F77 code to
>> C++ in my calculation engine, I will run a timing test using my 659 +
>> 100 = 759 benchmark files.  I just restarted this project after a year
>> or two of working on customers problems and demands.
> 
> That could be interesting.  With such a conversion test, it would
> also be interesting to see how many bugs were uncovered in the
> conversion process, and how many new ones were introduced.  You
> may know the first number (although I totally understand if you don't
> want to share), but you may never know the second one.
> 
> Do you use tools like valgrind and sanitizers?
> 
>> I have over 100,000 lines of F77 converted to C++ now and the input
>> parser of my chemical data regression tool is fully working.
> 
> Parsers are a field where Fortran does not shine, although allocatable
> characters have made this much easier.

I have tried valgrind in the past.  It alerts too much in my F77 code 
since we have a homegrown dynamic memory system dating back to 1977. 
The pointers are stored in integers and valgrind really hates those.

The only conversion problem that I am worried about is that I have 
Fortran 66 interpreter built into my software for my customers to write 
custom calculations embedded in their datasets attached to any type of 
object.  I will need to write a converter for the F66 format statements 
to C formats.  Not a big deal though.  Some of my customers have over 
10,000 lines of F66 code in their datasets.  And yes, the F66 parser is 
written in F77 code, we wrote that back in 1982.

Lynn

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

Back to top | Article view | comp.lang.c++

csiph-web