Обновить
15
0

Пользователь

Отправить сообщение
У вас диапазон в любом случае будет ограничен максимальным значением size_t. В этом же суть этого типа.
Причём не только GCC. RVO давно уже поддерживается большей частью современных компиляторов.
А почему
format!("{}{}", path.file_stem().unwrap().to_str().unwrap(), "_diffuse");
а не
format!("{}_diffuse", path.file_stem().unwrap().to_str().unwrap());


Создалось впечатление, что вы недооцениваете важность социальных связей. К тому же, некоторые люди (почему-то мне кажется, что их большинство) не любят учиться/работать в одиночестве. Для себя всегда отмечал позитивную роль ВУЗа именно в ключе общения с сокурсниками — именно за счёт этого общения вы обзаводитесь начальным багажом культуры своей будущей профессии, зачатками профессиональной этики. Постоянно общаясь с большим количеством деятельных людей с различными интересами в близких областях, вы неплохо расширяете свой кругозор, всегда находитесь в курсе того, что сейчас происходит в различных направлениях вашей области деятельности. От своих одногруппников за время обучения я научился множеству различных вещей. Это не говоря уже о заряде мотивации.
Учился в СПбГПУ. Все 3 пункта отлично выполнялись.
Высокоуровневое ООП на плюсах — это как? И чем оно отличается от невысокоуровневого (или не ООП?)
Некоторые пути непредставимы в валидном utf-8, коими являются все строки в Rust.

А можно подробнее об этом? Ни разу не слышал о не текстовых путях. Какая-то специфическая область?
И чаще всего, как и с некоторыми другими перегружаемыми операторами в C++, лучше так не делать )
Дело не в классах, а в глобальных переменных и странных функциях с побочными эффектами.

P.S. Я, конечно же, понимаю, что это просто решение задачи и вы не стремились создать сверхсопровождаемый код ) Просто обратилось внимание на это.
Как-то по стилю больше на С похоже
Я же не говорил, что нужно искать и пробовать именно опенсурс. Есть готовое решение, которое вам подходит — лучше использовать его. В вашем случае это ваша же библиотека.
Я сам больше 4-х лет по работе имел дело именно с написанием протоколов. Я не говорю, что это сложно (вообще не сложно, если откровенно), просто это лишнее время на написание + отладку, которое можно было бы потратить на разработку игры. Иногда гибкость не нужна, но, обычно, для проекта вроде онлайн игры, который будет постоянно развиваться, лучше бы иметь надёжное и отлаженное решение. Конечно же, это не аксиома, просто мнение.
Дело тут не в том, хорошо они будут делать свою работу или нет. Чтобы хорошо сделать такого рода работу, предусмотрев все нюансы, надо затратить очень много времени, это можно увидеть по репозиториям проектов. Когда же разработка своего протокола это просто побочный эффект от основного проекта, то, обычно, он страдает всеми теми проблемами, о которых написали выше.
Это может показаться смешным, но мне приходилось делать аудит одной игры, в которой из-за использования json и системы polling-based, а не event-based, разработчики уперлись именно в пропускную способностью сетевой карты. И после этого все читаемые и красиво названные поля в json пришлось называть в стиле A, B и т.д. для того, чтобы минимизировать размер пакета.

Эээ, это что за варварство? Поставить их в угол за такие оптимизации. Чем не устраивает gzip или, на крайний случай, msgpack?
Тут проблема в том, что ни один способ вызова методов не универсален. Например с тем же bark(dog) было бы как-раз наоборот — именно «bark the dog» в прямом смысле, тогда как dog.bark() выглядет логично. Хотя Раст позволяет вызывать методы и так и этак, так что можете делать всегда так, как вам кажется правильнее. Хотя, как по мне, это лишает код единого стиля и несколько затрудняет его чтение и анализ в дальнейшем.
Понял. Подобную функциональность трейты обеспечивают. Причём объектам, которые вы кладёте в вектор, не обязательно даже быть одного типа. Получается, возможно, не так лаконично, но делается так:
trait Foo {
  fn bar(&self);
}

impl Foo for u32 {
  fn bar(&self) {
    println!("{:?}", self);
  }
}

impl<'r> Foo for &'r str {
  fn bar(&self) {
    println!("{:?}", self);
  }
}

fn main() {
  let first = 10;
  let second = "str";
  let vec : Vec<&Foo> = vec![&first, &second];
  for elem in vec {
    elem.bar();
  }
}
Перегрузки функций в стиле С++ в Rust вообще нет, насколько мне известно. То есть, вот такой код не скомпилируется:
fn foo(a: u32) {
...
}
fn foo(a: &str) {
...
}

Но, вообще говоря, я понимаю, почему в C++ не реализовано то, о чём вы говорите и понимаю также, почему это вряд ли будет когда либо вообще реализовано в плюсах — представленный вами код требует обязательного RTTI, а в C++ он не обязателен.

А в чём проблема использовать для подобных случаев виртуальные методы?
Ну, собственно, вот, чтобы не быть голословным. Часть стандартной библиотеки, а значит — описаны в стандарте. Если нужна именно ссылка на стандарт, то вот здесь, параграф 18.8, страницы 461-466.
Проблема в том, что с исключениями вы не будете знать, происходит ли в этом регионе ошибка и если происходит то какая. Те же ошибки, связанные с выделением памяти в плюсах может выкинуть вообще любая функция. То есть если исключения есть, то нужно ожидать, что всё бросает исключения.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность