Изобретение велосипедов

[Igors]

Добрый день

Навеяно этим

Ну так посмотрите на реализацию в boost'е.. Boost всёже далеко не глупыми людьми разрабатывался.. И вообще, считаю, что нужно стремиться к этой философии заложенной там (в boost'е).. Во всяком случае, мне приходилось писать под себя нечто, аналогичное (что есть в boost'е),  лишь в очень-очень специфических задачах и то это па пальцам пересчитать..
Мораль в итоге такова:
Прежде чем изобретать свой велосипед (как рекомендуют тут асы 80 уровня) посмотрите на то, как это реализовано у тех, кто реально заслуживает авторитета  и уже потом, если в чём то объективно не согласны, создавайте своё, бессмертное)
Всё же, повторюсь,  boost далеко  не дураки писали..

Посмотрите как там, а потом уже делайте выводы) Надо оно вам али нет..)

Эта "парадигма" часто мелькает тут и там. Про "объективно не согласны" это автор из вежливости, сам он будет согласен с бустом во всем и всегда (что, на мой взгляд, плохо).  Вместо буста может быть нечто другое, напр крутой паттерн(ы), но суть то же самая: написание своего кода - это очень, очень плохо, программист ОБЯЗАН пользоваться готовыми решениями. Словом "велосипед" - это позор.

Я тоже хочу "воспользоваться готовым",  но почему-то редко получается. Вот задача которой я занимаюсь сейчас. Мои действия были:

- полез в буст, да, там прекрасная polygons (немногое чем я оттуда пользовался), но она 2D
- в CGAL то же самое - только 2D
- накачал 3D-boolean open-sources. Есть хорошие, напр "cork". Правда там все на лямбдах, ну ничего. И есть зависимость от др либы "mpir" с которой связываться совсем не хотелось бы. Тут типовая проблема: задачи "похожи", но есть и существенная разница. Не вдаваясь в тех детали, после 2-3 дней изучения исходников и сомнений пришел к выводу - работы с их переделкой под свои нужды никак не меньше.

И вот, в очередной раз, - велосипед. Что впрочем мое нормальное состояние и никакой трагедии в этом не вижу   Что я делаю не так? Недостаточно упорно искал? Нужно было продолжать гуглить! Но сколько? Неделю? Две? (а время-то идет). И почему оно "должно найтись"?

Почему др так лихо только и делают что "пользуют готовое" (ну судя по их словам), а у меня так выходит редко? 

Спасибо

[Old]

Словом "велосипед" - это позор.

В очередной раз не увидел, где m_ax говорит, что свой велосипед это позор. Покажите пожалуйста.

Вот я вижу, что он предлагает посмотреть, как уже люди делали.
Понимаете, сделать машину состояний это занятие на несколько минут. Самое важное и интересное, это придумать концепт, как диаграмму состояний удобно описать на C++, что бы все было понятно и легко расширяемо.
Если вы посмотрите, как сделано в предлагаемых библиотеках, то обнаружите, что описание диаграмм сильно отличаются. Где то удобней одно, где-то другое. Человеку предлагалось ознакомиться с опытом других и сделать так как ему будет удобно.

[Akon]

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

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

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

[Bepec]

В добавку к Akon:
У всех фирм свои стандарты. И свои велосипеды. И велосипеды велосипедов партнёров. Так что с точки зрения одного разработчика нет разницы, с чьим велосипедом работать

[vulko]

Словом "велосипед" - это позор.

В очередной раз не увидел, где m_ax говорит, что свой велосипед это позор. Покажите пожалуйста.

Вот я вижу, что он предлагает посмотреть, как уже люди делали.
Понимаете, сделать машину состояний это занятие на несколько минут. Самое важное и интересное, это придумать концепт, как диаграмму состояний удобно описать на C++, что бы все было понятно и легко расширяемо.
Если вы посмотрите, как сделано в предлагаемых библиотеках, то обнаружите, что описание диаграмм сильно отличаются. Где то удобней одно, где-то другое. Человеку предлагалось ознакомиться с опытом других и сделать так как ему будет удобно.

На самом деле, "супер макс" не предлагал сделать как человеку удобно, он предлагал взять готовое, т.к. это делали не дураки.
Действительно, изобретение велосипедов не лучшее занятие. Но в его словах четко прослеживается идея того, что надо пользоваться обязательно тем же бустом, т.к. он всяко лучше.
Да, быть может в плане структур данных он лучше. А в плане state machine... ?!

Но в одном я более чем уверен. Простые вещи иногда лучше сделать самому, при этом не изобретая велосипед, но делая все четко и ясно для любого программиста, читающего ваш код. Причина достаточно банальна - очень часто чужие реализации крайне нечитабельны, хоть и сделаны грамотно. Тот же буст сделан через жопу, в плане читабельности.
Если вам приходилось заниматься разработкой java кода, вы также согласитесь, что boost это полная Ж в плане восприятия кода.
Тут конечно не буст виноват, любые попытки сделать ООП апишки с красивыми интерфейсами на С++ в сравнении с аналогичными на жабе, выглядят крайне убого.

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

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

[kamre]

Тут конечно не буст виноват, любые попытки сделать ООП апишки с красивыми интерфейсами на С++ в сравнении с аналогичными на жабе, выглядят крайне убого.

Это как раз в Java все убого с примитивными generics, type erasure и хранением всего подряд в куче. Такого уровня абстракции с сохранением эффективности как в boost в Java просто не может быть. Даже .NET и то может больше чем Java предложить в этом плане.

[Akon]

Java много проще C++, отсюда более простое восприятие Java кода. Некоторые элегантные вещи, которые делаются на плюсах, на Jаva просто не мыслимы. Конечно, платой за эту элегантность является сложность.

[Igors]

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

Вот напр 3D, возьмем самые простые вещи

- точка, вектор (x, y, z)
- операции с ними, алгебра операторов, скалярное и векторное произведения
- полигон (в общем случае facet)
- матрицы (3x3 и 4x4)

Какой стандарт для этих (совершенно базовых и неизбежных) вещей? Мне об этом ничего не известно. Можно пойти и чуть дальше: покажите мне хотя бы 2 приложения использующие идентичный класс "вектор 3D". В общем, профессионализмом и не пахнет

И почему разговор сразу переводится на state machine, контейнеры и др? Для таких общих/стандартных вещей есть широкий выбор, грех не воспользоваться. Вот только почему пользуются далеко не всегда? Почему QVector, а не std::vector? И этот QList - махровый велосипед! Они явно не поняли идейной красоты и философии буста!! Однако рез-т у них очень даже неплохой. И др уважающие себя либы поступают аналогично. И я так вижу соображения нестандартности/непрофессионализма их нисколько не волнуют. Но вот когда человек пишет свой контейнер - так сразу "велосипед, ату его!!!". Конечно должны быть резоны, а не просто "желание пооригинальничать".

Но тема совсем о другом. Вот у меня немало работы - найти все пересечения в сцене, перестроить топологию, причем определенным образом и много еще чего. Каким образом буст (или др "готовые решения") мне может помочь? Не вижу. Ну да, я могу заменить самопальный allocator (в бусте наверняка есть и лучше), ну может что-то еще такого плана. Но мне сейчас это не помощь, а "еще одна работа", т.к. и то что есть устраивает.

И вот я пыхтю и пишу велосипед - а что делать если постоянно не везет с "готовыми решениями"?  

[kambala]

Какой стандарт для этих (совершенно базовых и неизбежных) вещей? Мне об этом ничего не известно. Можно пойти и чуть дальше: покажите мне хотя бы 2 приложения использующие идентичный класс "вектор 3D". В общем, профессионализмом и не пахнет

BLAS, разве нет?

[Igors]

BLAS, разве нет?

По "содержанию" все реализации идентичны (во всяком случае практически), это одна и та же геометрия 18-го века (если не раньше). Но я ни разу не видел "по форме", грубо говоря базового класса который использовался бы в 2 и более приложениях. Напр недавно был вопрос по libQGLViewer. Ну казалось бы если на Qt, то и надо юзать имеющийся QVector3D, но http://www.libqglviewer.com/refManual/classqglviewer_1_1Vec.html. И это правильное решение

[Old]

покажите мне хотя бы 2 приложения использующие идентичный класс "вектор 3D". В общем, профессионализмом и не пахнет

Вот смотрите:
Здесь описаны проекты, которые используют вектор из ogre: http://www.ogre3d.org/tikiwiki/tiki-index.php?page=projects+using+ogre
А здесь из SFML: https://github.com/LaurentGomila/SFML/wiki/Projects
Это на вскидку, если вы пошаритесь на github, то найдете еще 100500 разных проектов, использующих одинаковые библиотеки.

И почему разговор сразу переводится на state machine, контейнеры и др?

Не знаю, это вы начали этот разговор.

Для таких общих/стандартных вещей есть широкий выбор, грех не воспользоваться.

Тогда не понятно, для чего вы начали эту тему?

И этот QList - махровый велосипед! Они явно не поняли идейной красоты и философии буста!!

Когда появился QList, о boost еще даже не мечтали.

Но вот когда человек пишет свой контейнер - так сразу "велосипед, ату его!!!".

Кто вас так обижает все время? Неужели m_ax?

Каким образом буст (или др "готовые решения") мне может помочь? Не вижу.

Вы постоянно путаете два понятия: решить за вас или помочь вам написать решение. От этого у вас возникает желание периодически начинать такие темы.

И вот я пыхтю и пишу велосипед

Как и все остальные.

[m_ax]

Понимаете, сделать машину состояний это занятие на несколько минут. Самое важное и интересное, это придумать концепт...

Концепт.. Именно, я просто уже боюсь произносить здесь это слово, поэтому заменил его на "философия")

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

Почему, почему, всё что из вне, даже то, что действительно заслуживает внимания, воспринимается категорически в штыки? Что это вообще такое? Почему на буст такая реакция? Ведь я не заставляю/не принуждаю им пользоваться, просто рекомендую подсмотреть на то, как это реализовано там, тем более что это оправдано) Ведь это всегда полезно - сделать шаг назад и посмотреть на проблему с другой стороны..
Ну как же - подсмотрел, значит всё: лишил себя чего то творческого, обфусцировал своё сознание и способность к творческому мышлению.. Ну честно, смешно..(

[vulko]

Тут конечно не буст виноват, любые попытки сделать ООП апишки с красивыми интерфейсами на С++ в сравнении с аналогичными на жабе, выглядят крайне убого.

Это как раз в Java все убого с примитивными generics, type erasure и хранением всего подряд в куче. Такого уровня абстракции с сохранением эффективности как в boost в Java просто не может быть. Даже .NET и то может больше чем Java предложить в этом плане.

убого?))
это называется продуманно!

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

шарп кстати настолько похож на жабу, что бесполезно отрицать что создан он был явно в попытке достичь успеха жабы.

[vulko]

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

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

а что есть в плюсах? stl, boost... но все это очень разнородно. писалось разными людьми, и не воспринимается как единое целое.

Некоторые элегантные вещи, которые делаются на плюсах, на Jаva просто не мыслимы.

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

[kamre]

убого?))
это называется продуманно!

Конечно, убого! Как только хоть какой-то performance из Java надо выжимать, сразу вся ее стандартная библиотека на помоечку идет: http://java-performance.info/use-case-optimizing-memory-footprint-of-read-only-csv-file-trove-unsafe-bytebuffer-data-compression/

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

Пока не нужен performance и используются готовые кубики, из которых собирается очередной enterprise, оно так и есть. Например, для задача типа таких как у Igors никакие "удобства разработчика" не позволят решать их эффективно на java.