X-Received: by 10.182.36.35 with SMTP id n3mr2678633obj.19.1356107024140;
Fri, 21 Dec 2012 08:23:44 -0800 (PST)
X-BeenThere: std-***@isocpp.org
Received: by 10.182.113.67 with SMTP id iw3ls373992obb.15.gmail; Fri, 21 Dec
2012 08:23:43 -0800 (PST)
X-Received: by 10.60.29.226 with SMTP id n2mr11196844oeh.132.1356107023764;
Fri, 21 Dec 2012 08:23:43 -0800 (PST)
X-Received: by 10.60.29.226 with SMTP id n2mr11196842oeh.132.1356107023750;
Fri, 21 Dec 2012 08:23:43 -0800 (PST)
Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52])
by mx.google.com with ESMTPS id s5si12455528obo.196.2012.12.21.08.23.43
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 21 Dec 2012 08:23:43 -0800 (PST)
Received-SPF: pass (google.com: domain of ***@gmail.com designates 209.85.219.52 as permitted sender) client-ip=209.85.219.52;
Received: by mail-oa0-f52.google.com with SMTP id o6so4721304oag.25
for <std-***@isocpp.org>; Fri, 21 Dec 2012 08:23:43 -0800 (PST)
Received: by 10.60.171.175 with SMTP id av15mr11328127oec.75.1356107023617;
Fri, 21 Dec 2012 08:23:43 -0800 (PST)
Received: by 10.182.228.66 with HTTP; Fri, 21 Dec 2012 08:23:03 -0800 (PST)
In-Reply-To: <CAGdQazd6UVBYYZUyfYEvSUkpj=CoSn+cNQ=A=***@mail.gmail.com>
X-Original-Sender: ***@gmail.com
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain
of ***@gmail.com designates 209.85.219.52 as permitted sender)
smtp.mail=***@gmail.com; dkim=pass header.i=@gmail.com
Precedence: list
Mailing-list: list std-***@isocpp.org; contact std-proposals+***@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-***@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?hl=en&topic=25838>,
<mailto:std-proposals+***@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+***@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
<mailto:googlegroups-manage+399137483710+***@googlegroups.com>
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/1195>
On Mon, Dec 17, 2012 at 9:42 AM, Sebastian Gesemann
Post by Sebastian Gesemannclass UnwindDetector
{
UnwindDetector();
: atinit(std::current_exception())
{}
bool unwinding() const
{ return std::uncaught_exception()
&& (atinit != std::current_exception());
}
std::exception_ptr atinit;
};
struct Transaction
{
UnwindDetector uwd;
Transaction();
~Transaction()
{ if (uwd.unwinding())
RollBack();
else
Commit();
}
};
Interesting...
I like the original proposal of having two destructors because it is
quite clear what it is about.
And then I like the form taking the bool such that the regular dtor
would not even be implemented when the other is needed.
However, this solution would also get the job done AFAICT. And it also
provides a way to determine what exactly is happening, like Aleksandar
proposed, even if via RTTI as opposed to a direct dispatching resolved
by the compiler. So, it seems to me that this is a better solution.
Lastly, I've been wondering if there could be a use case when I am in
a normal scope exit destructor BUT within an unwinding destructor, and
I want to know that and use a strategy closer to the unwinding than
the normal exit. In that case, the separate dtros would get in the way
while this solution would give me all the information I want.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--