Объектно-ориентированные и структурные системы склонны подходить к проблемам с диаметрально противоположных направлений. Возьмите в качестве примера скромную запись employee. В структурных системах вы бы использовали тип struct и имели бы доступ к полям этого типа повсюду
из своей программы. Например, код для печати записи мог бы свободно повторяться в нескольких
сотнях мест программы. Если вы меняете что-то в основе, вроде изменения типа поля name с массива
char на 16-битные символы Unicode, то вы должны разыскать каждую ссылку на name и
модифицировать ее для работы с новым типом.
В хорошо спроектированной объектно-ориентированной системе было бы невозможно получить
доступ к полю name.
Позвольте мне повторить это, потому что эта концепция так фундаментальна:
невозможно получить доступ к полю внутри объекта, даже такому простому, как name в объекте
employee. Скорее всего вы попросите employee проявить какую-нибудь способность, такую как
«напечатать себя», «сохранить себя в базе данных» или «модифицировать себя, взаимодействуя с
пользователем». В этом последнем случае обработчик сообщений вывел бы диалоговое окно, которое
бы использовалось пользователем для ввода или изменения данных.
Ален Голуб, «Правила программирования С++».
Рекомендую очень внимательно отнестись к данному подходу.
Его «подсказывает» сам синтаксис: либо мы заводим простейшие структуры с открытыми для доступа членами (для семантической группировки данных в структуру), либо используем классы с закрытыми по умолчанию членами — как самостоятельно действующие единицы программы. Несмотря на одинаковую реализацию, это совершенно разные сущности.
Класс хранит всё внутри и работает как чёрный ящик, выполняя высокоуровневые запросы, обращённые к нему (открытые функции-члены). В соответствии с правилами инкапсуляции (которые, поверьте, имеют смысл), всё остальное закрыто для внешнего мира.
В этом смысле, стоит задуматься, что представляет собой реализуемое свойство (property) класса. Это действительно необходимость, то есть некое сообщение, запрос действия от класса? Или это просто усложнённый и завуалированный вариант открытого члена класса?
Не получается ли тогда, что если посмотреть с точки зрения «лубочно-прагматической», то аналоговая передача при гораздо более простом и дешёвом оборудовании даёт вполне сравнительную полосу пропускания? Разумеется, здесь с учётом кучи допущений.
Лет 10 назад нам в институте демонстрировали аналоговые компьютеры 70-х годов, которые с некоторыми классами задач справлялись очень и очень быстро. Вопрос в том, не вышло ли так, что пересев на западную цифровую технику и отказавшись от развития своей аналоговой, мы потеряли в возможностях?
Знаете, в этом контексте я вспомнил про V8. Недавно его поддержку включили в фреймворк, которым я активно пользуюсь. Пожалуй, буду активно обдумывать его использование для обработки часто изменяемой логики в последующих больших проектах.
А какими скриптовыми языками в сцепке с С++ пользуетесь вы?
Дядя Петя, мужик лет 60, компьютер видел только по телевизору, о транзисторах знает из книг Борисова. Тем не менее, ему хватает смекалки понять, что узел с выгоревшими «жучками» является обычным преобразователем напряжения… Ток, потребляемый четырьмя планками памяти он со старта не угадал, потому первоначальный вариант с КТ805 был забракован. КТ8105 возбудился на сотнях килогерц, проблема была устранена пленочным конденсатором на выходе…
Попутно была модернизирована СО процессора вышеописанным способом.
Вот она, советская инженерная школа и системные знания. Браво!
В избранное.
Так точно.
И это как раз отличает цельные, системные знания, от фрагментарных и поверхностных.
Действительно, понимание того, как программа на Си работает со стеком вполне является ключом к пониманию таких трюков с языком.
С моей точки зрения, такой подход куда лучше, чем примеры с натяжкой. Или, не дай боги, передачу знаний в азиатском стиле:
Капля дождя весенним утром
Стекает по лицу
Как быстротечна жизнь стековой переменной
Полностью солидарен.
И со связкой скриптовый язык / Си.
И с проблемой квалификации для С++.
Мне лично ближе «монолитный» код, но я вполне отдаю себе отчёт что далеко не все и всегда могут себе позволить нормального С++ программиста на реализацию всех аспектов проекта.
Я даже позволяю себе немного мечтать о появлении хорошей школы С++ у нас на Родине. Потому что кадровый голод, который мы только начинаем ощущать, можно решить только длительным процессом действительно серьёзного обучения.
Здесь был очень точный комментарий, что в статье можно было не городить огород с примерами, а просто дать людям цельное, системное знание о том как на самом деле работает Си и С++. В этом смысле, знание как происходит работа со стеком, позволяет понимать вот такие вот трюки с языком.
Во-первых, мне очень симпатичен D, в Ocaml я разбираюсь значительно меньше, но и о нём слышал кое-что хорошее. В общем, предложенные вами языки считаю очень достойными и конкурентоспособными по тем требованиям, которые я изложил выше.
Но. Если сравнивать с эффективностью именно С++, то аргументы те же самые: избыточный (в указанном выше контексте) мусоросборщик, отсутствие полного контроля вплоть до указателей (костыли вроде unsafe не предлагать).
Кроме того, сам по себе нативный код D или Окамл, если судить по тестам, имеет сравнимую с С++ эффективность на определённых классах задач. На некоторых классах задач нативный код Окамл даёт замедление в 2-3 раза. Это тоже очень достойный результат, но в качестве «замены на все случаи жизни», увы, не тянет.
Много раз уже сказано как об избыточности, так и о сложности С++. Уверен, что зачастую эти доводы оправданы.
Я хотел бы заметить две вещи.
Первая. Чем мощнее инструмент, тем более серьёзной подготовки требует. Это важно и требует осознания.
Совсем грубо говоря, острый скальпель «мощнее» тупого ножа, а потому и требует более серьёзной подготовки.
С++ не идеален, наверняка какие-то моменты можно было сделать лучше (впрочем, я считаю что рассуждать об этом на адекватном уровне могут буквально единицы профессионалов высочайшего уровня, к которым я себя ни коим образом не причисляю). Но, согласитесь, инструмент очень мощный, так как позволяет работать с широчайшим спектром абстракций — от ООП до указателей и ассемблера (включая, с оговорками, и работу с виртуальными таблицами).
Вторая. Альтернативы? Предположим вы не супер-пупер профессионал, но у вас есть хороший GUI фреймворк, у вас есть методики работы с памятью, которые практически исключают проблемы с указателями и прочим. У вас есть в голове системные знания о том, как собрать всё это вместе.
Теперь вопрос: зачем вам брать язык, в котором всё то же самое делается на 1%-2% проще, но без возможности контролировать всё при необходимости, а требования к оперативной памяти и процессорное время — хуже в разы? Конечно, смысла никакого нет.
Замечательно, что есть альтернативы там, где хочется простоты. Там, где даже в перспективе не понадобится «тонкая» настройка работы программы вплоть до ассемблера. С моей точки зрения, это бесценно для процесса обучения программированию. Наверняка, в определённых нишах большего и не нужно.
Но как быть со всем тем что я назвал? Широчайший спектр абстракций, эффективность кода (без виртуальных машин и всего остального), минимум использованной памяти. Кто ещё способен предложить адекватную альтернативу?
Друг мой, о каком курсе идёт речь? Мне уже четвёртый десяток идёт.
И давайте без «давайте» и переходов на личности впредь. Также рекомендую быть осторожнее с фразами, начинающимися со слов «для тупых».
Очевидно, что любой инструмент требует подготовки и привыкания.
Чем инструмент сложнее, тем более серьёзная, более системная подготовка требуется.
С++ — мощный и сложный инструмент.
Для его применения требуется системная подготовка, дисциплина и привыкание.
К сожалению, мест, где на адекватном уровне дают системную подготовку к С++, у нас в современной России почти нет. Соответственно, никто не готовит будущего программиста С++ к дисциплине и не устраивает полноценный «инкубационный период» для привыкания.
С моей точки зрения, статья наглядно показывает недостатки отсутствия системного подхода, когда ряд подходов и практик создаёт мешанину в голове программиста. На которую он и реагирует вполне обоснованно.
Есть интересный подход к многопоточности в С++ в стили Эрланга.
Решение вполне кроссплатворменное.
Позволяет освободиться от объектов синхронизации во внешнем коде. Применимо в очень большом спектре задач.
Кого-нибудь заинтересует статья на тему?
Можно вас помирить?
Я за высокие технологии при здоровом существовании.
Если немного подумать, то одно другому не мешает. А даже наоборот, способствует.
В здоровом теле — работающий мозг!
Ален Голуб, «Правила программирования С++».
Рекомендую очень внимательно отнестись к данному подходу.
Его «подсказывает» сам синтаксис: либо мы заводим простейшие структуры с открытыми для доступа членами (для семантической группировки данных в структуру), либо используем классы с закрытыми по умолчанию членами — как самостоятельно действующие единицы программы. Несмотря на одинаковую реализацию, это совершенно разные сущности.
Класс хранит всё внутри и работает как чёрный ящик, выполняя высокоуровневые запросы, обращённые к нему (открытые функции-члены). В соответствии с правилами инкапсуляции (которые, поверьте, имеют смысл), всё остальное закрыто для внешнего мира.
В этом смысле, стоит задуматься, что представляет собой реализуемое свойство (property) класса. Это действительно необходимость, то есть некое сообщение, запрос действия от класса? Или это просто усложнённый и завуалированный вариант открытого члена класса?
Лет 10 назад нам в институте демонстрировали аналоговые компьютеры 70-х годов, которые с некоторыми классами задач справлялись очень и очень быстро. Вопрос в том, не вышло ли так, что пересев на западную цифровую технику и отказавшись от развития своей аналоговой, мы потеряли в возможностях?
Можно с этого места чуть поподробнее?)
Знаете, в этом контексте я вспомнил про V8. Недавно его поддержку включили в фреймворк, которым я активно пользуюсь. Пожалуй, буду активно обдумывать его использование для обработки часто изменяемой логики в последующих больших проектах.
А какими скриптовыми языками в сцепке с С++ пользуетесь вы?
Попутно была модернизирована СО процессора вышеописанным способом.
Вот она, советская инженерная школа и системные знания. Браво!
В избранное.
Нет пророка в своём отечестве.
Замечу, что передача информации шла аналоговая. И обычной телефонной связи (на старых ещё коммутаторах) хватало для передачи видеосигнала.
Сейчас под ту же задачу (да, чуть более качественно реализованную, но всё же!) требуется не самое медленное соединение с Сетью.
Вот такие они, современные Левши.
И это как раз отличает цельные, системные знания, от фрагментарных и поверхностных.
Действительно, понимание того, как программа на Си работает со стеком вполне является ключом к пониманию таких трюков с языком.
С моей точки зрения, такой подход куда лучше, чем примеры с натяжкой. Или, не дай боги, передачу знаний в азиатском стиле:
Капля дождя весенним утром
Стекает по лицу
Как быстротечна жизнь стековой переменной
И со связкой скриптовый язык / Си.
И с проблемой квалификации для С++.
Мне лично ближе «монолитный» код, но я вполне отдаю себе отчёт что далеко не все и всегда могут себе позволить нормального С++ программиста на реализацию всех аспектов проекта.
Я даже позволяю себе немного мечтать о появлении хорошей школы С++ у нас на Родине. Потому что кадровый голод, который мы только начинаем ощущать, можно решить только длительным процессом действительно серьёзного обучения.
Здесь был очень точный комментарий, что в статье можно было не городить огород с примерами, а просто дать людям цельное, системное знание о том как на самом деле работает Си и С++. В этом смысле, знание как происходит работа со стеком, позволяет понимать вот такие вот трюки с языком.
Но. Если сравнивать с эффективностью именно С++, то аргументы те же самые: избыточный (в указанном выше контексте) мусоросборщик, отсутствие полного контроля вплоть до указателей (костыли вроде unsafe не предлагать).
Кроме того, сам по себе нативный код D или Окамл, если судить по тестам, имеет сравнимую с С++ эффективность на определённых классах задач. На некоторых классах задач нативный код Окамл даёт замедление в 2-3 раза. Это тоже очень достойный результат, но в качестве «замены на все случаи жизни», увы, не тянет.
Я хотел бы заметить две вещи.
Первая. Чем мощнее инструмент, тем более серьёзной подготовки требует. Это важно и требует осознания.
Совсем грубо говоря, острый скальпель «мощнее» тупого ножа, а потому и требует более серьёзной подготовки.
С++ не идеален, наверняка какие-то моменты можно было сделать лучше (впрочем, я считаю что рассуждать об этом на адекватном уровне могут буквально единицы профессионалов высочайшего уровня, к которым я себя ни коим образом не причисляю). Но, согласитесь, инструмент очень мощный, так как позволяет работать с широчайшим спектром абстракций — от ООП до указателей и ассемблера (включая, с оговорками, и работу с виртуальными таблицами).
Вторая. Альтернативы? Предположим вы не супер-пупер профессионал, но у вас есть хороший GUI фреймворк, у вас есть методики работы с памятью, которые практически исключают проблемы с указателями и прочим. У вас есть в голове системные знания о том, как собрать всё это вместе.
Теперь вопрос: зачем вам брать язык, в котором всё то же самое делается на 1%-2% проще, но без возможности контролировать всё при необходимости, а требования к оперативной памяти и процессорное время — хуже в разы? Конечно, смысла никакого нет.
Замечательно, что есть альтернативы там, где хочется простоты. Там, где даже в перспективе не понадобится «тонкая» настройка работы программы вплоть до ассемблера. С моей точки зрения, это бесценно для процесса обучения программированию. Наверняка, в определённых нишах большего и не нужно.
Но как быть со всем тем что я назвал? Широчайший спектр абстракций, эффективность кода (без виртуальных машин и всего остального), минимум использованной памяти. Кто ещё способен предложить адекватную альтернативу?
И давайте без «давайте» и переходов на личности впредь. Также рекомендую быть осторожнее с фразами, начинающимися со слов «для тупых».
Желаю удачи! Искренне ваш, mt_.
Чем инструмент сложнее, тем более серьёзная, более системная подготовка требуется.
С++ — мощный и сложный инструмент.
Для его применения требуется системная подготовка, дисциплина и привыкание.
К сожалению, мест, где на адекватном уровне дают системную подготовку к С++, у нас в современной России почти нет. Соответственно, никто не готовит будущего программиста С++ к дисциплине и не устраивает полноценный «инкубационный период» для привыкания.
С моей точки зрения, статья наглядно показывает недостатки отсутствия системного подхода, когда ряд подходов и практик создаёт мешанину в голове программиста. На которую он и реагирует вполне обоснованно.
Решение вполне кроссплатворменное.
Позволяет освободиться от объектов синхронизации во внешнем коде. Применимо в очень большом спектре задач.
Кого-нибудь заинтересует статья на тему?
Я за высокие технологии при здоровом существовании.
Если немного подумать, то одно другому не мешает. А даже наоборот, способствует.
В здоровом теле — работающий мозг!