Последовательность инициализации и сброса в расширениях PHP

Я сейчас занимаюсь написанием расширения , которое меняет UID/EUID (а также GID/EGID) процесса -интерпретатора на UID/GID владельца DocumentRoot сайта. При этом по замыслу расширение должно отключаться, если SAPI не используется (например, запущена CLI-версия интерпретатора).

Для этой задачи оказалось важным знать точную последовательность инициализации и финализации. Далее »

Автор: , опубликовано в: C/C++, PHP, комментариев: нет
29
Авг
2009

GCC: освобождение ресурсов для ленивых

Одной из, скажем так, «нетрадиционных» возможностей, которые предоставляет , являются атрибуты типов, переменных и функций.

Я хочу рассказать об одном из них — а именно, отвечающем за удаление использованных ресурсов. Далее »

Автор: , опубликовано в: C/C++, комментариев: 2
2
Июн
2009

PHP: зависимости времени выполнения между расширениями

Так (как, кстати, рекомендует Sara Golemon) нельзя:

[-]
View Code C
#if ZEND_MODULE_API_NO >= 220050617
static zend_module_dep php_afs_depencies[] ={
    ZEND_MODULE_REQUIRED("krb5");
    {NULL,NULL,NULL}
}
#endif

Потому что даже не скомпилируется, если с ZEND_MODULE_API_NO (не) повезёт. Далее »

Автор: , опубликовано в: C/C++, комментариев: нет
13
Май
2009

О пользе избыточной инициализации, или, В исходный код смотреть вредно

То, что данные нужно инициализировать перед использованием, знают все. Но иногда правильная инициализация — хитрая штука. Я с этим столкнулся, когда писал расширение для , работающее с Voxel Hosting API.

Одна из проблем PHP — плохая документация (отсутствие таковой) по внутреннему API. А из кода не всегда всё однозначно ясно, чо временами приводит к очень милым ошибкам вида «фиг ты меня найдешь» (смягчено из соображений цензуры).

Об одной из таких особенностей я хочу рассказать. Далее »

Автор: , опубликовано в: C/C++, комментариев: нет
7
Май
2009

Параллельная версия генерации и проверки подписи по алгоритму DSA

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

, использующие «большие числа» — всегда хорошие кандидаты на распараллеливание. Дело в том, что даже при современной мощности процессоров многие задачи являются довольно сложными с вычислительной точки зрения. Хотя криптографические , как правило, очень тяжело поддаются распараллеливанию (например, когда значение, вычисленное на предыдущем шаге алгоритма, используется на текущем шаге), чисто математические задачи все же дают определённый простор для распараллеливания.

В данной статье рассмотрим возможность распараллеливания алгоритма DSA. Далее »

Автор: , опубликовано в: C/C++, OpenMP, Безопасность, комментариев: 1
3
Май
2009

Полиморфизм времени компиляции без использования виртуальных функций

Рассмотрим такой фрагмент кода:

[-]
View Code C++
#include <iostream>

struct A {
    A() {};
    ~A() { ::std::cout < < "A::~A()\n"; }
};

struct B : public A {
    B() {};
    ~B() { ::std::cout << "B::~B()\n"; }
};

int main(void)
{
    {
        const A& a = B();
    }

    return 0;
}
Вопрос: что будет выведено в результате выполнения кода? Далее » Автор: , опубликовано в: C/C++, комментариев: нет
29
Апр
2009

И снова о простых числах Софи Жермен

Год назад я писал о генерации простых чисел Софи Жермен.

Вкратце напомню: p — простое число , если q = 2p+1, тоже простое число. Простые числа Софи Жермен применяются в криптографии (в частности, в протоколе обмена ключами Диффи–Хеллмана–Меркле). Далее »

Автор: , опубликовано в: C/C++, комментариев: 4
22
Апр
2009

C или C++?

Задача: программа должна вывести строку «С++», если скомпилирована на С++ и «С», если на С. Далее »

Автор: , опубликовано в: C/C++, комментариев: 3
19
Апр
2009

Сколько будет i++ + ++i?

Вопрос для собеседования на вакансию -программиста:

int i = 5, j = i++ + ++i; – чему равно i и j?

Ответ вида «За такое нужно руки отрывать», не подходит, ибо автор вопроса считает, что знает правильный ответ — i=7, j=12. Но так ли это? Далее »

Автор: , опубликовано в: C/C++, комментариев: 5
13
Апр
2009

Распараллеливать или не распараллеливать — вот в чём вопрос

 — мощная технология, позволяющая значительно повысить быстродействие приложения без переработки его архитектуры. Как и в случае с любой другой мощной технологией, знать, когда нужно её использовать не менее важно, чем уметь с этой технологией работать. В данной статье мы попытаемся показать, что распараллеливание — не панацея от всех бед, и неправильное его использование не только не улучшает производительность приложения, но и может привести к проблемам. Мы постараемся рассмотреть реализацию на низком уровне, чтобы оценить потери производительности, связанные с издержками на управление потоками и внутреннюю синхронизацию. В конце статьи будут даны некоторые практические рекомендации по использованию . Далее »

Автор: , опубликовано в: OpenMP, комментариев: 1
10
Апр
2009
«
»