Value Semantics (CppCon 2022) - C/C++

Здравствуйте, B0FEE664, Вы писали:

BFE>Пример на 7:07 class invariant

BFE>То, что эти данные приватные ничего не меняет, если вектора два, то должен существовать код обеспечивающий их инвариантность...
BFE>Фактически это архитектурно неверное решение, так как нам надо заниматься согласованием двух независимых объектов xs и ys.

Не понял с чем ты не согласен. Два вектора это данность, это просто пример двух классов членов другого класса, между которыми нужно поддерживать строго определённый набор состояний. Он просто таким образом иллюстрирует зачем нужен класс и что такое поддержка инварианта. Представь что ты не можешь их объединить, что это два независимых класса, какие-нибудь: gl::vector и dx::vector.

Если инвариант не нужен, то и класс не нужен. Достаточно структуры.

BFE>И далее всё так же...
Дальше всё совсем не об этом.

Здравствуйте, Videoman, Вы писали:

V>Не понял с чем ты не согласен. Два вектора это данность, это просто пример двух классов членов другого класса, между которыми нужно поддерживать строго определённый набор состояний. Он просто таким образом иллюстрирует зачем нужен класс и что такое поддержка инварианта. Представь что ты не можешь их объединить, что это два независимых класса, какие-нибудь: gl::vector и dx::vector.
Ну, если у нас такая ситуация, то у нас проблема: ошибка проектирования. Но каким образом это относится к Value Semantics ?

V>Если инвариант не нужен, то и класс не нужен. Достаточно структуры.
BFE>>И далее всё так же...
V>Дальше всё совсем не об этом.
Не об этом, но в таком же стиле. Какие-то не связанные друг с другом задачи и не относящиеся к ним решения.

Там по делу наверное только про сортировку, но:
— то, что при наличии возможности перемещать объекты, объекты следует перемещать, а не передавать на них ссылки говорилось сразу после введения С++11.

— что будет с вектором, когда (на 35:44) при сортировке будет брошено исключение? Потеряем все данные?

К чему там всё остальное вообще не понятно. Если память не ресурс, то на каждое изменение копируем значение — это теория программирования первого курса университета.

BFE>при сортировке будет брошено исключение

🤡

Здравствуйте, B0FEE664, Вы писали:

BFE>Ну, если у нас такая ситуация, то у нас проблема: ошибка проектирования. Но каким образом это относится к Value Semantics ?
Да что ты привязался к конкретике. Он просто объясняет что такое инвариант, зачем нужен класс и что по его мнению инварианты легко нарушить с reference semantics.

BFE>Там по делу наверное только про сортировку, но:
BFE>- что будет с вектором, когда (на 35:44) при сортировке будет брошено исключение? Потеряем все данные?
Не знаю что ты увидел на 35:44, не понятно, приведи пример

BFE>К чему там всё остальное вообще не понятно. Если память не ресурс, то на каждое изменение копируем значение — это теория программирования первого курса университета.
Тут фиг поспоришь. Функциональное программирование наше всё. Жалко что на практике память тоже нужна.

Здравствуйте, B0FEE664, Вы писали:

BFE>- что будет с вектором, когда (на 35:44) при сортировке будет брошено исключение? Потеряем все данные?

Тут вопрос где следует ловить исключение, когда sort принимает параметр как inout. Может быть в самой функции?

Или просто inout мувнет состояние объекта обратно, даже при исключении? Собственно процесс муванья желательно делать noexcept, скорее всего.

Здравствуйте, night beast, Вы писали:

NB>то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?

А я так и не понял, зачем оттуда что-то вытаскивать. Место на диске экономить? Или какие-то религиозные заморочки?
Что не используешь — то не мешает. Зато установить можно разом, а не возиться из-за каждой новой понадобившейся фичи.

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

Здравствуйте, ути-пути, Вы писали:

NB>>то есть это его надо благодарить за то что коллекцию библиотек превратили в хренов монолит, вытащить что-то из которого тот еще геморрой?

УП>А я так и не понял, зачем оттуда что-то вытаскивать. Место на диске экономить? Или какие-то религиозные заморочки?
УП>Что не используешь — то не мешает. Зато установить можно разом, а не возиться из-за каждой новой понадобившейся фичи.

затем что мне не нужно в проекте то, что я не использую

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

Я долго откладывал написание соображений на эту тему. В начале думал создать отдельный пост.
Я написал версию двух вспомогательных шаблонов cref<T> и in<T> , служащих для передачи параметров в функцию.
Как на ваш взгляд можно сделать лучше?

https://cpp.godbolt.org/z/ETjzoKhKj

cref<T> это простой алиас на const T &

in<T> мувает полученный параметр во внутреннее состояние с предоставлением доступа на запись/чтение.
Его нестатический метод move() нужен к примеру чтобы вернуть значение из функции.

Про inout<> и ref<> я напишу отдельно (скорее всего ответом на исходную тему).
std::array мувать смысла видимо нет, вот для него и ref<> сойдёт.

#include <utility>
#include <vector>
#include <iostream>

template <typename T>
using cref = const T &;

template <typename T>
struct in {
  using t_data = T;
  using t_read = const T &;
  using t_write = T &;
  using t_move = T &&;

  // data
  t_data    m_value;

  in(t_data && p) : m_value{std::move(p)} {}
  in(t_data & p) : m_value{std::move(p)} {}

  t_read read() const { return m_value; }
  t_write write() { return m_value; }
  t_move move() { return std::move(m_value); }

  // forbid
  in() = delete;
  in(cref<in>) = delete;
  in(in &&) = delete;
  in & operator = (cref<in>) = delete;
  in & operator = (in &&) = delete;
};

// testing

using t_vector = std::vector<int>;

void print(cref<t_vector> p, char name) {
  std::cout << name << ": ";
  if( p.empty() ) { std::cout << "empty vector\n"; }
  else {
    for( typename t_vector::const_reference it : p ) {
      std::cout << it << ' ';
    }
    std::cout << '\n';
  }
}

void test_in(in<t_vector> p) {
  std::cout << "test_in()\n";
  p.write().push_back(4);
  print(p.write(), 'p');
  std::cout << "test_in() end\n";
}

t_vector test_in_ret(in<t_vector> p) {
  std::cout << "test_in_ret()\n";
  return p.move();
}

int main() {
  std::cout << "# test 1\n";
  {
    t_vector v{1, 2, 3};
    print(v, 'v');
    test_in(v);
    print(v, 'v');
  }
  std::cout << "# test 2\n";
  {
    t_vector d{4, 5}, v;
    print(d, 'd'); print(v, 'v');
    v = test_in_ret(d);
    print(d, 'd'); print(v, 'v');
  }
  return 0;
}

Здравствуйте, Sm0ke, Вы писали:

S>https://cpp.godbolt.org/z/ETjzoKhKj

S>cref<T> это простой алиас на const T &

S>

S>template <typename T>
S>using cref = const T &;
S>

Тут проблемка есть: при таком определении, cref<T> — не всегда константная ссылка, например:

http://coliru.stacked-crooked.com/a/f110a7aead6d4f5d

#include <iostream>

template <typename T>
using cref = const T &;

template <typename T>
cref<T> make_cref(T&& t) { return cref<T>(t); }

int main()
{
    int i = 42;

    make_cref(i) = 666;

    std::cout << i << std::endl; // -> 666
}

Зачем это нужно вообше? Чтоб еще больше запутать тех, кто и так путается?

S>std::array мувать смысла видимо нет, вот для него и ref<> сойдёт.

Ну, как посмотреть. Если это, например, std::array<std::unique_ptr<HardThing>, N>, то очень даже есть смысл.

Отредактировано 04.02.2023 18:30 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 18:29 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 18:04 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:49 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:40 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:38 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:37 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:32 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:29 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:28 rg45 . Предыдущая версия .

Отредактировано 04.02.2023 17:26 rg45 . Предыдущая версия .

Здравствуйте, rg45, Вы писали:

S>>

S>>template <typename T>
S>>using cref = const T &;
S>>

R>Тут проблемка есть: при таком определении, cref<T> — не всегда константная ссылка, например:

R>http://coliru.stacked-crooked.com/a/308af58edc86d8bc
R>

Код примера

R>#include <iostream>

R>template <typename T>
R>using cref = const T &;

R>template <typename T>
R>cref<T> make_cref(T&& t) { return cref<T>(t); }

R>void test(const int& i) { std::cout << "Non-mutable: " << i << std::endl; }

R>void test(int& i) { std::cout << "Mutable: " << ++i << std::endl; }

R>int main()
R>{
R>    int i = 42;

R>    test(make_cref(i)); // -> Mutable: 43
R>}
R>

Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции.
А вы его возвращаете из return и используете не по назначению.

Это просто чтобы не писать const type & — а для наглядности. Но какой в этом тогда смысл?
Его определение можно по желанию переписать для trivial типов через std::conditional, чтобы они по const копии передавались, а не по ссылке.
Например зачем char передавать по конст ссылке?

Здравствуйте, Sm0ke, Вы писали:

S>Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции.

1. Из чего следует, что cref нельзя использовать так, как показал я?
2. Что случится плогого, если доработать его таким образом, чтоб он гарантированно обеспечивал константную ссылку и соответствовал своему названию?

S>Это просто чтобы не писать const type & — а для наглядности. Но какой в этом тогда смысл?
S>Его определение можно по желанию переписать для trivial типов через std::conditional, чтобы они по const копии передавались, а не по ссылке.
S>Например зачем char передавать по конст ссылке?

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

Здравствуйте, Sm0ke, Вы писали:

S>Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции.
S>А вы его возвращаете из return и используете не по назначению.

Ну, хорошо, можно и без make_cref, и без return. В таком примере все "по назначению"?

http://coliru.stacked-crooked.com/a/c4d021b1f60b8384

#include <iostream>

template <typename T>
using cref = const T &;

void process(cref<int>) { std::cout << "Constant" << std::endl; }
void process(int&) { std::cout << "Mutable" << std::endl; }

template <typename T>
void process_as_cref(T&& t) { process(cref<T>(t)); }

int main()
{
    int i = 42;

    process_as_cref(i);
}

Здравствуйте, Sm0ke, Вы писали:

S>Его определение можно по желанию переписать для trivial типов через std::conditional, чтобы они по const копии передавались, а не по ссылке.

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

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Sm0ke, Вы писали:

S>>Зачем вам нужен make_cref()? Напомню, что такой cref предназначен лишь для входных параметров функции.
S>>А вы его возвращаете из return и используете не по назначению.

R>Ну, хорошо, можно и без make_cref, и без return. В таком примере все "по назначению"?

R>http://coliru.stacked-crooked.com/a/c4d021b1f60b8384

R>

R>#include <iostream>

R>template <typename T>
R>using cref = const T &;

R>void process(cref<int>) { std::cout << "Constant" << std::endl; }
R>void process(int&) { std::cout << "Mutable" << std::endl; }

R>template <typename T>
R>void process_as_cref(T&& t) { process(cref<T>(t)); }

R>int main()
R>{
R>    int i = 42;

R>    process_as_cref(i);
R>}
R>

Можно просто написать:
void process_as_cref(T&& t) { process(t); }

Здравствуйте, rg45, Вы писали:

R>Тут проблемка есть: при таком определении, cref<T> — не всегда константная ссылка, ...
http://coliru.stacked-crooked.com/a/f110a7aead6d4f5d
Спасибо, что нашли ошибку.

А что если определить так?

#include <type_traits>

template <typename T>
using cref = const std::remove_reference_t<T> &;

Здравствуйте, Sm0ke, Вы писали:

S>А что если определить так?
S>

S>#include <type_traits>

S>template <typename T>
S>using cref = const std::remove_reference_t<T> &;
S>

Можно так, можно чуть короче:

template <typename T>
using cref = const std::decay_t<T> &;

Но тогда возникает следующая проблема:

template <typename T>
void foo(cref<T>);

int main()
{
    foo(42); // error: couldn't deduce template parameter 'T'
}

А в целом выгоды от использования такого приспособления лично мне не очень понятны. По-моему, const T& проще и понятнее во всех случаях.

Здравствуйте, Sm0ke, Вы писали:

S>Можно просто написать:
S>void process_as_cref(T&& t) { process(t); }

Так и я о том же — вреда от cref больше, чем пользы. Только лишний повод напрягаться при чтении кода.

Здравствуйте, Videoman, Вы писали:

V>- С++ отлично поддерживает value types, поэтому используйте эту возможность по максимуму, где это возможно и не будете иметь каскад описанных в докладе проблем.
А что, многие имели каскад описываемых проблем? Вот всю жизнь так делали и вот тебе на, оказывается проблемы на ровном месте.
V>- Reference types — тоже самое, что глобальные переменные, поэтому избегайте эту семантику как только можете.
Скоуп всё же меньше, не надо драматизировать и нагнетать. В рамках этого скоупа можно легко понять кто и что меняет.
V>А интересным он показался мне потому, что я, неосознанно, сам начал скатываться к тем же методам что используются в докладе, но не мог четко обосновать самому себе. Особенно актуально в свете массовой многопоточки и параллельности.
Это будет работать если обеспечить атомарность конструктора копирования или перемещения, тогда можно будет запускать несколько функций в разных потоках не беспокоясь о гонках, т.к. все они будут работать со своей копией данных.
Ещё коллега B0FEE664 задал корректный вопрос про исключение при move.
V>Интересно мнение коллег, кто что думает на эту тему?
Насмотрелись на иммутабельность в функциональных языках и тащат теперь везде. Я думаю проблема связана больше с конструкциями async/await в итоге, чем с тем что он приводил как "проблему".

Здравствуйте, B0FEE664, Вы писали:

BFE>То, что эти данные приватные ничего не меняет, если вектора два, то должен существовать код обеспечивающий их инвариантность...
BFE>Фактически это архитектурно неверное решение, так как нам надо заниматься согласованием двух независимых объектов xs и ys. "заниматься согласованием" — это означает дополнительную работу, дополнительный код, который занимается согласованием, для обеспечения инвариантности. Но смотрите: если объединить x и y в одну структуру, то у нас останется один вектор xy для которого инвариантность соблюдается автоматически! И никакого дополнительного кода, никаких проверок не надо.

BFE>И далее всё так же...

Т.е. поработали над 2мя типами структур, сделали 1у и теперь всё норм? Можно лишь 1 вектор. Звучит не плохо. Т.е. он же, к примеру, работал с тем что ему дали. И сказал почему это плохо. Может, мы можем провести аналогии и к нашему коду и сделать подобное улучшение, что он показал.

От:	Videoman	https://hts.tv/
Дата:	10.01.23 13:22
Оценка:

	От:	B0FEE664
	Дата:	10.01.23 14:56
	Оценка:

	От:	σ
	Дата:	10.01.23 15:02
	Оценка:	+1

От:	Videoman	https://hts.tv/
Дата:	10.01.23 15:12
Оценка:

От:	Sm0ke	http://ksi.ru.net/
Дата:	13.01.23 03:05
Оценка:

	От:	ути-пути
	Дата:	28.01.23 07:26
	Оценка:

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	12.02.23 11:54
Оценка:

	От:	avovana
	Дата:	15.02.23 13:53
	Оценка: