Нет, при реализации трейта вы не можете использовать методы из реализации соседнего трейта, только методы и данные самого типа. Т.е. если учть продолжить пример у вас будет:
trait TraitA{
fn a(&self);
}
trait TraitB: TraitA{
fn b(&self);
}
struct My
{
d: i32,
}
impl My
{
fn a_p(&self) {
}
}
impl TraitA for My{
fn a(&self){
self.a_p());
}
}
impl TraitB for My{
fn b(&self){
self.a_p());
// и только так, вы не можете сделать self.a()
}
}
Ключевое слово dyn достаточно хитрое. По факту оно создает новый тип "dyn Trait", который содержит указатель на данные и указатель на методы. Но, помимоо этого вы можете сделать:
impl dyn Trait
{
pub fn my_fn(&self) {
}
}
У типажей нету механизма наследования когда вы пишите:
trait TraitA{}
trait TraitB: TraitA{}
Вы не наследуете TraitB от TraitA, вы накладывает ограничения, чтобы тип определяющий TraitB также определял бы и TraitA. И это две большие разницы.
Это не совсем корректный вопрос. Да, некоторые из тех проверок которые в Си++ проходится делать в рантайме, в Расте можно делать на этапе компиляции. Но вот в чем прикол: понятие "объект" у вас при этом исчезает. И если во многих случаях без него можно обойтись не потеряв производительности (хотя придется и поломать голову), то в некоторых областях (тот же пользовательский интерфейс) это доставлет массу проблем, которые, вполне возможно, выливаются в потерю производительсноти.
Мысль такая: "Если перевыпуск Visa и MasterCard был свзяан с безопасностью, то в условиях когда они не перевыпускаются, то м.б. это и оправдано". Однако видите здесь сколько "м.б." и "если"? Вот отсюда и вопрос
В твердых телах распространение звука имеет принципиально иной механизм, чем в газе. В газе больше роль имеет средняя скорость частиц, которая зависит от массы молекулы и температуры.
Мой опыт показывает, что в 999 случаев из 1000 необходимость в тестировании внутренних методов класса говорит о неправильной декомпозиции. В очень редких случаях, это действительно нужно, но эти тесты уже что-то среднее между интеграционными и юнит-тестами.
Имеет. Фишка в том, что вы можете сформулировать утверждение вида: "Сумма этого ряда равна (число)" и доказать его, предъявив конкретную схему суммирования.
Ряд не имел бы суммы только в одном случае - сама бы операция сложения не может быть определена.
Нет, при реализации трейта вы не можете использовать методы из реализации соседнего трейта, только методы и данные самого типа. Т.е. если учть продолжить пример у вас будет:
Ключевое слово dyn достаточно хитрое. По факту оно создает новый тип "dyn Trait", который содержит указатель на данные и указатель на методы. Но, помимоо этого вы можете сделать:
У типажей нету механизма наследования когда вы пишите:
Вы не наследуете TraitB от TraitA, вы накладывает ограничения, чтобы тип определяющий TraitB также определял бы и TraitA. И это две большие разницы.
Нет, они что-то сродни концептам.
Это не совсем корректный вопрос. Да, некоторые из тех проверок которые в Си++ проходится делать в рантайме, в Расте можно делать на этапе компиляции. Но вот в чем прикол: понятие "объект" у вас при этом исчезает. И если во многих случаях без него можно обойтись не потеряв производительности (хотя придется и поломать голову), то в некоторых областях (тот же пользовательский интерфейс) это доставлет массу проблем, которые, вполне возможно, выливаются в потерю производительсноти.
Мысль такая: "Если перевыпуск Visa и MasterCard был свзяан с безопасностью, то в условиях когда они не перевыпускаются, то м.б. это и оправдано". Однако видите здесь сколько "м.б." и "если"? Вот отсюда и вопрос
Интересно, а с чем был связан постоянный перевыпуск карт этих систем?
В твердых телах распространение звука имеет принципиально иной механизм, чем в газе. В газе больше роль имеет средняя скорость частиц, которая зависит от массы молекулы и температуры.
Молекулы и атом целиком уже классический объект.
Валве тоже, столкнувшись с обвалом продаж.
Мой опыт показывает, что в 999 случаев из 1000 необходимость в тестировании внутренних методов класса говорит о неправильной декомпозиции. В очень редких случаях, это действительно нужно, но эти тесты уже что-то среднее между интеграционными и юнит-тестами.
По идее могу, аксиома выбора мне это позволяет..
UPD Протупил.
Есть такое понятие, как супернатуральное число.
То, что вы просите - доказать инвариантность суммы ряда относительно этой операции. Я же начал ветку со ссылкой на теорему, что это не так.
А операция тождественна в силу аксиом операции сложения в их классическом виде.
Я сделал тождественную замену.
Ноу проблем. Докажем что ряд сходится к 0: (-1+1) + (-1+1) + (-1+1) ... , каждое выражение в скобках равно 0, а вместе с ней и сумма ряда.
Вопрос не в том, что вы так "нарекли", вопрос в том, что можете ли привести доказательство.
Имеет. Фишка в том, что вы можете сформулировать утверждение вида: "Сумма этого ряда равна (число)" и доказать его, предъявив конкретную схему суммирования.
Ряд не имел бы суммы только в одном случае - сама бы операция сложения не может быть определена.
Полез проверять. Фихтенгольц, том 2, глава XV параграф 1:
А вот и ничего подобного.
Ну да. Но это я к тому, что автор дает это как единственно верный ответ, когда на самом деле это не так.