void()const

[Marc]

Hello,

working with member functions, we can end up with types like
"void()const". In g++, this type does not match a template pattern
"const T" (nor "R(A...)") but typeid reports it the same as "void()".
This doesn't seem very consistant to me, but I may be missing
something.

 

[SG]

working with member functions, we can end up with types like
"void()const".

There is no such type. The "const" can only be part of a member
function pointer type. There is no T so that "T SomeClass::*" becomes
something like "void (SomeClass::*)() const".

In g++, this type does not match a template pattern
"const T" (nor "R(A...)") but typeid reports it the same as "void()".
This doesn't seem very consistant to me, but I may be missing
something.

Please show some code.

There are some things about member function pointers that I would
consider as irregular or unfortunate. But there are ways to get around
that. The C++98 standard already started to provide tools for that
(std::mem_fun, std::mem_fun_ref, ...). There's also boost::bind and
boost::mem_fn. The upcoming C++ standard picks up on that and improves
these things. Basically, it's much more convenient to deal with
function objects rather than limit oneself to member function
pointers.

SG

 

[Johannes Schaub]

There is no such type. The "const" can only be part of a member
function pointer type. There is no T so that "T SomeClass::*" becomes
something like "void (SomeClass::*)() const".

No, there *is* such a type. If you say "void (C::*)()const", you have a
member pointer, and the member type pointed to is "void() const".

It's just the case that constructing the type-id "void() const" is only
valid in certain circumstances. For example, only as the toplevel type in a
typedef declaration, as the toplevel type of a member function declaration
or (in C++0x) as a default or explicit argument to a template type
parameter.

 

[Johannes Schaub]

Hello,

working with member functions, we can end up with types like
"void()const". In g++, this type does not match a template pattern
"const T" (nor "R(A...)") but typeid reports it the same as "void()".
This doesn't seem very consistant to me, but I may be missing
something.

That typeid thing looks like a bug to me, but remember the lexical
presentation of what typeid(...).name() returns is unspecified.

"void() const" does not match the pattern "const T", because the type
"void() const" is not a cv-qualified type. In fact, if "U" is "void()", then
specifying the type "const U" yields to an ill-formed program in C++03, and
yields the type "U" in C++0x.

The spec has a note on this, FDIS 8.3.5p6: "[ Note: a function type that has
a cv-qualifier-seq is not a cv-qualified type; there are no cv-qualified
function types. — end note ] ".

Note that the fact that you can say "const U" does not imply that there are
cv-qualified function types. The fact does only imply that you can specify
such types. But the translation to semantics yield a cv-unqualified function
type.

 

[SG]

On 18 Apr., 08:38, Marc wrote:

There is no such type. The "const" can only be part of a member
function pointer type. There is no T so that "T SomeClass::*" becomes
something like "void (SomeClass::*)() const".

No, there *is* such a type. [...]

It's just the case that constructing the type-id "void() const" is only
valid in certain circumstances. [...]

I stand corrected. I didn't know that a typedef à la

typedef void blah() const;

is actually valid.

SG

 

[Marc]

That typeid thing looks like a bug to me, but remember the lexical
presentation of what typeid(...).name() returns is unspecified.

I compared with typeid(A)==typeid(B) for that reason. I'll report this
to gcc.

"void() const" does not match the pattern "const T", because the type
"void() const" is not a cv-qualified type.

That was also my understanding, but gcc's typeid behavior and the
demangler (from binutils) showing void( const)() both made it look
like gcc was considering it as a const function.

Thank you for the confirmation.

 

[Paul N]

Hello,

working with member functions, we can end up with types like
"void()const". In g++, this type does not match a template pattern
"const T" (nor "R(A...)") but typeid reports it the same as "void()".
This doesn't seem very consistant to me, but I may be missing
something.

I know nothing about templates, so can't answer your question, but I'm
puzzled as to what you are using a void() const function to do. As I
see it, it doesn't return a value, neither can it alter the object.
The most plausible use would be to set a global variable based on the
value of the object. So what are you doing?

(Possibly, explaining this will help others - or perhaps even you
yourself - answer your actual question.)

 

[Marc]

I know nothing about templates, so can't answer your question, but I'm
puzzled as to what you are using a void() const function to do. As I
see it, it doesn't return a value, neither can it alter the object.
The most plausible use would be to set a global variable based on the
value of the object. So what are you doing?

This was just the simplest example of a function. The same applies to
"int(double,void*&)volatile" for instance.

 

[SG]

Paul N  wrote:


This was just the simplest example of a function. The same applies to
"int(double,void*&)volatile" for instance.

Care to provide some code here? Otherwise I don't see the need to
discuss anything further. Have you thought about what I said w.r.t.
function objects?

SG

 

[Marc]

Care to provide some code here?

I noticed that the pretty printer (takes a type and creates a string)
I wrote some time ago:
http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/printtype.cpp
doesn't work on const member functions. I experimented a bit to see if
it was really necessary to make 4 copies (const, volatile) of the code
dealing with functions (apparently it is) and noticed some
inconsistant behavior which I reported here and then on the gcc
bugzilla.

Otherwise I don't see the need to discuss anything further.

Well, the question has already been answered...

Have you thought about what I said w.r.t. function objects?

I completely agree that function objects are nicer than functions and
that utilities like mem_fun are useful. I was more interested here in
how these utilities are implemented, and indeed some of them have a
large number of specializations to handle all of these function types.