Tuesday, September 21, 2021

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Bart <bc@freeuk.com>: Sep 21 12:39AM +0100

On 20/09/2021 23:16, Paavo Helde wrote:
 
> How many
> individuals it took to build the airplane you last used? Even your
> bicycle was most probably built by more than one person.
 
Well, the pencil on my desk was probably also made by more than one
person! While the bike probably /could/ be made by an individual.
 
If the equivalent of my everyday Print task is going to the shops to buy
some milk, then you will find a bicycle more apt for that purpose than
an airplane.
 
I just don't see the need for a programming language to be so complex
that it takes many man-years to implement it. I like my tools lightweight.
 
This is not just about Print either; everything in C++ seems designed to
be the opposite of simple. That's why I said I look at C++ to find out
how /not/ to do things.
Bo Persson <bo@bo-persson.se>: Sep 21 09:08AM +0200

On 2021-09-20 at 22:38, Bart wrote:
 
> the first type considerably easier to write, and to read. The only
> difficulty is having to go and find out how to suppress the automatic
> space between items, and the newline at the end.
 
Yes, the BASIC print works well for built in types, but how do you
extend it to works with user defined types? Wait, in BASIC that is not a
problem (you just don't allow user defined types :-).
 
I have seen the same feature in Pascal, where READ and WRITE worked
similarly well, for the built in types. I looked long and hard for the
way to output one of my records - only to find that you could not.
 
Still remember how disappointed I was - a nice language feature that
only worked for some simple types, but not for the types I actually used
in the program. See "useless".
David Brown <david.brown@hesbynett.no>: Sep 21 09:39AM +0200

On 20/09/2021 22:38, Bart wrote:
> implemented in any language, you really need to have tried implementing
> Print within a language, and specifically implementing it as a built-in
> feature
 
No one cares about how easy or hard it is to implement. Seriously.
Rounded to the nearest 0.01% of programmers, /no one/ cares. The
important thing is how people can /use/ the feature in the language, not
how it is implemented!
 
And how you want to /use/ your print features depends on the language
and what you want to do with it. A BASIC-style print statement is fine
for BASIC-style languages - typically designed to be quick and simple
for easy tasks, but unsuitable for bigger work or more complex work, or
programs that don't fit into the simple sequence of start program, read
files and/or keyboard, print to screen and/or files, stop program.
 
But for a language that supports multiple types, formatting,
translations, redirected outputs, systems without a console, etc., then
a simple print statement won't do. It is both too much, and too little.
 
In fact, /no/ single solution will do everything. When you think you
have "/the/ answer" to a coding or programming language problem, you are
almost guaranteed to be wrong - and you, Bart, think you have all the
answers.
 
So a good, serious programming language does not provide a "print"
statement. It does not even provide a "print" function as part of the
language itself. It provides ways to make printing functionality. Then
it can have one or more printing implementation as part of the standard
library, for the convenience of users - while letting them make their
own systems to suit more specialised needs, with their own balance of
pros and cons.
 
Thus C++ has printf that works reasonably for translations and
formatting, but not for different types, and it has std::cout that works
well for different types, but not for translations and formatting. And
there is a new (C++20) formatting library that should work well for
translations, formatting /and/ different types, but is sure to have
other disadvantages (I haven't used it myself as yet). And in my own
code I often use my own system because I have different needs from those
of most C++ programmers.
 
 
>   std::cout << i << " " << sqrt(i) << std::endl;
 
> The first line is from decades-old BASIC. The second line, which also
> needs iostream and math.h includes, is from latest C++.
 
The first version is easiest for a quick and dirty script. The second
is better for more serious programming. (I am not mocking quick and
dirty coding - that is suitable for a great deal of work, but it is
certainly not suitable for everything.)
 
Oh, and if your "sqr" is a language built-in function for square roots,
then that demonstrates another reason why serious languages avoid
built-in functions. The name is wrong, and changing the library is
vastly easier than changing the language.
 
> the first type considerably easier to write, and to read. The only
> difficulty is having to go and find out how to suppress the automatic
> space between items, and the newline at the end.
 
And there you have it.
 
With your personal language and tools, if you want to change the way the
spacing or formatting works, you change the language and the
compiler/interpreter. With real languages, the programmer changes the
code they write to change the formatting.
 
Contrary to some experts' views, I have nothing against BASIC. I
learned to program in BASIC, in several dialects - the "B" stands for
"Beginners'". But then I grew up, and understood that while languages
like BASIC can undoubtedly be good for a few hundred line programs, they
are rarely a good choice for more serious work.
Bart <bc@freeuk.com>: Sep 21 11:12AM +0100

On 21/09/2021 08:39, David Brown wrote:
>> Print within a language, and specifically implementing it as a built-in
>> feature
 
> No one cares about how easy or hard it is to implement.
 
You're changing the goalposts. You said my opinion wasn't an informed
one, when I was talking about the deficiences of both cout and printf
approaches.
 
 
> for easy tasks, but unsuitable for bigger work or more complex work, or
> programs that don't fit into the simple sequence of start program, read
> files and/or keyboard, print to screen and/or files, stop program.
 
What can 'cout' or 'printf' do that an easier-to-use and better designed
Print can't do? This is an example bit of C++ posted a couple of days ago:
 
CMT:
 
std::cout << sizeof(__int64) << "\n";
std::cout << sizeof(__m128) << "\n";
 
std::cout << foo_64.is_lock_free() << "\n";
std::cout << foo_128.is_lock_free() << "\n";
 
 
I might be missing something, but is there any reason why something like:
 
println sizeof(__int64);
println sizeof(__m128);
 
println foo_64.is_lock_free();
println foo_128.is_lock_free();
 
wouldn't cut it? Too sensible? Too uncluttered? Might leave too many
people thinking, where's the catch? Because all that extra crap in C++
must do something important, right?
 
 
> But for a language that supports multiple types, formatting,
> translations, redirected outputs, systems without a console, etc., then
> a simple print statement won't do. It is both too much, and too little.
 
You're making this up aren't you?
 
Simple Print doesn't mean an inability to do anything. It means being
able to do most of it, but in a simpler manner with a lot less typing!
 
> In fact, /no/ single solution will do everything.
 
But it might do 90% of it.
 
> have "/the/ answer" to a coding or programming language problem, you are
> almost guaranteed to be wrong - and you, Bart, think you have all the
> answers.
 
Some things are just no-brainers.
 
> So a good, serious programming language does not provide a "print"
> statement.
 
Yeah. And the better ones also do away with mutability. And global
variables (see new 'pen' language). And loops. And of course goto.
 
 
>> The first line is from decades-old BASIC. The second line, which also
>> needs iostream and math.h includes, is from latest C++.
 
> The first version is easist for a quick and dirty script.
 
Most of my uses of Print are quick and dirty:
 
* Because I add and remove such statements extensively for debugging, so
the total number of Prints written are much greater than than the number
of static Print statements in a finished program
 
* I also use it a lot for large numbers of throwaway programs, test
programs, code posted on forums, etc, in a variety of languages.
 
C's printf is poor in that regard, but I think C++'s cout might just pip
it. However Zig's print facilities I think are even worse; once you've
figured out how to do it once, you have to keep that example locked away
for future reference!
 
 
> The second
> is better for more serious programming.
 
So give me an example of serious programming where:
 
println X
 
is no good at all, and you're better off with:
 
std::cout << X << "\n";
 
> then that demonstrates another reason why serious languages avoid
> built-in functions. The name is wrong, and changing the library is
> vastly easier than changing the language.
 
SQR comes from BASIC (most languages use 'sqrt'). Many also have such
abilities built-in, because it's convenient.
 
In mine, sqrt is an operator. You don't need to include or import
anything; it's just there. And usually mapped to an x64 'sqrtsd'
instruction, but that's up to the backend.
 
Now look at the abs() function, and you realise why it is BETTER to have
such things properly built-in, and not just a bunch of templates. In C,
you have these variations:
 
abs(x) // these need stdlib.h
labs(x)
llabs(x)
fabs(x) // these need math.h
fabsf(x)
 
Maybe there's some more, I don't know. I just have 'abs', and it works
on any suitable type, because it's a unary operator like 'negate'.
 
> spacing or formatting works, you change the language and the
> compiler/interpreter. With real languages, the programmer changes the
> code they write to change the formatting.
 
You say you like Python.
 
Python also injects implicit spaces and implicit new lines. But that's
OK, even though it is a PITA to figure out how to suppress them.
 
But C++, where it is a PITA to have to add explicit spaces and newlines,
is also fine.
 
The only place it isn't fine, apparently, is my language, where I have
implicit spaces and explicit newlines!
 
There /is/ a simple way to suppress spaces, but if you don't know what
it is, then instead of writing:
 
print "ABC","DEF" # ABC DEF
 
you have the option to just split the print into two:
 
print "ABC"; print "DEF" # ABCDEF
 
Because of how it works. In Python, you HAVE to go and look this up, as
splitting a print will just insert a newline instead of a space.
 
(Space suppression between my print items uses: ",," instead of ",".
When that gets too ugly, then you use formatted print.)
 
 
> "Beginners'". But then I grew up, and understood that while languages
> like BASIC can undoubtedly be good for a few hundred line programs, they
> are rarely a good choice for more serious work.
 
I want to port an algorithm which is expressed in both language A and
language B, into a new language.
 
Suppose A and B were C++ and BASIC; which do you think would be simplest
to work from?
 
The chances are that it will be BASIC, since most of its features exist
also in many other languages.
 
With C++, especially if written by Bonita Montero, it would likely mean
first implementing a dozen C++ libraries that it will depend on, and
disentangling a mess of arcane syntax.
 
You shouldn't really write off a language for language for being too simple.
 
It actuality, that simpler language, more likely to use mostly simple,
universal features, might be something like Lua or Python. Or even C,
provided the author hasn't gone mad with macros.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 03:45PM +0300

21.09.2021 13:12 Bart kirjutas:
 
> wouldn't cut it? Too sensible? Too uncluttered? Might leave too many
> people thinking, where's the catch? Because all that extra crap in C++
> must do something important, right?
 
In our codebase of hundreds of thousands lines of C++ code there are
very few outputs to STDOUT, mostly because it's all libraries used by
various client programs who would not like at all if a library polluted
the console with some unwanted messages. Also, when running in Windows
there typically is no console, so there is not much point in printing
anything there. If I want to see the value of some variable during a
program run, I put a breakpoint there and hover the mouse over the name.
 
There are some messages to STDERR though, in critical conditions like
memory exhaustion. How do you write a message to STDERR with your
'println'? It's not obvious at all, unlike for std::cout vs std::cerr.
 
Printing to STDOUT seems to me a kind of niche facility which is used
pretty rarely during large parts of C++ development. Why should such a
facility get some special short name and simplified syntax?
Bart <bc@freeuk.com>: Sep 21 02:37PM +0100

On 21/09/2021 13:45, Paavo Helde wrote:
> there typically is no console, so there is not much point in printing
> anything there. If I want to see the value of some variable during a
> program run, I put a breakpoint there and hover the mouse over the name.
 
A variety of Print is in pretty much every language; it's a fundamental
feature. Why try to justify a naff implementation of it? But at least
C++'s version is different! If little copied...
 
It doesn't necessary mean writing to STDOUT either. Most runtime calls
to Print are likely to be to a file, or will captured by redirection.
 
Others might be to a string.
 
(My biggest use of C's *printf routines via a FFI was to sprintf, to
assemble strings. But hardcoding format codes /outside of C/, which
varied across OSes anyway, was problematical. I now have my own
formatted print.)
 
> There are some messages to STDERR though, in critical conditions like
> memory exhaustion. How do you write a message to STDERR with your
> 'println'? It's not obvious at all, unlike for std::cout vs std::cerr.
 
I virtually never use STDERR, mainly because I've no idea how to do so
outside of C, or via fprintf from a FFI. Even when writing C, it's just
not a thing for me. STDOUT is already used for logging, error messages,
everthing.
 
However, in /my language/ (I'm not going to do a survey of a dozen
others) you define a destination like this:
 
print @dest, x
print @con, x # same as print x
 
Until you mentioned it, I didn't know about cerr at all. I guess there's
a different syntax again for a file.
 
In C++, how do you conditionally output to either STDOUT or STDERR? This
doesn't work:
 
auto F = (cond ? stdout : stderr);
F << "HELLO";
 
 
> Printing to STDOUT seems to me a kind of niche facility which is used
> pretty rarely during large parts of C++ development.
 
You can say that about lots of features. One of my favourite features of
my own is Stop:
 
stop # equivalent to stop 0
stop N
 
which may be implemented via exit(N) or ProcessExit or whatever. It
might be used a tiny number of times in a program, or none at all.
 
That doesn't mean it shouldn't be user-friendly. Now apply that thinking
to more features...
 
 
> Why should such a
> facility get some special short name and simplified syntax?
 
I explained why in my post. Because printing to the console is used
extensively during debugging.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 05:09PM +0300

21.09.2021 16:37 Bart kirjutas:
> outside of C, or via fprintf from a FFI. Even when writing C, it's just
> not a thing for me. STDOUT is already used for logging, error messages,
> everthing.
 
Well that's just plain wrong.
 
> doesn't work:
 
>    auto F = (cond ? stdout : stderr);
>    F << "HELLO";
 
It works if you use C++ names and syntax:
 
#include <iostream>
int main() {
bool cond = false;
(cond ? std::cout : std::cerr) << "HELLO";
}
 
Or more commonly one defines function interfaces in terms of
std::ostream& references, which can be used for all kind of streams.
 
 
>> Printing to STDOUT seems to me a kind of niche facility which is used
>> pretty rarely during large parts of C++ development.
 
> You can say that about lots of features.
 
Yes I can. C++ has lots and lots of features.
 
> might be used a tiny number of times in a program, or none at all.
 
> That doesn't mean it shouldn't be user-friendly. Now apply that thinking
> to more features...
 
Until someone wants to encode a nice loop like that:
 
stop = false;
while (!stop) {
// do something
}
 
Then it becomes clear you have hijacked a perfectly nice 4-letter name
so it cannot be used any more for other purposes.
Bart <bc@freeuk.com>: Sep 21 04:26PM +0100

On 21/09/2021 15:09, Paavo Helde wrote:
> }
 
> Or more commonly one defines function interfaces in terms of
> std::ostream& references, which can be used for all kind of streams.
 
This is what I initially tried:
 
auto fred=std::cout;
fred << "Hello, world!\n";
}
 
The point was to end up with a variable that refers to STDOUT or STDERR,
that can be passed to functions for example.
 
 
> }
 
> Then it becomes clear you have hijacked a perfectly nice 4-letter name
> so it cannot be used any more for other purposes.
 
You mean, like 'exit'?! 'exit' in my languages is used for loop break.
 
It causes problems when I want to use C's exit() as portable way to
terminate my program. "exit" is exported by the C library.
 
(I have to define it as `exit instead, which allows the use of reserved
words or case-sensitive names.)
 
Your example can be dealt with using a different tense (actual code):
 
repeat
khandlertable[pcptr^]^()
until stopped
scott@slp53.sl.home (Scott Lurndal): Sep 21 03:36PM

>outside of C, or via fprintf from a FFI. Even when writing C, it's just
>not a thing for me. STDOUT is already used for logging, error messages,
>everthing.
 
Another reason not to use your "language".
 
hint: 'fprintf(stderr, ...'
 
The utility guidelines require diagnostic messages go to stderr with
non-diagnostic output to stdout. This is been the case for a half
century for extremely good reasons.
scott@slp53.sl.home (Scott Lurndal): Sep 21 03:38PM

>}
 
>Then it becomes clear you have hijacked a perfectly nice 4-letter name
>so it cannot be used any more for other purposes.
 
He could resurrect COBOL's "STOP RUN" instead of Fortran's "STOP". :-)
HorseyWorsey@the_stables.com: Sep 21 03:49PM

On Tue, 21 Sep 2021 15:36:15 GMT
 
>The utility guidelines require diagnostic messages go to stderr with
>non-diagnostic output to stdout. This is been the case for a half
>century for extremely good reasons.
 
He's probably spent too long in an academic ivory tower and doesn't understand
the use case for standard program output to go to one place while the error
stream is directed elsewhere.
David Brown <david.brown@hesbynett.no>: Sep 21 06:04PM +0200

On 21/09/2021 17:26, Bart wrote:
>  }
 
> The point was to end up with a variable that refers to STDOUT or STDERR,
> that can be passed to functions for example.
 
"auto fred = std::cout;" will make "fred" a copy of the value of
"std::cout". What you want is a reference, so that you are referring to
the real output stream:
 
#include <iostream>
int main() {
bool cond = false;
auto& fred = (cond ? std::cout : std::cerr);
fred << "HELLO\n";
}
scott@slp53.sl.home (Scott Lurndal): Sep 21 04:21PM


>He's probably spent too long in an academic ivory tower and doesn't understand
>the use case for standard program output to go to one place while the error
>stream is directed elsewhere.
 
People in the "academic ivory tower" are directly responsible for the
state of the art today. Djikstra, Wirth, Atanasoff, Patterson,
Diffie, Helman, Rivest, Shamir, Adelman, Aho, Ullman, the exceptional Leslie Lamport
and thousands of others.
 
Bart has never even been _close_ to an ivory tower.
Bo Persson <bo@bo-persson.se>: Sep 21 06:34PM +0200

On 2021-09-21 at 12:12, Bart wrote:
 
> wouldn't cut it? Too sensible? Too uncluttered? Might leave too many
> people thinking, where's the catch? Because all that extra crap in C++
> must do something important, right?
 
Yes, it makes it extendable to new types. My types specifically.
 
 
> You're making this up aren't you?
 
> Simple Print doesn't mean an inability to do anything. It means being
> able to do most of it, but in a simpler manner with a lot less typing!
 
So now we get one more way to do the exact same thing, just a bit shorter.
 
I can already see the next post saying that C++ is now even bigger and
harder too learn. And when I change a typedef, suddenly all my print
statements stop working. Why?
Bart <bc@freeuk.com>: Sep 21 05:45PM +0100

On 21/09/2021 16:36, Scott Lurndal wrote:
 
> The utility guidelines require diagnostic messages go to stderr with
> non-diagnostic output to stdout. This is been the case for a half
> century for extremely good reasons.
 
Somebody should tell Microsoft then.
 
Their CL compiler shows error messages on stdout no stderr.
 
So does DMC, Walter Bright's C compiler.
 
As does mine, since I consider the console the error device. However
getting STDERR on Windows, if you're not using C, is not actually that easy.
 
The WinAPI provides GetStdHandle to retrieve a suitable error handler,
but that only works if also using WinAPI for all console output, using
that handle.
 
I like to do console output via printf in msvcrt.dll, but that doesn't
provide a means that I can see, to get a compatible value of its stderr
through its DLL interface.
 
(Other than using non-portable means to directly access the FILE
structures via __iob_func(), since on Windows, stdout etc are not just
small integers.)
 
However, this is not specifically about my language nor about Windows.
 
Somebody asked, how to do STDERR output via a syntax based on 'print
a,b,c'; and I showed how - same as doing output to a file.
scott@slp53.sl.home (Scott Lurndal): Sep 21 05:02PM

>> non-diagnostic output to stdout. This is been the case for a half
>> century for extremely good reasons.
 
>Somebody should tell Microsoft then.
 
Feel free. stdout and stderr, and the rules for their usage predate
MSDOS and were in existence long before microsoft produced a C compiler.
 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
 
"At program start-up, three streams are predefined and need not be
opened explicitly: standard input (for reading conventional input),
standard output (for writing conventional output), and standard error
(for writing diagnostic output). When opened, the standard error stream
is not fully buffered; the standard input and standard output streams
are fully buffered if and only if the stream can be determined not to
refer to an interactive device."
 
C Standard, while not explicitly stating such, implies it.
 
n1256.pdf:
 
void error(char *function_name, char *format, ...)
{
 
va_list args;
 
va_start(args, format);
// print out name of function causing error
fprintf(stderr, "ERROR in %s: ", function_name);
// print out remainder of message
vfprintf(stderr, format, args);
va_end(args);
}
Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 08:11PM +0300

21.09.2021 19:45 Bart kirjutas:
>> century for extremely good reasons.
 
> Somebody should tell Microsoft then.
 
> Their CL compiler shows error messages on stdout no stderr.
 
That's easy to check:
 
c:\tmp>"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64\CL.exe"
/BLABLA >out.txt 2>err.txt
 
c:\tmp>type out.txt
 
c:\tmp>type err.txt
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29913 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
 
cl : Command line warning D9002 : ignoring unknown option '/BLABLA'
cl : Command line error D8003 : missing source filename
 
 
This shows CL compiler indeed reports errors to stderr, as it should. It
also reports its name and copyright message to stderr, to avoid
polluting stdout. This is common practice.
 
Maybe you are confusing the errors appearing in the compiler with the
diagnostic messages reported about the compiled programs? The latters
constitute the compiler output, so indeed should appear in stdout (and
they do).
Bart <bc@freeuk.com>: Sep 21 06:16PM +0100

On 21/09/2021 18:02, Scott Lurndal wrote:
> is not fully buffered; the standard input and standard output streams
> are fully buffered if and only if the stream can be determined not to
> refer to an interactive device."
 
It's not clear what that document is about, but seems to refer to a lot
of C headers.
 
In case of a C (or C++) compiler and where it writes its output, who's
to say what language it might be written in. It might even be a
cross-compiler running on a system where your document has no jurisdiction.
 
> Feel free. stdout and stderr, and the rules for their usage predate
> MSDOS and were in existence long before microsoft produced a C compiler.
 
Well I've never heard of any such rules. They probably emanated from the
same place that inflicted case-sensivity and 0-baseness on everyone.
Bart <bc@freeuk.com>: Sep 21 06:33PM +0100

On 21/09/2021 18:11, Paavo Helde wrote:
> diagnostic messages reported about the compiled programs? The latters
> constitute the compiler output, so indeed should appear in stdout (and
> they do).
 
Here's what I get:
 
C:\c>type c.c
int main(void) {
print a,b,c;
}
 
C:\c>cl c.c >out.txt 2>err.txt
 
C:\c>type out.txt
c.c
c.c(2): error C2065: 'print': undeclared identifier
c.c(2): error C2146: syntax error: missing ';' before identifier 'a'
c.c(2): error C2065: 'a': undeclared identifier
c.c(2): error C2065: 'b': undeclared identifier
c.c(2): error C2065: 'c': undeclared identifier
 
C:\c>type err.txt
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29337 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
 
 
> diagnostic messages reported about the compiled programs? The latters
> constitute the compiler output, so indeed should appear in stdout (and
> they do).
 
So what you are saying is that CL is doing the right thing? The
copyright messages go to STDERR, while actual program *error messages*
go to STDOUT?
 
Which is the opposite to what happens with gcc:
 
C:\c>gcc c.c --verbose >out.txt 2>err.txt
 
C:\c>type out.txt
 
C:\c>type err.txt
Using built-in specs.
COLLECT_GCC=gcc
.... <snip long output>
c.c: In function 'main':
c.c:2:5: error: unknown type name 'print'; did you mean 'int'?
2 | print a,b,c;
| ^~~~~
| int
 
Although that doesn't quite get it right either: it sends ALL its output
to STDERR, even informative messages, and nothing at all to STDOUT.
 
Two major compilers and /they/ don't know how to handle STDOUT and STDERR!
 
I said I'm not interested in separate output streams (when running GUI
programs I used a console for special messages; I didn't need two
consoles!), but if I was to use both STDOUT and STDERR, at least I would
get it right.
Bo Persson <bo@bo-persson.se>: Sep 21 09:28AM +0200

On 2021-09-20 at 23:30, Lynn McGuire wrote:
> hooks and basic functionality for supporting coroutines, but we must
> incorporate this into our own classes. I anticipate that there will be
> full library support for generator style coroutines in C++23."
 
Yes, this seems to be one of the downsides of the current "no delays"
method of producing the standard revisions. The train leaves the station
on time, but not everyone made it. Some passengers didn't have all their
baggage ready, and were left on the platform.
 
The opposite, of course, was the C++08 revision where the committee
tried hard to complete everything and it turned out as C++11. Now
everyone got on the train, but 3 years late.
 
Pros and cons, and all that.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 21 11:45AM +0200

Am 20.09.2021 um 23:30 schrieb Lynn McGuire:
> incorporate this into our own classes. I anticipate that there will be
> full library support for generator style coroutines in C++23."
 
> Lynn
 
Here, two parts on coroutines of two books about C++20:
https://x0.at/EwrI.pdf
HorseyWorsey@the_stables.com: Sep 21 03:37PM

On Tue, 21 Sep 2021 11:45:21 +0200
 
>> Lynn
 
>Here, two parts on coroutines of two books about C++20:
>https://x0.at/EwrI.pdf
 
Coroutines should have stayed in the microsoft world, not added to the C++
standard. They're a solution looking for a problem.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 21 05:40PM +0200

>> https://x0.at/EwrI.pdf
 
> Coroutines should have stayed in the microsoft world, not added
> to the C++ standard. They're a solution looking for a problem.
 
Coroutines are a solution for a problem which is very often:
state machines that need interaction with a consumer of the
states.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 21 01:24PM +0200

Am 21.09.2021 um 00:52 schrieb Chris M. Thomasson:
 
> Creating a working condvar can be very tricky. Have you
> tried to run your implementation through a race detector? ...
 
Can you read ? I haven't built a condvar but a monitor-object.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 21 09:31AM +0200

Am 21.09.2021 um 01:02 schrieb Chris M. Thomasson:
 
> I don't know why they just don't use CMPXCHG16B directly. Look at the
> disassembly of:
 
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange128
 
Can you please respond according to what I wrote ??? It's
about the assembly of the code I posted and not this intrinsic.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)