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

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

MN>>>>деле фигня и где-то их на самом деле разводят (сам такой же — каюсь) .
Doc>>>А расскажите в чем развод STL? Очень уж интересно
LM>>В том, что это как наркотик. Разок попробуешь и ....
E>Странно. Сколько не пробую, всё равно не подспживаюсь
Смешай с бустом в пропорции 2 к 1

Doc>А расскажите в чем развод STL? Очень уж интересно

В нереентерабельности кода. STL — это как садово-парковый лабиринт, очень извилистый и длинный, но без развилок Знай, иди себе вперед и вперед, а все идущие в нем — идут гуськом, в колонну по одному.

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

К>В нереентерабельности кода.
Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном использовании".

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

Doc>Здравствуйте, Mr. None, Вы писали:

MN>>деле фигня и где-то их на самом деле разводят (сам такой же — каюсь) .
Doc>А расскажите в чем развод STL? Очень уж интересно
В том, что это как наркотик. Разок попробуешь и ....

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

Doc>>>>А расскажите в чем развод STL? Очень уж интересно
LM>>>В том, что это как наркотик. Разок попробуешь и ....
E>>Странно. Сколько не пробую, всё равно не подспживаюсь
LM>Смешай с бустом в пропорции 2 к 1

Не, не выйдет, от этой смеси сразу резко тошнит

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

MN>>>2. Интерфейсы.
MN>>>

MN>>>std::transform(it->begin(), it->begin() + commandEnd,
MN>>>    cmd.begin(),
MN>>>    std::bind2nd(std::ptr_fun(toupper_wrap), &loc));
MN>>>

MN>>>Это ещё достаточно простая комбинация. Для меня эта запись выглядит понятной, но я встречал людей, которых она вгоняла в такой ступор... А уж если надо написать свой функтор (но это уже больше относится к 3-ему пункту).

A>В ступор этот код вогнать конечно может. Но только человека плохо знающего stl.
По-моему, использование тривиальных STL-алгоритмов (вроде for_each или transform) ухудшает код.
Во-первых, такой код превращается в тайнопись для избранных и рискует стать write-only (это сейчас понятно, а через пару лет будет непонятно, и тогда проще переписать, чем понять).
Во-вторых, нельзя писать функтор по месту использования – теряется локальность кода (вспоминаю Pascal: переменная объявлена в одном месте, а используется совсем в другом; приходится постоянно метаться между двумя этими местами). Неудобно использовать в функторе локальные переменные, лежащие рядом с вызовом STL-алгоритма (приходится пихать ссылки в функтор). Архитектура программы захламляется мелочными искусственными функтор-классами (мои понятия: если название класса – не существительное, то класс искусственный).
В-третьих, снижается эффективность программы (вместо статического вызова loc.toupper_wrap(…) делается динамический вызов; это плохо для cache-а, особенно в цикле).
В-четвёртых, код с функторами сложнее отлаживать.

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

C>Здравствуйте, Кондыбас, Вы писали:

К>>В нереентерабельности кода.
C>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном использовании".
Нет... Повторная входимость рекурсии — это частный случай...
Реентерабильный — повторно-входимый...
Понятие возникло в начале 60-х годов в операционных системах...
Повторная входимость — это использование ОДНОЙ КОПИИ программы (вместие с памятью для переменных) для нескольких процессов. Естесственно, код программы в процессе работы не должен изменяться — это раз. Второе — для переменных программы новый процесс должен получать новую память...

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

Doc>А расскажите в чем развод STL? Очень уж интересно

Развод в нереентерабельности кода. Это как садово-парковый лабиринт, очень длинный и извилистый, но без развилок. По нему можно идти только прямо, гуськом, в колонну по одному. Из недостатков — скучно. Из преимуществ — не заблудишься.

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

C>Здравствуйте, Кондыбас, Вы писали:

К>>В нереентерабельности кода.
C>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном использовании".

Ммм... Реинтерабельный — повторно входимый. Это значит, что если этот код выполняется в данный момент, его можно запустить снова и ничего не сломается, всё будет работать. Запустить можно в другой нити, например. Рекурсия, мне кажется, не всегда может быть реинтерабельна.

Аноним wrote:

> Ммм... Реинтерабельный — повторно входимый. Это значит, что если этот
А можно пример? Что именно в stl не такое и какое должно быть?

> код выполняется в данный момент, его можно запустить снова и ничего не
> сломается, всё будет работать. Запустить можно в другой нити, например.
Это называется Multithread Safe Code.

> Рекурсия, мне кажется, не всегда может быть реинтерабельна.

Аноним wrote:
> C>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном
> использовании".
> Ммм... Реинтерабельный — повторно входимый. Это значит, что если этот
> код выполняется в данный момент, его можно запустить снова и ничего не
> сломается, всё будет работать.
А как ты можешь запустить уже работающий код? Правильно, рекурсией

> Запустить можно в другой нити, например.
Нет. Это связанные, но не эквивалентные понятия.

Например, код, использующий thread local storage, будет
потокобезопасным, но не реентерабельным.

> Рекурсия, мне кажется, не всегда может быть реинтерабельна.
Эта... Рекурсия — она по определению "реентерабельна".

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

MN>>>деле фигня и где-то их на самом деле разводят (сам такой же — каюсь) .
Doc>>А расскажите в чем развод STL? Очень уж интересно
LM>В том, что это как наркотик. Разок попробуешь и ....

Странно. Сколько не пробую, всё равно не подспживаюсь

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

_>А можешь привести пример функции, безопасной при рекурсивном использовании но не реентерабельной? Или реентерабельной но
_>не безопасной при рекурсивном использовании?

Процедура, строящая рекурсивно дерево по некоторому закону. Корень хранится в глобальной переменной.
Не-Реентербалельность заключается в том, что следующая "сессия" будет использовать тот же корень. Т.е. либо затрет уже готовый результат первой сессии, либо присоединится к этим результатам (в зависимости от кода).

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

MN>деле фигня и где-то их на самом деле разводят (сам такой же — каюсь) .

А расскажите в чем развод STL? Очень уж интересно

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

К>>В нереентерабельности кода.
C>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном использовании".

Реентерабельность — возможность рекурсивного вхождения. Если рекурсивно вызовешь нереентерабельный код, то получишь лажу В смысле — вызвать-то вызовешь, результату будешь не рад.

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

К>>>В нереентерабельности кода.
C>>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном использовании".
D> Реентерабельность — возможность рекурсивного вхождения. Если рекурсивно вызовешь нереентерабельный код, то получишь лажу В смысле — вызвать-то вызовешь, результату будешь не рад.
А чем это отличается от того, что я сказал?

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

Doc>Здравствуйте, Mr. None, Вы писали:

MN>>деле фигня и где-то их на самом деле разводят (сам такой же — каюсь) .

Doc>А расскажите в чем развод STL? Очень уж интересно

Н-да... Не думал, что моя шутка породит такую дискуссию... В пору уже отделять в "Священные войны".
А тепрь конкретика, никакую реентерабельность или потоко-безопасность я не имел в виду. Это вообще отдельная песня и не многие библиотеки, обладают 3-мя качествами одновременно: потоко-безопасность, универсальность и эффективность. Чем-то одним приходится жертвовать...
Stl удобен, для тех кто его знает и умеет им пользоваться, а это очень и очень не просто. Не мне судить, но как человек, знающий его относительно хорошо (скажем так на 4-ку, думаю даже с плюсом — скромность не позволяет выставить оценку выше ), могу сказать: некоторые вещи можно было сделать по проще и по понятнее. Это касается и нюансов использования, и интерфейсов, и реализации.

1. Нюансы использования.
Вот последнее, в обсуждение чего я принимал участие:

std::vector<std::string> myVec;
myVec.push_back("QQQQQQ");
// ещё много-много push_back`ов.
myVec.clear(); // (1)

Вы надеетесь, что в точке (1) память из-под myVec освободится? Вы очень наивны, если так думаете. А чтобы узнать как её гарантировано освободить на любой реализации придётся либо проштудировать стандарт, либо искать на форуме, либо прочитать ещё одну книжку (например С. Мейерса "Эффективное использование C++"). Но и этого не достаточно: чтобы всё это сделать, надо как минимум подозревать, что не всё так просто и память реально не освободится при вызове clear. При всём при этом самое неприятное — это то, что в некоторых случаях сложность совершенно не оправдана.
Чтобы убедиться, что не всё так тривиально, вбейте слово stl в поиске на RSDN`е: у меня вышло 11319 тем...

2. Интерфейсы.

std::transform(it->begin(), it->begin() + commandEnd,
    cmd.begin(),
    std::bind2nd(std::ptr_fun(toupper_wrap), &loc));

Это ещё достаточно простая комбинация. Для меня эта запись выглядит понятной, но я встречал людей, которых она вгоняла в такой ступор... А уж если надо написать свой функтор (но это уже больше относится к 3-ему пункту).

3. Реализация.
Вы когда-нибудь порбовали написать свой аллокатор или свой контейнер, удовлетворяющий всем требованиям stl? Попробуйте на досуге...

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

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

Doc>>Здравствуйте, Mr. None, Вы писали:

MN>>>деле фигня и где-то их на самом деле разводят (сам такой же — каюсь) .

Doc>>А расскажите в чем развод STL? Очень уж интересно

MN>Н-да... Не думал, что моя шутка породит такую дискуссию... В пору уже отделять в "Священные войны".
MN>А тепрь конкретика, никакую реентерабельность или потоко-безопасность я не имел в виду. Это вообще отдельная песня и не многие библиотеки, обладают 3-мя качествами одновременно: потоко-безопасность, универсальность и эффективность. Чем-то одним приходится жертвовать...
MN>Stl удобен, для тех кто его знает и умеет им пользоваться, а это очень и очень не просто. Не мне судить, но как человек, знающий его относительно хорошо (скажем так на 4-ку, думаю даже с плюсом — скромность не позволяет выставить оценку выше ), могу сказать: некоторые вещи можно было сделать по проще и по понятнее. Это касается и нюансов использования, и интерфейсов, и реализации.

MN>1. Нюансы использования.
MN>Вот последнее, в обсуждение чего я принимал участие:
MN>

MN>std::vector<std::string> myVec;
MN>myVec.push_back("QQQQQQ");
MN>// ещё много-много push_back`ов.
MN>myVec.clear(); // (1)
MN>

MN>Вы надеетесь, что в точке (1) память из-под myVec освободится? Вы очень наивны, если так думаете. А чтобы узнать как её гарантировано освободить на любой реализации придётся либо проштудировать стандарт, либо искать на форуме, либо прочитать ещё одну книжку (например С. Мейерса "Эффективное использование C++"). Но и этого не достаточно: чтобы всё это сделать, надо как минимум подозревать, что не всё так просто и память реально не освободится при вызове clear. При всём при этом самое неприятное — это то, что в некоторых случаях сложность совершенно не оправдана.
MN>Чтобы убедиться, что не всё так тривиально, вбейте слово stl в поиске на RSDN`е: у меня вышло 11319 тем...

MN>2. Интерфейсы.
MN>

MN>std::transform(it->begin(), it->begin() + commandEnd,
MN>    cmd.begin(),
MN>    std::bind2nd(std::ptr_fun(toupper_wrap), &loc));
MN>

MN>Это ещё достаточно простая комбинация. Для меня эта запись выглядит понятной, но я встречал людей, которых она вгоняла в такой ступор... А уж если надо написать свой функтор (но это уже больше относится к 3-ему пункту).

MN>3. Реализация.
MN>Вы когда-нибудь порбовали написать свой аллокатор или свой контейнер, удовлетворяющий всем требованиям stl? Попробуйте на досуге...

И в каком месте смеяться? Вы не забыли в каком форуме находитесь?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Mr. None, Вы писали:

А>И в каком месте смеяться? Вы не забыли в каком форуме находитесь?

MN>>В пору уже отделять в "Священные войны".

Или лучше в "C++". Если вы обратите внимание, то я уже предложил отделить тему.

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

C>Здравствуйте, Кондыбас, Вы писали:

К>>В нереентерабельности кода.
C>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном использовании".
Не обязательно при рекурсивном. При вложенном тоже.

Reentrant. A reentrant function does not hold static data over successive
calls, nor does it return a pointer to static data. All data is
provided by the caller of the function. A reentrant function
must not call non-reentrant functions.

LaptevVV wrote:

> C>Вообще-то под "реентерабельный код" — это "безопасный при рекурсивном
> использовании".
> Нет... Повторная входимость рекурсии — это частный случай...
> Реентерабильный — повторно-входимый...
> Понятие возникло в начале 60-х годов в операционных системах...
> Повторная входимость — это использование ОДНОЙ КОПИИ программы (вместие
> с памятью для переменных) для нескольких процессов. Естесственно, код
> программы в процессе работы не должен изменяться — это раз. Второе — для
> переменных программы новый процесс должен получать новую память...
>
> Переменные создаются либо в стеке, либо в динамической памяти...
> Естественно, стек для каждого процесса назначает ось...
А можешь привести пример функции, безопасной при рекурсивном использовании но не реентерабельной? Или реентерабельной но
не безопасной при рекурсивном использовании?

И объяснить, в чём же сабж???

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

Doc>>>>>А расскажите в чем развод STL? Очень уж интересно
LM>>>>В том, что это как наркотик. Разок попробуешь и ....
E>>>Странно. Сколько не пробую, всё равно не подспживаюсь
LM>>Смешай с бустом в пропорции 2 к 1
E>Не, не выйдет, от этой смеси сразу резко тошнит
А не фиг MFC-ей запивать.

Лучшая закусь для этого коктеля *НИКС

Здравствуйте, Аноним, Вы писали:

MN>>1. Нюансы использования.
MN>>Вот последнее, в обсуждение чего я принимал участие:
MN>>

MN>>std::vector<std::string> myVec;
MN>>myVec.push_back("QQQQQQ");
MN>>// ещё много-много push_back`ов.
MN>>myVec.clear(); // (1)
MN>>

MN>>Вы надеетесь, что в точке (1) память из-под myVec освободится? Вы очень наивны, если так думаете. А чтобы узнать как её гарантировано освободить на любой реализации придётся либо проштудировать стандарт, либо искать на форуме, либо прочитать ещё одну книжку (например С. Мейерса "Эффективное использование C++"). Но и этого не достаточно: чтобы всё это сделать, надо как минимум подозревать, что не всё так просто и память реально не освободится при вызове clear. При всём при этом самое неприятное — это то, что в некоторых случаях сложность совершенно не оправдана.
MN>>Чтобы убедиться, что не всё так тривиально, вбейте слово stl в поиске на RSDN`е: у меня вышло 11319 тем...

Так и логично, что она не освободиться. Ведь, если я использую clear, значит вектор мне ещё нужен и я буду опять в него что-то добавлять. Зачем перераспределять память для вектора несколько раз? А если я не буду использовать вектор больше, то деструктор всё сам очистит и будет вызван автоматически при выходе за область видимости.
Всё, что я хочу сделать вызовом clear — удалить элементы вектора. Память и т.д. меня здесь не интересует — особенности реализации. Если стоит задача, где это критично (есть ограничения на использование памяти) — тогда читаю документацию.

MN>>2. Интерфейсы.
MN>>

MN>>std::transform(it->begin(), it->begin() + commandEnd,
MN>>    cmd.begin(),
MN>>    std::bind2nd(std::ptr_fun(toupper_wrap), &loc));
MN>>

MN>>Это ещё достаточно простая комбинация. Для меня эта запись выглядит понятной, но я встречал людей, которых она вгоняла в такой ступор... А уж если надо написать свой функтор (но это уже больше относится к 3-ему пункту).

В ступор этот код вогнать конечно может. Но только человека плохо знающего stl.

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

E>>Не, не выйдет, от этой смеси сразу резко тошнит
LM>А не фиг MFC-ей запивать.
MFC с этой смесью сочетать очень трудно

LM>Лучшая закусь для этого коктеля *НИКС
Это чтоли чтобы жизнь мёдом не казалась? Какая связь между кодированием, скажем, программы, которая оптимизирует меню похода под маршрут и операционкой?

Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, alzt, Вы писали:


MN>>>>Это ещё достаточно простая комбинация. Для меня эта запись выглядит понятной, но я встречал людей, которых она вгоняла в такой ступор... А уж если надо написать свой функтор (но это уже больше относится к 3-ему пункту).

A>>В ступор этот код вогнать конечно может. Но только человека плохо знающего stl.
ПС>По-моему, использование тривиальных STL-алгоритмов (вроде for_each или transform) ухудшает код.

Почему вы так считаете? Кажется так более яснее выражаются намерения автора, например, если for{;;} используется для тривиального перебора, то for_each будет уместно использовать.

ПС>Во-первых, такой код превращается в тайнопись для избранных и рискует стать write-only (это сейчас понятно, а через пару лет будет непонятно, и тогда проще переписать, чем понять).

Везде необходима умеренность. Стауструп ещё писал, что мы типа не можем запретить программисту писать плохой код или как-то ограничить его, но можем предоставить больше средств для выразительности и эффективности.

Зачем же выискивать плохие примеры кода, если и так понятно — использовать STL можно и через одно место.

ПС>Во-вторых, нельзя писать функтор по месту использования – теряется локальность кода (вспоминаю Pascal: переменная объявлена в одном месте, а используется совсем в другом; приходится постоянно метаться между двумя этими местами). Неудобно использовать в функторе локальные переменные, лежащие рядом с вызовом STL-алгоритма (приходится пихать ссылки в функтор). Архитектура программы захламляется мелочными искусственными функтор-классами (мои понятия: если название класса – не существительное, то класс искусственный).

Если функтор не имеет состояния, то наверное надо подумать над тем, надо ли вообще его писать. Тоже самое.. надо шире смотреть на решение задачи, не обязательно упираться в эти функторы без необходимости.

ПС>В-третьих, снижается эффективность программы (вместо статического вызова loc.toupper_wrap(…) делается динамический вызов; это плохо для cache-а, особенно в цикле).

Там где это кретична вообще на асме можно писать. Об этом же уже много сказано... или ещё не достаточно много?

ПС>В-четвёртых, код с функторами сложнее отлаживать.

Да ну. Я то всегда думал, функторы легче отлаживать, так как можно подставлять дебаг-вариант функтора с дополнительными регистациями.
Ну это ведь тоже на любителя Такое ощущение, что STL диктует или заставляет использоваться..

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

MN>Вы надеетесь, что в точке (1) память из-под myVec освободится? Вы очень наивны, если так думаете. А чтобы узнать как её гарантировано освободить на любой реализации придётся либо проштудировать стандарт, либо искать на форуме, либо прочитать ещё одну книжку (например С. Мейерса "Эффективное использование C++"). Но и этого не достаточно: чтобы всё это сделать, надо как минимум подозревать, что не всё так просто и память реально не освободится при вызове clear. При всём при этом самое неприятное — это то, что в некоторых случаях сложность совершенно не оправдана.
Интересно, а в какой ситуации нужно освобождать память? Имхо, обычная проблема — как очистить вектор не освобождая память (использовать resize(0))...

MN>3. Реализация.
MN>Вы когда-нибудь порбовали написать свой аллокатор или свой контейнер, удовлетворяющий всем требованиям stl? Попробуйте на досуге...
Хорошее развлечение
Практически — редко кому нужен свой контейнер удовлетворяющий всем требованиям stl, его не для того пишут.
А в чём проблема с аллокатором? Как правило при разработке своих аллокаторов копипаст рулит.

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

NBN>А в чём проблема с аллокатором?
У STL allocator-а кривой интерфейс. Например, зачем было пихать туда методы construct (вызывает конструктор копирования) и destroy (вызывает деструктор)? Зачем было делать allocator шаблоном? Вполне сошло бы что-нибудь попроще, например:

class MyAllocator
{
public:
  void* AllocBlock(int Size, void* pImproveLocalityHint = NULL);
  void FreeBlock(void* pMem, int Size);
  friend bool operator==(const MyAllocator& a1, const MyAllocator& a2);
private:
  ...
}

http://en.wikipedia.org/wiki/Standard_Template_Library#STL_design:

Criticisms
…
STL design
…
3. Other flaws, caused either by trade-offs in design or which have become more visible over time
…
* The design of STL allocator (used by the containers) is widely seen as flawed.

Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, NikeByNike, Вы писали:

NBN>>А в чём проблема с аллокатором?
ПС>У STL allocator-а кривой интерфейс. Например, зачем было пихать туда методы construct (вызывает конструктор копирования) и destroy (вызывает деструктор)? Зачем было делать allocator шаблоном? Вполне сошло бы что-нибудь попроще, например:

А какая разница? Всёравно, когда делаешь свой аллокатор — делаешь копию стандартного и модифицируешь его под себя. Сколько раз делал — каждый раз на разработку уходило минут по 15. С контейнерами так не получится. Но с ними, как правило проще, в плане тонкостей реализации.

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

NBN>>>А в чём проблема с аллокатором?
ПС>>Вполне сошло бы что-нибудь попроще, например:
NBN>А какая разница?
Разница в удобстве. Интерфейс allocator-а неудобен для программистов, которые используют STL (то есть пишут свои allocator-ы). Также интерфейс allocator-а неудобен для программистов, которые реализуют STL (достаточно просмотреть исходники STLport).

NBN>Всёравно, когда делаешь свой аллокатор — делаешь копию стандартного и модифицируешь его под себя. Сколько раз делал — каждый раз на разработку уходило минут по 15.
Долго. Если бы был нормальный дизайн (трёх методов хватает), то заняло бы минуту-две без всякого copy-paste-а.

Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, NikeByNike, Вы писали:

NBN>>>>А в чём проблема с аллокатором?
ПС>>>Вполне сошло бы что-нибудь попроще, например:
NBN>>А какая разница?
ПС>Разница в удобстве. Интерфейс allocator-а неудобен для программистов, которые используют STL (то есть пишут свои allocator-ы). Также интерфейс allocator-а неудобен для программистов, которые реализуют STL (достаточно просмотреть исходники STLport).
Меня смущает, что аллокатор не охватывает все выделения памяти в контейнерах, а остальное дело наживное.

NBN>>Всёравно, когда делаешь свой аллокатор — делаешь копию стандартного и модифицируешь его под себя. Сколько раз делал — каждый раз на разработку уходило минут по 15.
ПС>Долго. Если бы был нормальный дизайн (трёх методов хватает), то заняло бы минуту-две без всякого copy-paste-а.

Хм, я надеюсь, ты не по сто аллокаторов используешь? Мы написали три, которых нам хватило на довольно большой проект. В принципе, я не вижу особых проблем в аллокаторе и могу придумать объяснения для большинства его особенностей, некоторые из них мы юзали. А свои контейнеры писать, по моему вообще извращение. Я писали только один в связи с жёсткой необходимостью, для слабой платформы... А если платформа не совсем слабая -то в бусте много чего готового есть, лучше же его использовать, а не писать велосипеды, разве нет?