Похоже, что увеличить размер объекта типа 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 оптимизации надо перекпроектировать структуры данных, то надо просто начинать другой проект.

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

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

Да, спасибо, похоже для C++ ничего невозможного нет.

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

LVV>В два раза — стОит. А полпроцента — нет.

Ну а если разработчиков 100 и у каждой части свой разработчик? Немаловероятно, что именно это обстоятельство вкупе с пропагандой избегания преждевременной оптимизации, приводит к тому, что некоторые современные приложения работают, мягко говоря, небыстро.

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

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

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

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

Обходить private — это слишком грязный хак, вместо которого правильнее было-бы написать свою реализацию. Да и постоянность private-компонентов никто не гарантирует.

Написать 2 раза по 10 строк это конечно существенный минус с точки зрения архитектуры(необходимо подстраиваться под компилятор,STL), но то, что в среднем дописывать код придется раз в ~15 лет полностью компенсирует данный недостаток. У меня основная платформа RedHat 4,5,6(в планах) и во всех перечисленных версиях необходимый protected-API std::vector'а одинаковый. А версия VC у меня одна — 2005 и в ближайшее время миграция на более новые не планируется.

В сумме получается, что да, отсутствие полиморфного удаления остается главным минусом. А если необходимо поддерживать множество версий компиляторов и STL, то конечно такое решение будет не совсем удачным.

P.S. Я всегда считал, что внутренняя реализация — это, то что находится в private, а protected только с очень большой натяжкой можно отнести к внутренней реализации, ведь protected-API напрямую доступно при наследовании. Или я не прав?

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

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

std::valarray<char>::resize тоже инициализирует новые элементы нулями, или есть другая возможность увеличения размера?

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

P>Обходить private — это слишком грязный хак, вместо которого правильнее было-бы написать свою реализацию. Да и постоянность private-компонентов никто не гарантирует.

В данном случае "постоянность" protected-компонентов — тоже никто не гарантирует (см. ниже).

P>P.S. Я всегда считал, что внутренняя реализация — это, то что находится в private, а protected только с очень большой натяжкой можно отнести к внутренней реализации, ведь protected-API напрямую доступно при наследовании. Или я не прав?

Прав в том смысле, что protected по-хорошему должен являться частью интерфейса, но интерфейс к сожалению не совсем формальное понятие, в данном случае он определяется стандартом, а там никаких protected членов нет.

I>std::valarray<char>::resize тоже инициализирует новые элементы нулями, или есть другая возможность увеличения размера?

ну вообще-то это все зависит от реализации.
Как известно если выделять память средствами типа mmap, то за счет использования MMU процессора обнуление страниц памяти можно получить без явной записи нулей (и в момент первого доступа к ним).
Так что даже достаточно продвинутая реализация vector<char> может быть способна не делать проход обнуления.

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

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

LVV>>В два раза — стОит. А полпроцента — нет.

I>Ну а если разработчиков 100 и у каждой части свой разработчик? Немаловероятно, что именно это обстоятельство вкупе с пропагандой избегания преждевременной оптимизации, приводит к тому, что некоторые современные приложения работают, мягко говоря, небыстро.
Наверное да. Может именно это подвигло Фаулера написать Рефакторинг.

On 19.02.2011 14:26, igna wrote:

> std::valarray<char>::resize тоже инициализирует новые элементы нулями, или есть
> другая возможность увеличения размера?

Блин, malloc. Чего ты привязался ко всем ?

On 19.02.2011 13:45, любой wrote:

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

Ага, и этот конструктор вызываться будет на каждый элемент.
Нулём затирание хотя бы встраивается.

MZ>Ага, и этот конструктор вызываться будет на каждый элемент.
MZ>Нулём затирание хотя бы встраивается.

вектор это ж шаблон, он точно так мже может инлайнить этот пустой конструктор, и оптимизатор может цикл вообще выкинуть

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

I>std::valarray<char>::resize тоже инициализирует новые элементы нулями, или есть другая возможность увеличения размера?

Посмотрел его исходники в 2010 студии — он всегда вызывает конструктор для своих элементов при выделении памяти.

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

MZ>Ага, и этот конструктор вызываться будет на каждый элемент.
В релизе конструктор соптимизируется.

MZ>Нулём затирание хотя бы встраивается.
Неа.

On 19.02.2011 16:03, любой wrote:

> MZ>Ага, и этот конструктор вызываться будет на каждый элемент.
> В релизе конструктор соптимизируется.

МОЖЕТ. А Может и нет.

> MZ>Нулём затирание хотя бы встраивается.
> Неа.

Хотите сказать, что функция настоящая генерируется ?

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

N>Посмотрел его исходники в 2010 студии — он всегда вызывает конструктор для своих элементов при выделении памяти.

Ну естественно, это же требование стандарта.

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

D>ну вообще-то это все зависит от реализации.
D>Как известно если выделять память средствами типа mmap, то за счет использования MMU процессора обнуление страниц памяти можно получить без явной записи нулей (и в момент первого доступа к ним).
D>Так что даже достаточно продвинутая реализация vector<char> может быть способна не делать проход обнуления.

"Достаточно продвинутая реализация" может даже заменить vector<char> на что-нибудь другое, только при чем тут это? В стандарте прописана инициализация, мой вопрос в том как ее избежать, причем избежать естественно за счет изменения программы, а не за счет применения некой "достаточно продвинутой реализации".

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

MZ>On 19.02.2011 13:45, любой wrote:

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

MZ>Ага, и этот конструктор вызываться будет на каждый элемент.
ты хочешь сказать, что сгернерированный релизный ассемблерный код хоть как-то будет отличаться для

std::vector<char> v;

и для сгенерированного компилятором

struct Char { char x; Char(){} };
std::vector<Char> v;

MZ>Нулём затирание хотя бы встраивается.

а для конструктора Char вообще встраивать нечего, ибо кода нету в принципе: тело пустое, члены не инициализируются.

You will always get what you always got
  If you always do  what you always did

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

J>ты хочешь сказать, что сгернерированный релизный ассемблерный код хоть как-то будет отличаться для

J>std::vector<char> v;

J>и для сгенерированного компилятором

J>struct Char { char x; Char(){} };
J>std::vector<Char> v;

J>

Думаю, что никаких гарантий того, что sizeof(Char) == 1 нет, я не прав?

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

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

J>>ты хочешь сказать, что сгернерированный релизный ассемблерный код хоть как-то будет отличаться для
I>

J>>std::vector<char> v;
I>

J>>и для сгенерированного компилятором
I>

J>>struct Char { char x; Char(){} };
J>>std::vector<Char> v;
I>

J>>

I>Думаю, что никаких гарантий того, что sizeof(Char) == 1 нет, я не прав?

Вот тебе гарантия:

BOOST_STATIC_ASSERT( sizeof(Char) == sizeof(char) );

You will always get what you always got
  If you always do  what you always did

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

J>Вот тебе гарантия:

J>BOOST_STATIC_ASSERT( sizeof(Char) == sizeof(char) );

То есть я прав. И на том спасибо.

-MyXa-:

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

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

Как думаешь, что, скорее всего, в данном случае делает используемая там реализация функции resize? Даю подсказку: http://codepad.org/k4VFEWb6

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

M>Как думаешь, что, скорее всего, в данном случае делает используемая там реализация функции resize? Даю подсказку: http://codepad.org/k4VFEWb6

А, да, я про это знал... раньше.
А зачем они так сделали?

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

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

M>>Как думаешь, что, скорее всего, в данном случае делает используемая там реализация функции resize? Даю подсказку: http://codepad.org/k4VFEWb6

MX>А, да, я про это знал... раньше.
MX>А зачем они так сделали?

Может потомучто, думают что скопировать данные быстрее чем сгенерировать/создать новые

Пример в конструкторе ктото написал загрузку текстуры с фаила, что лучше скопировать буфер, или открывать заного Н раз?

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

IRO>Может потомучто, думают что скопировать данные быстрее чем сгенерировать/создать новые

IRO>Пример в конструкторе ктото написал загрузку текстуры с фаила, что лучше скопировать буфер, или открывать заного Н раз?

Оно, конечно, да, 42 легче скопировать, чем заново считать.