Topic: [std lib] is cute feature X missing?


Author: jgottman@carolina.rr.com ("Joe Gottman")
Date: Thu, 18 Aug 2005 05:35:01 GMT
Raw View
""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message
news:4303a589$0$18645$14726298@news.sunsite.dk...
>
> ""Joe Gottman"" <jgottman@carolina.rr.com> wrote in message
> news:pvvMe.134235$3j2.4505031@twister.southeast.rr.com...
>>
>> ""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message
>
>> > Let's hear your ideas.
>
>>   One thing that would be neat is a make_array template function, similar
> to
>> make_pair and make_tuple, that returns a tr1::array object.
>>     template <class X> array<X, 0> make_array();
>>     template <class X, class P1> array<X, 1> make_array(const P1 &p1);
>>     template <class X, class P1, class P2> array<X, 2> make_array(const
>> P1
>> &p1, const P2 &p2);
>> etc.
>>
>> This would interact very nicely with the new auto syntax, which seems
> likely
>> to make it into C++09
>>
>>     auto array1 = make_array<string>("Foo", "Bar", "Glarch"); // type is
>> array<string, 3>
>>    auto array2 = make_array<double>(1, 2, 2.5, 3); //type is
>> array<double,
>> 4>
>>
>> The paper that originally proposed tr1::array
>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html)
>> mentioned that there was no way to parallel the automatic type deduction
>> seen in the code
>>     int x[] = {0, 1, 2, 3};
>>
>> The make_array function together with auto would add that ability, albeit
>> with a new syntax.
>
> In the example above, one can use the normal { .... } syntax.
> Mentioning the type is easier than with make_array, but
> specifying the size is irritating. Then again, why not use a vector
> if you don't want to specify the size?
> (well, eficieny, but is that important here?)

One reason is that make_array can be used after construction.
    array<int, 3> foo = make_array<int>(1,2, 3);
    // do some processing
    foo = make_array<int>(4, 5, 6);

Also, tr1::array is supposed to be a replacement for C-style arrays.  It
would be nice if it emulated all the features of C-style arrays, including
automatic size deduction.


>
> If only we could avoid making N overloads of the function :-)
>

   This might be possible if the variadic template proposal passes
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf).  I have
no idea how likely this is to happen.

> Another question is what the practical limit of the number of overloads
> should be?
>

At least the maximum number of elements allowed in a tuple, which is
implementation-defined but at least 10.

Joe Gottman


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





Author: nesotto@cs.aau.dk ("Thorsten Ottosen")
Date: Fri, 19 Aug 2005 04:58:58 GMT
Raw View
""Joe Gottman"" <jgottman@carolina.rr.com> wrote in message
news:9VQMe.140541$3j2.4612965@twister.southeast.rr.com...
>
> ""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message

> > In the example above, one can use the normal { .... } syntax.
> > Mentioning the type is easier than with make_array, but
> > specifying the size is irritating. Then again, why not use a vector
> > if you don't want to specify the size?
> > (well, eficieny, but is that important here?)
>
> One reason is that make_array can be used after construction.
>     array<int, 3> foo = make_array<int>(1,2, 3);
>     // do some processing
>     foo = make_array<int>(4, 5, 6);

right. is that very used?

the committee is going to look a lot at initialization for C++0x, for
example to
support { .... } initialization of classes like vector.

perhaps one should also be able to use { ... } in assignments.

> Also, tr1::array is supposed to be a replacement for C-style arrays.  It
> would be nice if it emulated all the features of C-style arrays, including
> automatic size deduction.

it would be nice.

> > If only we could avoid making N overloads of the function :-)
> >
>
>    This might be possible if the variadic template proposal passes
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf).  I
have
> no idea how likely this is to happen.

me neither.

br

-Thorsten


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





Author: nesotto@cs.aau.dk ("Thorsten Ottosen")
Date: Tue, 16 Aug 2005 21:44:16 GMT
Raw View
Dear All,

I'm baking on a small paper for the C++ standard committee. It's gonna be
a mix of little things or changes or tweaks to the standard library.

If you have any ideas that you would like me to incorporate, let's discuss
it here and we'll see if its worth including. Maybe you're missing an
algorithm.
Maybe you would like a new member function in vector. Who knows.
Let's hear your ideas.

I have my own list, but I won't disclose it before the paper is out.

best regards

Thorsten


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





Author: jgottman@carolina.rr.com ("Joe Gottman")
Date: Wed, 17 Aug 2005 03:02:23 GMT
Raw View
""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message
news:43025a3c$0$18646$14726298@news.sunsite.dk...
> Dear All,
>
> I'm baking on a small paper for the C++ standard committee. It's gonna be
> a mix of little things or changes or tweaks to the standard library.
>
> If you have any ideas that you would like me to incorporate, let's discuss
> it here and we'll see if its worth including. Maybe you're missing an
> algorithm.
> Maybe you would like a new member function in vector. Who knows.
> Let's hear your ideas.
>
> I have my own list, but I won't disclose it before the paper is out.
>
> best regards
>
> Thorsten
>

  One thing that would be neat is a make_array template function, similar to
make_pair and make_tuple, that returns a tr1::array object.
    template <class X> array<X, 0> make_array();
    template <class X, class P1> array<X, 1> make_array(const P1 &p1);
    template <class X, class P1, class P2> array<X, 2> make_array(const P1
&p1, const P2 &p2);
etc.

This would interact very nicely with the new auto syntax, which seems likely
to make it into C++09

    auto array1 = make_array<string>("Foo", "Bar", "Glarch"); // type is
array<string, 3>
   auto array2 = make_array<double>(1, 2, 2.5, 3); //type is array<double,
4>

The paper that originally proposed tr1::array
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html)
mentioned that there was no way to parallel the automatic type deduction
seen in the code
    int x[] = {0, 1, 2, 3};

The make_array function together with auto would add that ability, albeit
with a new syntax.

Joe Gottman

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





Author: nesotto@cs.aau.dk ("Thorsten Ottosen")
Date: Wed, 17 Aug 2005 21:22:25 GMT
Raw View
""Joe Gottman"" <jgottman@carolina.rr.com> wrote in message
news:pvvMe.134235$3j2.4505031@twister.southeast.rr.com...
>
> ""Thorsten Ottosen"" <nesotto@cs.aau.dk> wrote in message

> > Let's hear your ideas.

>   One thing that would be neat is a make_array template function, similar
to
> make_pair and make_tuple, that returns a tr1::array object.
>     template <class X> array<X, 0> make_array();
>     template <class X, class P1> array<X, 1> make_array(const P1 &p1);
>     template <class X, class P1, class P2> array<X, 2> make_array(const P1
> &p1, const P2 &p2);
> etc.
>
> This would interact very nicely with the new auto syntax, which seems
likely
> to make it into C++09
>
>     auto array1 = make_array<string>("Foo", "Bar", "Glarch"); // type is
> array<string, 3>
>    auto array2 = make_array<double>(1, 2, 2.5, 3); //type is array<double,
> 4>
>
> The paper that originally proposed tr1::array
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1479.html)
> mentioned that there was no way to parallel the automatic type deduction
> seen in the code
>     int x[] = {0, 1, 2, 3};
>
> The make_array function together with auto would add that ability, albeit
> with a new syntax.

In the example above, one can use the normal { .... } syntax.
Mentioning the type is easier than with make_array, but
specifying the size is irritating. Then again, why not use a vector
if you don't want to specify the size?
(well, eficieny, but is that important here?)

If only we could avoid making N overloads of the function :-)

Another question is what the practical limit of the number of overloads
should be?

-Thorsten


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