Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #119130
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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