2015-11-09 14:59 GMT-03:00 Nicolás Alvarez <[email protected]>:
> 2015-11-09 14:28 GMT-03:00 Christian Beer <[email protected]>:
>> this is another one of the High impact defects that has a simple fix and
>> where I'm not sure if this is really the intended behavior. All the code
>> that uses work_items points to this solution which seems strange because
>> it creates a new DB_WORK_ITEM object, copies it into the vector and then
>> destroys the original object. The alternative would be to have a vector
>> of pointers to DB_WORK_ITEM objects but for this, one has to change the
>> code in scan_work_array() too.
>
> That is how vectors have to be used in C++98, there is no other way.
> Either you copy an object into it and destroy the original if you
> don't need it for something else, or you make a vector of pointers.
>
> In C++11 you have more alternatives. You can std::move an object into
> the vector, or you can use vector.emplace_back to construct the object
> in-place inside the vector.
Hooold on. I hadn't seen the linked patch.
for (int i=0; i<napps; i++) {
DB_WORK_ITEM* wi = new DB_WORK_ITEM();
work_items.push_back(*wi);
delete wi;
}
That makes no sense. Why dynamically allocate the object if it's just
temporary? You can just do this:
for (int i=0; i<napps; i++) {
DB_WORK_ITEM wi;
work_items.push_back(wi);
}
But wait, if the DB_WORK_ITEM doesn't need arguments passed to the
constructor (ie. you're adding default-constructed objects), you don't
even need a loop!
work_items.resize(napps);
--
Nicolás
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
