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

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>>>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-а, особенно в цикле).
В-четвёртых, код с функторами сложнее отлаживать.

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

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

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

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

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

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