is a typedef necessary?

[Armen Tsirunyan]

Hello all,
I have recently experimented (just for experiment's sake) with
declaring variables and functions of arbitrarily complicated types
without using typedefs, and finally learned to do it. By saying
arbitrarily complicated, I DO mean arbitrarily complicated . This
led me to believe that any piece of code(let's precautiously add
"which doesn't involve templates") can be rewritten without using
typedefs. But...
struct IncrementFunctorClassWithNoOperatorParentheses
{
static int f(int n) { return n+1; }
typedef int(*pf) (int);
operator pf () { return &f; }
};

One might expect that this conversion function can also be declared
without a typedef -
operator int (*) (int) () { ... }
but, alas, this compiles on neither MSVC9.0 nor online comeau. Nor do
any variations of the syntax I was able to invent.
So, I have two question. First, is it possible to declare a
conversion
function to a pointer-to-function without using a typedef, if yes,
how?
And, second (valid if the answer to the first is positive), is there
anything that cannot be declared without a typedef?
Thank you in advance,
Armen Tsirunyan, Software Developer at CQG, Yerevan.
--
comp.lang.c.moderated - moderation address: (e-mail address removed) -- you
must
have an appropriate newsgroups line in your header for your mail to be
seen,
or the newsgroup name in square brackets in the subject line. Sorry.

 

[Marc]

Hello all,
I have recently experimented (just for experiment's sake) with
declaring variables and functions of arbitrarily complicated types
without using typedefs, and finally learned to do it. By saying
arbitrarily complicated, I DO mean arbitrarily complicated .  This
led me to believe that any piece of code(let's precautiously add
"which doesn't involve templates") can be rewritten without using
typedefs. But...

If you take into account linkage (extern "C" vs extern "C++"), some
things can't be written without a typedef.

struct IncrementFunctorClassWithNoOperatorParentheses
{
   static int f(int n)  { return n+1; }
   typedef int(*pf) (int);
   operator pf () { return &f; }

};

(*operator int ())(int) { return &f; }
works with g++ and Intel,
produces "error: must use a typedef to declare a conversion to 'int (*)
(int)'" with clang.

 

[Armen Tsirunyan]

Thank you very much, Marc

If you take into account linkage (extern "C" vs extern "C++"), some
things can't be written without a typedef.

for example what?

   (*operator int ())(int) { return &f; }

This still doesn't work on MSVC9.0
error C2091: function returns function
error C2586: incorrect user-defined conversion syntax : illegal
indirections

works with g++ and Intel,
produces "error: must use a typedef to declare a conversion to 'int (*)
(int)'" with clang.

Who is right? I mean, does the standard indirectly imply whether or
not (*operator int ())(int) { return &f; } is supposed to work?

 

[Marc]

Thank you very much, Marc


for example what?

A function that takes as first argument a C function and as second
argument a C++ function, for instance. (note that few compilers
implement this properly)

This still doesn't work on MSVC9.0
error C2091: function returns function
error C2586: incorrect user-defined conversion syntax : illegal
indirections


Who is right? I mean, does the standard indirectly imply whether or
not (*operator int ())(int) { return &f; }  is supposed to work?

The way I understand it, if there was a valid syntax, that would be
it, but the standard says that a conversion-function-id starts with
the keyword operator, so it can't be legal. Also, it is a gcc
extension.

 

[Armen Tsirunyan]

The way I understand it, if there was a valid syntax, that would be

it, but the standard says that a conversion-function-id starts with
the keyword operator, so it can't be legal. Also, it is a gcc
extension.

So, I guess a typedef is necessary. That's... sad )

Thank you very much indeed, marc, I really appreciate your help
Best regards.

 

[Goran Pusic]

So, I guess a typedef is necessary. That's... sad )

Why? Why would I want repetitive gibberish when I can give a name to
the type said gibberish represents?

When used well, typedef is a good abstraction building tool and it
helps applying DRY principle, too (http://en.wikipedia.org/wiki/Don
%27t_repeat_yourself).

Goran.

 

[ThosRTanner]

So, I guess a typedef is necessary. That's... sad )

Why on earth is it sad? I typedef pretty much every complex type (and
I'm not above typedef'ing an int if it has significant semantics).
It's a HELL of a lot easier to read and understand. Especially where
function pointers or arrays are involved which are almost totally
incomprehensible when consumed raw.

 

[Armen Tsirunyan]

Why on earth is it sad? I typedef pretty much every complex type (and
I'm not above typedef'ing an int if it has significant semantics).
It's a HELL of a lot easier to read and understand. Especially where
function pointers or arrays are involved which are almost totally
incomprehensible when consumed raw.

OK, I need to make myself clear. I agree with every single thing you
said, and
believe me I do the same. But it's still sad that the " raw syntax "
of C++, i.e.
without typedefs is not expressive enough. That's all

 

[Juha Nieminen]

This
led me to believe that any piece of code(let's precautiously add
"which doesn't involve templates") can be rewritten without using
typedefs.

There was an example in another thread recently of a situation where
typedef seems to be mandatory. It's a completely artificial example,
of course, but I don't think it's possible to do without the typedef:

typedef int Integer;
(0).~Integer();

 

[Armen Tsirunyan]

  There was an example in another thread recently of a situation where
typedef seems to be mandatory. It's a completely artificial example,
of course, but I don't think it's possible to do without the typedef:

    typedef int Integer;
    (0).~Integer();

If I understand correctly (and there's a fa chance I don't ) the
pseudodestructor or whatever it's called is 'invented' so that generic
code wouldn't bother that built-in types don't have destructors. If
that statement was correct, then the typedef is not really NECESSARY,
because the construct you wrote is somewhat equivalent to an empty
statement.

 

[Juha Nieminen]

If I understand correctly (and there's a fa chance I don't ) the
pseudodestructor or whatever it's called is 'invented' so that generic
code wouldn't bother that built-in types don't have destructors. If
that statement was correct, then the typedef is not really NECESSARY,
because the construct you wrote is somewhat equivalent to an empty
statement.

It could theoretically become relevant if, for some reason, you used
a preprocessor macro instead of an actual template to do something which
requires explicitly calling the destructor of an object (and the type of
the object is given as one of the macro parameters).

Of course nobody would write code like that, but it's still theoretically
possible.