Comments 27
А не проще взять какой-нибудь libuv и забыть про 99% описанных тут нуансов?
Да, обучаться чему-то самому - всегда тяжелее, чем просто взять что-то уже приготовленное другими. Я не согласен с выводами типа "зачем учиться готовить борщ или плов, когда можно просто заказать еду в ближайшем кафе". Для того чтобы качественно программировать под ОС, необходимо хотя бы в общих чертах понимать как юзерский код взаимодействует с ядром. И чем глубже это понимание, тем лучше. Цель данного учебного материала - помочь читателю лучше в этом разобраться, узнать и научиться чему-то новому и интересному.
Имея эти фундаментальные знания, понимая суть, программист затем сам сможет выбрать любую понравившуюся ему библиотеку. И эти знания как раз помогут ему сделать наиболее правильный выбор.
ниасилил такой длинный текст, да еще в воскресенье. Но после чтения по диагонали вижу, что товарищ предпочитает заниматься (самоцензура выгрызла) вместо использования fopen(), а также молчит напрочь о нитках (thread), хотя какими-то функциями для них пользуется. Так же не упоминает о различии 1% функций стандартной библиотеки, которые на самом деле отличаются для для gcc и MS VC которые условно стандартны для линукса и винды.
У функций fopen() и компании есть недостатки, например, с помощью fread() нельзя читать из файла асинхронно (без отдельного потока).
Трэды - довольно таки сложная вещь для начального уровня, поэтому здесь я про них не рассказываю.
непонятно о каких потоках вы говорите и что имеется ввиду под асинхронным чтением. fopen() и компания - это есть функции потокового ввода-вывода, и вполне логично что без потока они не работают. Потоковый ввод-вывод почти всегда эффективнее.
Асинхронно кого с кем? Если программа работает в один поток, т.е. thread, то никакой асинхронности быть не может в принципе, а если в несколько, то для вас это сложная вещь. Если же есть куча процессов, хотя бы форкнутых, то читать процессам из файла хоть синхронно, хоть асинхронно никаких проблем, в отличии от писания.
Да, еще немного почитал по диагонали, насчет работы с памятью. Опять неясно, нафиг всё вот это вот, начиная с нетрадиционного называния кучи хипом. Никакого принципиального отличия в работе с кучей в линуксе и windows нет, пользуйте malloc() & Co и будет вам щастье и полностью портабельный код
Какой смысл писать обертки, уже над кросс-платформенными обертками, которыми является стандартная библиотека C/C++? Вроде того же fopen ? Молчу уж про то, что 95% оставшегося платформенно зависимого функционала покрывается, в каком ни буть Boost или Qt или еще какой-то менее известной фрэймворке/библиотеке. Иногда конечно бывает смысл написать обертку над каким-то точечным функционалам. Но то что описано в статье это просто пропагандирование NIH синдрома.
Возможно конечно, автор просто хочет, показать какие-то реальные примеры. Но что вот так делать в общем случаи не надо, хорошо бы написать красными буквами.
Если бы в стандартной библиотеке Си было всё что нужно и кросс-платформенно, то не было бы тех же libev, libuv и прочих кросс-платфомернных сишных библиотек. Насчёт fopen() - в этих функциях нет всего необходимого функцонала, например асинхронного I/O.
Вы наверное неправильно поняли цель данной статьи. Я ведь не призываю людей не пользоваться сторонними либами, в т.ч. boost или Qt - я лишь объясняю основу, на чём строится *любая* кросс-платформенная библиотека. А эти знания уже помогут более эффективно пользоваться тем же boost или Qt.
> Но что вот так делать в общем случаи не надо, хорошо бы написать красными буквами.
Опять же, не согласен с вами. Как делать, а как нет - это всё таки пусть решает каждый человек самостоятельно.
Любая кросс-платформенная библиотека строится на некоторой абстракции, которая бы эффективно покрывала все необходимые платформы. Придумать подобную абстракцию обычно довольно тяжело, особенно чтобы "раз и на все времена", а написать ее реализацию чаще всего не так чтобы сильно сложно.
Именно поэтому я не люблю, велосипеды для кросс-платформы, они почти всегда получаются с квадратными колесами, которые приходится переделывать, и скорее всего ни раз, а так же код который опирался на их не стабильный интерфейс.
Вот поэтому я и написал своё предложение, подтверждающее ваше, ниже: https://habr.com/ru/articles/726410/#comment_25400312
Статья полезна, чтобы понимать что вообще происходит, как это работает. Т.е. как это вживую работает на низком уровне, в одном из вариантов реализации. Спасибо. Очень интересно (для начинающего уровня).
Было интересно почитать, лет 20 на C не писал. Для выделения памяти и под windows есть malloc, calloc. Но в любом случае интересно и по моему очень даже неплохо. Автору спасибо.
Как мы можем решить эту проблему:
Переведу твой список:
1. Использовать языки в которых уже кто-то использует #ifdef и код под разные АПИ
2. Использовать самому #ifdef и код под разные АПИ
3. Найти на Си библиотеку с #ifdef и кодом под разные АПИ
Ну и не только на Си можно писать низкоуровневый код
Мне кажется, что для обеспечения кросс-платформенности программ на Си было бы лучше создать такое расширение стандарта языка, которое было бы реализовано стандартной библиотекой. То есть типа новый stdlib.h (не только он один) с расширенным набором необходимых функций, структур, констант, макросов и т.п. С соответствующими run-time библиотеками, естественно. Тогда кросс-платформенность стала бы просто частью нового стандарта языка.
То есть, это задача как для разработчиков стандарта языка, так и для разработчиков компиляторов. А далее, программисты просто будут пользоваться новым стандартом так же, как функцией printf(), например. Ну и весь вопрос тогда будет закрыт на этом.
Почему? Не вижу причин для этого.
Бывают платформы, где sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long int).
Не смотря на приведённый факт, это не помешало реализовать "malloc() & Co" независимо от платформы.
"эта функция поддерживается только при наличии long long int, эта только на LE, эта только при наличии float"
Можно через внедрённую настройку #define TARGETOS Windows/Linux/etc в стандартных #include реализовать любое поведение компилятора со всеми возможными ветвлениями. В том числе отказ компилировать программу, если для указанной в TARGETOS целевой платформы невозможно реализовать стандартную функцию. Что мне вообще кажется маловероятным.
То, что можно сделать стандартным для разных современных платформ, нужно сделать. Ведь авторы и разработчики языка си смогли это сделать для всего тогдашнего зоопарка платформ. По моему, нормальная задача для разработчиков и реализаторов стандарта.
я прочел все статью ? В качестве учебника-сравнения того, как разные штуки работают в разных ОС -- отличная вещь.
Что, если мы хотим написать высокопроизводительный сервер, как nginx? Нам абсолютно необходим Си. (...)
Но вот эта вводная очень не современна, мне кажется. Сейчас уже есть стабильный Rust, который заменяет Си по всем параметрам, в целом, и в котором прямо в стандартной библиотеке почти все (если не совсем все) из описанных оберток уже есть. Плюс активное сообщество.
А в С++ таких оберток в стандартной библиотеке нет?
> В качестве учебника-сравнения того, как разные штуки работают в разных ОС -- отличная вещь.
спасибо!
Насчёт Раст - до тех пор пока крупные хай-пеформанс проекты (nginx, postgre, etc.) не будут переписаны на нём, не приходится говорить о какой-либо замене старого доброго Си в обозримом будущем. Поддерживать старые сишные кросс-платформенные проекты всё равно придётся ещё долго, и материал данной статьи рассчитан именно на это.
Для вводной статьи - самое то. Надеюсь, в следующей будет работа с периферийными устройствами
Странная статья... Для новичка может и интересно, НО здесь есть слова "РУКОВОДСТВО" по "СИСТЕМНОМУ" программированию. А здесь ВВЕДЕНИЕ в кроссплатформенное прикладное программирование на Си (как в чём-то связанно с системным может вообще упоминаться Java и Go?).
Вот назовите статью правильно, и я просто её пропущу и не буду здесь нудеть)))
Была бы возможность минусануть, минусанул бы за кликбейтность.
Руководство по Кросс-Платформенному Системному Программированию для UNIX и Windows: Уровень 1