В Perl byte-code давно уже внутрях, есть даже модуль, чтобы с этим как-то работать. Хотя в исполнении ActiveState он как-то не очень работоспособным оказался, хотя я требовал от него .exe ;-) Ruby интересный язык, тока возможности до него добраться у меня нет, а жаль. Жаль, что в сутках тока 24 часа, а на работе я сейчас программирую на английском ;-)

2buddha: "Ты абсолютно зря воюешь - Перл для обработки текстов ГОРАЗДО удобней чем Ц/Ц++, "
Еще раз. Я не спорю, что специализированнре преспособление удобнее, чем обычное. Я возмутился тем фактом, когда пишут, что смогли сделать с ограничением по объему и черт знает какой величины.
2ZhekaSmith: "Программа на perl удаляет любое(?) количество "пробельных символов" перед "разделителями". Это за 5 минут на С не напишешь"
Ну сколько можно повторять что я с этим согласен с самого начала. Я не согласен только с аргументацие типа "программа получается огромная и с ограничением по размеру"...
"были "пробельные символы" и выводить их правильно, если за ними нет "разделителя". Но, realloc, нас спасет, безусловно"
Там вверху есть программа которая это реализовывает вообще без выделения памяти... Учитесь составлять алгоритмы, правильно...
2Casus: "0. О конкретно взятом #define: Вопрос стиля. Нет стиля -- нет вопроса"
Откровенно ради Вас не стал вставлять тот дефайн.
"абсалютно эквивалентно"
Ну и... Я же не стремился сократить программу до нельзя. я это написал с ходу за 15 минут полностью...
"chaNonSpace[i] != cSym_2_ );"
марш смотреть на программу чтоб понять, что Sym2 в той функции *вообще* не нужен. Блин еще советы по сокращению программы даем...
"2. Я таки настаиваю на построчном чтении"
А за чем? Программа и так разбирает тестовый пример правильно... Догадайся почему...
"3. Просили программу с идентичным поведением, я напомню: читает из stdin, если не передали _имён"
Гхм... А это по твоему что FILE *fpIn = (argc > 1) ? fopen( argv[1], "rt" ) : stdin;
"4. Слушай меня, а не slashzone_ru ;-)"
Так вот и я спрашиваю... Что все таки означает <> в том тексте, ты дал два определния поведения этой конструкции... Какое из них правильное.
"5. Дай определение линуксоида. Почему ты считаешь, что я линуксоид?"
Гнутие пальцев, не поделу.
2Lucky: "cSym2 тут не к чему"
Я это знал еще через 30 секунд как запостил программку. Я ж её с ходу писал не проверяя очень уж долго.
"(cSym1 = fgetc( fpIn ))"
Советую:
а) прочитать описание функции fgetc
б) закатать в начало потока символы с кодом 255 и
в) удивится почему программа не работает.
"open source рулез правда?!"
В твоем варианте, ты внес ошибоку которая 'не правильно обрабатывает поток'... Так что уж лучше не надо. Блин если бы я компильнул свою программу то Sym2 я бы удалил, т.к. получил бы предпреждение за не использованную переменную...

2Ogr: ты по-русски не понимаешь?
>> "марш смотреть на программу чтоб понять, что Sym2 в той функции *вообще* не нужен. Блин еще советы по сокращению программы даем..."

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

>> "Гхм... А это по твоему что FILE *fpIn = (argc > 1) ? fopen( argv[1], "rt" ) : stdin; "

Нет, по-русски ты понимать уже разучился. Я употребил множественное число, сколько файлов откроет твой fopen?

>> "Что все таки означает <> в том тексте, ты дал два определния поведения этой конструкции... Какое из них правильное."

Оба, они не противоречивые. Процитирую:
>> Ну а к Вам Casus вопрос, чему верить "оригинальном коде <>
>> означает построчное чтение" или "<> означает stdin тока в том
>> случае, если не были переданы имена файлов как параметры", а?

Я не понял, в чем проблема читать построчно из stdin? Или это невозможно понять?

А нить "Гнутие пальцев не по делу" -> "линуксоид" меня приводит просто в восторг.

Вывод: Огр, ты не умеешь программировать, более того, ты даже мыслить логически не можешь. Может ты женщина?

2Casus: "Я не понял, в чем проблема читать построчно из stdin?"
Потому что для решения этой задачи физически читать построчно не требуется... Но это если подумать, а не гнуть пальцы... '\n' ни чем не отличается поповедению от другого не пробельного символа. Если же какое-то отличие имеется, то рещается это одной проверкий в функции TrimSpace, но это нужно уже уметь думать, чтоб понять.
Чей-то Вы там разнервничались, что по два раза одно и тоже посылаете. Спокойнее, все нормально, тихо повторяйте про себя "я линуксоид, я крут"... и все будет нормально...

""5. Дай определение линуксоида. Почему ты считаешь, что я линуксоид?"
Гнутие пальцев, не поделу. "

А как назвать человека который гнет пальцы только по делу, но пользуется OS Linux ? ;-))

logIN,
назвать Ogr :>

Эмулятор perl6

http://archive.develooper.com/perl6-language@perl.org/msg07602.html

2Ogr: Если подумать, то эта задача не решается автоматом таким как у тебя. Здесь можно применить знание, что пропускаем мы именно пробелы(пробельные символы) перед знаками препинания и надо их не печатать, пока мы не узнаем, что является следующим символом, если знак перепинания, то выкинуть пробелы, если нет, то напечатать сколько пропустили. Но это если подумать. Понимаю, это непривычно, это не "компоненты", нужно приложить усилие, чтобы сдвинуть извилину, а не язык, но что поделать, движениями языком не заменишь движение извилиной.

облом. даже мой алгоритм работает только для пробелов, зря в последний момент дописал "(пробельные символы)". Итого, без lookahead или его замены (запомнить начало куска пробельных символов) не обойтись. А значит нужно читать блоками, не разрывающими слова/строки, а значит построчно, а значит без дополнительной фукции, гарантирующей чтение полной строки, не обойтись.

Вывод: корректно и грамотно написанная программа действительно займёт страницу текста, зато можно будет гордиться, что она работает быстрее, чем однострочник на Perl ;-)

2Casus: В общем так... Идете там где я дал программу, делаете cut-n-paste компилируете. Делаете один файл следующего содержания: " couple spaces between (one space) test : tst \none more line . another test". Компилируете, запускаете и смотрите на результат и уж *потом* выдвигаете притензии на счет look ahead.
PS блин я то думал, что Вы С знаете, ан нет...

Хм... Интересно местный скрипт пробелы удалает... Ну ладно разберетесь я в Вас верю.

2Casus: Посмотрев на то как местный скрипт форматирует пробелы, мне кажется стало понятно чем Вы не довольны. Возможно Ваш пример подразумевал наличие более одного пробела между *словами*? Так?... Нужно ли удалять пробемы между словами или нет? Если пробелы между словами должны оставастся, то без буффера не обойтись, но опять таки читать строку полтостью не надо, достаточно читать до следующего не пробельного символа.

Ogr: О! не прошло и полгода, как фраза "перед знаками препинания" обрела смысл! Уточню, раз непонятно: ТОЛЬКО перед знаками препинания. Между словами не трогать, перед словами не трогать. Тебе задачу всегда так долго повторять надо?

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

Впрочем, стоит признать, что твой код в общей массе GPL-дерьма просто затерялся бы и никто бы не вспомнил, что конкретную какашку написал тот самый Ogr. Так что можешь не комплексовать.

Для тех, кто в танке: GPL код бывает GPL-crap (очень много) и GPL-diamond (много меньше, но много полезней).

2Casus: "не прошло и полгода, как фраза "перед знаками препинания" обрела смысл!"
Оригинальная фраза была "удаляет пробельные символы между словами и знаками препинаний". Было понято как удалени пробелов между словами в том числе...
"Тебе задачу всегда так долго повторять надо?"
Нужно точно формулировать, потму как *перед* и *между* играет весьма большую роль.
"мне понятно почему тебе ненавистна GPL, тебе стыдно свой код народу показывать"
Мне не стыдно свой код показывать. То что он короток и ясно из него самого что он делает, говорит о том что он написан правильно.
Ну а то что ты сам не представляешь как писать программы я уже понял, по твоему предложению читать строку полностью...

2Ogr: чего ты понял мало кого волнует, ты ведь всё равно логически мыслить не умеешь, а значит не интересен.

2Casus: "чего ты понял мало кого волнует, ты ведь всё равно логически мыслить не умеешь, а значит не интересен."
Это Вы о себе? Надо же додуматся читать всю строку а потом её обрабатывать, когда нужно знать все часть строки... А еще о логике рассуждать берется...

А чёто Вы оба козлы, и Casus и Ogr..
нормальные люди бы кинулись парой фраз да и завязали бы с ентой херней,
 ан нет...значится у Вас обоих боооольшие проблемы...комплекс неполноценности
 называется...
Вам врачей нужно искать, психиатров то бишь...а оне всё в форумы постят..
И главное было бы что постить, так нет..на тему достаточно нехитрого регекспа..

Как-то мой пример плохо работал, поправил:

#!/usr/bin/perl # convert.pl print( map{ s/\s+(\.|,|:|;)/$1/g; $_ } <> ); Само конвертирование выглядит так: cat input_big_file| convert.pl > out

Или

convert.pl < input > output

Переводить на слова больше не рискну, но покажу более подробный пример:

[el@slashzone.ru el]$ hexdump -c ./input; ./convert.pl < input |hexdump -c 000 a s d f a , s d f d : \n 010 \t : s d f s d f ; s d f 020 \t s d f s d f . . . . ; ; 030 \t ; ;\n 034 000 a s d f a , s d f d : \n : 010 s d f s d f ; s d f \t s d f 020 s d f . . . . ; ; ; ;\n 02c

Как видно \n не удаляется, так как служит разделителем построчного чтения "<>".

К сожалению, не смог ввести в пример \r

Еще попытка "asdfa , sdfd: \n\t : sdfsdf ;sdf \tsdfsdf .. .. ;;\t;;\n" -> "asdfa, sdfd: \n: sdfsdf;sdf \tsdfsdf....;;;;\n"

2Org:
по поводу EOF замечание принимаю. rtfm - rulez :)

в твоем for(;;); не инициализировалась cSym2 на первом проходе,
это сразу борсилось в глаза, собственно поэтому я и затеял
все это кодокопательство ;)
есть и еще один глюк: алгоритм "забывает"
выдать в fpOut последний символ (тот, что в fpIn был перед EOF)
итак:

int main(int argc, char* argv[])
{
FILE *fpIn = (argc > 1) ? fopen( argv[1], "rt" ) : stdin;
FILE *fpOut = (argc > 2) ? fopen( argv[2], "wt" ) : stdout;
int nIsSpace = 0, nEof;
char cSym1, cSym2;
if( fpIn && fpOut )
for( cSym2 = fgetc( fpIn ); ((cSym1 = nEof = fgetc( fpIn )) | 0x01) && (nEof != EOF); cSym2 = cSym1)
if( TrimSpace( &nIsSpace, cSym1 ) )
fputc( cSym2, fpOut );
fputc( cSym2, fpOut );
return 0;
}

теперь на счет эмуляции перловской строчки:
на сколько я понял из приведенных выше примеров в ней было написано:
"читать данные с stdin.
удалить все "пробельные" сиволы перед перечисленными знаками препинания.
результат выдать на stdout"
твой алгоритм делает немного другое, а именно
"читает данные непосредственно из файла/stdin
удаляет все пробельные символы перед знаками препинания;
удаляет прочие подряд идущие пробельные символы, кроме последнего в данной цепочке.
выводит данные непосредственно в файл/stdout".

откуда берутся данные и куда выводятся - пофиг, а вот "удалалка пробелов"
занимается не тем. чтобы такое поведение твоей проги было нагляднее я и
подправил TrimString().

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

если для этой задачи нужна и скорость исполнения и легкость написания,
то, imho, lex-спецификация будет самое то.

Resume

Сколько предложено вариантов C-кода? Какого они объёма? Сколько из них работают?

А перловый код занимает 2 строчки. Вопрос на засыпку - где больше вероятность появления ошибки - в 20 строках или в двух? И где эту ошибку легче обнаружить?

2Ogr: ""Программа на perl удаляет любое(?) количество "пробельных символов" перед "разделителями". Это за 5 минут на С не напишешь" Ну сколько можно повторять что я с этим согласен с самого начала. Я не согласен только с аргументацие типа "программа получается огромная и с ограничением по размеру"... "были "пробельные символы" и выводить их правильно, если за ними нет "разделителя". Но, realloc, нас спасет, безусловно" Там вверху есть программа которая это реализовывает вообще без выделения памяти... Учитесь составлять алгоритмы, правильно... "

Дело в том, что я как раз больше алгоритмист, нежели программист, и хорошо себе представляю алгоритмические проблемы. Ты поступил как типичный кодер, реализовал простое подмножество спецификаций, и решил что задача очень простая. На самом деле эта задача без выделения памяти не решается. Двух "непробельных" символов вполне достаточно чтобы закодировать что угодно, в том числе "войну и мир", например. И ты должен помнить эту последовательность до момента решения выдавать ее на выводящий поток или нет. Другое дело что выделять память можно по разному, в частности, используя временные файлы и т.д.

Задача, кстати, всегда имеет ограничение на размер. Представь себе машину, где есть клавиатура, и принтер, но нет жестких дисков, и доступной памяти всего 4 кб, программа в ПЗУ. Последовательность длинней 4096*N (где N зависит от представления в памяти, но тоже весьма ограничено) знаков ты запомнить не можешь. В принципе. Вот так, наш дорогой друг Огр.

Итог ясен,

только идиот будет писать на C
программу для обработки текста.

Особенно, когда не нужна скорость.

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

Еще одна реализация для slashzone_ru (*) (2001-08-02 01:02:42.0)

sed -E 's/[[:blank:]]*([,.:;])/\1/g'

причём тут perl?
зачем тут C?

регулярные выражения существовали много раньше perl :)

Ик!.. А если файло читать с конца... ик!.. то вааще ик!.. никакого look..ик!..

2anonymous (2001-08-03 17:01:06.0)
с конца можно, но это плохо кончится, потому что выводить результат
надо все-равно в "прямом" порядке. ;) и вообще stdin с конца
не читается. :)
вот кстати flex вдогонку %):
%option main
%%
[[:blank:]]+[,.:;] putchar( *(yytext+yyleng-1) );
%%

Ну вот, это уже лучше.
А то, тут некоторые, не будем
показывать палцем, от большого ума наверно,
везде суют свой C.

Хотя использовать flex для такой простенькой
задачки тоже не фонтан.
Всё равно количество ударов по клавишам в
несколько раз больше.

2 Lucky
Ик!.. а ик!.. как большие обемы из stdin чтать? ик.. не-е-е-е... не так.. ик!.. зачем? ик!.. и писать можно через такую же дупу ик!.. пардон,.. как и читать.. фсе путем ...ик!..

> когда же они наконец додумаются сделать компиляцию в байт-код? > Цены бы не было. Всяки джавы окончательно бы ушли на помойку.

perlcc не подойдет??

ТУТ мелькнула библиотека с perlregex-ами для C, киньте ссылку ,please.

2 eda: либа называется libpcre. Но мне кажется что надо пытаться приучать себя к функциям из <regex.h> (regcomp и прочие) - они поддерживаются входят в POSIX стандарт.

А где достать учебник по flex?
Уж больно крутая вещь.

Вопрос снимается. Похоже что man flex будет достаточно.

2anonymous (*) (2001-08-03 17:38:23.0) ех как клинит тебя ;) ну было же сказано -- обрабатываемый файл здоровый. в память ну ни как не помещается. может даже на стримере записан, а может и нет. хочешь с конца читать - валяй. ;) но только вот какая незадача получается при таком подходе: последний символ из исходного файла станет первым в выходном потоке ( и наоборот ). и если только ты параллельно не занимаешься сознанием переводчика с еврита/на еврит ;), то это немного не то, что требовалось по условию.

Ruby

Да, я знал что я найду его - скриптовый язык моей мечты ! Ну надоело мне разбираться в корявостях perl'а !!! Написал программу, потом все забыл а вот можифицировать... проще все заново ! Здесь промелькнуло слово Ruby - http://www.ruby-lang.org/ мне понравился синтаксис и возможности ! Рекомендую.

!

2Lucky

Ик!.. ой, блин, как..ик!..ой перводчИК! я и по-русски-то не очень...мысь я твою ик! понял..., а вот ты мою - ик!.. нет. Писать символы в файл надо ик... смещая указатель ик! выходного потока, условно говоря "от конца к началу", я же говорил - через дупу или вопу.. ик!.. как больше нравиться, после каждого записанного символа.. тебе вообще... ик! буффер для текста не понадобится... Если, конечно... ик! .. ты буфферизацию не отключишь... ик!...
Уф...

ну про то, что твой алгоритм и без буферов прекрасно обходится это вроде как с самого начала понятно было ;) вот только твоя ( навязчивая наверно :) ) идея прости.. алгоритма с конца начинающего, и к началу кончающего, имхо тут совсем не уместна. тем более что весь интим вопроса-то находится еще в более пошлой области -- в реализации. хотя может быть ты и знаешь какой-нить способ писать на диски, при этом не сводящийся к write'у, в следствие своей низменности способного только на то, чтобы заменять, да еще добавлять инфу лишь, тфу ты мля, в конец файла... вобщем, в следующий раз, сырц плззз продемонстрируй, ага. ;)

ЗЫ: или ты решил прям в исходном файле данные менять? мдя, ну тогда и флаг те в ... а впрочем куда хошь туды себе и засунь, ибо это уже порнография.

2 Lucky

Ох, блин.. ик!. почему в исходном файле?.. чушь какая-то... ик...
Формулирую задачку .. ик!: удалить пробельные символы, следующие за словами и предшествующие знакам ик... пунктуации. Задача должна быть решена ик... в условиях острой нехватки оперативной ик.. ой... чхи памяти.... Ничего не упустил? Вроде нет. Ага.. ага.. так.. ик... ик...
Ну, если памяти нет, стало быть, расплачиваемся чтением - записью на внешние носители. Ик! Читаем исходный файл с конца, выкидываем пробелы, реализацию приводить не буду(у меня и C компилятора-то под рукой нет).. ик..., главное - буффера никакого не надо, эт ик главное..., пишем в промежуточный ик... файл, имеем файл, записанный, как ..ик сказано в толковом музыкальном словаре в статье о фуге .. ик.., в ракоходном направлении ик!.. (классно они там сказали, до сих пор хих...ик...аю)... что дальше делать - ик... прозрачно... выходной файл я бы записал поверх исходного, но это по ситуации....
Чую, сейчас меня тут обзывать начнут словами, ик... за такой вот алгоритм.. Ик! Решительно хочу я вам ответить! Я же не сказал, что нарисую приличный алгоритм, я сказал ик... , что можно без буфера обойтись и и без lookahead (как там это слово пишется), что я и сделал... Зайт гизунд! Ик...

Усложним задачу :
Пусть мы имеем огромный файл.
И в нем всего лишь одну строчку.
Первый символ - непробельный,
далее большая часть файл состоит из случайной последовательности
пробельных символов.

"случайной последовательности пробельных символов." ...ик!...роскошно

2anonymous (*) (2001-08-07 11:37:42.0) мдя, если бы твоя сообразительность была на уровне упорства... ;) хочешь временный файл создавать -- валяй. хотя по условию было, что файл-то исходный агроменный. ну да ладно, можешь винтов по свой алгоритм накупить -- все к лучшему. кстати сколько в итоге на винте займет твой временный файл? думается ровно

Sc=S0-Ssp, где S0 - объем исходного файла, Ssp - суммарный объем удаленных пробельных символов, Sc - объем требуемого дискового пространства для хранения твоего временного файла.

другое дело, если использовать "lookahed" (в твоей терминологии) алгоритм, (кстати, если уж оперативки действительно в обрез, то никто не запрещает кеш пробельных символов размещать не в в RAM, а на винте и думается никакого дополнительного объема памяти, по сравнению с твоим алгоритмом не понадобится), то требуемый объем для кеша будет Sc=max( Sspi ), где Sspi - объем i-той цепочки последовательных пробельных символов.

таким образом "lookahed" алгоритм, при наиболее вероятном стечении обстоятельств, когда наибольшая удаляемая цепочка последовательных пробельных символов меньше суммарного объема оставленных данных, оказывается менее прожорливым к требуемому объему памяти. и это при том, что область применения твоего алгоритма сводится файлам с произвольным доступом, а "lookahed"-варианты способны обрабатывать любые файлы, плюс потоки, сокеты и прочие фифы. в свою очередь для файлов с произвольным доступом очень даже просто написать сикающую прогу, вообще не требующюю каких либо буферов для пробелов. думается этого будет достаточно, для признания полной несостоятельности твоей ничтожной бредовой идейки. :)

А какие есть непробельные символы и можно ли tab заменять пробелами? john

Извиняюсь пробельные символы

2 Lucky

Гы-ы-ы... чего-то примерно такого я и ждал ик!.. Любишь быть правым? Ик! Люби и будь... ик!.. вел.. ик!.. алепный анализ провел, блистательный, и даже подкрепил ноукообразнами выкладками... еще осталось для окончательного закрепления победы в этом непростом, принципиальном и черезвычайно важном диспуте свидетелей призвать:
Вы видели! Видели! Прав я, прав!
Ик... ох, я только не понял, могу я без буффера обойтись или нет? И файло правильное получиться? Могу?.. ик... Ну слава богу, я только это и хотел узнать... ик... А то я и сам сомневаться начал. То, что метод дурацкий я сам знаю, божьим попущением в анацефалы еще не перебрался. Я же предупреждал - через жопу. А ты продолжаешь настаивать: "Нет не через жопу, а через жопу, я говорю!" Ладно будь по-твоему... я - что... ик!

И.К!:
А где ты видел текстовый файл ОГРОМЕННЫЙ? ОГРОМЕННЫЙ - это сколько?
Толстый роман меньше чем в мег влезает. Мег вроде ОГРОМЕННЫМ не считается...

И.И.К!:
Но ты - да, ик.. ик..рудицию показал, спору нет... Дал жару, дал... Так держать! В следующий раз, когда пойдет флейм на тему типа:"как из строки запятые повыковыривать", ты тоже жахни, что б ламерам поганым поплохело...

Компилятор Perl'а

Вот мне интересно, компилятор для перловки нормальный делать не хотят принципиально? Было бы очень мило.

2anonymous (*) (2001-08-07 19:15:24.0) >>Я же предупреждал - через жопу. А ты продолжаешь настаивать: "Нет не через жопу, а через жопу, я говорю!"<< хех, сколько эмоций.. ;) подумаешь -- рекурсия. :) а быть правым рулез, ага?. Ж) ЗЫ: мдя, ты логи когда-нить видел? ЗЗЫ: и вообще не нервничай, в анацефалы еще никто не переберался -- анацефалы -- это с рождения. :)

2 Lucky

Икать больше не буду - достало.

Логи видел. А зачем у логов такие вещи править? Это ж логи. Надуманно как-то.

"а быть правым рулез, ага?. " - не знаю, не испытываю особенного кайфа. Но неправым быть не люблю.

to Lucky

задача может быть решена без использования буферизации. Проход по файлу в прямом направлении можно осуществить функцией fgetc, если
будет прочитан пробельный символ, позиция его запоминается, далее,
можно вернуться к нему используя lseek(fseek), когда по следующей
последовательности байт будет ясно надо ли ее записать в выходной
файл.

AIF