Здравствуйте, smeeld, Вы писали:
IB>>А многоэтажные шаблоны это разве не типовой код?
S>Здешняя публика считает, что они недопустимы, так как могут быть не понятны двоечникам, невесть каким образом затесавшимся в проект.
Шаблоны отлично подходят для многих вещей, в частности когда конкретный тип чего-то либо неизвестен, либо предполагается его менять или использовать несколько типов. Но часто возникает соблазн вообще всё на шаблонах написать. Объединить необъединяемое. Если после использования шаблонов код не стал проще, то значит их не надо использовать.
Хорошо, когда есть несколько классов, созданных с использованием шаблонов, про которые все знают и они упрощают жизнь. Но когда для понимания какого-то кода надо лезть в реализацию этих шаблонов и при этом они нигде не переиспользуются, то что-то здесь не так.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Самое печальное, что это влияет на рабочие отношения. Чувак, который тащится от сложности и тащит ее в общий проект и превознемогает, чаще всего не понимает что он делает что-то не то, при этом еще относится снисходительно к коллегам, которые так не делают. На фоне таких людей мы с остальными коллегами выглядим статистами (по крайней мере для таких людей). По факту, подобные адепты сложности почти не добавляют ничего в проект, постоянно что-то превознимогают, но потом оказывается, например, что несколько дней работы ушло коту под хвост только ради какой-то ерунды, которая никому не нужна. Как с такими быть?
Частный случай неопытности. Если рядом есть квалифицированные коллеги, то с опытом пройдёт. Я периодически наблюдаю похожую картину. При разработке какой-либо функциональности неопытный программист пытается сделать это максимально гибко. На пальцах — если надо спроектировать дом, то он предусмотрит, чтобы его можно было и в конюшню превратить, и если что жить там инопланетянам с щупальцами, а водопроводные трубы сделаны так, что их можно будет в соседнем проекте использовать в качестве газопровода. В итоге код превращается непонятно во что, его становится сложно поддерживать и он не понятный. И самое главное в нём нет никакой гибкости. Через некоторое время оказывается, что в созданном доме неудобно жить людям, там нет лифта, и вкорячить его туда стоит просто невероятных усилий.
Здравствуйте, chaotic-kotik, Вы писали:
S>>Интересно было бы посмотреть на примеры простого кода, который решает сложные задачи.
CK>http://www.sequitur.info/ you're welcome
глобальные переменные;
ручное управление памятью в классе rules (std::auto_ptr/std::unique_ptr? не не слышали);
в классе rules не определены и не запрещены конструкторы/операторы копирования/перемещения. Появление бага с double free -- это лишь вопрос времени;
в классе rules нет отметки const даже у методов, которые используются явно как getter-ы
непоследовательность в именовании сущностей внутри rules: rules::count, но rules::Usage.
Здравствуйте, _Artem_, Вы писали:
F>>а вот и корень всех проблем шаблонов — жадность! _A_>Блин, ну меру, конечно, нужно знать. Но когда требования меняются, например, в играх, то более гибкая архитектура позволяет намного проще изменять поведение.
а можно пример?
а то, насколько я знаю, если меняются требования, то проще выкинуть всё, чем натягивать сову на глобус. либо самому диктовать условия.
S> глобальные переменные; S> ручное управление памятью в классе rules (std::auto_ptr/std::unique_ptr? не не слышали); S> в классе rules не определены и не запрещены конструкторы/операторы копирования/перемещения. Появление бага с double free -- это лишь вопрос времени; S> в классе rules нет отметки const даже у методов, которые используются явно как getter-ы S> непоследовательность в именовании сущностей внутри rules: rules::count, но rules::Usage. S>S>Такая простота хуже воровства.
добавление ползунков^W ограничений и квалификаторов в язык — это от нехватки культуры разработки.
A>Частный случай неопытности. Если рядом есть квалифицированные коллеги, то с опытом пройдёт.
А если рядом коллеги, которые сами маньяки описывать всё шаблонами, и в их квалификации сомнений нет-они свои закрытые реализации stl в своё время пилили, когда стандартный из дистров ещё под стол ходил (много не было реализовано или реаизовано с багами, что было на рубеже 90-2000-ых)?
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, alpha21264, Вы писали:
A>>Тебе не кажется, что обзывать оппонентов двоечниками — неконструктивный подход?
S>Покажите участок строки, в котором обзывал оппонентов двоечниками.
Здешняя публика считает, что они недопустимы, так как могут быть не понятны двоечникам, невесть каким образом затесавшимся в проект.
A>>Всю жисть считалось, что программы надо писать просто.
S>Скажите это разрабам либ из boost.
Здравствуйте, so5team, Вы писали:
A>>Всю жисть считалось, что программы надо писать просто. A>>Задачи при этом можно решать сложные, но программы должны быть простыми.
S>Интересно было бы посмотреть на примеры простого кода, который решает сложные задачи.
Мне нравятся исходники библиотеки Qt.
Реально просто разобраться кто что делает. Я даже там кое-что правил.
Шаблоны там тоже есть, но они используются уместно.
A>Здешняя публика считает, что они недопустимы, так как могут быть не понятны двоечникам, невесть каким образом затесавшимся в проект.
Ну и где тут обзывание оппонентов? Тут оппоненты называются "здешней публикой", с которыми упомянутые двоечники никак и нигде не связываются.
S>>Скажите это разрабам либ из boost.
A>Когда встречусь, скажу. Реально уроды.
Им Ваше мнение будет безразлично. Знаете, это чуваки такого уровня. И если возникнет вопрос о том, к чьему мнению прислушиваться (в том числе и касательно шаблонов), то подавляющее большинство выберет их точку зрения.
Здравствуйте, alpha21264, Вы писали:
A>Мне нравятся исходники библиотеки Qt.
Во-первых, в чем там сложность?
Во-вторых, использованный Qt подход (активное использование динамической памяти, навязанное системой владения Qt; реализация механизма сигналов-слотов) сказывается на производительности из-за чего в случаях, где от GUI-тулкита требуется отзывчивость и легковестность, Qt предпочитают не использовать. Так что простота реализации Qt неразрывно связана с более высокими требованиями к ресурсам.
В-третьих, в таких случаях простота кода компенсируется ее объемом. Если задачу можно решить в 100KLOC "сложного" кода или в 500KLOC "простого" кода в стиле Qt, то что экономически целесообразнее? При том, что продуктивность программиста составляет порядка 100LOC отлаженного кода в день.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, chaotic-kotik, Вы писали:
S>>>Интересно было бы посмотреть на примеры простого кода, который решает сложные задачи.
S>
S> глобальные переменные; S> ручное управление памятью в классе rules (std::auto_ptr/std::unique_ptr? не не слышали); S> в классе rules не определены и не запрещены конструкторы/операторы копирования/перемещения. Появление бага с double free -- это лишь вопрос времени; S> в классе rules нет отметки const даже у методов, которые используются явно как getter-ы S> непоследовательность в именовании сущностей внутри rules: rules::count, но rules::Usage. S>
S>Такая простота хуже воровства.
S>Этот пример порвался, давайте следующий.
это на самом деле ерунда, легко исправить, ты же просил простой код, решающий слжные задачи — вот, пожалуйста. код хоть и говно (т.к. написан академиками), но написан очень просто, но ты попробуй разберись с sequitur-ом для начала
Здравствуйте, so5team, Вы писали:
A>>Мне нравятся исходники библиотеки Qt.
S>Во-первых, в чем там сложность?
В том же в чём обычно — решает задачи, которые никто другой решить не может.
Это реально кросс-платформенная библиотека, которая реньше делала интерфейс,
а теперь похоже, что вообще всё — то есть изображает из себя операционную систему.
S>Во-вторых, использованный Qt подход (активное использование динамической памяти, навязанное системой владения Qt; реализация механизма сигналов-слотов) сказывается на производительности из-за в случаях, где от GUI-тулкита требуется отзывчивость и легковестность, Qt предпочитают не использовать. Так что простота реализации Qt неразрывно связана с более высокими требованиями к ресурсам.
Чёт не слышал о такой проблеме. Использовал Qt с 2000 года и с Pentium II 266 МГц.
Ты её случайно не придумал?
Если мы всё ещё говорим про шаблоны (темплейты), то каким образом шаблоны могут помочь в этой ситуации?
S>В-третьих, в таких случаях простота кода компенсируется ее объемом. Если задачу можно решить в 100KLOC "сложного" кода или в 500KLOC "простого" кода в стиле Qt, то что экономически целесообразнее? При том, что продуктивность программиста составляет порядка 100LOC отлаженного кода в день.
Экономически целесообразнее то, что программист быстрее поймёт и сделает.
Код, который я предложил вот тут: https://rsdn.org/forum/cpp/7188421.1
Здравствуйте, alpha21264, Вы писали:
A>В том же в чём обычно — решает задачи, которые никто другой решить не может.
Никто? FLTK, wxWidgets, FOXToolkit, Nana, Ultimate++. Как минимум из известных и используемых.
A>Чёт не слышал о такой проблеме. Использовал Qt с 2000 года и с Pentium II 266 МГц.
Может просто вам не приходилось делать действительно отзывчивые GUI приложения?
A>Ты её случайно не придумал?
Нет.
A>Если мы всё ещё говорим про шаблоны (темплейты), то каким образом шаблоны могут помочь в этой ситуации?
Сделать Qt быстрее? Это вряд ли. Там модель владения менять нужно принципиально.
Поинт был в другом: Qt как-то слабо подходит на пример сложной задачи решаемой простым кодом.
A>Код, который я предложил вот тут: A>https://rsdn.org/forum/cpp/7188421.1
A>Не только простой, а меньше твоего по объему. A>То есть ты пишешь сложный код, который даже по объёму больше. A>Выбор очевиден.
Все, что можно было сказать цензурно по поводу вашего говнокода уже было сказано. Вам нравится плодить неподдерживаемую и непроверяемую компилятором лапшу и ваш работодатель с этим согласен -- нет проблем. Но говнокодом это быть не перестает.
Здравствуйте, chaotic-kotik, Вы писали:
CK>это на самом деле ерунда, легко исправить, ты же просил простой код, решающий слжные задачи — вот, пожалуйста. код хоть и говно (т.к. написан академиками), но написан очень просто, но ты попробуй разберись с sequitur-ом для начала
Тут не мешало бы провести некую грань между нормальным кодом, который кому-то может казаться сложным, и якобы простым кодом, который суть говнокод. А то может оказаться так, что кто-то пишет говнокод просто потому, что не может осознать, в чем преимущество const-методов, но начинает плакать о сложности когда встречает что-то вида:
class rules {
std::unique_ptr<symbols> guard;
...
public:
[[nodiscard]] int freq() const noexcept { return count; }
...
}
S>Тут не мешало бы провести некую грань между нормальным кодом, который кому-то может казаться сложным, и якобы простым кодом, который суть говнокод. А то может оказаться так, что кто-то пишет говнокод просто потому, что не может осознать, в чем преимущество const-методов, но начинает плакать о сложности когда встречает что-то вида: S>
— он использует логику первого порядка, т.е. только вычисления над данными, результат зависит только от данных, нет никаких предикатов/коллбэков и тд
— работает с конкретными типами, в данном случае на строках типа char*, не на обобщенных последовательностях токенов, тип которых вычисляется, а массивы обрабатывает
сам код при этом решает сложную задачу, т.к. реализуемый алгоритм сложен, а граф возможных состояний очень большой, рекурсия и куча ветвлений
Здравствуйте, chaotic-kotik, Вы писали:
CK>я привел этот код в пример потому что:
Но по факту вы привели пример говнокода, который бы не прошел ревью ни в одной нормальной команде. А если бы этот код был написан нормально, то посчитали бы его простым?
Здравствуйте, so5team, Вы писали:
S>В-третьих, в таких случаях простота кода компенсируется ее объемом. Если задачу можно решить в 100KLOC "сложного" кода или в 500KLOC "простого" кода в стиле Qt, то что экономически целесообразнее? При том, что продуктивность программиста составляет порядка 100LOC отлаженного кода в день.
если перестать засирать всё неуместными шаблонами и прочим мусором, то продуктивность резко повышается.
поэтому 500клок кода — предпочтительней с точки зрения экономики проекта.
Здравствуйте, neFormal, Вы писали:
F>если перестать засирать всё неуместными шаблонами и прочим мусором, то продуктивность резко повышается. F>поэтому 500клок кода — предпочтительней с точки зрения экономики проекта.
Почему-то по умолчанию подразумевается, что сложный код пишут ради диверсии. Мол, молодые дурачки, которые еще пороху не нюхали, начитались Александреску, изучили Boost.Hana и айда клепать шаблоны направо и налево.
Тогда как объемный, но простой код пишут умудренные опытом и многолетним самосовершенствованием ветераны, которые прошли огонь, воду и медные трубы, которые все делают исключительно качественно, взвешенно и никогда не ошибаясь.
Здравствуйте, so5team, Вы писали:
F>>если перестать засирать всё неуместными шаблонами и прочим мусором, то продуктивность резко повышается. F>>поэтому 500клок кода — предпочтительней с точки зрения экономики проекта. S>Почему-то по умолчанию подразумевается, что сложный код пишут ради диверсии. Мол, молодые дурачки, которые еще пороху не нюхали, начитались Александреску, изучили Boost.Hana и айда клепать шаблоны направо и налево.
это люди без ответственности. часто немолодые дурачки, но необязательно.
обычно у них завышенные впечатления о собственной разумности, плохое понимание предметной области, неспособность оценивать трудозатраты, неумение ясно выражать свои мысли и пубертатный характер.
S>Вы сами из каких будете?
