Мелкие пакости: время жизни переменной в Rust

Допустим, хочется получить текстовое представление типа переменной в Rust. При этом в язык входит такая замечательная функция как type_name() -> &’static str принимающая тип выдающая его тектовое обозначение. Само собой, хочет применить его не только для типа (название типа не так уж и полезно в диагностических целях), а к переменной. Логичным для C++ разработчика выглядит приблизительно следующее решение:

fn type_of<'a, T>(_: T) -> &'a str {
    unsafe { std::intrinsics::type_name::<T>() }
}

Но тут возникнет довольно занятная проблема, так как переменная становится недоступной после (с некоторыми ньюансами в зависимости от типа) получения её имени:

error: use of moved value: `*variable_name` [E0382]

После небольшой фрустрации понимаешь, что в принципе это ж фича и компилятор не должен догадываться о моих намерениях только лишь получить тип, а не реально использовать значение. Но делать что-то нужно. Единственным подходящим решением оказывается передача по ссылке (ссылке в понимании Rust, а не C++), что ожидаемо, но немного странно для C++ разработчика.

fn type_of<'a, T>(_: &T) -> &'a str {
    unsafe { std::intrinsics::type_name::<T>() }
}

Вообще, все эти мелкие пакости модели памяти постоянно преследуют при программировании на Rust. Никак не могу понять, это реально зло или я просто еще не привык и просто мыслю моделью памяти C++?

Rust в Dropbox

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

> Are you happy using rust ?
Yes, overall the team has been very pleased with it. Compile times are the only serious complaint.

> How many lines of rust code are you using in production?
About 60k of our own, about 300k incl crates.

> Are you using nightly? or just stable version of rust?
We’re pinned to a particular nightly right now, as we rely on a fair amount of features that are still stabilizing. I imagine we’ll be on a stable by this summer.

> What drove the move to Rust precisely? Most of the players in the industry are somewhat reluctant about moving to Rust.
Well, we basically needed C++, but:
1) Dropbox doesn’t have a strong C++ ecosystem on the backend, and it takes a lot of work to build one.
2) Given (1), we had basically a blank slate, and our team is C++ and Haskell type folks, we decided to use Rust so we could get C++ with better type safety and fewer sharp corners.
So realistically, if we had been at a place with an awesome preexisting set of C++ libraries, practices, etc, we probably never would have used Rust.

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

Генератор CMakeLists.txt файлов

Довольно часто возникает необходимость быстренько написать тестовое приложение на C++ и опробовать в нем что-то. IDE я не слишком люблю, а каждый раз где-то выискивать завалявшийся шаблон к CMake-у довольно лениво. После очередных поисков запилил небольшой вспомогательный скриптик (само собой на Python) для генерации CMakeLists.txt.

На данный момент поддерживается только генерация приложений, как надоест конвертировать приложения в библиотеки, так будут и они генериться

Сам скриптик с руководством по использованию тут: https://github.com/astavonin/gen-cmake

Clojure & SQLite

С базами данных я не работал уже лет… 10 наверное. Само собой, мой старый опыт это ODBC, C++ обертки над ним и прочие реально страшные штуки. И тут я столкнулся с современными способами взаимодействия с базами данных и не в монстроподобном C++, а в изящной Clojure и обомлел! Все так просто, изящно, правда, потенциально, тормознуто Но про тормознутость это не более чем теория вызванная тяжелым C++ опытом, когда подозреваешь в плохой оптимизации все, что автоматически генерирует какие-либо сущности.

На мой неискушенный взгляд, поддержка баз данных в Clojure замечательная. Я ограничился довольно скромным набором состоящим из ядра org.clojure/java.jdbc, драйвера для SQLite org.xerial/sqlite-jdbc и библиотечки для работы с SQL в Clojure-стиле java-jdbc/dsl. Continue reading

Обработка исключений в Clojure

Одной из основных претензий к Java у меня всегда была её “многословность”. Особенно эта многословность раздражает в обработке исключений, где сравнительно небольшой участок кода часто обильно сдабривался “соплями” обработки исключений. Разнообразные среды типа IDEA эту многословность позволяли в той или иной степени сгладить в процессе написания кода, но, к сожалению, она никуда не девалась из кода уже написанного и мозолила глаза. Как эту радость прятали в Scala я уже не помню, т.к. язык мне показался мало пригодным для моих нужд, а вот варианты доступные в Clojure мне очень даже понравились.
Исключения в Clojure, по логике работы с ними, можно разделить на две группы. Первая группа – это исключения возбуждаемые Java-библиотеками. Для примера возьмем функцию выполняющую запрос HEAD:

(defn test-fn [url]
  (client/head url)
  )

Continue reading

Конфигурации

Со всех сторон нас окружают файлы конфигураций. Иногда, это просто некий набор значений по умолчанию, который читается на старте и пишется при изменениях. Такой тип конфигураций обычно оказывается в более-менее приемлемом и читабельном виде вне зависимости от его формата. Но периодически приходится сталкиваться с довольно странной формой извращения – “программирование на конфигурациях”. Обычно для этих целей берется совершенно не пригодный инструмент, например XML файл или, что еще хуже, база данных и придумывается загадочный псевдоязык для скрещивания логически не совместимых вещей.
Continue reading

C++XX в CMake

Вообще я очень люблю использовать CMake для создания различных небольших тестов. Собирается везде, ручной работы ощутимо меньше, чем если писать правила для Make, генерируется поддержка для любой IDE (если тестик в что-то более крупное перерастет и т.д). И как-то меня угораздило “проспать” как CMake 3.x так и довольно полезную фифу в нем – простое и понятное подключение поддержки C++11. Я всегда подключал C++11 по старинке:

list( APPEND CMAKE_CXX_FLAGS "-std=c++11")

Но, оказывается-то, прогресс шагнул далеко вперед! так что для тех кого так же как и меня “заморозили” сообщаю – все стало проще и понятнее:

cmake_minimum_required(VERSION 3.1 FATAL_ERROR) # (1)
project(cpp11_test)

add_executable(cpp11_test main.cpp)

set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11)          # (2)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD_REQUIRED ON) # (3)

Прекрасная фича доступна начиная с CMake 3.1 1 и включается она 2 очень просто. Если какие-то обходные пути при отсутствии у компилятора поддержки C++11 не планируются, то стоит объявить 3 наличие поддержки C++11 обязательной.

Браузер в песочнице

По не совсем понятным мне причинам, ряд критичных к наличию уязвимость приложений, например широко распространенный браузер Firefix, игнорируют использование встроенной в OS X песочницы. Казалось бы, много какие приложения могут игнорировать песочницу, но никак не те, которые скачивают и так или иначе исполняют произвольный контент из интернета. Возмущаться, конечно, можно долго, а можно просто взять и запустить этот самый Firefox в песочнице. Безопасно, интересно и познавательно

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

  • Запустить генератор профайла и выкинуть все лишнее;
  • Запускать приложение и отслеживать все, что выводится в консоль с тегом sandbox.

Continue reading

Swift – это изумительно!

Давно ничего не писал по программированию, т.к. у меня возрадилось старое хобби – фотография. Но про такое я просто не могу молчать! Язык Swift просто покорил меня с первого взгляда! Я долго откладывал знакомство с ним, воспринимая язык как улучшенную версию Objective-C в чем был сильно не прав. Первые впечатления которые оставляет язык – это как Python, только лучше и со статической типизацией. Основная крайне досадная проблема связанная с языком – поддержка исключительно OSX. Хотя, насколько я помню, было обещание Apple выпустить язык под какой-то свободной лицензией, что меня сильно обнадеживает.

На данный же момент мы получили просто мечту OSX/iOS разработчика.
Continue reading

TeamLead С++ OSX wanted!

Не думал что когда-то напишу такое, но… я ищу себе замену! По деньгам не обидят, официально вилка звучит как 140-180. Функцоинал двоякий, есть интересное, есть болото, но это как и в любой другой работе. Писать можно мне на e-mail. Если не интересно самим, поделитесь с теми, кому может быть интересно. Заранее спасибо!

C++ TeamLead, описание вакансии

Основные функции и задачи:

  • Создание программных решений в составе команды разработчиков;
  • Анализ требований и постановка задач членам команды;
  • Разработка оптимальных решений, оценка трудоемкости задач;
  • Участие в подготовке проектной и технической документацию по порученным задачам.

Позиция предполагает работы по:

  • портированию существующих Windows-компонент на Mac (включая и последующую отладку портированного кода);
  • реализации Mac-специфических компонент и сервисов (включая драйвера);
  • интеграции компонент в общий продукт.

Требования к кандидату:

Обязательно:

  • Инициативность и умение внятно, корректно обосновать логичность и правильность выбранного решения;
  • Опыт в управлении командами до 10 человек;
  • Опыт в создании WBS, распределении задач по членам команды и контроле за их выполнением;
  • Отличное знание C и C++;
  • Отличное знание библиотек STL и BOOST;
  • Знание платформы Mac OS X ИЛИ обширный опыт разработки под *NIX системы (FreeBSD, Linux, etc.) и желание перейти в разработку под Mac OS X;
  • Знание инструментальных средств разработки под *NIX, таких как GDB, Make, CMake;
  • Знание Sh, стандартных консольных *NIX приложений и какого-либо скриптового языка (предпочтительно Python);
  • Опыт работы с логами и крэш-дампами;
  • Опыт разработки мультиплатформенных систем (Windows, UNIX).

Желательно:

  • Понимание принципов и опыт разработки многоуровневых клиент-серверных приложений;
  • Знание и опыт использования межпроцессных взаимодействий;
  • Понимание принципов основных сетевых протоколов (как минимум TCP/IP);
  • Опыт портирования приложений с Win32 и UNIX.