Общие вопросы по программированию (1303 стр)

Dmitry_Milk
> неужели ничего готового нет?
  Если тебе нужен тип для представления специфических данных, то ты делаешь это сам. Так во всех языках. Не вижу особой проблемы в том, чтобы объявить енум с двумя полями. Если тебе даже это лень сделать, значит программирование это не твоё. Иногда специально делают новый тип хотя уже есть другой конструктивно такой же просто чтобы в коде они различались, легко можно было найти все случаи использования конкретного типа и чтобы нельзя было случайно присвоить один другому (тайпдеф в крестах от этого не спасает).
  Ну и как уже сказали, ты можешь просто спрятать все нужные операции за интерфейсом, написать его один раз и дальше уже просто вызывать эти методы и в йух не дуть абсолютно не думая что там за проверки происходят внутри.

На словах всё прекрасно.
А на деле обычно тут как раз и начинается швистопляски,перделки-переделки и ловля багов.

Zefick

Программирование похоже не твоё.
А вспомнил ты же на Яве пишешь.

ronniko
> А на деле обычно тут как раз и начинается швистопляски,перделки-переделки и ловля багов.

Например?
Обычно наоборот за интерфейсы прячут чтобы избавиться от ловли багов.

=A=L=X=
> Обычно наоборот за интерфейсы прячут чтобы избавиться от ловли багов.

Ну с другой стороны, если соглашаться с totoro, реализация арифметического интерфейса на типе "int с бесконечностью" и использование этого типа в коде так, будто это конкретное количество - наоборот, ухудшило бы понимание кода.

Dmitry_Milk
> Ну с другой стороны, если соглашаться с totoro, реализация арифметического интерфейса на типе "int с бесконечностью" и использование этого типа в коде так, будто это конкретное количество - наоборот, ухудшило бы понимание кода.

Первый принцип процедурно-модульного программирования - запрятывать работу с какой то сложной сущностью так чтобы реализацию можно было поменять поменяв текст одного конкретного модуля, а все другие модули пользующиеся этими процедурами не надо было переделывать.
Поэтому в твоём случае напрашивается в такой модуль оформить весь этот контейнер с ресурсами - сделать наверное интерфейс типа isInfinity(ResourseMap &, ResourceId) и getValue(ResourceMap &, ResourceId) и через какую мапу от чего оно там внутри реализовано - пофигу становится внешнему коду. Главное как постановщику задачи понять что именно тебе от этого интерфейса надо будет.
Я предположу что для вывода в GUI - asString потребуется и setInfinity и setValue(int) ибо явно в интерфейсе выставлять бесконечность ты будешь галочкой которая будет отключать поле ввода числа. Ну тебе должно быть виднее.
Возможно все сложности с if-ами можно было бы вообще избежать если сделать в интерфейсе enumFinites и enumInfinites. Просто развести в два разных цикла обработки то и другое.

totoro
> и одного бита для признака бесконечности
Или одного состояния

ronniko
> Программирование похоже не твоё.
  От тебя это почему-то слышится наоборот как одобрение. Ведь если роннико чем-то недоволен, то значит скорее всего это правильная вещь, просто роннико слишком недалёкий чтобы это понять.

Dmitry_Milk
> реализация арифметического интерфейса на типе "int с бесконечностью" и использование этого типа в коде так, будто это конкретное количество - наоборот, ухудшило бы понимание кода.
  А так и не надо делать. Надо работать с ним так, как будто это специальный тип данных. Например перед тем, как вычесть из него определённое количество нужно проверить а получится ли сделать это в принципе. И если получится, то тебе уже не важно что там останется после вычитания - какое-то другое число или то же самое. Можно даже сделать метод decreaseAndGet по аналогии с атомиками, который будет возвращать либо новое значение, либо ошибку чтобы не пришлось делать две операции.

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

Покумекал и решил, что корутины можно сделать по эмбеддерской классике - обычный кооперативный мультитаскинг с полу-ручным менеджментом контекста.

boolean yield(CoroutineState state, YieldOperation operation) {
    operation.allocateIfNeeded(state);

    return operation.isCompleted(state);
}

void coroutine(CoroutineState state) {
  if(yield(state, WaitForSeconds(3.0f)) {

  }

}

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

С дебажными итераторами не работает

#ifdef __cpp_lib_constexpr_string
constexpr std::string s;  // error C2131: expression did not evaluate to a constant
  // (sub-)object points to memory which was heap allocated during constant evaluation
#endif

Есть казалось бы простой шаблонный крестокод https://godbolt.org/z/dTfbaxW5s
Чому оно работает только при обращении через this?
Где про енто можно почитать?

nes
> только
не только

> Где про енто можно почитать?
в стандарте, где же ещё.

Aroch
Спасибо кэп )

моё окно при создании вызывает dll текстовый редактор.
Возможно эта dll меняет имя окна.
Как получить имя окна ?
Чтобы увидеть была ли замена имени ?

SetWindowText/GetWindowText

а разве это не title имя ?
имя окна и title могут отличатся.