Библиотеки на С слишком сложны. И в этой статье я хочу подробно описать что конкретно под этим имеется в виду и почему оно происходит
Нет, я не про сложность задач, которые они решают, не про количество кода или его качество, а про то, что они представляют собой для конечного пользователя.
Библиотеки не просто сложны, они выглядят намеренно переусложнёнными, как будто разработчики намеренно делали всё, чтобы то во что они вкладывали годами свой труд невозможно было использовать.
Для незнакомых с ситуацией вкратце - любая библиотека на С это в конечном счёте всего лишь набор .c файлов и набор .h файлов, а также опции компиляции которые записываются в современности в CMakeLists.txt. Для адекватных библиотек CMakeLists.txt обычно состоит из набора опций в самом верху (и только они нужны пользователю) и дальше описания таргетов (библиотеки, исполняемые файлы), зачастую это укладывается в сотню строк
Но по какой-то причине в реальности всё совсем не так и тут нужно смотреть на примеры
Типичным примером можно считать репозиторий OpenSSL. Взгляните на (ЧАСТЬ) того что видит перед собой человек, который хочет использовать OpenSSL:
template <class ForwardIt, class T, class Compare>
constexpr ForwardIt sb_lower_bound(
ForwardIt first, ForwardIt last, const T& value, Compare comp) {
auto length = last - first;
while (length > 0) {
auto rem = length % 2;
length /= 2;
if (comp(first[length], value)) {
first += length + rem;
}
}
return first;
}std::lower_bound, но вдвое быстрее и короче. «Без ветвления», потому что if компилируется в команду условной передачи, а не в ветвление/условный переход. Ближе к концу статьи мы изучим опции компилятора и даже более быстрые версии полностью без ветвления. Для понимания этой статьи не нужны особые знания в C++. Достаточно понимать, что итераторы (first и last) по сути являются указателями на элементы массива, хотя могут указывать на один элемент дальше, чем последний элемент массива. Можете не обращать внимания на template, class, constexpr и &. Вот если бы существовал быстрый и чистый язык, работающий на уровне железа...1 2
В этом тексте я делюсь трюками, с помощью которых удалось заставить Windows стать чем-то похожим на операционную систему реального времени.
Привет! Меня зовут Колосов Денис, я являюсь разработчиком клиентской части проекта «Allods Online» в студии IT Territory. Сегодня я расскажу о том, как мы решились обновить среду разработки и заодно компилятор на нашем проекте с Visual C++ 2010 на 2019.
О чем пойдет речь?
1. Как мы докатились до такой жизни и отважились на этот шаг;
2. О сборке вендерских библиотек и всего окружения, которое у нас есть;
3. С какими кастомными проблемами мы столкнулись;
4. К чему это все привело.
Предлагаем читателю очередную статью о проверке известного open-source проекта. В этот раз мы проверили проект LibreOffice, представляющий собой офисный пакет. В его разработке принимает участие более чем 480 программистов. Код оказался весьма качественным и регулярно проверяемым статическим анализатором Coverity. Но, как и в любом другом большом проекте, были найдены новые ошибки и недочеты, о которых мы и расскажем в статье. Для разнообразия, в этот раз нас будут сопровождать не единороги, а коровы.
Ровно два года назад — в ту же самую дату и в то же самое время — я опубликовал статью «ВКонтакте снова выкладывает KPHP».
Сегодня рассказываю, куда мы продвинулись за эти два года: про язык, рантайм, использование KPHP вне ВКонтакте, другие open-source проекты и февраль 2022-го.
#include "mbed.h"
DigitalOut myled(LED1);
int main() {
while(1) {
myled = 1; // LED is ON
wait(0.2); // 200 ms
myled = 0; // LED is OFF
wait(1.0); // 1 sec
}
}
11 августа компания Mail.Ru Объявила об очередном конкурсе HighloadCup для системных программистов backend-разработчиков.
Вкратце задача стояла следующим образом: докер, 4 ядра, 4Гб памяти, 10Гб HDD, набор api, и нужно ответить на запросы за наименьшее количество времени. Язык и стек технологий неограничен. В качестве тестирующей системы выступал яндекс-танк с движком phantom.
О том, как в таких условиях добраться до 13 места в финале, и будет эта статья.
Некоторое время назад я написал несколько статей о различных трюках, применявшихся в операционной системе DOS, чтобы вписаться в те жёсткие лимиты памяти, которые действовали в реальном режиме на архитектуре x86. Постоянно возникал и оставался без ответа один вопрос: а каковы были различные «модели», которые предлагались компиляторами тех времён? Взгляните, как выглядело меню для генерации кода в Borland Turbo C++.
Tiny (крошечный), small (маленький), medium (средний), compact (компактный), large (большой), huge (огромный)… Что означают эти опции? Каковы их эффекты? Ещё важнее… а так ли важен весь этот антиквариат сегодня, в мире 64-разрядных машин и гигабайтных ОЗУ? Чтобы ответить на этот вопрос, сделаем небольшой обзор архитектуры 8086 и тех двоичных форматов, которые поддерживались в DOS.
В продолжение к прошлой статье решил пощупать и Attiny10. Ну меньше уже точно ничего нет. Если и есть такое извращение с 4 ногами, я о нем не знаю, точнее не нашел.
Тут у нас полноценный МК, в корпусе SOT-23! И задачи на нем решать можно вполне серьезные. Собрав схему на макетке, с МК на адаптере и модулем дисплея я было обрадовался, но готовая плата работать отказалась...