- DCAS-supplement ? - 1 Update
- condvar-implementation - 1 Update
- rational numbers - 12 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 21 04:09PM -0700 On 9/21/2021 12:31 AM, Bonita Montero wrote: >> 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 do it. Its a pain to converse with you. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 21 04:08PM -0700 On 9/21/2021 4:24 AM, Bonita Montero wrote: >> 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. I answered the part where you wrote: Bonita: But I'm still interested in the paper which describes the different approaches in implementing a condvar for Win32. Maybe I can implement some improvemehts here also. You snipped it out. |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 08:43PM +0300 21.09.2021 20:33 Bart kirjutas: > Two major compilers and /they/ don't know how to handle STDOUT and STDERR! Hint: if everybody else seems to drive on the wrong side of the highway, it might be a time for little self-contemplation. |
| Bart <bc@freeuk.com>: Sep 21 06:59PM +0100 On 21/09/2021 18:43, Paavo Helde wrote: >> STDERR! > Hint: if everybody else seems to drive on the wrong side of the highway, > it might be a time for little self-contemplation. So to be clear: * Copyright messages from CL belong in STDERR * Informative messages from gcc belong in STDERR * Program Error messages from CL belong in STDOUT * Program Error messages from gcc belong in STDERR You are saying this behaviour is correct, not crazy nor conflicting at all, and it's time for ME to do self-comtemplation? Just checking... |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 21 09:20PM +0300 21.09.2021 20:59 Bart kirjutas: > * Informative messages from gcc belong in STDERR > * Program Error messages from CL belong in STDOUT > * Program Error messages from gcc belong in STDERR Error messages from compiler belong to STDERR. Diagnostic messages (errors and warnings) about compiled programs can be either way, depending on what is considered the main output from the compiler. > You are saying this behaviour is correct, not crazy nor conflicting at > all, and it's time for ME to do self-comtemplation? Yes. These rules have a simple and sound reason: if the program is producing some output which can be potentially post-processed programmatically by another program, then everything not belonging to this output must be sent to stderr, to avoid garbling the output. Gcc manpage contains examples how to send assembler or other output to stdout, so it makes sense for them to send all diagnostics to stderr to avoid garbling. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 21 11:51AM -0700 David Brown <david.brown@hesbynett.no> writes: [...] > "auto fred = std::cout;" will make "fred" a copy of the value of > "std::cout". No it won't. There's no assignment operator for std::basic_ostream. > auto& fred = (cond ? std::cout : std::cerr); > fred << "HELLO\n"; > } Right. And if you want to change fred later, you can use a pointer (smart or otherwise). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| scott@slp53.sl.home (Scott Lurndal): Sep 21 06:52PM > * Program Error messages from gcc belong in STDERR >You are saying this behaviour is correct, not crazy nor conflicting at >all, and it's time for ME to do self-comtemplation? The output of GCC is an object file. Any other output is diagnostic output and rightly belongs on stderr. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 21 11:53AM -0700 > On 21/09/2021 18:02, Scott Lurndal wrote: [...] >> 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. [...] So now you've learned something. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Bart <bc@freeuk.com>: Sep 21 08:32PM +0100 On 21/09/2021 19:20, Paavo Helde wrote: > Gcc manpage contains examples how to send assembler or other output to > stdout, so it makes sense for them to send all diagnostics to stderr to > avoid garbling. I'm still not clear. Is what MS' CL is doing correct or not: sending program error messages to STDOUT instead of STDERR as gcc does? Because I don't understand how they can both be right if they are doing opposite things; ONE of them must be wrong! I'm getting the feeling that someone here is winding me up... |
| Bart <bc@freeuk.com>: Sep 21 08:48PM +0100 On 21/09/2021 19:53, Keith Thompson wrote: >> Well I've never heard of any such rules. > [...] > So now you've learned something. Not really. The rules apply to what, exactly: a specific OS, ALL OSes, a specific language, ALL languages, some library..... I think somebody is making a few assumptions. The fact is, when I write an application then it does what I say. And /I/ decide how any error handling is to be performed. |
| scott@slp53.sl.home (Scott Lurndal): Sep 21 08:23PM >Not really. The rules apply to what, exactly: a specific OS, ALL OSes, a >specific language, ALL languages, some library..... >I think somebody is making a few assumptions. You should stop doing that. >The fact is, when I write an application then it does what I say. And >/I/ decide how any error handling is to be performed. It has already been pointed out to you the reasoning behind the rule. Specifically to support pipelining the output of one command into another without interleaving diagnostic messages. $ cat /path/to/file | egrep -w '^fred|^joe|^sam' > list-of-lines-starting-with-fred-joe-or-sam Any diagnostics from cat or grep will go to stderr, not to the pipeline. |
| scott@slp53.sl.home (Scott Lurndal): Sep 21 08:24PM >I'm still not clear. Is what MS' CL is doing correct or not: sending >program error messages to STDOUT instead of STDERR as gcc does? As with most microsoft software, CL is broken if it behaves as you describe. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 21 01:47PM -0700 >> So now you've learned something. > Not really. The rules apply to what, exactly: a specific OS, ALL OSes, > a specific language, ALL languages, some library..... Right, I shouldn't have assumed that you've learned something. > I think somebody is making a few assumptions. The distinction between standard output and standard error (stdout and stderr in C, std::cout and std::cerr in C++) has been well established for decades. It's not specific to C++, and therefore not specific to this newsgroup. It originated in early UNIX, and possibly from Fortran before that, and has been adopted by some other operating systems including Windows, though Windows programs often don't make as much use of either stdout or stderr as typical Unix/Linux programs do. The distinction isn't always 100% clear. I would certainly call printing error messages to stdout incorrect behavior. Usage messages (the output of `some_command -h` or `some_command --help`, for example) are sometimes a corner case, especially if they can be printed either as the result of a specific request or because an option name was misspelled. I suggest you go off and do some research before telling us that we're wrong about something we've been using for decades and you've only recently learned about. There are even Wikipedia articles. > The fact is, when I write an application then it does what I say. And > /I/ decide how any error handling is to be performed. Yes, and if you don't care about following long established conventions, you can certainly do that. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Bart <bc@freeuk.com>: Sep 21 11:29PM +0100 On 21/09/2021 21:23, Scott Lurndal wrote: > messages. > $ cat /path/to/file | egrep -w '^fred|^joe|^sam' > list-of-lines-starting-with-fred-joe-or-sam > Any diagnostics from cat or grep will go to stderr, not to the pipeline. OK, so primarily to suit Unix utilities. That's fine. I don't use Unix. I don't write utilities that take text input from pipes and write output to another pipe. There's usually more going on and I make my own arrangements for generating and displaying any diagnostics. |
| 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. |
No comments:
Post a Comment