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

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

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

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

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

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

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

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

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

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

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

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

не знаешь про комбинируемые символы?

Ага, ну значит utf8 буду юзать.

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

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

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

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

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

Комбинируемые (а правильнее комбинирующие) символы ортогональны utf-8

https://en.wikipedia.org/wiki/Combining_character

Я выше писал, что Си на десктопе не нужен.

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

зачем ему вообще городить несколько приложений?

Это ж как тебя удивят настоящие высокоуровневые языки, значит...

Конечно, ведь есть же Vala. А как он умеет в единственный нормальный графический тулкит, ммм...

Это вы про убогий gtk?

Я вроде все мейнстримовое пробовал, под мои хотелки не подходят.

16 бит и вовсе на все языки мира хватит. wchar_t непортируем.

Ага, а потом оси падают от индусских символов

13. GNU dbm

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

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

Нормальные ОС не падают. :)

ядро десктопу тоже не нужно?

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

Ядро не при чём.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GUI нема.

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

Как лучше обрабатывать 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

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

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

Спасибо, книжку почитаю. Еще вопрос появился, не слишком велосипедно CSS «вручную» парсить?

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

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

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

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

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

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

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

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

GUI нема.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Свой GUI будет

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

А как мне поможет готовый GUI? Мне же все равно придеться рисовать все самому, позиционировать самому итд.

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

Это разве серьезная задача? Я уже начинал писать, сделал div, input button, img, hX, p, br. К ним CSS фигню, js прикрутил даже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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