Похоже, что увеличить размер объекта типа std::vector<char> без инициализации его новых элементов нулем нельзя. Это так или есть все же такая возможность?

Здравствуйте, igna, Вы писали:

I>Похоже, что увеличить размер объекта типа std::vector<char> без инициализации его новых элементов нулем нельзя. Это так или есть все же такая возможность?

А замем вам такая возможность? Заботитесь о производительности?

I>Похоже, что увеличить размер объекта типа std::vector<char> без инициализации его новых элементов нулем нельзя. Это так или есть все же такая возможность?
если мои догадки верны, то вам наверно нужен reserve

Здравствуйте, ZegSoft, Вы писали:

ZS>А замем вам такая возможность? Заботитесь о производительности?

Да.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, ZegSoft, Вы писали:

ZS>>А замем вам такая возможность? Заботитесь о производительности?

I>Да.
Это имеет смысл если у вас циклы по нескольку миллиардов раз с векторами по нескольку миллионов элементов.
Например, у меня матрица размером 10000*10000 = 100 000 000 элементов. Цикл выполняется несколько тысяч миллиардов раз (триллионы, что ли? ) — тут эффективность критична. Ибо, если не принимать мер, считает сутками.

Здравствуйте, ononim, Вы писали:

O>если мои догадки верны, то вам наверно нужен reserve

Нет, потому-что заполнять этот vector будет C функция, которой будут переданы &my_vector.front() и my_vector.size(). Если вместо последнего передать my_vector.capacity() и вызвать my_vector.resize() после вызова C функции, будет еще хуже, значения попросту перезапишутся нулями.

Здравствуйте, LaptevVV, Вы писали:

LVV>Это имеет смысл если у вас циклы по нескольку миллиардов раз с векторами по нескольку миллионов элементов.

Вот-вот, именно тот случай.

Здравствуйте, igna, Вы писали:

O>>если мои догадки верны, то вам наверно нужен reserve

I>Нет, потому-что заполнять этот vector будет C функция, которой будут переданы &my_vector.front() и my_vector.size(). Если вместо последнего передать my_vector.capacity() и вызвать my_vector.resize() после вызова C функции, будет еще хуже, значения попросту перезапишутся нулями.

а свой лисапед нельзя сделать?

Здравствуйте, night beast, Вы писали:

NB>а свой лисапед нельзя сделать?

Можно, но вероятно я все же использую scoped/shared_array, несмотря на то, что размер придется передавать отдельно.

Здравствуйте, igna, Вы писали:

I>Похоже, что увеличить размер объекта типа std::vector<char> без инициализации его новых элементов нулем нельзя. Это так или есть все же такая возможность?

Штатными средствами этого сделать нельзя. Я недавно сталкивался с подобной задачей и оказалось, что во всех необходимых мне компиляторах (GCC, MSVS) в реализациях STL указатели на внутренние данные std::vector находятся в секции protected, что позволило унаследоваться от std::vector и реализовать недостающий функционал в виде нового метода, тело которого индивидуально для каждого компилятора. Минус такого решения в том, что у вектора не виртуальный деструктор и по этому нужно следить за недопустимостью полиморфного удаления нового контейнера.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, LaptevVV, Вы писали:

LVV>>Это имеет смысл если у вас циклы по нескольку миллиардов раз с векторами по нескольку миллионов элементов.

I>Вот-вот, именно тот случай.
У меня подобная решетка обнуляется за 1.5-2 секунды: v.assign(L*L, 0); При L = 10000
Ноут АСУС, процессор двухядерный, памяти 2 гига.
По моим наблюдениям при L = 16000 все еще хорошо работает.

Здравствуйте, igna, Вы писали:

I>Похоже, что увеличить размер объекта типа std::vector<char> без инициализации его новых элементов нулем нельзя. Это так или есть все же такая возможность?

Если очень нужно, можно вместо char использовать специальный класс с ничего не делающим конструктором без параметров и конструкторами/операторами преобразований к/из char.

Здравствуйте, phprus, Вы писали:

P>Штатными средствами этого сделать нельзя. Я недавно сталкивался с подобной задачей и оказалось, что во всех необходимых мне компиляторах (GCC, MSVS) в реализациях STL указатели на внутренние данные std::vector находятся в секции protected, что позволило унаследоваться от std::vector и реализовать недостающий функционал в виде нового метода, тело которого индивидуально для каждого компилятора. Минус такого решения в том, что у вектора не виртуальный деструктор и по этому нужно следить за недопустимостью полиморфного удаления нового контейнера.

Если бы это был единственный или хотя бы главный минус! Твое решение привязано к конкретной версии библиотеки, тебе ведь два раза пришлось его писать, для GCC и для VC? И между прочим protected или нет, приципиальной роли не играет, с тем же успехом ты мог бы и private обойти; суть-то ведь одна: ты положился на внутренности реализации.

Здравствуйте, любой, Вы писали:

Л>Если очень нужно, можно вместо char использовать специальный класс с ничего не делающим конструктором без параметров и конструкторами/операторами преобразований к/из char.

Хм, спасибо, интересное решение. Вряд ли я буду делать так, но действительно интересно.

Здравствуйте, LaptevVV, Вы писали:

LVV>У меня подобная решетка обнуляется за 1.5-2 секунды: v.assign(L*L, 0); При L = 10000
LVV>Ноут АСУС, процессор двухядерный, памяти 2 гига.
LVV>По моим наблюдениям при L = 16000 все еще хорошо работает.

Так, то есть все же меняем тему. Хорошо, у меня свое мнение по поводу преждевременной оптимизации. Я вот недавно внес одно (добавляющее функциональность) изменение в программу замедлившее ее на 1%. Вроде оно и ладно, оставил пока так, хотя там точно есть возможность для оптимизации и надо будет к этому вернуться и хотя бы померять. Если окажется, что за счет оптимизации замедление программы (с добавленной функциональностью) будет не на 1%, а на 0,5%, то стоит ли этой отимизацией заниматься?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, LaptevVV, Вы писали:

LVV>>У меня подобная решетка обнуляется за 1.5-2 секунды: v.assign(L*L, 0); При L = 10000
LVV>>Ноут АСУС, процессор двухядерный, памяти 2 гига.
LVV>>По моим наблюдениям при L = 16000 все еще хорошо работает.

I>Так, то есть все же меняем тему. Хорошо, у меня свое мнение по поводу преждевременной оптимизации. Я вот недавно внес одно (добавляющее функциональность) изменение в программу замедлившее ее на 1%. Вроде оно и ладно, оставил пока так, хотя там точно есть возможность для оптимизации и надо будет к этому вернуться и хотя бы померять. Если окажется, что за счет оптимизации замедление программы (с добавленной функциональностью) будет не на 1%, а на 0,5%, то стоит ли этой отимизацией заниматься?
Однозначно — не стОит...

Здравствуйте, igna, Вы писали:

I>Похоже, что увеличить размер объекта типа std::vector<char> без инициализации его новых элементов нулем нельзя. Это так или есть все же такая возможность?

Пока писАл, тут уже ответили.

Здравствуйте, igna, Вы писали:

I>Вот-вот, именно тот случай.

Я в вычислительных задачах забил на std::vector и использую std::valarray. С индексами работает гораздо быстрей, чем вектор, что с индексами, что с итераторами.

Здравствуйте, LaptevVV, Вы писали:

LVV>Однозначно — не стОит...

Так ли уж однозначно? А если программа состоит из равных по времени выполнения ста частей, ускорив любую из них в два раза получаем выгоду в полпроцента, а ускорив все сто — в два раза, тоже не стоит?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, LaptevVV, Вы писали:

LVV>>Однозначно — не стОит...

I>Так ли уж однозначно? А если программа состоит из равных по времени выполнения ста частей, ускорив любую из них в два раза получаем выгоду в полпроцента, а ускорив все сто — в два раза, тоже не стоит?
В два раза — стОит. А полпроцента — нет.
Тут же еще вопрос: сколько вашего времени это займет. Если день-два-неделю, то вполне может быть. А если lzk оптимизации надо перекпроектировать структуры данных, то надо просто начинать другой проект.