Что такое буфер в программировании

Буферы

Буфер — это любая часть памяти приложения, используемая для передачи данных между приложением и драйвером. Например, буферы приложений могут быть связаны с столбцами результирующего набора с SQLBindCol или привязаны к ним. При выборке каждой строки данные возвращаются для каждого столбца в этих буферах. Входные буферы используются для передачи данных из приложения в драйвер. выходные буферы используются для возврата данных из драйвера в приложение.

Если функция ODBC возвращает SQL_ERROR, содержимое всех выходных аргументов этой функции не определено.

В основном это обсуждение касается буферов неопределенного типа. Адреса этих буферов отображаются в виде аргументов типа СКЛПОИНТЕР, например аргумент таржетвалуептр в SQLBindCol. Однако некоторые обсуждаемые здесь элементы, например аргументы, используемые с буферами, также применяются к аргументам, используемым для передачи строк в драйвер, например аргумента TableName в SQLTables.

Эти буферы обычно бывают парными. Буферы данных используются для передачи самих данных, в то время как буферы длины и индикатора используются для передачи длины данных в буфере данных или специального значения, такого как SQL_NULL_DATA, которое указывает, что данные имеют значение null. Длина данных в буфере данных отличается от длины самого буфера данных. На следующем рисунке показана связь между буфером данных и буфером «Длина/индикатор».

Буфер длины и индикатора необходим всякий раз, когда буфер данных содержит данные переменной длины, такие как символьные или двоичные данные. Если буфер данных содержит данные фиксированной длины, такие как структура типа Integer или Date, буфер длины и индикатора необходим только для передачи значений индикатора, так как длина данных уже известна. Если приложение использует буфер длины или индикатора с данными фиксированной длины, драйвер игнорирует все переданные длины.

Длина буфера данных и содержащихся в нем данных измеряется в байтах, а не в символах. Это различие не имеет значения для программ, использующих строки ANSI, так как длина в байтах и символах одинакова.

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

Если аргумент функции, указывающий значение поля или атрибута, является указателем на символьную строку, аргумент length имеет длину строки или SQL_NTS.

Если аргумент функции, указывающий значение поля или атрибута, является указателем на значение, отличное от символьной строки или двоичной строки, аргумент length должен иметь значение SQL_IS_POINTER.

Если аргумент функции, указывающий значение поля или атрибута, содержит значение фиксированной длины, аргумент длины — SQL_IS_INTEGER, SQL_IS_UINTEGER, SQL_IS_SMALLINT или SQL_ISI_USMALLINT, в зависимости от ситуации.

Источник

Руководство по использованию буферов

ПРИМЕЧАНИЕ: Перезапуск игры не очистит и не удалит буфер! Но это предотвратит дальнейший доступ к ранее созданному буферу, так как ID handle будет потерян, что вызовет утечку памяти, которая в конечном итоге приведет к краху вашей игры. Поэтому, перезапуская игру, не забудьте сначала удалить все буферы.

GameMaker Studio 2 позволяет создавать четыре различных типа буферов. Причина этого заключается в том, что буферы предназначены для высоко оптимизированного временного хранения данных, и поэтому вы должны создавать буфер, соответствующий типу данных, которые вы хотите в нем хранить, иначе вы можете получить ошибки или вызвать узкое место в вашем коде. Прежде чем объяснять это дальше, давайте рассмотрим четыре доступных типа буферов (определенные как константы в GML ):

При создании буфера всегда старайтесь создавать его с размером, соответствующим типу, общее правило гласит, что он должен быть создан для максимального размера данных, которые он должен хранить, а если есть сомнения, используйте растущий буфер для предотвращения ошибок перезаписи.

Фактический код для создания буфера будет выглядеть примерно так:

player_buffer = buffer_create(16384, buffer_fixed, 2);

Это создаст фиксированный буфер размером 16384 байта с выравниванием по байтам до 2, при этом функция возвращает уникальное значение ID, которое хранится в переменной для последующего обращения к этому буферу.

При чтении и записи данных в буфер, вы делаете это «кусками» данных, определяемыми их «типом данных». Тип данных» задает количество байт, выделяемых в буфере для записываемого значения, и очень важно, чтобы это было правильно, иначе вы получите очень странные результаты (или даже ошибки) для вашего кода.

Запись в буфер (и чтение из него) происходит последовательно, то есть одна часть данных записывается за другой, причем каждая часть данных имеет определенный тип. Это означает, что в идеале вы должны постоянно знать, какие данные вы записываете в буфер. Эти типы данных определяются в GML следующими константами:

Итак, допустим, вы создали буфер и хотите записать в него информацию, тогда вы используете что-то вроде следующего кода:

buffer_write(buff, buffer_bool, global.Sound);
buffer_write(buff, buffer_bool, global.Music);
buffer_write(buff, buffer_s16, obj_Player.x);
buffer_write(buff, buffer_s16, obj_Player.y);
buffer_write(buff, buffer_string, global.Player_Name);

Рассмотрев приведенный выше пример, можно увидеть, что в буфер можно одновременно записывать различные типы данных (при использовании быстрого типа буфера вы ограничены только определенным типом данных), и эти данные будут добавляться в буфер последовательно (хотя их фактическое положение в буфере будет зависеть от их выравнивания по байтам, о чем будет сказано ниже). То же самое относится и к чтению информации из буфера, и в случае приведенного выше примера вы будете читать из буфера в том же порядке, в котором записывали данные, проверяя наличие одного и того же типа данных, например:

global.Sound = buffer_read(buff, buffer_bool);
global.Music = buffer_read(buff, buffer_bool);
obj_Player.x = buffer_read(buff, buffer_s16);
obj_Player.y = buffer_read(buff, buffer_s16);
global.Player_Name = buffer_read(buff, buffer_string);

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

Если вы читали эту страницу, то наверняка видели упоминания о выравнивании байтов в буфере. В основном это относится к позиции, в которой новые данные будут храниться в данном буфере. Как это работает? Для буфера с выравниванием по одному байту каждый фрагмент данных записывается в буфер последовательно, причем каждый новый фрагмент данных добавляется непосредственно после предыдущего. Однако буфер с выравниванием по 2 байтам будет записывать каждый фрагмент данных с интервалом в 2 байта, так что даже если ваша первоначальная запись составляет 1 байт данных, следующая запись будет перемещена для выравнивания по двум байтам:

Однако если вы запишете еще один фрагмент данных размером в 1 байт, а затем выполните буфер tell, вы получите смещение в 5 байт (даже если вы записали только 2 байта данных), так как выравнивание добавило данные, чтобы выровнять их с выравниванием буфера в 4 байта.

По сути, это означает, что выравнивание влияет только на то , куда записываются данные, поэтому если после записи чего-либо вы сделаете буфер tell, он вернет текущую позицию записи, которая следует сразу за данными, которые вы записали ранее. Обратите внимание, однако, что если после этого вы запишете еще один фрагмент данных, буфер с внутренней стороны переместит позицию записи на следующую кратную величину выравнивания, прежде чем записать этот фрагмент данных.

Ниже мы приводим несколько примеров использования буферов в проекте:

ПРИМЕЧАНИЕ: Эта функция очень ограничена и предназначена для новичков, чтобы быстро запустить систему контрольных точек, но более опытные пользователи могут предпочесть кодировать свою собственную систему, используя функции File, из-за того, что игра не будет сохранять динамические ресурсы, которые вы можете создавать во время выполнения, такие как структуры данных, поверхности, добавленные sprites и т.д..

Первое, что нам нужно сделать, это создать новый объект для управления сохранением и загрузкой, поэтому создайте его и дайте ему событие Create. В этом событии вы можете разместить следующий код:

SaveBuffer = buffer_create(1024, buffer_grow, 1);
StateSaved = false;

Первая строка создает растущий буфер (поскольку мы не знаем окончательного размера сохраненных данных) размером 1024 байта с выравниванием по 1 байту. Затем создается переменная для проверки, была ли игра сохранена или нет (она будет использоваться для загрузки).

Далее мы добавим событие нажатия клавиш (например, Keypress Event ), в котором мы сохраним текущее состояние игры в созданный буфер:

StateSaved = true;
buffer_seek(SaveBuffer, buffer_seek_start, 0);
game_save_buffer(SaveBuffer);

Теперь мы сохранили текущее состояние игры в буфер. Следующим шагом будет разработка кода для его загрузки, возможно, в другом событии Keypress Event:

if StateSaved
<
buffer_seek(SaveBuffer, buffer_seek_start, 0);
game_load_buffer(SaveBuffer);
>

Игра будет загружена в конце события, в котором вы разместите приведенный выше код.

ПРИМЕЧАНИЕ: Это только для использования в одной комнате, а не для создания полных сохраненных игр после закрытия или перезапуска игры!

Теперь этот объект можно поместить в комнату и по нажатию клавиши сохранить и загрузить состояние комнаты из буфера.

При работе с сетевыми функциями GameMaker Studio 2 необходимо использовать буферы для создания пакета данных, который передается по сетевому соединению. Данный пример призван показать, как это делается, но в связи с широкими возможностями сетевых функций, он предназначен только для демонстрации использования самих буферов, а не всей сетевой системы.

Первое, что мы покажем, это создание и использование буфера для клиентской стороны сетевого соединения. Этот буфер будет использоваться для создания небольших пакетов данных, которые затем могут быть отправлены на сервер, поэтому в событии Create экземпляра мы назначим буфер следующим образом:

send_buff = buffer_create(256, buffer_grow, 1);

Теперь предположим, что мы хотим, чтобы наш клиент отправлял данные на сервер. Для этого нам нужно создать буферный «пакет», и в этом примере мы собираемся отправить событие нажатия клавиши, например, когда игрок нажимает стрелку влево для перемещения по игре. Для этого мы сначала запишем необходимые данные в буфер, а затем отправим их:

buffer_seek(buff, buffer_seek_start, 0);
buffer_write(buff, buffer_u8, 1);
buffer_write(buff, buffer_s16, vk_left);
buffer_write(buff, buffer_bool, true);
network_send_packet(client, buff, buffer_tell(buff));

Перед записью в буфер мы установили «tell» в начало буфера, так как networking всегда берет данные из начала буфера. Затем мы записываем контрольное значение (оно будет использоваться сервером для определения типа обрабатываемого события), затем используемую клавишу, а затем состояние клавиши (в данном случае true для нажатой). Этот буфер затем отправляется сетевой функцией в виде пакета данных. Обратите внимание, что мы не отправляем весь буфер! Мы отправляем только записанные данные, используя функцию buffer_tell для возврата текущей позиции чтения/записи в буфере (помните, что запись в буфер перемещает «tell» в конец того, что было записано). Это делается просто для того, чтобы избежать отправки большего количества байт, чем необходимо.

А как насчет получения данных на сервере? Полученный пакет данных должен быть записан в буфер на сервере и затем использован для обновления игры. Для этого мы будем использовать асинхронное событие Networking в объекте сетевого контроллера сервера, как показано в этом упрощенном коде ниже:

var buff = ds_map_find_value(async_load, «buffer»);
if cmd == buffer_read(buff, buffer_u8);
<
key = buffer_read(buff, buffer_s16);
key_state = buffer_read(buff, buffer_bool);
>

Источник

Немного неудобно, но хочу поговорить о буферах

Просто статья о буферах. Вы наверняка думаете, что знаете о буферах всё. Возможно, так оно и есть. Но мне кажется, вы всё равно найдёте для себя что-то новое. Просто потому, что тема – неисчерпаемая. О буферах всегда есть что сказать.

Это не чушь, и не шутка. Статья действительно о буферах. И она не про буфер обмена. Речь пойдёт о буферах, которые помогают работать лучше.

Не знаю, кто первый придумал использовать буферы в организации работы, но прям использовал это слово и описал, как принцип и кейс – Голдратт в Теории Ограничений.

Еще в первой книге («Цель»), которая написана в жанре бизнес-романа (т.е. это худлит) герои, познав ТОС и влияние буферов, приходят к выводу, что они «ничего такого не делали» — просто работали в соответствии со здравым смыслом. Точнее, прекратили работать как попало, и включили здравый смысл.

Идея использования ограничения и буфера, его защищающего, когда она понята и использована на практике, ничем иным, кроме здравого смысла, уже не кажется.

На самом деле, все мы используем буферы, постоянно. Но делаем это неосознанно. Что интересно – в личной жизни мы пользуемся буферами чаще, чем в работе. Надеюсь, после прочтения статьи вы попробуете перестроить свою деятельность, зная больше о буферах.

Для начала кратко расскажу о трёх видах буферов, которые предлагал сам Голдратт.

Буфер в производстве

Это вообще классика. Представьте, что у вас производство – станки, которые последовательно обрабатывают деталь, пока она не станет готовой продукцией. Один из станков в цепочке является ограничением – бутылочным горлышком, звеном цепи с самой низкой производительностью. Производительность всей линии определяется производительностью этого ограничения.

На самом деле, производительность линии обычно ниже, чем может фигачить ограничение. Потому что ограничение не защищено, и не работает на своей максимальной мощности, по одной простой причине – ограничением управляют так же, как всеми остальными станками. И проблемы у него те же – например, простои по вине предыдущих этапов цепи.

Решение предлагается простое, как дрова – создать перед ограничением буфер. Перестроить линию так, чтобы ограничению всегда было, чем заняться, и оно не простаивало.

У этого буфера будет забавный способ измерения, но его важно понять. Потому что их два – количество и время. С одной стороны, это может быть сто заготовок. С другой стороны, сто заготовок – это четыре часа работы станка-ограничения.

Время – более универсальная характеристика, т.к. она понятна без знания производительности. Можно просто, без изысков и с полным здравым смыслом сказать: ограничение защищено на четыре часа. Или – у него буфер времени в четыре часа.

Что бы там ни случилось до ограничения, есть четыре часа на исправление – и за это время производительность линии не снизится.

Буфер в снабжении

Примерно то же самое, только ещё проще. Вообще, буферы в снабжении были любимой темой Голдратта в собственной практике, он внедрял их в рознице. Говорил, что там минимум усилий и максимум результата. А его компания брала процент от увеличения выручки после внедрения ТОС.

Так вот, буфер в снабжении – это держать на складе столько единиц товара, чтобы хватило до следующей поставки. Логично до противного.

И чувствуете – сразу в формулировке буфера заложено две единицы измерения? И количество единиц, и время – до следующей поставки. Хочешь уменьшить буфер – увеличивай частоту поставки. Ну и привози ровно столько, чтобы свой буфер пополнить.

Буфер в данном случае тупо защищает от дефицита – отсутствия товара в тот момент, когда он необходим – неважно кому, собственному цеху завода или очередному покупателю пива.

Буфер в проектах

В проектах Голдратт ставит простую цель – уложиться в срок без снижения качества и увеличения стоимости. Прям как в рекламном буклете.

Что защищать в проекте? Недолго думая, Голдратт предлагает защищать критический путь – цепочку этапов или задач, которая определяет конечный срок выполнения проекта. Если учились в ВУЗе достаточно давно, то помните – нас всех заставляли этот критический путь рассчитывать.

Голдратт чуть расширил понятие критического пути, назвав его (а заодно и книгу) критической цепью. Углубляться в детали не буду, если захотите – почитаете, но цепь отличается от пути динамическим перестроением, т.е. ключевая последовательность этапов может меняться в ходе выполнения проекта.

Где тут воткнуть буфер? Примерно этим вопросом задавались герои книги – они вроде уже знали ТОС, но не понимали, как его применить в проектах. Потом догадались – буфер уже сидит во всех оценках времени исполнения этапов и задач. Каждый программист, аналитик, менеджер, оценивая свои этапы, заложил туда буфер.

Если память не изменяет, Голдратт утверждал, что все, как один, заложили буфер размером процентов в 90%. Но никто не хотел в этом признаваться, потому что оценки выполнения проектов не поддаются регламентации, и делаются «по опыту», который у всех обычно трудный.

На реальное выполнение каждого этапа проекта нужно примерно 10% времени, которое на него заложено. Это время, когда прям что-то делается, а не планируется или анализируется. А дальше просто – никто же толком не умеет укладываться в сроки и планировать свою работу. Имея запас времени, десятикратно превосходящий трудозатраты, всё равно все опаздывают, потому что начинают не вовремя (в книге это названо «синдром студента»).

Ну Голдратт и говорит – парни, хорош. Давайте мы все ваши буферы вытащим из оценок, суммируем и поместим в конец проекта. Никаких локальных буферов, только один общий – на весь проект. Точнее, на его критическую цепь.

Прям все буферы ему, конечно, не отдали, но в 2-3 раза свои оценки урезали. Заодно и срок проекта в 2-3 раза сократился, потому что в общий буфер пошла не вся сумма, а её разумная и объяснимая часть – начальство не согласилось на очень уж большой запас времени.

Всем парням сказали – не ориентируйтесь на сроки, просто делайте. Как можно скорее, но без увеличения стоимости или снижения качества. По сути, сказал ориентироваться не на плановую дату завершения, а на дату начала. Ну и всё заколосилось.

В критической цепи буфер защищает срок выполнения проекта.

От чего защищает буфер?

Если обобщить, то – от необходимости срочно вмешиваться и что-то мудрить. Голдратт это называл «внимание руководства», и рисовал график, который говорил – если буфер времени слишком короткий или слишком длинный, то внимания потребуется много.

А что есть внимание руководства? Зависит от ситуации, но этим руководством вполне можете быть вы. Например, если будете покупать продукты на приготовление только одного обеда – вам придётся бегать в магазин трижды в день. А если накупите на год вперёд, то намучаетесь с хранением и инвентаризацией сроков годности. В обоих случаях такой простой процесс, как продукты, будет занимать намного больше вашего времени, чем хотелось бы.

На работе типичный пример – ручное управление задачами. Это когда есть начальник, который целыми днями только и делает, что раздаёт поручения, контролирует их исполнение, запрашивает информацию и т.д. Если все его задачи срочные и важные, со сроком исполнения 1 час, то он будет буквально стоять над душой. Если сроки измеряются в месяцах или годах, то всё время уйдёт на освежение памяти подчиненных – кто всю эту чушь долгоиграющую запомнит?

Посмотрим на более приземленные примеры буферов.

Буфер недельных закупок

Простой пример из жизни – закупки на неделю вперед. Наверное, большинство из нас пользуется таким буфером. Опять же, заметьте – тут и количество, и время. Мы покупаем ровно столько еды, сколько нам надо на неделю.

Если купим меньше, то придётся часто бегать в магазин – потратим время и деньги, т.к. в магазине около дома цены несколько выше. Если купим больше, то половину выбросим, или придётся купить второй холодильник.

Буфер недельных закупок защищает нас от геморроя. Можно всю неделю жить, не переживая о питании, а внимание к этому процессу требуется на понятный отрезок времени в один из выходных дней.

Буфер – техподдержка

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

Я раньше работал на заводах и, пока штат ИТ был маленький, проблему отсутствия буфера особо не ощущал. Ну, мешают мне звонки и сообщения в скайпе – я просто не брал трубку и не отвечал. Кому сильно надо – прибежит. И услышит, что я занят.

А когда штат вырос, продолжал действовать по инерции, никак не деля роли в команде. В результате рваная, непонятная, непредсказуемая нагрузка была у всех без исключения. Тут только допёрло, что буфер нужен – отдельный человек, который занимается только поддержкой. И всё, геморрой как ветром сдуло. А заодно – и требование к моему вниманию, чтобы постоянно разруливать срочные задачи, перемешанные с нормальной разработкой.

Человек на техподдержке стал буфером, защищающим развитие ИТ-систем.

Буфер – поменьше говорить

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

А я идею сказал и забыл. Через час – передумал. Через два придумал другую идею, противоположную первой. Ну или развивающую первую. В общем, ничего я реализовывать не хочу.

Но начальство настаивает, потому что я «базаром писанулся». В результате таких ошибок я несколько раз попадал на реализацию проектов, которые сам считал бессмысленными. Ну и выработал простое правило – молчать.

Молчание стало буфером, защищающим меня от самого себя. Если обсуждается проблема не моя, а чья-нибудь, или какая-то общая, то можно высказывать всё, что угодно. Если же речь о работе моей или моего подразделения, то говорить можно и нужно лишь о том, что уже сделано, или находится в процессе реализации.

Хочешь что-то изменить – измени. Но не надо никому об этом рассказывать, пока не сделал. Такой примерно буфер. Защищает прям сильно.

Буфер коммуникаций

С одной стороны, электронные способы коммуникации, вроде, призваны ускорить процесс. Поднял трубку, набрал номер, и можешь тут же поговорить с человеком на другом краю Земли. Или написал сообщение, и тут же получил ответ.

Но сейчас тренд другой – пешком быстрее. Электронные коммуникации, особенно почта, стали реальным таким буфером, ограждающим от слишком назойливых любителей получить ответ сию минуту (привет, менеджеры). Трубку можно не брать, на письмо не отвечать, только гадкие мессенджеры рисуют свои две галочки.

Мне нравятся эти буферы. Они позволяют не тратить моё «внимание руководства», которого и так мало. А кому сильно надо – всё равно найдёт, как связаться.

Бюрократический буфер

Это прям классика из классик. Особенно, если речь про чиновников. Все регламенты работы, написанные бюрократами – это буферы, смягчающие удары и, собственно, от них защищающие.

В каждом приличном регламенте есть вход, какие-то действия, ответственные за их выполнение и, главное, срок исполнения. То самое время, в котором и измеряется буфер. Благодаря этому буферу можно, и нужно не подпрыгивать на каждое обращение, а чинно, спокойно, по всей форме ответить на обращение. Если ответ не устроит – будет второй буфер на второй ответ. И так далее, до бесконечности.

Бюрократические буферы создаются системами для самозащиты. От кого? От нас или от вас, смотря с какой стороны вы находитесь.

Буфер ценностей

Одна из разновидностей бюрократии, обычно скрывающаяся под соусом ценностей, моральных принципов, корпоративной культуры и любви к клиентам. Чаще всего встречается у туповатых менеджеров.

Проявляется обычно в ситуациях, которые выходят за рамки типовых, знакомых, отработанных. В таких случаях, увы, надо думать, искать необычное решение, иногда творческое, работать с конфликтами. Это сложнее, чем выставлять счета на оплату или согласовывать служебки.

Поэтому человек не делает то, чего требует ситуация, но надо же как-то объяснить свою позицию. На помощь и приходят фразы из буфера, который есть в большинстве более или менее крупных компаний.

Например, прикрывается модной клиентоориентированностью, когда клиент сел на шею и хочет услуг на миллион, заплатив тысячу. Менеджер обычно процент с продаж получает, и по соотношению усилия-результат тысяча намного лучше миллиона. Тем более, что процент заплатят только после подписания акта. Наверняка, в этой ситуации менеджер и синицу в руках упомянет.

Любят буфер ценностей и высшие менеджеры. Например, про лояльность компании. Особенно, когда надо поработать в выходные, или зарплату уменьшить, ибо кризис, а на чём же ещё экономить, если не на зарплате сотрудников.

Правда, в кризис не упоминается буфер, который те же высшие менеджеры создать забыли – например, для выплаты зарплаты, портфель проектов или, на крайний случай, несколько постоянных лояльных клиентов.

Но это уже немного другая история – буферы, про которые мы не думали. Хотя, последние месяцы наглядно показали, кто думал о защите, а кто – об удобных ценностях.

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

Теперь, поняв принцип, хочу почитать ваши варианты буферов. Если они будут про программистов или их менеджеров – прям вообще хорошо будет. Заранее спасибо.

Источник