Работа со множествами, 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]

Я не отмалчиваюсь, я просто сейчас сидел и разбирался с ассемблерными листингами разных тестов работы со множествами. Смотри, что получается...

Берем кусок кода №1:

// переменные описаны так:
type
  byteset = set of 128 .. 255;
const
  bset: byteset = [128 .. 255];
  arr: array[1 .. 5] of byte = (1, 128, 129, 130, 131);

//
  for i := 1 to 5 do
    if arr[ i ] in bset then inc(count);
  writeln(count);

Что имеем на выходе? Вот что:

# [18] if arr[ i ] in bset then inc(count);
	movl	U_P$PROGRAM_I,%eax
	subl	$1,%eax
	cmpl	$4,%eax
	jbe	.Lj8
	call	FPC_RANGEERROR
.Lj8:
	movl	U_P$PROGRAM_I,%edx
	movl	%edx,%eax
	subl	$1,%eax
	cmpl	$4,%eax
	jbe	.Lj9
	call	FPC_RANGEERROR
.Lj9:
	movzbl	TC_P$PROGRAM_ARR-1(,%edx,1),%eax
	btl	%eax,TC_P$PROGRAM_BSET
	jc	.Lj6
	jmp	.Lj7
.Lj6:
	movl	TC_P$PROGRAM_COUNT,%eax
	addl	$1,%eax
	jno	.Lj12
	call	FPC_OVERFLOW
.Lj12:
	movl	%eax,TC_P$PROGRAM_COUNT
.Lj7:
	cmpl	$5,U_P$PROGRAM_I
	jl	.Lj5
	.stabn 68,0,19,.Ll4 - _main
.Ll4:
# [19] writeln(count);

. Обратил внимание? Сразу запихиваем содержимое очередного элемента массива в EAX, и смотрим, есть ли оно в множестве. А теперь вышеприведенный мной код:

type
  tset = set of 'a' .. 'z';
const
  myset: tset = ['a' .. 'z'];
  s: string = 'the test';

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

На выходе:

# [24] if s[ i ] in myset then inc(count);
	movl	U_P$PROGRAM_I,%edx
	cmpl	$255,%edx
	jbe	.Lj30
	call	FPC_RANGEERROR
.Lj30:
	movzbl	U_P$PROGRAM_I,%ecx
	movzbl	TC_P$PROGRAM_S(,%ecx,1),%edx
	subl	$97,%edx
	cmpl	$25,%edx
	jbe	.Lj31
	call	FPC_RANGEERROR
.Lj31:
	movzbl	TC_P$PROGRAM_S(,%ecx,1),%edx
	btl	%edx,TC_P$PROGRAM_MYSET
	jc	.Lj28
	jmp	.Lj29
.Lj28:
	movl	TC_P$PROGRAM_COUNT,%edx
	addl	$1,%edx
	jno	.Lj34
	call	FPC_OVERFLOW
.Lj34:
	movl	%edx,TC_P$PROGRAM_COUNT
.Lj29:
	cmpl	U_P$PROGRAM_I,%eax
	jg	.Lj27
.Lj26:
	.stabn 68,0,26,.Ll8 - _main
.Ll8:
# [26] writeln(count);

То есть, сначала из выдирается очередной символ, от него отнимается 97 (ну, это понятно - приводим к началу отсчета, 'a' считается нулевым элементом множества - значит ото всего будем отнимать 97, начинался бы интервал при описании tset с 'b' - отнимали бы 98), потом проверяем результат на попадание в допустимый интервал (26 символов, начиная с 0 - если значение больше 25, то RCE). А потом опять выдираем значение из строки и его уже проверяем на наличие во множестве...

Если так все-таки было задумано, то чего бы не сделать то же самое действие для целочисленных базовых типов - непонятно. Для перечислимых тоже есть такая проверка:

type
  t = (_1, _2, _3, _4);
  st = set of _2 .. _4;

const
  ssv: st = [_2 .. _4];
  one: t = _1;
begin
  if one in ssv then 
    writeln('wrong');
end.

точно так же, как и при работе с Char-ами вылетает при отладке.

Неоднозначность какая-то получается. Учитывая то, что есть Generic-и - это ОЧЕНЬ нехорошая неоднозначность.

[Lapp]

Если так все-таки было задумано, то чего бы не сделать то же самое действие для целочисленных базовых типов - непонятно. Для перечислимых тоже есть такая проверка:
<...>
Неоднозначность какая-то получается. Учитывая то, что есть Generic-и - это ОЧЕНЬ нехорошая неоднозначность.

Да, с этим я не могу не согласиться. Явная неоднозначность. И неоднозначность плохая, да. В такой ситуации ответ может дать только тот, кто делал.. Володь, ты еще не запостил этот вопрос на форум FP?