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

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

A_A>>Поэтому нужен баланс между простотой и универсальностью решения.
E>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?

А какие ещё языки предназначены для создания библиотек?

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

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


R>У них абсолютно одинаковая семантика — "создать реализацию интерфейса ISome для переданного значения".
R>Ну так как бы ты это решил?


Если нет больше подробностей, то я ответил уже как бы я это решил
Обычно такая нужда (перегружать функции по каким-то формальным принципам) возникает когда мы хотим эту функцию потом позвать из шаблона.
У меня обычно таких желаний не возникает. Я согласен, что если всё усложнить, всюду завести шаблоны и т. д., то такая нужда возникнет и ты как миленький или заведёшь себе велосипед какой или пойдёшь компилять на своём компиляторе boost. Никуда не денешься. Это плата за усложнение кода. Так как реально в языке это всё хреново поддержано, то всё быстро обрастает нереально сложными костылями.
Так понятно?
STL, boost и Loki не дураки же писали. Просто людям нравится программировать с шаблонами, при этом они стараются применять их везде, где это хоть зачем-то нужно. Так как шаблоны в C++ спроектированы хреново, то приходится рожать продвинутые шаблоны, для того, чтобы и они нигде не тёрли, и в результате вместо дублирования небольшого куска кода, получается мегабайт бреда, который якобы "под капотом".
ИМХО это всё неоправданно

В частности, можно было, например, реализовать как-то привязку одной из двух реализаций к списку типов, совсем немного продублировав код. Очень может быть, что так будет значительно проще, чем с mpl

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

R>1. Видел в проекте (благо не в моём) самопальный умный указатель — зрелище достаточно убогое. Часть состояния открытая. Не защищён от большинства неправильных использований. Не обеспечивает безопасноть относительно возникновения ошибок. И т.д.

Согласен, но мне кажется, что часть таких ошибок некритична, (скажем защита от плохого использования не всегда нужна), а часть происходит от общей низкой квалификации. Но в любом случае умный указатель -- это довольно древняя идея. И мне кажется, что она не идея А. Во всяком случае есть много реализаций умных указателей, которые вовсе не являются продвинутыми шаблонами.
R>2. Видел много примеров плохого дизайна, когда люди не разделял ортоганальные аспекты. А валили всё в одну большую кучу.
Плохого дизайна я видел часто много. Но вот именно от того, что они не применили Loki я что-то ещё не разу не пожалел
Хотя я согласен, что размышление над книжклй в целом полезно. Но рамышление должно быть направлено в правильную сторону. Не "как бы этоприменть?", а "где бы это могло бы упростить код?"

R>Дело не именно в А. Дело в том, что люди пытались делать все очень просто, как в лабораторной в институте. Я бы даже сказал наивно. Со временем это аукалось.
Это ясный пень что аукнется. Навернео они ещё и проетированием своих изделей не занимались...

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

R>Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым?
Это отдельная долгая тема. В целом можно рассматривать такое свойство кода, как сопровождаемость и возможность переиспользования.
Ну типа сколько в среднем занимает что-то сделать с кодом. Чем сумма меньше, тем сопровождаемость больше

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

E>>Ну в целом подход похвальный. Но есть две беды.
E>>1) Очень уж неудобный язык описания моих желаний
R>Есть немного. Покрайней мере непривычный.

E>>2) Компилятору-то я может и объясню, но лучше бы объяснять тому, кто будет этот код поддерживать
R>В чём проблема?
смотри пункт 1

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

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

A_A>>>Поэтому нужен баланс между простотой и универсальностью решения.
E>>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?

R>А какие ещё языки предназначены для создания библиотек?

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

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

А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))

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

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

E>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.


I>И в большинстве случаев лучше на Java, а не на C++.

Да, так точно — все должно быть примерно просто и без лишних наворотов. А к тому же лучше всего было бы не писать один и тот же код по сотне раз, для чего в С++ и были введены шаблоны: C++ STL лучшее этому доказательство. А если при этом плевать на используемые ресурсы, то как нельзя лучше подойдет нечто вроде Java.

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

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

КЛ>>>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт)
E>>Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз?
E>>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.

J>Вот здесь присоединяюсь.
J>На мой взгляд, этот паттерн — один из самых неудачных.
Знаешь, Брюс Эккель тоже так считает — он прям в своей книжкке "Философия С++" так и написал об этом...

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

LVV>Знаешь, Брюс Эккель тоже так считает — он прям в своей книжкке "Философия С++" так и написал об этом...

Какой я умный, оказывается
Что, книжка стоит того, чтоб ее прочитать?

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

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

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

A_A>>>>Поэтому нужен баланс между простотой и универсальностью решения.
E>>>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?

R>>А какие ещё языки предназначены для создания библиотек?

E>Ну, скажем дельфи
Нет

E>Но вообще библиотек я знаю вообще много на каких языках. Скажем на fortran.
E>А вот стандартная библиотека, или какое-то её подобие есть вообще практически во всех языках
Отношения к делу не имеет. В прикладном языке и стандартная библиотека соответствующая.

E>А merge я вот что-то не припомню. Видимо не было на него пока что спроса всё-таки
Это языки совсем другие.

Твоя цитата:

так что я с радостью выбросил бы и итераторы и отсутсвие проверок в самом частотном доступе к элементу и т. д.

Советую почитать Страуструпа про язык с++. Ты сейчас предложил примерно следующее "А давай в java введём ассемблерные вставки".

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

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

R>>1. Видел в проекте (благо не в моём) самопальный умный указатель — зрелище достаточно убогое. Часть состояния открытая. Не защищён от большинства неправильных использований. Не обеспечивает безопасноть относительно возникновения ошибок. И т.д.

E>Согласен, но мне кажется, что часть таких ошибок некритична, (скажем защита от плохого использования не всегда нужна),
Ну да, если работы уже мало. То что бы не уволили надо писать код с ошибками, что бы потом было что делать
Или как ты сам говорил, если цель программиста сорвать проект, то тоже, конечно можно не защищать от неправильного использования.


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

Зато они не позволяют за 5 минут поменять какой-то аспект программы.
Ты спрашивал про опыт использования Loki — недавно воспользовался бонусом Loki — написав 10 строк кода и потратив 10 минут, изменил способ shedul'ирования всех синглтонов на разрешение. При этом написал именно то, что требовалось семантически — стратегию shedul'ирования на разрушение. При этом не было ни одной ошибки. При этом поменялось всё сразу и везде, без нудного поиска всех мест и вспоминания при запуске "ах, да ещё здесь забыл поменять".При этом не надо было затрагивать другие аспекты программы.


R>>2. Видел много примеров плохого дизайна, когда люди не разделял ортоганальные аспекты. А валили всё в одну большую кучу.
E>Плохого дизайна я видел часто много. Но вот именно от того, что они не применили Loki я что-то ещё не разу не пожалел

Именно применение Loki не обязательно.



R>>Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым?
E>Это отдельная долгая тема. В целом можно рассматривать такое свойство кода, как сопровождаемость и возможность переиспользования.
E>Ну типа сколько в среднем занимает что-то сделать с кодом. Чем сумма меньше, тем сопровождаемость больше


Именно для этого и были придуманы шаблоны. Советую догонть время, а не считать до сих пор на счётах.

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

E>Здравствуйте, Anton V. Kolotaev, Вы писали:

E>>>Казалось бы граф. движок не должне быть сверхсложен архитектурно.
AVK>> Интересно, на чем основано это мнение?

E>Ну, скажем так, он дожен быть намного проще ОС, например.

В нектором роде, он и есть замена OC
Особенно движок типа небулы, который не просто графический движок, а скорее портируемый
framework для игр.

E>Нет? Возможно я неправильно понгимаю, что скрывается за словми "графический движок"

наверно

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

Не знаю об опыте использования именно Loki, но вот об ОЧЕНЬ успешным опытом внедрения его идей я пользуюсь почти в каждом проекте.
Это ATL.
Кто не верит — смотри в исходники. Самый простой пример стратегии в ATL — DefaultThreadTraits. Используется как параметр шаблона CThreadPool.
Вот так вот ...

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

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

LVV>>Знаешь, Брюс Эккель тоже так считает — он прям в своей книжкке "Философия С++" так и написал об этом...

J>Какой я умный, оказывается
J>Что, книжка стоит того, чтоб ее прочитать?
Первый том — ликбез для совсем новичков... Хотя очень близко к стандарту...
Второй том — ликбез для начинающих профессионалов...
Там есть основы, как делать CppUnit, естественно, про шаблоны и обобщенное программирование, STL довольно подробно... Основы паттернов — на элементарных примерах...
В общем, как раз — как только научился основам С++ — первая книжка после этого...
Профессионалам — скучно...

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

E>>Согласен, но мне кажется, что часть таких ошибок некритична, (скажем защита от плохого использования не всегда нужна),
R>Ну да, если работы уже мало. То что бы не уволили надо писать код с ошибками, что бы потом было что делать
R>Или как ты сам говорил, если цель программиста сорвать проект, то тоже, конечно можно не защищать от неправильного использования.
Ну защита от неправильного использования нужна, ИМХО, только если кто-то так реально ошибается.
Пртсто часто так выходит, что вреда от "защиты от всех мыслемых возможных проблем" намного больше, чем пользы

R>Зато они не позволяют за 5 минут поменять какой-то аспект программы.
R>Ты спрашивал про опыт использования Loki — недавно воспользовался бонусом Loki — написав 10 строк кода и потратив 10 минут, изменил способ shedul'ирования всех синглтонов на разрешение. При этом написал именно то, что требовалось семантически — стратегию shedul'ирования на разрушение. При этом не было ни одной ошибки. При этом поменялось всё сразу и везде, без нудного поиска всех мест и вспоминания при запуске "ах, да ещё здесь забыл поменять".При этом не надо было затрагивать другие аспекты программы.

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

R>>>Сопровождение и развитие — это относится к проекту, а касательно кода? Т.е. какие требования к коду, что бы проект был сопровождаемым и развиваемым?
E>>Это отдельная долгая тема. В целом можно рассматривать такое свойство кода, как сопровождаемость и возможность переиспользования.
E>>Ну типа сколько в среднем занимает что-то сделать с кодом. Чем сумма меньше, тем сопровождаемость больше

R>Именно для этого и были придуманы шаблоны. Советую догонть время, а не считать до сих пор на счётах.
За совет спасибо, хотя он и кажется мне немного хамским , но я таки верю, что ты это из добрых чувств написал.
Но в целом для чего кем-то были придуманы шаблоны -- проблема его биографии. Тем более, что, скажем, STL, ИМХО, был придуман в основном из соображений "гибкости" и "красоты". На мой взгляд оба критерия обычно контрпродуктивные. Во всяком случае с сопровождаемостью напрямую никак не связанные
Для нас важно что же выходит, когда продвинутые шаблоны применяют на практике.
Вот ещё раз напишу тебе, что ни разу ещё не встретил случая, чтобы писанный по месту шаблон потом смогли без весьма продвинутого гемора переиспользовать

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

A_A>>>>>Поэтому нужен баланс между простотой и универсальностью решения.
E>>>>Конечно, просто мне кажется, что в STL баланс неоправданно смещён в сторону универсальности. Вот, скажем, в каких языках было нужно реализовывать алгоритм merge в библиотеке?
R>>>А какие ещё языки предназначены для создания библиотек?
E>>Ну, скажем дельфи
R>Нет
Как так нет? Разве дельфи не славится своим "компонентным программированием"?

E>>Но вообще библиотек я знаю вообще много на каких языках. Скажем на fortran.
E>>А вот стандартная библиотека, или какое-то её подобие есть вообще практически во всех языках
R>Отношения к делу не имеет. В прикладном языке и стандартная библиотека соответствующая.

Очень хорошо. Где есть merge-то?

E>>А merge я вот что-то не припомню. Видимо не было на него пока что спроса всё-таки
R>Это языки совсем другие.
В чём другие? Какие такие задачи часто решают на C++ с продвинутыми шаблонами, что merge нужен, а в других языках не нужен?

R>Твоя цитата:
R>

R>так что я с радостью выбросил бы и итераторы и отсутсвие проверок в самом частотном доступе к элементу и т. д.

R>Советую почитать Страуструпа про язык с++. Ты сейчас предложил примерно следующее "А давай в java введём ассемблерные вставки".
-1
И за этот совет спасибо. Но он немного запоздал. Да и аналогия мне не ясна.

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

E>>>>Казалось бы граф. движок не должне быть сверхсложен архитектурно.
AVK>>> Интересно, на чем основано это мнение?

E>>Ну, скажем так, он дожен быть намного проще ОС, например.

FR>В нектором роде, он и есть замена OC
FR>Особенно движок типа небулы, который не просто графический движок, а скорее портируемый
FR>framework для игр.

E>>Нет? Возможно я неправильно понгимаю, что скрывается за словми "графический движок"

FR>наверно

Ну, тем не меее, в ОС пока что как-то неплохо выходило обходиться без шаблонных наворотов

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

K>Не знаю об опыте использования именно Loki, но вот об ОЧЕНЬ успешным опытом внедрения его идей я пользуюсь почти в каждом проекте.
K>Это ATL.
K>Кто не верит — смотри в исходники. Самый простой пример стратегии в ATL — DefaultThreadTraits. Используется как параметр шаблона CThreadPool.
K>Вот так вот ...

Я согласен, что ATL не так уж плоха, кстати. Но всё-так тоже несколько переусложнено там всё.

Стратегии Loki и стратегии ATL это далеко не одно и то же, хотя и служат для схожих целей, и в чём-то похожи.

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

E>2) Под OS Linux если вы пишете библиотеку или даже SB-шку, всем компонентам доступны все символы.
E>Это приводит к тому, что если в двух частях программы используются разные реализации STL, то всякие приватные шаблонные потроха начинают конкурировать по именам. Нарушается ODR собственно говоря. А так как нарушители шаблонные, то линкер это дело пропускает.
E>Так что какие-то случайные места проекта от сборки к сборке (или даже от загрузки к загрузке) начинают сбоить из-за того, что в данном конкретном месте взялась не та версия потрохов.

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

Легкий оффтопик: данная проблема не имеет ничего общего с шаблонами, строго говоря. Пересечение динамических имен может случится и на обычных функциях. Назвали два чувака в разных библиотеках функцию getRecordCount одинаково — и добро пожаловать в gdb. Решается с помощью version scripts для дисциплинированных или при помощи опции линкера -Bsymbolic для ленивых.