On 2005-04-19 19:58:06 -0700, jfa1@cec.wustl.edu ("James Aguilar") said:

> Currently, when writing a member function in a class definition,
> typedefs that the programmer makes in the class allow member typedefs
> to be used as a return type, thus:
>
> class Example
> {
> public:
>   typedef bool result_type;
>   typedef int input_type;
>
>   result_type operator ()(input_type in1, input_type in2)
>   {
>     return in1 < in2;
>   }
> };
>
> However, when defining a member function outside of the class in which
> it is declared, it looks more like this:
>
> Example::result_type Example::operator ()(input_type in1, input_type in2)
> {
>   return in1 < in2;
> }
>
> and
>
> result_type Example::operator ()(input_type in1, input_type in2)
> {
>   return in1 < in2;
> }
>
> is illegal.  This should not be.  If the parameter types can be assumed
> to be members of the containing class, so should return types.

The "class namespaces" proposal would solve this problem and more, in a
simpler way.  Here's how it would work:

namespace class Example
{
  result_type operator ()(input_type in1, input_type in2)
  {
    return in1 < in2;
  }
}

See http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2003/n1420.pdf

--
Derek Ledbetter
derekl@serve.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Currently, when writing a member function in a class definition, typedefs that
the programmer makes in the class allow member typedefs to be used as a return
type, thus:

class Example
{
public:
  typedef bool result_type;
  typedef int input_type;

  result_type operator ()(input_type in1, input_type in2)
  {
    return in1 < in2;
  }
};

However, when defining a member function outside of the class in which it is
declared, it looks more like this:

Example::result_type Example::operator ()(input_type in1, input_type in2)
{
  return in1 < in2;
}

and

result_type Example::operator ()(input_type in1, input_type in2)
{
  return in1 < in2;
}

is illegal.  This should not be.  If the parameter types can be assumed to be
members of the containing class, so should return types.  This has two benefits:
first, it makes typedefs more useful -- when the typedefs must be qualified with
their class's name, it makes them less of a time-saver because of the extra
characters that must be typed, especially with the longer class names that
descriptive naming sometimes requires.  Also, acceptance of this proposal would
bring uniformity between return type usage of member typedefs and parameter
usage of member typedefs.

So: allow member typedefs to be used implicitly in both return types and
parameter types.

- JFA1


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Max T. Woodbury"" <max.teneyck.woodbury@verizon.net> wrote in message
news:8lv9e.22540$ox3.11441@trnddc03...
>
> This causes technical parsing problems.  The return type of the function has
> to be known to be a type to parse it properly.  In order to identify it as a
> type in this context you need to know which class the member function belongs
> to, but that information is not available until the 'Example::' is seen.  So
> what you want to do is not possible given that parsing is a sequential
> process.

This is not the case.  Any LALR(1) parser should be able to put the return type
lower on the Abstract Syntax Tree than the function node.  For instance, the
syntax for the rule in CUP would be something like this:

FunctionHeader ::= Typename:t Identifier:i OPAREN FParamList:fpl CPAREN
    {:
        RESULT = FunctionNode(i);
        RESULT.addChild(t);
        RESULT.addChild(fpl);
    :}

I do not know what it would look like in YACC or whatever the C++ compiler
compiler is, but, to my knowledge, all of the set of compiler compilers use
LALR(1) style parsers.

And other such out of order syntax is easily permitted.  The return type could
definitely be resolved to class scope without changing the accepted language
very much, and certainly the current set of accepted programs could still be
accepted with this modification.  Now, I can see another reason, and that's that
the parameters -look- like they are scoped to the class, whereas the return type
does not, but this argument is far from convincing for me.

> There are two ways around the sequencing problem.  The simplest would be to
> put the return type after the function name.  This would be a major change to
> declaration syntax and would break every "C" and "C++" program ever written.
> That makes this first possibly totally unacceptable.  The second would be
> to make the context qualifier 'sticky'.  That is
>
> Example::result_type operator ()(input_type in1, input_type in2)
> {
>     return in1 < in2;
> }

This could possibly work but doesn't really make much sense in the overall
context of "this method is part of a class.  Now everything else here is also
part of that class."  "This return type is part of a class, now everything else
is," is much less attractive.

> would be an acceptable definition of 'Example::operator ()'.  How wise this
> change to the language would be is another question of course and I have NO
> opinion on that.

Thanks for your input.

- JFA1


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Aguilar" wrote:
> Currently, when writing a member function in a class definition,
> typedefs that the programmer makes in the class allow member
> typedefs to be used as a return type, thus:
>
> class Example
> {
> public:
>   typedef bool result_type;
>   typedef int input_type;
>
>   result_type operator ()(input_type in1, input_type in2)
>   {
>     return in1 < in2;
>   }
> };

Yes, because the member type is in scope at the beginning of the
member function declaration.

> However, when defining a member function outside of the class in which it is
> declared, it looks more like this:
>
> Example::result_type Example::operator ()(input_type in1, input_type in2)
> {
>   return in1 < in2;
> }
>
> and
>
> result_type Example::operator ()(input_type in1, input_type in2)
> {
>   return in1 < in2;
> }
>
> is illegal.  This should not be.  If the parameter types can be
> assumed to be members of the containing class, so should return
> types.
<snip>

Perhaps they should, but the return type has to be parsed before the
member function name can be parsed and its scope determined.  In your
example this doesn't require the name to be looked-up immediately, but
general it is impossible to parse the return type without knowing what
scope names should be looked-up in.  In some circumstances it would be
necessary to resort to disambiguating keywords, as in template
definitions.  Why add further complexity to the declaration rules for
so little gain?

--
Ben Hutchings
Larkinson's Law: All laws are basically false.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Max T. Woodbury" wrote:
> James Aguilar wrote:
<snip>
>> So: allow member typedefs to be used implicitly in both return types and
>> parameter types.
>
> This causes technical parsing problems.  The return type of the function has
> to be known to be a type to parse it properly.
<snip>

I don't believe that in itself is a difficulty, because a declaration
must begin with either a keyword or a type-specifier.

--
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]