Path: csiph.com!news.mixmin.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: rational numbers Date: Tue, 21 Sep 2021 13:47:31 -0700 Organization: None to speak of Lines: 48 Message-ID: <878rzpoduk.fsf@nosuchdomain.example.com> References: <87h7edoj4v.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="bb72713767aed0d2b74b94bfa2480dba"; logging-data="17479"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182s0qSuyw8kQPyWwVNZTDH" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:kYtnkJ4PKIZPc7EqkB2/g8/52zY= sha1:a5aaEUE3HKYdW1HiL6mkwh7hflg= Xref: csiph.com comp.lang.c++:81396 Bart writes: > On 21/09/2021 19:53, Keith Thompson wrote: >> Bart writes: >>> 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. > > 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 */