220 134 <50A2BFD2.8040007@wanadoo.fr> article
Path: news.gmane.org!not-for-mail
From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Anonymous or unnamed variables
Date: Tue, 13 Nov 2012 22:46:58 +0100
Lines: 52
Approved: news@gmane.org
Message-ID: <50A2BFD2.8040007@wanadoo.fr>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Trace: ger.gmane.org 1352843230 22347 80.91.229.3 (13 Nov 2012 21:47:10 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 13 Nov 2012 21:47:10 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBDH67CONY4PBBW77RKCQKGQECCWSGUY@isocpp.org Tue Nov 13 22:47:21 2012
Return-path: <std-proposals+bncBDH67CONY4PBBW77RKCQKGQECCWSGUY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-wg0-f70.google.com ([74.125.82.70])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDH67CONY4PBBW77RKCQKGQECCWSGUY@isocpp.org>)
	id 1TYOKE-00055J-Nb
	for gclcip-std-proposals@m.gmane.org; Tue, 13 Nov 2012 22:47:18 +0100
Original-Received: by mail-wg0-f70.google.com with SMTP id ds1sf290703wgb.9
        for <gclcip-std-proposals@m.gmane.org>; Tue, 13 Nov 2012 13:47:08 -0800 (PST)
Original-Received: by 10.14.216.197 with SMTP id g45mr24616457eep.3.1352843228719;
        Tue, 13 Nov 2012 13:47:08 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.14.2.4 with SMTP id 4ls9628eee.8.gmail; Tue, 13 Nov 2012
 13:47:06 -0800 (PST)
Original-Received: by 10.14.182.5 with SMTP id n5mr79130986eem.5.1352843226559;
        Tue, 13 Nov 2012 13:47:06 -0800 (PST)
Original-Received: by 10.14.182.5 with SMTP id n5mr79130977eem.5.1352843226522;
        Tue, 13 Nov 2012 13:47:06 -0800 (PST)
Original-Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr. [80.12.242.123])
        by mx.google.com with ESMTP id f7si20418894eeo.130.2012.11.13.13.47.06;
        Tue, 13 Nov 2012 13:47:06 -0800 (PST)
Received-SPF: neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.123;
Original-Received: from iMac-de-Vicente-Botet-Escriba.local ([2.11.183.176])
	by mwinf5d53 with ME
	id P9mz1k00C3olrei039n1Bq; Tue, 13 Nov 2012 22:47:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
X-Original-Sender: vicente.botet@wanadoo.fr
X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com:
 80.12.242.123 is neither permitted nor denied by best guess record for domain
 of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post?hl=en>,
 <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?hl=en&topic=25838>,
 <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:134
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/134>

Hi,

Quite often we need to name a guard variable which is not used other 
than in the declaration to do some action on the destruction (raii), e.g.

{
   std::lock_guard<std::mutex> guard(mtx);
   // ...
}

Giving a name to these guard variables doesn't adds value to the 
expression, and some of us use to name them '_'

{
   std::lock_guard<std::mutex> _(mtx);
   // ...
}

Of course we can not include two of them on the same scope without using 
a more specific name as the name conflict.

{
   std::lock_guard<std::mutex> g1(mtx1);
   std::lock_guard<std::mutex> g2(mtx2);
   // ...
}

Do you think it could be worth adding some kind of anonymous variable 
that avoid having to name these kind of variables? E.g.we could use the 
token '...'

{
   std::lock_guard<std::mutex> ...(mtx1);
   std::lock_guard<std::mutex> ...(mtx2);
   // ...
}

One of the features of these unnamed variables could be that we can not 
do anything with, so maybe the compiler could take advantage in order to 
optimize the code.

I recognize that the added value is minor, but I'm sure that you have 
already desired to not name these variables.

Best,
Vicente

-- 




.