По-моему, для реализма очень нехватает пыли какой-нибудь, очень все стерильно смотрится. Много глянца.
И да, при просмотре этого видео у меня не было «ощущения погружения в виртуальную реальность».
Но для реалтайм рендера, конечно, очень круто.
Охренеть. Я только сегодня утром размышлял вообще о такой возможности, даже не успел в доку зарыться.
Почему-то пропустил первую часть. Пишите продолжение!
Я сперва написал реализацию канала tcp под posix сокеты, а потом портировал под винду используя Qt. И мне почему-то не казалось нелогичным создание сокета только при коннекте. Более того, я считаю setSocketDescriptor очень неплохой штукой.
Вообще изначальная ветка была про «многословность», так что оставим это =)
Я с Вами частично соглашусь, хотя бы потому что я как раз прошел это на своей шкуре. Начал изучать в 9 классе С++, долго матерился и бился упорно головой, писал в Си-стиле, не читал книжек, набивал шишки.
В итоге когда через год стал смотреть на Delphi, Javascript а через пару лет еще и PHP, то многие внутренние особенности этих языков уже не вызывали вопросов =)
с в) не соглашусь.
в С++ синтаксический сахар в виде шаблонов дается зачастую бесплатно. На хабре была статья ( увы нет в закладках), как человек на шаблонах под микроконтроллеры генерировал код, причем результирующий ASM был такой же оптимальный, как человек бы вручную соптимизировал.
inline template<> имеет такой же overhead, как и макрос, по сути.
Может это и ТИПОВАЯ задача, но я был бы сильно против, чтобы такие инструменты были в стандартной библиотеке языка.
Ну и потом, Бьёрн иллюстрирует API конкретной библиотеки, asio — на Qt, мне кажется, я бы написал в два раза короче.
Читал недавно Мейерса. Эффективный С++14.
Таки я считаю что для новичка это далеко не лучший язык (сам начинал именно с него и много страдал). Да, const, & — по началу весьма непонятно (хотя, нет, вру, как раз const как таковой не вызывал у меня вопросов в параметрах, мне не понятно было зачем его пихать везде. И что значит const после прототипа функции.).
«вызов виртуальной функции препятствует инлайнингу, что может раз в 50 замедлить вашу программу»
Для тех кто плохо знаком с внутренней кухней это «хрмбрмрмрбхппхх», однозначно! :)
А вот насчет управления памяти и жизнью объектов с вами не соглашусь. Для меня — то что компилятор САМ позаботится о деструкторах, и есть «автоматически», а не вручную. Я пишу на плюсах 10 лет, из них 4 года в коммерческой разработке (нет, не такой большой опыт, кто спорит), но я уже давно не заморачиваюсь «управлением памятью».
Контейнеры, shared-поинтеры, передача this в качестве parent в Qt — все это разные ипостаси RAII, и я не знаю как при любой из них «просто допустить ошибку». Да, ошибки допустить МОЖНО. С++ позволяет допускать ошибки (например, создать указатель и передать его в конструкторы разных shared_ptr), но это же постараться надо =)
Т.е., подытожив — в современных плюсах РУЧНОЕ управление памятью есть, но оно нафиг обычно не нужно.
Никогда почему-то не задумывался о необходимости на лету во время выполнения приложения переключать языки. Ну, просто даже не как программист, а как пользователь.
Для меня это все же пока остается «Установил приложение, запустил, выбрал язык в настройках, все»
P.S. QTranslator активно использую, правда NOOP гораздо реже.
В дополнение этому, я не вижу здесь никаких команд, которые будут понятны только ассемблеру, и при этом не будут являться выходным машинным кодом. Вроде директив.
Я согласен с Вами. и вот почему.
Язык ассемблера должен быть понятен человеку, но еще не машине.
Для выполнения на машине, он должен быть оттранслирован.
Процессор x86 читает байты- мненмоники команд и потом — операнды.
Предположим на минуточку, если бы в памяти кода, вместо числовых кодов — были бы строки, которые процессор разбирал.
Да, у нас были бы читаемые мнемоники, но суть от этого не особо изменилась — это все равно машинный язык.
В листе Excel — машиной является процессор выражений листа и условия в ячейках, написанные автором.
Я могу с чистой совестью утверждать, что первые четыре столбца понятны этой машине.
Поскольку дополнительного преобразования (изменения структуры программы, блоков, разворачивание процедур, подстановки адресов) не делается, то назвать это Ассемблером будет громко.
Я не владею ни теорией вероятностей, не обладаю познаниями в физике и электротехнике, только поверхностными знаниями по С++ и информатике.
И да, при просмотре этого видео у меня не было «ощущения погружения в виртуальную реальность».
Но для реалтайм рендера, конечно, очень круто.
Почему-то пропустил первую часть. Пишите продолжение!
2) paranoid mode on.
А если разработчики irmaker уже добавили исключение на скрипт ValdikSS?
Вообще изначальная ветка была про «многословность», так что оставим это =)
В итоге когда через год стал смотреть на Delphi, Javascript а через пару лет еще и PHP, то многие внутренние особенности этих языков уже не вызывали вопросов =)
с в) не соглашусь.
в С++ синтаксический сахар в виде шаблонов дается зачастую бесплатно. На хабре была статья ( увы нет в закладках), как человек на шаблонах под микроконтроллеры генерировал код, причем результирующий ASM был такой же оптимальный, как человек бы вручную соптимизировал.
inline template<> имеет такой же overhead, как и макрос, по сути.
Ну и потом, Бьёрн иллюстрирует API конкретной библиотеки, asio — на Qt, мне кажется, я бы написал в два раза короче.
Читал недавно Мейерса. Эффективный С++14.
Таки я считаю что для новичка это далеко не лучший язык (сам начинал именно с него и много страдал). Да, const, & — по началу весьма непонятно (хотя, нет, вру, как раз const как таковой не вызывал у меня вопросов в параметрах, мне не понятно было зачем его пихать везде. И что значит const после прототипа функции.).
«вызов виртуальной функции препятствует инлайнингу, что может раз в 50 замедлить вашу программу»
Для тех кто плохо знаком с внутренней кухней это «хрмбрмрмрбхппхх», однозначно! :)
А вот насчет управления памяти и жизнью объектов с вами не соглашусь. Для меня — то что компилятор САМ позаботится о деструкторах, и есть «автоматически», а не вручную. Я пишу на плюсах 10 лет, из них 4 года в коммерческой разработке (нет, не такой большой опыт, кто спорит), но я уже давно не заморачиваюсь «управлением памятью».
Контейнеры, shared-поинтеры, передача this в качестве parent в Qt — все это разные ипостаси RAII, и я не знаю как при любой из них «просто допустить ошибку». Да, ошибки допустить МОЖНО. С++ позволяет допускать ошибки (например, создать указатель и передать его в конструкторы разных shared_ptr), но это же постараться надо =)
Т.е., подытожив — в современных плюсах РУЧНОЕ управление памятью есть, но оно нафиг обычно не нужно.
Для меня это все же пока остается «Установил приложение, запустил, выбрал язык в настройках, все»
P.S. QTranslator активно использую, правда NOOP гораздо реже.
Но почему не ithappens.ru?
1. Генерация символьных констант
2. генерация имен, через ##, например (сериализация variant-like:):
Язык ассемблера должен быть понятен человеку, но еще не машине.
Для выполнения на машине, он должен быть оттранслирован.
Процессор x86 читает байты- мненмоники команд и потом — операнды.
Предположим на минуточку, если бы в памяти кода, вместо числовых кодов — были бы строки, которые процессор разбирал.
Да, у нас были бы читаемые мнемоники, но суть от этого не особо изменилась — это все равно машинный язык.
В листе Excel — машиной является процессор выражений листа и условия в ячейках, написанные автором.
Я могу с чистой совестью утверждать, что первые четыре столбца понятны этой машине.
Поскольку дополнительного преобразования (изменения структуры программы, блоков, разворачивание процедур, подстановки адресов) не делается, то назвать это Ассемблером будет громко.