Строки, Для строки, которая может начинаться с пробела найти кол-во слов Опции

[Джейн Смит]

Для строки, которая может начинаться с пробела найти кол-во слов.

Я сделала, но если вначале строки или в конце я ставлю пробел, то выдаёт неправильное значение. Может объясните в чём ошибка?

Program Stroki (input, output);
Uses crt;
Var
  N,b,ch:integer;
  word:string;
Label l;
BEGIN
Clrscr;
writeln('Vvedite stroky:');
readln(word);
n:=length (word);
ch:=1;
b:=pos(' ',word);
l: If b>0
  then
    begin
    ch:=ch+1;
    delete(word,1,b);
    n:=length (word);
If n>0
then
  begin
  b:=pos(' ',word);
  goto l;
  end;
  end;
writeln('V predlogenii ',ch,'slov(o)');
readkey;
END.

[Archon]

Действительно, я и забыл об этой директиве. Но формально, это все же оптимизация, ведь условие - это не более, чем арифметическое выражение, и как оно вычисляется - дело компилятора. Во всяком случае в курсе теории языков программирования подобная задача входила в тему "оптимизация". Имхо, любое выражение должно быть вычислимо полностью, а то так дойдет до того, что выражение "a := 10 * b + 0 * c / 0;" корректно, потому что второй многочлен уже после умножения "очевидно" равен нулю .

Но если окажется, что директива $B является частью языка паскаль и обязана присутствовать в любом его компиляторе, тогда я соглашусь, что использование подобных логических выражений в целом корректно (хотя {$B-} лучше все таки явно указать).

В Паскале тоже были попытки ввести нечто подобное, и это как раз есть ложка дегтя в бочке меда.. Мало того, что они оставили нормальную форму (or и and) именно для полного вычисления, они еще и изобрели совершенно неудобоваримые и длинные обозначения and_then и or_else для гораздо более широко используемой краткой формы!!

Очень интересно Нашел эти стандарты, на досуге почитаю. Мне казалось что-то подобное было а Аде, но чтоб в паскале...

Добавлено через 12 мин.
Вот тут об этом вопросе пишут: Wikipedia: Comparison of Pascal and C -> Expressions -> Logical connectives

[Lapp]

формально, это все же оптимизация, ведь условие - это не более, чем арифметическое выражение, и как оно вычисляется - дело компилятора. Во всяком случае в курсе теории языков программирования подобная задача входила в тему "оптимизация". Имхо, любое выражение должно быть вычислимо полностью, а то так дойдет до того, что выражение "a := 10 * b + 0 * c / 0;" корректно, потому что второй многочлен уже после умножения "очевидно" равен нулю .

Да хоть горшком назови )). Archon, ты не врубаешься: это как раз удобно ИМЕННО для таких вот случаев, когда остаток выражения НЕ ИМЕЕТ СМЫСЛА (как, например, выход за границы диапазона). То есть, мне кажется, возможна и такая ситуация - с делением на ноль, которого нужно избежать. Конечно, программист должен все случаи правильно интерпретировать - но это же всегда так )). Согласен, что в некоторых случаях выражение усложнится настолько, что его трудно будет осмыслить, но в простых случаях (типа ограничений по индексам) это очень удобно и прозрачно.

Но если окажется, что директива $B является частью языка паскаль и обязана присутствовать в любом его компиляторе, тогда я соглашусь, что использование подобных логических выражений в целом корректно (хотя {$B-} лучше все таки явно указать).
...
Вот тут об этом вопросе пишут:

Это все теория, которая суха, как известно. В своей практике я использую это направо и налево и получаю компактный и легко читаемый код. Ведь не факт, что явное указание ограничений через if влечет за собой простоту и ясность - размер кода тоже много значит. Так что - теоретики пусть пишут "The Pascal compiler has the freedom to use whatever ordering it may prefer and must always evaluate the whole expression even if the result can be determined by partial evaluation," - (кстати, забавная выбрана форма, некая "декларация свобод" , как будто речь идет об их ущемлении) я буду пользовать short evaluation - причем, как явно (указывая {$B+}), так и неявно. Извиняюсь за этот выпад, но - вольнО им разглагольствовать на тему, как оно должно быть (прозакладываю последние джинсы за то, что они сами на нем не программируют). В Паскале до, извините, фига недостатков - и это один из них. И если есть нормальный рабочий work around - я буду его использовать. А говорить про "любой его компилятор" - просто смешно в ситуации, когда их осталось всего раз-два - и обчелся, и новых уже не будет; надо говорить про те, что есть и используются.

Я был бы очень рад, если бы в FPC 2.5 ввели нечто типа сишного a=b=c (включаемого специальной директивой). Ошибка для Паскаля? ну да и Бог с ней, родимой )). Не стандарт? ну и pls )). Я осведомлен про бОльшую вероятность совершения ошибок в этом случае, просьба мне не напоминать..

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

Выделенное серым добавлено позже.