Monday, September 7, 2015

Digest for comp.lang.c++@googlegroups.com - 10 updates in 5 topics

Paavo Helde <myfirstname@osa.pri.ee>: Sep 07 04:18PM -0500

ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:quiz-20150907203920
> /* here some values might be put into the map */
 
> for( const ::std::pair< ::std::string, int > & pair : map )
> /* assume a statement here that might use the pair */
 
The correct way is to use auto and let it figure out the needed type:
 
for( const auto& pair : map )

According to the docs the type would be std::pair<const std::string,int>,
but why should I waste my time on it and hope to get it right every time?
This example is just an example of fragile code.
 
Cheers
Paavo
Luca Risolia <luca.risolia@linux-projects.org>: Sep 07 11:54PM +0200

Il 07/09/2015 21:51, Stefan Ram ha scritto:
> change in the source code:
 
> for( const ::std::pair< ::std::string, int > & pair : map )
> /* assume a statement here that might use the pair */
 
I know from what book your quizzes come from...;)
ram@zedat.fu-berlin.de (Stefan Ram): Sep 07 06:50PM

>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.
 
After more than a week has passed, I now would like to post
a solution to the quiz.
 
A correct solution was sent to me via E-mail, but I think
that it is permissible to post solutions directly to this
newsgroup.
 
A correct solution posted into this newsgroup was posted
by Luca Risolia in <mrpn9p$9pm$1@speranza.aioe.org>
(date: Fri, 28 Aug 2015 15:21:30).
 
Jorgen Grahn suggested in
<slrnmugv5c.eij.grahn+nntp@frailea.sa.invalid>
to change »return(v)« into »return v«.
 
Jorgen was seemingly not aware of the fact that this
change changes the behavior of the code, possibly he
had not yet read Luca's post when he wrote his post.
 
In
 
#include <iostream>
#include <ostream>
decltype(auto)f(){int v=2;return(v);}
int main(){::std::cout<<f()<<'\n';}
 
, »decltype(auto)« denotes a type derived from the
return expression.
 
When that expression is a variable name, the type
is the type of that variable name.
 
Using »decltype(auto)« will retain the reference-ness and
the const-ness of the type, while just using »auto« will
strip it.
 
However, the expression »(v)« is not a variable name.
 
.----------------------------------------------------.
| When the return expression is not a variable name, |
| »decltype« always adds reference-ness to the type. |
'----------------------------------------------------'
 
Therefore, in the code given above, the return type of »f«
is deduced to be »int &«, which means that the program has
undefined behaviour.
 
If »return(v)« is changed into »return v« as suggested
by Jorgen, the return type deduced will be »int« instead,
and the behavior of the program should then be defined.
 
So Jorgen indeed has improved the program, albeit possibly
not being aware of why.
 
Luca was right when he explained that this is also valid
when applying »decltype« directly to an expression according
to:
 
#include <iostream>
#include <ostream>
#include <type_traits>
 
 
int main()
{
int v;
auto println = []( auto x ){ ::std::cout << x << '\n'; };
 
println( std::is_reference< decltype( v )>::value );
println( std::is_reference< decltype( ( v ))>::value ); }
 
, which prints
 
0
1
 
.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 07 07:51PM

The following code is legal, but it still has an unnecessary
run-time inefficiency in it, that can be cured by a (small)
change in the source code:
 
/* assume necessary #includes */
 
::std::unordered_map< ::std::string, int >map;
/* here some values might be put into the map */
 
for( const ::std::pair< ::std::string, int > & pair : map )
/* assume a statement here that might use the pair */
 
.
woodbrian77@gmail.com: Sep 07 12:00PM -0700

I've taken the following from this page:
https://isocpp.org/blog/2015/09/cpp-user-group-meetings-in-september
 
 
C++ User Group Meetings in September
 
by Jens Weller
 
The list of Meetings:
 
9.9 C++ UG Utah - Regular Monthly Meeting
9.9 C++ UG San Francisco/ Bay area - Presentation and Q&A
9.9 C++ UG Washington, DC - Q & A / Info Sharing 10.9 C++ UG Dresden - Scripting in C++
14.9 C++ UG Denver - Denver Tech Center C++ Developers
14.9 C++ UG Bristol - Tim Perry
14.9 C++ UG Zentralschweiz - Coding Dojo
16.9 C++ UG Düsseldorf - Treffen der C++ User Gruppe NRW
16.9 C++ UG North West/Seattle - The BBC micro: bit and C++
17.9 C++ UG Chicago - "Cross-compiling to C++" and "Can you make me more productive
21.9 C++ UG Austin - North Austin Monthly C/C++ Pub Social
23.9 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
23.9 C++ UG Washington, DC - Q & A / Info Sharing
24.9 C++ UG Rhein-Neckar - C++ Usergroup Meeting
24.9 C++ UG Bremen - C++ - Vorstellung eines Frameworks für den Integrationtest
24.9 C++ UG Arhus - Libreoffice Hackfest
30.9 C++ UG San Francisco/ Bay area - CppCon Trip Report
 
----------------------------------------------------------
 
I noticed that the third line above contains 2 meetings.
I also think it's more readable to factor out the "C++ UG" from
each entry. Here's the new version:
 
 
C++ User Group Meetings in September
 
by Jens Weller
 
The list of Meetings:
 
9.9 Utah-Regular Monthly Meeting
9.9 San Francisco-Presentation and Q&A
9.9 Washington,DC-Q&A/Info Sharing
10.9 Dresden-Scripting in C++
14.9 Denver-Denver Tech Center C++ Developers
14.9 Bristol-Tim Perry
14.9 Zentralschweiz-Coding Dojo
16.9 Düsseldorf-Treffen der C++ User Gruppe NRW
16.9 Seattle-The BBC micro: bit and C++
17.9 Chicago-"Cross-compiling to C++" and "Can you make me more productive
21.9 Austin-Monthly C/C++ Pub Social
23.9 San Francisco-Workshop and Discussion Group
23.9 Washington,DC-Q&A/Info Sharing
24.9 Rhein-Neckar-C++ Usergroup Meeting
24.9 Bremen-C++ - Vorstellung eines Frameworks für den Integrationtest
24.9 Arhus-Libreoffice Hackfest
30.9 San Francisco-CppCon Trip Report
 
-------------------------------------------------------------
 
If others are interested in a C++ meeting in the St. Paul,
Minnesota area, please let me know. By the grace of G-d,
I'm able to provide a meeting area in a conference room in
the office building where Ebenezer Enterprises is, and I
would be happy to give a talk or two.
 
 
Brian
Ebenezer Enterprises - "And we know that G-d causes all
things to work together for good to those who love G-d,
to those who are called according to His purpose." Romans 8:28
 
http://webEbenezer.net
Gareth Owen <gwowen@gmail.com>: Sep 07 07:13AM +0100

> utterances. Had he read a bit about the minimalist position on the
> authenticity of the texts, he would have been able to engage with
> David in an interesting way, but he obviously hasn't.
 
Yup.
Gareth Owen <gwowen@gmail.com>: Sep 07 07:39AM +0100

> two, the evangelical literalist, both appear to have no interest in
> the relevant historical scholarship. More time with the books, mate!
> and less time at the pub.
 
*applause*
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 07 05:21PM +0100

On 07/09/2015 07:13, Gareth Owen wrote:
>> authenticity of the texts, he would have been able to engage with
>> David in an interesting way, but he obviously hasn't.
 
> Yup.
 
Nope.
woodbrian77@gmail.com: Sep 06 09:50PM -0700

On Sunday, September 6, 2015 at 5:38:35 PM UTC-5, Chris Vine wrote:
 
> 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.
 
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 <chris@cvine--nospam--.freeserve.co.uk>: Sep 07 12:44PM +0100

On Sun, 6 Sep 2015 21:50:51 -0700 (PDT)
> comments. I understand that it's difficult for some
> to admit that I've been blessed by G-d with increasingly
> robust software ...
 
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.
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)