Sunday, March 12, 2017

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

Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 12 11:01AM


> int fn() {
> return fn2a(fn1());
> }
 
or, in sufficiently modern C++, using an anonymous function:
 
int fn() { return [](auto r){ return r + fn2(); }(fn1());
 
There's enough noise (all those (){[](){()}(())}s) that it's only good
for illustration but at least g++ compiles it down to minimal code (with
-O2).
 
--
Ben.
legalize+jeeves@mail.xmission.com (Richard): Mar 12 10:33PM

[Please do not mail me a copy of your followup]
 
Alvin <Alvin@invalid.invalid> spake the secret code
 
>int fn() {
> return fn1() + fn2();
>}
 
I wouldn't want commutative math operations to enforce an ordering
because that is an unwarranted imposition on the compiler IMO.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Andrey Karpov <karpov2007@gmail.com>: Mar 12 11:43AM -0700

> I don't see the problem in the 5th place entry.
 
You're right, it's a slip-up. It happens, you know. Only those who don't write articles don't make mistakes in them. :)
 
However, it's shit code anyway and one shouldn't write like that. Perhaps the programmer wanted to call the constructor but failed, and the code works only because of sheer luck.
Andrey Karpov <karpov2007@gmail.com>: Mar 12 11:45AM -0700

5th item - it's a slip-up. It happens, you know. Only those who don't write articles don't make mistakes in them. :)
 
However, it's shit code anyway and one shouldn't write like that. Perhaps the programmer wanted to call the constructor but failed, and the code works only because of sheer luck.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 12 12:00PM -0700

On Sunday, March 12, 2017 at 2:43:54 PM UTC-4, Andrey Karpov wrote:
> You're right, it's a slip-up. It happens, you know. Only those who don't
> write articles don't make mistakes in them. :)
 
> However, it's .. code anyway...
 
Andrey Karpov, do you think your post was better with the profanity in
there?
 
Has anyone ever taught you who Jesus is? What He's about? What sin is?
And why you need to be forgiven for your sin?
 
Thank you,
Rick C. Hodgin
Manfred <invalid@invalid.add>: Mar 12 11:20PM +0100

On 03/12/2017 07:43 PM, Andrey Karpov wrote:
>> I don't see the problem in the 5th place entry.
 
> You're right, it's a slip-up. It happens, you know. Only those who don't write articles don't make mistakes in them. :)
 
> However, it's shit code anyway and one shouldn't write like that. Perhaps the programmer wanted to call the constructor but failed, and the code works only because of sheer luck.
 
Not sure that the code works only because of sheer luck.
In fact any access to G4PhysicsModelCatalog is guaranteed to have the
(private static) catalog initialized, so the code appears to work, and
not by coincidence.
Still the design could be improved.
legalize+jeeves@mail.xmission.com (Richard): Mar 12 10:27PM

[Please do not mail me a copy of your followup]
 
Andrey Karpov <karpov2007@gmail.com> spake the secret code
 
>However, it's shit code anyway and one shouldn't write like that.
>Perhaps the programmer wanted to call the constructor but failed, and
>the code works only because of sheer luck.
 
Yeah, I totally agree that the design is awkward. If your intention
is to initialize the globals-variables-declared-as-class-static-members,
then make that intention clear by an appropriately named static
funtion like
 
prepareCatalog()
 
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Christiano <christiano@engineer.com>: Mar 12 01:47PM -0300

In the book [1], page 360
 
The code is:
 
#include <iostream>
#include <stdexcept>
 
int main()
{
std::cout << "Please, enter an integer in the range 1 to 10
(inclusive):\n";
int n = 0;
 
while(true) {
std::cin >> n;
 
if(std::cin) { // Region 1
if(1<=n && n<=10) break;
std::cout << "Sorry, " << n << " is not in the [1:10]
range; please, try again\n";
 
}
else if(std::cin.fail()) { // Region 2
std::cin.clear();
 
std::cout << "Sorry, that was not a number; please try
again\n";
for(char ch; std::cin>>ch && !isdigit(ch);)
std::cout << "repeat\n";
if(!std::cin)
throw std::runtime_error("no input");
std::cin.unget();
 
 
}
else { // Region 3
// book says here : "eof or bad: give up "
throw std::runtime_error("no input");
}
}
 
return 0;
}
 
The problem is that the region 3 will never be reached.
The negation of bool "std::cin" is the bool "std::cin.fail()", according
to ISO/IEC 14882:2011 27.5.5.4, therefore, the condition " else
if(std::cin.fail()) " is a redundancy since if the flux control goes
through the "else" of region 2 then it only has happened because
std::cin.fail() is true. The effect of this is that Region 3 will never
be reached, although the book Region3 comment: "// eof or bad: give up"(
= [c]).
Regarding the commentary [c]:
First, bad will be detected by fail(), according with ISO/IEC
14882:2011(E) 27.5.5.4.9.
Secondly, eof will cause a fail-set, because it generate a format
problem, therefore the eof will be detected also by first "if" (so
entering in the region 2).
 
Testing (Text inside "****" is my comment) :
 
debian@debian:~/principles/project2$ ./a.out
Please, enter an integer in the range 1 to 10 (inclusive):
******* HERE I PRESS CTRL+D (LINUX) TO FORCE A END OF FILE **************
Sorry, that was not a number; please try again ***** EOF ENTER
REGION 2 AS MY EXPECTATION ****
1
debian@debian:~/principles/project2$
 
My conclusion is that this code is confusing because the last branch
will never be accessed.
But I am just learning the C ++ language and therefore I would like to
hear the opinion of the most experienced.
 
For the learner any little mistake in the book is a mountain generating
doubts.
 
[1] http://stroustrup.com/Programming/
ISBN 978-0-321-99278-9
Fourth Printing
Programming: Principles and Practice using C++ (Second Edition)
In respect to the group and author: I have the original book;
using here only a little portion of the book for
educational/research purposes according to fair use.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 12 06:05PM +0100

On 12-Mar-17 5:47 PM, Christiano wrote:
 
> return 0;
> }
 
> The problem is that the region 3 will never be reached.
 
That's a bug all right. Good catch!
 
 
[snip]
> But I am just learning the C ++ language and therefore I would like to
> hear the opinion of the most experienced.
 
Note: logic can nearly always be trusted.
 
This bug is not in the second edition's errata list at <url:
http://www.stroustrup.com/Programming/PPP2errata.html>.
 
But how to report it?
 
Apparently Bjarne has removed his e-mail address from the web, and I see
no contact information for the book. But people have managed to contact
him. After all, there /is/ an errata list, and thanks to people for
contributing. So maybe I'm blind. That I just don't see it.
 
Anyway, according to gmail, the last mail address I had for him was
(rot-13-encoded, at-sign spelled out) "of at pf.gnzh.rqh"; as it
happened we discussed just that book. ;-)
 
 
Cheers & hth.,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 12 06:30PM +0100

On 12-Mar-17 6:05 PM, Alf P. Steinbach wrote:
 
[snip]
> Anyway, according to gmail, the last mail address I had for him was
> (rot-13-encoded, at-sign spelled out) "of at pf.gnzh.rqh"; as it
> happened we discussed just that book. ;-)
 
Oh. Found:
<url: https://parasol.tamu.edu/~bs/>
 
 
Cheers!,
 
- Alf
Christiano <christiano@engineer.com>: Mar 12 05:34PM -0300

On 03/12/2017 02:30 PM, Alf P. Steinbach wrote:
> <url: https://parasol.tamu.edu/~bs/>
 
> Cheers!,
 
> - Alf
 
Hi, Alf,
 
I already contacted him saying that I would report *possible* bugs in
the specific group about the book:
https://groups.google.com/forum/#!forum/ppp-public
So he could search when he has an interest.
I'd rather not contact him directly because this can be considered an
excess.
 
Thank you
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 12 10:37PM +0100

On 12-Mar-17 9:34 PM, Christiano wrote:
> So he could search when he has an interest.
> I'd rather not contact him directly because this can be considered an
> excess.
 
Oh, well this is a definite bug. `if( !x ) {...} else if( x ) { ... }
else { /* spurious conclusion */ }`. There's no "possible" about it,
it's very definitely a bug.
 
As far as I know Bjarne has always tried to reply to clc++ users who
contacted him. Around 10 years ago or so he still posted here. The last
clc++ posting of his I found now was in 2006, as a response to me, but
that's because I remembered what to search for, the intentional
¹misspeling. I don't think he reads this group anymore; too much noise,
at least when one doesn't use a newsreader with noise filters. It's
possible though that he reads the dedicated-to-PPP Google group.
 
But I think he will be happy if you contact him about a definite error
in the book. You can just write that an old Norwegian Usenet denizen
name of Alf told you to. It helps the community to have things fixed. ;-)
 
 
Cheers!,
 
- Alf
 
¹ <url:
https://groups.google.com/d/msg/comp.lang.c++/PbywU1s6sqI/TJjnFd4xYYsJ>
ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 06:36PM

>Apparently Bjarne has removed his e-mail address from the web, and I see
>no contact information for the book. But people have managed to contact
>him.
 
OT:
 
Once I wrote to a programming legend about as large as
Bjarne by guessing his e-mail address (there was no
indication published that he has an e-mail address at all).
 
My first guess turned out to be correct (I received an
answer), and I pondered the idea of the stance "Anyone who
is able to correctly guess my address may write to me."
ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 09:20PM

>I'd rather not contact him directly because this can be considered an
>excess.
 
If you want to give feedback about a book, I think you might
just send it to the publishing house. They then can sort out
what they want to pass on to the author.
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 11 08:49PM -0800

ok i will try :) by dosbox do u mean virtualvm box ?
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 12 07:40PM

On Sat, 2017-03-11, kushal bhattacharya wrote:
> layer and how it allocates data and other memory related stuffs
> . Can any of you please give me some references or any book from
> where i can have a start? Thanks, Kushal
 
I don't know what you already know, but if you don't already know
about processes, you should probably start there. Perhaps with Unix
processes -- there's a lot more material out there on them than on
threads.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 11 11:07PM -0800

On 3/9/2017 1:02 PM, Chris M. Thomasson wrote:
 
> Is this crap? It cannot be anything new. But, it would be nice to talk
> about threading here for C++ can handle it now.
 
> Nice! :^)
 
I hope the thought did not come across as stupid, but can we have a
discussion on this? How do you handle blocking?
Paavo Helde <myfirstname@osa.pri.ee>: Mar 12 10:19AM +0200

On 12.03.2017 9:07, Chris M. Thomasson wrote:
 
>> Nice! :^)
 
> I hope the thought did not come across as stupid, but can we have a
> discussion on this? How do you handle blocking?
 
In my programs I strive to make mutex lock durations as short as
possible. Typically just a pointer will be added or removed from a queue
during the lock. Therefore the mutex would become available very soon
and there would be no point to try anything else during that time.
 
Having long lock times and trying to carry out other tasks while waiting
for the lock seems like a sure receipt for over-complicating the system,
increasing the danger of deadlocks and decreasing the responsiveness of
the program. YMMV.
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 12 12:48AM -0800

On 3/12/2017 12:19 AM, Paavo Helde wrote:
> for the lock seems like a sure receipt for over-complicating the system,
> increasing the danger of deadlocks and decreasing the responsiveness of
> the program. YMMV.
 
long wait times should be avoided. However, think about how short wait
times should gain the lock in step 0 more often than not.
The slow path fallback is step 2:
_____________________________________
for (;;)
{
0: if (try_lock()) return;
 
1: if (! try_something_else())
{
// possible nesting opportunity...
2: lock();
3: return;
}
}
_____________________________________
 
Not sure about deadlocks yet, should not be a problem if we know some
things about the nature of step 1. This can be modeled wrt making step 1
random. Sometimes it has some work to do, other times it does not. When
not, it falls back to the slow path in step 2.
 
There should be a limit on the for (;;) to prevent infinite loop wrt
always having other work to do, and always failing the try lock.
 
So, perhaps something like:
_______________________________________
for (unsigned int i = 0; i < 42; ++i)
{
if (try_lock()) return;
 
if (! try_something_else())
{
break;
}
}
 
lock();
return;
_______________________________________
 
 
Trying to think of a contrived usage case here.
 
 
;^)
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)