«

Christian Hackl <> wrote:
>> Exactly how does it go against "experience and common sense"?
>
> It goes against experience because std::vector is used more often than
> other containers.

I'm sorry, but I have hard time understanding how "it's more commonly
used" is an argument for std::vector being the correct substitute and
std::deque being the incorrect one. Popularity is not a measurement of
correctness. That's a fallacy.

> It goes against common sense because std::deque's
> ability of growing in both directions is obviously a special requirement.

The ability of std::vector to grow at all is against "common sense"
because basic arrays can't grow. std::vector adds the capability of
growing the array by adding to the end in constant time, which is
something you can't do out-of-the-box with basic arrays. So that's
something where std::vector already differs from basic arrays.

std::deque additionally gives the possiblity of adding elements to
the beginning in constant time. Why does that make it a "non-array"?
Why is adding to the end ok, but adding to the beginning not?

So no, std::vector doesn't make any more sense than std::deque does.

> And of course, you cannot pass a std::deque to a C function usig &d[0]
> and d.size(), while you can do this with a std::vector, which only
> strengthens the point that vectors are designed as the array replacement
> of C++.

I thought you wanted to distance the beginner from such low-level stuff
and teach higher-level constructs instead.

> A std::deque has slower element access. How is element access less
> important than inserting elements at the beginning?

So using premature optimization as an argument is ok when it makes
std::vector look good, but it's bad when it's used to make basic arrays
look good? You yourself argued that the efficiency arguments for basic
arrays are just "premature optimization". Now you are arguing in favor
of std::vector using the same kind of argument.

> Of course, it won't make any difference for a beginner, but again: why
> expose him to a special container type instead of simply starting with
> the most general and most used, which is std::vector?

What would be wrong in teaching different alternatives and explain their
strengths and weaknesses, and where they are useful and where something
else would be better? A person can learn such things relatively easily,
and claiming otherwise is a bit patronizing, IMO.

James Kanze <>, on 25/08/2010 04:20:23, wrote:

> On Aug 24, 3:35 pm, "Francesco S. Carta"<entul...@gmail.com> wrote:
>> Laurel Shimer<laurelshi...@gmail.com>, on 23/08/2010 15:23:29, wrote:
>
>> <questions about managing raw arrays>
>
>> I wonder why nobody pointed out that we can simply wrap raw arrays into
>> a template in order to bring along their sizes, and we can do that quite
>> easily too.
>
> You mean std::array, from C++0x (or tr1::array, before that).

I just meant any wrapped array that fits. Now I can specify that it
could be either existing or quickly tailored to the needs where
possible, std::array wasn't exactly in my mind when I wrote the above.

> Note that any solution involves compromizes. It's far from
> trivial to come up with the "correct" solution. (In fact, one
> should probably say *a* correct solution, since depending on
> what you want, the correct solution might not be the same.)
>
>> It took me way more time to come up with the silly test case than to
>> write the actual wrapper:
>
>> //-------
>> // in some header or hidden in an implementation file
>> // with fitting explicit instantiations in an appropriate header
>> // (or maybe exported, if you're lucky)
>> // this can be, of course, widely extended and improved
>
>> template<class T, int SIZE> class Array {
>> public:
>> T& operator[](int index) {
>> return data[index];
>> }
>> const T& operator[](int index) const {
>> return data[index];
>> }
>> int size() const {
>> return SIZE;
>> }
>> private:
>> T data[SIZE];
>> };
>
> This is interesting. You can't actually instantiate it unless
> T has a default constructor, and all of the data are initialized
> using the default constructor.

Well, I said it could be improved... I don't know if what you mention
below is achievable with the current standard, though... is it?

> Probably the most important single reason for using a C style
> array is the aggregate initialization sequence, and the fact
> that it can have fully static initialization. (std::array
> preserves this quality.)

As I said somewhere else, the upcoming standard is not exactly fully in
my mental toolbox, but what you mention about std::array is definitely
good to know.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com

* Francesco S. Carta, on 25.08.2010 14:48:
> James Kanze <>, on 25/08/2010 04:20:23, wrote:
>
>> On Aug 24, 3:35 pm, "Francesco S. Carta"<entul...@gmail.com> wrote:
>>> Laurel Shimer<laurelshi...@gmail.com>, on 23/08/2010 15:23:29, wrote:
>>
>>> <questions about managing raw arrays>
>>
>>> I wonder why nobody pointed out that we can simply wrap raw arrays into
>>> a template in order to bring along their sizes, and we can do that quite
>>> easily too.
>>
>> You mean std::array, from C++0x (or tr1::array, before that).
>
> I just meant any wrapped array that fits. Now I can specify that it
> could be either existing or quickly tailored to the needs where
> possible, std::array wasn't exactly in my mind when I wrote the above.
>
>> Note that any solution involves compromizes. It's far from
>> trivial to come up with the "correct" solution. (In fact, one
>> should probably say *a* correct solution, since depending on
>> what you want, the correct solution might not be the same.)
>>
>>> It took me way more time to come up with the silly test case than to
>>> write the actual wrapper:
>>
>>> //-------
>>> // in some header or hidden in an implementation file
>>> // with fitting explicit instantiations in an appropriate header
>>> // (or maybe exported, if you're lucky)
>>> // this can be, of course, widely extended and improved
>>
>>> template<class T, int SIZE> class Array {
>>> public:
>>> T& operator[](int index) {
>>> return data[index];
>>> }
>>> const T& operator[](int index) const {
>>> return data[index];
>>> }
>>> int size() const {
>>> return SIZE;
>>> }
>>> private:
>>> T data[SIZE];
>>> };
>>
>> This is interesting. You can't actually instantiate it unless
>> T has a default constructor, and all of the data are initialized
>> using the default constructor.
>
> Well, I said it could be improved... I don't know if what you mention
> below is achievable with the current standard, though... is it?
>
>> Probably the most important single reason for using a C style
>> array is the aggregate initialization sequence, and the fact
>> that it can have fully static initialization. (std::array
>> preserves this quality.)
>
> As I said somewhere else, the upcoming standard is not exactly fully in
> my mental toolbox, but what you mention about std::array is definitely
> good to know.

All you have to do support instantiation is to remove the access specifiers.

That turns your class into an aggregate class, which can be initialized by curly
braces syntax in C++98.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

Alf P. Steinbach /Usenet <alf.p.steinbach+>, on
25/08/2010 16:09:10, wrote:

> * Francesco S. Carta, on 25.08.2010 14:48:
>> James Kanze <>, on 25/08/2010 04:20:23, wrote:
>>
>>> On Aug 24, 3:35 pm, "Francesco S. Carta"<entul...@gmail.com> wrote:
>>>> Laurel Shimer<laurelshi...@gmail.com>, on 23/08/2010 15:23:29, wrote:
>>>
>>>> <questions about managing raw arrays>
>>>
>>>> I wonder why nobody pointed out that we can simply wrap raw arrays into
>>>> a template in order to bring along their sizes, and we can do that
>>>> quite
>>>> easily too.
>>>
>>> You mean std::array, from C++0x (or tr1::array, before that).
>>
>> I just meant any wrapped array that fits. Now I can specify that it
>> could be either existing or quickly tailored to the needs where
>> possible, std::array wasn't exactly in my mind when I wrote the above.
>>
>>> Note that any solution involves compromizes. It's far from
>>> trivial to come up with the "correct" solution. (In fact, one
>>> should probably say *a* correct solution, since depending on
>>> what you want, the correct solution might not be the same.)
>>>
>>>> It took me way more time to come up with the silly test case than to
>>>> write the actual wrapper:
>>>
>>>> //-------
>>>> // in some header or hidden in an implementation file
>>>> // with fitting explicit instantiations in an appropriate header
>>>> // (or maybe exported, if you're lucky)
>>>> // this can be, of course, widely extended and improved
>>>
>>>> template<class T, int SIZE> class Array {
>>>> public:
>>>> T& operator[](int index) {
>>>> return data[index];
>>>> }
>>>> const T& operator[](int index) const {
>>>> return data[index];
>>>> }
>>>> int size() const {
>>>> return SIZE;
>>>> }
>>>> private:
>>>> T data[SIZE];
>>>> };
>>>
>>> This is interesting. You can't actually instantiate it unless
>>> T has a default constructor, and all of the data are initialized
>>> using the default constructor.
>>
>> Well, I said it could be improved... I don't know if what you mention
>> below is achievable with the current standard, though... is it?
>>
>>> Probably the most important single reason for using a C style
>>> array is the aggregate initialization sequence, and the fact
>>> that it can have fully static initialization. (std::array
>>> preserves this quality.)
>>
>> As I said somewhere else, the upcoming standard is not exactly fully in
>> my mental toolbox, but what you mention about std::array is definitely
>> good to know.
>
> All you have to do support instantiation is to remove the access
> specifiers.
>
> That turns your class into an aggregate class, which can be initialized
> by curly braces syntax in C++98.

So you mean something like this:

//-------

#include <iostream>

template <class T, int SIZE> struct Array {
T data[SIZE];
T& operator[](int index) {
return data[index];
}
const T& operator[](int index) const {
return data[index];
}
int size() const {
return SIZE;
}
};

using namespace std;

int main() {
Array<int, 5> arr = {{1, 2, 3, 4, 5}};
for(int i = 0; i < arr.size(); ++i) {
cout << arr[i] << endl;
}
return 0;
}

//-------

Very good, thanks for your note Alf!

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com

Christian Hackl <> wrote:
> At my university, we had a beginner's course in which C++ was taught
> like this. char*, arrays and the particularities of unions were
> introduced in great detail, and when STL containers were finally
> introduced (in less detail than all the other material) the students'
> reaction was -- understandably -- along the lines of "what I do I need
> all this extra stuff for"? A few years later, when I was a teaching
> assistent in a more advanced course, I noticed that many students would
> not unlearn those bad habits and were still reluctant to use the
> standard library or try Boost components rather than continue to write C
> with Classes (which was obviously perceived the "simpler" way of using C++).

The problem is that they started with a low-level construct and taught
is at the main data container, and only much later taught alternatives.

You are proposing, basically, the same thing: Teach std::vector as the
basic construct and then maybe much later basic arrays. Thus the effect
will usually be the same: Students will often be reluctant to use basic
arrays and will always use std::vector, even in situations where it
causes significant performance degradation.

What I was proposing was teaching them *at the same time*, explaining
their properties, advantages and disadvantages, and when one or the other
is better.

[Please do not mail me a copy of your followup]

James Kanze <> spake the secret code
<ee08eb9a-8287-41f8-95cb-> thusly:

>Still, [C arrays are] for special uses (most of mine are const); for
>general work, std::vector is the choice, even if you're not
>going to be adjusting the size once it has been constructed.

Agreed.

>> sizeof() is what you want to tell you the size of a fixed-size
>> array, i.e. sizeof(array_)/sizeof(array_[0])
>
>For that, I use the template function size (which will cause
>a compiler error, rather than a wrong value, if invoked on
>a pointer.

Is this your own recipe, or is it in std or boost?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

* Richard, on 26.08.2010 19:50:
> [Please do not mail me a copy of your followup]
>
> James Kanze<> spake the secret code
> <ee08eb9a-8287-41f8-95cb-> thusly:
>
>> Still, [C arrays are] for special uses (most of mine are const); for
>> general work, std::vector is the choice, even if you're not
>> going to be adjusting the size once it has been constructed.
>
> Agreed.
>
>>> sizeof() is what you want to tell you the size of a fixed-size
>>> array, i.e. sizeof(array_)/sizeof(array_[0])
>>
>> For that, I use the template function size (which will cause
>> a compiler error, rather than a wrong value, if invoked on
>> a pointer.
>
> Is this your own recipe, or is it in std or boost?

It's a set of related functions, and they're not in std or boost.

Not sure but I think first designed by Dietmar Kuhl.

One nice implementation at <url:
http://alfps.wordpress.com/2010/05/10/how-to-avoid-disastrous-integer-wrap-around/>.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

On 26/08/2010 19.57, Alf P. Steinbach /Usenet wrote:
> * Richard, on 26.08.2010 19:50:
>> [Please do not mail me a copy of your followup]
>>
>> James Kanze<> spake the secret code
>> <ee08eb9a-8287-41f8-95cb-> thusly:
>>
>>> Still, [C arrays are] for special uses (most of mine are const); for
>>> general work, std::vector is the choice, even if you're not
>>> going to be adjusting the size once it has been constructed.
>>
>> Agreed.
>>
>>>> sizeof() is what you want to tell you the size of a fixed-size
>>>> array, i.e. sizeof(array_)/sizeof(array_[0])
>>>
>>> For that, I use the template function size (which will cause
>>> a compiler error, rather than a wrong value, if invoked on
>>> a pointer.
>>
>> Is this your own recipe, or is it in std or boost?
>
> It's a set of related functions, and they're not in std or boost.
>
> Not sure but I think first designed by Dietmar Kuhl.

I think I learned it from some of his code, too. IIRC that was
around 1999 (big caveat: I don't have a good memory ) and it
was the version that allows getting a compile-time constant
(returning a reference to an array, and to be used in
conjunction with sizeof --and never defined).

In my code, I decided to give up on the constant expression
requirement:

<http://breeze.svn.sourceforge.net/viewvc/breeze/trunk/breeze/counting/>

and I know that James does the same. Of course in C++0x you
could add a constexpr.

At a point, I even wrote a version that gives a constant
expression and also works for multi-dimensional arrays (gives
the count of any projection). And I even managed to make it work
with VC++6 But, of course, there's a difference between
experiments and production code (something that Boost should
definitely learn).

--
Gennaro Prota | I'm available for your projects.
Breeze (preview): <https://sourceforge.net/projects/breeze/>

On Aug 26, 6:50 pm, legalize+jee...@mail.xmission.com (Richard) wrote:
> James Kanze <james.ka...@gmail.com> spake the secret code
> <ee08eb9a-8287-41f8-95cb-e72a404b0...@5g2000yqz.googlegroups.com>
> thusly:

[...]
> >> sizeof() is what you want to tell you the size of a fixed-size
> >> array, i.e. sizeof(array_)/sizeof(array_[0])
>
> >For that, I use the template function size (which will cause
> >a compiler error, rather than a wrong value, if invoked on
> >a pointer.
>
> Is this your own recipe, or is it in std or boost?

It's not my own recipe, since I'd heard about it long before I
actually started using it. I forget who I heard it from,
however, but the idea has been floating around a long time.

--
James Kanze