Monday, March 9, 2020

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

Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 09 04:18AM -0700

I'm using "boost::process" to start a second program.
 
I want to write a robust function to start a second program and to retrieve the first line of text from its stdout. If any kind of error takes places, the function will simply return an empty string. No exceptions will be thrown.
 
When I say the first line of text, I mean either of these two things:
(1) Retrieve bytes from stdout until a new line is encountered, and discard the new line character.
(2) Retrieve bytes from stdout until EOF.
 
I will give a default timeout of 5 seconds for the second program to finish.
 
So I start off with this:
 
#include <boost/process.hpp> /* boost::process::child, ipstream */
#include <boost/chrono.hpp> /* boost::chrono::seconds */
#include <boost/thread.hpp> /* try_join_for */
 
#include <string> /* string */
 
std::string Run_Command_string(std::string const &str_prog, unsigned const timeout = 5u) noexcept
{
using std::string;
namespace bp = boost::process;
 
try
{
string retval;
 
bp::ipstream ip;
 
/* Start second thread here to capture one line of stdout */
boost::thread reader(
[&retval, &ip]
{
try
{
/* Retain the first line of text */
std::getline(ip,retval);

/* Now just discard the rest of the output */
for (string tmp; std::getline(ip,tmp); ) { /* Do Nothing */ }
}
catch (...)
{
try { retval.clear(); } catch (...) { /* Do Nothing */ }
}
}
);
 
bp::child c(str_prog, bp::std_in.close(), bp::std_out > ip, bp::std_err > bp::null);
 
if ( reader.try_join_for(boost::chrono::seconds(timeout)) )
{
/* Program has ended, so hopefully we have text */
return retval;
}
else
{
/* Program has frozen, so just return an empty string */
reader.interrupt();
// I think technically we're supposed to call 'join' here ???
return string();
}
}
catch (...)
{
return string();
}
}
 
#include <iostream>
 
using std::cout;
using std::endl;
 
auto main(void) -> int
{
//cout << Run_Command_string("ps aux | grep sbin") << endl;
 
/* Under Linux I have to do "sh -c" otherwise the piping from ps to grep doesn't work.
I tried using boost::process:shell but I couldn't get it to work. */

cout << Run_Command_string("sh -c \"ps aux | grep sbin\"") << endl;
}
 
Is there anything you'd change?
cdalten@gmail.com: Mar 09 05:29AM -0700

On Monday, March 9, 2020 at 4:18:20 AM UTC-7, Frederick Gotham wrote:
 
> cout << Run_Command_string("sh -c \"ps aux | grep sbin\"") << endl;
> }
 
> Is there anything you'd change?
 
Your brain.
cdalten@gmail.com: Mar 09 05:37AM -0700

> > }
 
> > Is there anything you'd change?
 
> Your brain.
 
More to the point, the whole moron alert got triggered at the following line...
 
#include <string> /* string */
 
That's as bad as you inverting your conditionals in a previous post. I think maybe the only thing dumber would be a 12 yr old retarded girl having the following as a code comment...
 
return 1; /* returns 1 */
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 09 05:49AM -0700


> return 1; /* returns 1 */
 
 
You should explicitly indicate that it's signed:
 
return static_cast<signed int>(5); /* return 5 as a signed integer */
cdalten@gmail.com: Mar 09 05:59AM -0700

On Monday, March 9, 2020 at 5:49:27 AM UTC-7, Frederick Gotham wrote:
 
> > return 1; /* returns 1 */
 
> You should explicitly indicate that it's signed:
 
> return static_cast<signed int>(5); /* return 5 as a signed integer */
 
You're a dumbass that needs to be banned from coming near a computer.
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 09 06:01AM -0700


> You're a dumbass that needs to be banned from coming near a computer.
 
 
Either meditate more, or give me your home address and I'll send you some beads.
red floyd <no.spam@its.invalid>: Mar 08 06:16PM -0700

On 3/8/20 1:01 AM, Jorgen Grahn wrote:
 
 
> (I dislike 'if (nullptr == expr)' anyway, but for different reasons.)
 
I agree, it doesn't "read" properly. I understand what's going on,
though. I think it's a protection against typo for a single = sign,
if expr happens to evaluate to an lvalue of some kind.
 
e.g.:
 
T*& f();
 
if (f() = nullptr) // oops wrong operator! No diagnostic required.
 
if (nullptr = T()) // oops wrong operator! ERROR
David Brown <david.brown@hesbynett.no>: Mar 09 08:39AM +0100

On 09/03/2020 02:16, red floyd wrote:
 
> T*& f();
 
> if (f() = nullptr)  // oops wrong operator!  No diagnostic required.
 
> if (nullptr = T())  // oops wrong operator!  ERROR
 
That is sometimes known as a "Yoda conditional", precisely because a lot
of people feel it reads backwards. Typos here are easily found by many
tools (IDE's, linters, and compilers) - but if you enable warnings on
"if (x = 0)" then you need extra parenthesis for when you really want to
check the result of an assignment, as "if (x = next_item())" will give
the same warning. But it is very common to have such warnings enabled.
 
However, Jorgen may also have been referring to the superfluous
comparison to nullptr. If "expr" has a pointer type, then "if (expr)"
has exactly the same effect as comparing it to "nullptr".
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 09 07:45AM

On Mon, 2020-03-09, red floyd wrote:
 
> I agree, it doesn't "read" properly. I understand what's going on,
> though. I think it's a protection against typo for a single = sign,
> if expr happens to evaluate to an lvalue of some kind.
 
That whole thing (that argument, the counter-argument, the counter-
counter-arguments) has been beaten to death, though. I hope I didn't
reanimate it.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Mar 09 01:04AM -0700

On Monday, 9 March 2020 09:45:35 UTC+2, Jorgen Grahn wrote:
 
> That whole thing (that argument, the counter-argument, the counter-
> counter-arguments) has been beaten to death, though. I hope I didn't
> reanimate it.
 
I would not participate in project that regulates such idiocy one way or
other. Also I would not let operator== or operator!= overloads that do
not work symmetrically and commutatively to pass review.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 09 09:33AM

On Mon, 2020-03-09, David Brown wrote:
...
> However, Jorgen may also have been referring to the superfluous
> comparison to nullptr.
 
I had forgotten when I responded earlier but yes, I did. I happily
use pointers and smart pointers in boolean context.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Brown <david.brown@hesbynett.no>: Mar 09 10:54AM +0100

On 09/03/2020 09:04, Öö Tiib wrote:
>> reanimate it.
 
> I would not participate in project that regulates such idiocy one way or
> other.
 
Not everyone has that choice. There are some coding standards used that
dictate (or at least strongly encourage) "Yoda conditionals". (I'm sure
you'd dislike other rules too, and for equally good reasons.) Most
programmers work on the projects they are paid to work on and told to
work on, rather than projects they want to work on.
 
> Also I would not let operator== or operator!= overloads that do
> not work symmetrically and commutatively to pass review.
 
I can't imagine any coding standard that would not agree with that one!
Bo Persson <bo@bo-persson.se>: Mar 09 01:51PM +0100

On 2020-03-09 at 10:54, David Brown wrote:
> you'd dislike other rules too, and for equally good reasons.) Most
> programmers work on the projects they are paid to work on and told to
> work on, rather than projects they want to work on.
 
And some programmers go looking for another employer if the work gets
too silly.
Daniel <danielaparker@gmail.com>: Mar 08 04:32PM -0700

On Sunday, March 8, 2020 at 7:12:11 PM UTC-4, Juha Nieminen wrote:
> > could be useful... It is SO BIG that a beginner has no chance in the
> > first few years, of understanding why something compiles or why it doesn't.
 
> Then don't use it. Your infantile whining is useless. Grow up.
 
It is, nonetheless, a legitimate observation, and I'm doubtful that many with
repute on this newsgroup would dispute it. Whether making it serves any
purpose, of course, is another matter.
 
Daniel
Cholo Lennon <chololennon@hotmail.com>: Mar 08 09:37PM -0300

On 3/8/20 8:12 PM, Juha Nieminen wrote:
>> could be useful... It is SO BIG that a beginner has no chance in the
>> first few years, of understanding why something compiles or why it doesn't.
 
> Then don't use it. Your infantile whining is useless. Grow up.
 
Why your critic? "Then don't use it" is really an infantile phrase.
 
He's right, the language is too complex even for advance programmers,
and the complexity is not free, it costs a lot of money and time
(programmers, companies, tool vendors, compiler vendors, etc, all of
them suffer it). It's too complex that the whole tool ecosystem sucks if
you compare it with other languages. And a language that has bad tools
it's a complete failure IMHO. Hiring new competent C++ programmers is
really hard nowadays, and a language without users... you know... tend
to disappears.
 
 
--
Cholo Lennon
Bs.As.
ARG
"Öö Tiib" <ootiib@hot.ee>: Mar 08 06:20PM -0700

On Monday, 9 March 2020 02:37:40 UTC+2, Cholo Lennon wrote:
> and the complexity is not free, it costs a lot of money and time
> (programmers, companies, tool vendors, compiler vendors, etc, all of
> them suffer it).
 
Most of the complexity plus pointless backwards compatibility support
of useless peculiarities like octal numbers and EBCDIC character
encodings is perhaps voted in by monsters who have huge piles of legacy
trash C++ code lying around and on other hand want C++ to look like
garbage compared to their proprietary toy languages (swifts, golangs,
javas, csharps).
 
 
> it's a complete failure IMHO. Hiring new competent C++ programmers is
> really hard nowadays, and a language without users... you know... tend
> to disappears.
 
It is pointless to whine. For example why there is constexpr if there are
no way to detect compile time if something is constexpr or not?
It was in C++14. There was rule in C++14 that constexpr is noexcept.
However that was removed by P0003
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html>
by C++17. The committee (read clicque consisting mostly of wormtongues
of monsters) was informed, but they left it like it was. So C++ is
technically doomed to become worse and worse pile of debris with each
iteration.
jacobnavia <jacob@jacob.remcomp.fr>: Mar 09 07:52AM +0100

Le 09/03/2020 à 00:12, Juha Nieminen a écrit :
>> could be useful... It is SO BIG that a beginner has no chance in the
>> first few years, of understanding why something compiles or why it doesn't.
 
> Then don't use it. Your infantile whining is useless. Grow up.
 
Well, of course I will not use it. Even if I wanted to use it, it would
take me so many years to be productive that it is not really worth the
effort.
 
But your answer, devoid of any arguments, is typical of the "group
think" that abounds in C++ expert circles. Critics to this race to ever
increasing complexity will just be dismissed without even trying to
adress the concerns about this complexity nightmare.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 09 08:10AM

On Sun, 2020-03-08, Daniel wrote:
 
>> Then don't use it. Your infantile whining is useless. Grow up.
 
> It is, nonetheless, a legitimate observation, and I'm doubtful that many with
> repute on this newsgroup would dispute it.
 
Don't know I have repute, but I dispute it, even though I'm sceptical
to the current pace and direction of C++ development.
 
If you get over the fact that you don't know the whole language
(including standard library) I don't think C++ is that difficult to
master. And in particular, I'm pretty sure that in terms of working,
useful code, you can do a lot more, earlier, if you start with C++
than with C.
 
> Whether making it serves any purpose, of course, is another matter.
 
The "OMG it's so complex!" message may prevent some migration from C
to C++.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Maciej Sobczak <see.my.homepage@gmail.com>: Mar 09 01:14AM -0700

> C++ programmers must have big brains, the standard of C++17 is 1633
> pages long! Imagine how much brain space that takes...
 
> The whole bible (King James edition) has 1513 pages...
 
This still does not tell whether the C++ standard is too long, or The Bible is too short, or both are too long, or ... The sure difference being that you can be forgiven for using only a subset of C++. ;-)
 
But:
 
Java: The Complete Reference, Eleventh Edition = 1248 pages.
Core Java (Vol. I+II) = 928 + 960 = 1888 pages.
 
These are *references*, so presumably they were made as short as reasonably possible.
 
> And everybody is happy of course.
 
Of course. And those who are not, are free to move to Java.
 
> The committee goes on adding and
> adding features,
 
And judging by the size of Java books, you could conclude that perhaps this is what the programming community actually asks for. Because even if you invent a much smaller language, it will (inevitably?) grow to address the needs that it did not address when it was young and small.
 
> this incredible featurism is leading the
> language into a pit it will never be able to get out.
 
And where exactly you would like it to get out?
 
> too much time needed to master a small part of it that
> could be useful...
 
I disagree. Most of the complexity addresses the needs of library authors. The language can be immensely useful for library *users* in some reasonably small subset, that can be understood by, even if not complete beginners, then by people who have already seen the ideas of statically typed imperative languages (it is also the task for library authors to design their APIs for wider audience). Then, more advanced concepts can be acquired as the professional career progresses in its natural pace.
You can only complain that you cannot not get 20 years of experience within the first 2 years of practice. Well.
 
But in other languages it does not seem to be any different.
 
--
Maciej Sobczak * http://www.inspirel.com
Ian Collins <ian-news@hotmail.com>: Mar 09 09:18PM +1300

On 09/03/2020 19:52, jacobnavia wrote:
 
> Well, of course I will not use it. Even if I wanted to use it, it would
> take me so many years to be productive that it is not really worth the
> effort.
 
You could be more productive tomorrow with just a the C subset and a
tiny bit more. But you already know (and will probably carry on
ignoring) that.
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Mar 09 11:39AM +0100

On 09/03/2020 09:14, Maciej Sobczak wrote:
 
> This still does not tell whether the C++ standard is too long, or The
> Bible is too short, or both are too long, or ... The sure difference
> being that you can be forgiven for using only a subset of C++. ;-)
 
The key point is to use the subset of C++ that works for you. C++ is a
big language, with a big library, and a huge range of uses. No one is
ever expected to know it all, or find all of it useful. But each part
of it is likely to be useful to /somebody/.
 
> Java (Vol. I+II) = 928 + 960 = 1888 pages.
 
> These are *references*, so presumably they were made as short as
> reasonably possible.
 
For most large languages, complete references and documentation will be
huge. The documentation for Python or PHP will also be massive, and the
languages are full of features that are useful to a few people, and
totally beyond most programmers. Hands up all Python programmers who
truly understand metaclasses, decorators and generators? Hands up all
MSVC programmers who know the entire Windows API? Hands up all C
programmers who understand all the details of floating point?
 
Hands up all the English speakers who know all the words in the OED?
 
There is nothing wrong with a language being too big for people to know
it all. Problems only occur when a lack of knowledge of some parts
means you make subtle mistakes in parts that you think you know. But
that occurs in smaller languages too (like C).
 
 
>> The committee goes on adding and adding features,
 
I've seen several types of features added to C++ over the years. Some
are pure library additions - use them if you want them, or ignore them
if you don't. Some are language enhancements that are hard to
understand, but can mostly be ignored if you want (like rrefs and move
semantics). Some language enhancements sound complex, but make code
simpler (like concepts eliminating gruesome "enable_if" code). Some are
incomprehensible to many people, but allow useful libraries (you don't
have to understand how to write variadic templates in order to use
variants).
 
C++ does suffer from a some serious issues, however. Backwards
compatibility can make things more awkward or bulky than it should be
(someone mentioned EBCDIC, for example). And sometimes the balance
between "make this feature available so that people can use it" and "be
sure this feature doesn't have unexpected problems before it is
released" doesn't hit the mark.
 
> not get 20 years of experience within the first 2 years of practice.
> Well.
 
> But in other languages it does not seem to be any different.
 
Agreed.
Bart <bc@freeuk.com>: Mar 09 11:00AM

On 09/03/2020 08:18, Ian Collins wrote:
 
> You could be more productive tomorrow with just a the C subset and a
> tiny bit more.   But you already know (and will probably carry on
> ignoring) that.
 
Until you make a typo that would be thrown out by a C compiler, but is
legal in C++ and does something you don't expect.
 
Or if it is not legal in C++ either, it generates a 300-line error
message that you can't make head nor tail of.
gazelle@shell.xmission.com (Kenny McCormack): Mar 09 11:20AM

In article <r456d2$e7f$1@dont-email.me>,
>big language, with a big library, and a huge range of uses. No one is
>ever expected to know it all, or find all of it useful. But each part
>of it is likely to be useful to /somebody/.
 
These funny threads. All you supposedly smart people tripping over the
simplest things.
 
The point here, that everybody seems to be ignoring (and which Jacob has
seen fit not to elucidate - no doubt because it winds you people up) is
that the "Use the small subset that you are comfortable with" mantra falls
apart in the following, all-too-common scenario:
 
You work in a company on a large project. Everybody agrees to use C++
for the project. Everybody programs their part in their own, known,
comfortable subset of the C++ language. Nobody can
understand/critique/debug any else's code. Even though they are all
using exactly the same language.
 
Job security!
 
This situation wouldn't occur if they used a smaller, uniform language,
that everybody understood completely.
 
--
If it seems like I'm not responding to some moronic criticism that you've
posted in response to one of my posts, be aware that I do not debate with idiots.
 
It doesn't mean you've won anything...
David Brown <david.brown@hesbynett.no>: Mar 09 12:46PM +0100

On 09/03/2020 12:20, Kenny McCormack wrote:
> comfortable subset of the C++ language. Nobody can
> understand/critique/debug any else's code. Even though they are all
> using exactly the same language.
 
That's not a language problem - that is a management problem.
 
 
> Job security!
 
> This situation wouldn't occur if they used a smaller, uniform language,
> that everybody understood completely.
 
And what, exactly, would that language be?
Paavo Helde <myfirstname@osa.pri.ee>: Mar 09 01:50PM +0200

On 9.03.2020 13:20, Kenny McCormack wrote:
 
> Job security!
 
> This situation wouldn't occur if they used a smaller, uniform language,
> that everybody understood completely.
 
A smaller language will miss many features, meaning that everybody has
to invent their own wheels. What makes you think that understanding and
debugging e.g. N half-baked and partially copy-pasted hash container
variants from various colleagues is easier than learning the interface
of std::unordered_map once?
 
Or is it really easier if every colleague reinvents C++ templates in C
each by their own way, some by macros, some by copy-paste, etc?
 
Linux kernel is successful because they have lots of discipline and a
lot of common agreements in place, like how to implement virtual tables
and OOP in C in an unified way etc. I'm sure it would take more than
1000 pages to specify all those agreements in detail.
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)