Мысли об обобщенном программировании, шаблонах и UML

[Utkin]

Например те же умные указатели, есть несколько стратегий поведения:

Для справки: умные указатели есть в дельфи и без обобщеннного программирования (при адресации строк). Это две независимые концепции. И не стоит их смешивать.

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

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

У меня под плюсами гораздо больше ^^

Врядли. Объективно c# в данном плане круче. Это не для холивара.

Я лично не понимаю всех этих разговоров про отсутствие сборщика мусора в C++.

Значит Вы недостаточно осведомлены в современных тенденциях в программировании. Что уже тут говорить о концепциях обобщенного программирования? Это объясняет многие вещи которые Вы до сих пор не понимаете или не хотите понимать.

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

ООП уже наступило на эти грабли. Нет, чисто для сбора бабла идея удачная. Для программирования нет.

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

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

Лично я этого тоже до конца не представляю, но цель сделать все максимально просто и прозрачно.

Цель ООН - мир во всем мире. На деле перераспределить нефть так, чтобы США осталась в значительном плюсе . Отсутствие четкого механизма всегда означает зло. Запомните: благими намерениями вымощена дорога в ад. Тысячи человеческих жизней подтвердили это.

Многим просто лень копаться и пишут свои велосипеды

Детский лепет. Ни один здоровый координатор проекта не допустит этого.

При добавлении нового непонятно чего придется переписывать все предыдущие классы.

Здесь все зависит от частных случаев. Вы в очередной раз доказали что отлично умеете читать, но не имеете приемлимого опыта работы в команде.

Впрочем я уже программировал на C# и на ruby и даже литературу по scheme читал(scheme показался крайне отвратительным).

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

Тем более я существую под Linux, а mono знаете ли ...

А Моно знаете ли отличная вещь, которая отличается тем, что Визуал Студио не запускается . И не понимание моно опять же минус в Вашу сторону .

[Smitt&Wesson]

Сообщение от Kostia

Пишу под влиянием лекций про UML, прочтения книги "Современное проектирование на C++" Андрей Александреску и многого другого.

А давайте вместе покурим. Думаю, мыслей появится ещё больше.

Положим что существует общий стандарт для обобщенного программирования

После этой фразы, вообще дальше читать не стал. Пополз под стол...
Blondy, ну я в институте батаном был. Тащил на себе группу в 25 человек. И чё? "Любимчики" сдавали на 4-5, а мне тройки ставили. Чё, рожей не вышел? Да пошли они...
Сейчас я освободился от всей этой ахинеи. Я счастлив.

[Utkin]

Blondy, ну я в институте батаном был. Тащил на себе группу в 25 человек. И чё? "Любимчики" сдавали на 4-5, а мне тройки ставили. Чё, рожей не вышел? Да пошли они...
Сейчас я освободился от всей этой ахинеи. Я счастлив.

Не знаю причем здесь обобщенное программирование, но чувствую, что наших бьют . Короче, Blondy, если у Вас не любовь с Smitt&Wesson, то я на его стороне и Вам не поздоровится .

[pu4koff]

Сообщение от Kostia

По сути у нас всего 1 класс smart_ptr, но мы сами задаем по какой стратегии он будет работать.

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

Сообщение от Kostia

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

Сейчас модно говорить, что правильно отделять данные от их представления и уж тем более не задумываться при проектировании о дальнейшей реализации. На деле имеем, что одно от другого очень плохо отделяется (логика от данных в том числе). Затыкается всё это дело по возможности всяким метапрограммированием, кодогенерацией,... В тот же С++ не все плюшки в стандарт попадают, а только те, что ясны в плане реализации. То, что плохо реализуется или может привести к неоднозначностям, не вносят в стандарт, хоть это могут быть и очень полезные вещи для пользователей языка.

Сообщение от Kostia

Я лично не понимаю всех этих разговоров про отсутствие сборщика мусора в C++. Кто кроме студентов в наше время может впиндюрить int *array = new int[50];?

Указатели хоть и "умные" есть, но они таки в кавычках умные. В больших проектах тяжело следить за удалением объектов. В том числе, из-за этого на плюсах нет целых классов фреймворков. Например, я не видел ни одной ORM. Работа с указателями в прямых руках и при наличии достаточного времени - это более чем хорошо, но в реальности порождает трудноуловимые ошибки.

Сообщение от Kostia

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

На самом деле не очень то и придумано. Тот же ООП толком никак не устаканится и не придет к общему знаменателю. Мысль у людей есть, но как её довести до ума, никак не придумают.

Сообщение от Kostia

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

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

Сообщение от Kostia

Лично я этого тоже до конца не представляю, но цель сделать все максимально просто и прозрачно.

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

Сообщение от Kostia

Многим просто лень копаться и пишут свои велосипеды
Автогенерация кода частично решает эту проблему

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

Сообщение от Kostia

С UML плохой пример, просто именно он меня и натолкнул на идею проектирования и одновременной реализации программы.

Есть такая штука isagraf - для программирования контроллеров. Там в одном из языков есть такая тема, что на верхнем уровне рисуется эдакая блок-схема, а уже реализация каждого блока пишется на чем-то похожем на паскаль. Там это оправдано, т.к. важны алгоритмы. В большинстве же прикладных программ для ПК пользы от схем будет мало, т.к. алгоритмов с гулькин нос, а те, что есть, реализованы в сторонних фреймворках.

Сообщение от Kostia

Система становится жесткой и не расширяемой. При добавлении нового непонятно чего придется переписывать все предыдущие классы.

В студенчестве писал векторный редактор. Никаких паттернов я тогда не слышал и Александреску не читал. Добавление любой новой 2-мерной фигуры заключалось в наследовании нового класса от базового и перегрузке виртуальных методов. Каждый класс сам себя рисовал на холсте, сам мог проверять на пересечение с другой фигурой и прочее. Базовый класс был практически интерфейсом для хранения в одной коллекции всех фигур. Стратегии заменялись множественным наследованием или жестко фиксировались в методах типа:

bool IsContainer() { return false; } // Означает, что объект данного класса не может быть контейнером для другого

[Kostia]

Для справки: умные указатели есть в дельфи и без обобщеннного программирования (при адресации строк). Это две независимые концепции. И не стоит их смешивать.

И какую же стратегию поведения они используют? И могу ли я ее поменять?

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

Вы меня не поняли, я имел ввиду нечто такое:
tree<tree<tree<...>>>
или
matrix<polynom<fraction<double>>> a, b;
a *= b;

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

google code и source forge еще существуют.

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

функциональное программирование я не отвергаю, это раз. Scheme ужасен, это два.

функциональное программирование как основоположника обобщенного программирования

Источник?

Значит Вы недостаточно осведомлены в современных тенденциях в программировании. Что уже тут говорить о концепциях обобщенного программирования? Это объясняет многие вещи которые Вы до сих пор не понимаете или не хотите понимать.

Как раз таки более чем. И пытаюсь отстраниться от их влияния!(тут было много букаф)
Вот скажите Utkin, какова Ваша задача?
Не оно:

struct Node
{
    int val;
    std::vector<smart_ptr<Node>> Nodes;
};

А Моно знаете ли отличная вещь, которая отличается тем, что Визуал Студио не запускается . И не понимание моно опять же минус в Вашу сторону .

Не встречал еще ни одного нормально работающего mono приложения!

Здесь все зависит от частных случаев. Вы в очередной раз доказали что отлично умеете читать, но не имеете приемлимого опыта работы в команде.

Причем здесь работа в команде? Т.к. работаю в команде уже более 2х лет.

[Smitt&Wesson]

Сообщение от Utkin

Не знаю причем здесь обобщенное программирование, но чувствую, что наших бьют . Короче, Blondy, если у Вас не любовь с Smitt&Wesson, то я на его стороне и Вам не поздоровится .

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

[Kostia]

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

Не понимаю по каким причинам это должно быть медлительнее. Разве что +1 указатель на счетчик указателей или +2 для связных списков или ни одного для др. стратегий. Все генерируется еще на этапе компиляции.

А на счёт "обобщённое программирование", это что-то из области "- "перпетуум мобиле".

Это всюду используется в STL.
Например:

template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
    class vector : protected _Vector_base<_Tp, _Alloc>

Класс vector, работающий с элементами типа _Tp и стратегией выделения памяти _Alloc заданной по умолчанию std::allocator<_Tp>

[Smitt&Wesson]

Сообщение от Kostia

Не понимаю по каким причинам это должно быть медлительнее. Разве что +1 указатель на счетчик указателей. Все остальное генерируется еще на этапе компиляции.

Это всюду используется в STL.
Например:

template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
    class vector : protected _Vector_base<_Tp, _Alloc>

Класс vector, работающий с элементами типа _Tp и стратегией выделения памяти _Alloc заданной по умолчанию std::allocator<_Tp>

Kostia, только про STL не нужно. Тупая библиотека. Создавалась в 80-х годах прошлого века. Мы её использовали на ЕС-6000. (Машинка с гектар размером). Ну и сейчас я её использую, но отнюдь не в восторге от неё.

[Kostia]

Тупая библиотека.

Аргументируйте, пожалуйста.

scheme я назвал ужасным только по личной неприязни к синтаксису:

;; Tabulation of squares from 0 to 9:
;; Note: loop is simply an arbitrary symbol used as a label. Any symbol will do.
(let loop ((i 0))
  (if (not (= i 10))
     (begin
        (display i)(display " squared = ")(display (* i i))(newline)
        (loop (+ i 1)))))

Я просто не представляю как можно писать что-то серьезное на этом языке. Это же получится здоровенная портянка кода.
На D это выглядит так:

foreach(i; 0 .. 10) writeln(i, " squared = ",i*i);

На руби:

(0...10).each{|i| print(i, ' squared = ', i*i, "\n");}

Почему так все пробиваются по этому scheme. Может мне кто глаза раскроет?
____________________

Создавалась в 80-х годах прошлого века.

И до сих пор создается. Чего только async стоит. А function и bind.
Правда вроде как ничего на счет связки функций не добавили(хотя хз), их удобно использовать при решении задачи undo, redo.
C++ 11 FAQ от Бьярна Страуструпа

[Smitt&Wesson]

Сообщение от Kostia

Аргументируйте, пожалуйста.

Да, легко. Библиотека не имеет функций работы с деревьями, что очень осложняет жизнь. Хотя, на основе деков это можно бы было зделать. Ан, - нет. Мозгов не хватило, наверное, у разработчиков.