pdimov@mmltd.net (Peter Dimov) writes:

> Christopher Eltschka <celtschk@web.de> wrote in message news:<9ur287$g6h$1@news.tuwien.ac.at>...
> > Indeed, typeof can be implemented on top of this:
> >
> >   template<class T> struct type_struct { typedef T type; };
> >   template<class T> type_struct<T> typer(T const& expr);
> >   #define typeof(expr) typer(expr)::type
>
> One particular variation of 'typeof' that loses the top-level const
> and reference can.

You can also implement the version whichg doesn't loose top-level
const, by just removing the const in the argument of typer. Indeed, I
prefer that version; I just accidentally typed that const here.

"Losing" the reference is IMHO the right thing given the semantics
of references.

Alternatively you could of course invent a typeof which gave a
reference type for *any* lvalue, and a non-reference type for rvalues.
Done this way, it could actually be useful.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Christopher Eltschka <celtschk@web.de> wrote in message news:<9vq897$q$3@news.tuwien.ac.at>...
> pdimov@mmltd.net (Peter Dimov) writes:
>
> > Christopher Eltschka <celtschk@web.de> wrote in message news:<9ur287$g6h$1@news.tuwien.ac.at>...
> > > Indeed, typeof can be implemented on top of this:
> > >
> > >   template<class T> struct type_struct { typedef T type; };
> > >   template<class T> type_struct<T> typer(T const& expr);
> > >   #define typeof(expr) typer(expr)::type
> >
> > One particular variation of 'typeof' that loses the top-level const
> > and reference can.
>
> You can also implement the version whichg doesn't loose top-level
> const, by just removing the const in the argument of typer. Indeed, I
> prefer that version; I just accidentally typed that const here.

This (most likely, depending on how precisely expr::type is defined)
would make this implementation of typeof() not support non-const
rvalues. (The "argument forwarding" problem.)

> "Losing" the reference is IMHO the right thing given the semantics
> of references.

Not agreed.

typeof(f()) g()
{
  return f();
}

f() may return a reference to a noncopyable type. (The "return type
inference" problem.)

> Alternatively you could of course invent a typeof which gave a
> reference type for *any* lvalue, and a non-reference type for rvalues.
> Done this way, it could actually be useful.

Yes, this is my preferred typeof. ;-)

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Valentin Bonnard wrote:
>
> "James Kuyper Jr."  wrote:
...
> > Most simple function objects can be composed by using the
> > standard-defined funtion object classes, and the binders.
>
> Ah ah ah
>
> <laugh>
>
> You weren't joking ? Sorry, I think you were.

Hey - I very carefully did NOT say that they were "easily composed". :-)

---
[ 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.research.att.com/~austern/csc/faq.html                ]

agriff@tin.it (Andrea Griffini) writes:

> Hello...
>
> When coding with STL one should use typedefs to be able
> to write reasonable source code... but what about extending
> just a bit the C++ syntax and allow things like:
>
>   for (v::iterator i=v.begin(),e=v.end(); i!=e; ++i)
>   {
>     ...
>   }
>
> in other words allowing the use of an expression to
> identify a type ? To me seems this would simplify
> the cluttered STL syntax in a few places and should
> also be simple to implement.

I can remember havin seen this suggestion quite a few times (more
often it's seen with dot notation instead of :: notation, but I prefer
:: to indicate the left hand side should not be evaluated in this
case).

>
> This is in my opinion much simpler (from a logical
> point of view) than adding a "typeof" operator.

Indeed, typeof can be implemented on top of this:

  template<class T> struct type_struct { typedef T type; };
  template<class T> type_struct<T> typer(T const& expr);
  #define typeof(expr) typer(expr)::type

>
> sorry if this is very naive ... but i don't see the
> drawback of this approach.

I don't, either.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Christopher Eltschka <celtschk@web.de> wrote in message news:<9ur287$g6h$1@news.tuwien.ac.at>...
> Indeed, typeof can be implemented on top of this:
>
>   template<class T> struct type_struct { typedef T type; };
>   template<class T> type_struct<T> typer(T const& expr);
>   #define typeof(expr) typer(expr)::type

One particular variation of 'typeof' that loses the top-level const
and reference can.

--
Peter Dimov
Multi Media Ltd.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Richard Smith <richard@ex-parrot.com> wrote:
[...]
: I think perhaps we should be looking at ways of making it easier to define
: local classes and local functions (perhaps even ones that can access the
: automatic variables of the outer scope) and to use them in generic
: algorithms.

Perhaps lambda abstraction for the functions?

Tom Payne





















---
[ 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.research.att.com/~austern/csc/faq.html                ]

thp@cs.ucr.edu wrote:
> Richard Smith <richard@ex-parrot.com> wrote:
> [...]
> : I think perhaps we should be looking at ways of making it easier to define
> : local classes and local functions (perhaps even ones that can access the
> : automatic variables of the outer scope) and to use them in generic
> : algorithms.
>
> Perhaps lambda abstraction for the functions?

Yes, sure.

  --   VB

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr."  wrote:
> Andrea Griffini wrote:
>>
>> "Richard Smith" <richard@ex-parrot.com> wrote in message news:<1006970872.28117.0.nnrp-08.3e31d362@news.demon.co.uk>...
>>
>> > The standard answer to this is to use (and write if necessary) a generic
>> > algorithm such as for_each.  If you just write,
>> >
>> >     for_each(v.begin(), v.end(), do_something());
>> >
>> > you don't need to use any typedefs, as this is all handled by template
>> > argument deduction.
>>
>> This is wonderful, in theory. However sometimes the body of
>> "do_something" is very very simple and writing a separate
>> function doesn't add anything to clarity.
>
> Most simple function objects can be composed by using the
> standard-defined funtion object classes, and the binders.

Ah ah ah

<laugh>

You weren't joking   ? Sorry, I think you were.

  --   VB

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Richard Smith" <richard@ex-parrot.com> wrote in message news:<1006970872.28117.0.nnrp-08.3e31d362@news.demon.co.uk>...

> The standard answer to this is to use (and write if necessary) a generic
> algorithm such as for_each.  If you just write,
>
>     for_each(v.begin(), v.end(), do_something());
>
> you don't need to use any typedefs, as this is all handled by template
> argument deduction.

This is wonderful, in theory. However sometimes the body of
"do_something" is very very simple and writing a separate
function doesn't add anything to clarity.
Also it's quite common to have that code needing access to
other contextual symbols and, while possible to do, this
adds more clutter to this forced decontextualization.

Sometimes i got things working using local declared
classes (horrible, but at least you don't have to
jump around in the source code to understand the meaning
of that code) but that won't always work as local classes
have limitations.

Anyway this is a far more complex issue... i was just
wondering why object::name wasn't allowed to acces types;
looks  to me a somewhat "natural" use of :: and, while
i'm not a compiler guru, looks to me trivial to
implement in a C++ compiler (if anything can be trivial
in this syntax nightmare).

Andrea

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Andrea Griffini wrote:
>
> "Richard Smith" <richard@ex-parrot.com> wrote in message news:<1006970872.28117.0.nnrp-08.3e31d362@news.demon.co.uk>...
>
> > The standard answer to this is to use (and write if necessary) a generic
> > algorithm such as for_each.  If you just write,
> >
> >     for_each(v.begin(), v.end(), do_something());
> >
> > you don't need to use any typedefs, as this is all handled by template
> > argument deduction.
>
> This is wonderful, in theory. However sometimes the body of
> "do_something" is very very simple and writing a separate
> function doesn't add anything to clarity.

Most simple function objects can be composed by using the
standard-defined funtion object classes, and the binders.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Andrea Griffini" <agriff@tin.it> wrote in message
news:748d71e3.0112020232.5857df23@posting.google.com...
> "Richard Smith" <richard@ex-parrot.com> wrote in message
news:<1006970872.28117.0.nnrp-08.3e31d362@news.demon.co.uk>...
>
> > The standard answer to this is to use (and write if necessary) a generic
> > algorithm such as for_each.  If you just write,
> >
> >     for_each(v.begin(), v.end(), do_something());
> >
> > you don't need to use any typedefs, as this is all handled by template
> > argument deduction.
>
> This is wonderful, in theory. However sometimes the body of
> "do_something" is very very simple and writing a separate
> function doesn't add anything to clarity.
> Also it's quite common to have that code needing access to
> other contextual symbols and, while possible to do, this
> adds more clutter to this forced decontextualization.

I agree entirely, and I think that this is something that does need
addressing, but I'm not sure that

    for (v::iterator i=v.begin(),e=v.end(); i!=e; ++i) { ... }

is necessarily the best way to go.

> Sometimes i got things working using local declared
> classes (horrible, but at least you don't have to
> jump around in the source code to understand the meaning
> of that code) but that won't always work as local classes
> have limitations.

I think perhaps we should be looking at ways of making it easier to define
local classes and local functions (perhaps even ones that can access the
automatic variables of the outer scope) and to use them in generic
algorithms.  For example, the restriction that local classes don't have
external linkage, and hence can't be used as template arguments, has always
struck me as unecessary.  But as you say, this is all incidental to your
original point.

> Anyway this is a far more complex issue... i was just
> wondering why object::name wasn't allowed to acces types;
> looks  to me a somewhat "natural" use of :: and, while
> i'm not a compiler guru, looks to me trivial to
> implement in a C++ compiler (if anything can be trivial
> in this syntax nightmare).

Yes, I think it probably would be fairly straight-forward to add this
functionality, and as I said earlier I think it will probably tidy up some
things that I regard as inconsistencies in the language.

--
Richard Smith


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Andrea Griffini" <agriff@tin.it> wrote in message
news:3c02cef8.18566538@news.interbusiness.it...
>
> Hello...
>
> When coding with STL one should use typedefs to be able
> to write reasonable source code... but what about extending
> just a bit the C++ syntax and allow things like:
>
>   for (v::iterator i=v.begin(),e=v.end(); i!=e; ++i)
>   {
>     ...
>   }
>
> in other words allowing the use of an expression to
> identify a type ? To me seems this would simplify
> the cluttered STL syntax in a few places and should
> also be simple to implement.

The standard answer to this is to use (and write if necessary) a generic
algorithm such as for_each.  If you just write,

    for_each(v.begin(), v.end(), do_something());

you don't need to use any typedefs, as this is all handled by template
argument deduction.

> This is in my opinion much simpler (from a logical
> point of view) than adding a "typeof" operator.

Yes, but it is not as flexible -- what if there is no such type v::iterator?
The typeof(v.begin()) solution would still work, but v::iterator would not.

Having said that, I'm not in favour of a typeof keyword, and I think that
this is something that would tidy up an inconsistancy in the language.
Currently, the construct foo::bar (where foo is an instance of a class) is a
valid way of accessing any non-type name 'bar' in the class bar.  I don't
see any reason why it shouldn't be possible to access type names in the same
way.  The information is certainly avaliable to the compiler.

--
Richard Smith


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hello...

When coding with STL one should use typedefs to be able
to write reasonable source code... but what about extending
just a bit the C++ syntax and allow things like:

  for (v::iterator i=v.begin(),e=v.end(); i!=e; ++i)
  {
    ...
  }

in other words allowing the use of an expression to
identify a type ? To me seems this would simplify
the cluttered STL syntax in a few places and should
also be simple to implement.

This is in my opinion much simpler (from a logical
point of view) than adding a "typeof" operator.

sorry if this is very naive ... but i don't see the
drawback of this approach.

Andrea

---
[ 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.research.att.com/~austern/csc/faq.html                ]