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

E>2) Обычно производители софта ориентируются не на стоимость разработки, а на инсталляцилнную базу. В конце концов привинтить более С++ строчки поверх этих не так уж и дорого
Строчки эт только пример Там кроме этого хватает граблей Ну и на инсталляционную базу в первую очередь смотрят когда продукт имеет солидный бюджет. А средние и маленькие проекты на стоимость разработки очень даже смотрят.

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

L>Строчки эт только пример Там кроме этого хватает граблей Ну и на инсталляционную базу в первую очередь смотрят когда продукт имеет солидный бюджет. А средние и маленькие проекты на стоимость разработки очень даже смотрят.

Ну так база -- это же обороты
Если таких телефонов много, то для них легко продавать прогу, значит её можно разработать за подороже и всё равно остаться в плюсах

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

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

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

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

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

Ну так необходимости рефакторинга никто не отменял. Иначе любой код превратится в тихий ужас

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

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

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

В общем мне так кажется, что идея о возможности смены типа контейнера "задёшево" в основном разрушительная и вредная. Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации"

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

E>Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации" :)

Что изменится в худшую сторону, если, например, функцию inline f(char *, size_t) заменить на template f(BidirectionalIterator, BidirectionalIterator)? А в лучшую — много что.

Другое дело, что можно написать, например, версию алгоритма для Random Access Iterator, но повременить с версией для Bidirectional Iterator. Тем не менее, такая структура допускает беспроблемное расширение, и не нужно сложного проектирования.

Кроме того, у обобщенного проектирования с итераторами есть еще одно преимущество: даже если ограничиваться одним типом контейнеров, можно легко задавать подпоследовательности, что далеко не всегда свойственно другим подходам.

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

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

E>>Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации"

Ну я так тебя понял, что с закавыченным утверждением ты не согласен?

---

RO>Что изменится в худшую сторону, если, например, функцию inline f(char *, size_t) заменить на template f(BidirectionalIterator, BidirectionalIterator)? А в лучшую — много что.

Ну интересно что изменится в лучшую и почему.Положим функция f( char* size_t ) проверяет по словарю наличие такого английского слова. Итак, что нам даст в этйо функции переход к итераторам? В частности интересно бы узнать, где брать словари универсального формата...

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

RO>Кроме того, у обобщенного проектирования с итераторами есть еще одно преимущество: даже если ограничиваться одним типом контейнеров, можно легко задавать подпоследовательности, что далеко не всегда свойственно другим подходам.
Это конечно очень, очень, очень нужная фича. Абсолютно вообще всегда.
Если вернуться к примеру с функцией f( char*, size_t ), которая проверяет по словарю английские слова, то конечно
1) Проверить, что чётные буквы строки являются английским словм -- это очень ценная и важная возможность.
2) Если уж припечёт, конкретно в этом случае всё легко решается порождением новой строки, например.

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

E>>>Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации" :)

E>Ну я так тебя понял, что с закавыченным утверждением ты не согласен? :)

С первой частью согласен. Со второй частью не согласен.

E>

---

RO>>Что изменится в худшую сторону, если, например, функцию inline f(char *, size_t) заменить на template f(BidirectionalIterator, BidirectionalIterator)? А в лучшую — много что.

E>Ну интересно что изменится в лучшую и почему.Положим функция f( char* size_t ) проверяет по словарю наличие такого английского слова. Итак, что нам даст в этйо функции переход к итераторам? В частности интересно бы узнать, где брать словари универсального формата...

А причем здесь универсальный формат? Например, словарь живет в плоском текстовом файле. Или его уже загрузили в упорядоченный массив или дерево. Какая разница, char * или Iterator?

RO>>...и не нужно сложного проектирования.
E>Вот это-то и есть корень зла. Там не нужно проектирования, сям. А в результате неподдерживаемый мегаурод выходит. Пошевилишь такой "обобщённый код" и
никогда больше не отладишь :(

Тогда и hello world проектировать надо? Везде надо меру знать.

RO>>Кроме того, у обобщенного проектирования с итераторами есть еще одно преимущество: даже если ограничиваться одним типом контейнеров, можно легко задавать подпоследовательности, что далеко не всегда свойственно другим подходам.
E>Это конечно очень, очень, очень нужная фича. Абсолютно вообще всегда.
E>Если вернуться к примеру с функцией f( char*, size_t ), которая проверяет по словарю английские слова, то конечно
E>1) Проверить, что чётные буквы строки являются английским словм -- это очень ценная и важная возможность.
E>2) Если уж припечёт, конкретно в этом случае всё легко решается порождением новой строки, например.

А как насчет проверки того, что подстрока между N-ным и N+1-м пробелом входит в словарь? Кстати, f(char*, size_t) с этим тоже справится. А f(SomeContainer const &) — нет.

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

E>>>>"...А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации"
RO>...Со второй частью не согласен.

ТО есть тебе кажется, что шаблонные обощённые функции проектировать не надо? И документировать тоже?
Ну собственно я про тоже самое, что "использование STL провоцирует порождение кучи обобщённого кода, который никто никогда не проектировал, как обобщённый".

Беда-то не в том, что итератор так же хорошо, как const char*, а в том, что в обощённом случае семантика у функции может оказаться неожиданной, или может оказаться, что реализовать какой-то варинат непросто, а так, как реализовать просто неправильно.
Функции-то проектируют не для того, чтобы интерфейс им написать какой-то, а для того, чтобы они улучшали код

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

E>>Ну интересно что изменится в лучшую и почему.Положим функция f( char* size_t ) проверяет по словарю наличие такого английского слова. Итак, что нам даст в этйо функции переход к итераторам? В частности интересно бы узнать, где брать словари универсального формата...

RO>А причем здесь универсальный формат? Например, словарь живет в плоском текстовом файле. Или его уже загрузили в упорядоченный массив или дерево.
Ну словарь где-то надо брать, вообще-то... Он же не может материализоваться из шаблонных конструкций
RO>Какая разница, char * или Iterator?
Ну разница простая, char* намного конкретнее. НИкто не подсунет вместо Iterator какую-нибудь неожиданную хреновину. Но в целом я так и не понял чем лучше и почему... Чем хуже я и так знаю

RO>Тогда и hello world проектировать надо? Везде надо меру знать.
Ну от архитектуры зависит. Но обычно hello world программировтаь не надо, так как это как раз алгоритм, предназанчный для выполнения конкретных действий.
А вот если у тебя hello world будет метапрограммой. То есть будет порождать программы для разных обстоятельств (например для 100 разных ОС), то проектироватьочень даже стОит

RO>А как насчет проверки того, что подстрока между N-ным и N+1-м пробелом входит в словарь? Кстати, f(char*, size_t) с этим тоже справится. А f(SomeContainer const &) — нет.
1) Ты сам ответил. Проектирование таки рулит намного больше итераторов.
2) ИМХО в этой задаче не жалко копировать строку, если это от чего-то удобно...

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

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

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


R>Имхо, тут двухсвязный список — то, что доктор прописал.
тут еще одна возможность появляется. Если смарт поинтеры в список связаны, то можно иенять сам обьект на ходу, если пройтись по списку

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

R>>Имхо, тут двухсвязный список — то, что доктор прописал.
P>тут еще одна возможность появляется. Если смарт поинтеры в список связаны, то можно иенять сам обьект на ходу, если пройтись по списку

ИМХО еси есть такая нужда, то дешевле таки иметь какие-то прокси-объекты...

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

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

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

E>Это помогает под виндой.
E>Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста.

Если so правильно приготовить, то не сможет. Надо эти символы просто повырезать во время линковки so-шки, а как это уже особенности конкретного линковшика.

P>>тут еще одна возможность появляется. Если смарт поинтеры в список связаны, то можно иенять сам обьект на ходу, если пройтись по списку
E>ИМХО еси есть такая нужда, то дешевле таки иметь какие-то прокси-объекты...

Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.

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

L>Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.

Если указателей мало, то не жалко лишнего new

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

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

L>>Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.

E>Если указателей мало, то не жалко лишнего new

Не путай указатели вообще и указатели на конкретный объект

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

R>Не путай указатели вообще и указатели на конкретный объект

Ну я так понимаю, что временем жизни указуемого объекта мы не управляем, так что выбора особого нет

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

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

R>>Не путай указатели вообще и указатели на конкретный объект

E>Ну я так понимаю, что временем жизни указуемого объекта мы не управляем, так что выбора особого нет

При чём тут время жизни указываемого объекта?

L>>Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.
E>Если указателей мало, то не жалко лишнего new
Я говорю о ситуации когда обьектов много, но на каждый из них всего 1-2-3 указателя. Тогда linked_ptr будет выгоднее shared_ptr — не нужно будет лишнего new (для обьекта-прокси) на КАЖДЫЙ выделенный "реальный" обьект. Мне кажется что это будет быстрее чем даже в случае самого оптимизированного аллокатора для проксей.
Кстати, для такой ситуации наверняка односвязный циклический список (вместо двусвязного) для linked_ptr будет идеей, достойной рассмотрения.

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

J>Первое — глупость, так и передай своим заказчикам

John Robbins в книге Debugging Applications for Microsoft .NET and Microsoft Windows рекомендовал не использовать STL. Хотелось бы надеяться, что в новом издании он эту рекомендацию убрал; но пока-что если заказчик сошлется на Роббинса, отвечать ему в духе "а jazzer сказал, что это глупость" не очень перспективно. И обрати внимание, Роббинс говорил про STL, а boost и хочешь использовать, и разрешение имеется, а как получишь пару сотен ворнингов при его сборке, так ... слов нет, одни буквы.