Конфликт мышки и не мышки

[vitaly_l]

юнит с мапом о них ниче может не знать

Я почему-то подумал об отладке и пришёл к выводу, что компилятор тут уже будет слабым помощником. Одна ошибка и вся эта красота, станет громадным неподъёмным багом. А вообще интересное решение, заменять case на бинарный поиск.

[zub]

Отладке это не мешает, только внутрь fpc-stl лазить ненадо. Также плюс подхода - подключил модуль в uses, он в своей секции инициализации зарегистрировал свои процедуры - "фича" появилась. убрал из uses - фича исчезла. С case так не прокатит - нужно будет закоментировать код в куче мест.

[sign]

На этом претензии к нему заканчиваются.

В паре if/if или case/if приходится слишком часто "косячить"... так что лучше перебдеть и вставить лишнее else. Это просто особенность языка и ее никак не исправить, если не менять самого языка. Впрочем, сомневаюсь, что в любом другом языке иначе. Для этого надо изменить саму форму условного оператора, фактически, подписав все условия вручную.

Настройте среду и будет всё видно слёту.

[Лекс Айрин]

sign, проблема не в том, что не видно... а в том, что "точки зрения" компилятора и программиста не всегда совпадают. Это не страшно... просто неприятно.

[zub]

>>а в том, что "точки зрения" компилятора и программиста не всегда совпадают
При этом у компилятора есть строгие правила которым он всегда следует. а у програмиста - хотелка. Как только програмист возмет на вооружение эти правила - неприятно перестанет

[Лекс Айрин]

zub, не спорю.

[sign]

sign, проблема не в том, что не видно... а в том, что "точки зрения" компилятора и программиста не всегда совпадают. Это не страшно... просто неприятно.

У компилятора нет точки зрения.
Этот конфликт рождается в голове программиста от недопонимания работы компилятора и более ни от чего.

[Лекс Айрин]

sign, потому и в кавычках. Но, кстати, ты не совсем прав. У программы то нет, а у написавшего ее человека вполне присутствует... только это неважно. А последнее предложение ППКС.