Monday, March 9, 2020

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

Juha Nieminen <nospam@thanks.invalid>: Mar 09 12:14PM


> 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.
 
Are you in the habit of going to forums for different kinds of things,
like programming languages, software, operating systems and the like,
which you don't use, and complaining that it's "too complicated"?
 
If you are not using the thing, then why are you whining?
jacobnavia <jacob@jacob.remcomp.fr>: Mar 09 02:28PM +0100

Le 09/03/2020 à 13:14, Juha Nieminen a écrit :
> like programming languages, software, operating systems and the like,
> which you don't use, and complaining that it's "too complicated"?
 
> If you are not using the thing, then why are you whining?
 
1: I am reflecting about the direction C++ is heading and expressing a
view that it is keeping a wrong direction: instead of simplifying it
keeps adding features piled upon more features. This is my opinion.
You can qualify it as "whining" in a pejorative way, but I really do not
care about your polemic.
 
2: I am a C programmer/developper, and since C++ is C compatible to a
certain extent, I am interested in it. Besides, I have landed some
consulting jobs to fix C++ software, so I try to follow (as far as I
can) the new developments in it.
 
3: Fixing C++ bugs gives you a different perspective on its development.
For instance the new feature of C++17 that allows to distinguish between
a function that throws and one that doesn't (where it is unclear if a
function that throws an int is different that one that throws a long
long, the example doesn't mention that possibility) and that is a NEW
feature. Will that change or affect old code?
 
Most of these consulting jobs are like this:
 
Customer:
Hey jacob, this code compiled under gcc 4.2 but now it doesn't. Can you
fix that?
 
Jacob:
Sure, but that is C++. Penalties apply for the bill.
 
Customer
Look jacob just FIX IT ok?
 
Jacob
Sure sure, don't get angry.
 
After that I go to the forums, look in google, and figure out what
changes to the language are affecting the code. Sometimes I can read the
error message, google around, etc.
 
It takes an awful lot of work but in most cases I can fix it or develop
a work around.
 
This "usage" is not really usage in the common sense of the word. I am
not really programming in C++, just trying to make money from its bugs...
 
:-)
 
jacob
Paavo Helde <myfirstname@osa.pri.ee>: Mar 09 04:18PM +0200

On 9.03.2020 15:28, jacobnavia wrote:
 
> Most of these consulting jobs are like this:
 
> Customer:
> Hey jacob, this code compiled under gcc 4.2 but now it doesn't.
 
These problems mostly appear because the code was sloppy and
non-conforming in the first place, but older gcc versions did not check
it so thoroughly.
 
There have been very few actual code breaking changes in the C++
standards. Unless your customers are using trigraphs or marking all
their variables 'auto' or 'register', it should work fine, assuming the
code was correct C++98 in the first place. And obsolete usage of
trigraphs, auto and register is trivial to fix.
 
 
> After that I go to the forums, look in google, and figure out what
> changes to the language are affecting the code. Sometimes I can read the
> error message, google around, etc.
 
Suggesting to compile it with clang, it makes some effort to produce
helpful error messages and actually suggests necessary fixes like
injecting missing template/typename keywords (a frequent source of
problems with compiler version upgrades).
 
 
> It takes an awful lot of work but in most cases I can fix it or develop
> a work around.
 
Of course it will take a lot of time if you do work which you are not
really qualified for.
 
 
> This "usage" is not really usage in the common sense of the word. I am
> not really programming in C++, just trying to make money from its bugs...
 
The customer bugs, you mean.
Daniel <danielaparker@gmail.com>: Mar 09 07:19AM -0700

On Monday, March 9, 2020 at 6:39:40 AM UTC-4, David Brown wrote:
> On 09/03/2020 09:14, Maciej Sobczak wrote:
 
> > But in other languages it does not seem to be any different.
 
> Agreed.
 
Is it? Do you know of another language where && means two completely
different things, depending on whether is template or not? Or T{} means
different things for 0, 1 and 2 arguments, depending on T's constructors? Is
there another language where somebody felt they had to write an entire book
entitled Move Semantics - The Complete Guide? A std::string_view that has
conversion semantics with std::string that are opposite to those of const char*? The list is endless. In the meantime we don't have int128_t because
modifying intmax_t is an ABI break, we don't have big_integer or big_decimal
or big_float, or unicode conversion utilities, or random number generators
that game developers or finance risk engines can use. Now there are many
stakeholders that don't use the standard library - game developers have EASTL,
Facebook has folly, Google has Abseil. Maybe that's a better way forward.
 
Daniel
Maciej Sobczak <see.my.homepage@gmail.com>: Mar 09 07:20AM -0700

> You work in a company on a large project.
 
OK.
 
> Everybody agrees to use C++
> for the project.
 
Not likely, because usually not everybody takes part in the decision process. If that was a big project, the decision was centralized. Most likely, it was taken even before most of the participants got on board.
But let's move on.
 
> Everybody programs their part in their own,
 
No. The company has (better) selected an existing or (worse, but passable) invented their own coding standard that was imposed on everybody in the project. Non-complying individuals are systematically discouraged from diverting from the common standard. The company uses tools to automate those checks.
 
> Nobody can
> understand/critique/debug any else's code.
 
No, see above. Your argument fell apart.
 
Unless you work in a very badly managed company. But then, the choice of programming language is not your biggest problem.
 
> This situation wouldn't occur if they used a smaller, uniform language,
> that everybody understood completely.
 
Like the one defined by their chosen coding standard?
Sure, and that's why those coding standards get invented.
 
--
Maciej Sobczak * http://www.inspirel.com
Maciej Sobczak <see.my.homepage@gmail.com>: Mar 09 07:29AM -0700

> Is it? Do you know of another language where && means two completely
> different things, depending on whether is template or not?
 
Heck, at least this is known statically... Duck-typed languages can make such differences even funnier.
 
But you might entertain yourself learning about equality operation in LISP:
 
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node74.html
 
And you thought C++ is complex? :-)
 
--
Maciej Sobczak * http://www.inspirel.com
Daniel <danielaparker@gmail.com>: Mar 09 07:41AM -0700

On Monday, March 9, 2020 at 7:50:53 AM UTC-4, Paavo Helde wrote:

> A smaller language will miss many features, meaning that everybody has
> to invent their own wheels.
 
Everybody is already reinventing their own wheels. game developers have EASTL,
Facebook has folly, Google has Abseil. Game developers and finance risk
systems can't use standard library random number generators for repeatability
and verifiability reasons. Rapidjson and some other json libraries have their
own floating point parsing, more have their own floating point printing. All
json libraries have their own unicode conversion and validation code. The list
goes on.
 
Daniel
Daniel <danielaparker@gmail.com>: Mar 09 08:33AM -0700

On Monday, March 9, 2020 at 10:29:53 AM UTC-4, Maciej Sobczak wrote:
 
> But you might entertain yourself learning about equality operation in LISP:
 
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node74.html
 
> And you thought C++ is complex? :-)
 
Point taken :-) That link failed for me, but I found this one
 
http://clhs.lisp.se/Body/f_equal.htm
 
Daniel
Paavo Helde <myfirstname@osa.pri.ee>: Mar 09 05:50PM +0200

On 9.03.2020 16:41, Daniel wrote:
 
>> A smaller language will miss many features, meaning that everybody has
>> to invent their own wheels.
 
> Everybody is already reinventing their own wheels.
 
And sometimes unnecessarily.
 
> own floating point parsing, more have their own floating point printing. All
> json libraries have their own unicode conversion and validation code. The list
> goes on.
 
Special needs will require special solutions anyway, that's very fine.
The point is that those 99% of language users who don't need EASTL can
use the standard STL.
 
Moreover, even those with special needs can use the basic template and
OOP mechanisms, instead of reinventing their own as it happens in C. And
they can use other standard means in the program parts which do not
require special means.
jacobnavia <jacob@jacob.remcomp.fr>: Mar 09 06:00PM +0100

Le 09/03/2020 à 15:20, Maciej Sobczak a écrit :
>> Everybody programs their part in their own,
> No. The company has (better) selected an existing or (worse, but passable) invented their own coding standard that was imposed on everybody in the project
 
I would like to point out the logic behind this reasoning:
 
1: Everyone agrees that it is impossible for a normal individual to
understand all C++
 
2: Then, you have to define a new subset of it, accessible to mere
humans and not compilers
 
3: You "standardize" into that subset.
 
This is completely incredible as a situation and shows how C++ people
reason!
gazelle@shell.xmission.com (Kenny McCormack): Mar 09 05:14PM

In article <r45snb$po3$1@dont-email.me>,
jacobnavia <jacob@jacob.remcomp.fr> wrote:
...
 
>3: You "standardize" into that subset.
 
>This is completely incredible as a situation and shows how C++ people
>reason!
 
Quite so.
 
And let me note that the responses (other than Jacob's) to my little poke
in this thread have all been of the "circling the wagons" variety. That is
to say, they are all utter nonsense.
 
--
I've learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.
 
- Maya Angelou -
jacobnavia <jacob@jacob.remcomp.fr>: Mar 09 06:36PM +0100

Le 09/03/2020 à 16:33, Daniel a écrit :
 
> Point taken :-) That link failed for me, but I found this one
 
> http://clhs.lisp.se/Body/f_equal.htm
 
> Daniel
 
Well, of course common lisp is baroque, but that is an unfair comparison.
 
The page leads to the definition of "equal" in lisp
 
"equal" is a recursive depth first comparison, that doesn't even exist
in C++ since it compares whole trees of objects for equality. C++ has
only shallow equality, it doesn't follow pointers as in lisp.
 
There is in lisp the distinction between "eq" (address comparison) and
eql (value comparison) and equal (trees comparison). In C++ you have
"==" that compares values (scalar values) what would be similar to "eql"
but not to "equal" that doesn't exist in C++.
 
At least the lisp complexity is warranted by more performance (trees
comparison). But I will stop here, maybe if I go on the C++ committee
will hear that and will add it to C++27!
 
:-)
Maciej Sobczak <see.my.homepage@gmail.com>: Mar 09 03:45PM -0700

> I would like to point out the logic behind this reasoning:
 
> 1: Everyone agrees that it is impossible for a normal individual to
> understand all C++
 
I have not seen any agreement on this (it's just your perspective). I would rather say that it is not *necessary* for a normal individual to understand all of C++. And nobody expects that.
 
> 2: Then, you have to define a new subset of it, accessible to mere
> humans and not compilers
 
Wrong. There are also tools for doing useful stuff. Say I have a tool that can draw diagrams based on code (and I value those diagrams a lot), but it is not up to date with all new language features and would break when faced with too fancy code. This is also a reason to standardize locally on a smaller subset.
Another tool might perform static analysis of some important properties of my programs and I also might want to step back with too liberal language use to reap the benefits of these analyses.
And so on. It's not only humans vs. compilers.
 
> 3: You "standardize" into that subset.
 
Yes. And interestingly, I might want to pick different subsets for each of my projects.
 
> This is completely incredible
 
I guess you have never thought, even for a while, how engineering goes in any other technical domain, right? Multiple levels of standardization and conventions are used everywhere. Your daily life depends on people who choose to only use agreed subsets of what their available tech allows them - and you would be seriously messed up otherwise. C++ is not any different.
 
And, by the way, there are coding standards for other programming languages, too. For the same reasons.
 
--
Maciej Sobczak * http://www.inspirel.com
cdalten@gmail.com: Mar 09 06:14AM -0700

On Monday, March 9, 2020 at 6:01:26 AM UTC-7, Frederick Gotham wrote:
> On Monday, March 9, 2020 at 12:59:58 PM UTC, cda...@gmail.com wrote:
 
> > 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.
 
If you are trying to get this to run under Linux, and insist on using a PC, might I suggest that you give *BOTH* the computer and your right had a rest, and like read "Advanced Programming in the Unix Environment" by the late Dr. Stevens. After that, take a step back and ask yourself "Why I'm I using C++ to write a Linux program."
 
This is words can't express the pure abomination on the following winner line of code..
 
cout << Run_Command_string("sh -c \"ps aux | grep sbin\"") << endl;
 
 
This is in addition to your retarded comments, coupled with your thinking it's okay to invert an expression because some jackass heathen fast food worker posted it on stackoverflow, and everything else.
 
Well...here is some other advice.
 
Step away from your computer. After that, disconnect your PC, open your windows, throw the thing in the trash, and then ask yourself "How come I still get find a person of the opposite sex who will date me?"
cdalten@gmail.com: Mar 09 06:16AM -0700


> This is in addition to your retarded comments, coupled with your thinking it's okay to invert an expression because some jackass heathen fast food worker posted it on stackoverflow, and everything else.
 
> Well...here is some other advice.
 
> Step away from your computer. After that, disconnect your PC, open your windows, throw the thing in the trash, and then ask yourself "How come I still get find a person of the opposite sex who will date me?"
 
 
And apparently my I can't write this morning. Whatever. I need to get back to writing code at my job.
cdalten@gmail.com: Mar 09 06:19AM -0700

On Monday, March 9, 2020 at 6:01:26 AM UTC-7, Frederick Gotham wrote:
> On Monday, March 9, 2020 at 12:59:58 PM UTC, cda...@gmail.com wrote:
 
> > 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.
 
If you are trying to get this to run under Linux, and insist on using a PC, might I suggest that you give *BOTH* the computer and your right had a rest, and like read "Advanced Programming in the Unix Environment" by the late Dr. Stevens. After that, take a step back and ask yourself "Why I'm I using C++ to write a Linux program."
 
Because the following in words can't express the pure abomination on the following winner line of code..
 
cout << Run_Command_string("sh -c \"ps aux | grep sbin\"") << endl;
 
 
This is in addition to your retarded comments, coupled with your thinking it's okay to invert an expression because some jackass heathen fast food worker posted it on stackoverflow, and everything else.
 
Well...here is some other advice.
 
Step away from your computer. After that, disconnect your PC, open your windows, throw the thing in the trash, and then ask yourself "How come I still find a person of the opposite sex who will date me?"
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 09 09:16AM -0700

On Monday, March 9, 2020 at 11:18:20 AM UTC, Frederick Gotham wrote:
 
> 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.
 
 
After testing my previous code, I've now got the following which works on Linux x64 and Linux armhf(32bit):
 
std::string Run_Command_string(std::string str_cmd, unsigned const timeout = 5u) noexcept
{
using std::string;
namespace bp = boost::process;
 
try
{
string retval;
 
bp::ipstream ip;
 
boost::replace_all(str_cmd, "\"", "\\\"");

cout << "sh -c \"" + str_cmd + "\"" << endl;

bp::child c(bp::search_path("sh"), "-c", str_cmd, bp::std_in.close(), bp::std_out > ip, bp::std_err > bp::null);
 
cout << "About to start other thread. . ." << endl;

/* Start second thread here to capture one line of stdout */
boost::thread reader(
[&retval, &ip]
{
try
{
/* Retain the first line of text */
cout << "About to try to get a line of text" << endl;
std::getline(ip,retval);
cout << "Got line of text: " << retval << endl;
 
/* Now just discard the rest of the output */
for (string tmp; std::getline(ip,tmp); ) { /* Do Nothing */ }
}
catch (...)
{
try { retval.clear(); } catch (...) { /* Do Nothing */ }
}
}
);
 
cout << "About to wait for other thread. . ." << endl;

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 (...)
{
cout << "Exception caught inside Run_Command_string" << endl;
return string();
}
}
 
I should be able to use "boost::process::shell" instead of doing "sh" "-c", but I just can't get the former to work.
David Brown <david.brown@hesbynett.no>: Mar 09 02:57PM +0100

On 09/03/2020 13:51, Bo Persson wrote:
>> work on, rather than projects they want to work on.
 
> And some programmers go looking for another employer if the work gets
> too silly.
 
And some programmers can't conveniently do so. We could go round in
circles all day. But I think it is undeniable that any professional is
going to have to spend some time doing work he/she doesn't like,
following rules that they think are wrong, spending effort that they
think is counter-productive. Those that are lucky and/or higher up in
the ranks do this less, those that are unlucky do it more. There are
certainly very few who would be ready to walk out of a job because they
are asked to write "if (1 == x)" instead of "if (x == 1)".
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 09 08:12AM -0700

On Friday, March 7, 2020 at 05:47:54 UTC-8, Chad wrote:
...
> error at runtime while the other doesn't. While this might be okay in
> C++, carry this kind of practice over to other programming languages
> has some really really bad consequences.
No, this kind of practice would not be OK in C++. But when I say "this
kind of practice", I'm not referring to performing the comparison in the
"wrong" order. There shouldn't be a "wrong" order for an inherently
symmetric operator like equals() (or != in the C++ code you were
originally complaining about). The thing that is not OK about this code
is defining equals() in such a way that the order makes a difference.
 
Thanks to Jorgen, I now understand that this behavior depends upon the
fact that, unlike C++, Java supports null references. In C++, in order
for getAction() to indicate that there was no action to be gotten, it
would have to return a pointer, not a reference (or possibly
std::optional<> - but I'm not sufficiently familiar with std::optional<>
to be sure of that). Null pointers ARE supported in C++. You certainly
could define a comparison that takes pointer arguments, and compares the
things pointed at, rather than the pointers themselves. You could define
the function to either throw or return false when one of the pointers is
null - either behavior might make sense, in different contexts.
 
However, it is bad design to define equals() in such a way that, when pB
is null, equals(pA, pB) throws while equals(pB, pA) returns false. And
that's what's not OK about the java code you've shown. The C++ code you
claimed had undefined behavior displays no such problem.
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: