Re: чтение из файла на С
а зачем тебе C? что за проект?
если просто поиграться, лучше python юзай.
если хочешь изучить именно C, почему до сих пор не прочитал классиков?
если просто поиграться, лучше python юзай.
если хочешь изучить именно C, почему до сих пор не прочитал классиков?
я прочитал классическую книжку про Си, но там не написано детально про чтение из файла. Это не проект, просто играюсь с Си)
прочитай: "Kernighan B. W., Ritchie D. M. The C Programming Language. Ed. 2": Chapter 7: Input and Output
и Chapter 8, конечно же, не помешает, если уж на C собрался писать.
вообще, странно. какую же классику ты читал, если не кернигана/ритчи?
зы. а еще лучше сразу читай исходники. например, nginx. там многие примитивные функции
(библиотека для строк, пул памяти, сборщик мусора, работа с файлами) реализованы, проникнешься философией типа.
вообще, странно. какую же классику ты читал, если не кернигана/ритчи?
зы. а еще лучше сразу читай исходники. например, nginx. там многие примитивные функции
(библиотека для строк, пул памяти, сборщик мусора, работа с файлами) реализованы, проникнешься философией типа.
целые строчки поштучнос этим в голых сях плохо, надо писать самому такую функцию
риальные поцаны щас хаскель чисто ботают, си для лохов, ёпта
целые строчки поштучно доставать?Я лично для этого юзаю функцию fgets
давно на сях не писал, но то что fgets бесполезная функция это хорошо помню
что интересно, про нее написано следующее
а я ею не пользовался, м.б. попробовал разок и не понравилось
fgets gets a string from a stream
Declaration:
char *fgets(char *s, int n, FILE *stream);
Remarks:
fgets reads characters from stream into the string s. It stops when it reads
either n - 1 characters or a newline character, whichever comes first.
fgets retains the newline character at the end of s and appends a null byte
to s to mark the end of the string.
а я ею не пользовался, м.б. попробовал разок и не понравилось
риальные поцаны щас хаскель чисто ботают, си для лохов, ёптариальные поцаны знают что "There is more than one way to do it" (C)
(C)это = (Си) ?
нет, это перл
зы. а еще лучше сразу читай исходники. например, nginx.Трудно понять, Бачан шутит или УЖЕ нет...
ога, походу бачан сам накурился этих сырцов =)
ога, походу бачан сам накурился этих сырцов =)это боян! Ща Бачан уже сам так пишет.
так? if (p[0] == 'P' && p[1] == 'O' && p[2] == 'S' && p[3] == 'T') {... =}
риальные поцаны знают что "There is more than one way to do it" (C)Риальные поцаны любят побыстрее.
Уж чего-чего а работы со строками на С лучше избегать как огня.
Уж чего-чего а работы со строками на С лучше избегать как огня.Почему? Как раз очень эффективно получается писать.
Почему? Как раз очень эффективно получается писать.Эффективно в наше время означает, что любая операция со строками пишется за 5 секунд, включая любые поиски, слияния, разбиения, регэкспы и т.п. и сразу работает. Надрачивание с-шных функций с постоянным риском схлопотать переполнение буфера или еще какую-нибудь фигню, никак нельзя назвать эффективным.
тебя кто-то заставляет всё писать на уровне "*p++" ?
но то что fgets бесполезная функция это хорошо помнюне согласен. Это как раз, если не изменяет память, единственное правильое решение для чтения в текстовом виде, так как функции семейства scanf небезопасны: нет явного ограничения на размер вводимого буфера, как в fgets.
Эффективно в наше время означает, что любая операция со строками пишется за 5 секундА это смотря _что_ эффективно. Писать регекспы на перле или питоне, конечно, быстрее, но по производительности сишные функции вне конкуренции.
By the way: даже перловое pcre сильно просасывает в случае, когда нам нужно только срабатывание регулярки (матчинг) и не требуется кэпчуринг. Это потому, что там автоматы недетерминированные используются. Кстати, никому не звестны какие-нибудь (бесплатные) библиотеки "быстрых" регулярок (без capture)? Сырцы grep-а не предлагать.
flex? =)
но по производительности сишные функции вне конкуренцииочень сомнительно. Чтобы достичь производительности immutable строк из Java или C# в C нужно серъёзно поебаться. Про std::string из C++ вообще говорить не буду
риальные поцаны знают что "There is more than one way to do it" (C)ну ты задвинул, пёрл с хаскелом сравнил. Хотя, сравнение, может быть, и уместно
Они оба пиздец как непонятны.но по производительности сишные функции вне конкуренции.Присоединюсь к Высеру.
Если тебе нужно что-нибудь совсем-совсем простое, тогда да, С окажется быстрее.
Как только у тебя появляется первый маллок, твоя прога начинает стремительно просасывать любому языку с GC.
Как только у тебя появляется несколько сравнений одной и той же строки с другими, твоя прога начинает стремительно просасывать любому языку, в котором immutable строки интернятся в специальный хэштейбл.
По поводу перла — не пробовал нонкэпчуринг группы юзать ( "(?:)" )
Как только у тебя появляется первый маллок, твоя прога начинает стремительно просасывать любому языку с GC."как только" — это громко сказано. чтобы чудо произошло, надо немало фейлов проектирования, си тут ни при чем.
Как только у тебя появляется несколько сравнений одной и той же строки с другими, твоя прога начинает стремительно просасывать любому языку, в котором immutable строки интернятся в специальный хэштейбл.
примеры есть какие-нибудь для кругозора?
А это смотря _что_ эффективно. Писать регекспы на перле или питоне, конечно, быстрее, но по производительности сишные функции вне конкуренции.Б**, 2008 год на дворе, а базары те же, что я еще 10-ть лет назад слушал. Кому нужна эта сишная эффективность, если требуется писать тонны малопонятного, error-prone кода? Единственное место, где уместны сишные функции для работы со строками - это ядро интерпретатора нормального языка, ну может еще в утилите хелп на экран вывести. Нормальные операции работы со строками - это существенное повышение уровня абстракции, которое экономит кучу времени. В 99% случаев падение производительности будет меганезначительно на общем фоне.
субд/фс не в счёт, ога, их все уже давно пишут на C# 
если в программе много опрераций со строками то эффективный пул строк с хэшами, слайсами и прочими хуйнями реализуется (да и полно реализаций, если поискать) на любом языке.
другой впрос что оверхед вносимый высокоуровневым языком не уберёшь хоть тресни.
так что эффективная реализация строковых операция это не главное преимущество манаджед языков — это просто попытка компенсировать скорость в другом месте, а не где они теряют.
если в программе много опрераций со строками то эффективный пул строк с хэшами, слайсами и прочими хуйнями реализуется (да и полно реализаций, если поискать) на любом языке.
другой впрос что оверхед вносимый высокоуровневым языком не уберёшь хоть тресни.
так что эффективная реализация строковых операция это не главное преимущество манаджед языков — это просто попытка компенсировать скорость в другом месте, а не где они теряют.
Что именно ты называешь "фейлами проектирования"?
Использование сырого маллока для выделения памяти под список кэпчуров в регексе вместо подтягивания собственного специально заточенного под это менеджера памяти — это фейл проектирования? Если да, то как бы я не вижу особого смысла в этом понятии, слишком высока у него энтропия, если ты понимаешь, о чём я.
Если нет, то твой регекс будет тормозить сильнее шарпового, например. Потому что сырой маллок/фри очень, очень тормозной.
Конкретные примеры? Ну я не знаю, напиши программку, которая маллочит куски памяти случайного размера от одного байта до килобайта и в довольно случайном порядке их освобождает, сравни производительность. Могу я написать.
over: слишком толсто.
: во-первых, что за оверхед от высокоуровнего языка, опиши конкретно? Я понимаю в питоне каком-нибудь, всё ясно, вызов функции тормозной. А в шарпе?
Во-вторых, ты тоже рассматриваешь сферическую прогу на С в вакууме, в которой подтянута реализация всего .НЕТ фреймворка, а заодно и питона с перлом, и которую пишут умные программисты, в 99% случаев использующие именно её, и только иногда добавляющие что-нибудь от себя? Ну-ну.
Использование сырого маллока для выделения памяти под список кэпчуров в регексе вместо подтягивания собственного специально заточенного под это менеджера памяти — это фейл проектирования? Если да, то как бы я не вижу особого смысла в этом понятии, слишком высока у него энтропия, если ты понимаешь, о чём я.
Если нет, то твой регекс будет тормозить сильнее шарпового, например. Потому что сырой маллок/фри очень, очень тормозной.
Конкретные примеры? Ну я не знаю, напиши программку, которая маллочит куски памяти случайного размера от одного байта до килобайта и в довольно случайном порядке их освобождает, сравни производительность. Могу я написать.
over: слишком толсто.
: во-первых, что за оверхед от высокоуровнего языка, опиши конкретно? Я понимаю в питоне каком-нибудь, всё ясно, вызов функции тормозной. А в шарпе?
Во-вторых, ты тоже рассматриваешь сферическую прогу на С в вакууме, в которой подтянута реализация всего .НЕТ фреймворка, а заодно и питона с перлом, и которую пишут умные программисты, в 99% случаев использующие именно её, и только иногда добавляющие что-нибудь от себя? Ну-ну.
Единственное место, где уместны сишные функции для работы со строками - это ядро интерпретатора нормального языка, ну может еще в утилите хелп на экран вывести.Ню-ню. А если нужно обработать пару терабайт текста, например, поисковый индекс или просто все урлы рунета? Тут, пожалуй, остаются только плюсы. Но и чистый Си покажет себя лучше Шарпа или Джавы.
это с точки зрения юнихового программиста .NET это тот самый сферический конь, который где-то есть и по слухам работает быстро, память не жрёт большой ложкой как ява, но под unix он работать никогда не будет.
поиск яндекса? лучше бы ваш поисковик искал хорошо , а не быстро
Но, если быть честным, в последнее время поиск по рунету у яндекса и рамблера работает адекватнее гуглёвого. Причём намного.
Использование сырого маллока для выделения памяти под список кэпчуров в регексе вместо подтягивания собственного специально заточенного под это менеджера памяти — это фейл проектирования?да, конечно. это фейл проектирования библиотеки регексов.
что мешает написать нормальный аллокатор, задача то довольно узко специализирована.
я в сишных приложениях регкесами не пользуюсь вообще, поэтому ничего конкретного не скажу.
а все свои маллоки в тупой пул, как минимум, заворачиваю. это пишется за 10-15 минут с отладкой.
Конкретные примеры? Ну я не знаю, напиши программку, которая маллочит куски памяти случайного размера от одного байта до килобайта и в довольно случайном порядке их освобождает, сравни производительность. Могу я написать.я хотел примеры из реальной жизни, конечно же. пример двух приложений на C и С# каком-нибудь
с аналогичной функциональностью, чтобы сишный аналог проигрывал в производительности.
там и фейлы сразу видны будут, как в примере с регексами.
http://www.mono-project.com/Main_Page, лол.
Правда, я недавно проверял, сам компилятор у них такой же эффективный, как в 2008 студии (и довольно сильно быстрее 2005го а вот CLR тормозит. Тормозит CLR что-то! Довольно сильно тормозит! Раза в два почти на исследовавшейся мной проге!
И эта, что за троллиеобразный перевод темы?
Правда, я недавно проверял, сам компилятор у них такой же эффективный, как в 2008 студии (и довольно сильно быстрее 2005го а вот CLR тормозит. Тормозит CLR что-то! Довольно сильно тормозит! Раза в два почти на исследовавшейся мной проге!
И эта, что за троллиеобразный перевод темы?
пример двух приложений на C и С# каком-нибудь с аналогичной функциональностьюэээ...
что "эээ..."?
то есть, я понял, что ты имел в виду, но это хуевый ответ.
действительно — ЛОЛ.
это поделие нужно пионерам красноглазым и эгтерпрайз граблестроителям.
чем .net так принципиально отличается от java что он сделает то что не смогла сделать sun?
там наверно просто супер гениальная оптимизация какая-то внутри?
это поделие нужно пионерам красноглазым и эгтерпрайз граблестроителям.
чем .net так принципиально отличается от java что он сделает то что не смогла сделать sun?
там наверно просто супер гениальная оптимизация какая-то внутри?
я думаю текстовых редакторов (тм) наберётся достаточно на любом языке
я вообще не понимаю, о чем спор и ввязался только из-за того, что согласился с флудовым высером высера. =)
по-моему, идея о том, что на C крутую оптимизацию из шарпа для конкретной задачи всегда можно накодить,
выкинув остальной оверхед (или даже ту же оптимизацию в местах, где оптимизировать не нужно) — очевидна.
конечно, речь идет о том, где затраты на "накодить" оправданы. накодить нормальный аллокатор можно почти всегда и недорого.
с иммутабл строками может быть чуть сложнее, но тоже реализуемо.
по-моему, идея о том, что на C крутую оптимизацию из шарпа для конкретной задачи всегда можно накодить,
выкинув остальной оверхед (или даже ту же оптимизацию в местах, где оптимизировать не нужно) — очевидна.
конечно, речь идет о том, где затраты на "накодить" оправданы. накодить нормальный аллокатор можно почти всегда и недорого.
с иммутабл строками может быть чуть сложнее, но тоже реализуемо.
а вот не надо. я отвечал на флудовый высер стрикера про невъебенную скорость строк на це.
ну там совсем неприлично было, я бы промолчал. хуже только Over выступил.
по-моему, идея о том, что на C крутую оптимизацию из шарпа для конкретной задачи всегда можно накодить, выкинув остальной оверхед (или даже ту же оптимизацию в местах, где оптимизировать не нужно) — очевидна.
---
Ну да, очевидна. Я и говорю, получится сферическая прога в вакууме, которая на 98% написана фактически на шарпе, но с неудобным синтаксисом и постоянными опасными кастами.
по-моему, идея о том, что подавляющее количество активно работающих со строками прог на С, написанных подавляющим большинством программистов (наивно считающим что расширение ".с" само по себе обеспечивает высокую производительность будет тормознее программы на С# написанной левой ногой за пять минут — очевидна.
Кстати. Я уже спрашивал и повторю вопрос: что за оверхед вы таки имеете в виду? Это очень важный вопрос, на самом деле. Я развлекался оптимизацией прог на шарпе, это довольно забавно на самом деле. Там, видите ли, есть поинтера и структуры (в отличие от жавы, так-то, Blind! И, кстати, Blind, ты неправ насчёт моны, она мало того, что довольно надёжна, так ещё и делается в принципе в сотрудничестве с микрософтом, особенно мунлайт).
Оверхед как таковой состоит из различных частей, вроде оверхеда на диспатч виртуальных методов, оверхеда на создание объектов в куче, оверхеда на доступ к объектам в куче, как непосредственного (если у нас есть массив объектов, то для доступа к полю одного из них нужно две операции с пойнтерами произвести вместо одной так и от кэш-промахов, оверхеда на проверку границ массивов, и, наконец, несколько хуже оптимизирующего компилятора (что до известных пределов исправляется ngen'ом (native image generator.
В процессе внимательного изучения обнаруживается, что все пункты кроме последнего в общем-то manageable. Наследование выкидывается нафиг, объекты превращаются в структуры и аллокаются из массивов с ручным ресайзом, и так далее. Этим путём можно идти довольно успешно и зайти довольно далеко, прежде чем геморройность очередных улучшений достигает уровня геморройности написания совершенно неоптимизённой проги на няшной сишке. И только совсем уж в конце наступает момент, когда видно, что дальше на С было бы оптимизить легче. Вот так вот.
---
Ну да, очевидна. Я и говорю, получится сферическая прога в вакууме, которая на 98% написана фактически на шарпе, но с неудобным синтаксисом и постоянными опасными кастами.
по-моему, идея о том, что подавляющее количество активно работающих со строками прог на С, написанных подавляющим большинством программистов (наивно считающим что расширение ".с" само по себе обеспечивает высокую производительность будет тормознее программы на С# написанной левой ногой за пять минут — очевидна.
Кстати. Я уже спрашивал и повторю вопрос: что за оверхед вы таки имеете в виду? Это очень важный вопрос, на самом деле. Я развлекался оптимизацией прог на шарпе, это довольно забавно на самом деле. Там, видите ли, есть поинтера и структуры (в отличие от жавы, так-то, Blind! И, кстати, Blind, ты неправ насчёт моны, она мало того, что довольно надёжна, так ещё и делается в принципе в сотрудничестве с микрософтом, особенно мунлайт).
Оверхед как таковой состоит из различных частей, вроде оверхеда на диспатч виртуальных методов, оверхеда на создание объектов в куче, оверхеда на доступ к объектам в куче, как непосредственного (если у нас есть массив объектов, то для доступа к полю одного из них нужно две операции с пойнтерами произвести вместо одной так и от кэш-промахов, оверхеда на проверку границ массивов, и, наконец, несколько хуже оптимизирующего компилятора (что до известных пределов исправляется ngen'ом (native image generator.
В процессе внимательного изучения обнаруживается, что все пункты кроме последнего в общем-то manageable. Наследование выкидывается нафиг, объекты превращаются в структуры и аллокаются из массивов с ручным ресайзом, и так далее. Этим путём можно идти довольно успешно и зайти довольно далеко, прежде чем геморройность очередных улучшений достигает уровня геморройности написания совершенно неоптимизённой проги на няшной сишке. И только совсем уж в конце наступает момент, когда видно, что дальше на С было бы оптимизить легче. Вот так вот.
Да, а по поводу приложений, чем искать текстовые редакторы и пытаться придумать вменяемый бенчмарк, давай-ка вот что:
http://community.livejournal.com/coding4fun_ru/1510.html
Простая такая задачка, даже довольно реалистичная. Ближе к концу я уже перестал понимать, как там чуваки время меряют, но вообще у меня сложилось ощущение, что те проги на С и С++, которые там были, в сумме на этих 12 примерах жрали порядка 300 миллисекунд и больше, на загадочно широко распространённом среди участнегов атлон64 3000+. Да, участники вроде совсем не индусы. Я туда запостил прогу на шарпе, отбивавшуюся за 285 миллисекунд, потом, уже после формального завершения, я её ещё поковырял, сейчас у меня есть работающая версия, дающая 150мс, и я бы её ещё пооптимизил, если бы был повод, благо мыслей много, но кодить их влом. Подчеркну, это всё практически только за счёт именно оптимизаций, а не каких-либо хитроумных алгоритмических трюков.
Ну вот как бы вот. Просто пример такой. Можешь тоже поковыряться, интересно, что получится.
http://community.livejournal.com/coding4fun_ru/1510.html
Простая такая задачка, даже довольно реалистичная. Ближе к концу я уже перестал понимать, как там чуваки время меряют, но вообще у меня сложилось ощущение, что те проги на С и С++, которые там были, в сумме на этих 12 примерах жрали порядка 300 миллисекунд и больше, на загадочно широко распространённом среди участнегов атлон64 3000+. Да, участники вроде совсем не индусы. Я туда запостил прогу на шарпе, отбивавшуюся за 285 миллисекунд, потом, уже после формального завершения, я её ещё поковырял, сейчас у меня есть работающая версия, дающая 150мс, и я бы её ещё пооптимизил, если бы был повод, благо мыслей много, но кодить их влом. Подчеркну, это всё практически только за счёт именно оптимизаций, а не каких-либо хитроумных алгоритмических трюков.
Ну вот как бы вот. Просто пример такой. Можешь тоже поковыряться, интересно, что получится.
ты перебор что-ли оптимизировал?
я бы построил бор из масок и пустил бы волну с двух сторон.
я бы построил бор из масок и пустил бы волну с двух сторон.
Алгортм там в общем-то простой и особых ответвлений не допускает. Читаем слова, пихаем в хэштейбл заменяя буквы на звёздочки (я пробовал делать трие, но совершенно беспонтово, по-моему получаем граф, пускаем волну (с двух сторон может быть хорошо, если путь есть, но плохо, если его нет) или делаем А* (но у меня есть подозрение, что накладные расходы нифига не оправдаются).
А я занимался оптимизацией. Ты знаешь, что такое оптимизация? Попробуй напиши, посмотри на время, попытайся улучшить, в процессе может быть узнаешь, что такое оптимизация.
А я занимался оптимизацией. Ты знаешь, что такое оптимизация? Попробуй напиши, посмотри на время, попытайся улучшить, в процессе может быть узнаешь, что такое оптимизация.
заменяя буквы на звёздочки (я пробовал делать трие, но совершенно беспонтово, по-моему)ну да, логично:
>>> ord('*')
42
Оставить комментарий
ka19
Здравствуйте!Я начинающий программист на С, и думаю как лучше написать:
есть, допустим, текстовый файл со строчками. Какими функциями,
помимо fopen, можно оттуда целые строчки поштучно доставать?
Спасибо!