[timer] May I apply trivial fix?
Hi, As far as I know Beman is almost always busy, so may I apply trivial fix described in this ticket https://svn.boost.org/trac/boost/ticket/8956 ? This fix is essential for running regression tests with Intel compiler. -- Best regards, Antony Polukhin
On Friday 02 August 2013 12:52:56 Antony Polukhin wrote:
Hi,
As far as I know Beman is almost always busy, so may I apply trivial fix described in this ticket https://svn.boost.org/trac/boost/ticket/8956 ?
This fix is essential for running regression tests with Intel compiler.
I recently made a workaround in Boost.Test for this problem [1] but I simply dropped noncopyable and replaced it with deleted functions. I wonder if there's any need for noncopyable now besides backward compatibility. [1] https://svn.boost.org/trac/boost/changeset/85187
2013/8/2 Andrey Semashev <andrey.semashev@gmail.com>
On Friday 02 August 2013 12:52:56 Antony Polukhin wrote:
Hi,
As far as I know Beman is almost always busy, so may I apply trivial fix described in this ticket https://svn.boost.org/trac/boost/ticket/8956 ?
This fix is essential for running regression tests with Intel compiler.
I recently made a workaround in Boost.Test for this problem [1] but I simply dropped noncopyable and replaced it with deleted functions. I wonder if there's any need for noncopyable now besides backward compatibility.
Adding `boost::noncopyable` is much shorter than adding 2-3 lines of macros. Ugly macros are not in users code, so the resulting code is easier to read. Just some syntactic sugar for developers. -- Best regards, Antony Polukhin
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: Friday, August 02, 2013 10:26 AM To: boost@lists.boost.org Subject: Re: [boost] [timer] May I apply trivial fix?
On Friday 02 August 2013 12:52:56 Antony Polukhin wrote:
Hi,
As far as I know Beman is almost always busy, so may I apply trivial fix described in this ticket https://svn.boost.org/trac/boost/ticket/8956 ?
This fix is essential for running regression tests with Intel compiler.
I recently made a workaround in Boost.Test for this problem [1] but I simply dropped noncopyable and replaced it with deleted functions. I wonder if there's any need for noncopyable now besides backward compatibility.
Backward compatibility is important for this noncopyable. (And the BOOST_DEFAULTED_FUNCTION is ugly and its function is less obvious). I vote for this fix. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 02/08/2013 06:25 a.m., Andrey Semashev wrote:
On Friday 02 August 2013 12:52:56 Antony Polukhin wrote:
Hi,
As far as I know Beman is almost always busy, so may I apply trivial fix described in this ticket https://svn.boost.org/trac/boost/ticket/8956 ?
This fix is essential for running regression tests with Intel compiler.
I recently made a workaround in Boost.Test for this problem [1] but I simply dropped noncopyable and replaced it with deleted functions. I wonder if there's any need for noncopyable now besides backward compatibility.
Doesn't a defaulted function get the access level it would get if implicitly declared? In C++11 mode the singleton constructor and destructor would be public. At least gcc-4.8.1 thinks so: http://ideone.com/FSXqeX This are the relevant paragraphs in the standard to support that (emphasis mine): [dcl.fct.def.default]/4: Explicitly-defaulted functions and implicitly-declared functions are collectively called defaulted functions, and the implementation shall provide implicit definitions for them (12.1 12.4, 12.8), which might mean defining them as deleted. (...) [class.ctor]/4: A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no user-declared constructor for class X, a constructor having no parameters is implicitly declared as defaulted (8.4). An implicitly-declared default constructor is an inline **public** member of its class. (...) Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
AMDG On 08/02/2013 03:33 PM, Agustín K-ballo Bergé wrote:
<snip> Doesn't a defaulted function get the access level it would get if implicitly declared? In C++11 mode the singleton constructor and destructor would be public. At least gcc-4.8.1 thinks so: http://ideone.com/FSXqeX
<snip>
[dcl.fct.def.default]/4: Explicitly-defaulted functions and implicitly-declared functions are collectively called defaulted functions, and the implementation shall provide implicit definitions for them (12.1 12.4, 12.8), which might mean defining them as deleted. (...)
[class.ctor]/4: A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no user-declared constructor for class X, a constructor having no parameters is implicitly declared as defaulted (8.4). An implicitly-declared default constructor is an inline **public** member of its class. (...)
I don't see it. This paragraph says nothing about explicitly defaulted functions. It very clearly states that it applies to *implicitly-declared* default constructors In Christ, Steven Watanabe
On 03/08/2013 04:45 p.m., Steven Watanabe wrote:
AMDG
On 08/02/2013 03:33 PM, Agustín K-ballo Bergé wrote:
<snip> Doesn't a defaulted function get the access level it would get if implicitly declared? In C++11 mode the singleton constructor and destructor would be public. At least gcc-4.8.1 thinks so: http://ideone.com/FSXqeX
<snip>
[dcl.fct.def.default]/4: Explicitly-defaulted functions and implicitly-declared functions are collectively called defaulted functions, and the implementation shall provide implicit definitions for them (12.1 12.4, 12.8), which might mean defining them as deleted. (...)
[class.ctor]/4: A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no user-declared constructor for class X, a constructor having no parameters is implicitly declared as defaulted (8.4). An implicitly-declared default constructor is an inline **public** member of its class. (...)
I don't see it. This paragraph says nothing about explicitly defaulted functions. It very clearly states that it applies to *implicitly-declared* default constructors
I was just looking for something that may justify the way GCC reacts. I will be happy if this just happens to be a bug in GCC. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
participants (5)
-
Agustín K-ballo Bergé -
Andrey Semashev -
Antony Polukhin -
Paul A. Bristow -
Steven Watanabe