>Слишком сурово и расточительно для элементарных задач плодить объекты классов
В книгах по ООП сразу пишут, различайте классы ADT (Abstract Data Types) и классы участвующие в построении различных объектно-ориентированных конструкций. Хотя яву не изучал, но мне думается в примере слишком много лишнего просто для прикола.
В глаза сразу бросается out, который используется не там где объявляется, и многократно повторяющийся new для получения строк. Ну тебе виднее, если бы это был .NET, я бы сказал, что это намеренное издевательство :), а так не знаю.
>Чего уж такого ужасного, не понятно.
Какой-то он недоделанный, впрочем это не столь важно. В Qt пошли по пути сокрытия деталей. В итоге там всё равно после MOC получится обычный C++ код. Мне такое положение дел не очень нравится.
Хотя если подумать для C++ столько сторонних библиотек, и каждая имеет какой-то свой стиль. Здесь уж без разницы, что сам пишешь, то и будет. Нет определяющего общий стиль фреймворка и это не так плохо, хотя думать на проблемой выбора своего стиля надо больше.
>На самом деле меня ничего не удерживает от того чтобы опубликовать свое проектное решение после того как я достигну результата, я не собираюсь делать на продукте А бизнеса, мне нужен штучный экземпляр (ну или столько сколько нужно).
Удерживает, специалисты по разработке ПО создают его с помощью ПО и распространяют используя ПО. Человек создающий материальную вещь может её делать как ему вздумается. Даже если он выложит в цифровом виде вменяемые чертежи, другим чтобы её сделать понадобятся не хилые вложения с точки зрения обычного копирования данных, которое ничего этого не требует.
Даже если узнать как получить нужный сплав, его изготовление потребует очень больших затрат. Можно взять чертёж устройства, но не суметь его воплотить в реальность даже в одном экземпляре. А обучиться этому так просто нельзя, ведь обычным людям недоступны станки. И станки надо купить, на реальном производстве люди ещё думают, купить их или не купить, при том, что станок работает без перерыва, а не пять минут ради одной вещи.
Без материального снабжения нельзя научиться делать материальные вещи. Это всё равно что учиться программировать лишь в теории вообще не используя компьютер. И всё это в итоге выльется в — я мечтаю.
>Но если задуматься над тем чем отличается магазин со складом (прилавком) от супермаркета…
Во втором не надо бегать в поисках товаров по разным магазинам. По идее если бы я мог узнать какой товар существует, или бы нашёл, то что мне нужно не выходя из дома, то было бы ещё лучше. То есть помимо цены и прочего есть желание иметь вещь, но нет желания тратить излишние усилия по её приобретению. В целом люди разные и предпочитают они тоже под час разное, иными словами различная целевая аудитория. К примеру, для меня бы лучше узнать о товаре по интернету, но купить его только лично, придя в обычный магазин. А кому-то другому надо иное, и т.д.
Требования в статье в целом на ноутах выполняются. Другое дело, что чем больше хочется, тем дороже стоит. Я бы сказал, что ноутам неплохо бы иметь не просто тачпад, а планшетный экран с перьями. Так как пальцами много не накалякаешь, да и вообще изотрёшь их до дыр.
Между прочим некоторые думают, что даже второго потока не надо, достаточно грузить алгоритмы в том же, в котором работает GUI. А всё это приводит к банальному подвисанию интерфейса. Ну для примера, если это некое бизнес-приложение, при обращении к базе данных.
Мне это скорее анекдот напоминает, где старушка бегает и кричит, насилуют, насилуют. В конце концов всё равно придётся переходить на более прогрессивные методы программирования. По идее уже сейчас можно, но здесь кучу времени надо будет потратить.
>Например реализовать систему делегатов и событий для С++ не составляет большого труда, благо получить адрес объекта и адрес метода в С++ можно без проблем
А я где-то говорил, что это запредельно сложно? Написал же — шаблон проектирования — Observer. Кстати, в связи с адресами вспомнилось, что в книге про Qt писали. (мой вольный перевод :) Им якобы обратный вызов извратской техникой казался. И сигнатуру не передашь, и в целом неудобно.
Потому они метакомпилятор (moc) и сделали сверху. Иными словами обратный вызов им не нравился, а возится с шаблонами проектирования, которые лишены этих недостатков не стали. Но как я уже говорил, Qt очень хорош для быстрого и качественного результата, только это не образец для обучения ООП, во многих смыслах всё совсем наоборот.
>Какой случай вам больше нравится? Где ООП или где СП? А где код работает быстрее?
Честно тебе скажу, второй твой пример с ООП не имеет ничего общего, как впрочем и первый. У тебя просто всё запихано в одну функцию, которая лежит в классе. Но ключевое слово class само по себе не делает стиль объектно-ориентированным.
Если не считать этого грубого примитива, когда процедурное программирование пытаются выдать за ООП, я бы сказал так. ООП даёт преимущество на относительно больших проектах, а учится приходится на маленьких. А маленькое очень похоже на «сложение двух чисел».
Мы пытаемся сложить два числа, и одновременно применить ООП. И тут попадаем в ловушку собственных заблуждений о том чего достигли. Потому чтобы осилить путь ООП нужно очень постараться, читать книги, писать код. Если же не охота, так не проблема, просто стиль будет называться не объектно-ориентированным, и его не надо путать с ним.
Перейди хотя бы по первой ссылке, это STL, она должна быть во всех реализациях C++. Сборка мусора — garbage collection, и часть этой системы умные указатели. В вики описаны основные принципы.
Если говорить в целом, то сборка мусора это управление памятью (memory) и автоматическое удаление объектов, когда их больше нельзя использовать, а значит и незачем держать в памяти. На C++ предоставляется выбор, или ручное управление памятью, или использование стандартных, сторонних и самописных реализаций.
Ссылки между прочим часто считают для того, чтобы удалить объект, когда их количество становится равно нулю. Давайте всё же не будем судить о C++ на основе других языков и реализаций стандартных библиотек, дескать те истинные сборщики мусора, а вот это что-то не то хотя бы потому что оно на C++, а не на ххх.
По мне так нет смысла опускаться ниже 1998 года. Это не обязательно школьник писал, просто человек из далёкого прошлого, когда мир был другим и знаний было накоплено меньше.
>Да да, многие паттерны просто добавляют тормозов в реальности.
Не паттерны добавляют тормозов, а использование полиморфизма в них (то есть виртуальные функции), особенно его неоправданно высокий уровень. Именно поэтому я и упомянул о template в C++. Шаблон (паттерн) проектирования ООП в общем случае это некая идея, она жёстко от реализации не зависит.
Хотя тормоза это сильно сказано, я бы сказал вызов происходит немного медленнее. Но C++ часто предоставляет такой вот выбор, встроенная функция (больше объём скомпилированного кода) или нет, виртуальная или нет (например template при тех же возможностях паттернов нет потери производительности), и так далее.
>С меня в свое время хватило ковыряния в ZendFramework чтобы понять, что ООП ради ООП не ведет ни к чему кроме создания тонны лишнего кода.
>>Zend Framework — это свободный каркас на PHP для разработки веб-приложений и веб-сервисов.
Про него ничего не знаю, я C++ обсуждал. Причём здесь какой-то фреймворк и вообще другой язык?
>Плюсы всё же компилируемый язык и витать в облаках патернов тут не позволяет низкоуровневость
Позволяет, но это зависит от уровня умений программистов. Инкапсуляция, наследование и полиморфизм это только начало, наиболее мелкие кирпичики ООП. Знать и использовать их вовсе не значит уметь программировать в стиле ООП.
А мне всё равно, пользоваться рф не престижно. Пользоваться ru как-то не очень, ведь com, org, net международные, а тут какое-то ограничение, и наезды от ментов в последнее время на эту группу доменов. Мне всё равно, так как я вообще буду избегать таких сайтов.
Очень даже нарушали, не веришь, почитай «Быстрая разработка программ. Принципы, примеры, практика» автор Р.К. Мартин. В книге учат не только понимать, что принципы ООП нарушаются, но и измерять в цифрах насколько они нарушены, строить по ним графики и так далее. Про template лучше всего наверное Александреску курить, что-нибудь типа «Современое проектирование на C++», и другое.
Давайте покритикуем C++ на примере других языков. Возьмём хотя бы C#, он имеет систему событий. Иными словами есть ключевые слова для этого. Но что это такое? А это Multicast Delegate. И давайте упрекайте C++ в том, что не знаете после этого, что такое Observer. Со свойствами ещё веселее, будут тупо сделаны две функции, те самые accessor и mutator.
Вернёмся к статье, там критика про иерархии и прочее. Чем не нравится Composite и прочие шаблоны проектирование? Чем не нравятся умные указатели? В итоге мы имеем не плохую совместимость с GUI, а просто лень в изучении ООП и обыкновенное незнание его. Ну и конечно одна от балды написанная виртуальная функция сразу доказала всю мерзость C++ как языка.
К сожалению уже дожили. У меня десятки книг на одном только русском языке про параллельные вычисления, кластера и так далее. Все эти технологии и библиотеки на типа MPI, OpenCL и прочих уже вошли в обиход, только вот я, да и думаю не только я, всё еще не проснулись. Одно дело пул потоков сделать и распределить задачи внутри приложения, другое дело техники параллельных вычислений с максимальным разбиением всех алгоритмов для выполнения на множестве ядер. Сейчас ещё ладно, на возможности видеокарт можно забить, хотя это и нехорошо. Но когда пойдут ещё и процессоры, то если это игнорировать, конечный пользователь в итоге получит выхлоп в виде медленного ПО.
Слишком много возможностей, охват большинства парадигм программирования, всё это порождает неопределённость. Синтаксис самого языка не так сложен в изучении, как умение пользоваться техниками программирования на нём.
Например, он не варит по утрам кофе. Не отводит детей в детский сад. А ведь столько ещё в мире вещей, которые C++ почему-то не делает. Меня всегда расстраивало, что C++ за меня не думает, и не выполняет всю работу.
В третьих, многие шаблоны проектирования могут реализовываться не только полиморфизмом, но и с помощью техники обобщённого программирования (template C++).
P.S. между прочим в Qt нарушили кучу принципов ООП, то что C++ позволял делать решили реализовать метакомпилятором, про принципы вообще уж молчу. На самом деле C++ очень даже подходит, только вот пользоваться им и техникой ООП многие не умеют.
Прочитал разные комментарии. Сложилось ощущение, что закон Мура это закон рынка, а не техническое ограничение. Вероятно просто выгодно насыщать рынок повышая производительность именно с такой скоростью. И второе, похоже теперь будут тупо херачить ядра. То есть уже сейчас могут дать десятки и сотни, но будут их добавлять медленно, но верно, заставляя покупать 2-ух ядерные, 4-ёх ядерные, 6-ядерные, 8-ядерные и так далее. Юзеры будут покупать, а софт придётся переписывать и перекомпилировать. Программистам уже сейчас надо готовится к «стопитьсот» ядерным компам.
В книгах по ООП сразу пишут, различайте классы ADT (Abstract Data Types) и классы участвующие в построении различных объектно-ориентированных конструкций. Хотя яву не изучал, но мне думается в примере слишком много лишнего просто для прикола.
В глаза сразу бросается out, который используется не там где объявляется, и многократно повторяющийся new для получения строк. Ну тебе виднее, если бы это был .NET, я бы сказал, что это намеренное издевательство :), а так не знаю.
>Чего уж такого ужасного, не понятно.
Какой-то он недоделанный, впрочем это не столь важно. В Qt пошли по пути сокрытия деталей. В итоге там всё равно после MOC получится обычный C++ код. Мне такое положение дел не очень нравится.
Хотя если подумать для C++ столько сторонних библиотек, и каждая имеет какой-то свой стиль. Здесь уж без разницы, что сам пишешь, то и будет. Нет определяющего общий стиль фреймворка и это не так плохо, хотя думать на проблемой выбора своего стиля надо больше.
Удерживает, специалисты по разработке ПО создают его с помощью ПО и распространяют используя ПО. Человек создающий материальную вещь может её делать как ему вздумается. Даже если он выложит в цифровом виде вменяемые чертежи, другим чтобы её сделать понадобятся не хилые вложения с точки зрения обычного копирования данных, которое ничего этого не требует.
Даже если узнать как получить нужный сплав, его изготовление потребует очень больших затрат. Можно взять чертёж устройства, но не суметь его воплотить в реальность даже в одном экземпляре. А обучиться этому так просто нельзя, ведь обычным людям недоступны станки. И станки надо купить, на реальном производстве люди ещё думают, купить их или не купить, при том, что станок работает без перерыва, а не пять минут ради одной вещи.
Без материального снабжения нельзя научиться делать материальные вещи. Это всё равно что учиться программировать лишь в теории вообще не используя компьютер. И всё это в итоге выльется в — я мечтаю.
Во втором не надо бегать в поисках товаров по разным магазинам. По идее если бы я мог узнать какой товар существует, или бы нашёл, то что мне нужно не выходя из дома, то было бы ещё лучше. То есть помимо цены и прочего есть желание иметь вещь, но нет желания тратить излишние усилия по её приобретению. В целом люди разные и предпочитают они тоже под час разное, иными словами различная целевая аудитория. К примеру, для меня бы лучше узнать о товаре по интернету, но купить его только лично, придя в обычный магазин. А кому-то другому надо иное, и т.д.
Мне это скорее анекдот напоминает, где старушка бегает и кричит, насилуют, насилуют. В конце концов всё равно придётся переходить на более прогрессивные методы программирования. По идее уже сейчас можно, но здесь кучу времени надо будет потратить.
А я где-то говорил, что это запредельно сложно? Написал же — шаблон проектирования — Observer. Кстати, в связи с адресами вспомнилось, что в книге про Qt писали. (мой вольный перевод :) Им якобы обратный вызов извратской техникой казался. И сигнатуру не передашь, и в целом неудобно.
Потому они метакомпилятор (moc) и сделали сверху. Иными словами обратный вызов им не нравился, а возится с шаблонами проектирования, которые лишены этих недостатков не стали. Но как я уже говорил, Qt очень хорош для быстрого и качественного результата, только это не образец для обучения ООП, во многих смыслах всё совсем наоборот.
>Какой случай вам больше нравится? Где ООП или где СП? А где код работает быстрее?
Честно тебе скажу, второй твой пример с ООП не имеет ничего общего, как впрочем и первый. У тебя просто всё запихано в одну функцию, которая лежит в классе. Но ключевое слово class само по себе не делает стиль объектно-ориентированным.
Если не считать этого грубого примитива, когда процедурное программирование пытаются выдать за ООП, я бы сказал так. ООП даёт преимущество на относительно больших проектах, а учится приходится на маленьких. А маленькое очень похоже на «сложение двух чисел».
Мы пытаемся сложить два числа, и одновременно применить ООП. И тут попадаем в ловушку собственных заблуждений о том чего достигли. Потому чтобы осилить путь ООП нужно очень постараться, читать книги, писать код. Если же не охота, так не проблема, просто стиль будет называться не объектно-ориентированным, и его не надо путать с ним.
ru.wikipedia.org/wiki/Сборка_мусора
Если говорить в целом, то сборка мусора это управление памятью (memory) и автоматическое удаление объектов, когда их больше нельзя использовать, а значит и незачем держать в памяти. На C++ предоставляется выбор, или ручное управление памятью, или использование стандартных, сторонних и самописных реализаций.
Ссылки между прочим часто считают для того, чтобы удалить объект, когда их количество становится равно нулю. Давайте всё же не будем судить о C++ на основе других языков и реализаций стандартных библиотек, дескать те истинные сборщики мусора, а вот это что-то не то хотя бы потому что оно на C++, а не на ххх.
Ну тогда и обсуждать нечего.
ISO/IEC 14882:1998 C++
ISO/IEC 14882:2003 C++
По мне так нет смысла опускаться ниже 1998 года. Это не обязательно школьник писал, просто человек из далёкого прошлого, когда мир был другим и знаний было накоплено меньше.
www.cplusplus.com/reference/std/memory/auto_ptr/
www.boost.org/doc/libs/1_43_0/libs/smart_ptr/smart_ptr.htm
Между прочим в том же .NET сборщик мусора не из воздуха берётся.
Не паттерны добавляют тормозов, а использование полиморфизма в них (то есть виртуальные функции), особенно его неоправданно высокий уровень. Именно поэтому я и упомянул о template в C++. Шаблон (паттерн) проектирования ООП в общем случае это некая идея, она жёстко от реализации не зависит.
Хотя тормоза это сильно сказано, я бы сказал вызов происходит немного медленнее. Но C++ часто предоставляет такой вот выбор, встроенная функция (больше объём скомпилированного кода) или нет, виртуальная или нет (например template при тех же возможностях паттернов нет потери производительности), и так далее.
>С меня в свое время хватило ковыряния в ZendFramework чтобы понять, что ООП ради ООП не ведет ни к чему кроме создания тонны лишнего кода.
>>Zend Framework — это свободный каркас на PHP для разработки веб-приложений и веб-сервисов.
Про него ничего не знаю, я C++ обсуждал. Причём здесь какой-то фреймворк и вообще другой язык?
>Плюсы всё же компилируемый язык и витать в облаках патернов тут не позволяет низкоуровневость
Позволяет, но это зависит от уровня умений программистов. Инкапсуляция, наследование и полиморфизм это только начало, наиболее мелкие кирпичики ООП. Знать и использовать их вовсе не значит уметь программировать в стиле ООП.
Давайте покритикуем C++ на примере других языков. Возьмём хотя бы C#, он имеет систему событий. Иными словами есть ключевые слова для этого. Но что это такое? А это Multicast Delegate. И давайте упрекайте C++ в том, что не знаете после этого, что такое Observer. Со свойствами ещё веселее, будут тупо сделаны две функции, те самые accessor и mutator.
Вернёмся к статье, там критика про иерархии и прочее. Чем не нравится Composite и прочие шаблоны проектирование? Чем не нравятся умные указатели? В итоге мы имеем не плохую совместимость с GUI, а просто лень в изучении ООП и обыкновенное незнание его. Ну и конечно одна от балды написанная виртуальная функция сразу доказала всю мерзость C++ как языка.
Вот, а это уже выходит за рамки обычных потоков, здесь фоновым режимом не обойдёшься.
В третьих, многие шаблоны проектирования могут реализовываться не только полиморфизмом, но и с помощью техники обобщённого программирования (template C++).
P.S. между прочим в Qt нарушили кучу принципов ООП, то что C++ позволял делать решили реализовать метакомпилятором, про принципы вообще уж молчу. На самом деле C++ очень даже подходит, только вот пользоваться им и техникой ООП многие не умеют.
А я не согласен, всё что написано полный бред.
Во-первых есть принципы ООП
butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Во-вторых то чего якобы нет в C++ называется шаблонами проектирования