Summary: | resize initializes whole array | ||
---|---|---|---|
Product: | gcc | Reporter: | Theo Bosman <theo.bosman> |
Component: | libstdc++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | fang, gcc-bugs, gdr, paolo.carlini |
Priority: | P3 | ||
Version: | 3.3.5 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: |
Description
Theo Bosman
2006-11-02 13:17:52 UTC
I do not have Stroustrup at hand, but certainly the ISO C++ Standard 2003, the real reference for our work (we are implementing it), says, in 26.3.2.7/9, that resize first changes the length of *this to sz and then assigns to each element the value of the second argument. It also says that the operation invalidates all pointers and references to elements in the array, thus, the meaning is clear and our implementation is 100% conforming. The only possible change I can see, as an optimization, is using __valarray_fill instead of __valarray_destroy_elements and __valarray_fill_construct, when _M_size == __n. Let's ask Gaby... Subject: Re: resize initializes whole array There is no argument against the ISO standard, but to a non C/C++ programmer it seems a waist of time to reallocate the array and initialize it when one wants to add something to an array. Some other compilers will copy the existing data into the newly allocated space which seems more in line with the text book. The application will be changed to avoid the loss of data on a resize of arrays, which is a better idea anyway. Thanks for the speedy reply. Theo Bosman ----- Original Message ----- From: "pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> To: <theo.bosman@net.HCC.nl> Sent: Thursday, November 02, 2006 2:51 PM Subject: [Bug libstdc++/29688] resize initializes whole array > > > ------- Comment #2 from pcarlini at suse dot de 2006-11-02 13:51 ------- > The only possible change I can see, as an optimization, is using > __valarray_fill instead of __valarray_destroy_elements and > __valarray_fill_construct, when _M_size == __n. Let's ask Gaby... > > > -- > > pcarlini at suse dot de changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |pcarlini at suse dot de, > gdr > | |at integrable-solutions > dot > | |net > Status|RESOLVED |UNCONFIRMED > Resolution|INVALID | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > (In reply to comment #3) > Subject: Re: resize initializes whole array > > There is no argument against the ISO standard, but to a non C/C++ programmer > it seems a waist of time to reallocate the array and initialize it when one > wants to add something to an array. Some other compilers will copy the > existing data into the newly allocated space which seems more in line with > the text book. I don't know. We are definitely implementing the ISO C++ Standard, and, by the way, many details in Stroustrup' books, predating the Standard, are know to be slightly different. I will also add that valarray is *very* special - its design was motivated by considerations of highest performance on superscalar architectures, etc. - for example vector::resize behaves in a completely different way, which probably you like better. > The application will be changed to avoid the loss of data on a resize of > arrays, which is a better idea anyway. Thanks for the speedy reply. For portability, that is the safe thing to do, yes, I agree. > There is no argument against the ISO standard, but to a non C/C++ programmer
> it seems a waist of time to reallocate the array and initialize it when one
> wants to add something to an array. Some other compilers will copy the
> existing data into the newly allocated space which seems more in line with
> the text book.
> The application will be changed to avoid the loss of data on a resize of
> arrays, which is a better idea anyway. Thanks for the speedy reply.
If you really want efficient appending to a dynamically allocated array, then use std::vector, which is capable of pre-allocating more memory than the number of elements, using the reserve() member function. From looking in the implementation, N push_back operations result in lg N reallocations, by doubling the reserve size each time the capacity is exceeded. vector achieves this by tracking three pointers: beginning, end-of-elements (size), end-of-storage (capacity). valarray is lighter-weight, having only two pointers, beginning- and end-of-storage; thus it must reallocate upon resize (otherwise, how could size() be reported correctly?). I'd only use valarray when the sizeof(container) is crucial and/or the size of the container is unlikely/infrequently to change at run-time.
I have analized in detail the case at issue (resize to the same size of the current one) and came to the conclusion that trying to optimize for it (at the cost of increasing the size of the inlined function) isn't really worth the trouble, taking also into account that for PODs __valarray_destroy_elements is already optimized out. |