Re: A small quiz

[Victor Bazarov]

On 8/26/2015 11:28 PM, Stefan Ram wrote:
> What's wrong with the following code? The error is in the
> definition of f, and it's not about style but just about
> straight errors.
>
> #include <iostream>
> #include <ostream>
> decltype(auto)f(){int v=2;return(v);}
> int main(){::std::cout<<f()<<'\n';}
>
> One bonus point, if one can answer it without using a compiler.

Without much experience in C++11 yet, or C++14 for that matter, it does
seem strange to me to see 'auto' as the argument to 'decltype' operator.

V
--
I do not respond to top-posted replies, please don't ask

[Wouter van Ooijen]

Op 27-Aug-15 om 5:28 AM schreef Stefan Ram:

> What's wrong with the following code? The error is in the
> definition of f, and it's not about style but just about
> straight errors.
>
> #include <iostream>
> #include <ostream>
> decltype(auto)f(){int v=2;return(v);}
> int main(){::std::cout<<f()<<'\n';}
>
> One bonus point, if one can answer it without using a compiler.

Does using google disqualify me?

decltype(auto) forces decltype to use the same type-determining rules as
auto. The important distinction between the plain decltype rules and the
auto rules is that the latter can determine a type to be a reference,
which is what happens here. Hence the code is effectively

int & f(){ int v=2; return v; }

What I am not sure of is whether v instead of (v) would still give the
same effect?

Wouter

[Luca Risolia]

On 27/08/2015 05:28, Stefan Ram wrote:
> What's wrong with the following code? The error is in the
> definition of f, and it's not about style but just about
> straight errors.

> decltype(auto)f(){int v=2;return(v);}

decltype(v) != decltype ((v))

the former is int (as "v" is a name), while the latter is int& (as "(v)"
is an expression where v is an lvalue)

[mark]

Another obscure language feature - defined in C++14 7.1.6.2/4.3.

Thankfully, gcc, clang and Visual C++ all issue warnings about returning
a reference to a local variable.

[Jorgen Grahn]

On Thu, 2015-08-27, Stefan Ram wrote:
> What's wrong with the following code? The error is in the
> definition of f, and it's not about style but just about
> straight errors.

If it's not about style, why not use a more normal and readable
style?

> #include <iostream>
> #include <ostream>
> decltype(auto)f(){int v=2;return(v);}
> int main(){::std::cout<<f()<<'\n';}

decltype(auto) f()
{
int v=2;
return v;
}

int main()
{
std::cout << f() << '\n';
}

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnmugv5c.e...@frailea.sa.invalid> thusly:

>If it's not about style, why not use a more normal and readable
>style?

Becausewhitespacehindersreadabilitywhenitcomestocomputerprograms.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[bartekltg]

On 03.09.2015 19:00, Jorgen Grahn wrote:
> On Thu, 2015-08-27, Stefan Ram wrote:
>> What's wrong with the following code? The error is in the
>> definition of f, and it's not about style but just about
>> straight errors.
>
> If it's not about style, why not use a more normal and readable
> style?

Training?

http://www0.us.ioccc.org/1998/banks.c

bartekltg

[woodb...@gmail.com]

On Thursday, September 3, 2015 at 12:04:34 PM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnmugv5c.e...@frailea.sa.invalid> thusly:
>
> >If it's not about style, why not use a more normal and readable
> >style?
>
> Becausewhitespacehindersreadabilitywhenitcomestocomputerprograms.

Yeah, the form that Jorgen wrote might be easier for
people who are less experienced to read, but I think
there's something to be said for the original form.
I was influenced toward more compact forms by the
author of the Boost Multi_index library.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[woodb...@gmail.com]

On Thursday, September 3, 2015 at 1:43:16 PM UTC-5, woodb...@gmail.com wrote:
> On Thursday, September 3, 2015 at 12:04:34 PM UTC-5, Richard wrote:
> > [Please do not mail me a copy of your followup]
> >
> > Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> > <slrnmugv5c.e...@frailea.sa.invalid> thusly:
> >
> > >If it's not about style, why not use a more normal and readable
> > >style?
> >
> > Becausewhitespacehindersreadabilitywhenitcomestocomputerprograms.
>
> Yeah, the form that Jorgen wrote might be easier for
> people who are less experienced to read, but I think
> there's something to be said for the original form.
> I was influenced toward more compact forms by the
> author of the Boost Multi_index library.
>

I've been doing more of this lately and ran into
a problem when I tried removing the space between
the '*' and the '=' in the following

bool Flush (::sockaddr* =nullptr,::socklen_t=0);

The compiler "thought" the *= was a multiply
and assign and that didn't make sense in the context.
I recall having a similar problem when using a ?:
statement and had 3 ':' in a row. I had to leave a
space between the first and second ':' to help the
compiler out.

Brian
Ebenezer Enterprises - "The wicked spies upon the
righteous and seeks to kill him." Psalms 37:32

http://breitbart.com

[Chris Vine]

On Sun, 6 Sep 2015 11:04:56 -0700 (PDT)
woodb...@gmail.com wrote:
> The compiler "thought" the *= was a multiply
> and assign and that didn't make sense in the context.
> I recall having a similar problem when using a ?:
> statement and had 3 ':' in a row. I had to leave a
> space between the first and second ':' to help the
> compiler out.

No, not to help the compiler out, but to write valid C++ code. C++
tokens are greedy (aka the "max munch" rule).

Quite why you should want to obfuscate your code I don't know, but if
you are going to do so then you need to learn the rules, and not try
blaming the compiler.

[woodb...@gmail.com]

I think you are capable of more helpful and thoughtful
comments. I understand that it's difficult for some
to admit that I've been blessed by G-d with increasingly
robust software ...

Brian
Ebenezer Enterprises
http://webEbenezer.net

[Chris Vine]

I doubt that. You cannot write robust software (i) without knowing the
rules of the language, and (ii) with obfuscated code.

If you think whitespace is irrelevant to C++ syntax you are misguided.
'& &' is not the same as '&&'. The first is two operators and the
second is one.

Proper layout of code using whitespace is essential for producing
robust and maintainable code. If you think otherwise you are deluded.