«

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.

On 18 Apr., 08:38, Marc wrote:
>
> 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

SG wrote:

> On 18 Apr., 08:38, Marc wrote:
>>
>> 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".
>

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.

Marc wrote:

> 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.

On 18 Apr., 10:35, Johannes Schaub wrote:
> SG wrote:
> > On 18 Apr., 08:38, Marc wrote:
>
> >> 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".
>
> 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

Johannes Schaub wrote:

> Marc wrote:
>> 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.

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.

On Apr 18, 7:38*am, Marc <marc.gli...@gmail.com> wrote:
> 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.)

Paul N wrote:

> On Apr 18, 7:38*am, Marc <marc.gli...@gmail.com> wrote:
>> 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?

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

On 18 Apr., 21:54, Marc <marc.gli...@gmail.com> wrote:
> Paul N *wrote:
> > On Apr 18, 7:38 am, Marc <marc.gli...@gmail.com> wrote:
> >> 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?
>
> 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

SG wrote:

> 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/te.../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.