[c++] Meyers. Effective STL

>Effective STL

такое бывает?

> > Effective STL

> такое бывает?

да.

а какой смысл ты вкладываешь в слово Effective?

Ну и? Не нравится использовать алгоритмы -- не используй. Не нравятся итераторы -- не используй.

В чем вопрос? ;)

> Не нравятся итераторы -- не используй.

Бгг. Сразу можешь сказать: "не используйте STL". И с тобой всё будет ясно.

Но ты все равно продолжаешь кушать кактус, да?

> Ну и? Не нравится использовать алгоритмы -- не используй. Не нравятся итераторы -- не используй.

вопрос не в том, нравится что-то мне или нет.

вопрос в том, какого хрена все это реализовано настолько неудобным способом?

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

получается что stl вообще, и в частности алгоритмы -- замечательная штука,
а на практике чем меньше ими пользуешься, тем получается проще
(хотя должно быть наоборот)

> а на практике чем меньше ими пользуешься, тем получается проще

Дадада, реализовать свои контейнеры от list до map - это гораздо проще :D

> не напрягаясь распознают весь этот этот фантастический синтаксис

да.

> при этом держа в уме особенности поведения итераторов и прочей херни

Какие ещё особенности и какой херни?

> получается что stl вообще, и в частности алгоритмы -- замечательная штука

да.

> на практике чем меньше ими пользуешься, тем получается проще

4.2

>> при этом держа в уме особенности поведения итераторов и прочей херни

> Какие ещё особенности и какой херни?

из статьи по ссылке:

// for each i in data, insert data[i]+41
// at the front of d; this code has a bug!
for (size_t i = 0; i < numDoubles; ++i) {
d.insert(d.begin(), data[i] + 41);
}


еще вариант:

// remember d’s begin iterator
deque<double>::iterator insertLocation = d.begin();

// insert data[i]+41 at insertLocation, then
// increment insertLocation; this code is also buggy!
for (size_t i = 0; i < numDoubles; ++i) {
d.insert(insertLocation++, data[i] + 41);
}

еще один:

deque<double>::iterator insertLocation =
d.begin();

// update insertLocation each time
// insert is called to keep the iterator valid,
// then increment it
for (size_t i = 0; i < numDoubles; ++i) {
insertLocation =
d.insert(insertLocation, data[i] + 41);
++insertLocation;
}


и что, всем должно быть очевидно что третий вариант верный а два первых нет?

>> на практике чем меньше ими пользуешься, тем получается проще

> 4.2

4.2 тебе обратно

для совсем простых вещей записать явный цикл выходит проще чем for_each (и понятней!)

только потому что для for_each приходится либо использовать альтернативный синтаксис (втч для арифметики, здраствуй лисп) или городить вложенный класс (в котором все аргуенты анонимной лямбда-функии надо повторить три раза)

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

> всем должно быть очевидно что третий вариант верный а два первых нет?

Кто эти загадочные "все"? O_o

малыша обломали на собеседовании?

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

ну дык

я бы понял если бы автор сабжевой книги так и написал, честно -- мол на с++ можно писать программы естественным способом (т.е. преимущественно в функциональном стиле), но записывается это через жопу так что придется слегка придрочиться

однако ж нет, в предисловии там встречается булшит вроде "освоив algorithms, вы сможете делать такие увлекательные вещи что хрен оттащищь из-за компьютера"

что это, ФГМ или просто умение продавать?

На C++ вообще писать невозможно, если у тебя все в порядке с головой.

2 my mind он это приводит как не совсем удачный в сиду сложности пример. В качестве окончательного решения предлагается лямбда из буста. Хотя, возможно, я более позднюю редакцию читал.

>малыша обломали на собеседовании?

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

>для совсем простых вещей записать явный цикл выходит проще чем for_each (и понятней!)

Согласен. И, кажется, о том, что for_each() в большинстве случаев неудобен уже обсуждалось (не здесь, так на RSDN точно).

Можно использовать обычные циклы, BOOST::FOR_EACH или ждать foreach из нового стандарта.

> для совсем простых вещей записать явный цикл выходит проще чем for_each (и понятней!)

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

Вот только в _большинстве случаев_ гораздо удобнее использовать vector.Sort вместо своей реализации сортировки Хоара, так же как и реализацию многих других структур данных(pair, map, deque) и алгоритмов для работы с ними (find, insert, replace).

> Бгг. Сразу можешь сказать: "не используйте STL". И с тобой всё будет ясно.

ну хватает в природе мест, где использование STL будет не оптимально. зачем себя насиловать? где подходит - используем. где не подходит - не используем.

// wbr

> вопрос в том, какого хрена все это реализовано настолько неудобным способом?

Ради эффективности исполняемого кода пожертвовали многим другим. В остальном STL выглядит, конечно, убого по сравнению с теми же Java или .NET Collections. В общем, STL получилась уродливой и трудно-расширяемой, но зато очень быстрой.

>> Бгг. Сразу можешь сказать: "не используйте STL". И с тобой всё будет ясно.

> ну хватает в природе мест, где использование STL будет не оптимально.

Если ты не заметил, ветеран PHP-кодирования предложил использовать STL без итераторов %) Можешь назвать область, в которой использование STL оправдано, а итераторов - нет? :D

>я бы понял если бы автор сабжевой книги так и написал, честно -- мол на с++ можно писать программы естественным способом (т.е. преимущественно в функциональном стиле), но записывается это через жопу так что придется слегка придрочиться

сабжевый автор пишет на C++, и аудитория книги - программисты на C++; там во введении указано - на кого книга расчитана. так что нефиг газифицировать лужи без повода

>однако ж нет, в предисловии там встречается булшит вроде "освоив algorithms, вы сможете делать такие увлекательные вещи что хрен оттащищь из-за компьютера"

ну правильно пишет. в худшем случае после освоения algorithms человек перейдёт на boost, в лучшем - на LISP

>что это, ФГМ или просто умение продавать?

это твоё неумение читать книги

> Если ты не заметил, ветеран PHP-кодирования предложил использовать STL без итераторов %) Можешь назвать область, в которой использование STL оправдано, а итераторов - нет? :D

кхм. в такие дебри как то - что без чего - я не вдавался. впрочем, использование std::map "без итераторов" должно выглядеть весьма оригинально.

// wbr

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

Как надо осилить шаблоны для того чтобы поиметь для них ABI и раздельную компиляцию?

> Как надо осилить шаблоны для того чтобы поиметь для них ABI и раздельную компиляцию?

Для начала, нужно определить, что такое "ABI для шаблонов" %)

>Как надо осилить шаблоны для того чтобы поиметь для них ABI и раздельную компиляцию?

а как ты себе это представляешь? давай proof-of-concept - зафигачим :)

Да! Давно не было хорошего плюсосрача!

>Да! Давно не было хорошего плюсосрача!

ну так вперёд, делись сахарком

> сабжевый автор пишет на C++, и аудитория книги - программисты на C++; там во введении указано - на кого книга расчитана

кто такие "программисты на С++"?

это любой кто пишет на С++,
или тот кто кроме С++ ничего не знает?

>>Как надо осилить шаблоны для того чтобы поиметь для них ABI и раздельную компиляцию?

>а как ты себе это представляешь? давай proof-of-concept - зафигачим :)

Да без виртуальных машин в общем-то никак. Но то что есть в С++ - бесполезно, т.к в реальном мире клиент кода и библиотека разговаривают на разных версиях протокола, а протокол омерзителен. Прикрываться идеями опен-сорца тут не стоит, т.к некрасноглазый юзер не будет заниматься постоянной пересборкой на каждый чих. Делать extern "C" - прослойки тоже бесполезно, т.к это губит всю идею с абстракцией типов на корню. Следовательно, разработчик ООП-надстройки над С должен был помедитировать над этими проблемами и сконцентрировать внимание на рантайме и получить в итоге Objective C.

>> а как ты себе это представляешь? давай proof-of-concept - зафигачим :)

> Да без виртуальных машин в общем-то никак.

Давай с виртуальными машинами, не вопрос :D Но именно ABI.

> в реальном мире клиент кода и библиотека разговаривают на разных версиях протокола, а протокол омерзителен.

"Остапа понесло" (c)

>Но то что есть в С++ - бесполезно, т.к в реальном мире клиент кода и библиотека разговаривают на разных версиях протокола, а протокол омерзителен

будь добр пояснить эту вот фразу

а вообще интересно, насколько в C++ реализуемо data-driven программирование. ни разу не возникало потребности проверить

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

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

>это любой кто пишет на С++, или тот кто кроме С++ ничего не знает?

ммм...а где ощутимая грань? :)

>>> а как ты себе это представляешь? давай proof-of-concept - зафигачим :)

>> Да без виртуальных машин в общем-то никак.

>Давай с виртуальными машинами, не вопрос :D Но именно ABI.

Генерировать байт-код на стороне клиента по описанию шаблона? Мой коллега такое на жабе делал - по списку бизнес-правил генерировал жавский байткод и загружал его через класслодер. J/Invoke тоже работает в примерно таком ключе - по аннотации интерфейса делает в рантайме переходник который вызывает методы нативной либы.

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

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

некрасногзазый пользователь скачает просто бинарный плагин и прогамма его невозбранно подцепит поскольку для интеракции с плагинами у нее есть ABI.

>> Давай с виртуальными машинами, не вопрос :D Но именно ABI.

> Генерировать байт-код на стороне клиента по описанию шаблона?

Нихрена себе поняти об _ABI_ - со встроенным компилятором %) Ну ладно, излагай подробнее - зачем тут виртуальная машина, и какой именно код генерить :)

>некрасногзазый пользователь скачает просто бинарный плагин и прогамма его невозбранно подцепит поскольку для интеракции с плагинами у нее есть ABI.

херня какая-то, батенька...какое отношение система плагинов имеет к шаблонам и тому, вот что они компиляются? это более-менее ортогональные понятия, n'est-ce pas?

>Мой коллега такое на жабе делал - по списку бизнес-правил генерировал жавский байткод и загружал его через класслодер

так, а ну-ка поставь внятное ТЗ %) потому как то, о чём ты говоришь, делается очень многими методами. и в C++ тоже

>>> Давай с виртуальными машинами, не вопрос :D Но именно ABI.

>> Генерировать байт-код на стороне клиента по описанию шаблона?

>Нихрена себе поняти об _ABI_ - со встроенным компилятором %)

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

>А иначе никак - в той же Корбе например дается клиенту IDL, и он по нему генерирует код. Если интерфейс параметризировать, что в общем-то и призваны делать шаблоны, то клиенту и библиотеке понадобится компилировать новый код в рантайме для восприятия датаграмм идущих от противоположной стороны

а просто не использовать параметризованные интерфейсы для IPC (распределённого в том числе) религия не позволяет? шаблоны отдельно, взаимодействие отдельно

>>А иначе никак - в той же Корбе например дается клиенту IDL, и он по нему генерирует код. Если интерфейс параметризировать, что в общем-то и призваны делать шаблоны, то клиенту и библиотеке понадобится компилировать новый код в рантайме для восприятия датаграмм идущих от противоположной стороны

>а просто не использовать параметризованные интерфейсы для IPC (распределённого в том числе) религия не позволяет? шаблоны отдельно, взаимодействие отдельно

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

>>> Генерировать байт-код на стороне клиента по описанию шаблона?

>> Нихрена себе поняти об _ABI_ - со встроенным компилятором %)

> А иначе никак - в той же Корбе например дается клиенту IDL, и он по нему генерирует код.

Ну и причем тут CORBA? Параметризуемых модулей в ней нет (ну или не было в CORBA 2.x).

> Если интерфейс параметризировать, что в общем-то и призваны делать шаблоны, то клиенту и библиотеке понадобится компилировать новый код в рантайме

Ну то есть ты тоже пришел к выводу о том, что без компиляции по некторому описанию не обойтись? В Си++ так и делается, что не устраивает-то? :D

>> Если интерфейс параметризировать, что в общем-то и призваны делать шаблоны, то клиенту и библиотеке понадобится компилировать новый код в рантайме

>Ну то есть ты тоже пришел к выводу о том, что без компиляции по некторому описанию не обойтись? В Си++ так и делается, что не устраивает-то? :D

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

>Ну тогда получается что по факту мы имеем только те типы которые мы выставляем на внешние интерфейсы программы и параметризировать в ней в общем-то нечего.

бред. горячечный. всё, что относится к реализации в данном контексте - параметризуемо

>компиляция должна быть не только при сборке но и в рантайме.

...Либо должна быть ориентация на динамическую типизацию, что в общем-то и сделано в Objective C.

>>Ну тогда получается что по факту мы имеем только те типы которые мы выставляем на внешние интерфейсы программы и параметризировать в ней в общем-то нечего.

>бред. горячечный. всё, что относится к реализации в данном контексте - параметризуемо

Что параметризуемо? Мы имеем только те типы, которые получаются извне и отправляются вовне. Других нет.

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

у тебя очень странные представления о "реальном мире", равно как и притянутая за уши задача

у меня сейчас в подсистеме три достаточно сложных протокола (в частности, MOST) - и при том, что проект монстрообразный и полностью на плюсах - подобных проблем почему-то не возникает. ЧЯНТД?

если тебе нужна компиляция в рантайме - используй системы с JIT и будет тебе счастье; вот в том, что она тебе так уж нужна в текущей задаче, я очень сомневаюсь

>>Ну то есть ты тоже пришел к выводу о том, что без компиляции по некторому описанию не обойтись? В Си++ так и делается, что не устраивает-то? :D

>То, что библиотека и ее клиент в реальном мире всегда работают на разных версиях протокола,

"Наша песня хороша, начинай сначала" (c) Если у них разные версии протокола, то они, в общем случае, не смогут работать вместе. Это что, непонятно?

> и компиляция должна быть не только при сборке но и в рантайме.

Если так уж хочется, запусти компилятор перед dlopen :D

И вообще - речь шла об 'ABI для шаблонов'. Ты его сформулируешь или как? :D

>Что параметризуемо? Мы имеем только те типы, которые получаются извне и отправляются вовне. Других нет.

что за бред? система, состоящая из одного уровня абстракции? это что, hello world?