LINUX.ORG.RU

Вопросы по C, и вообще.

 , ,


4

9

Будем считать что я пишу прикладные программки.

  1. Как лучше обрабатывать malloc == NULL? Игнорировать или кидаться аbort() не хочется, но обработать нужно, обрабатывать каждый вызов?
  2. Писать свои строки или есть библиотека? Строки хранить как utf8 или utf32?
  3. Динамические массивы, писать свои, есть готовые? Как находить оптимальный размер для увеличение массива при расширении, нужно ли вообще заранее выделять память?
  4. Куда лучше выводить ошибку? Можно в консоль, но на винде не прокатит вроде, плюс ничего не видно.
  5. Нормальная ли идея: Есть много строк по 3-16 символов, сделать MyMemAllocate который при выделении (64 > X) байт, выделяет память в уже аллоцированном буфере на пару мегабайт к примеру... А при MyMemRealloc(X > 64) перемещает память из этого буфера в системную кучу. Перед данными хранить байт отвечающий за тип кучи.
  6. Когда структуру нужно передавать через стек а когда по указателю?
  7. на x86_64 быстрее uint32_t или uint64_t?
  8. for(...;i != len;...) vs for(...;i < len;...)
  9. Всегда ли ((unsigned)0-1) == ((unsigned)0-1)?
  10. На чем быстро рисовать графику (картиночки, кнопочки)? SDL2 говорят медленный.
  11. Есть много текста, с разным шрифтом, разным размером. Как лучше такое рисовать? (ttf), нарисовать алфавит для каждого {размер+шрифт}, или нарисовать алфавит с очень большим размером а потом сжимать для буков меньшего размера? Рендерит кто нибудь TTF на видеокарте кстати?
  12. Есть много объектов с одинаковыми и неизвестными именами, делать отдельную структуру (в виде чего?) где будут храниться эти имена дабы не занимать память одинаковыми строками?
  13. Как лучше хранить значения key:value что бы быстро с ними работать?
    1. если значений мало,
    2. если значений много.
  14. Можно ли как то поставить обработчик на изменение участка памяти? Костыль, но нужно. (Win/Linux хотя бы)
  15. Актуальна ли для современных систем фрагментация кучи?
  16. Какие библиотеки есть для многопоточного? Что можно почитать? SDL_Thread тоже медленный?
  17. Вот допустим решил я распарсить INI файл, как лучше его читать? По линиям? Сразу весь? Проецировать?
  18. Библиотека для RegExp?
  19. Какие флаги для строгости компилятора юзать стоит? Я использую: -std=c89 -Wall -pedantic

Ну или можно книжку где это расписанно.

Ответ на: комментарий от tailgunner

не надо паниковать. у нас тут целый ЛОР про систему на Си. таки неуместно тут возмущаться.

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

Iron_Bug ★★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

всегда будут нужны те, кто умеет не стрелять себе в ногу.

И их никогда не будет.

не надо паниковать. у нас тут целый ЛОР про систему на Си

Авторы этой системы тоже регулярно стреляют себе в ноги.

tailgunner ★★★★★ ()
Ответ на: комментарий от linuhs_user

>И uint32_t не всегда вместит символ полностью

Да? Например?

Мы сейчас будем сраться за термины или ты действительно не знаешь про комбинируемые символы?

yyk ★★★★★ ()
Ответ на: комментарий от Iron_Bug

Поддерживаю так люто, как только могу.

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

dsl ()
Ответ на: комментарий от slovazap

еще один тролль…

Сколько ж вас, рукожопых, не осиливших С?

anonymous ()
Ответ на: комментарий от RazrFalcon

Что-то ты очень жирно и неумело троллишь.

anonymous ()
Ответ на: комментарий от Iron_Bug

мы не сможем им объяснить даже малую часть сложностей серьёзной разработки.

Какое напыщенное название для кучи переизобретённых велосипедов на платформозависемых костылях.

anonymous ()
Ответ на: комментарий от t184256

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

Iron_Bug ★★★★★ ()

Имхо, слишком много общих вопросов, не имеющих однозначных ответов вне конкретной задачи.

Из треда я понял, что пишется браузер для PC.

Я бы сформулировал, для каких осей и процов пишется браузер, насколько он кроссплатформенный, будет ли он использоваться на планшетах или только на обычных компах? Наконец, с какой целью пишется браузер? Что не устраивает в существующих и что хотелось бы сделать по-другому?

Из этого первым делом выбирал бы инструмент:

  1. C — наиболее низкоуровневый из всех вариантов (ну, если не считать ассемблера). Писать на нём будет сложнее всего, многое нужно будет велосипедить или искать неизвестно где библиотеки. Зато потом отлаживать будет проще. И код при прочих равных будет надёжнее, чем на крестах.
  2. C++ — писать надо тоже аккуратно. Код получится слегка пожирнее. Зато для крестов намного больше инструментов, которые могут тебе пригодиться. Например, шаблоны, STL, boost, тот же Qt.
  3. Неожиданно Pascal — не очень популярный ныне язык, а напрасно. Для Linux есть IDE Lazarus — аналог Delphi. Код безопаснее, чем на си и на крестах, и не намного менее эффективен, если писать нормально.
  4. Java — удобно, безопасно, кроссплатформенно, но неэффективно.

Ну и есть другие варианты.

Дальше я бы выбрал графическую библиотеку. Сейчас для GUI на крестах Qt, наверно, самая популярная. Но на чистом C с ней работать не получится. Кроме того, она довольно жирная. А под андроид, говорят, ещё и недопилена по-человечески, и работает медленнее, чем java.

Ну а остальные вопросы — по мере возникновения проблем. Например, строки, если их просто нужно хранить и иногда выводить, проще рассматривать как последовательность байт, а что в этих байтах — зависит от локали. Но если в строках надо производить поиск, причём не только двоичный, но и лексикографический, или без учёта регистра, например, то для этих целей строки удобнее преобразовывать в многобайтные символы фиксированной ширины. Равно нет универсального ответа, как распределять память, нужно ли её заранее выделять и т. д. Всё это надо тестировать в конкретных кусках программы. Для константных строк достаточно выделить ровно столько памяти, сколькло они занимают. А для динамически увеличивающихся массивов память можно выделять заранее. Но насколько больше? Без конкретных тестов однозначного ответа тут быть не может. Однако все эти детали лучше допиливать потом. Сначала надо написать программу, чтоб она хоть как-то работала, используя стандартные аллокаторы, а потом уже искать узкие места и оптимизировать, а не наоборот.

aureliano15 ★★ ()
Ответ на: комментарий от Iron_Bug

а гуй можно писать на чём угодно, ему не важна скорость и оптимизация.

Как это не важна?! Вот поэтому-то современные гуёвые програмы такие тормозные, что все так думают.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

для каких осей

Где запустится.) Linux, Windows, BSD.

Что не устраивает в существующих

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

Сначала надо написать программу

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

linuhs_user ()
Ответ на: комментарий от aureliano15

Что не устраивает в существующих и что хотелось бы сделать по-другому?

Человек не в состоянии оценить сложность задачи. Не разрушайте его фантазии.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

А что я смогу сделать по твоему? Хочу послушать. Давай, прикинь что я смогу реализовать)

linuhs_user ()
Последнее исправление: linuhs_user (всего исправлений: 2)

Как лучше обрабатывать malloc == NULL? Игнорировать или кидаться аbort() не хочется, но обработать нужно, обрабатывать каждый вызов?

можно сделать обёртку над malloc() в которой обрабатывать NULL, если это будет удобно в твоём случае

Строки хранить как utf8 или utf32?

если только хранить то utf-8 если будешь модифицировать их то в wchar_t

Динамические массивы, писать свои, есть готовые?

определить структуру с тремя полями и функции new, push, pop, append. займёт меньше пяти минут

Как находить оптимальный размер для увеличение массива при расширении

просто умножай на 2. уверен ты ещё не определился как именно это будет использоваться но уже думаешь о тонкой оптимизации

нужно ли вообще заранее выделять память?

самый точный ответ получишь измерив оба варианта в своих условиях, я почти уверен разницы не будет

Куда лучше выводить ошибку?

stderr, если комуто будет удобнее в другое место ему не будет сложно перенаправить

Нормальная ли идея: Есть много строк по 3-16 символов, сделать MyMemAllocate который при выделении (64 > X) байт, выделяет память в уже аллоцированном буфере на пару мегабайт к примеру... А при MyMemRealloc(X > 64) перемещает память из этого буфера в системную кучу. Перед данными хранить байт отвечающий за тип кучи.

malloc() у всех живых libc знает как эффективно обрабатывть мелкие запросы

Когда структуру нужно передавать через стек а когда по указателю?

когда структура больше указателя и тебе не нужно передовать именно копию то лучше по указателю

на x86_64 быстрее uint32_t или uint64_t?

Intel Optimisation Guide рекомендует не использовать 64-битные инструкции для данных которые не будут больше 32-бит, т.к. 64-бит инструкции длинне и потому их меньше помещяется в кеш

for(...;i != len;...) vs for(...;i < len;...)

без разницы, главное что-то одно

Всегда ли ((unsigned)0-1) == ((unsigned)0-1)?

да, согласно 6.3.1.3.2 стандарта

На чем быстро рисовать графику (картиночки, кнопочки)? SDL2 говорят медленный.

на нём игры пишут и ты думаешь тебе его для GUI не хватит? можно OpenGL напрямую

Есть много объектов с одинаковыми и неизвестными именами, делать отдельную структуру (в виде чего?) где будут храниться эти имена дабы не занимать память одинаковыми строками?

только если иначе ты не помещяешься в память

Как лучше хранить значения key:value что бы быстро с ними работать?

мало — вектор пар (k,v), много — бинарное дерево; если простое дерево будет сильно медленным относительно всего остального в gprof(1) отчётах, сделаешь балансированным

Актуальна ли для современных систем фрагментация кучи?

сделай тесты на сколько это окажется релевантно для твоей программы. ещё не понятно проявится ли это в твоей программе а ты уже чинишь

Вот допустим решил я распарсить INI файл, как лучше его читать? По линиям? Сразу весь? Проецировать?

что займёт меньше кода, последний вариант тут не имеет смылса

Библиотека для RegExp?

regex.h

Ну или можно книжку где это расписанно.

The Practice of Programming

anonymous ()
Ответ на: комментарий от RazrFalcon

Да шо ты говоришь! Вся жабу, что я видел, именно в гуях и заключалась: и матлаб, и лабвью и прочая погань вантузячья! Да и ондроед — тот ведь тоже без жабы никуда!

Отличное доказательство того, что жаба — дерьмо!

anonymous ()
Ответ на: комментарий от anonymous

просто умножай на 2

Это — копипаста советов от быдлокодеров. Нельзя так делать. Надо константный объем памяти прибавлять, а не умножать на два! Ну и всегда проверять физически доступный объем памяти, благо, линукс это позволяет.

У нас с царем уже были терки насчет malloc, и он доказал мне, что надо в линуксе работать через жопу!

anonymous ()
Ответ на: комментарий от linuhs_user

Хочу быстрый и настраиваемый, и убрать всякие сомнительные вещи, например воспроизведение видео браузером.

Ну тогда Qt, наверно, не самый лучший выбор. Но я бы заранее продумал, что из GUI нужно и насколько удобно это реализуется в выбранной библиотеке. Может, задал бы отдельный вопрос здесь же, что вот мне нужно эффективно реализовать такие-то элементы GUI, насколько эта библиотека подходит для данных целей.

И вообще к выбору языка и библиотек (не только для GUI) надо отнестись серьёзно ещё до написания программы, чтоб потом всё не переделывать с нуля. Так, на ansi c89 без крестов написать браузер может оказаться в разы сложнее, чем на крестах. Хотя и на крестах эта задача совсем не элементарная, если мы говорим о настоящем полноценном браузере, а не просто о парсере html-страничек.

Кстати, в одной давней теме про учебник Столярова, начиная с этого камента и ниже среди прочего обсуждаются и браузеры в плане того, как их надо делать и как не надо. Я бы почитал. Имхо, Столяров, он же croco, порой необоснованно нападает на использование процессов/потоков и прочее распараллеливание, но доля правды в этом есть. Если бы, например, все js-скрипты выполнялись в одном потоке, причём в низкоприоритетном потоке, то, возможно, таких тормозов, какие мы имеем сейчас на кривых веб-страничках, не было бы.

aureliano15 ★★ ()
Ответ на: комментарий от RazrFalcon

Java — удобно, безопасно, кроссплатформенно, но неэффективно.

GUI нема.

Как же нема? GUI там не только мае, но ещё и стандартизировано на уровне языка, в отличие от си и крестов.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Если бы, например, все js-скрипты выполнялись в одном потоке, причём в низкоприоритетном потоке

все js-скрипты выполнялись в одном потоке отдельном процессе (это надёжнее, чем в потоке, а расходы не так уж и велики), причём в низкоприоритетном процессе

aureliano15 ★★ ()
Ответ на: комментарий от anonymous

в скольких потоках сейчас по твоему это работает?

Не знаю. Не дебажил код браузеров. Но знаю, что часто скрипт легко подвешивает браузер. Если там и используется один поток для всех скриптов, в чём я не уверен, значит приоритет этого процесса должен быть ниже, чем у всего остального.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Один поток для всего уже давно не модно, даже firefox перешёл на многопроцессную модель. Другое дело что js и dom живут в одном потоке, и зависший скрипт блокируют отрисовку отдельной страницы, но тут авторы браузеров не виноваты, т.к. dom по стандарту синхронный и сделать работу с ним асинхронной не нарушая стандартов нетривиальная если вообще осуществимая задача

anonymous ()
Ответ на: комментарий от anonymous

Один поток для всего уже давно не модно

Я совсем не сторонник Столярова в этом вопросе и тоже согласен, что в разумных пределах можно и нужно использовать разные процессы и потоки. А почитать каменты советовал просто «хозяйке на заметку».

Другое дело что js и dom живут в одном потоке, и зависший скрипт блокируют отрисовку отдельной страницы

Только не отдельной страницы, а зачастую всего браузера.

но тут авторы браузеров не виноваты, т.к. dom по стандарту синхронный и сделать работу с ним асинхронной не нарушая стандартов нетривиальная если вообще осуществимая задача

Возможно. Но это единственный путь, если хочешь сделать браузер с поддержкой js, который не будет постоянно подвисать на кривых страничках. А именно это, если я правильно понял, и является конечной целью ТС'а.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Но я бы заранее продумал, что из GUI

Я там писал что хочу сделать буфер команд, один тред будет писать в буфер по сути страничку, а другой тред будет рисовать. Свой GUI будет.

Так, на ansi c89 без крестов написать браузер может оказаться в разы сложнее

Если не заморачиваться то на си мне проще.

linuhs_user ()
Ответ на: комментарий от linuhs_user

Свой GUI будет

Но это отдельная задача. Возможно, более сложная, чем написание браузера. В своё время разработчики gimp'а создали отдельный проект gtk для него со своим gui. Можно, конечно, пойти и по такому пути, но, боюсь, браузер тогда выйдет в лучшем случае лет через 10.

aureliano15 ★★ ()
Ответ на: комментарий от linuhs_user

Но хотя бы компоненты будут уже готовые. А тут и их придётся создавать с нуля со всеми колбаками или сигналами/слотами, в зависимости от того, что больше нравится.

aureliano15 ★★ ()
Ответ на: комментарий от linuhs_user

Это разве серьезная задача? Я уже начинал писать, сделал div, input button, img, hX, p, br.

А ещё полосы прокрутки, которые то надо отображать, то нет; главное и контекстные меню; адресную строку; строку состояния; вкладки; разные модальные и не модальные диалоги, а в них всё те же вкладки, поля ввода, выпадающие и невыпадающие списки, кнопки и т. д.

Но тебе виднее, особенно если уже делал это без использования библиотек. Только зачем всё это велосипедить, если есть готовые инструменты? Думаешь, ты в одиночку напишешь лучше всех?

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

А ещё полосы прокрутки, которые то надо отображать, то нет;

Это легко детектится.

адресную строку

Это на HTML тоже реализовать, и остальное.

поля ввода, выпадающие и невыпадающие списки, кнопки и т. д.

Мы в разных мирах наверное, это примитивные вещи которые можно написать за один вечер.

linuhs_user ()
Ответ на: комментарий от linuhs_user

адресную строку

Это на HTML тоже реализовать, и остальное.

В смысле «на HTML»? Ты что, браузер на html пишешь?

поля ввода, выпадающие и невыпадающие списки, кнопки и т. д.

это примитивные вещи которые можно написать за один вечер.

Хм... Ну, тебе виднее. Бог, как говорится, в помощь.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

В смысле «на HTML»? Ты что, браузер на html пишешь?

Я и ОС на нем пишу! Ну сделать веб рендер, и все остальное тоже на нем.

Хм... Ну, тебе виднее. Бог, как говорится, в помощь.

Ну те которые в списке действительно за вечер реализовать можно.

linuhs_user ()
Ответ на: комментарий от Iron_Bug

И я прям чую, что в его задаче такое разделение неоправдано.

t184256 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.