Я видел где то статью, там описывалось, что иногда все же использовать конечный цикл, если в итоге он будет конечным. Использовать заведомо большое число, которое покрывает ориентировочный диапазон, и обрабатывать выход за этот диапазон, каким либо способом, например считать это ошибкой или зависанием.
1. Программисты часто не начинают задачи вечером и до обеда, которые они точно не успеют (работа в потоке).
2. Есть программисты которые работают дома, если проект по фану.
Вот и получается, что приходится вечером на работе смотреть развлекательные сайты, а дома, зная что тебе за это не заплатят, весь фан пропадает.
Есть много проектов, где не нужно решать уникальные задачи, и не нужен R&D. Например игрострой, все что можно уже сделали кчей разных вариантов, уже известны практики разработки, известная сложность, известный компромисы. На начальном этапе уже можно прикинуть, сколько нуна денег и выбрать путь для проекта. Либо это будет простенький говнокод с минимум архитектуры, и попробовать выплестнуть на рынок. Либо будет серьезно прорабатывать архитектуру, потому что проект будет поддерживатся и дизы уверены в его успехе.
А что удивительного? Все ждут пока кнонибудь напишет статью по канкаренси, я например, ждал точно. Еще бы чуть чуть и написал бы кто нибудь другой, может быть и я, это как игра в слабака, кто первый струсит. За статью спасибо!
Это называется Компонентно-ориентированное программирование. И его частный случай для игровых сущностей в геймдеве. Unity3D использует такой подход и некоторые другие движки.
Диапазоны это альтернатива двум опсным итераторам в c++ языке и подобных (начальный и конечный). И я в с++ писал свой вело-рейндж. Но в шарпе уже есть такое, называется енумератор. А после того как добавили Linq с кучей алгоритмов и сахара, плюс еще с генерацией кода запроса, то вопрос вообще отпал.
Но как альтернатива сие решение имеет право на существование =). Хотя обычно такое называют велосипедством. (Статью конечно же плюсанул)
У меня ощущение, что с появлением Linq, это немного неактуально. Оригинальный рейдж подразумевает любой диапазон, а не прямой, и подсовывая разные алгоритмы мы получаем другой диапазон, он может быть с дырками.
Сечас, мейнстрим: Программисты, потратившие пол жизни на изучение С++, берут шарп, и кодят в нем в С++ стиле, попутно бурча, об отсутсвии деструкторов и шаблонов.
Автор верно подметил, если вы давно знакомы с с++ то вам это известно.
И для каждого такого случая есть правило, которое люди игнорируют, пока сами не наткнутся на такой гемор:
1. При делении всегда проверять на 0
2. Не юзать switch, юзать if if else (оптимизатор, если будет уверен, сам все сделает)
3. Не использвать функции в условных операторах (и внутри помнить что не все операнды вычисляются)
4. Ну тут комилятор подсказывает
5. Тонкость, которую нуна знать, потому что указатель может быть и мусорный вообще
6. Всегда в наследуемом классе определать все вирт функции, и все, которые учавствуют в перегрузке. Для первого случая можно юзать патерн — невертуальный интерфейс.
2. Есть программисты которые работают дома, если проект по фану.
Вот и получается, что приходится вечером на работе смотреть развлекательные сайты, а дома, зная что тебе за это не заплатят, весь фан пропадает.
Вот пара ссылок на русском:
Это перевод:
gameinstitute.ru/tutorials/razvivaem-svoyu-ierarhiyu/
Это с геймдевру:
www.gamedev.ru/code/forum/?id=145339
www.gamedev.ru/code/forum/?id=136011
Но как альтернатива сие решение имеет право на существование =). Хотя обычно такое называют велосипедством. (Статью конечно же плюсанул)
Финансово успешные
Технически успешные
И они не всегда коррелируют.
Я встречал людей, которые ждут в резюмэ программиста, список финансово успешных проектов.
И для каждого такого случая есть правило, которое люди игнорируют, пока сами не наткнутся на такой гемор:
1. При делении всегда проверять на 0
2. Не юзать switch, юзать if if else (оптимизатор, если будет уверен, сам все сделает)
3. Не использвать функции в условных операторах (и внутри помнить что не все операнды вычисляются)
4. Ну тут комилятор подсказывает
5. Тонкость, которую нуна знать, потому что указатель может быть и мусорный вообще
6. Всегда в наследуемом классе определать все вирт функции, и все, которые учавствуют в перегрузке. Для первого случая можно юзать патерн — невертуальный интерфейс.
— Нет, будем сидеть на диване и байкотировать медиапродукцию, глядя в ковер.