I agree with Siemel and Joe that this should be included, and have had some
discussion within the EGCS compiler mailing list about this issue ... the usual
response is that it is not part of the standard ...

How do we hound the committee to make it a part of the standard?

[ moderator's note: See the newsgroup FAQ. -sdc ]

William Waterson



[ 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              ]

Will wrote:
>
> I agree with Siemel and Joe that this should be included, and have had some
> discussion within the EGCS compiler mailing list about this issue ... the usual
> response is that it is not part of the standard ...
>
> How do we hound the committee to make it a part of the standard?
>
> [ moderator's note: See the newsgroup FAQ. -sdc ]

Which IMHO isn't very helpful in this case. It's mainly
a pointer to D&E, together with the fact that you'll have to
wait for the next round, and that the idea probably was
rejected anyway.

AFAIK, to get something into the standard, you generally should
make it widely used, i.e. get it into a comiler. The problem
here is: To get it into the compiler, you first have to get it
into the standard. Sort of a chicken-and-egg 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              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote in message
news:377894CE.8FF1609E@physik.tu-muenchen.de...
> Will wrote:
> > I agree with Siemel and Joe that this should be included, and have had
some
> > discussion within the EGCS compiler mailing list about this issue ...
the usual
> > response is that it is not part of the standard ...
> >
> > How do we hound the committee to make it a part of the standard?
> >
> AFAIK, to get something into the standard, you generally should
> make it widely used, i.e. get it into a comiler. The problem
> here is: To get it into the compiler, you first have to get it
> into the standard. Sort of a chicken-and-egg problem...

Requiring something to be added to the standard before it will be included
in a compiler is wrong.  It would require that a feature be added to the
standard before there was enough experience to show that the feature was
truly useful and practical.  The standard should specify the minimum that a
compiler will support, not the maximum.  New ideas for features should first
be tried as compiler extensions.  If the extension proves to be useful and
practical, then it can be considered for addition to the standard as part of
the minimum set of features that all compilers should support.
---
[ 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              ]

Christopher Eltschka wrote:
...
> AFAIK, to get something into the standard, you generally should
> make it widely used, i.e. get it into a comiler. The problem
> here is: To get it into the compiler, you first have to get it
> into the standard. Sort of a chicken-and-egg problem...

Incorrect. It's quite normal for compilers to support features that
aren't in the standard. If nothing else, there are shareware compilers
with freely available source code. Even if no one else likes your idea,
you can download one of those compilers and make the changes yourself.
Show that it can be implemented, show how it works, and you may be able
to convince a popular compiler to support it.
---
[ 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              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

>> I agree with Siemel and Joe that this should be included, and have had some
>> discussion within the EGCS compiler mailing list about this issue ... the usual
>> response is that it is not part of the standard ...
>>
>> How do we hound the committee to make it a part of the standard?
>>
>> [ moderator's note: See the newsgroup FAQ. -sdc ]

>Which IMHO isn't very helpful in this case. It's mainly
>a pointer to D&E, together with the fact that you'll have to
>wait for the next round, and that the idea probably was
>rejected anyway.

Well, it's the truth, however inconvenient that might be.
In particular, you don't "hound" the C++ committee. You can
make proposals, as explained in the FAQ, but no matter how
good a proposal is, it can't go into the current standard.

>AFAIK, to get something into the standard, you generally should
>make it widely used, i.e. get it into a comiler. The problem
>here is: To get it into the compiler, you first have to get it
>into the standard. Sort of a chicken-and-egg problem...

All C++ implementations offer extensions that are not in the
standard. The GNU project is famous for experiments, in
particular. Hound your favorite vendor(s) to add the extension.
It might take some persuading, but it should be easier (and
quicker) to persuade a vendor if the idea has merit than to
get action from the C++ committee. By design, it takes a long
time for committee actions to reach fruition.

If there is wide agreement on the utility of an extension, it
will appear in more implementations, and probably wind up in
the next standard.

--
Steve Clamage, stephen.clamage@sun.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              ]

On 02 Jun 99 13:23:20 GMT, Ram'on Garc'ia Fern'andez

>The idea is that the expression
>template <template args>
>typedef "existing type" "alias type";

I showed that the BNF grammar supports this syntax.  But people corrected
me: if the BNF grammar supports some construct, this does not mean that
the construct is legal; but if a construct is legal, then it must be
expressible in a BNF construct.

In short, template typedefs are a great idea and should be in the
standard.  Maybe compiler vendors will add it as an extension.

BTW, there is a workaround:
   template <class T>
   struct Container { typedef std::vector<T,myallocator<T> > type; };
and to use
   int main() { Container<int>::type container; };

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

Siemel Naran wrote:

> On 02 Jun 99 13:23:20 GMT, Ram'on Garc'ia Fern'andez
>
> >The idea is that the expression
> >template <template args>
> >typedef "existing type" "alias type";
>
> I showed that the BNF grammar supports this syntax.  But people corrected
> me: if the BNF grammar supports some construct, this does not mean that
> the construct is legal; but if a construct is legal, then it must be
> expressible in a BNF construct.
>
> In short, template typedefs are a great idea and should be in the
> standard.  Maybe compiler vendors will add it as an extension.
>
> BTW, there is a workaround:
>    template <class T>
>    struct Container { typedef std::vector<T,myallocator<T> > type; };
> and to use
>    int main() { Container<int>::type container; };
>
>

       I have a question about how this would work.  Suppose you already have
a template class
Foo, something like

template <class X>
class Foo {};

If you wanted a template typedef to make Bar<X> an alias for Foo<X>, would
you do it like

template <class X>
typedef  Foo<X> Bar;

or like

tempate <class X>
typedef Foo Bar;

I would lean toward the first, because then you could legally write code like

template <class X>
typedef int Glarch;      //Make Glarch<X> equivelent to int for all X

Also, should it be possible to specialize template typedefs?  How about
specializing a template class using  a template typedef , like

 template <class X> class Foo {};
template<> typedef int Foo<int>;

   I do think template typedefs would be a good idea, but it would take a bit
of work to design them correctly.

--
Joe Gottman
joegottman@worldnet.att.net

The philosophy of C++: "Nothing is false; everything else is true."
---
[ 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              ]

C++ provides template classes and template functions, so why not providing
template typedefs.

The idea is that the expression
template <template args>
typedef "existing type" "alias type";

where the expression exiting type defines a type, using
"template args" for its definition. This sentence creates new
alias type, that is used as "alias type"<template args".

I believe that this extension is quite natural and coherent with the
rest of the language. Now let me show some examples.

I want to be able to change some code from using std::vector
to using std::list, because sometimes a vector is better for my purpose
but sometimes a list is better, depending on the final program where this
code will be used.

So instead of hardwiring the container class inside my code, I always use
a container alias "mycontainer".


I define the alias with a template typedef:

template <typename T, typename allocator = alloc>
typedef std::vector<T, alloc> mycontainer<T, alloc>;

I could achive the same effect using C macros:
#define mycontainer std::vector

but all of you know that macros are ugly because they lead to obscure error
messages, they are more difficult to manage for development tools (for example,
if you have a compiler that can find for you where a type is defined, or where
it is implemented) and so on.

Another example: suppose that I use a vector of vectors quite often. It makes
sense to define:

template <typaname T, typename allocator = alloc>
typedef std::vector<std::vector<T, allocator>, allocator> vvector;

vvector<string> a; // a is std::vector<std::vector<string, alloc>, alloc>

I have read the FAQ about proposing new extensions. The FAQ says that
before making a new proposal I should read the book "Developent and
evolution of C++". Unfortunately I do not have enough free time, even
if my experience with "The C++ programming language" was great. Anyway,
I believe that I understand the C++ design goals, and that all my
proposals are coherent with the language. If there is anything
that can help so that proposals can be taken into account for the next
revision of the language, please let me know. I will do my best
within my time and money constrains.

Please focus your answers in the main ideas, rather that spelling errors
or minor technical programs.

Ramon
---
[ 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              ]