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


Groups > comp.lang.c++ > #119130

Re: Threads across programming languages

From wij <wyniijj5@gmail.com>
Newsgroups comp.lang.c++
Subject Re: Threads across programming languages
Date 2024-05-15 22:38 +0800
Organization A noiseless patient Spider
Message-ID <f2e71e1bd6159c9591d8711e59438a5ea6ddc767.camel@gmail.com> (permalink)
References (20 earlier) <v1vfqf$4eq2$1@dont-email.me> <f919090a93e5ab7c32c8961a6061c9e6e38c8fc4.camel@gmail.com> <v1vs6e$7b2f$1@dont-email.me> <126394fbbc6a61aa1257379032ed4fc43689a61c.camel@gmail.com> <v21upd$pnc1$1@dont-email.me>

Show all headers | View raw


On Wed, 2024-05-15 at 11:20 +0200, David Brown wrote:
> On 14/05/2024 21:29, wij wrote:
> > On Tue, 2024-05-14 at 16:24 +0200, David Brown wrote:
> > > On 14/05/2024 13:46, wij wrote:
> > > > On Tue, 2024-05-14 at 13:53 +0300, Paavo Helde wrote:
> > > > > On 14.05.2024 05:43, Tim Rentsch wrote:
> > > > > > Paavo Helde <eesnimi@osa.pri.ee> writes:
> > > > > > 
> > > > > > > On 07.05.2024 01:13, Tim Rentsch wrote:
> > > > > > 
> > > > > 
> > > > > > > > 
> > > > > > > > C++ doesn't need nested functions because it has lambdas, which
> > > > > > > > are effectively equivalent.
> > > > > > > 
> > > > > > > Lambdas are better than nested functions as one can specify explicitly
> > > > > > > which variables are shared and how.  One can be lazy and pass [&], but
> > > > > > > one doesn't have to.
> > > > > > 
> > > > > > To me that sounds like all the complications of nested functions,
> > > > > > and more besides, and no real advantages.  The choice of which
> > > > > > variables to share is syntactic sugar, there is no difference
> > > > > > in expressive power.
> > > > > 
> > > > > Most of what programming languages do is syntactic sugar. For just
> > > > > writing Turing complete code one programming language would be enough.
> > > > > 
> > > > 
> > > > The primary goal of high level language should be for reducing software
> > > > development/maintenance cost.
> > > 
> > > Yes.  And the main way to do that is to reduce the risk of errors
> > > passing into later stages of development.  A language (and the
> > > programmer using the language) should aim to make it easy to write good
> > > code, hard to write bad code, easy to see that good code is good, and
> > > easy to see that bad code is bad.
> > 
> > Sounds like Bjarne Stroustrup's tongue.
> 
> I think it is a good aim for any programming language, so I am not 
> surprised to see top language designers having similar opinions.
> 
> (Whether or not you think a given language succeeds in these goals is 
> another matter.  And it's highly subjective, from experience, 
> preferences, target applications and code type, and so on.)
> 
> > But I don't feel C++ is steering
> > in that way. Since C++11 many features do not feel like what BS says in his
> > book.
> 
> OK.  I think some are, some are not.  There's no doubt, however, that 
> some features added to C++ are obscure, hard to understand and use, but 
> were made primarily to support improving features that are easier and 
> commonly used.  An example is rvalue references - they can often seem 
> weird and it's not easy to know when they are a good idea or not.  But 
> they make classes like std::vector<>, which are commonly used, more 
> efficient.
> 
> > 
> > > "Syntactic sugar" is vital to this effort.  And a key source of "power"
> > > of a language is not in what it allows you do to, but in what it stops
> > > you from doing, or allows you to restrict yourself.  For example, often
> > > a correct program will work just as correctly, and just as efficiently,
> > > if all uses of "const" are removed.  The "const" does not add to the
> > > things the language can do - it helps by restricting the errors you can
> > > make when using the language.
> > 
> > I agree what you say, but pretty much every high level language would say
> > the same (how about BASIC?). 
> 
> I agree with that, which is pretty much the point - that's why we have 
> high level languages.
> 
> > I am more concerned about the practical side.
> 
> Sure.
> 
> > 
> > > So Tim is completely wrong to say that specifying the variables
> > > accessible in a lambda gives "no real advantages".  It doesn't give the
> > > compiler's code /generator/ any more information than it can deduce
> > > itself from [&] or [=], but it gives more information to the compiler's
> > > code /checker/ and to human programmers - those are big advantages and
> > > greater expressive power.
> > 
> > Probably. I now still hesitate whether or not I should learn and adopt C++'s
> > lambda expression. My consideration is that many new features after C++11
> > are not really necessary and the burden may be greater than the gain for me.
> 
> I like lambdas on occasion.  I haven't found much use for them in my C++ 
> programming, but that is probably just the kind of work I do using C++. 
> I have had more use of them in my Python coding.
> 
> But they are like any other tool - a bit odd and hard to grasp when you 
> are unfamiliar with them, then you get the idea and they are just 
> another tool in the box, ready to use when they are the best fit for the 
> task in hand.  Use them when they make the code clearer, don't use them 
> when they make the code hard to follow.
> 
> > 
> > > > Cpp is just having too many 'syntactic sugars'
> > > > (and keep on adding it) to be away from this goal, IMO.
> > > 
> > > C++ is a very big language, and gains new features (in the language and
> > > standard library) every three years.  While some features make it easier
> > > to write better code, backwards compatibility means it is rarely
> > > possible to remove features that are no longer necessary.  Thus if you
> > > want to be able to read and understand all the syntax of C++, it gets
> > > more effort.  But if you are in the position to be able to deal with C++
> > > code using only the features you find useful and like, then that is much
> > > less of an issue.
> > 
> > I am not optimistic about the future of C++.
> 
> I am - there are some things, like reflection and contracts, that I 
> think will be /very/ nice.  But I also expect to see many new features 
> that I won't have much use for, as always.  No one uses everything in 
> big languages.
> 
> (When I started in embedded development, I worked in assembly.  You 
> could know /everything/ about the microcontroller you were using - every 
> single instruction in the processor, every peripheral on the chip. 
> /Every/ instruction executed by the microcontroller was one you wrote 
> explicitly.  It was nice to know everything.  But such times are past, 
> like it or not.)
> 
> > 
> > > It's primarily when dealing with smart-arse
> > > programmers like Bonita that it is a real problem.  (But such
> > > programmers can also write smart-arse code in C and any other language
> > > they use.)
> > > 
> > > > Putting the 'expressivness' aside, I think cpp cannot complete with C and
> > > > Assembly if measuring the compiled code size and speed. But I still like to
> > > > program in cpp for my own reasons.
> > > > 
> > > 
> > > If your C++ code is more than marginally slower than equivalent C code
> > > in situations where the speed is important, then you are using C++
> > > incorrectly.  It's not uncommon for C++ to pull in a whole lot of extra
> > > library code, but that is rarely significant on PC's or other "big"
> > > computers.
> > > 
> > > It is perhaps easier to accidentally write code that is big and slow in
> > > C++ than it is in C, but it is certainly not necessary.
> > 
> > My concern is that C++ codes typically consumes more memory much less
> > proportional than the speed gain.
> 
> I think it is hard to define "typically".  But I think you will have to 
> justify your claims here with some examples.  (I don't mean detailed 
> code or analysis, just rough descriptions of your thought processes here.)

You are right in your concern, C++ language does not particularly consume more 
run-time memory than C. I was concerned about the abuse of container classes. 
std::list is mostly the case. For others, I should say those 'data structure'
containing links, e.g. std::set. Because the ratio of speed gain and memory 
consumption is likely very low. C++ programmer should notice this point.

> It's useful to remember that just about anything that can be written in 
> C, can be written in C++ with /very/ little overhead.  If you are 
> concerned that using a std::vector<> will chew up excess memory compared 
> to a manual call to malloc(), you can make the malloc() call in C++. 
> You can also make it a bit safer and easier to use by wrapping it in a 
> class and using a std::unique_ptr<> to ensure it gets freed at the right 
> time.  And you get this with no measurable extra cost.
> 
> > Basically, time*space=constant, 
> 
> Um, no, that is not generally true.
> 
> But sometimes you can make trade-offs between speed and space (either 
> data space or code space).  Again, if you can choose a particular 
> balance in C, you can choose the same balance in C++ - though the 
> default, simpler or more idiomatic C++ code might have a different 
> balance than you might have chosen in C.
> 
> > which is
> > especially observable for computation intensive problems. I am more concerned
> > about the cost of problem solving instead of plain code analysis.
> > 
> > > And while it occasionally makes sense to use assembly for the most
> > > time-critical parts of code, it is very common for clear, maintainable C
> > > or C++ code to be /faster/ than clear, maintainable assembly code.
> > > 
> > > Unless you are dealing with something that makes use of processor
> > > instructions or features that are unknown to the C/C++ compiler, writing
> > > assembly code that is faster than C or C++ will often require such
> > > specific care for things like instruction scheduling, register pressure,
> > > cache prefetching, etc., than your results will be far from clear or
> > > maintainable.  And by the time you've got it working, the end user has
> > > bought a new PC and the processor has different numbers of execution
> > > units and more specialised instructions.  You can re-write much of the
> > > assembly, or you can re-compile your C/C++ with a different "-march=" flag.
> > 
> > To me, there is no clear cut saying which (assembly or C/C++) is better just
> > from the view point of common capabilities mutual to low/high level languages.
> > (there are many capabilities C/C++ cannot do, typically involving hardware
> > capabilities, virus, anti-interference, simulation,...)
> 
> Sure - there are times that assembly is essential.  But usually you try 
> to minimise that in your code.
> 
> > It all depends on what kind of application is desired.
> > Generally, I feel software projects within 6-man-month are no difference from
> > the language choice. One can also program assembly as fast.
> 
> There is a vague rule of thumb that people experienced in a programming 
> language can write at roughly the same rate in terms of lines of code 
> per unit time, and that bug rates are roughly proportional to the number 
> of lines of code.  It is a statistical pattern, not a law, but it is 
> generally the case that it is more efficient for programmers to use the 
> highest level language that is suitable for the task at hand, at least 
> as far as the coding is concerned.  (Things like system design, 
> algorithm design, etc., are mostly independent of the programming 
> language - if these dominate the development time, then the language 
> makes little difference.)
> 
> > Those said, I retired earily (at about 37), I use C++ exclusively since then.
> > Many are from my memory and what I received and my observations.
> > 
> > 
> 

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-29 19:13 +0300
  Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 20:29 +0000
    Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 13:33 -0700
      Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 22:41 +0000
        Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 16:46 -0700
          Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-30 00:11 +0000
      Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 06:54 +0200
        Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 07:10 +0000
          Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:13 +0200
            Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 08:53 +0000
              Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:59 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 20:34 +0000
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 05:45 +0200
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-02 15:53 +0200
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 17:10 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:24 +0000
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 09:38 +0200
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:58 +0200
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 11:18 +0200
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 13:23 +0200
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:01 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 17:18 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:20 +0000
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-04 20:41 +0300
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-05 01:41 +0000
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-05 10:38 +0300
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-05 12:37 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-05 13:00 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-13 00:43 +0000
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-13 15:04 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-13 16:52 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-17 22:18 +0000
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-17 22:17 +0000
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-06 15:13 -0700
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-07 08:41 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-07 11:00 +0200
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-13 19:43 -0700
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 04:59 +0200
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 16:39 -0700
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-14 13:53 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 13:42 +0200
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 19:55 +0800
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 14:11 +0200
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 20:16 +0800
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 16:02 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-14 13:34 -0700
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 19:46 +0800
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 14:13 +0200
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 20:28 +0800
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-14 16:24 +0200
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 03:29 +0800
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-14 23:34 +0300
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 08:31 +0800
                Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-14 18:16 -0700
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:26 +0200
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 11:06 +0300
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 16:34 -0700
                Re: Threads across programming languages olcott <polcott333@gmail.com> - 2024-05-21 18:43 -0500
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:25 +0200
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 20:48 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:23 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-14 21:37 -0700
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 19:57 +0800
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 20:07 +0800
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 17:33 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-15 08:43 -0700
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 17:55 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-15 10:31 -0700
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-15 11:20 +0200
                Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 22:38 +0800
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 20:46 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 21:51 +0200
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 19:30 -0700
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-06-04 09:03 +0200
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-15 14:24 +0300
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 19:26 -0700
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 20:27 -0700
                Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-22 11:43 +0300
                Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 21:03 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:21 +0000
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 08:45 +0200
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:05 +0200
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:09 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 02:33 +0000
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:05 -0700
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:07 -0700
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:09 -0700
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 06:00 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:19 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-05 01:40 +0000
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-04 22:23 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 05:39 +0000
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 07:53 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:16 +0000
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:00 +0200
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 02:30 +0000
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:36 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 04:46 +0000
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:50 -0700
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 06:00 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:27 -0700
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 13:28 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:15 +0000
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 16:58 -0700
                Re: Threads across programming languages Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-03 00:15 +0000
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 17:22 -0700
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 00:07 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 02:25 +0000
                Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-03 12:33 -0700
                Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-07 20:48 -0700
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 10:34 +0200
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:05 +0300
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 17:20 +0200
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:47 +0300
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:19 +0000
                Re: Threads across programming languages bart <bc@freeuk.com> - 2024-05-04 00:27 +0100
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-04 22:04 +0300
                Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-05 14:56 +0200
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 17:36 +0200
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-04 22:11 +0300
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-04 12:59 -0700
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 22:20 -0700
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 22:22 -0700
              Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 11:55 -0700
        Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 11:55 -0700
    Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 06:53 +0200
      Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 07:09 +0000
        Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:11 +0200
          Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 08:53 +0000
            Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 11:00 +0200
              Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 20:31 +0000
                Re: Threads across programming languages scott@slp53.sl.home (Scott Lurndal) - 2024-05-01 21:00 +0000
                Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-02 00:05 +0300
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 23:05 +0000
                Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 05:46 +0200
                Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 13:33 -0700
                Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:22 +0000
  Re: Threads across programming languages scott@slp53.sl.home (Scott Lurndal) - 2024-04-30 16:48 +0000

csiph-web