Используется ли концепция отложенных буферов за пределами ODBC?
В ODBC, Отложенные буферы это концепция, в которой значение используется через некоторое время после того, как оно указано в вызове функции.
В рамках своего исследования я пытался выяснить, есть ли в настоящее время какое-либо другое приложение, в котором отложенные буферы используются за пределами ODBC?
В связи с этим я хотел бы узнать от сообщества, сталкивались ли они с чем-то похожим в других областях.
Решение
Это очень специфическая деталь реализации ODBC. В начале 1990-х годов были распространены 16-битные операционные системы, такие как Windows 3.x. Что очень важно для использования памяти и во избежание дублирования хранилища было очень важно.
Таким образом, общий шаблон в ODBC состоял в том, что приложение выделяло хранилище, необходимое для табличных данных и запросов. Те «отложенные буферы», о которых вы говорите. SQLBindCol () позволяет драйверу ODBC позднее выложить извлеченные данные непосредственно в хранилище, выделенное приложением. SQLBindParameter () делает противоположное для данных, передаваемых из приложения в базу данных.
Это была хрупкая схема, очевидно, что очень плохие вещи случаются, когда приложение освобождает буферы слишком рано. Вот почему современные 32-битные и 64-битные провайдеры данных больше этого не делают. Они сами распределяют буферы, приложение копирует данные из / в них.
Как «концепция», которая применяется к другим обычаям, в этом нет ничего особенного. Многие функции API работают таким образом: вы передаете указатель на буфер, а функция API затем копирует данные в / из передаваемого вами буфера. Единственное, что немного особенного в ODBC, это то, что буфер может оставаться в использовании после одного вызова функции API. Обычно с этим лучше справиться с концепцией «ручки». Другими словами, есть функция API, которая выделяет и возвращает непрозрачное число для идентификации ресурса. Затем приложение вызывает другие функции API и передает дескриптор обратно. И одна специальная функция, которая снова отпускает дескриптор. Таким образом, меньше несчастных случаев, кроме риска утечки ручки.
Другие решения
detector