С утра задергали, чуть не забыл 🙂
Я вот думаю, надо уточнить — 18 января 2000 года я понял, что OLE DB провайдер таки придется писать.
Бо к тому моменту я уже наелся своими поделками на тему COM-интерфейсов для доступа к InterBase и уже понимал, что крупный проект (который только предстояло писать) они явно не потянут.
Так что сегодня 19 лет как я решился создать эту штуку.
Дури много тогда было, да.
UPD. 6940 дней 🙂
На нем можно выполнить очень полезный запрос:
select CURRENT_DATE-CAST('<дата вашего рождения>' AS DATE) FROM RDB$DATABASE
И узнать сколько вам сегодня стукнуло дней.
Я свои 15000 дней очень хорошо отметил.
А сегодня пойду отмечать 25000 дней своего старика 🙂
Оставлю здесь ссылку на эту заметку про Hyper Threading.
Чтобы долго её не искать, когда у меня снова появятся мысли — «может включить его у себя?«.
… которая будет очень долго вызывать у меня тоску по времени, бездарно потраченному на глупые решения:
pDataSource->m_spDsState.swap(spOpenedState); //no throw
В новой тестовой сборке IBProvider (v3.55.1.29284) исправлена очень древняя ошибка, связанная с непониманием различия между состоянием источника данным и состоянием подключения.
Как следствие, вместо проверки состояния источника данных (здесь достаточно определить сам факт перехода в инициализированное состояние) проверялось состояние подключения (в общем случае это приводит к дерганью сервера).
Проверка состояния источника данных выполняется в методах IDBProperties, которые могут вызываться относительно часто.
По идее, это исправление делает ненужным свойство инициализации check_cn_status.
Не прошло и двадцати лет. Только девятнадцать.
Уже очень хочется от них избавиться.
И начать писать по-настоящему интересные программы с «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% пришлось напрячься. (далее…)
Созерцая предупреждение 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.