I have some code which requires me to use *this, but I want it to be noexcept friendly:
struct foo;
// Would actually be something with conditional noexcept
void do_something(foo&);
struct foo {
void fn()
noexcept(noexcept(::do_something(*this)))
{
::do_something(*this);
}
};
However, gcc rejects this:
<source>:7:43: error: invalid use of 'this' at top level
noexcept(noexcept(::do_something(*this)))
If I just access a member, gcc is fine:
void do_something(int);
struct bar {
int x;
void fn()
noexcept(noexcept(::do_something(x)))
{
::do_something(x);
}
};
However, if I access the member through the this pointer, gcc complains again:
struct baz {
int x;
void fn()
noexcept(noexcept(::do_something(this->x)))
{
::do_something(this->x);
}
};
Diagnostic:
<source>:7:42: error: invalid use of 'this' at top level
noexcept(noexcept(::do_something(this->x)))
Every other compiler I tried accepts using this inside the noexcept specification, but I don't actually know if it's gcc that has the bug or all the other compilers.
Can the keyword this be used inside a noexcept specification?
Yes, it is allowed. [expr.prim.this]p2 says:
If a declaration declares a member function or member function template of a class X, the expression this is a prvalue of type “pointer to cv-qualifier-seq X” between the optional cv-qualifier-seq and the end of the function-definition, [...].
The cv-qualifier-seq refers to the cv qualifiers of the member function, which appear before the noexcept specifier:
parameters-and-qualifiers:
( parameter-declaration-clause ) cv-qualifier-seq[opt] ref-qualifier[opt]
noexcept-specifier[opt] attribute-specifier-seq[opt]
So, this is a valid expression to use in the noexcept-specifier. This was a DR (cwg1207), which gcc doesn't implement. The bug report.
Related
I have some code which requires me to use *this, but I want it to be noexcept friendly:
struct foo;
// Would actually be something with conditional noexcept
void do_something(foo&);
struct foo {
void fn()
noexcept(noexcept(::do_something(*this)))
{
::do_something(*this);
}
};
However, gcc rejects this:
<source>:7:43: error: invalid use of 'this' at top level
noexcept(noexcept(::do_something(*this)))
If I just access a member, gcc is fine:
void do_something(int);
struct bar {
int x;
void fn()
noexcept(noexcept(::do_something(x)))
{
::do_something(x);
}
};
However, if I access the member through the this pointer, gcc complains again:
struct baz {
int x;
void fn()
noexcept(noexcept(::do_something(this->x)))
{
::do_something(this->x);
}
};
Diagnostic:
<source>:7:42: error: invalid use of 'this' at top level
noexcept(noexcept(::do_something(this->x)))
Every other compiler I tried accepts using this inside the noexcept specification, but I don't actually know if it's gcc that has the bug or all the other compilers.
Can the keyword this be used inside a noexcept specification?
Yes, it is allowed. [expr.prim.this]p2 says:
If a declaration declares a member function or member function template of a class X, the expression this is a prvalue of type “pointer to cv-qualifier-seq X” between the optional cv-qualifier-seq and the end of the function-definition, [...].
The cv-qualifier-seq refers to the cv qualifiers of the member function, which appear before the noexcept specifier:
parameters-and-qualifiers:
( parameter-declaration-clause ) cv-qualifier-seq[opt] ref-qualifier[opt]
noexcept-specifier[opt] attribute-specifier-seq[opt]
So, this is a valid expression to use in the noexcept-specifier. This was a DR (cwg1207), which gcc doesn't implement. The bug report.
The following doesn't compile in clang:
#include <iostream>
void f() { std::cout << "f()\n"; }
struct S {
typedef void(*p)();
operator p() { return f; }
};
int main()
{
S s;
s.operator p()();
}
Yields:
main.cpp:13:16: error: unknown type name 'p'; did you mean 'S::p'?
s.operator p()();
^
S::p
main.cpp:6:19: note: 'S::p' declared here
typedef void(*p)();
^
But it should, as the expression s.operator p()() accesses a public member function of the object S::s. Am I missing something?
If I'm wrong, I would appreciate a quote from the Standard supporting the answer.
This appears to be a bug in Clang. I believe the code is correct.
Clang 4.0.0 reports:
<source>:13:16: error: unknown type name 'p'; did you mean 'S::p'?
s.operator p()();
^
However, from C++14 3.4.5/7 [basic.lookup.classref]
If the id-expression is a conversion-function-id, its conversion-type-id is first looked up in the class of the
object expression and the name, if found, is used. Otherwise it is looked up in the context of the entire
postfix-expression. In each of these lookups, only names that denote types or templates whose specializations
are types are considered.
[ Example:
struct A { };
namespace N {
struct A {
void g() { }
template <class T> operator T();
};
}
int main() {
N::A a;
a.operator A();
// calls N::A::operator N::A
}
— end example ]
In your example, the type p should have been found in the class without requiring qualification.
struct test
{
void f() {};
};
test t1;
using memfun_t = void (test::*)();
memfun_t mf = &test::f;
auto a1 = &test::f; // OK
auto a2 = t1.*mf; // error
auto a3 = &(t1.*mf); // still no luck
Any ideas why this can't be deduced? I would appreciate answers referencing the Standard.
Edit :
I have found a RAD Studio language extension called __closure that appears to be addressing this issue.1 Here is the code :
class base {
public:
void func(int x) {
};
};
typedef void(base::*pBaseMember)(int);
class derived : public base {
public:
void new_func(int i) {
};
};
int main(int argc, char * argv[]) {
derived derivedObject;
void(__closure * derivedClosure)(int);
// Get a pointer to the ‘new_func’ member.
// Note the closure is associated with the
// particular object, ‘derivedObject’.
derivedClosure = derivedObject.new_func;
derivedClosure(3); // Call ‘new_func’ through the closure.
return 0;
}
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Closure
You can't use
auto a2 = t1.*mf; // error
just like you can't use:
auto a2 = t1.f;
t1.f is not a valid expression. A pointer to a member function cannot be obtained through an instance of the class. Unlike non-member functions, which decay to a function pointer when used like that, member functions don't decay to a member function pointer.
Relevant text from the C++11 Standard:
Unary Operators
...
4 A pointer to member is only formed when an explicit & is used and its operand is a qualified-id not enclosed in parentheses. [ Note: that is, the expression &(qualified-id), where the qualified-id is enclosed in parentheses, does not form an expression of type “pointer to member.” Neither does qualified-id, because there is no implicit conversion from a qualified-id for a non-static member function to the type “pointer to member function” as there is from an lvalue of function type to the type “pointer to function” (4.3). Nor is
&unqualified-id a pointer to member, even within the scope of the unqualified-id’s class. —end note ]
I'm just curious to know why this small piece of code compiles correctly (and without warnings) in Visual Studio. Maybe the result is the same with GCC and Clang, but unfortunately I can't test them now.
struct T {
int t;
T() : t(0) {}
};
int main() {
T(i_do_not_exist);
return 0;
}
T(i_do_not_exist); is an object declaration with the same meaning as T i_do_not_exist;.
N4567 § 6.8[stmt.ambig]p1
There is an ambiguity in the grammar involving expression-statements and declarations: An expression-statement with a function-style explicit type conversion (5.2.3) as its leftmost subexpression can be indistinguishable from a declaration where the first declarator starts with a (. In those cases the statement is a declaration.
§ 8.3[dcl.meaning]p6
In a declaration T D where D has the form
( D1 )
the type of the contained declarator-id is the same as that of the contained declarator-id in the declaration
T D1
Parentheses do not alter the type of the embedded declarator-id, but they can alter the binding of complex declarators.
Because it defines a variable of type T:
http://coliru.stacked-crooked.com/a/d420870b1a6490d7
#include <iostream>
struct T {
int t;
T() : t(0) {}
};
int main() {
T(i_do_not_exist);
i_do_not_exist.t = 120;
std::cout << i_do_not_exist.t;
return 0;
}
The above example looks silly, but this syntax is allowed for a reason.
A better example is:
int func1();
namespace A
{
void func1(int);
struct X {
friend int (::func1)();
};
}
Probably other examples could be found.
Is it possible to declare a function pointer including the throw specification? For example, I have this function:
void without_throw() throw() {
}
And would like to to create a function that accepts it as a parameter, complete with the throw() part. I've tried adding it to the typedef, but that doesn't seem to work:
typedef void (*without)() throw();
GCC gives me the error error: ‘without’ declared with an exception specification.
You can't typedef that. It's explicitly not allowed in the standard. (And replacing that with noexcept doesn't help, same problem.)
Quoting C++11 draft n3290 (§15.4/2 Exception specifications)
An exception-specification shall appear only on a function declarator for a function type, pointer to function type, reference to function type, or pointer to member function type that is the top-level type of a declaration or definition, or on such a type appearing as a parameter or return type in a function declarator. An exception-specification shall not appear in a typedef declaration or alias-declaration. [ Example:
void f() throw(int); // OK
void (*fp)() throw (int); // OK
void g(void pfa() throw(int)); // OK
typedef int (*pf)() throw(int); // ill-formed
– end example]
The second example allows you to do something like this:
void foo() throw() {}
void bar() {}
int main()
{
void (*fa)() throw() = foo;
void (*fb)() throw() = bar; // error, does not compile
}
Also you can use std::function if c++0x is acceptable:
#include <functional>
void without_throw() throw() {}
typedef std::function<void() throw()> without;
int main()
{
without w = &without_throw;
w();
}