Topic: Limitation with typedefs


Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1999/07/26
Raw View
On 12 Jul 99 12:55:01 GMT, Christopher Eltschka

>It can be made more readable with a typedef, like
>
>  typedef std::map<std::string, Foo>::iterator var;
>  var iter = m.find(key);
>
>but we still have to write down the type unnecessarily.
>The only way to avoid this are additional templates:

Ah, the typeof keyword to the rescue again!
   Foo get(std::map<std::string, Foo>& foomap,
           std::string key,
           Foo const& defaultFoo)
   {
     typedef typeof(foomap)::iterator Iter;
     const Iter iter = m.find(key);
     return (iter==m.end())? defaultFoo : *iter;
   }

But templates might be even better.  Template are pretty much
necessary because the map might have non-default third and fourth
arguments.
   export
   template <class Container>
   Foo get(const Container& foomap,
           std::string key,
           Foo const& defaultFoo)
   {
     typedef typename Container::iterator Iter;
     const Iter iter = m.find(key);
     return (iter==m.end())? defaultFoo : *iter;
   }


>Also note that in case you notice that in both functions
>above the container is not changed and should therefore
>be passed by const reference, currently you'll have to
>change all the declarations from X::iterator to
>X::const_iterator; with the var notation this would not
>be necessary.

Good point.  But now the behaviour of "var" is harder
to write up in a standard.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Nick Ambrose <nicka@interdyn.com>
Date: 1999/07/20
Raw View
Peter Mutsaers wrote:

> >> "CE" == Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>
>     CE> In current C++, we would have to write
>
>     CE>   std::map<std::string, Foo>::iterator iter = m.find(key);
>
>     CE> This is less readable without adding new information
>
> If you (usually) typedef the template usages, e.g.
> typedef map<std::string, Foo> str2fmap;
>
> then using str2fmap::iterator isn't that bad.
>
> I think it is good practice to use a typedef for such cases.

And another good think about it is if I then change my mind and want another
container which has the same interface and iterator-types, I can change the
typedef and not break client code (true, it will have to be rebuilt but not
re-written)

Nick
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1999/07/15
Raw View
Fergus Henderson wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>
> >I'd like a "var" construct, where "var" denotes the type of the
> >initializer (and may only be used with the "=" syntax, so it
> >is guaranteed that there's exactly one object whose type to take).
>
> I agree such a construct would be very handy.
> But something similar to this would be useful for constants too --
> it would be good if there was an analagous construct which gave
> you the const-qualified type corresponding to the type of the
> initializer.

Since "var" can be seen as placeholder for that type, the logical
way to do so would be

  var const foo = bar;

"var const" looks quite strange; however, since...

>
> Making "var" a keyword would probably break quite a few programs...

... one could choose a better one which doesn't look strange
with const.

Maybe "righttype" would be a good choice: It stands for the
*type* on the *right* hand side of the "=". In addition, it
suggests that it is just the right type ;-)

However, it's quite long; abbreviations like "rtype" suffer
from the same problem as "var", though.

One could also use a currently illegal syntax, like:

? a = foo();

(but this could give problems if the ';' was forgotten on a
previous expression statement)

Maybe we could use ":=" as "definition operator":

a := foo(); // define a as type of foo(), initialized with foo()

This would also be consistent with the use of ":=" in math.

OTOH, I guess "mutable" broke at least as many programs as
"var" would do.

> perhaps we could use "auto" instead ;-)

At least it would break less code, and it would continue
the tradition of re-using keywords for different purposes ;-)
(And, of course, it's not that wrong, since the type would be
automatically right.)


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/07/15
Raw View
Christopher Eltschka wrote:

> Fergus Henderson wrote:

> > perhaps we could use "auto" instead ;-)

> At least it would break less code, and it would continue
> the tradition of re-using keywords for different purposes ;-)

static f = 5.;

Oups, it doesn't work !

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Peter Mutsaers <plm@xs4all.nl>
Date: 1999/07/19
Raw View
>> "CE" == Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

    CE> In current C++, we would have to write

    CE>   std::map<std::string, Foo>::iterator iter = m.find(key);

    CE> This is less readable without adding new information

If you (usually) typedef the template usages, e.g.
typedef map<std::string, Foo> str2fmap;

then using str2fmap::iterator isn't that bad.

I think it is good practice to use a typedef for such cases.

It is like the C++ library does too, like (in <string>):

typedef basic_string<char> string;
typedef basic_string<wchar_t> wstring;

--
Peter Mutsaers |  Abcoude (Utrecht), | Trust me, I know
plm@xs4all.nl  |  the Netherlands    | what I'm doing.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1999/07/12
Raw View
Siemel Naran wrote:

[...]

> As you suggest, I could very well make a pointer to function.
>          void (*const Function)()=&SomeNamespace::LongFunctionName;
> But this means that I have to duplicate the function signature,
> which is a nuisance if it is long -- and this almost always happens
> to be the case.  The argument and return types may have slighly long
> names, and maybe live in namespaces with slightly long names, or
> nested namespaces or nested classes.
>
> But from the other posts, I realize that a function is really
> an object, and you can't typedef one object to another, which is
> what I was trying to do.  But a class is a type, and you can
> typedef one type into another.
>
> Incidentally, this is yet another place where the 'typeof' keyword
> would be useful.  Here goes:
>    const typeof(SomeNamespace::LongFunctionName)
>       Function=&SomeNamespace::LongFunctionName;
> It's cumbersome that we have to write "SomeNamespace::LongFunctionName"
> twice, but otherwise, I think this notation is quite clear.

I'd like a "var" construct, where "var" denotes the type of the
initializer (and may only be used with the "=" syntax, so it
is guaranteed that there's exactly one object whose type to take).

Useful examples for this:

Foo get(std::map<std::string, Foo>& foomap,
        std::string key,
        Foo const& defaultFoo)
{
  var iter = m.find(key);
  return (iter==m.end())? defaultFoo : *iter;
}

In current C++, we would have to write

  std::map<std::string, Foo>::iterator iter = m.find(key);

This is less readable without adding new information
(we don't really care about the exact type of the iterator,
we only need the fact that it is the iterator which is
returned by find).
It can be made more readable with a typedef, like

  typedef std::map<std::string, Foo>::iterator var;
  var iter = m.find(key);

but we still have to write down the type unnecessarily.
The only way to avoid this are additional templates:

template<class Iter, class T>
 T deref_or_default(Iter i, Iter end, T const& def)
{
  return (i==end)? def : *i;
}

Foo get(/* params as above */
{
  return deref_or_default(foomap.find(key),
                          foomap.end(),
                          defaultFoo);
}

I doubt this is more readable, though (it's a helper function
without generally useful semantics, which is always called with
end() as the second argument).

Another example:

void info(std::multimap<int, int>& m, int i)
{
  var range = m.equal_range(i);
  if (range.first == range.second)
    std::cout << "No elements!" << std::endl;
  for(var i=range.first; i!=range.second; ++i)
    std::cout << i->second << endl;
}

In this case, we have two variables where writing down the
exact type would not be helpful. First, the range: we know
that equal_range returns a pair of iterators; however, all
we really need to know is that we get to those iterators by
writing range.first and range.second; the exact type
(std::pair<std::multimap<int, int>::iterator,
           std::multimap<int, int>::iterator>)
would only serve to confuse.
The same is true for the iterator i, which is just the
type of f.first - the full type would not help here either.

Also note that in case you notice that in both functions
above the container is not changed and should therefore
be passed by const reference, currently you'll have to
change all the declarations from X::iterator to
X::const_iterator; with the var notation this would not
be necessary.

Finally note that this doesn't create a hole in the type
system; the variables still have an unique, well defined
type - just that it isn't written down explicitly.

If we didn't need the same value more than once, we could
just have used unnamed temporaries, where we generally
don't write the type explicitly as well. The var keyword
would allow to do the same even if the same value is used
twice.

[...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1999/07/12
Raw View
blargg@flash.net writes:

>Let's stop mucking around with the details and look at the big picture.
>
>Is renaming in a totally general sense, i.e. scoped token replacement,
>really generally useful?

Yes!

>As I understand it, typedef wasn't introduced to shorten long names. It
>was mainly for abstraction [...]

Renaming of other kinds of entities is useful for abstraction too.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1999/07/13
Raw View
On 11 Jul 99 01:37:57 GMT, blargg@flash.net <blargg@flash.net> wrote:

>There are many idioms that don't use a language feature for its intended
>purpose. This is one of them.

How do you know what the intended purpose of 'typedef' was?  And even
if the original purpose was to help with some kind of abstraction, it's
reasonable to believe that the purpose evolved.  I still maintain that
renaming is invaluable for program understanding.


>> Anyway, my main intent is to avoid duplicating long function signatures.
>
>Get the function names right (reasonably short) in the first place and
>there is no problem.

This is not always possible.  The names have to be long enough to be
descriptive to a general audience.  Consider std::back_inserter.  To
me, it's quite a long name.  But it has to be so.  Alternatives like
std::inserter or std::insert or std::bi or std::iback would be not
descriptive enough, or would be misleading.  But at global file scope
in a cpp file, or inside a function, I might want to rename the
function to insert.  I do this a lot with classes, eg:
   void f() {
      typedef math::Polynomial<double,int> Poly;
      Poly p1(...);
      Poly p2(...);
   }
So it would be nice to do this with functions too.  The typeof
trick I mentioned in another post seems to be the way to do it.
   void f() {
      const typeof(math::make_Polynomial<double,int>) make
         =&math::make_Polynomial<double,int>;
      ...
   }

The 'const' in the declaration of f()::make encourages the
compiler to do the optimization of resolving the function address
to call at compile time.  So the compiler can eliminate storage
space for f()::make and even inline the function!

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: blargg@flash.net
Date: 1999/07/13
Raw View
In article <slrn7ok97f.2gk.sbnaran@localhost.localdomain>,
sbnaran@uiuc.edu wrote:

> On 11 Jul 99 01:37:57 GMT, blargg@flash.net <blargg@flash.net> wrote:
>
> >There are many idioms that don't use a language feature for its intended
> >purpose. This is one of them.
>
> How do you know what the intended purpose of 'typedef' was?  And even
> if the original purpose was to help with some kind of abstraction, it's
> reasonable to believe that the purpose evolved.  I still maintain that
> renaming is invaluable for program understanding.

Please provide examples of renaming functions that enhance program
understanding.

> >> Anyway, my main intent is to avoid duplicating long function signatures.
> >
> >Get the function names right (reasonably short) in the first place and
> >there is no problem.
>
> This is not always possible.  The names have to be long enough to be
> descriptive to a general audience.  Consider std::back_inserter.

I assume this isn't a function, so it isn't relevant to what I said above.

> To
> me, it's quite a long name.  But it has to be so.  Alternatives like
> std::inserter or std::insert or std::bi or std::iback would be not
> descriptive enough, or would be misleading.  But at global file scope
> in a cpp file, or inside a function, I might want to rename the
> function to insert.

It's a function? Why would this aid in comprehension?

> I do this a lot with classes, eg:
>    void f() {
>       typedef math::Polynomial<double,int> Poly;
>       Poly p1(...);
>       Poly p2(...);
>    }

We are NOT talking about classes. Argh.

Anyway, this is more than a rename. It is a concept. Poly means some
Polynomial type. It is more than just renaming.

> So it would be nice to do this with functions too.  The typeof
> trick I mentioned in another post seems to be the way to do it.

typeof has no special meaning in C++. We are discussing a hypothetical
language feature (function renaming), and you're suggesting ways of
achieving it with another hypothetical language feature? Is this a game?

>    void f() {
>       const typeof(math::make_Polynomial<double,int>) make
>          =&math::make_Polynomial<double,int>;
>       ...
>    }
>
> The 'const' in the declaration of f()::make encourages the
> compiler to do the optimization of resolving the function address
> to call at compile time.  So the compiler can eliminate storage
> space for f()::make and even inline the function!

Wow! Efficiency.

Whatever.... I think Java has some "hot" stuff that would be novel to play
with. I'm going to be making useful things with C++.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1999/07/14
Raw View
Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

>I'd like a "var" construct, where "var" denotes the type of the
>initializer (and may only be used with the "=" syntax, so it
>is guaranteed that there's exactly one object whose type to take).

I agree such a construct would be very handy.
But something similar to this would be useful for constants too --
it would be good if there was an analagous construct which gave
you the const-qualified type corresponding to the type of the
initializer.

Making "var" a keyword would probably break quite a few programs...
perhaps we could use "auto" instead ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1999/07/09
Raw View
We can do this
   int main() {
      typedef SomeNamespace::LongClassName Class;
      Class<int> c(1,2,3); // make a class
   }

So why can't we do
   int main() {
      typedef SomeNamespace::LongFunctionName Function;
      Function<int>(1,2,3); // call a function
   }

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Valentin Bonnard <Bonnard.V@wanadoo.fr>
Date: 1999/07/09
Raw View
Siemel Naran wrote:

> We can do this
>    int main() {
>       typedef SomeNamespace::LongClassName Class;
>       Class<int> c(1,2,3); // make a class
>    }

No

> So why can't we do
>    int main() {
>       typedef SomeNamespace::LongFunctionName Function;
>       Function<int>(1,2,3); // call a function
>    }

???

(inline forwarding function)

Do you want Ada's renaming ?

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: wmm@fastdial.net
Date: 1999/07/09
Raw View
In article <slrn7o9mls.pb7.sbnaran@localhost.localdomain>,
  sbnaran@uiuc.edu wrote:
> We can do this
>    int main() {
>       typedef SomeNamespace::LongClassName Class;
>       Class<int> c(1,2,3); // make a class
>    }
>
> So why can't we do
>    int main() {
>       typedef SomeNamespace::LongFunctionName Function;
>       Function<int>(1,2,3); // call a function
>    }

Because types and functions are pretty different things.

If you want to make a shorter synonym for a function, you can
use a pointer or reference.

(Yes, I know this doesn't work for a function template, but
neither does "typedef" for class templates, contrary to your
assertion, so the situation is parallel.)

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: comeau@panix.com (Greg Comeau)
Date: 1999/07/09
Raw View
In article <slrn7o9mls.pb7.sbnaran@localhost.localdomain> sbnaran@uiuc.edu writes:
>We can do this
>   int main() {
>      typedef SomeNamespace::LongClassName Class;
>      Class<int> c(1,2,3); // make a class
>   }
>
>So why can't we do
>   int main() {
>      typedef SomeNamespace::LongFunctionName Function;
>      Function<int>(1,2,3); // call a function
>   }

Because typedef is _type_define, not #define.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: blargg@flash.net
Date: 1999/07/10
Raw View
In article <7m57s6$n60$1@panix.com>, comeau@comeaucomputing.com wrote:

> In article <slrn7o9mls.pb7.sbnaran@localhost.localdomain>
sbnaran@uiuc.edu writes:
> >We can do this
> >   int main() {
> >      typedef SomeNamespace::LongClassName Class;
> >      Class<int> c(1,2,3); // make a class
> >   }
> >
> >So why can't we do
> >   int main() {
> >      typedef SomeNamespace::LongFunctionName Function;
> >      Function<int>(1,2,3); // call a function
> >   }

Let's stop mucking around with the details and look at the big picture.

Is renaming in a totally general sense, i.e. scoped token replacement,
really generally useful?

As I understand it, typedef wasn't introduced to shorten long names. It
was mainly for abstraction (with clarity for "confusing" function pointer
and similar types).

It just so happens that it can be used conveniently to shorten long type
names. It also happens to be that renaming functions isn't as convenient -
some type of forwarding is needed.

To bring in a related renaming construct, that of namespace aliases, this
is because namespaces are to prevent name collisions, and thus namespace
names at the company level (AcmeCo_namespace { }) will tend to be rather
long.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Pete Becker <petebecker@acm.org>
Date: 1999/07/10
Raw View
Siemel Naran wrote:
>
> We can do this
>    int main() {
>       typedef SomeNamespace::LongClassName Class;
>       Class<int> c(1,2,3); // make a class
>    }
>
> So why can't we do
>    int main() {
>       typedef SomeNamespace::LongFunctionName Function;
>       Function<int>(1,2,3); // call a function
>    }

Neither one of these is legal. From their usage, it looks like
SomeNamespace::LongClassName and SomeNamespace::LongFunctionName,
despite their names, are supposed to be the names of two templates.
Typedef can't be used on templates, only on types (e.g. template
instantiations).

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1999/07/10
Raw View
On 9 Jul 1999 15:50:07 GMT, wmm@fastdial.net <wmm@fastdial.net> wrote:
>In article <slrn7o9mls.pb7.sbnaran@localhost.localdomain>,

>>       typedef SomeNamespace::LongClassName Class;
>>       Class<int> c(1,2,3); // make a class

>>       typedef SomeNamespace::LongFunctionName Function;
>>       Function<int>(1,2,3); // call a function


>Because types and functions are pretty different things.
>
>If you want to make a shorter synonym for a function, you can
>use a pointer or reference.

Oops.  I meant for Class and Function to be a non-template class
and non-template function, respectively.  So now
         typedef SomeNamespace::LongClassName Class;
         Class c(1,2,3); // make a class
works as expected.  But
         typedef SomeNamespace::LongFunctionName Function;
         Function(1,2,3); // call a function
fails to work because the typedef is a syntax error.

As you suggest, I could very well make a pointer to function.
         void (*const Function)()=&SomeNamespace::LongFunctionName;
But this means that I have to duplicate the function signature,
which is a nuisance if it is long -- and this almost always happens
to be the case.  The argument and return types may have slighly long
names, and maybe live in namespaces with slightly long names, or
nested namespaces or nested classes.

But from the other posts, I realize that a function is really
an object, and you can't typedef one object to another, which is
what I was trying to do.  But a class is a type, and you can
typedef one type into another.

Incidentally, this is yet another place where the 'typeof' keyword
would be useful.  Here goes:
   const typeof(SomeNamespace::LongFunctionName)
      Function=&SomeNamespace::LongFunctionName;
It's cumbersome that we have to write "SomeNamespace::LongFunctionName"
twice, but otherwise, I think this notation is quite clear.


>(Yes, I know this doesn't work for a function template, but
>neither does "typedef" for class templates, contrary to your
>assertion, so the situation is parallel.)

Sorry, at the last minute, I added the fact that
SomeNamespace::LongClassName and SomeNamespace::LongFunctionName
were templates.  For a moment, I thought that template typedefs
were part of the standard.  If they were part of the standard,
then the question makes more sense.  But because we can't typedef
objects, the original program would still be a syntax error.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1999/07/10
Raw View
On 10 Jul 99 06:54:00 GMT, blargg@flash.net <blargg@flash.net> wrote:
>> In article <slrn7o9mls.pb7.sbnaran@localhost.localdomain>

>Let's stop mucking around with the details and look at the big picture.
>
>Is renaming in a totally general sense, i.e. scoped token replacement,
>really generally useful?

Yes.  Shorter names are invaluable for program maintainance.  I could
do this
   #define Function SomeNamespace::LongFunctionName;
   Function(1,2,3);
   #undef Function
but I'd rather avoid #define's.


>As I understand it, typedef wasn't introduced to shorten long names. It
>was mainly for abstraction (with clarity for "confusing" function pointer
>and similar types).
>
>It just so happens that it can be used conveniently to shorten long type
>names. It also happens to be that renaming functions isn't as convenient -
>some type of forwarding is needed.

Why isn't renaming functions not as convenient?  Anyway, my main intent
is to avoid duplicating long function signatures.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: blargg@flash.net
Date: 1999/07/11
Raw View
In article <slrn7of6ah.5sb.sbnaran@localhost.localdomain>,
sbnaran@uiuc.edu wrote:

> On 10 Jul 99 06:54:00 GMT, blargg@flash.net <blargg@flash.net> wrote:
> >> In article <slrn7o9mls.pb7.sbnaran@localhost.localdomain>
>
> >Let's stop mucking around with the details and look at the big picture.
> >
> >Is renaming in a totally general sense, i.e. scoped token replacement,
> >really generally useful?
>
> Yes.  Shorter names are invaluable for program maintainance.  I could
> do this
>
>    #define Function SomeNamespace::LongFunctionName;
>    Function(1,2,3);
>    #undef Function
>
> but I'd rather avoid #define's.

Don't you mean the opposite? I would consider lots of different names for
the same function to be a maintenance problem.

You tried to make your case by throwing in a namespace name too. That is
not an issue.

    using SomeNamespace::LongFunctionName;

    LongFunctionName();

If the function name was too long to use conveniently, then it was named
wrong in the beginning. This is a design issue, and not one to throw a
language feature at (general renaming).

Show me a good case for general renaming of functions.

> >As I understand it, typedef wasn't introduced to shorten long names. It
> >was mainly for abstraction (with clarity for "confusing" function pointer
> >and similar types).
> >
> >It just so happens that it can be used conveniently to shorten long type
> >names. It also happens to be that renaming functions isn't as convenient -
> >some type of forwarding is needed.
>
> Why isn't renaming functions not as convenient?

I'm not sure what you're asking.

Renaming functions is not a one-liner like a typedef (or namespace alias)
is. This isn't as convenient. Typedefs coincidentally can be used to
shorten names. There doesn't happen to be a feature in the language that
can be used in a simple way to get the effect of renaming functions.
Renaming with typedef can be considered a syntactic hack - the new entity
isn't for abstraction purposes, just for renaming purposes.

There are many idioms that don't use a language feature for its intended
purpose. This is one of them.

> Anyway, my main intent is to avoid duplicating long function signatures.

Get the function names right (reasonably short) in the first place and
there is no problem.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]