19 лет

С утра задергали, чуть не забыл 🙂

Я вот думаю, надо уточнить — 18 января 2000 года я понял, что OLE DB провайдер таки придется писать.

Бо к тому моменту я уже наелся своими поделками на тему COM-интерфейсов для доступа к InterBase и уже понимал, что крупный проект (который только предстояло писать) они явно не потянут.

Так что сегодня 19 лет как я решился создать эту штуку.

Дури много тогда было, да.

UPD. 6940 дней 🙂

Для чего нужен FB

На нем можно выполнить очень полезный запрос:

select CURRENT_DATE-CAST('<дата вашего рождения>' AS DATE) FROM RDB$DATABASE

И узнать сколько вам сегодня стукнуло дней.

Я свои 15000 дней очень хорошо отметил.

А сегодня пойду отмечать 25000 дней своего старика 🙂

Hyper Threading

Оставлю здесь ссылку на эту заметку про Hyper Threading.

Чтобы долго её не искать, когда у меня снова появятся мысли — «может включить его у себя?«.

Строчка кода …

… которая будет очень долго вызывать у меня тоску по времени, бездарно потраченному на глупые решения:

pDataSource->m_spDsState.swap(spOpenedState); //no throw

Вести с полей

В новой тестовой сборке IBProvider (v3.55.1.29284) исправлена очень древняя ошибка, связанная с непониманием различия между состоянием источника данным и состоянием подключения.

Как следствие, вместо проверки состояния источника данных (здесь достаточно определить сам факт перехода в инициализированное состояние) проверялось состояние подключения (в общем случае это приводит к дерганью сервера).

Проверка состояния источника данных выполняется в методах IDBProperties, которые могут вызываться относительно часто.

По идее, это исправление делает ненужным свойство инициализации check_cn_status.

Не прошло и двадцати лет. Только девятнадцать.

VS2010 и VS2012

Уже очень хочется от них избавиться.

И начать писать по-настоящему интересные программы с «enum class» и «variadic templates».

С наступающим Новым Годом!

Наверное уже можно поздравить всех, кто сюда заглядывает, с наступающим Новым 2019-ым Годом!

И это, простите меня, если что 🙂

Мысль …

… пришла в больную голову. ОРЗ или что-то вроде того, блин.

Я тут как-то тут писал что в сетевых пакетах (гоняемых между сервером и клиентом) первым делом нужно указывать их длину.

Ну, чтобы его можно было целиком выбирать пакет из потока без анализа его данных.

Сейчас этого (в FB) нет, и как результат плохо работает отмена выполнения операции (op_cancel).

Еще можно в пакеты включать последовательно генерируемый ID, для более точного управления. Но это так. Мысль не про это.

Мысль про то, что в последнем байте нужно засылать флаг подтверждения завершения отправки пакета. Какие могут быть варианты значений этого флага:

— Ноль, если все ok и пакет таки надо обработать.
— Единица, если пакет нужно выкинуть. К примеру, в процессе его отправки клиент передумал и решил его отменить.

Не знаю, хорошая эта мысль или плохая. Но зафиксировать её стоит.

Вести с полей

На сайт загружена новая тестовая сборка IBProvider — v3.55.0.29115.

В неё, в том числе, вошли результаты борьбы с предупреждениями PVS-Studio.

95% это замена assert на assert_hint.

//-V:assert_hint:779, 547
#define assert_hint(cond) assert(cond);

Из этих 95% большая часть — в моей переработанной версии libtommath, которую перед тем как затащить в проект пришлось перетряхнуть и нафаршировать ассертами.

Для остальных 5% пришлось напрячься. (далее…)

assert_hint

Созерцая предупреждение PVS-Studio для код вида:

HRESULT hr=S_OK;

try
{
 //.... много страшного кода, которые может кидать исключения, но таки не трогает hr.

 assert(hr==S_OK); //PVS-Studio warning: V547 Expression 'hr == ((HRESULT) 0L)' is always true.
}
catch //....

… задумался.

У меня таких декларативных отладочных проверок — даже не вагон и маленькая тележка. Тут их эшелон(ы).

И наверное уже пора добавить в свою в инструментальную библиотеку макрос assert_hint.