shaneasd

I'm a little confused. It seems like there's an inconsistency between the view expressed in http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-expects and the view being presented here (particularly by @BjarneStroustrup ). That rule, as I...

The guidelines currently recommend ```if (p)``` over ```if (p == nullptr)``` in http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es87-dont-add-redundant--or--to-conditions . Though I prefer ==nullptr so I'm intrigued by the ```//I accept it``` I believe ```if (p==0)```...

Is this a problem (and possible solution) for pointers in general? I don't see what makes ```this``` special. For example why should the treatment of ```this``` be different to ```x```...

That doesn't sound like a problem specific to lambdas though right? Indeed various smart pointer solutions aim to solve this sort of problem by making ownership (and thus lifetime) more...

Related/Duplicate: #1707

The guideline does include the line > We also include lossy arithmetic casts, such as from a negative floating point type to an unsigned integral type: followed by example code...

This issue sounds like a duplicate of #1561

Thanks for your response. I'm not yet convinced but that's exactly the kind of concrete recommendation I'd like from this rule. The justification I see for 1 is that as...

I suspect a lot of the time you run into this problem it probably is an indicator of bad design and as such it's a little tricky to produce example...

> If it is fine at all, then it is fine. Period. I agree. My assertion is that therefore it is not fine. You're right that the reading of Parent::Reset()...