Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Style: Declaration in if/while-condition - good or bad?

Reply
Thread Tools

Style: Declaration in if/while-condition - good or bad?

 
 
goran.pusic@gmail.com
Guest
Posts: n/a
 
      03-01-2013
On Wednesday, February 27, 2013 2:40:58 PM UTC+1, Tobias Müller wrote:
> Martin Ba <(E-Mail Removed)> wrote:
>
> > C(++) allows for a simple variable declaration+init in the condition ofan if or while:

>
> >

>
> > while (T t = x) {

>
> > }

>
> >

>
> > if (int x = f()) {

>
> > }

>
> >

>
> > I find this rather useful for things like:

>
> >

>
> > if (const T* pThing = GetThing()) {

>
> > ...

>
> > } else {

>
> > // Handle No-Thing case

>
> > }

>
> >

>
> >

>
> > However, I have been told by a colleague that this is little used and

>
> > would surprise and confuse a lot of developers and therefore it's better to use the form:

>
> >

>
> > const T* pThing = GetThing();

>
> > if (pThing) {

>
> > ...

>
> > } else {

>
> > // Handle No-Thing case

>
> > }

>
> >

>
> >

>
> > Opinions?

>
>
>
> Regardless whether someone is actually using it or not, it should at least
>
> be clear what it does. I don't understand how this is confusing. Everyone
>
> uses it with 'for' loops.
>
>
>
> Personally, I use it from time to time but it has also some drawbacks.
>
>
>
> Pro:
>
> - Keeps the outer scope clean.
>
> - Declaration is very close to the point where it is used, especially in
>
> 'else if' conditions.
>
> Con:
>
> - Only possible with implicit conversion to bool instead if explicit
>
> condition (e.g. pThing != NULL).
>
> - Complex conditions are not possible. E.g: if (pThing &&
>
> pThing->IsValid())


That second one is better solved through refactoring, e.g.:

if (auto p = getValidThing(...))
{
}

and

namespace {
const TYPE* getValidThing(...)
{
auto result = getThing();
if (!result)
return nullptr;
if (!isvalidThing(*result))
return nullptr;
return nullptr;
}
}
Moving complex conditions into trivial helpers has no impact on
performance (will get inlined anyhow), but is often a boon for readability.

Nobody should read a three-line "if". That induces a headache, especially on a Friday!

G.
 
Reply With Quote
 
 
 
 
Balog Pal
Guest
Posts: n/a
 
      03-02-2013
On 3/1/2013 7:12 AM, BCFD36 wrote:
> 2. When debugging, you can breakpoint on the line with the call.
> Depending on the debugger, you may not easily be able to step into
> GetThing(). Stepping out also could get interesting.


That's a killer argument indeed. IMNSHO where singlestepping and
breakpointing in a debugger takes up practically measurable amount of
dev time we can hardly speak about quality in the first place.

And tuning code for that activity implies that even hope is abandoned
that it gets better.

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      03-04-2013
On Friday, 1 March 2013 09:48:18 UTC, Martin T. wrote:
> On 28.02.2013 18:37, James Kanze wrote:


> > On Thursday, February 28, 2013 11:22:26 AM UTC, Andy Champ wrote:
> >> On 28/02/2013 10:23, Martin Ba wrote:


> >>> On 27.02.2013 15:26, David Brown wrote:
> >>>> On 27/02/13 13:41, Martin Ba wrote:
> >>>>> C(++) allows for a simple variable declaration+init in the condition of
> >>>>> an if or while.....


> >> There are two things here - it looks a bit odd to put "if
> >> (type var = ...) into code. But the fact that it limits the
> >> scope of the variable is a far more powerful argument than it
> >> relying on the implicit conversion to bool.


> > The implicit conversion to `bool` is, of course, a killer
> > argument. This is one of the most confusing features of C/C++;
> > and even after more than 30 years of using the language, I still
> > get confused by things like `if ( strcmp(...) )`. Even in C, it
> > was more less recognized good practice to program as if the
> > language had a boolean type, the comparison operators returned
> > a boolean type, and there were no implicit conversions to
> > `bool`. Those have been the rules in every coding guidelines
> > I've seen in those 30 years.


> Care to give any references? (How many have you seen? By whom?)


I'd guess I've seen something like 10. They're all proprietary,
of course, because they were developed in house for the
companies I've worked for. This goes back to C, of course, but
the Ellemtel coding guidelines explicitly forbid it as well.

It's worth noting, too, that in the original proposal to add
`bool` to the language, conversions of pointer to bool were to
be deprecated.

> T* p;


> ...


> if (p) {
> }


> seems perfectly fine to me.


And I (and most people I've worked with) find it confusing.

--
James
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-04-2013
James Kanze <(E-Mail Removed)> writes:
>> if (p) {
>> }
>> seems perfectly fine to me.

>And I (and most people I've worked with) find it confusing.


A C++ programmer eventually is expected to understand code like

template< typename A, typename B >
::std::function< B( A )>fix( std::function< std::function
< B( A )>(std::function< B( A )>)> f )
{ F< ::std::function< B( A )>>r =
{ ::std::function< std::function< B( A )>
( F< std::function< B( A )>>) >
([ f ](F< std::function< B( A )>> w )
{ return f( ::std::function< B( A )>([ w ]( A x )
{ return w.o( w )( x ); })); })}; return r.o( r ); }

. If he already finds »if (p)« confusing, well ...

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-04-2013
http://www.velocityreviews.com/forums/(E-Mail Removed) (Scott Lurndal) writes:
>I've been programming in C++ for over a quarter of a century and
>I have _zero_ desire to understand code like that.


Admittedly, it also is hard to understand because it is only
a part of a program, not the complete program, so some
definitions are missing. But one can still get the idea of
a distinction between code that is inherently complex and
simple code that just requires a reader to know the language.

 
Reply With Quote
 
jz bnk
Guest
Posts: n/a
 
      03-04-2013
On Monday, March 4, 2013 9:26:44 AM UTC-7, Stefan Ram wrote:
> Admittedly, it also is hard to understand because it is only
>
> a part of a program, not the complete program, so some
>
> definitions are missing. But one can still get the idea of
>
> a distinction between code that is inherently complex and
>
> simple code that just requires a reader to know the language.


It seems like fix is being used to terminate a dynamic function chain you're
building (which is kind of neat by the way - why weren't you using something
like the following:

function <B(A)> fix (function <function <B(A)> (function <B(A)>)> f)
{
return [f](A x)
{
return f([](function <B(A)> y) {return y})(x);
};
}
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-04-2013
jz bnk <(E-Mail Removed)> writes:
>It seems like fix is being used to terminate a dynamic function chain you're
>building (which is kind of neat by the way - why weren't you using something
>like the following:


That code was stolen from

http://rosettacode.org/wiki/Y_combinator#C.2B.2B

by me, a page, which I found looking for an arbitrary
example of C++ code that is difficult to understand for an
average C++ programmer, which seems to include me.

 
Reply With Quote
 
jz bnk
Guest
Posts: n/a
 
      03-04-2013
On Monday, March 4, 2013 10:35:10 AM UTC-7, Stefan Ram wrote:
> That code was stolen from
>
>
>
> http://rosettacode.org/wiki/Y_combinator#C.2B.2B
>
>
>
> by me, a page, which I found looking for an arbitrary
>
> example of C++ code that is difficult to understand for an
>
> average C++ programmer, which seems to include me.


I misread the above function, so it seems that would include me as well. The
following works, and I think it's a little cleaner than the above:

template <typename A, typename B>
std::function <B(A)> fix (function <function<B(A)>> f)
{
return [=](A x) -> B
{
std::function <B(A)> top;
top = [&](A x) {
return f(top)(x);
};

return top(x);
}
}

although I'm not entirely convinced I'm not doing something awful above like
invoking undefined behaviour - I'll need to give it some more thought. Anyway,
thanks for the link - it was interesting
 
Reply With Quote
 
jz bnk
Guest
Posts: n/a
 
      03-04-2013
On Monday, March 4, 2013 11:52:24 AM UTC-7, jz bnk wrote:
> std::function <B(A)> fix (function <function<B(A)>> f)


Typo - that should be:
function <B(A)> fix (function <function<B(A)>(function <B(A)>)> f)
 
Reply With Quote
 
Martin Ba
Guest
Posts: n/a
 
      03-04-2013
On 01.03.2013 12:44, Öö Tiib wrote:
> On Friday, 1 March 2013 11:48:18 UTC+2, Martin T. wrote:
>> On 28.02.2013 18:37, James Kanze wrote:
>>> Those have been the rules in every coding guidelines
>>> I've seen in those 30 years.

>>
>> Care to give any references? (How many have you seen? By whom?)

>
> The question you are asking has been answered in C++ FAQ.
> You can find C++ FAQ from http://www.parashift.com/c++-faq/
>
> Please read at least it, NP that you haven't yet seen any
> C++ coding guidelines. Thanks.
>


Right. And now I'm going to search through the whole C++FAQ to find out
what exactly you refer to.

I have skimmed it several times but never read it top-to-bottom. Don't
remember reading an item wrt. the implicit bool conversion - do you have
the detailed link?

cheers,
Martin

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can a static function declaration conflict with a non-static declaration? nospam_timur@tabi.org C Programming 4 12-12-2006 10:26 PM
maxplusII error: a deferred constant declaration without a full declaration is not supported Noah VHDL 5 04-07-2006 02:34 PM
"virtual outside class declaration" and "declaration does not declare anything" kelvSYC C++ 6 05-17-2005 08:58 AM
Function declaration in class declaration Ovidesvideo C++ 4 12-10-2004 06:36 PM
Intel C++ 8.0 : declaration hides declaration Alex Vinokur C++ 4 04-05-2004 09:49 PM



Advertisments