Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #163780 > unrolled thread
| Started by | Mehdi Amini <atorrses@gmail.com> |
|---|---|
| First post | 2021-12-11 10:06 +0330 |
| Last post | 2021-12-20 07:35 +0100 |
| Articles | 20 on this page of 63 — 12 participants |
Back to article view | Back to comp.lang.c
Book or tutorial on standard C threads Mehdi Amini <atorrses@gmail.com> - 2021-12-11 10:06 +0330
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-11 08:29 +0100
Re: Book or tutorial on standard C threads gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-13 08:12 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 17:41 +0100
Re: Book or tutorial on standard C threads Thiago Adams <thiago.adams@gmail.com> - 2021-12-13 09:16 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 17:47 +0100
Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-14 17:13 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 18:43 +0100
Re: Book or tutorial on standard C threads Guillaume <message@bottle.org> - 2021-12-14 19:23 +0100
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 20:16 +0100
Re: Book or tutorial on standard C threads Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-15 04:02 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 17:53 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-15 17:26 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 18:30 +0100
Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-15 17:49 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 19:19 +0100
Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-15 17:44 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 20:23 +0100
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 07:54 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 14:16 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 15:49 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 15:57 +0000
Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 17:03 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 20:08 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 20:48 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 07:19 +0100
Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-16 17:24 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 18:00 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 20:06 +0100
Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-16 20:14 +0100
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-17 09:30 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 19:06 +0100
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-18 03:07 -0800
Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-18 18:33 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-17 18:19 +0000
Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-18 18:45 +0100
Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 21:45 +0000
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 23:02 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-18 13:45 +0100
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-18 06:02 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-18 15:31 +0100
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-18 07:12 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-18 16:45 +0100
Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-18 23:38 +0000
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-19 10:40 -0800
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-19 19:07 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-19 20:17 +0100
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-19 12:41 -0800
Re: Book or tutorial on standard C threads Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-20 03:21 -0800
Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-20 09:39 -0800
Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-16 18:32 +0000
Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-16 20:27 +0100
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 20:33 +0100
Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-17 10:59 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 13:08 +0100
Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-17 16:25 +0000
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 17:38 +0100
Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-16 16:03 -0800
Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-17 00:12 +0000
Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-16 17:05 -0800
Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-16 17:07 -0800
Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-19 17:23 -0800
Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-20 07:35 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-12-18 15:31 +0100 |
| Message-ID | <spkrbh$i1h$1@dont-email.me> |
| In reply to | #163943 |
> Lambdas are just syntax simplification of few things ... No, it's not "just" syntax-simplification, it's the ease of use to prevent a lot of redundant code and to write objects with only a calling operator in one line. > From syntax sugar improvements the range-based-for and variadic > templates are also far better than lambdas ... They're not comparable since they solve completely different purposes. > because these make code more elegant without adding any weird > garbage or confusion. Lambdas are not confusing. But variadic templates can be very confusing.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-12-18 07:12 -0800 |
| Message-ID | <95ceeac2-58e2-4cfe-be9e-d86a42387c73n@googlegroups.com> |
| In reply to | #163945 |
On Saturday, 18 December 2021 at 16:31:23 UTC+2, Bonita Montero wrote: > > Lambdas are just syntax simplification of few things ... > > No, it's not "just" syntax-simplification, it's the ease of use > to prevent a lot of redundant code and to write objects with only > a calling operator in one line. That is definition of the syntax sugar. No effects to result just different way to type it in. There already was Boost.Bind template for generating such classes and objects of such classes on same line ... for whatever reason it was also added to C++11 as std::bind. > > From syntax sugar improvements the range-based-for and variadic > > templates are also far better than lambdas ... > > They're not comparable since they solve completely different > purposes. But you compared them first by saying that lambdas are most important. Why you compared non-comparable thing? > > because these make code more elegant without adding any weird > > garbage or confusion. > Lambdas are not confusing. But variadic templates can be very confusing. Nonsense. Lambdas are often just copy paste bloat with garbled syntax while variadic templates made lot of template code far shorter. So snip and run with nonsense? Restoring: # C++11 added several performance improvements like move semantics, # constexpr, noexcept, split concepts of trivial classes and standard layout # classes, even underlying type of enum. These are all better than syntax # sugar because these help to have more efficient product. # # Therefore only the optional cosmetic things like nullptr, final, override, # enum class, explicit, etc. are less important than lambdas.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-12-18 16:45 +0100 |
| Message-ID | <spkvmo$e87$1@dont-email.me> |
| In reply to | #163953 |
Am 18.12.2021 um 16:12 schrieb Öö Tiib: > That is definition of the syntax sugar. No effects to result just different. Syntactic sugar is when there's no major improvement also. But here the improvement is huge because you have to write much less code and the code becomes much more readable-. > There already was Boost.Bind template for generating > such classes and objects of such classes on same line ... The ease of C++ lambdas isn't substitutable. > But you compared them first by saying that lambdas are most > important. Why you compared non-comparable thing? My comparison was from the standpoint of code-length and readability. > Nonsense. Lambdas are often just copy paste bloat ... Lambdas usually save a lot of redundant code and make the code much more readable. > ... with garbled syntax ... The syntax is trivial. > ... while variadic templates made lot of template code far shorter. .. Variadic templates make templates not easier but make tmplated things possible which weren't possible before. But they can be tricky to use.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-12-18 23:38 +0000 |
| Message-ID | <87mtkxpjq9.fsf@bsb.me.uk> |
| In reply to | #163943 |
Öö Tiib <ootiib@hot.ee> writes: > Lambdas are just syntax simplification of few things and later... > C++11 added several performance improvements like move semantics, > constexpr, noexcept, split concepts of trivial classes and standard layout > classes, even underlying type of enum. These are all better than syntax > sugar because these help to have more efficient product. Both of which are striking things to say, but there has already been too much discussion of C++ in comp.lang.c for me to feel happy to add more. (I think it's deliberate on BM's part.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-12-19 10:40 -0800 |
| Message-ID | <b5418603-4c57-45e9-9210-c664055db39cn@googlegroups.com> |
| In reply to | #163976 |
On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote: > Öö Tiib <oot...@hot.ee> writes: > > > Lambdas are just syntax simplification of few things > > and later... > > > C++11 added several performance improvements like move semantics, > > constexpr, noexcept, split concepts of trivial classes and standard layout > > classes, even underlying type of enum. These are all better than syntax > > sugar because these help to have more efficient product. > > Both of which are striking things to say, but there has already been too > much discussion of C++ in comp.lang.c for me to feel happy to add more. > (I think it's deliberate on BM's part.) I also realized that so I stopped answering to BM yesterday. Otherwise the constexpr and underlying types to enums I would love to have in C too. The constexpr lets to use most of language compile time. That is likely tricky to implement from scratch but as gcc and clang both have it anyway then why not. It is rather good both for performance and testing. The underlying types to enums let to have one byte wide enums. That is good for performance and also portability in communications. I do not think it is rather tricky feature.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-12-19 19:07 +0000 |
| Message-ID | <spnvtl$ukl$1@dont-email.me> |
| In reply to | #163992 |
On 19/12/2021 18:40, Öö Tiib wrote:
> On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote:
>> Öö Tiib <oot...@hot.ee> writes:
>>
>>> Lambdas are just syntax simplification of few things
>>
>> and later...
>>
>>> C++11 added several performance improvements like move semantics,
>>> constexpr, noexcept, split concepts of trivial classes and standard layout
>>> classes, even underlying type of enum. These are all better than syntax
>>> sugar because these help to have more efficient product.
>>
>> Both of which are striking things to say, but there has already been too
>> much discussion of C++ in comp.lang.c for me to feel happy to add more.
>> (I think it's deliberate on BM's part.)
>
> I also realized that so I stopped answering to BM yesterday. Otherwise the
> constexpr and underlying types to enums I would love to have in C too.
> The constexpr lets to use most of language compile time. That is likely
> tricky to implement from scratch but as gcc and clang both have it
> anyway then why not.
Yeah, in complicated compilers for a complicated language, so more
complication will hardly be noticed!
I have a problem with that feature: since this is user-code being run at
compile-time, how long is a compiler prepared to spend executing such
code? How worthwhile is that effort if it turns out that only a fraction
of it, or none, is actually during any specific run?
The following is something I've just tried; it took nearly 5 seconds to
compile:
#include <stdio.h>
constexpr long long int fib(long long int n) {
long long int a;
if (n<3)
a=1;
else
a=fib(n-2)+fib(n-1);
return a;
}
int A[fib(42)/1000000];
int main(void) {
printf("%d\n", fib(42));
printf("%d\n", sizeof(A)/sizeof(A[0]));
}
Without the constexpr, and using a literal for A's size, it took 0.23
seconds.
It's scary might might happen in a substantional application.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-12-19 20:17 +0100 |
| Message-ID | <spo0h1$2t0$1@dont-email.me> |
| In reply to | #163994 |
Am 19.12.2021 um 20:07 schrieb Bart: > Yeah, in complicated compilers for a complicated language, so more > complication will hardly be noticed! The benefit is: you write much less complicated code than with C.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-12-19 12:41 -0800 |
| Message-ID | <02dd7eda-0b92-4076-b280-793203e573bcn@googlegroups.com> |
| In reply to | #163994 |
On Sunday, 19 December 2021 at 21:07:45 UTC+2, Bart wrote: > On 19/12/2021 18:40, Öö Tiib wrote: > > On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote: > >> Öö Tiib <oot...@hot.ee> writes: > >> > >>> Lambdas are just syntax simplification of few things > >> > >> and later... > >> > >>> C++11 added several performance improvements like move semantics, > >>> constexpr, noexcept, split concepts of trivial classes and standard layout > >>> classes, even underlying type of enum. These are all better than syntax > >>> sugar because these help to have more efficient product. > >> > >> Both of which are striking things to say, but there has already been too > >> much discussion of C++ in comp.lang.c for me to feel happy to add more. > >> (I think it's deliberate on BM's part.) > > > > I also realized that so I stopped answering to BM yesterday. Otherwise the > > constexpr and underlying types to enums I would love to have in C too. > > The constexpr lets to use most of language compile time. That is likely > > tricky to implement from scratch but as gcc and clang both have it > > anyway then why not. > Yeah, in complicated compilers for a complicated language, so more > complication will hardly be noticed! > > I have a problem with that feature: since this is user-code being run at > compile-time, how long is a compiler prepared to spend executing such > code? How worthwhile is that effort if it turns out that only a fraction > of it, or none, is actually during any specific run? It like every other feature depends on how programmer uses it. It can compile 5 seconds longer but start program quicker or it can build executable quicker but hang 5 seconds at start of every run. Or both, or neither. If you are paranoid that your team members sabotage your project with pointless compile time processing then reduce the maximum steps of constexpr evaluation in your continuous integration server. However one who's clever enough can do it with preprocessor metaprogramming and recursive #includes in C as easily as in your C++ example. So better hire a team that you trust.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-12-20 03:21 -0800 |
| Message-ID | <f2e2cbee-ed49-470f-8fc0-637e5d70e1a8n@googlegroups.com> |
| In reply to | #163996 |
On Sunday, 19 December 2021 at 20:41:46 UTC, Öö Tiib wrote: > On Sunday, 19 December 2021 at 21:07:45 UTC+2, Bart wrote: > > On 19/12/2021 18:40, Öö Tiib wrote: > > > On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote: > > >> Öö Tiib <oot...@hot.ee> writes: > > >> > > >>> Lambdas are just syntax simplification of few things > > >> > > >> and later... > > >> > > >>> C++11 added several performance improvements like move semantics, > > >>> constexpr, noexcept, split concepts of trivial classes and standard layout > > >>> classes, even underlying type of enum. These are all better than syntax > > >>> sugar because these help to have more efficient product. > > >> > > >> Both of which are striking things to say, but there has already been too > > >> much discussion of C++ in comp.lang.c for me to feel happy to add more. > > >> (I think it's deliberate on BM's part.) > > > > > > I also realized that so I stopped answering to BM yesterday. Otherwise the > > > constexpr and underlying types to enums I would love to have in C too. > > > The constexpr lets to use most of language compile time. That is likely > > > tricky to implement from scratch but as gcc and clang both have it > > > anyway then why not. > > Yeah, in complicated compilers for a complicated language, so more > > complication will hardly be noticed! > > > > I have a problem with that feature: since this is user-code being run at > > compile-time, how long is a compiler prepared to spend executing such > > code? How worthwhile is that effort if it turns out that only a fraction > > of it, or none, is actually during any specific run? > It like every other feature depends on how programmer uses it. It can > compile 5 seconds longer but start program quicker or it can build > executable quicker but hang 5 seconds at start of every run. Or both, > or neither. > > If you are paranoid that your team members sabotage your project > with pointless compile time processing then reduce the maximum > steps of constexpr evaluation in your continuous integration server. > > However one who's clever enough can do it with preprocessor > metaprogramming and recursive #includes in C as easily as in > your C++ example. So better hire a team that you trust. > We had a case. Someone put in an innocent-seeming compile time const expression in C++. It worked on the development machines. Then when pushed to the CI server, it broke. It's the type of thing which can be quite hard for another programmer to fix quickly, because you've got to replace the functionality with a totally different construct.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-12-20 09:39 -0800 |
| Message-ID | <dcd12d70-2f5b-493d-975a-91c82733249an@googlegroups.com> |
| In reply to | #164008 |
On Monday, 20 December 2021 at 13:21:46 UTC+2, Malcolm McLean wrote: > On Sunday, 19 December 2021 at 20:41:46 UTC, Öö Tiib wrote: > > On Sunday, 19 December 2021 at 21:07:45 UTC+2, Bart wrote: > > > On 19/12/2021 18:40, Öö Tiib wrote: > > > > On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote: > > > >> Öö Tiib <oot...@hot.ee> writes: > > > >> > > > >>> Lambdas are just syntax simplification of few things > > > >> > > > >> and later... > > > >> > > > >>> C++11 added several performance improvements like move semantics, > > > >>> constexpr, noexcept, split concepts of trivial classes and standard layout > > > >>> classes, even underlying type of enum. These are all better than syntax > > > >>> sugar because these help to have more efficient product. > > > >> > > > >> Both of which are striking things to say, but there has already been too > > > >> much discussion of C++ in comp.lang.c for me to feel happy to add more. > > > >> (I think it's deliberate on BM's part.) > > > > > > > > I also realized that so I stopped answering to BM yesterday. Otherwise the > > > > constexpr and underlying types to enums I would love to have in C too. > > > > The constexpr lets to use most of language compile time. That is likely > > > > tricky to implement from scratch but as gcc and clang both have it > > > > anyway then why not. > > > Yeah, in complicated compilers for a complicated language, so more > > > complication will hardly be noticed! > > > > > > I have a problem with that feature: since this is user-code being run at > > > compile-time, how long is a compiler prepared to spend executing such > > > code? How worthwhile is that effort if it turns out that only a fraction > > > of it, or none, is actually during any specific run? > > It like every other feature depends on how programmer uses it. It can > > compile 5 seconds longer but start program quicker or it can build > > executable quicker but hang 5 seconds at start of every run. Or both, > > or neither. > > > > If you are paranoid that your team members sabotage your project > > with pointless compile time processing then reduce the maximum > > steps of constexpr evaluation in your continuous integration server. > > > > However one who's clever enough can do it with preprocessor > > metaprogramming and recursive #includes in C as easily as in > > your C++ example. So better hire a team that you trust. > > > We had a case. Someone put in an innocent-seeming compile time > const expression in C++. It worked on the development machines. > Then when pushed to the CI server, it broke. > > It's the type of thing which can be quite hard for another programmer to > fix quickly, because you've got to replace the functionality with a totally > different construct. Why to fix? Just reject the pull request. Or if it was accidentally merged to some main development branch then revert.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-12-16 18:32 +0000 |
| Message-ID | <sDLuJ.126488$np6.2766@fx46.iad> |
| In reply to | #163864 |
David Brown <david.brown@hesbynett.no> writes:
>But C++ /does/ have several alternatives to a long list of booleans like
>this. The simplest would be:
>
>enum class FlagA { True, False };
>enum class FlagB { True, False };
>
>void foo(FlagA a, FlagB b);
>
>void bar(void) {
> foo(FlagA::True, FlagB::False);
>}
>
>You can't get this wrong and call "foo(FlagB::True, FlagA::False)" - the
>compiler would spot the error. Strong types like this for parameters
>can help if you have a long parameter list.
Although 'true' and 'false' by themselves don't transmit anything useful
at the call site.
enum class DMAtype { Flat, ScatterGather, None };
enum class ERRmode { Recover, Abort, Ignore };
foo(DMAType::Flat, ERRmode::Recover);
Enhances readability and maintainability.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-12-16 20:27 +0100 |
| Message-ID | <spg3ut$5n2$1@dont-email.me> |
| In reply to | #163869 |
On 16/12/2021 19:32, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> But C++ /does/ have several alternatives to a long list of booleans like
>> this. The simplest would be:
>>
>> enum class FlagA { True, False };
>> enum class FlagB { True, False };
>>
>> void foo(FlagA a, FlagB b);
>>
>> void bar(void) {
>> foo(FlagA::True, FlagB::False);
>> }
>>
>> You can't get this wrong and call "foo(FlagB::True, FlagA::False)" - the
>> compiler would spot the error. Strong types like this for parameters
>> can help if you have a long parameter list.
>
> Although 'true' and 'false' by themselves don't transmit anything useful
> at the call site.
>
> enum class DMAtype { Flat, ScatterGather, None };
> enum class ERRmode { Recover, Abort, Ignore };
>
> foo(DMAType::Flat, ERRmode::Recover);
>
> Enhances readability and maintainability.
>
Of course. This was just an example of a relatively small improvement.
There are other ways to do better. (And "True" and "False" may be
entirely sufficient if the type name is good enough -
EnableAutoMode::True is hard to better.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-12-16 20:33 +0100 |
| Message-ID | <spg4a6$61h$3@dont-email.me> |
| In reply to | #163869 |
Am 16.12.2021 um 19:32 schrieb Scott Lurndal:
> David Brown <david.brown@hesbynett.no> writes:
>
>> But C++ /does/ have several alternatives to a long list of booleans like
>> this. The simplest would be:
>>
>> enum class FlagA { True, False };
>> enum class FlagB { True, False };
>>
>> void foo(FlagA a, FlagB b);
>>
>> void bar(void) {
>> foo(FlagA::True, FlagB::False);
>> }
>>
>> You can't get this wrong and call "foo(FlagB::True, FlagA::False)" - the
>> compiler would spot the error. Strong types like this for parameters
>> can help if you have a long parameter list.
>
> Although 'true' and 'false' by themselves don't transmit anything useful
> at the call site.
>
> enum class DMAtype { Flat, ScatterGather, None };
> enum class ERRmode { Recover, Abort, Ignore };
>
> foo(DMAType::Flat, ERRmode::Recover);
>
> Enhances readability and maintainability.
I mostly use enums in my own classes and there I don't use scoped
enums. It's just cumbersome to type ClassName::EnumName::EnumValue.
But I would also scope global enums.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-12-17 10:59 +0000 |
| Message-ID | <sphqj1$e9d$1@dont-email.me> |
| In reply to | #163853 |
On 15/12/2021 19:23, Bonita Montero wrote:
> Am 15.12.2021 um 18:26 schrieb Bart:
>> On 15/12/2021 16:53, Bonita Montero wrote:
>>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>>> Simply? If your thread function is so simple that it makes
>>>>>> sense to write it as a lambda, you probably should not be
>>>>>> using threads.
>>>>> You're so silly to think lambdas are suitable only for simple things.
>>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>>> the initiators context through [&].
>>>>>
>>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>>> lambda to std::sort than to write a free-standing comparison function.
>>>> I rarely write code which accepts lambdas, just as I rarely write code
>>>> which declares templates, though I call such code quite frequently.
>>>
>>> I even use often templated lambdas.
>>
>> You would!
>>
>> You just /have/ to use the most elaborate toys at your disposal -
>> preferably as many at the same time as possible - and combine them in
>> ways that make people's heads spin.
>>
>> And yet you're always pushing the agenda that C++ somehow makes
>> everything a piece of cake!
>
>
> That's an example of my lambda-style:
>
> auto buildChain = [&]<CmdLineParams::type_t Type>( bool
> smtThreaded, unsigned toThread )
> {
> auto updateStarts = [&]<typename MappingFn>( MappingFn
> mappingFn )
> requires requires( MappingFn mappingFn, size_t i )
> {
> { mappingFn( i ) } -> same_as<size_t>;
> }
> {
> for( unsigned nThreads = 1; nThreads <= toThread;
> ++nThreads )
> {
> vector<link_t *> &starts = chainStarts[nThreads - 1];
> double gap = (double)(ptrdiff_t)n / (int)nThreads;
> for( unsigned t = 0; t != nThreads; ++t )
> starts[t] = &links[mappingFn(
> (ptrdiff_t)((int)t * gap) )];
> }
> };
> if constexpr( Type == CmdLineParams::LINEAR || Type ==
> CmdLineParams::XLINEAR )
> {
> auto linearConcat = [&]<typename MappingFn>( MappingFn
> mappingFn )
> requires requires( MappingFn mappingFn, size_t i )
> {
> { mappingFn( i ) } -> same_as<size_t>;
> }
> {
> for( size_t i = 0; i != n; ++i )
> links[i].next = &links[mappingFn( mappingFn( i
> ) + 1 & idxMask)];
> };
> if constexpr( Type == CmdLineParams::LINEAR )
> {
> auto directMap = []( size_t i ) { return i; };
> linearConcat( directMap );
> updateStarts( directMap );
> }
> else
> {
> size_t inverter = (size_t)0x5555555555555555u &
> idxMask;
> auto invertedMap = [&]( size_t i ) { return i ^
> inverter; };
> linearConcat( invertedMap );
> updateStarts( invertedMap );
> }
> return;
> }
> unsigned l2ThrTlbBits = l2TlbBits - (unsigned)(smtThreaded
> && l2TlbBits),
> l1ThrTlbBits = l1TlbBits - (unsigned)(smtThreaded
> && l1TlbBits);
> unsigned l1Bits, l2Bits, outerBits;
> size_t l2Mask, outerMask;
> auto maskFromBits = []( unsigned bits ) -> size_t { return
> ((size_t)1 << bits) - 1; };
> if constexpr( Type == CmdLineParams::TLB_RANDOM )
> if( bits > l2ThrTlbBits + pageBits )
> outerBits = bits - (l2ThrTlbBits + pageBits),
> outerMask = maskFromBits( outerBits ),
> l2Bits = l2ThrTlbBits - l1ThrTlbBits,
> l2Mask = maskFromBits( l2Bits ),
> l1Bits = l1ThrTlbBits + pageBits - linkBits;
> else if( bits > l1ThrTlbBits + pageBits )
> outerBits = 0,
> outerMask = 0,
> l2Bits = bits - (l1ThrTlbBits + pageBits),
> l2Mask = maskFromBits( l2Bits ),
> l1Bits = l1ThrTlbBits + pageBits - linkBits;
> else
> outerBits = 0,
> outerMask = 0,
> l2Bits = 0,
> l2Mask = 0,
> l1Bits = bits - linkBits;
> else
> l1Bits = bits - linkBits;
> auto flipIndex = [&]( size_t i ) -> size_t
> {
> static unsigned const SZT_BITS = sizeof(size_t) *
> CHAR_BIT;
> size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
> if constexpr( Type != CmdLineParams::TLB_RANDOM )
> return rL1;
> size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
> l2Bits & l2Mask,
> rOuter = reverseBits( i >> l2Bits + l1Bits ) >>
> SZT_BITS - outerBits & outerMask;
> return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
> l1Bits);
> };
> for( size_t rI = 0; rI != n; ++rI )
> links[rI].next = &links[flipIndex( flipIndex( rI ) + 1
> & idxMask )];
> updateStarts( flipIndex );
> };
>
> Without lambdas and even more templated lambdas the code
> would become very complicated.
Now that I know which bits are lambdas, and now that I know that you
mainly use lambdas to implement local functions, a missing C++ feature,
this code isn't really that remarkable.
It's just overly elaborate which is typical of your coding style.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-12-17 13:08 +0100 |
| Message-ID | <sphujv$qm0$3@dont-email.me> |
| In reply to | #163915 |
Am 17.12.2021 um 11:59 schrieb Bart:
>> That's an example of my lambda-style:
>>
>> auto buildChain = [&]<CmdLineParams::type_t Type>( bool
>> smtThreaded, unsigned toThread )
>> {
>> auto updateStarts = [&]<typename MappingFn>( MappingFn
>> mappingFn )
>> requires requires( MappingFn mappingFn, size_t i )
>> {
>> { mappingFn( i ) } -> same_as<size_t>;
>> }
>> {
>> for( unsigned nThreads = 1; nThreads <= toThread;
>> ++nThreads )
>> {
>> vector<link_t *> &starts = chainStarts[nThreads -
>> 1];
>> double gap = (double)(ptrdiff_t)n / (int)nThreads;
>> for( unsigned t = 0; t != nThreads; ++t )
>> starts[t] = &links[mappingFn(
>> (ptrdiff_t)((int)t * gap) )];
>> }
>> };
>> if constexpr( Type == CmdLineParams::LINEAR || Type ==
>> CmdLineParams::XLINEAR )
>> {
>> auto linearConcat = [&]<typename MappingFn>(
>> MappingFn mappingFn )
>> requires requires( MappingFn mappingFn, size_t i )
>> {
>> { mappingFn( i ) } -> same_as<size_t>;
>> }
>> {
>> for( size_t i = 0; i != n; ++i )
>> links[i].next = &links[mappingFn( mappingFn(
>> i ) + 1 & idxMask)];
>> };
>> if constexpr( Type == CmdLineParams::LINEAR )
>> {
>> auto directMap = []( size_t i ) { return i; };
>> linearConcat( directMap );
>> updateStarts( directMap );
>> }
>> else
>> {
>> size_t inverter = (size_t)0x5555555555555555u &
>> idxMask;
>> auto invertedMap = [&]( size_t i ) { return i ^
>> inverter; };
>> linearConcat( invertedMap );
>> updateStarts( invertedMap );
>> }
>> return;
>> }
>> unsigned l2ThrTlbBits = l2TlbBits -
>> (unsigned)(smtThreaded && l2TlbBits),
>> l1ThrTlbBits = l1TlbBits -
>> (unsigned)(smtThreaded && l1TlbBits);
>> unsigned l1Bits, l2Bits, outerBits;
>> size_t l2Mask, outerMask;
>> auto maskFromBits = []( unsigned bits ) -> size_t {
>> return ((size_t)1 << bits) - 1; };
>> if constexpr( Type == CmdLineParams::TLB_RANDOM )
>> if( bits > l2ThrTlbBits + pageBits )
>> outerBits = bits - (l2ThrTlbBits + pageBits),
>> outerMask = maskFromBits( outerBits ),
>> l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>> l2Mask = maskFromBits( l2Bits ),
>> l1Bits = l1ThrTlbBits + pageBits - linkBits;
>> else if( bits > l1ThrTlbBits + pageBits )
>> outerBits = 0,
>> outerMask = 0,
>> l2Bits = bits - (l1ThrTlbBits + pageBits),
>> l2Mask = maskFromBits( l2Bits ),
>> l1Bits = l1ThrTlbBits + pageBits - linkBits;
>> else
>> outerBits = 0,
>> outerMask = 0,
>> l2Bits = 0,
>> l2Mask = 0,
>> l1Bits = bits - linkBits;
>> else
>> l1Bits = bits - linkBits;
>> auto flipIndex = [&]( size_t i ) -> size_t
>> {
>> static unsigned const SZT_BITS = sizeof(size_t) *
>> CHAR_BIT;
>> size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>> if constexpr( Type != CmdLineParams::TLB_RANDOM )
>> return rL1;
>> size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
>> l2Bits & l2Mask,
>> rOuter = reverseBits( i >> l2Bits + l1Bits )
>> >> SZT_BITS - outerBits & outerMask;
>> return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
>> l1Bits);
>> };
>> for( size_t rI = 0; rI != n; ++rI )
>> links[rI].next = &links[flipIndex( flipIndex( rI ) +
>> 1 & idxMask )];
>> updateStarts( flipIndex );
>> };
>>
>> Without lambdas and even more templated lambdas the code
>> would become very complicated.
>
> Now that I know which bits are lambdas, and now that I know that you
> mainly use lambdas to implement local functions, a missing C++ feature,
> this code isn't really that remarkable.
Lambdas are local functions and make the code _much_ more
readable if you use them properly - like in the above example.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-12-17 16:25 +0000 |
| Message-ID | <GR2vJ.153777$qz4.91873@fx97.iad> |
| In reply to | #163916 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 17.12.2021 um 11:59 schrieb Bart:
>
>>> That's an example of my lambda-style:
>>>
>>> auto buildChain = [&]<CmdLineParams::type_t Type>( bool
>>> smtThreaded, unsigned toThread )
>>> {
>>> auto updateStarts = [&]<typename MappingFn>( MappingFn
>>> mappingFn )
>>> requires requires( MappingFn mappingFn, size_t i )
>>> {
>>> { mappingFn( i ) } -> same_as<size_t>;
>>> }
>>> {
>>> for( unsigned nThreads = 1; nThreads <= toThread;
>>> ++nThreads )
>>> {
>>> vector<link_t *> &starts = chainStarts[nThreads -
>>> 1];
>>> double gap = (double)(ptrdiff_t)n / (int)nThreads;
>>> for( unsigned t = 0; t != nThreads; ++t )
>>> starts[t] = &links[mappingFn(
>>> (ptrdiff_t)((int)t * gap) )];
>>> }
>>> };
>>> if constexpr( Type == CmdLineParams::LINEAR || Type ==
>>> CmdLineParams::XLINEAR )
>>> {
>>> auto linearConcat = [&]<typename MappingFn>(
>>> MappingFn mappingFn )
>>> requires requires( MappingFn mappingFn, size_t i )
>>> {
>>> { mappingFn( i ) } -> same_as<size_t>;
>>> }
>>> {
>>> for( size_t i = 0; i != n; ++i )
>>> links[i].next = &links[mappingFn( mappingFn(
>>> i ) + 1 & idxMask)];
>>> };
>>> if constexpr( Type == CmdLineParams::LINEAR )
>>> {
>>> auto directMap = []( size_t i ) { return i; };
>>> linearConcat( directMap );
>>> updateStarts( directMap );
>>> }
>>> else
>>> {
>>> size_t inverter = (size_t)0x5555555555555555u &
>>> idxMask;
>>> auto invertedMap = [&]( size_t i ) { return i ^
>>> inverter; };
>>> linearConcat( invertedMap );
>>> updateStarts( invertedMap );
>>> }
>>> return;
>>> }
>>> unsigned l2ThrTlbBits = l2TlbBits -
>>> (unsigned)(smtThreaded && l2TlbBits),
>>> l1ThrTlbBits = l1TlbBits -
>>> (unsigned)(smtThreaded && l1TlbBits);
>>> unsigned l1Bits, l2Bits, outerBits;
>>> size_t l2Mask, outerMask;
>>> auto maskFromBits = []( unsigned bits ) -> size_t {
>>> return ((size_t)1 << bits) - 1; };
>>> if constexpr( Type == CmdLineParams::TLB_RANDOM )
>>> if( bits > l2ThrTlbBits + pageBits )
>>> outerBits = bits - (l2ThrTlbBits + pageBits),
>>> outerMask = maskFromBits( outerBits ),
>>> l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>>> l2Mask = maskFromBits( l2Bits ),
>>> l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>> else if( bits > l1ThrTlbBits + pageBits )
>>> outerBits = 0,
>>> outerMask = 0,
>>> l2Bits = bits - (l1ThrTlbBits + pageBits),
>>> l2Mask = maskFromBits( l2Bits ),
>>> l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>> else
>>> outerBits = 0,
>>> outerMask = 0,
>>> l2Bits = 0,
>>> l2Mask = 0,
>>> l1Bits = bits - linkBits;
>>> else
>>> l1Bits = bits - linkBits;
>>> auto flipIndex = [&]( size_t i ) -> size_t
>>> {
>>> static unsigned const SZT_BITS = sizeof(size_t) *
>>> CHAR_BIT;
>>> size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>>> if constexpr( Type != CmdLineParams::TLB_RANDOM )
>>> return rL1;
>>> size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
>>> l2Bits & l2Mask,
>>> rOuter = reverseBits( i >> l2Bits + l1Bits )
>>> >> SZT_BITS - outerBits & outerMask;
>>> return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
>>> l1Bits);
>>> };
>>> for( size_t rI = 0; rI != n; ++rI )
>>> links[rI].next = &links[flipIndex( flipIndex( rI ) +
>>> 1 & idxMask )];
>>> updateStarts( flipIndex );
>>> };
>>>
>>> Without lambdas and even more templated lambdas the code
>>> would become very complicated.
>>
>> Now that I know which bits are lambdas, and now that I know that you
>> mainly use lambdas to implement local functions, a missing C++ feature,
>> this code isn't really that remarkable.
>
>Lambdas are local functions and make the code _much_ more
>readable if you use them properly - like in the above example.
The above code is completely unreadable. And it was unreadable
even before being mangled by various NNTP clients.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-12-17 17:38 +0100 |
| Message-ID | <spieea$18s$1@dont-email.me> |
| In reply to | #163919 |
Am 17.12.2021 um 17:25 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 17.12.2021 um 11:59 schrieb Bart:
>>
>>>> That's an example of my lambda-style:
>>>>
>>>> auto buildChain = [&]<CmdLineParams::type_t Type>( bool
>>>> smtThreaded, unsigned toThread )
>>>> {
>>>> auto updateStarts = [&]<typename MappingFn>( MappingFn
>>>> mappingFn )
>>>> requires requires( MappingFn mappingFn, size_t i )
>>>> {
>>>> { mappingFn( i ) } -> same_as<size_t>;
>>>> }
>>>> {
>>>> for( unsigned nThreads = 1; nThreads <= toThread;
>>>> ++nThreads )
>>>> {
>>>> vector<link_t *> &starts = chainStarts[nThreads -
>>>> 1];
>>>> double gap = (double)(ptrdiff_t)n / (int)nThreads;
>>>> for( unsigned t = 0; t != nThreads; ++t )
>>>> starts[t] = &links[mappingFn(
>>>> (ptrdiff_t)((int)t * gap) )];
>>>> }
>>>> };
>>>> if constexpr( Type == CmdLineParams::LINEAR || Type ==
>>>> CmdLineParams::XLINEAR )
>>>> {
>>>> auto linearConcat = [&]<typename MappingFn>(
>>>> MappingFn mappingFn )
>>>> requires requires( MappingFn mappingFn, size_t i )
>>>> {
>>>> { mappingFn( i ) } -> same_as<size_t>;
>>>> }
>>>> {
>>>> for( size_t i = 0; i != n; ++i )
>>>> links[i].next = &links[mappingFn( mappingFn(
>>>> i ) + 1 & idxMask)];
>>>> };
>>>> if constexpr( Type == CmdLineParams::LINEAR )
>>>> {
>>>> auto directMap = []( size_t i ) { return i; };
>>>> linearConcat( directMap );
>>>> updateStarts( directMap );
>>>> }
>>>> else
>>>> {
>>>> size_t inverter = (size_t)0x5555555555555555u &
>>>> idxMask;
>>>> auto invertedMap = [&]( size_t i ) { return i ^
>>>> inverter; };
>>>> linearConcat( invertedMap );
>>>> updateStarts( invertedMap );
>>>> }
>>>> return;
>>>> }
>>>> unsigned l2ThrTlbBits = l2TlbBits -
>>>> (unsigned)(smtThreaded && l2TlbBits),
>>>> l1ThrTlbBits = l1TlbBits -
>>>> (unsigned)(smtThreaded && l1TlbBits);
>>>> unsigned l1Bits, l2Bits, outerBits;
>>>> size_t l2Mask, outerMask;
>>>> auto maskFromBits = []( unsigned bits ) -> size_t {
>>>> return ((size_t)1 << bits) - 1; };
>>>> if constexpr( Type == CmdLineParams::TLB_RANDOM )
>>>> if( bits > l2ThrTlbBits + pageBits )
>>>> outerBits = bits - (l2ThrTlbBits + pageBits),
>>>> outerMask = maskFromBits( outerBits ),
>>>> l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>>>> l2Mask = maskFromBits( l2Bits ),
>>>> l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>>> else if( bits > l1ThrTlbBits + pageBits )
>>>> outerBits = 0,
>>>> outerMask = 0,
>>>> l2Bits = bits - (l1ThrTlbBits + pageBits),
>>>> l2Mask = maskFromBits( l2Bits ),
>>>> l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>>> else
>>>> outerBits = 0,
>>>> outerMask = 0,
>>>> l2Bits = 0,
>>>> l2Mask = 0,
>>>> l1Bits = bits - linkBits;
>>>> else
>>>> l1Bits = bits - linkBits;
>>>> auto flipIndex = [&]( size_t i ) -> size_t
>>>> {
>>>> static unsigned const SZT_BITS = sizeof(size_t) *
>>>> CHAR_BIT;
>>>> size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>>>> if constexpr( Type != CmdLineParams::TLB_RANDOM )
>>>> return rL1;
>>>> size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
>>>> l2Bits & l2Mask,
>>>> rOuter = reverseBits( i >> l2Bits + l1Bits )
>>>>>> SZT_BITS - outerBits & outerMask;
>>>> return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
>>>> l1Bits);
>>>> };
>>>> for( size_t rI = 0; rI != n; ++rI )
>>>> links[rI].next = &links[flipIndex( flipIndex( rI ) +
>>>> 1 & idxMask )];
>>>> updateStarts( flipIndex );
>>>> };
>>>>
>>>> Without lambdas and even more templated lambdas the code
>>>> would become very complicated.
>>>
>>> Now that I know which bits are lambdas, and now that I know that you
>>> mainly use lambdas to implement local functions, a missing C++ feature,
>>> this code isn't really that remarkable.
>>
>> Lambdas are local functions and make the code _much_ more
>> readable if you use them properly - like in the above example.
>
> The above code is completely unreadable. And it was unreadable
> even before being mangled by various NNTP clients.
The code is unreadable because you don't know what it's good for.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-12-16 16:03 -0800 |
| Message-ID | <spgk56$ovh$1@dont-email.me> |
| In reply to | #163780 |
On 12/10/2021 10:36 PM, Mehdi Amini wrote:
> Hi,
>
> Which book or tutorial would you recommend for standard C threads
> introduced in C11 ?
Call me old fashioned, but I still love this simple type of setup...
_____________________
#include <iostream>
#include <thread>
#include <atomic>
#include <algorithm>
struct ct_shared_state
{
std::atomic<int> m_foo;
};
void
ct_thread(ct_shared_state& shared)
{
shared.m_foo.fetch_add(1, std::memory_order_relaxed);
}
#define CT_THREADS 32
int main()
{
std::cout << "Hello World!\n\n";
std::cout.flush();
ct_shared_state shared_state = { { 1 } };
{
std::thread threads[CT_THREADS];
for (unsigned int i = 0; i < CT_THREADS; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared_state));
}
for (unsigned int i = 0; i < CT_THREADS; ++i)
{
threads[i].join();
}
}
std::cout << shared_state.m_foo.load(std::memory_order_relaxed) *
11 + 303;
std::cout << "\n\nFin!\n\n";
return 0;
}
_____________________
666
;^)
Old school. ;^)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-12-17 00:12 +0000 |
| Message-ID | <878rwkt7g5.fsf@bsb.me.uk> |
| In reply to | #163896 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > On 12/10/2021 10:36 PM, Mehdi Amini wrote: >> Hi, >> Which book or tutorial would you recommend for standard C threads >> introduced in C11 ? > > Call me old fashioned, but I still love this simple type of setup... > _____________________ > #include <iostream> The OP is asking about C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-12-16 17:05 -0800 |
| Message-ID | <spgnpq$tg0$1@dont-email.me> |
| In reply to | #163899 |
On 12/16/2021 4:12 PM, Ben Bacarisse wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > >> On 12/10/2021 10:36 PM, Mehdi Amini wrote: >>> Hi, >>> Which book or tutorial would you recommend for standard C threads >>> introduced in C11 ? >> >> Call me old fashioned, but I still love this simple type of setup... >> _____________________ >> #include <iostream> > > The OP is asking about C. > Indeed. Fwiw, the last time I tried to get a C11 compiler to work was in Pelles C: http://www.smorgasbordet.com/pellesc
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web