И, наконец, моя самая любимая фишка 8-го интела: обработка директивы препроцессора #error. Когда компилятор встречает эту директиву, он выводит необходимое сообщение и удаляет заголовочный файл (.h), оказавшийся первым в списке инклюдов компилируемого .cpp.
При грамотном использовании директивы #error можно сильно облегчить свой проект, или, скажем, какой-нибудь SDK.
Я это уже где-то писал, но найти не смог, поэтому повторю. Ещё один прикол, который нетрудно сделать своими руками, но трудно найти и исправить.
(more…)
8-й компилятор от Intel может не только компилировать, но и удивлять.
(more…)
Я люблю UTF-8, и даже написал про это статью для DTF, где агитирую коллег уж если не пользоваться моим инструментом, то хотя бы взять на вооружение эту кодировку для своих игр. PCRE я люблю не менее, потому что данную библиотеку легко интегрировать и использовать (единожды разобрался — и порядок). И PHP люблю, в том числе и 4-й версии.
А всё вместе с недавнего времени не люблю. Потому что выяснилось, что PCRE в 4-м PHP работает коряво с русским UTF (если верить нашим интернетам). А если регистронезависимо, то и вообще не работает (в этом я убедился лично).
$match = preg_match('/фабрика/iu', 'Фабрика чего-то там');
Что бы вы ни думали, $match == false.
«Четвёрка» хорошо сбалансирована: библиотека mbstring, кажущаяся разумной альтернативой, при встрече с кириллистическим текстом (по крайней мере, в случае поиска без учёта регистра) становится так же непроницаемо тупа, как и PCRE. И даже вызов mb_regex_encoding() не делает её более понятливой.
Утешает только то, что в PHP 5 всё хорошо, а 4-й в наше время скорее экзотика, чем правило.
Google выпустил собственный браузер. Нарекли Chrome. С одной стороны, вполне логичное действие, с другой стороны, увеличение хаоса и бардака. Если игрушка станет популярной, при разработке придётся подстраивать HTML/CSS/JavaScript ещё и под него. Спасибо, Гугл, удружил.
Кстати, неплохой пост по теме: «7 Reasons Why Google Chrome, the New Google Browser is a Bad Idea».
Боян, конечно, но, сколько бы я его не перечитывал, каждый раз испытываю радость и умиление.
Вот тут Шодан призывает всех людей доброй воли голосовать за своё детище Sphinx. Не вижу причин отказывать Шодану.
Есть такая OS, FreeBSD. А есть такой стандарт, POSIX. А есть такие семафоры, с ними удобно синхронизировать потоки. И вот беру я и объявляю у себя один:
static sem_t stackSem;
А чуть позже его инициализирую:
if (sem_init(&stackSem, 0, 0) == -1)
return 0;
И моё бесхитростное приложение умирает, как будто и не было его. Читаю man, смотрю чужой код — всё указывает на мою правоту. Посыпаю голову пеплом, ищу товарищей по несчастью, и, как ни странно, нахожу. В том же форуме даётся один-единственный дельный совет за авторством ephemera, суть которого сводится к тому, что для поддержки семафоров в BSD необходимо правильно пересобрать ядро. Ну кто бы мог подумать! Сидим, пересобираем.
Upd. Отказались от семафоров, потому что
# p1003_1b_semaphores are very experimental,
# user should be ready to assist in debugging if problems arise.
Зла не хватает. Сами разрабатывают свой POSIX, и сами же не могут его по-человечески поддержать.
Есть вещи, попробовав которые ты уже никогда не будешь прежним. И средства разработки такие тоже есть. Одно из них — Source Insight, лучший редактор кода из всех, которые я видел (и не только я, взгляните на список компаний-пользователей внизу заглавной страницы сайта). На его освоение и настройку «под себя» нужно потратить примерно неделю, но после этого пользоваться другими средствами просто противно по причине их тотальной ущербности. Особенно хорошо это ощущается при выполнении задач, связанных с грудами чужого говнокода.
Однако SI существует только для Windows. А мне надо под Kubuntu. Скорее всего, ситуацию спасёт wine, но я хочу быть последовательным и сперва выяснить, есть ли что-нибудь подобное для Linux. Прямо сейчас я изучаю список ссылок по теме (к счастью, не меня одного беспокоит данный вопрос), возможно, и кто-нибудь из читателей готов что-нибудь посоветовать.
Upd. Есть подозрение что, wine не поможет.
Придумал написать небольшую кроссплатформенную программку, для чего решил поизучать XPCOM. Остался очень доволен. По мне, так неплохое решение для маленьких GUI-based тулов (при условии, что у пользователя стоит Firefox, конечно же). Конкретно в моём случае ещё можно заточить код под использование ActiveX, если XPCOM не случилось, что даёт вообще сказочные перспективы: произвольно настраиваемый GUI + кроссплатформенность + не нужна никакая инсталляция. Делать такие тулы — одно удовольствие.
Я под FreeBSD раньше не писал, возможно, так и должно быть, но всё же странно.
Итак, есть тривиальный код демона:
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int main(int argc, char* argv[])
{
FILE* pidf = 0;
printf("Noname daemon v 1.0.0\n");
daemon(1, 0);
if (pidf = fopen("noname.pid", "wb"))
{
fprintf(pidf, "%u", getpid());
fclose(pidf);
}
for (;;)
sleep(1);
return 0;
}
Как видно, он ничего не делает кроме того, что бессмысленно висит в памяти.
Компилирую я его следующим образом:
gcc main.c -pie -I/include -I. -lc -o noname
Внимание, вопросы: почему top показывает, что такой мелкий демон занимает 1272K памяти (из них 572 резидентной)? Куда ему столько? Можно ли уменьшить этот объём?
Upd. Умные люди просветили.