LINUX.ORG.RU

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

 , ,


2

7

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

  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

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

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

Барин, что-то вы в тырнетах засиделись, извольте откушать супу, стол накрыт уже.

Вон бери пример с Царя. Смену на заводе отработал и гуляй на все четыре стороны — смотри аниме, играй в доту, запиливай убийцу Сишки, обосовывай ЛОР, создавай свой культ личности с последователями. Вот это жизнь!

А веб-мартышка вкалывает 24/7, у нее даже на доширак времени нет. И в итоге ее все равно за борт выкинут.

anonymous ()

Вон автор Modest ищет деньги на написание движка: https://habrahabr.ru/post/349512/

Разработчик qutebrowser поднимал себе €7,069 и CHF 8,169 на месяц работы. Это около 500k рублей. Причем это просто говносборка из разных компонентов с заточкой под vi-управление.

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

Киньте ему ссылку на этот коммент, а то фиг знает как этот ваш Хабр писать.

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

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

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

Из-за этого же нет нормальных «сравнений», «сопутствующих», «конструкторов».

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

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

Ну тогда Qt, наверно, не самый лучший выбор.

А как всё-таки из первого следует второе, можно поподробнее? Я не говорю, что Qt - идеальный инструмент, но слухи о её тормознутости, по-моему, сильно раздуты.

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

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

Ну тогда Qt, наверно, не самый лучший выбор.

А как всё-таки из первого следует второе, можно поподробнее? Я не говорю, что Qt - идеальный инструмент, но слухи о её тормознутости, по-моему, сильно раздуты.

Ну, сильно-не сильно, а факт раздутости Qt в сравнении с той же GTK и со многими другими библиотеками имеет место быть. Например, QString работает намного медленнее std::string. См., например, этот тест. В том же треде было и объяснение, почему это так. Ну а на андроидах, как я читал, Qt-программы вообще работают медленнее java-программ. Андроид в данном случае не критичен, т. к. ТС заявил о написании браузера для ПК, но то, что для заявленной цели существуют инструменты лучше, чем Qt, по-моему очевидно.

А вообще я не так давно потестировал разные существующие альтернативные графические браузеры. Из тех, с чем вообще можно работать с некоторыми (иногда серьёзными) оговорками в современном вебе среди опробованных мною, могу выделить luakit и xombrero. Но первый периодически начинает что-то активно писать на диск и в это время начинает подтормаживать, хотя процессор и ОЗУ не очень грузит. А второй при большом числе открытых вкладок тоже в какой-то момент начинает дико тормозить, грузит комп, а потом падает. Так что преимущества их перед «большой тройкой» или «большой пятёркой» (если говорить не только о Линукс и добавить IE с Сафари) сомнительны, а серьёзные недостатки имеются. Почему веб так криво работает — понятно, и об этом писалось и в этом треде. Но вот что должно быть сделано в браузере, чтоб он нормально работал с этим кривым вебом, «выпрямляя» его — сказать сложнее, как и то, возможно ли это вообще. Я думаю, что копать стоит в сторону снижения приоритетов js- и других браузерных скриптов и апплетов и в ограничении подгрузки кусков страницы, когда эти куски грузятся до бесконечности или почти до бесконечности.

aureliano15 ()