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

В этой статье мы поговорим о новом предложенном расширении языка С++ — метаклассах. Герб Саттер с коллегами работал над этим предложением около 2 лет и, наконец, этим летом представил его общественности.

Итак, что же такое «метакласс» с точки зрения Герба Саттера? Давайте вспомним наш С++ — самый прекрасный в мире язык программирования, в котором, однако, веками десятилетиями существуют примерно одни и те же сущности: переменные, функции, классы. Добавление чего-то фундаментально нового (вроде enum classes) занимает очень много времени и рассчитывать дождаться включения чего-то нужного вам здесь и сейчас в стандарт — не приходится. А ведь кое-чего и правда не хватает. Например, у нас всё ещё нет (да, наверное, и не будет) интерфейсов как таковых (приходится эмулировать их абстрактными классами с чисто виртуальными методами). Нет properties в полном их понимании, нет даже value-типов (чего-то такого, что можно было бы определить как набор переменных простых типов и сразу использовать во всяких там контейнерах/сортировках/словарях без определения для них разных там операций сравнения, копирования и хеширования). Да и вообще постоянно чего-то кому-то не хватает. Разработчикам Qt вот не хватает метаданных и кодогенерации, что заставляет их использовать moc. Разработчикам C++/CLI и C++/CX не хватило способов взаимодействия со сборщиком мусора и своими системами типов. Ну и т.д.

А давайте на секунду представим, что мы сами можем вводить в язык новые сущности. Ну или пусть не прямо «сущности», а правила проверки и модификации классов.

Что?

Привет, Хабр! Прошло очень много лет, с тех пор как я писал сюда. Надеюсь, время тебя/меня не слишком/слишком потрепало.

Я хотел бы написать о нашем опыте переосмысления идей QML. Qt — прекрасная (по совокупности заслуг) библиотека, и хотя её внутреннее устройство местами вызывает вопросы, но она дала миру не только кросс-платформенный UI тулкит, но и цельный профессиональный набор инструментов: Дизайнер, Креатор, Лингвист, и, конечно же, Qml. Результатом этого переосмысления стал наш скромный проект, который превращает qml в html5/javascript для разных платформ, и даже позволяет собирать простые android приложения используя Cordova.

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

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

Исходные коды доступны на github, там же лежат исходные коды сайта, примеров и библиотека контролов, которые мы используем для всех своих проектов. Документацию и уроки можно посмотреть на нашем сайте, pureqml.com.
Если вы чего-то не понимаете, можете присоединиться к группе поддержки в Telegram, мы постараемся ответить на все вопросы в реальном времени.

Одно из бесплатных приложений, которые мы сделали, был порт игры Fontanero, она должна быть доступна в маркетах LG/Samsung.

Ну а дальше можно не читать!

Как мы дошли до жизни такой

Всё началось в уже-далеком 2010-ом году, когда мы начали писать встраиваемое ПО (и интерфейс пользователя) в одной крупной корпорации для линейки разношерстных устройств на всевозможных платформах, доступных сейчас: arm, mips, x86, sh4, не хватало только sparc…

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.

Метапрограммирование — вид программирования, связанный с созданием программ, которые порождают другие программы как результат своей работы (wiki). Это достаточно общий термин, к которому, согласно той же википедии, относится и генерация исходного кода внешними инструментами, и различные препроцессоры, и «плагины к компилятору» — макросы с возможностью модификации синтаксического дерева не посредственно в процессе компиляции, и даже такая экзотическая возможность, как самомодифицирующийся код — модификация программы самой программой непосредственно во время выполнения.

Хотя, конечно, самомодифицирующийся код — это скорее отдельная большая тема, достойная отдельного исследования; здесь под метапрограммированием мы будем понимать процессы, происходящие во время компиляции программы.

Метапрограммирование реализовано в той или иной мере в очень разных языках; если не рассматривать экзотические и близкие к ним языки, то самым известным примером метапрограммирования является С++ с его системой шаблонов. Из «новых» языков можно рассмотреть D и Nim. Одна из самых удачных попыток реализации метапрограммирования — язык Nemerle. Собственно, на примере этой четверки мы и рассмотрим сабж.

Метапрограммирование — интереснейшая тема; в этой статье я попытаюсь разобраться, что же это такое, и каким оно должно быть в идеальном случае.

Почему-то в интернете мало документации про qbs, и я решил немного исправить эту ситуацию. Попробую описать в виде повествования, что необходимо сделать, что бы в QtCreator можно было компилировать (и не только) что угодно под что угодно.

Фреймворк Qt предоставляет неплохие средства разработки — входящая в него IDE Qt Creator включает дизайнер, отладчик, профайлер и другие удобные вещи. К сожалению, даже со всем этим иногда не очень понятно, почему приложение в данные момент выглядит так, как выглядит: чего-то не видно, что-то выглядит не так, как ожидалось, где-то неподходящий размер шрифта или неверная картинка.

Часть этих проблем может быть решена в Qt Designer, но только часть. Qt Designer имеет несколько существенных недостатков: во-первых, он неверно отображает положение Qt Quick компонентов в случае активного использования Javascript при расчете их координат и размеров, во-вторых в дизайнере мы видим состояние только «пустой» формы, без загруженных в неё данных. В общем, очень не хватает чего-то вроде инструментов разработчика в любом современном браузере: чтобы можно было посмотреть всё дерево компонентов, найти нужный, увидеть его положение относительно других, свойства, поправить на лету что-то, подобрать цвет\шрифт\размер, увидеть какие обработчики повешены на события и т.д.

И такой инструмент в мире Qt появился! Встречайте — GammaRay, средство интроспекции приложений на Qt. GammaRay понимает, что такое Qt, из чего состоит ваше Qt-приложение, как в нём взаимодействую компоненты, как они выглядят, как генерируются и обрабатываются события и т.д. Давайте посмотрим, что умеет GammaRay.

Пятая версия Android была выпущена почти полгода назад. Несмотря на это, большинство приложений в маркете до сих пор упорствуют в стиле Holo. То ли новый Material-стиль пока не по зубам среднему разработчику, то ли Android L еще не успел прочно войти в обыденность.

Как бы там ни было, новая парадигма дизайна активно пропагандируется «корпорацией добра», да и выглядит достаточно неплохо, несмотря на некоторую непоследовательность. И все больше появляется добрых волшебников, помогающих нам, простым разработчикам, оставаться «в струе» изменчивого мира мобильного UI.

Если вы, как я недавно, твердо решили обернуть своё, давно не обновлявшееся, приложение в новую «шкурку», этот обзор инструментов и библиотек может сэкономить вам N часов времени.

В течение десяти с небольшим лет своего существования ReSharper был ориентирован на .NET-разработчиков, что не удивительно для плагина к Visual Studio. 2 года назад, в чем-то благодаря удачной первоапрельской шутке, мы вплотную занялись поддержкой С++ в ReSharper, и вот совсем недавно был выпущен первый официальный релиз ReSharper C++ — нового продукта специально для разработчиков на C/С++ в Visual Studio. (Тем, кто заждался релиза CLion для кросс-платформенной разработки на C/C++, понадобится еще немного терпения.)

Чем же может быть полезен ReSharper C++? Разберем основные возможности продукта.

Для синхронизации данных в приложениях не подходят обычные «файловые» облачные хранилища. Слишком много проблем с консистентностью данных приходится решать самим авторам приложений. Поэтому сегодня мы открываем всем желающим технологию DataSync API, которую команда Яндекс.Диска разрабатывала для собственных сервисов Яндекса. Она позволяет синхронизировать структурированные данные между облачным хранилищем и устройствами. API использует логин Яндекса, который есть почти у каждого пользователя интернета в России и у многих в других странах. DataSync мультиплатформенный и не завязан только на Android или iOS.



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

Уже более двух лет Яндекс.Браузер работает на технологиях синхронизации Я.Диска. В ближайшем будущем другие крупные сервисы Яндекса начнут объединять свои платформы на DataSync. Под катом — больше подробностей о том, как он устроен, зачем нужен, и примеры, на которых можно посмотреть и попробовать, как всё работает.

Эта публикация о том, как можно в Windows скомпилировать библиотеку для обработки видео и аудио FFmpeg под Android в Eclipse с помощью NDK. Вы узнаете, как связать FFmpeg с библиотекой для обработки изображений OpenCV и как это всё можно использовать в Java-коде Android приложения. Всё это будет рассказано в контексте процесса создания Android приложения, основной функционал которого как раз и завязан на использовании этих библиотек и их взаимодействии. Итак, заинтересованных прошу под кат.

Уже сейчас Qt – неплохая среда для разработки мобильных приложений, однако некоторые моменты там остаются недоработанными. Так, например, если попробовать запустить стандартный пример с камерой, он будет работать в системе Windows, но не на Android. При этом примеры, использующие камеру в через Qml, вполне рабочие. А значит работа с камерой на Android — реализована, но полного доступа к ней нет. А если мы хотим свободы иметь доступ к видеопотоку?

Хорошо в плане поддержки JSON живётся программистам на Javascript — по какому-то невероятному стечению обстоятельств там JSON входит в спецификацию самого языка: есть JSON — есть объект. Удобно. Неплохо дело обстоит и в языках, где JSON не входит в сам язык, но поддерживается стандартной библиотекой (Python, Ruby): импортируешь модуль — и готово.

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

И у нас есть ответ на этот вопрос! Давайте посмотрим на JSON-библиотеку для С++ написанную в соответствии со всеми этими принципами, ну и вообще написанной людьми для людей, а не чужими для хищников, как это обычно бывает.

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

Уже год в свободное от работы время я пилю что-то вроде смеси Maven и Spring для С++. Важной её частью является самописная система умных указателей. Зачем мне всё это — отдельная тема. В данной статье я хочу коротко рассказать о том, как одна, казалось бы, полезная фича С++ заставила меня усомниться в здравом смысле Стандарта.

Редактировано:
Приношу свои извинения хабрасообществу и Стандарту. Буквально на следующий день после отправки статьи осознал грубую ошибку в своих размышлениях. Лучше читать сразу конец статьи… и, да, к copy elision, выходит, статья относиться лишь косвенно.

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

Все стало меняться в 2011 году, когда в Google начали усиленно работать над унификацией визуальной части экосистемы своих продуктов и назвали все это Project Kennedy.

Всем привет!

В конце февраля в Москве при поддержке Лаборатории Касперского, JetBrains, PVS-Studio и IncrediBuild прошла конференция C++ Russia, 2015: 2 дня, 2 трека, 16 докладов, 300 участников.

Недавно мы выложили слайды всех докладов и продолжаем работать над обработкой видео. Под катом краткое описание, общее впечатление от конференции со стороны организатора, работа над ошибками, планы на будущее.

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

Это первая и основная статья из упомянутого цикла и она представляет собой введение в систему документирования исходных текстов Doxygen, которая на сегодняшний день, по имеющему основания заявлению разработчиков, стала фактически стандартом для документирования программного обеспечения, написанного на языке C++, а также получила пусть и менее широкое распространение и среди ряда других языков.

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

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

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

Предварительная версия Visual Studio 2015 вобрала в себя ряд новинок, которые наверняка заинтересуют большое количество разработчиков. Мы продолжаем серию онлайн-мероприятий, на которых вы сможете узнать больше о возможностях этого продукта.
Компания Microsoft представляет будущее .NET на всех платформах, включая Linux и Mac, предварительную версию новой Visual Studio 2015, а также новые возможности по кроссплатформенной разработке, включая эмулятор Android, кроссплатформенную разработку на С++, расширенную интеграцию и поддержку Xamarin и многое другое.

Подключайтесь к нашей онлайн-трансляции 4 марта 2015 года в 10:00 (МСК)!