Здравствуйте, -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