Работа со множествами, FPC, Будьте аккуратнее :) Опции

[volvo]

Привет всем.

Сегодня наткнулся на непонятное (с точки зрения Паскаля) поведение FPC. Вот такой простейший код, совершенно корректно отрабатывающий в Турбо Паскале:

type
  tset = set of 'a' .. 'z';
const
  myset: tset = ['a' .. 'z'];
  s: string = 'the test';
  count: integer = 0;
var
  i: integer;

begin
  for i := 1 to length(s) do
  begin
    if s[ i ] in myset then inc(count);
  end;
  writeln(count);
end.

Попробуйте без его компиляции и запуска определить, что будет выведено на печать. А потом запустите на выполнение...

Так что осторожнее с множествами...

[volvo]

Не элемент - выяснение невозможно.

, и надо выбрасывать критическую ошибку, да? В топку такое поведение. У меня не строка может состоять из символов 'a'..'z', а посторонняя переменная. И если символ из строки в ней не присутствует или не может присутствовать - то In должен вернуть False.

Заметь, подобное поведение было как минимум до версии 2.0.0 (на двойке не помню, на 1.0.10 проверил только что - работает), обратная совместимость где?

Да. И еще одно - что мне совершенно непонятно. Откомпилируем программу в Options -> Mode = Release, все прекрасно работает и в 2.4.0. То есть, все-таки баг в отладочных режимах.

[Lapp]

И еще одно - что мне совершенно непонятно. Откомпилируем программу в Options -> Mode = Release, все прекрасно работает и в 2.4.0. То есть, все-таки баг в отладочных режимах.

Гм. А разве в моде Release включен Range Checking?..

Володь, я в целом согласен, что фича ненужная и бесполезная. Я не могу привести примера для себя, где оно бы помогло. Но все же логику тут отрицать пока не могу.
Я еще подумаю над этим..


Добавлено через 4 мин.

, и надо выбрасывать критическую ошибку, да?

Это обычный RangeCheck.. Выключи/включи его для этого куска кода - и проблема решена..

[Lapp]

Я еще подумаю над этим..

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

В твоем примере происходит обработка ВСЕХ входящих символов. Значит, конструкция для обработки должна принимать их ВСЕ. То, что в число "хороших" символов могут входить только буквы, еще не значит, что ты можешь ими ограничиться при обработке. Поэтому введение типа tset в этом коде не есть правильное действие. Если в твоем потоке символов предполагаются буквы и пробелы, а также цифры, но (допустим) никак не управляющие символы, то организуй соответствующее множество, и RCE (в процессе отладки, разумеется) будет означать, что пролез какой-нить ctrl-c, что есть признак ошики в коде и требует реакции программера.

Так что, тут нет никакого бага, мне кажется. IMHO, ессно. Но довольно твердое .