Closed Bug 318625 Opened 19 years ago Closed 19 years ago

Add nsTArray.AppendElement() that doesn't copy-construct

Categories

(Core :: XPCOM, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

Attachments

(1 file, 1 obsolete file)

When doing bug 316416 darin and I found that we wanted to avoid copy-construction when appending nsTArray elements. A new signature elem_type* AppendElement() will construct a new element in place.
Attached patch AppendElement(), rev. 1 (obsolete) — Splinter Review
Attachment #204734 - Flags: review?(darin)
Comment on attachment 204734 [details] [diff] [review] AppendElement(), rev. 1 >Index: xpcom/glue/nsTArray.h >+ // Append a new element without constructing. This is useful to avoid >+ // extra temporaries. >+ elem_type* AppendElement() { >+ if (!EnsureCapacity(Length() + 1, sizeof(elem_type))) >+ return nsnull; >+ elem_type* elem = new (Elements() + Length()) elem_type(); >+ ++mLength; >+ return elem; >+ } I think this should use "elem_traits::Construct" so that we can could specialize nsTArrayElementTraits<E> as needed. Also, how about adding a similar version of InsertElementAt? Please document the return value.
Attachment #204734 - Flags: review?(darin) → review-
Attachment #204734 - Attachment is obsolete: true
Attachment #204752 - Flags: review?(darin)
Comment on attachment 204752 [details] [diff] [review] AppendElement(), rev. 2 >Index: xpcom/glue/nsTArray.h >+ nsTArrayElementTraits<E>::Construct(elem); I wrote elem_traits::Construct for a reason! ;-) Please change the code accordingly. r=darin
Attachment #204752 - Flags: review?(darin) → review+
Bah, reading all those pretty typedefs is easier than writing them. Fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: