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

[Джейн Смит]

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

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

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.

[Unconnected]

Разбиение на слова. Все способы.

[Джейн Смит]

Спасибо, но я не совсем поняла к чему эта ссылка. Программы описанные там довольно сложные, вроде. Я вообще мало что поняла в них. Мне почему-то кажется, что в заданной мне задаче всё должно быть как-то полегче что ли.

[Unconnected]

Ну, тебе нужно посчитать количество слов, а для этого нужно разбить строку на слова. По ссылке есть и несложные способы, учитывающие и знаки препинания, и пробелы во всех местах.. Например, вот один из той темы:

const

   limits = [#0..#32,'.',',',':',';','!','?','"'];
type

   TWords = array[1..40] of string;

var
   text : string;
   words : TWords;

function GetWords(s : string; var w : TWords) : byte;
var
   i,back,n : byte;
begin
   i := 1;
   n := 0;
   while(i<=length(s)) do begin
      while(i<=length(s)) and (s[i] in limits) do
       inc(i);
      if i<=length(s) then begin
         back := i;
         while(i<=length(s)) and not(s[i] in limits) do
          inc(i);
         inc(n);
         w[n] := copy(s, back, i-back);
      end;
   end;

   GetWords := n;
end;

Эта функция уже будет возвращать количество слов. Можешь убрать занесение слов в массив (words).

Сообщение отредактировано: Unconnected - 4.04.2010 13:12

[Джейн Смит]

Большое спасибо)

[Гость]

Самое простое, наверное - выкинуть все начальные пробелы, если уж они мешают:

while Pos(' ',word)=1 do Delete(word,1,1);

Но лучше, конечно, переделать прогу. Метки - это зло.. ))

[Lapp]

Вот, как-то так можно сделать:

const
  A=['A'..'Z']+['a'..'z'];

Var
  i,n: integer;
  s: string;

BEGIN
  writeln('Vvedite stroky:');
  readln(s);
  n:=0;
  for i:=1 to Length(s) do if (s[i] in A)and((i=1)or not(s[i-1] in A)) then Inc(n);
  writeln('V predlogenii ',n,'slov/o/a)');
  ReadLn;
END.

Unconnected, искренне тебе советую работать не с разделителями, а с алфавитом ))

[Archon]

for i:=1 to Length(s) do if (s[i] in A)and((i=1)or not(s[i-1] in A)) then Inc(n);

Мне кажется, что не стоит полагаться на оптимизатор и писать такие условия. Volvo бы спросить, он точно знает =)

[Lapp]

Мне кажется, что не стоит полагаться на оптимизатор и писать такие условия. Volvo бы спросить, он точно знает =)

Я тоже точно знаю совершенно неожиданно и случайно )).
Эта фича не имеет никакого отношения к оптимизации. Называется она Short Boolean Evaluation и включена по умолчанию. Если ты хочешь Complete Boolean Evaluation - используй соответствующую опцию в меню либо (надежнее) - директиву {$B+}.

Если не использовать в выражении Булевы функции, изменяющие какие-то другие переменные, то все не только нормально, но и просто прекрасно (поскольку не только укорачивает, но и позволяет не отрабатывать то, что отрабатывать не нужно и нельзя). Описанная ситуация (функции, меняющие глобальные переменные) встречается крайне редко, а необходимость ее - и того реже. Я бы рекомендовал новичкам как раз НЕ использовать подобный изврат, по крайней мере до того, как станешь гуру. Кстати, аналогичный прием в арифметических выражениях (с использованием арифметических функций, меняющих другие параметры) действительно встречается, особенно в рекурсии. Но все же этим не стоит злоупотреблять, и использовать нужно крайне осторожно. Иначе мы дойдем до того, что порядок тоже важен, и A*B не равно B*A, и - пошло-поехало..

Лично я короткими вычислениями пользовался всегда - вставляя, если прога идет на стророну - директиву $B.

К слову сказать, в С это организовано несколько иначе: там есть две разных формы Булевых операторов: одинарные (полное вычисление) и двойные (краткое вычисление). Это, конечно, значительно удобнее, так как не только избавляет от необходимости ставить директиву - можно еще и без проблем смешивать эти операторы в одном выражении. Но только скажите мне: кто вообще использует одинарные | и & - по делу, а не по недоразумению?

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

[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 )).

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