#prog #rust

cargo-llvm-lines — инструмент для подсчёта количества строк LLVM IR, сгенерированных для каждой функции в программе, с учётом процентного вклада и дубликатов. Автор — ожидаемо Толян dtolnay

#моё #prog #rust

В крейте time есть структура Date с методом format, который возвращает String со датой, отформатированной согласно переданному формату. Выглядит это примерно так (пример из документации):

assert_eq!(date!(2019-01-02).format("%Y-%m-%d"), "2019-01-02");

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

Как примерно должен выглядеть код? Нам нужно абстрагироваться от конкретных типов по операции "отформатируй сюда дату", чтобы из элементарных форматировщиков можно было собрать составной. В самой операции нам, очевидно, требуются: сам форматировщик, дата и буфер, куда будут записываться данные. Мы не хотим возвращать строку непосредственно, потому что это при объединении привело бы ко множеству ненужных мелких аллокаций. Также мы не хотим, чтобы форматировщики могли удалять из буфера данные, поэтому мы сделаем обёртку над строкой с более узким интерфейсом:

use std::fmt;

#[derive(Default)]
pub struct Buf {
    inner: String,
}

impl Buf {
    pub fn new() -> Self {
        Self::default()
    }
    
    pub fn append(&mut self, s: &str) {
        self.inner += s;
    }
    
    // Этот метод позволит нам использовать макрос `write!` на `Buf`.
    // Он позволяет не безусловно выделять новую строку,
    // а использовать место в уже имеющейся
    pub fn write_fmt(&mut self, args: fmt::Arguments) -> fmt::Result {
        self.inner.write_fmt(args)
    }
}

Сам общий интерфейс форматировщиков:

use std::fmt;
use time::Date;

pub trait FormatDate {
    fn format_date(&self, b: &mut Buf, d: Date) -> fmt::Result;
}

(проблем с тем, чтобы принимать Date по значению, нет, потому что это Copy-тип).

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

impl FormatDate for &'_ str {
    fn format_date(&self, b: &mut Buf, _: Date) -> fmt::Result {
        b.append(self);
        Ok(())
    }
}

Теперь напишем реализацию для, скажем, дня даты:

pub struct DayOf;

impl FormatDate for DayOf {
    fn format_date(&self, b: &mut Buf, d: Date) -> fmt::Result {
        write!(b, "{:02}", d.day())
    }
}

Формат "{:02}" означает, что для печати дня отведено два места, и если в номере дня всего одна цифра, то вывод будет дополнен слева нулями. Форматировщики для номера месяца и года пишутся аналогично, поэтому не будем подробнее на этом останавливаться.

#prog #моё

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

Полиморфизм — это свойство кода обрабатывать данные разных типов единым образом. Замечательная вещь, не так ли? К сожалению, истинно полиморфного кода мало: если полиморфная функция делает что-то помимо тасовки аргументов, рано или поздно нужно будет выполнить операцию, специфичную для конкретного типа. Для того, чтобы исполнить полиморфный код, нужно каким-то образом передать в него эти функции для конкретного типа. О том, как это можно сделать и на какие компромиссы при этом приходится идти, я сегодня и расскажу.

1. ad hoc полиморфизм (aka полиморфизм для бедных). В этом варианте мы не прилагаем никаких специальных усилий к обеспечению полиморфизма: достаточно разрешить иметь в языке перегрузку функций. При подстановке конкретного типа в обобщённый код компилятор ищет перегрузки с соответствующими типами и вставляет нужные вызовы.

Достоинства:
* Легко реализовать.

Недостатки:
* Наличие перегрузки сразу ставит вопрос о том, какая перегрузка более специфичная, что усложняет рассуждения о коде.
* Требует наличия в языке механизма написания кода с отложенной проверкой типов (макросы в C и шаблоны в C++ под это определение в данном контексте подходят).
* Непосредственное следствие из предыдущего пункта: ошибки несоответствия типов ловятся по месту использования, а не по месту определения, что затрудняет отладку кода и написание высокообобщённого кода ("У меня не сошлись типы потому, что я неправильно вызвал функцию или потому. что сама функция определена ошибочно?").
* Сам факт обобщённости затруднительно переносить между границами отдельных единиц компиляции (читай, фиг вам, а не динамическая линковка).

Резюмируя: использовать имеет смысл тогда, когда нет других альтернатив.