Комментарии 125
НЛО прилетело и опубликовало эту надпись здесь
А зачем с азов? Материала для начинающих в сети куча. Что-нибудь среднего уровня — уже сложнее найти, а продвинутого либо совсем нет, либо какие-нибудь очень узкоспециализированные заметки.
А кто на C не писал(и кому не нужно это), тот и после прочтения азов писать не начнет, за ненадобностью.
А кто на C не писал(и кому не нужно это), тот и после прочтения азов писать не начнет, за ненадобностью.
Начинать надо с установки и настройки удобной среды разработки
НЛО прилетело и опубликовало эту надпись здесь
Лично я предпочитаю emacs, но это уже дело вкуса.
В отличие от Win и Mac OS X разработка под *NIX отличается тем, что нет единой, общепринятой, де-факто стандартной среды, как VS или XCode. Кто-то сидит в терминале с Vim/Emacs и консольным gdb, кто-то пользуется KDevelop, кто-то Eclipse+CDT, кто-то NetBeans, а кто-то ещё чем-то, о чём я наверное даже не слышал. Да и про настройку всех этих сред миллион статей уже давно написан.
НЛО прилетело и опубликовало эту надпись здесь
Было бы интересно почитать именно о программировании под *NIX. Т.е узнать о том чем тема отличается от тех же Виндов, особенности данной платформы, ее возможности, файловой системы например, но конечно все в применении к программированию.
Поддерживаю iv_s, для новичков и так материала по всему интернету полным-полно.
Ну в таком уж случае можно показать где самый норм материал и с чего вообще начинать новичку.
www.google.com O_o?
Тогда зачем вообще этот блог?
Может сразу www.google.com
Согласен с puzzo. Если и не писать азы, то тогда составить список ссылок, где почитать можно было бы новичкам)
Может сразу www.google.com
Согласен с puzzo. Если и не писать азы, то тогда составить список ссылок, где почитать можно было бы новичкам)
Если говорить про Си, интересно услышать пару слов о современных сферах применения.
И очень интересна тема написания дврайверов под Linux
И очень интересна тема написания дврайверов под Linux
Кстати да, где применяется Си кроме драйверов и, собственно, системы?
У нас даже железяки типа сканеров штрих-кодов или читалок карт у дверей программируются на сишарпе или, прости господи, на абапe :)
У нас даже железяки типа сканеров штрих-кодов или читалок карт у дверей программируются на сишарпе или, прости господи, на абапe :)
Ну например фирма, в которой я работаю занимается поддержкой стека протоколов ss7 (применяется в сотовой связи). Протоколы реализуются на С++ или Джаве, а конкретно мой модуль — платформозависимая часть, которая должна компилиться под добрый десяток операционок (обусловленно это тем, что есть куча платформ, на которых всё это добро должно крутиться) как раз таки написана на Си. Соответственно в подобных специфических решениях Си и применяется. И вряд ли его в ближайщем времени что-либо там заменит.
Мне бы было интересно почитать про процессы/потоки, то есть fork() и pthreads. И про какие нибудь либы для работы с основными протоколами(http,ftp...), а также про библиотеки для регулярных выражений в C.
Все перечисленное, это то, чего мне не хватает для комфортной работы с C.
Все перечисленное, это то, чего мне не хватает для комфортной работы с C.
Кстати, еще хотел бы узнать как мерить потребление памяти своего приложения, т.е. время выполнения просто time ./myapp, а как пик потребления памяти посчитать? Ну и конечно хотелось бы узнать про методики поиска и устранения мемори ликов.
В общем руководство к valgrind ;)
Спасибо за наводку:) Судя по описанию — то что я искал. Вот только одно но, там написано что вроде только под линукс, а я большей частью за маком… Но ничего, сейчас попробуем собрать, может удасться:)
А случаем не знаете каких либо аналогов? На случай если под маком не заведеться.
А случаем не знаете каких либо аналогов? На случай если под маком не заведеться.
Для мака есть неофициальный порт http://www.sealiesoftware.com/valgrind/. Других свободных не знаю :(
После непродолжительного гугленья обнаружилось что этот порт совсем недавно был включен в бранч официального репозитария.
Если кому будет интересно, поставил так:
Никаких патчей не нужно, вроде все норм работает.
Буду разбираться:)
Если кому будет интересно, поставил так:
svn co svn://svn.valgrind.org/valgrind/branches/DARWIN valgrind cd valgrind ./autogen.sh ./configure make sudo make install
Никаких патчей не нужно, вроде все норм работает.
Буду разбираться:)
Для поиска мемори-ликов и прочих проблем с памятью есть просто обалденная штука — Rational purify. Только вот стоит она — мама не горуй :(
Про потоки не расскажу, а fork предельно прост: тупо запускает копию родительского процесса, при этом родительский процесс получает PID дитя.
r = fork();
if (-1 == r) {
printf(«Случилось что-то страшное\n»);
} else if (0 == r) {
printf(«Я дитя!»);
} else {
printf(«Я не дитя, но дитя у меня есть: %d», r);
}
Раньше дитя получало копию всех родительских ресурсов, сейчас используются облегченные форки с copy-on-write — дитю подсовываются указатели (грубо говоря) на память предка, но как только он пытается в нее что-то записать, ему выделяется под это дело своя память, чтобы не разрушить работу предка.
Поскольку в юниксе исторически стартует всего один процесс (init pid = 1, если не считать ядро pid = 0), то если ему надо запустить какую-нибудь программу, то он должен по идее сделать exec("/path/to/some/program"), но в этом случае вместо инита выполнится some_program и по завершении вся система, кроме ядра уйдет в даун (инит конечно же ядром перезапустится, сколько я помню, но это не вариант все равно), поэтому инит сначала делает форк, а уже его дите делает exec, ибо дите нам не жалко.
Т.о. по сути все запущенные программы работают внутри программы init в том месте, где дергается exec у дитя. Идем дальше. Пользователь работает в оболочке (ну или командная строка, хотя это название мне не очень нравится); когда он набирает какую-то команду (точнее, имя файла с программой, досягаемое в пределах путей, перечисленных в $PATH), она выполняется в пределах оболочки. Если мы написали классный демон, запустили его в фоновом режиме в оболочке, а затем ее закрыли, демон так же сдохнет, поскольку принадлежит ее дереву процессов. Чтобы этого избежать, мы должны сделать примерно следующее:
if (fork()) {
// посылаем систему на фиг — мы теперь сами себе хозяева
setsid();
// делаем свое грязное дело даже после закрытия оболочки
while (1)
;
} else {
// родитель, привязанный к оболочке больше не нужен
exit();
}
Что делает setsid точно не скажу — вроде как выставляет вызывающий процесс лидером сессии (группы процессов о_О). Лучше ман на эту тему почитать))
Что касается библиотек для работы с http/ftp — вроде бы все известные сервера юзают свои реализации и работают напрямую с сокетами.
А регулярные выражения — libpcre однозначно))
Стоит она почти везде, если не везде; писать на ней достаточно просто.
r = fork();
if (-1 == r) {
printf(«Случилось что-то страшное\n»);
} else if (0 == r) {
printf(«Я дитя!»);
} else {
printf(«Я не дитя, но дитя у меня есть: %d», r);
}
Раньше дитя получало копию всех родительских ресурсов, сейчас используются облегченные форки с copy-on-write — дитю подсовываются указатели (грубо говоря) на память предка, но как только он пытается в нее что-то записать, ему выделяется под это дело своя память, чтобы не разрушить работу предка.
Поскольку в юниксе исторически стартует всего один процесс (init pid = 1, если не считать ядро pid = 0), то если ему надо запустить какую-нибудь программу, то он должен по идее сделать exec("/path/to/some/program"), но в этом случае вместо инита выполнится some_program и по завершении вся система, кроме ядра уйдет в даун (инит конечно же ядром перезапустится, сколько я помню, но это не вариант все равно), поэтому инит сначала делает форк, а уже его дите делает exec, ибо дите нам не жалко.
Т.о. по сути все запущенные программы работают внутри программы init в том месте, где дергается exec у дитя. Идем дальше. Пользователь работает в оболочке (ну или командная строка, хотя это название мне не очень нравится); когда он набирает какую-то команду (точнее, имя файла с программой, досягаемое в пределах путей, перечисленных в $PATH), она выполняется в пределах оболочки. Если мы написали классный демон, запустили его в фоновом режиме в оболочке, а затем ее закрыли, демон так же сдохнет, поскольку принадлежит ее дереву процессов. Чтобы этого избежать, мы должны сделать примерно следующее:
if (fork()) {
// посылаем систему на фиг — мы теперь сами себе хозяева
setsid();
// делаем свое грязное дело даже после закрытия оболочки
while (1)
;
} else {
// родитель, привязанный к оболочке больше не нужен
exit();
}
Что делает setsid точно не скажу — вроде как выставляет вызывающий процесс лидером сессии (группы процессов о_О). Лучше ман на эту тему почитать))
Что касается библиотек для работы с http/ftp — вроде бы все известные сервера юзают свои реализации и работают напрямую с сокетами.
А регулярные выражения — libpcre однозначно))
Стоит она почти везде, если не везде; писать на ней достаточно просто.
Спасибо за развернутый ответ. Вот еще примеров добавить, и этот комент можно постить статьей в этот блог:)
Возвращаемое значение fork — это ноль если мы в дочернем процессе и больше нуля если в родительском? И если больше нуля, то это и есть pid дочернего процесса? Теперь вроде понятно, а то меня всегда на этом клинило. Кстати, а как грохнуть дочерний процесс?
Про http — с серверами то понятно, мне обычно нужно клиентов деалать, get/post запросы. Хм, только сейчас сообразил, наверно мне libcurl посмотреть нужно.
За libpcre большое спасибо, пошел разбираться:)
Какой хороший блог, я нашел ответы чуть ли не на все проблемы, которые у меня с C возникали:)
Возвращаемое значение fork — это ноль если мы в дочернем процессе и больше нуля если в родительском? И если больше нуля, то это и есть pid дочернего процесса? Теперь вроде понятно, а то меня всегда на этом клинило. Кстати, а как грохнуть дочерний процесс?
Про http — с серверами то понятно, мне обычно нужно клиентов деалать, get/post запросы. Хм, только сейчас сообразил, наверно мне libcurl посмотреть нужно.
За libpcre большое спасибо, пошел разбираться:)
Какой хороший блог, я нашел ответы чуть ли не на все проблемы, которые у меня с C возникали:)
Чтобы грохнуть, надо записать его пид, и потом послать ему сингал:
pid_t cpid;
cpid = fork();
if(cpid == -1)
{
printf("Something is wrong\n");
}
else if (cpid == 0)
{
while(1); // Ребенка - в бесконечный цикл.
}
else
{
// родитель
printf("Press k to kill or t to terminate the child");
char buf;
fread(&buf, 1, 1, stdin);
if(buf=='k')
kill(cpid, SIGKILL);
else if(buf=='t')
kill(cpid, SIGTERM);
else
printf("\nNot a correct answer\n");
}
Могу наваять пост о разработке многопроцессного демона рассылки после обкатки его в боевых условиях. Причем, на PHP — для настоящих извращенцев))
Надо?
Надо?
Это мне вопрос? Лично мне это не интересно, я с PHP никак не связан, я Ruby программист. А C интересуюсь больше в контексте расширений для Ruby.
Но думаю если в блоге PHP опубликуете, то людям будет интересно:)
Но думаю если в блоге PHP опубликуете, то людям будет интересно:)
Кстати, а разве в PHP есть потоки? Или там какое то хитрое решение на запусках экземпляров интерпретаторов?
Надо.
инит конечно же ядром перезапустится, сколько я помню, но это не вариант все равно
По крайней мере Linux не перезапустит и запаникует с криками «attempt to kill init».
Если мы написали классный демон, запустили его в фоновом режиме в оболочке, а затем ее закрыли, демон так же сдохнет, поскольку принадлежит ее дереву процессов.
Не совсем так. Он сдохнет, только если оболочка его явно прибьёт сама при завершении, в противном случае он перекочует в «дети init-а».
Совершенно верно, но по-хорошему тот процесс, который запустил дите, должен отвечать за их уничтожение. По сигналу TERM, которое по умолчанию шлется закрываемой пользователем программе, так обычно и происходит.
Могу сказать одно, если запустить процесс как
$ foo &
и после этого сделать
$ ^D
в bash-3.2.39(1)-release
То этому процессу не придет ни одного сигнала из вот этого списка: SIGHUP SIGSYS SIGQUIT SIGUSR1 SIGFPE SIGTSTP SIGCHLD SIGIOT SIGBUS SIGXCPU SIGPROF SIGCLD SIGUSR2 SIGSEGV SIGINT SIGIO SIGTRAP SIGILL SIGPOLL SIGABRT SIGALRM SIGPIPE SIGWINCH SIGTERM SIGVTALRM SIGRTMIN SIGRTMAX SIGURG SIGPWR SIGXFSZ SIGTTIN SIGTTOU
Проверял скриптом на питоне.
$ foo &
и после этого сделать
$ ^D
в bash-3.2.39(1)-release
То этому процессу не придет ни одного сигнала из вот этого списка: SIGHUP SIGSYS SIGQUIT SIGUSR1 SIGFPE SIGTSTP SIGCHLD SIGIOT SIGBUS SIGXCPU SIGPROF SIGCLD SIGUSR2 SIGSEGV SIGINT SIGIO SIGTRAP SIGILL SIGPOLL SIGABRT SIGALRM SIGPIPE SIGWINCH SIGTERM SIGVTALRM SIGRTMIN SIGRTMAX SIGURG SIGPWR SIGXFSZ SIGTTIN SIGTTOU
Проверял скриптом на питоне.
НЛО прилетело и опубликовало эту надпись здесь
Было бы интересно посмотреть примеры модулей к PHP и базам данных и т.д — т.е. к существующим приложениям общего назначения. А то книжки по юниховому C++, как правило, рассказывают про визуальные среды — типа «как нам сделать Visual Studio под Линух». Да и примеры кода там ужасающие приводятся. И, в самом деле, лучше начинать с азов — я последний раз (не считая микроопыта месячной давности, давшегося, надо признать, большой кровью) писал на C лет 20 назад, а пресловутый микроопыт показал, что С довольно сильно изменился.
кстати user defined functions к mySQL — довольно интересная тема
Ну, мне интереснее contrib к PostgreSQL — собственно с ним как раз был связан этот самый последний микроопыт. Если я правильно понимаю, MySQL тоже нау
Кликнулось слишком быстро. В смысле, MySQL тоже умеет писать свои функции? Мы просто с ним не работаем. Но показатель производительности на постгресе впечатляет — функция, написанная на C пашет быстрее функции, написанной на PL/PgSQL, думаю, на порядки. Во всяком случае сортировка по индексу на основе самопальной C-шной функции (и, соответственно — по самопальному типу данных) работает примерно с той же скоростью, что и сортировка по встроенным типам данных, что есть хорошо. Правда, там куча как теперь уже малознакомой специфики (конструкций языка) — так изаведомо малознакомой специфики — как Postgresql
На сайте zend.com весьма подробное изложение о том, как писать модули к PHP (http://devzone.zend.com/node/view/id/1021).
Пишется преимущественно на чистом Си, поскольку в этом случае можно воспользоваться скриптом phpize, который на основе шаблона сгенерит configure и еще какие-нибудь рюшечки, после которых для сборки и установки модуля достаточно будет выполнить ./configure && make install.
Модуль в самом простом случае состоит из сишных макросов, предоставляемых зендовской либой, которые создают новые функции на php, описывают их параметры и вешают обработчики (функции на Си, которые эти сами параметры принимают). Соответственно, сначала надо придумать API, затем на его основе написать сишную библиотеку, которая реализует все эти функции, оттестить ее в консоли (если возможно), затем описать все макросы и создать шаблон для phpize.
Си в отличие от C++ особо-то и не изменялся вроде, там все вполне просто)
Пишется преимущественно на чистом Си, поскольку в этом случае можно воспользоваться скриптом phpize, который на основе шаблона сгенерит configure и еще какие-нибудь рюшечки, после которых для сборки и установки модуля достаточно будет выполнить ./configure && make install.
Модуль в самом простом случае состоит из сишных макросов, предоставляемых зендовской либой, которые создают новые функции на php, описывают их параметры и вешают обработчики (функции на Си, которые эти сами параметры принимают). Соответственно, сначала надо придумать API, затем на его основе написать сишную библиотеку, которая реализует все эти функции, оттестить ее в консоли (если возможно), затем описать все макросы и создать шаблон для phpize.
Си в отличие от C++ особо-то и не изменялся вроде, там все вполне просто)
А все зависит от того, что вы хотите рассказать в своих статьях.
Если о С вообще — то логичнее начинать с основ. Если в конкретной привязке к *nix — то разбирать именно особенности (kernel moules, glibc, xorg\apache\php extensions, etc), а не сам язык.
Если о С вообще — то логичнее начинать с основ. Если в конкретной привязке к *nix — то разбирать именно особенности (kernel moules, glibc, xorg\apache\php extensions, etc), а не сам язык.
да-да, «apache/php extensions» — тру! :)
кстати, вот хорошая статья: " Разработка модуля для Apache 2.x"
habrahabr.ru/blogs/webdev/50909/
habrahabr.ru/blogs/webdev/50909/
Выше писали насчет расширений для PHP. Чесно говоря, мне кажется по тематике это больше к PHP относиться, чем к C. К тому же уже была статья, когда про расширения для Ruby писал, нашел случайно: shuffle.habrahabr.ru/blog/39033/
Для новичков было бы интересно, по моему мнению, работа на «низком» уровне Си и ядра, допустим Линукса, Си и работа с потоками *nix, работа с сетью. Попутно нужно будет рассказать на примере, как организовано управление памятью и т.д. Мне кажется, это будет очень ценной информацией, в данном случае.
Причем для самых маленьких наверное не выйдет, т.к. все эти вещи подразумевают какой-то начальный уровень знания Си и, хотя бы, основы работы с памятью (указатели, выделение и т.д.). А писать очередной ЕщеОдинУчебник по Си наверное не цель автора?
Причем для самых маленьких наверное не выйдет, т.к. все эти вещи подразумевают какой-то начальный уровень знания Си и, хотя бы, основы работы с памятью (указатели, выделение и т.д.). А писать очередной ЕщеОдинУчебник по Си наверное не цель автора?
В ключе для тех, кто знаком с Си, но плохо ориентируется в том какие есть инструменты (либы то бишь) и с какой стороны к этому делу заходить.
Не хотелось бы видеть очередной туториал по Си для менеджеров или же перевод документации gtk+.
Не хотелось бы видеть очередной туториал по Си для менеджеров или же перевод документации gtk+.
C удовольствием поделюсь опытом использования механизмов очередей epoll(linux)/kqueue(freeBSD) на примере сервера, обслуживающего тысячи клиентов :)
Прочитал бы с удовольствием про unit тестирование C-кода.
«демонизация» приложений — очень интересная тема
fork() fork() setsid()? В классике описано же…
тема чуть более широка :)
отладка, логгирование, многопоточность, разграниченный доступ к ресурсам.
на самом деле, любую информацию можно получить из книг и в гугле. но концентрированные тонкости и нетривиальные ходы в пределах одного блога — это ведь интересно, разве нет? ;)
отладка, логгирование, многопоточность, разграниченный доступ к ресурсам.
на самом деле, любую информацию можно получить из книг и в гугле. но концентрированные тонкости и нетривиальные ходы в пределах одного блога — это ведь интересно, разве нет? ;)
А еще интересно про неблокирующие сетевые операции и поллинг.
Вы не кого-то извиняете, а сами просите прощения, поэтому правильно «извините за...», а не «извиняюсь».
даешь раздел: «говорим по-русски»: о)
Уже есть habrahabr.ru/blogs/pishu_pravilno/
Спасибо. Поправил.
вы, наверное, хотели сказать о возвратном значении суффикса «ся»?
тогда возражу, что он не всегда возвратный… кидаюсь !== кидаю себя
а сказали вообще другое: если бы он кого-то извинял, то сказал бы «извиняю»
вы из тех, наверное, кто часто исправляет «кофе мужского рода!», делая при этом кучу речевых ошибок
тогда возражу, что он не всегда возвратный… кидаюсь !== кидаю себя
а сказали вообще другое: если бы он кого-то извинял, то сказал бы «извиняю»
вы из тех, наверное, кто часто исправляет «кофе мужского рода!», делая при этом кучу речевых ошибок
Я сам раньше был удивлен что говорить «извиняюсь» является ошибкой, ведь так говорят ВСЕ. Я не филолог, поэтому объяснил насколько смог. Если Вас интересует эта тема можете погуглить.
И я не из «тех» :) Русский не мой родной, но у нас в Украине также есть «вибачаюсь», (извиняюсь на украинском) что также не верно. А казусов вроде «кофе — он» у нас нету.
И я не из «тех» :) Русский не мой родной, но у нас в Украине также есть «вибачаюсь», (извиняюсь на украинском) что также не верно. А казусов вроде «кофе — он» у нас нету.
Очень интересно было бы читать про решение каких-либо конкретных интересных задач, нежели читать теорию, которую и так можно найти.
А мне бы хотелось статей на тему сетевого программирования под никс, и тонкостей побольше.
С удовольствием буду следить за блогом =)
Ну вот у меня конкретная задача, хочу вести большую базу данных, качать файлы с юзеров и отсылать им файлы же. Всё это должно висеть сервисом на nix-сервере. Что мне вообще использовать? Какие маны раскуривать? Я раньше только под винды писал (учебные задачки с семафорами не считаются), не знаю за что хвататься и какие средства использовать.
И блог очень кстати появился) как раз задача возникла вчера)
И блог очень кстати появился) как раз задача возникла вчера)
Хм. тут много чего курить можно. Программировать под *nix тут несколько сбоку. Скорее в тему web-разработка. Вариантов может быть масса. Я бы порекомендовал курить в сторону:
nginx[fstcgi]+(lighttp|apache|другие варианты)+(php|perl|pyton|c[++]|другие варианты)+(mysql|pgsql|другие варианты)+(memcached)
nginx[fstcgi]+(lighttp|apache|другие варианты)+(php|perl|pyton|c[++]|другие варианты)+(mysql|pgsql|другие варианты)+(memcached)
Ну с большей частью названного вами я «на ты». Наверное я просто слишком поверхностно сформулировал задачу.
Нужен видимо демон, к которому могут подключаться клиенты, предоставляю некую информацию о себе, на основе которой сервер может в любой момент запросить с клиента фаил и получить его. + к этому нужно раз в несколько минут отправлять клиентам файлы, ну или по запросу клиента (что видимо сильно упростит задачу).
Имхо писать нужно не на php и вообще не на скриптовом языке, хотя могу заблуждаться конечно.
Нужен видимо демон, к которому могут подключаться клиенты, предоставляю некую информацию о себе, на основе которой сервер может в любой момент запросить с клиента фаил и получить его. + к этому нужно раз в несколько минут отправлять клиентам файлы, ну или по запросу клиента (что видимо сильно упростит задачу).
Имхо писать нужно не на php и вообще не на скриптовом языке, хотя могу заблуждаться конечно.
Т.е. какие-то самописные клиенты и свой собственный протокол? Тогда я бы начал с разработки протоколов взаимодействия. А реализация это уже дело техники. Если срочно нужно что-то курить, то можно курить в сторону socket. :)
Пиcать можно на чем угодно, что эти сокеты поддерживает. Лично я бы скорее всего написал для начала рабочий прототип на perl. Потом при особой нужде портировал бы его на C.
Пиcать можно на чем угодно, что эти сокеты поддерживает. Лично я бы скорее всего написал для начала рабочий прототип на perl. Потом при особой нужде портировал бы его на C.
тут нужно курить темы:
— сокеты
— процессы (fork)
— сигналы
— демоны
— сокеты
— процессы (fork)
— сигналы
— демоны
НЛО прилетело и опубликовало эту надпись здесь
Мне было бы интересно почитать про работу с DirectFB библиотекой. Интерес связан с тем, что в ближайшем будущем придется использовать эту библиотеку в проекте.
Именно сейчас занимаюсь разработкой небольшой библиотеки для linux/windows, цель которой во основном — обертка для API. Юзать кроссплатформенные либы аля boost, apr, poco нехочется поэтому ровно половину придется писать как раз под POSIX. Так что оч. надо.
Тема интересная.
Для новичков можно вставлять ссылки на разделы какого-нибудь онлайн-учебника.
Например встретился указатель — сделали ссылочку на то, где рассказывается об указателях.
И не надо заново писать учебник по Си, и в тоже время уже есть материал для изучения дополнительный.
Для новичков можно вставлять ссылки на разделы какого-нибудь онлайн-учебника.
Например встретился указатель — сделали ссылочку на то, где рассказывается об указателях.
И не надо заново писать учебник по Си, и в тоже время уже есть материал для изучения дополнительный.
Многопоточное программирование.
Т.е. как запустить отдельный поток и т.п. я знаю или найду в документации, а вот интересны именно принципы многопоточного программирования, взаимодействия потоков, разбиения задачи на потоки и т.п.
Язык, в принципе, не важен и зависит от задачи, хоть php :)
Т.е. как запустить отдельный поток и т.п. я знаю или найду в документации, а вот интересны именно принципы многопоточного программирования, взаимодействия потоков, разбиения задачи на потоки и т.п.
Язык, в принципе, не важен и зависит от задачи, хоть php :)
Хочется видеть не «как сделать то-то», а «почему это сделано так, какие ещё варианты были и т.п.».
про getopt было бы здорово почитать — что то на русском хорошего литературного описания этого дела я не встречал
Почитайте лучше про boost::program_options.
да я бы не против. но если я хочу написать маленькую консольную тулзу на 20 строчек, вы предлагаете тянуть буст в нее? имхо гетопт будет уместнее
Не вижу разницы, что тянуть, главное, чтобы пользоваться было удобно.
У меня сложилось такое впечатление, что люди воспринимают буст, как одну монструозную мега-библиотеку на стотыщпицот мегабайт, которую если уж подцепил к программе, то всё, капец. Буст — это набор библиотек. Некоторые даже не требуют линковки — они полностью в заголовочных файлах. К program_options это правда не относится, её линковать нужно.
У меня сложилось такое впечатление, что люди воспринимают буст, как одну монструозную мега-библиотеку на стотыщпицот мегабайт, которую если уж подцепил к программе, то всё, капец. Буст — это набор библиотек. Некоторые даже не требуют линковки — они полностью в заголовочных файлах. К program_options это правда не относится, её линковать нужно.
я мало общался с бустом, и возможно, имею предвзятое отношение к нему. И вот линковка как раз не понравилась — динамическая не подходит, потому что буст очень динамично меняется, и поэтому либы в имя включают версию буста. Конечно, можно придумать костыль — но зачем придумывать костыль?
Можно же прилинковать статически.
Тогда бинарник разжиреет. Что тоже не очень хорошо.
можно, но такая безальтернативность немного напрягает. Сейчас не могу привести фактов, но как то статически слинкованный буст(регэкспы, даты-время, хэш, и еще что-то) не плохо раздул мою программу. А может я и ошибаюсь) Я, кстати, не противник буста, если потребуется что то сложно для плюсов — первым делом буду искать там)
И еще одни довод про getopt. Заголовки буста в некоторых дистрибутивах разбиты на модули. И не установлены по умолчанию. С getopt`ом то попроще будет)
И еще одни довод про getopt. Заголовки буста в некоторых дистрибутивах разбиты на модули. И не установлены по умолчанию. С getopt`ом то попроще будет)
Я понял вашу мысль, спасибо.
На всякий случай, вдруг в будущем пригодится, в boost есть утилитка bcp — она позволяет извлечь из дерева буста только те файлы, которые вы используете, чтобы вы могли их распространять с исходниками своей программы, освобождая тех, кто будет эту программу собирать, от необходимости скачивать и собирать буст самим.
На всякий случай, вдруг в будущем пригодится, в boost есть утилитка bcp — она позволяет извлечь из дерева буста только те файлы, которые вы используете, чтобы вы могли их распространять с исходниками своей программы, освобождая тех, кто будет эту программу собирать, от необходимости скачивать и собирать буст самим.
Можно оставить эту головную боль мэйнтейнерам пакета в дистрибутиве :-)
ээ… не понял. Я же не мантейнер пакетов, а всего лишь программист. Мне нужно программу написать, и желаьельно, что бы она потом комплировалась на других системах. Если она не скомпилится, звонить то будут мне, а не мантейнерам пакетов)
Гм. Разве буст настолько динамично развивается, что регулярно меняет API без обратной совместимости?
Boost не C.
man 3 getopt — три страницы, плюс за описанием следует подробный пример.
Я не уверен, но по-моему там нечего переводить :-)
Я не уверен, но по-моему там нечего переводить :-)
Про getopt рекомендовал бы почитать Арнольда Роббинса «Программирование в примерах».
Если возможности нет, могу по мотивам главы из книги написать статью по этому поводу.
Если возможности нет, могу по мотивам главы из книги написать статью по этому поводу.
Про то как писать приложения, которые собираются не только на вашей конкретной установке конкретного дистрибутива, а «почти всюду». Со всеми этими безумными ifdef'ами и идеологии автоматизации этого барахла автотулзами и чем там ещё новомодным (- симейком?).
Для самых маленьких.
ммм… Всем привет!) в программировании под nix я еще соовсем маленький, как впрочем и в программировании на сях… к моему большому сожалению… но это не беда!)) вообще этот блог мне хотелось бы видеть следующим:
1) статьи по установке, сравнению инструментов (gcc, emacs и тд..) не обязательно собственноручно написанные, можно подборки статей (гуглить не в падлу)
2) статьи и задачи по тому, через что должен пройти матерый линуксовый коддер…
3) разбор полетов высокого уровня (или низкого кому как угоднее)
было бы здорово посмотреть на то как другие люди пишут)) Изучая код линуксового ядра (не долго и с головной болью) я открыл для себя «парадигму ошибки», если не ошибаюсь… нуууу и тд(:
1) статьи по установке, сравнению инструментов (gcc, emacs и тд..) не обязательно собственноручно написанные, можно подборки статей (гуглить не в падлу)
2) статьи и задачи по тому, через что должен пройти матерый линуксовый коддер…
3) разбор полетов высокого уровня (или низкого кому как угоднее)
было бы здорово посмотреть на то как другие люди пишут)) Изучая код линуксового ядра (не долго и с головной болью) я открыл для себя «парадигму ошибки», если не ошибаюсь… нуууу и тд(:
хотелось бы видеть статьи по написанию tcp серверов, использование неблокированных сокетов, практика использования libevent, практиа использования shmop, особенности многотредованного программирования и прочих системных инструментов.
было бы интересно услышать про таймеры в с++ :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вступительное слово