Перегрузка функций по параметрам

В Rust, по релизиозно-техническим причинам не хотят добавлять перегрузку функций по параметрам. Фактически, доступен только вариант из Си с созданием кучи функций с разными именами. На мой взгляд, это просто дико не удобно. Немного подумав, нашел не очень красивый, но работающий обходной вариант:

enum foo_param {
    i(int),
    s(str)
}

fn foo(param: foo_param) {
    alt param {
        i(int_val) {
            io::println(#fmt("foo was called with int == %d", int_val));
        }
        s(str_val) {
            io::println(#fmt("foo was called with str == %s", str_val));
        }
    }
}

fn main() {
    foo(i(10));
    foo(s("test"));
}

Continue reading

Когнитивный диссонанс

Вчера я был поражен на столько, что усомнился в том, во что верил уже лет 10. А именно в том, что при выравнивании 8, размер структур с полями {u64, u32, u16} и {u8, u32, u16} будет одинаков, т.е. равен 16. А ведь приложение собранное Rust утверждает что в первом случае размер 16, что и следовало ожидать, а во втором 12(!!!).

type tuple_type1 = (u64, u32, u16);
type tuple_type2 = (u8, u32, u16);

fn main() {
    io::println(#fmt("size of tuple_type1 = %u, size of tuple_type2 = %u",
        sys::size_of::<tuple_type1>(), sys::size_of::<tuple_type2>()));
    io::println(#fmt("align of tuple_type1 = %u, align of tuple_type2 = %u",
        sys::align_of::<tuple_type1>(), sys::align_of::<tuple_type2>()));
}

Содержимое консоли:

> ./main
size of tuple_type1 = 16, size of tuple_type2 = 12
align of tuple_type1 = 8, align of tuple_type2 = 8

Continue reading

Юнит-тесты и Rust

ИДея написания интегрированных юнит-тестов в Rust мне очень понравилась. Суть в том, что код тестов пишется не где-то сбоку, а в одном и том же файле что и основной рабочий код. И это еще не все! В процессе сборке, при помощи ключа компилятора –test можно запустить их на выполнение и посмотреть результаты их работы. Причем, совершенно не важно то, что у модуля нет функции main, она будет доавленна автоматически.
На практике это выглядит так:

fn foo() -> uint {
    ret 42;
}

#[test]
fn test_foo() {
    let foo_val = foo();

    assert foo_val != 0u;
}

Собираем и смотрим:

> rustc --test test.rc
> ./test
running 1 tests
test test_foo ... ok

result: ok. 1 passed; 0 failed; 0 ignored

На мой взгляд, реализация тестирования в Rust претендует на гордое звание идеальная!

**char to str

С документацией по Rust на данный момент не очень, зато в почтовой рассылке rust-dev@mozilla.org на вопросы отвечают очень быстро. Пусть и дают примеры с ошибками
Сейчас я пишу враппер для libevent, правильнее сказать начал писать. С первой же функцией, которую я выбрал как наиболее простую и ни на что не завязанную, я натолкнулся на вопрос с преобразованием массива Си строк в массив Rust строк.
Для начала пишем прототип функции event_get_supported_methods из libevent и объясняем Rust с какой библиотекой линковаться.

import libc::c_char;

#[link_name = "event"]
native mod c {
    fn event_get_supported_methods() -> **libc::c_char;
}

Теперь сам метод, где нам требуется перекодировка: Continue reading

Миф о Java

Про языки с автоматическим управлением памятью в целом и про Java в частности существует один довольно забавный миф – приложения с автоматическим управлением памяти не текут или текут редко. Бугагашеньки.

Берем известное и крайне популярное среди Java-разарботчиков приложение Intellij IDEA. Открываем в этом приложении большой проект (на мелком не так в глаза бросается) и работаем. Ближе к концу второго-третьего дня работы приложения, объем используемой памяти вырастает с изначальных 300 мегабайт до 700 и IDEA начинает ощутимо тормозить. Полагаю, что дальше будет только больше, лично мне на 700 это дело надоело, и я перезапустил приложение.

Что вобщем-то и требовалось доказать, напортачить можно даже на том языке, где создатели выдали тебе специальный не снимаемый памперс – было бы желание.

using namespace std

В кругах разработчиков C++ периодически возникает спор на тему “почему нельзя/нужно использовать using namespace std“. Наткнулся на довольно показательный пример того, почему этого делать ни в коем случае нельзя.
Товарищ пытается написать удаление пробелов из строки:

#include <iostream>

#include <string>

using namespace std;

int main(int argc, char* argv[]) {
    string str = "";
    cin >> str;
    remove(str.begin(), str.end(), ' ');
    cout << str;
    cin.ignore();
}

и получет довольно неожиданную ошибку компиляции.

'remove': function does not take 3 arguments (C2660)

А все почему? Да потому-что никогда, ни при каких условиях, не надо давать символам из пространства std глобальную видимость! Ведь в данном случае, можно было получить куда более понятное “error: ‘remove’ was not declared in this scope” просто убрав using namespace std.

Пара слов про Android

Начал было, от избытка свободного времени, писать RSDN-клиента для Android. Но что-то Android меня дико разочаровал, так что продолжать писать под эту “чудо-платформу” не буду. Честно сказать не ожидал такого. Претензии по пунктам:

  1. Нормальных биндингов нет. Есть некое жалкое подобие биндингов, работающее со списками и вроде еще с каким-то контролом.
  2. Архитектура построена таким образом, что ты волей-неволей вынужден валить все в Activity. Попытки разнести на слои с данными и логикой заканчиваются диким количеством проблем. Единственное что можно вынести – Content Providers, но на практике этого маловато.
  3. Вторая архитектурная проблема – работа с потоками за пределами Activity так же чрезмерно усложнена. Основная идея платформы – потоки внутри Activity это круто и правильно.
  4. Основной язык разработки – Java. Крайне убогий язык, особенно, если 10 лет писал на C++.

И если пункты 1 и 3, 4 еще как-то можно пережить, то вот мириться со вторым, для меня, совсем сложно.

Внешние проекты в CMake

Я просто весь мозг сломал со следующей ситуцией. Есть CMake проект состоящий из нескольких библиотек и исполнимого модуля. Этот проект использует некую внешнюю по отношению к нему библиотеку. В идеале, в процессе сборки, эту библиотеку надо скачать, собрать, установить и заюзать.
Перечирав кучу документации и устав от эксперементов, я наткнулся на чудесную функцию externalproject_add.

externalproject_add(
    memtree_external
    GIT_REPOSITORY "git@github.com:astavonin/memtree.git"
    CMAKE_ARGS
        -DCMAKE_INSTALL_PREFIX:STRING=${PROJECT_BINARY_DIR}
    UPDATE_COMMAND ""
)
add_library(memtree SHARED IMPORTED)
set_property(TARGET memtree PROPERTY
    IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/lib/libmemtree.a)
include_directories(${PROJECT_BINARY_DIR}/include)

Для того чтобы установка отрабатывала корректно, пришлось добавить несколько строк в CMakeLists.txt

install(FILES ../include/memtree/memtree.h DESTINATION include/memtree)
install(TARGETS memtree DESTINATION lib EXPORT memtree-targets)
install(EXPORT memtree-targets DESTINATION lib/memtree)

Уфф. Убил на это кучу времени, но оно того стоит – обновлять библиотеку теперь куда проще

CMake & Clang

Решил изменить сборку с идущего по умолчанию GCC на Clang для CMake проекта. Сходу наткнулся на граблю. Стандартная команда CMake:

set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_C_COMPILER clang)

Вводит его в вечный цикл, который выглядит как-то так:

You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /usr/bin/gcc
CMAKE_CXX_COMPILER= /usr/bin/c++

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
…и так до бесконечности…

Лечится не удобно, но юзабельно:

export CXX=/usr/bin/clang++
export CC=/usr/bin/clang
cmake CMakeLists.txt
make