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

L>>Во! Вот это типичная ошибка — считать что контейнеры STL должны быть заменяемы друг на друга лёгким движением руки ЕМНИП, Герб Саттер, которого я очень уважаю за то что он самый большой практик из всех гуру С++, предлагал забыть об этом принципе сразу и навсегда. ПисАть код который был бы контейнеро-независимым — слишком сложно и в итоге невыгодно экономически в большинстве случаев.
E>Вот и я к тому же. Что люди, которые где-то как-то изучили STL, особенно если по пути ещё и зафанатели, всё время в этот грех сваливаются
E>Чем-то он не очень опытных программистов цепляет

Вот, кажется, вот где собака порылась Маленькое интро.. У меня отец всю жисть ездил на ручной коробке передач. Потом купил автомат, соблазнился.. Но хватило его не на долго — щас опять ездит на ручной, ну хоть на иномарке и то слава богу... Я в принцепе его прекрасно понимаю и сам люблю больше ручную, но правда совсем по другим причинам, в дальнюю поездку на тысячи км я бы предпочёл всё таки автомат.

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

Мне кажется, что новые идеи обычно вызывают подозрения у "старперов", по этой причине всё внимание уделяется в основном недостаткам (по крайне мере как они там видят). Сам STL конечно полностью не идеален.

Короче это моё ИМХО. Я не фанат STL, и особых восторгов по поводу него не испытываю, просто принимаю как данность, пытаюсь разобраться, научиться, это всё же не просто библиотека там каких то контейнеров. Рождение буста обязано ему, и я уверен что рождение "новых" программистов тоже не за горами Поэтому, не будем воевать, каждый делает то что лучше всего у него получается и использует те инструменты, к которым он привык и знает как свои 5 пальцев

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

J>>Еще раз — буст ничем не отличается в этом плане от любой другой библиотеки.
E>ОТлиячается объемом зависимого кода. Одно дело, когда от стороненй библиотеи завист несколько классов-переходников, и совсем дургое, если зависит весь код всех проектов.
Я думаю, от библиотеки контейнеров зависят не несколько классов-переходников, независимо от того, кем она написана.
А вот всякие мелкие библиотеки из буста типа, скажем, токенайзера или того же регэкса — скорее всего, будут в нескольких классах-переходниках и влияния на всю систему не окажут (если, когнечно, ваш проект не завязан по уши на регэкспы).

E>Улучшает в смысле стоимости разработки и поддержки. По нашему опыту.
Ну, у вас ведь другого опыта нет, вы же всегда держите в уме возможность портирования на какую-нть недоплатформу.

J>>Предлагаешь вернуться к тому нашему долгому обсуждению STL-way?
E>Нет, просто сам хочу понять что же не так в STL. Видимо система ценностей.
E>А абстрагировать алгоритмы -- так кто же против? Только абстрагировать надо очень мало алгоритмов. Ну типа на большой проект может процент наберётся кода, который абстрагированными алгоритмами стоит сделать. И просто в рамках шаблонов C++ можно абстрагировать. STL для этого ненужен. Для этого нужен высококвалифицированный специалист...

E>А ллокатор нужен для того, чтобы о памяти не парится, в случае если освобождение дорогое или если нет исключений.
Получается, если ты хочешь "грохать все" через аллокатор — это оправдано только в случае объектов без осмысленных деструкторов. Иначе нужно у каждого персонально позвать деструктор, а такой вызов должен быть типизированным так или иначе, т.е. вместо аллокатора ты получаешь просто типизированный контейнер.

J>>>>

---

E>>>А что, от принятия стандарта C++ изменится аппаратура? Или, может быть, ОС?
J>>нет, появятся гарантии, что если ты написал какое-то выражение, то оно выполнится именно так, как ты написал, и ты сможешь это гарантировать безо всяких шаманских плясок, коими радует нас remark (я имею в виду его пост про double lock).

E>Да откуда они появятся?
Из стандарта, откуда же еще.
E>Если сейчас нельзя сделать быстро, то и после стандартизации не будет льзя
E>Мало того, стандартизация обычно мешает использовать преимущества конкретной платформы.
Ничего она не мешает, и не мешала никогда.
Хочешь писать преносимый код — пиши на стандартных фичах. Не хочешь — пиши на местных.
Стандарт же не запрещает какой-нть __int64 на основании того, что есть стандартный int.

J>>Так потому что на каждую задачу требуется свое решение.
J>>Хотя, конечно, есть некоторые тормозные, но безотказные вещи (мьютексы), которые, как самое простое для понимания, вцементированы в некоторые языки в виде слов типа synchronized. Чем не единообразное решение
E>Ну вот в том-то и дело, что не стандарта нет, а универсального решения
Все эти решения строятся на элементарных фичах. Например, на барьерах, на атомарных типах, на конкретном наборе атомарных операций.
Сейчас ты вынужден каждый раз юзать фичи конкретной системы, что делает твой код непереносимым. А так ты будешь писать просто на плюсах std::atomic<int> i; и делать на нем семафоры или что там тебе понадобилось для твоей конкретной задачи, и это будет абсолютно переносимо (естественно, с точностью до поддержки компилятора).

Потому что сейчас ты даже не можешь гарантированно безопасно прочитать значение переменной (типа if (x==5)), если ты не защитил ее мьютексом.

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

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

L>Во! Вот это типичная ошибка — считать что контейнеры STL должны быть заменяемы друг на друга лёгким движением руки ЕМНИП, Герб Саттер, которого я очень уважаю за то что он самый большой практик из всех гуру С++, предлагал забыть об этом принципе сразу и навсегда.
Не помню такого. По крайней мере, когда мы с ним на эту тему разговаривали — ничего он такого не утверждал.

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

90% (может, и больше) кода, работающего с контейнерами, формулируется в виде "взять все (или только удовлетворяющее некоторому условию) объекты вот отсюда и сделать с каждым то-то".
Именно поэтому почти во всех языках, кроме плюсов (но скоро и в плюсах будет: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html) есть for_each в той или иной форме. Весь такой код никак не зависит от того, в каком контейнере лежат объекты.

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

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

V>...и я уверен что рождение "новых" программистов тоже не за горами

Не, ну как только, так сразу. Пока что ярые приверженцы STL, ИМХО, неадекватны типичным задачам

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

S>

S>When there are equivalent elements in both source ranges, the elements in the first range precede the elements from the second source range in the destination range. If the source ranges contain duplicates of an element, then the destination range will contain the maximum number of those elements that occur in both source ranges.

S>Судя по-всему эта функция работает так же.

Ну да, в MSDN определено
Короче точно воспроизвести не умею. Зачем -- тоже не знаю.
На крайняк можно написать анологичный алгоритм руками

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

S>Алгоритм set_union не требует отсутствия повторов. (т.е. работает на multi_set)
Тогда понятно.

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

L>auto_ptr тут самописный. Он сам Pop и делает.
ИМХО нехорошо его так называть было...

E>>Странно. Вообще-то вроде бы популярная платформа...
L>Это она среди пользователей популярная.
Ну это же главная цель, вроде?
Есть прорва тормозных и прожорливых платформ, популярных у разработчиков...

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

J>Я думаю, от библиотеки контейнеров зависят не несколько классов-переходников, независимо от того, кем она написана.
Да. И такая ьиьлиотека своя.

J>А вот всякие мелкие библиотеки из буста типа, скажем, токенайзера или того же регэкса — скорее всего, будут в нескольких классах-переходниках и влияния на всю систему не окажут (если, когнечно, ваш проект не завязан по уши на регэкспы).
Ну регэкспы можно было попробовать взять из буста, но не ясно зачем

J>Ну, у вас ведь другого опыта нет, вы же всегда держите в уме возможность портирования на какую-нть недоплатформу.
Не всегда. Но там где держим код лучше

J>Получается, если ты хочешь "грохать все" через аллокатор — это оправдано только в случае объектов без осмысленных деструкторов. Иначе нужно у каждого персонально позвать деструктор, а такой вызов должен быть типизированным так или иначе, т.е. вместо аллокатора ты получаешь просто типизированный контейнер.
А зачем звать "осмысленные деструкторы" если объекты ни на что внешнее на самом деле не ссылаются? Ну пусть умрут все разом?

J>>>>>

---

J>Из стандарта, откуда же еще.
А в железе откуда появятся? И что мешает им появиться до стандарта?

J>Хочешь писать преносимый код — пиши на стандартных фичах. Не хочешь — пиши на местных.
J>Стандарт же не запрещает какой-нть __int64 на основании того, что есть стандартный int.
Ну на кой нужен ещё один "вредный" стандарт?
Хорошо, когда стандарт таки позволяет им пользоваться...

E>Я приведу один всего пример. В библиотеках, которые мне нравятся, перекрывают ::new/::delete для того, чтобы всякими хитрыми способами управлять стратегиями аллокации. Это позволяет делать аналог GC некий во многих нужных нам "прожорливых по памяти" алгоритмах, скажем. Ну и вообще это много чего позволяет. Кроме того есть ещё такая метода, что при обработке запроса, ты регишь где-то в запросе все критические ресурсы, а все некритические (например память под локальные на запрос объекты) аллокируешь на специальнйо куче запроса. В случае, если всё гавкнулось, то освобождаешь зарегистрированные критические ресурсы, и грохаешь всю кучу запроса. Восстанавливаешься таким образом.
E>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...

я подумываю о полезности такой стратегии выделения памяти для многопоточных приложений.
часто бывает что в треде вызываются new/delete чтобы аллокировать что-то в куче, несмотря на то что известно что объекты будут использоваться только этим тредом. в таком случаем можно было бы создать thread-local кучу и в ней выделять память под "однопоточные" объекты. для тех же которые должны шариться между потоками, используем глобальную кучу, с локами

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

V>>...и я уверен что рождение "новых" программистов тоже не за горами :)
E>Не, ну как только, так сразу. Пока что ярые приверженцы STL, ИМХО, неадекватны типичным задачам :)

Линуксоид — это не тот, кто использует Linux, а тот, у кого 1000 постов во flame.comp (©)?

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

RO>>Ну вот тебе реальная задача: объединить содержимое двух упорядоченных последовательностей.
E>0) Ты привёл код, который делает не то, что ты просил.

Ладно, ты прав, это я описал std::merge. set_union объединяет множества, представленные упорядоченными последовательностями.

E>1) Это стандартный алгоритм, его таки проектировали, я надеюсь :)

Здесь не понял.

E>2) Мне кажется, что он нужен довольно редко

В этом поверю тебе, твой опыт наверняка превосходит мой.

E>3) Даже если двухпутевое слиение написать "из головы", оно у нормального программиста обычно работает сразу. ИМХО лучше уметь программировать любой алгоритм, чем уметь пользоваться merge. Тем более, что набор алгоритмов в STL ИМХО никакой состематичностью не обладает. Хотя это не совсем двухпутевое слияние, конечно, так как повторы не копируются.

E>4) (И это главное, на самом деле) Это очень абстрактная задача. Реальная задача звучит как-то так: "Рассчитать аэродинамику такого-то самолёта" :)

Ничего, в 2050 г. это будет в STL, а ваша компания напишет велосипед ;-)

E>

---

RO>>

RO>>EropsMysteriousCompany::ProprietaryContainers::DynamicArray<WeHateTemplates> x, y, z;
RO>>// std::set_union(x.begin(), x.end(), y.begin(), y.end(), std::back_inserter(z));
RO>>как?
RO>>

E>Ну совсем так я не знаю, а если просто выбрасывать повторы, то так:

Я так и думал. У ваших контейнеров есть метод SortedMerge, наверняка есть Sort, Max, Min и т. д. И сколько контейнеров — столько и реализаций, причем далеко не всегда это продиктовано спецификой контейнера (например, std::list имеет свой метод merge, но свои find/max_element/replace и т. д. ему не нужны).

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

Попробую привести еще один пример. Выбрать из большой последовательности 10 наибольших элементов. Предполагается, что программер, который сам написал велосипедное двухфазное слияние, напишет и bicycle::partial_sort? А сколько раз у вас реализован ваш аналог stable_sort?

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

RO>>«Ну чесне слово — як діти». this->ptr = this->next->ptr; oldNext = this->next; this->next = this->next->next; delete oldNext. Заборы расставить по вкусу.

E>Угу.
E>1) Удалил не того
E>2) delete oldNext-то за что? :wow:

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

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

E>>Не, ну как только, так сразу. Пока что ярые приверженцы STL, ИМХО, неадекватны типичным задачам
RO>Линуксоид — это не тот, кто использует Linux, а тот, у кого 1000 постов во flame.comp (©)?
Я на всякий случай уточню.
Пока что, встречающиеся мне в реале, ярые приверженцы STL, ИМХО, неадекватны, встречающимся мне в реале,типичным задачам

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

E>>1) Это стандартный алгоритм, его таки проектировали, я надеюсь
RO>Здесь не понял.
Ну я высказывался в том смысле, что SRL провоцирует создание шаблонов, которые никто никогда не проектировал как шаблоны. В этом смысле пример нерелевантный.

E>>4) (И это главное, на самом деле) Это очень абстрактная задача. Реальная задача звучит как-то так: "Рассчитать аэродинамику такого-то самолёта"
RO>Ничего, в 2050 г. это будет в STL, а ваша компания напишет велосипед
Ну еслинаш не стандартизируют Правда при этом наверняка испортят

E>>

---

RO>Я так и думал. У ваших контейнеров есть метод SortedMerge, наверняка есть Sort, Max, Min и т. д. И сколько контейнеров — столько и реализаций, причем далеко не всегда это продиктовано спецификой контейнера (например, std::list имеет свой метод merge, но свои find/max_element/replace и т. д. ему не нужны).

Max/Min нет. Есть QuickSort, SortedMerge, BinarySearch, LinearSearch, IsSorted

RO>Т. е., ваша библиотека поощряет дублирование кода, и не позволяет писать универсальные алгоритмы.

Вообще-то есть или нет дублирование кода между реализациями методов BinarySearch -- это всего лишь подробность реализации библиотеки. Сложные алгоритмы, например QuickSearch у нас реализованы так. Есть шаблон класса-механизма, который осуществляет упорядочивание любого массива. А в конкретных реализациях массивов этот шаблон используется от подходящих параметров. Можно сказать, что он представляет собой что-то похожее на абстрактный алгоритм stl, а его параметры представляют что-то типа итераторов с произвольным доступом. Но это всё не возведено в абсолют
Простые методы, типа IsSorted просто продублированы.
Но в любом случае это всё всего лишь подробностиреализации библиотеки. ИМХО процесс её использования намного важнее её написания. Так что вопрос о дублировании кода в библиотеке вообще не очень важен, ИМХО.

RO>Попробую привести еще один пример. Выбрать из большой последовательности 10 наибольших элементов. Предполагается, что программер, который сам написал велосипедное двухфазное слияние, напишет и bicycle::partial_sort?
Ну в целом именно так нужно редко. Чаще всего у нас быват другая конструкция. Типа генерируем варианты пока не наберём 10 достаточно хороших, либо пока варианты не закончатся (что малореально). Но в любом случае, считается что да, напишет. Либо отсортирует всё и возмёт первых 10, если это таки понадобится.
RO>А сколько раз у вас реализован ваш аналог stable_sort?
АФАИК нисколько раз не реализован Он нам скорее всего пока что не был нужен.

Короче смысл в том, что алгоритмы STL (кроме нескольких реально востребованных, которые реализованы и в нашей библиотеке QuickSort, BinarySearch и т. д.) не то чтобы продоставляют вредные сервисы, а просто маловостребованные. Ну типа пользы мало от них довольно. Ну могут они автоматизировать 0.0001% кода, но это совсем непринципиально.

Зато подход с шаблонами и итераторами и обощёнными алгоритмами неизбежно пропитывает почти весь код, то есть приносит 99% вреда

В конце концов, если тебе таки реально надо написать обобщённый алгоритм, то никто нее мешает тебе взять да и спроектировтаь шаблон на эту туму. Но это только если надо и таки реально спроектировать

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

A>я подумываю о полезности такой стратегии выделения памяти для многопоточных приложений.
A>часто бывает что в треде вызываются new/delete чтобы аллокировать что-то в куче, несмотря на то что известно что объекты будут использоваться только этим тредом. в таком случаем можно было бы создать thread-local кучу и в ней выделять память под "однопоточные" объекты. для тех же которые должны шариться между потоками, используем глобальную кучу, с локами

ИМХО это правильно. Только прийдётся реализовать или заиспользовать библиотеку, которая позволяет переключать кучи. Советую сразу хранить во всех блоках аллокатор, на котором блок выделялся. Так будет надёжнее работать. Кроме того можно использовать обычные кучи, просто у каждой нити иметь свою. Насколько я понимаю, пока куча используется одной нитью синхронизация стоит недорого.

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

Правда на этом пути ты встретишь трудности с сопротивлением STL этому вопросу. Но они вполне сеюе преодолимы.

L>>auto_ptr тут самописный. Он сам Pop и делает.
E>ИМХО нехорошо его так называть было...
+1. Согласен, но идея и сам код изначально не мой, стырено у одного из гуру Симбиана, а переименовать как-то всё не доходят руки.

E>>>Странно. Вообще-то вроде бы популярная платформа...
L>>Это она среди пользователей популярная.
E>Ну это же главная цель, вроде?
E>Есть прорва тормозных и прожорливых платформ, популярных у разработчиков...
Как бы так сказать... Мне кажется что в отличие от прикладных программ, которые пишутся для пользователей, операционная система (вариант — библиотека, фреймворк) пишется в бОльшей степени для программиста. Так вот, если даже самая замечательно написанная операционная система будет иметь такой кошмарный API/убогую документацию/багливые средства разработки — то в итоге она программистов от себя отвернёт. А не будет программистов — не будет прикладных программ. А имея бедный набор прикладных программ сдохнет даже самая наилучшая ос. Ведь Windows как ОС — далеко не блестяще написана, но главное её достоинство — это тонны документации + разнообразные средства разработки, которые тоже неплохо документированы. Linux — там может не всё так хорошо с документацией (MSDN-а нету ), но зато сорцы открыты — если что-то надо, разберёшься сам. А вот Symbian — это капец. Очень часто возникают ситуации когда нужно просто плясать с бубном вокруг чтобы понять как это работает или почему не работает. В итоге, мне кажется, что со временем Symbian будет вытеснен Windows CE и embedded Linux-ом.

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

Всё это ИМХО, не претендующее на истину.

J>Не помню такого. По крайней мере, когда мы с ним на эту тему разговаривали — ничего он такого не утверждал.
Лень искать, честно, — к тому же мог действительно ошибаться насчёт авторства... Хотя, по С++ я кроме Саттера страюсь никого не читать

J>90% (может, и больше) кода, работающего с контейнерами, формулируется в виде "взять все (или только удовлетворяющее некоторому условию) объекты вот отсюда и сделать с каждым то-то".
J>Именно поэтому почти во всех языках, кроме плюсов (но скоро и в плюсах будет: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html) есть for_each в той или иной форме. Весь такой код никак не зависит от того, в каком контейнере лежат объекты.

Мы наверное спорим о слегка разных вещах
Всё дальше — личное ИМХО из личного опыта, с отфонарной терминологией и не претендует на истину.
Итак, есть 2 вида кода — обобщённый и решающий конкретные задачи. К примеру, std::sort, std::for_each и т.п. — код обобщённый. А контейнер который содержит все точки по которым проехала машина за день в ПО которое отслеживает её перемещение — это код конкретный. Бывает, что код конкретный мигрирует в код обобщённый — но случается это не очень часто, когда какое-то действие настолько часто встречается в программе что его выносят в библиотеку. Куда чаще обобщённый код изначально пишут "с нуля". Но и в случае миграции из конкретного кода, и в случае написАния "с нуля" код обобщённый пишется всегда по-другому — с более высокими уровнями абстракции, с более тщательным дизайном, пишется максимально универсальным и т.п.

Теперь вернёмся к нашим баранам, то бишь STL Если я пишу алгоритм вида std::for_every_odd_element (в моём понимании это код "обобщённый") — то естественно я всеми силами постараюсь абстрагироваться насколько это возможно от контейнера в котором лежат элементы, тут взаимозаменяемость контейнеров важна, нужна и экономически оправдана. Если же я пытаюсь сделать так чтобы у меня контейнер который содержит все точки по которым проехала машина за день мог лёгким движением руки из vector стать list — то это какая-то паранойя. Я всё равно этот контейнер выбираю заранее из расчёта конкретных требований к нему, а если требования поменяются в процессе разработки — то мне всё равно прийдётся переписывать огромные куски сопуствующего кода. Вот здесь попытки сделать котейнеронезависимость, ИМХО, только вредят.

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

L>Да, чтобы быть до конца точным — по "отвернёт программистов" я понимаю даже не то что они скажут "я не буду писАть под это убожество" — а то что менеджеры сочтут экономически невыгодным поддержку такого чуда, когда квалификация программистов должна быть высокой — а скорость написания программ и их надёжность в разы меньше оных на других осях.

ИМХО разработка софта -- не самая дорогая статья в устройствах с этйо ОС. А работает хорошо. Быстро и удобно...

Ну бедет телефон с такой ос на $0.05 дороже из-за того, что разработка дорогая. Ну и что?

L>Всё это ИМХО, не претендующее на истину.

E>ИМХО разработка софта -- не самая дорогая статья в устройствах с этйо ОС. А работает хорошо. Быстро и удобно...
E>Ну бедет телефон с такой ос на $0.05 дороже из-за того, что разработка дорогая. Ну и что?

Я имею в виду third-party софт. Если его будет мало, а для конкурирующих осей — много, то эта ось обречена.

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

L>Я имею в виду third-party софт. Если его будет мало, а для конкурирующих осей — много, то эта ось обречена.
Мутный это вопрос.
1) ИМХО в телефонах third-party сильно не главное
2) Обычно производители софта ориентируются не на стоимость разработки, а на инсталляцилнную базу. В конце концов привинтить более С++ строчки поверх этих не так уж и дорого