В восьмерке, ЕМНИП, какая-то версия метрошного WinRT XAML UI Framework. Который ни разу не WPF — он, на самом деле, еще более урезанный, чем обычный Silverlight (например, custom markup extensions там нет ни в каком виде).
Нет, они пишутся на Silverlight for Windows Phone. А Silverlight всегда был довольно урезанным фреймворком по сравнению с десктопным WPF — а на WP это вдвойне справедливо. В частности, многие extensibility hooks из WPF там недоступны.
Увы, в данном случае речь идет о вещах, которые вполне себе могли бы перенестись на мобилы. MultiBinding, например. Вообще, большое количество хуков в WPF, через которые его можно было более гибко расширять.
Писать быстрее только в режиме write-only. Если потом этот код переписывать, или даже дебажить, то все эти попытки сэкономить десяток символов отольются во много зря потраченного времени.
Потребление ресурсов в случае использования вменяемого оптимизирующего компилятора это не увеличивает ни на грамм (если только вы не о времени компиляции, но и там это пренебрежимо малая величина).
А с «копейка рубль бережет» спорить очень легко в том случае, если выбор языка изначально предполагает сорение «деньгами» просто в силу дизайна реализации (например, PHP или Python) — встречный аргумент там очень простой, предложить переписать все на плюсах, т.к. экономия сразу будет куда серьезней.
Сам по себе каст строкового литерала к char* неопределенного поведения не предполагает. Оно возникнет только в том случае, если вы попытаетесь потом через этот неконстантный указатель литерал поменять.
В целом, да, я был несколько некорректен. Но суть та же — /Wall включает в себя большое количество варнингов, которые таковыми по сути не являются, и на практике собирать с ним смысла не имеет — базовым должен являться /W4. А если там чего-то не хватает, то это уже надо включать выборочно.
Обычно в тех языках, в которых компиляторы не справляются с оптимизацией подобного кода — и уж тем более в таких, где компилятора нет — базовый уровень производительности настолько ниже, что микрооптимизации вроде инлайнинга переменных никакого значения иметь не будут. А там, где считают каждый такт — т.е. C и C++ — это свернет в изначальное выражение любой компилятор, выпущенный в последние 15 лет.
Область применимости RVO намного уже. Например, если вы напишете что-то вроде vec.push_back(foo()), и foo возвращает const-объект, то как минимум одна копия вам гарантирована. А без const это будет move.
Надо понимать, что /Wall в VC++ включает в себя т.н. «informational warnings», которые не предполагают наличия проблемы. Например, там выдаются варнинги о том, что в структуру добавлен padding. Настоящий аналог gcc -Wall в VC++ — это /W4. С ним все стандартные заголовочные файлы, в т.ч. WinSDK, компилируются молча.
Ничто не мешает разбить регулярку на куски в виде переменных, дать этим кускам имена, и «повторно использовать» их конкатенацией. Не хватает только рекурсии.
Долгое время забивала, да. Но к висте я уже не помню никакого софта от MS, который бы не понимал high DPI.
Чтобы совместить текст и изображение (и вообще все, что угодно) на экране с учетом DPI, достаточно иметь один-единственный API — тот, который вернет вам этот самый DPI. Потом уже можно самому пересчитывать все в пиксели и растягивать картинки. Да, WinAPI здесь не помощник (хотя были DPI-независимые dialog units — но это полумера), но он всегда был очень низкоуровневой вещью, и большинство пользовались обертками. А вот то, что почти все обертки игнорировали DPI, это грустно, да. Кстати, помните твипы в VB6? То, в чем измерялся размер всех форм и виджетов на них? Они ведь тоже были логическими…
В Windows DPI тоже мог быть «практически любой», еще со времен Win95 — всегда можно было выставить DPI вплоть до 480 (настройка «500%»; за «100%» принимается 96dpi). То, что на это забивал софт (причем в первую очередь именно сторонний) — это как бы не «усилиями MS», а скорее наоборот. Про то, как именно писать DPI-aware софт, на MSDN всегда была куча статей.
Напомню также, что WPF — UI-фреймворк, который не просто учитывал системное значение DPI, но форсил это на все написанные на нем приложения (вплоть до того, что в WPF пиксели, как в CSS сегодня, не были физическими пикселями) — вышел в еще 2006-м.
Наверное, капец как сложно и долго. И что? С какой стати Google должно быть интересно, сколько ресурсов MS на это потратит?
А с какой стати Google должно быть интересно, на чем именно написано приложение под чужую платформу? Сыр-бор начался ведь именно с того, что они стали диктовать вроде бы совсем не относящиеся к делу вещи. Что, мягко говоря, странно для сервиса со вроде бы открытым API.
Попробуйте это перевернуть. Например, представьте себе, что во все открытые на сегодня API от MS добавляется лицензия, требующая писать клиенты только на TypeScript, и выкладывать их на CodePlex под MPL.
Для пущего эффекта я потребовал бы у MS не просто HTML5-клиент, а HTML5-клиент с открытым исходным кодом, выложенным на гитхабе/кодеплексе под лицензией BSD/Apache
Да, я уверен, что антимонопольный комитет тоже оценит такую шутку юмора.
Это все можно сделать. Как я написал выше, именно таким образом работает половина существующих YouTube-приложений под WP (а их десятка два, наверное) — и в том числе самое первое «официальное» приложение от MS. Которое у пользователей имело рейтинг что-то порядка двух звездочек из пяти, и ревью в духе «уберите этот отстой и запилите уже полноценный app, как на айфоне». С чего, собственно, и началась данная история.
Кстати, если вы внимательно прочитаете текст обращения на блоге MS, в нем есть фраза «At the end of the day, experts from both companies recognized that building a YouTube app based on HTML5 would be technically difficult and time consuming».
WPF есть только на десктопе в полноценной винде.
А с «копейка рубль бережет» спорить очень легко в том случае, если выбор языка изначально предполагает сорение «деньгами» просто в силу дизайна реализации (например, PHP или Python) — встречный аргумент там очень простой, предложить переписать все на плюсах, т.к. экономия сразу будет куда серьезней.
В целом, да, я был несколько некорректен. Но суть та же — /Wall включает в себя большое количество варнингов, которые таковыми по сути не являются, и на практике собирать с ним смысла не имеет — базовым должен являться /W4. А если там чего-то не хватает, то это уже надо включать выборочно.
vec.push_back(foo()), и foo возвращает const-объект, то как минимум одна копия вам гарантирована. А без const это будет move.Лучше не надо. Это сломает move optimization в C++11.
Это все можно достаточно легко добавить самому, но отсутствие их из коробки удручает.
Чтобы совместить текст и изображение (и вообще все, что угодно) на экране с учетом DPI, достаточно иметь один-единственный API — тот, который вернет вам этот самый DPI. Потом уже можно самому пересчитывать все в пиксели и растягивать картинки. Да, WinAPI здесь не помощник (хотя были DPI-независимые dialog units — но это полумера), но он всегда был очень низкоуровневой вещью, и большинство пользовались обертками. А вот то, что почти все обертки игнорировали DPI, это грустно, да. Кстати, помните твипы в VB6? То, в чем измерялся размер всех форм и виджетов на них? Они ведь тоже были логическими…
Напомню также, что WPF — UI-фреймворк, который не просто учитывал системное значение DPI, но форсил это на все написанные на нем приложения (вплоть до того, что в WPF пиксели, как в CSS сегодня, не были физическими пикселями) — вышел в еще 2006-м.
А с какой стати Google должно быть интересно, на чем именно написано приложение под чужую платформу? Сыр-бор начался ведь именно с того, что они стали диктовать вроде бы совсем не относящиеся к делу вещи. Что, мягко говоря, странно для сервиса со вроде бы открытым API.
Попробуйте это перевернуть. Например, представьте себе, что во все открытые на сегодня API от MS добавляется лицензия, требующая писать клиенты только на TypeScript, и выкладывать их на CodePlex под MPL.
Да, я уверен, что антимонопольный комитет тоже оценит такую шутку юмора.
Кстати, если вы внимательно прочитаете текст обращения на блоге MS, в нем есть фраза «At the end of the day, experts from both companies recognized that building a YouTube app based on HTML5 would be technically difficult and time consuming».