23:36
Untitled [360]
О том, почему плохо применять одну и ту же переменную для двух разных задач.
Была одна процедура (процедура в смысле "логическое действие, которое должна выполнять программа", а не в смысле "функция в терминах языка программирования, которая не возвращает значения") и она имела, допустим, три режима:
#define MODE1 1
#define MODE2 2
#define MODE3 3
А у каждого из режимов было два подрежима:
#define MODE1A 1
#define MODE2A 2
#define MODE3A 3
#define MODE1B 4
#define MODE2B 5
#define MODE3B 6
И была переменная, которая хранила ОБА этих режима.
int nMode;
СНАЧАЛА там хранился общий режим и процедура работала с его использованием. Но, на определённом этапе (которой пришлось долго вычислять, т.к. процедура длинная) та же переменная начинала хранить уже ПОДРЕЖИМ. При этом диагностику затрудняло то, что числовые значения констант частично совпадали.
Не надо так.
P.S. Предвижу вопрос "Почему не сделали сразу просто хранение подрежимов, а на режимы бы просто не забили?". На самом деле режимов не три, а больше. А число подрежимов у каждого режима -- своё. На определённом этапе ветвление осуществляется по коду режима, а по коду подрежима -- потом. Поэтому разделение на "режим" и "подрежим" логично. Что нелогично -- так это одна переменная и под то и под другое. И что очень плохо -- что замена режима на подрежим происходила при вызове определённой функции ВНУТРИ неё, при этом замена производилась по ссылке:
void non_suspicious_name(int a, int b, int &mode)
{
mode=0;//...или что-нибудь ещё
}
//в другой функции
non_suspicious_name(val1,val2,nMode);
// теперь тут уже не режим, а подрежим
Это аргумент в пользу того, чтобы не использовать ссылки, а только указатели.
Была одна процедура (процедура в смысле "логическое действие, которое должна выполнять программа", а не в смысле "функция в терминах языка программирования, которая не возвращает значения") и она имела, допустим, три режима:
#define MODE1 1
#define MODE2 2
#define MODE3 3
А у каждого из режимов было два подрежима:
#define MODE1A 1
#define MODE2A 2
#define MODE3A 3
#define MODE1B 4
#define MODE2B 5
#define MODE3B 6
И была переменная, которая хранила ОБА этих режима.
int nMode;
СНАЧАЛА там хранился общий режим и процедура работала с его использованием. Но, на определённом этапе (которой пришлось долго вычислять, т.к. процедура длинная) та же переменная начинала хранить уже ПОДРЕЖИМ. При этом диагностику затрудняло то, что числовые значения констант частично совпадали.
Не надо так.
P.S. Предвижу вопрос "Почему не сделали сразу просто хранение подрежимов, а на режимы бы просто не забили?". На самом деле режимов не три, а больше. А число подрежимов у каждого режима -- своё. На определённом этапе ветвление осуществляется по коду режима, а по коду подрежима -- потом. Поэтому разделение на "режим" и "подрежим" логично. Что нелогично -- так это одна переменная и под то и под другое. И что очень плохо -- что замена режима на подрежим происходила при вызове определённой функции ВНУТРИ неё, при этом замена производилась по ссылке:
void non_suspicious_name(int a, int b, int &mode)
{
mode=0;//...или что-нибудь ещё
}
//в другой функции
non_suspicious_name(val1,val2,nMode);
// теперь тут уже не режим, а подрежим
Это аргумент в пользу того, чтобы не использовать ссылки, а только указатели.
23.03.2015 в 00:05
23.03.2015 в 00:14
-- Minoru
23.03.2015 в 00:47
>>Когда появится система или программа
Об этом рассказ Генри Каттнера "Некуда отступать" из этого сборника -- zhz00.diary.ru/p200379622.htm . К сожалению, мне не удалось его отыскать в электронном виде. Когда сделаю OCR, сообщу.
>>Вы там по какому стандарту пишете? В C89 и позже есть enum.
По традиции, принятой ещё до меня, мы объявляем списки констант дефайнами таким образом, а не через енум. Чем этот вариант хуже енума?
23.03.2015 в 01:04
Так вот поэтому, может быть, вы сами и расскажете zHz? И вообсче, мне интересно, шо вы об этом думаете, а не Каттнер.
23.03.2015 в 19:35
23.03.2015 в 20:35
> Чем этот вариант хуже енума?
Ничем; наезд отзывается. Я совершенно забыл, что enum молча кастится в int; мне казалось, что вот это должно выдать ворнинг:
-- Minoru
24.03.2015 в 00:20
Ящитаю:
1. Что если такая система появится у одной из стран (на уровне правительства), она постарается как можно дольше скрывать этот факт, а пока факт скрыт -- захватить мир.
2. После захвата мира будет установлен полностью тоталитарный режим, подавляющий любые волнения среди народа, и, возможно, насилие и преступность. Это будет возможно, т.к. все действия людей будут предсказуемы аналогичным образом (как и политическая ситуация) и обмануть систему будет невозможно.
3. Система будет стабильна до тех пор, пока какой-либо из правителей (если правители останутся как класс -- т.к. при такой системе всё может управляться одной машиной) не сломает эту машину к чёртовой бабушке. Как только машина будет сломана, начнётся массовое насилие, убийства, грабежи и прочее. Потом сценарий средневековья.
4. Если же в процессе захвата мира такая система окажется сразу у нескольких игроков, то рано или поздно все игроки кроме одного будут подавлены, т.к. даже если обе стороны будут делать ЛУЧШИЕ ходы, одна из сторон проиграет (вы играли когда-нибудь в "го"?). После этого см. п. 2.
5. Возможен случай и вооружённого нейтралитета. В данном случае тоталитарный режим, скорее всего, устанавливать не будут, т.к. каждая из сторон будет пенять на другую по поводу прав человека. Но как только одна из стран увидит, что она расположена в гарантировано выигрышной ситуации -- она обязательно начнёт чистить табло соседней, т.к. ей за это ничего не будет.
24.03.2015 в 01:46
Как именно? Хотя бы теоретически. Приблизительно. А?