Работа с файлами или с людьми -- может проще дать по рукам?

[arthur2]

Ну, 1) не принципиально - в данном случае нужна, собственно, простенькая защита от правки в блокноте, так что даже поля мусора в моей структурке -и то лишние.

Второй пункт в моем примере решен:

Код: Выделить всё

Private Sub getQuestFromFile(nF As Integer, v As victorina, nQ As Long)
Dim adr As Long
' в начале файла храним массив смещений
Get #nF, nQ * 4 + 1, adr 'читаем смещение к структурке номер такой-то
Get #nF, adr, v 'читаем саму структурку

End Sub

А третий и четвертый пункты - убедительно. Особенно третий

И всё же, у моего подхода есть одно преимущество - реализовать его намного проще

[Хакер]

Второй пункт в моем примере решен:

И всё же, у моего подхода есть одно преимущество - реализовать его намного проще

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

[iGrok]

Чем тогда твоё проще?

Чисто по реализации.

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

Кода писать придётся намного меньше. Но избыточность хранимой информации зашкаливает.

UPD:
При этом все форматы хранения задаются структурами. И при чтении доступны сразу как структуры.
По сути среднее между твоим способом, и тупой сериализацией массива, содержащего полный набор вопросов/ответов. У него много преимуществ перед двумя другими (простота реализации, но нет необходимости читать сразу всё - можно вытащить нужную запись), но остаётся минус с избыточностью хранимой информации.
При этом угадать, где там номер ответа всё равно достаточно сложно.

UPD2: Ну и плюс это всё-таки только формат хранения редко изменяемой инфы. Изменение файла остаётся крайне сложным и невозможно без полной переупаковки, либо добавления избыточности. В этом плане твой формат рулит безбожно.

[arthur2]

Хакер Естественно, это шаг в направлении твоего подхода, но без него никуда... Второй пункт, как-никак - самый весомый. И всё-таки, это не очень сложно - при чтении практически добавилась лишь одна строчка кода. Создание такого файла - тоже не очень сложно.

Хорошо бы решить ещё и третий пункт... но это уже практически в шаге от твоего варианта. Причем, простоту моего подхода мы уже потеряем, а от недостатков до конца так и не избавимся (останется 4 пункт, который с моем варианте вообще не решаем)

У меня в одном проекте есть сложно устроенные файлы - там я пользуюсь скорее твоим подходом: все строки лежат отдельно, а в структурах вместо строк - смещения и длины. Но сами стркутурки я читаю по своему варианту

iGrok А в чём большая избыточность? если, конечно, не считать того, что строки могут дублироваться?

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

А это действительно сильный аргумент!

[MIT]

Изменение файла остаётся крайне сложным и невозможно без полной переупаковки

Тут можно ненадолго включить моск.
Вообще я сталкивался с подобными системами, правда для хранения огромного (нереально огромного от 20к) количества блоков бинарной информации (если быть точнее - файлов), но то, что храниться - не суть. Суть в правильном построении структуры хранения. Приведу краткую схему обрабатываемой базы данных и функционал класса для работы с ней.
Структура
1) Заголовок; Некоторая системная информация; Количество записей
2) (Структура расположения данных) * Количество записей (причем сама структура фиксированной длины, и в самом простом случае она содержит идентификатор записи, его абсолютную (или относительную к началу блока перечисления структур) позицию и длину. Стоит отметить, что и позиция и размер - 32-битные числа, а что бы была возможность хранить файлы больше 2 гб как размер, так и позиция делятся на минимальный размер блока данных, который может быть как 512байт, так и 1мб - это не важно)
Исходя из этого мы имеем возможность получить прямой доступ к любому элементу таблицы, просто вычислив ее положение, и соответственно считать необходимую информацию о хранимых бинарных данных
3) (Бинарные данные) * Количество записей (размер данных должен быть кратен размеру минимального блока, "лишнее" место заполняется нулями)

Зная индекс элемента тут легко получить его бинарные данные.

По поводу изменения
Применяется система, аналогичная файловой системе:
Если надо перезаписать какой-то блок, то смотрим, если новый размер меньше старого, то смело перезаписываем, изменяя размер в таблице, а если больше - пишем новые данные в конец, меняя в таблице позицию и размер.
Удаление - или перемещение последнего элемента таблицы на место удаленного или сдвиг всей таблицы.
Добавление - изначально под таблицу выделяется некоторое пространство из расчета на то, что она может пополняться (или убавляться), следом за ней идут данные. Если при добавлении нового элемента новая запись в таблице "наедет" на бинарные данные, то просто перемещаем первый "файл" в самые конец, изменяя соответствующие данные в таблице (т.е. положение), а освободившееся место мы может спокойно занимать.

Функционал
Помимо вполне понятных - считать, добавить, изменить, удалить, извлечь/"скопировать в" и пр. необходима процедура дефрагментации файла.


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

[iGrok]

Изменение файла остаётся крайне сложным и невозможно без полной переупаковки

Тут можно ненадолго включить моск...

MIT, я вообще-то имел в виду недостаток конкретного способа работы с файлом, относительно подробно описанного в моём же посте и нескольких постах arthur2. А то, о чём ты говоришь можно реализовать и проще, если работать исключительно в рамках способа, описанного Хакером. И вообще, мы ФС пишем, или формат хранения БД для теста?

iGrok А в чём большая избыточность? если, конечно, не считать того, что строки могут дублироваться?

SAFEARRAY, заголовки строк. При наличии множества мелких строк - это офигенный лишний вес.

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

А это действительно сильный аргумент!

Ну не такой уж и сильный. Тебе нужно каждые пять минут менять БД теста?
Изменение элемента будет выглядеть как дописывание элемента в конец файла, и правка указателя. При этом старый вариант элемента останется лежать мёртвым грузом внутри файла, и убъётся только при "переупаковке" (оптимизации, "сжать и восстановить", по аналогии с Access). Удаление - просто удаление указателя из массива, добавление - в конец файла + добавление строки в массив указателей.

UPD:
Изменение порядкового номера записи - вообще элементарно. Меняется массив указателей.
Тут, правда, есть ещё один подвох. Скорей всего для простоты работы с файлом(изменения) придётся сам заголовок писать в конец файла, а в начало складывать смещение на него. Либо выделять под "рост" заголовка фиксированное БОЛЬШОЕ простарнство. Это ещё один камень в "избыточность".
Естественно, есть и другие варианты.

[MIT]

MIT, я вообще-то имел в виду недостаток конкретного способа работы с файлом, относительно подробно описанного в моём же посте и нескольких постах arthur2. А то, о чём ты говоришь можно реализовать и проще, если работать исключительно в рамках способа, описанного Хакером. И вообще, мы ФС пишем, или формат хранения БД для теста?

Да я ничего, я просто свое видение реализации изложил

Изменение элемента будет выглядеть как дописывание элемента в конец файла, и правка указателя. При этом старый вариант элемента останется лежать мёртвым грузом внутри файла, и убъётся только при "переупаковке" (оптимизации, "сжать и восстановить", по аналогии с Access). Удаление - просто удаление указателя из массива, добавление - в конец файла + добавление строки в массив указателей.

UPD:
Изменение порядкового номера записи - вообще элементарно. Меняется массив указателей.
...

Мне кажется, или я постом выше написал то же самое?

[iGrok]

Мне кажется, или я постом выше написал то же самое?

Кажется. )
Очень похоже, но существенные различия есть. )

[Лаборатор]

Все конечно, крассиво, но реальный проект предложил только arthur2 и его все раскритиковали.
Может оно и правильно, но сам я такого не напишу.
Хотелось бы конкретного кода!
Особая надежда на Хакера, поскольку, кажется, что он знает больше, чем говорит...
Хранить отдельно в одном файле вопросы, в другом ответы, в третьем-правильные номера - неужели это ускорение работы?
Надо ведь открыть 3 файла вместо 1!!!
Да и потом, я уже говорил, что полностью загружать базу в массив слишком долго на старых компах!
Более того, шифровать надо все и вопросы и ответы и номера, как бы глупо это не звучало... Ну надо!!!

[Хакер]

Вообще-то я первым предложил правильное и самое простое (без лишних действий) решение. iGrok потом несколько раз на него ссылался.

[arthur2]

Хакер ты предложил, на сколько я помню, правильный принцип. Но не решение. И - в плане кода - не самое простое.

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

Лаборатор Где ты увидел, что меня сильно раскритиковали? Просто показали недостатки моего подхода. Которые для твоей задачи - совершенно не существенны. Избыточность? Ну, может и будет заметна, если перевалить за пару сотен мегов Сложность редактирования? iGrok показал, как это довольно легко обойти, если вдруг всё-таки понадобится.

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

В общем мой примерчик - это почти готовое решение для тебя. И если оно кажется тебе слишком сложным, то уж решение Хакера точно сложнее

iGrok

SAFEARRAY, заголовки строк. При наличии множества мелких строк - это офигенный лишний вес.

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

А если ещё усложнить и раздельно хранить вопросы с ответами (чтобы можно было отдельно их читать), то уже совсем будет рукой подать до варианта Хакера

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

[iGrok]

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

А если ещё усложнить и раздельно хранить вопросы с ответами (чтобы можно было отдельно их читать), то уже совсем будет рукой подать до варианта Хакера

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

Если ты исключишь SAFEARRAY - тебе придётся руками грузить заголовок файла.
Далее. Давай определимся с форматом.

Я его сейчас себе представляю так ([offset:length=description]):
[0:4=Signature][4:4=Header Offset][8:...=DATA][Header Offset:Header Length=Header]
Data Size = Header Offset - 8 (логично?)
При этом в начала всегда - сигнатура (просто для приличия). За ней всегда смещение на заголовок. За ней, с 8го байта - данные.
При этом Header - это структура, содержащая информацию о файле, и массив смещений на структуры с вопросами в области данных (DATA).

Сначала читается сигнатура, потом считывается структура-заголовок по адресу Header Offset.
Получаем за один шаг список номеров и адресов вопросов.

Потом берётся адрес вопроса с нужным номером, и читается структура - вопрос.
В ней могут быть, в принципе, любые поля..

Если так, то при чём тут "хранить вопросы массивом", если они вообще хранятся в отдельных структурах?
Да и разбитая нулями строка требует времени на обработку. Т.е. нужно искать нули в строке, чтобы понять где тут следующий элемент. А тут мы обратно упираемся в то, что алгорим должен давать приемлемую производительность на 486м.

[arthur2]

([offset:length=description]):
[0:4=Signature][4:4=Header Offset][8:...=DATA][Header Offset:Header Length=Header]
Data Size = Header Offset - 8 (логично?)

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

при чём тут "хранить вопросы массивом"

Обчипятался Хотел сказать: если в структурке хранить ОТВЕТЫ не массивом, а одной, разбитой нулями строкой
Было:

Код: Выделить всё

type victorina
    vopros as string
    otvety() as string' вместо этого массива (массивчика)
    nOnveta as byte
end type

Предложил, дабы избавиться от одного SAFEARRAY на каждый вопрос:

Код: Выделить всё

type victorina
   vopros_onvety as string 'одну разбитую нулями строку :)
   
' А номер ответа, чтобы запутать но сильно не изгаляться, предлагаю хранить так:
   nB as byte 'номер произвольного байта в строке-вопросе
   nK as byte 'сколько от того байта отнять, чтобы получился номер правильного ответа :)
end type

Строка будет не очень длинная, так что даже на слабой машине и даже split-ом распарсится вполне быстро
И всё-таки вопрос экономии места, вроде бы, не стоял, так что я бы оставил массивом - будет и быстрее, и удобнее. Да и сэкономится-то не так уж много, от силы процента три.

Получаем за один шаг список номеров и адресов вопросов.

А зачем? массив адресов - это же лонги, каждый по 4 байта, так что мы просто в любой момент можем посчитать, где лежит адрес номер такой-то. Весь массив читать не обязательно У меня в примеретак и было.

Читать массив адресов нужно, только если надо редактировать файл. Кстати, если забить-таки на редактируемость, то можно получить ещё одно удобство: скажем, хотим загрузить не один вопрос, а сразу с 10 по 20. Создаем массив структур, редимим его в (1 to 20-10), и читаем с позиции десятого адреса: вуоля! загрузилось сразу 10 структурок

[iGrok]

([offset:length=description]):
[0:4=Signature][4:4=Header Offset][8:...=DATA][Header Offset:Header Length=Header]
Data Size = Header Offset - 8 (логично?)

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

Гм. Нету такого способа. Я его только что тут на месте за 5 секунд придумал, чтобы была хоть какая-то наглядность... Видимо, зря велосипед изобретал. Да и ладно, фиг с ним, с форматом.

Всё остальное более-менее понятно, просто получается ещё больший уклон в сторону простого формата хранения, описанного Хакером. )

Один момент:

Создаем массив структур, редимим его в (1 to 20-10), и читаем с позиции десятого адреса: вуоля! загрузилось сразу 10 структурок

Я, честно говоря, сомневаюсь, что это будет работать. А проверять сейчас некогда. Просто структуры-то у нас чёткого размера не имеют, и не факт, что таким способом всё будет прочитано правильно. Впрочем, можно проверить.

[[LEV&n]]

Доброго времени суток!
Тут у меня нарисовалась проблема, мож есть у кого мысли...
Короче, програмка у меня должна работать с компами очень древними (от 486 (помните еще такие) до P3-400), и она должна подгружать инфу из тестового файла(много инфы!!!!), короче даже при простом обращении (через оператор Open), при попытке полностью загрузить файл компы долго думают, ну я придумал алгоритм, как подгружать ее частями, дал файлам новое расширение - чтобы юзеры не лезли в них, но основа то всервно текстовая!!! Вот и чувствую, что текст то изменяют.
Короче надо запаролировать, но как, посимвольный XOR грузит полумерттвые машины, да и частичная подгрузка не работает, я ведь бил файл по строкам, а после кодирования - одни цифры.
Мож кто еще методы кодирования знает(не сильно грузящие комп), или алгорим работы с другим типом более "легких" файлов(у каждой программый ведь свой формат), хотя куда уж легче, чем Dos-текст!
HELPPPPPPPPPP!Я идиот! Убейте меня, кто-нибудь!Я идиот! Убейте меня, кто-нибудь!Я идиот! Убейте меня, кто-нибудь!Я идиот! Убейте меня, кто-нибудь!!

Существует некий шифровщик-дешифровщик, я его использовал в своей программе, кстати тоже тестер и тест-билдер в комплекте, можете посмотреть Global Poll

Так вот, программа очёнь лёгкая и алгоритм маленький, не сильно нагружает систему, впрочем смотрите:

[arthur2]

Всё остальное более-менее понятно, просто получается ещё больший уклон в сторону простого формата хранения, описанного Хакером. )

Ну да, так и есть Мой способ имеет некоторые недостатки, избавление от которых приводит во концовке к способу Хакера. Но и к потере простоты использования.

Про массив структур с произвольного места:

Я, честно говоря, сомневаюсь, что это будет работать.

Будет-будет (для очистки совести проверил). Массивы любых элементов, если они не внутри структуры, сохраняются без заголовков путём простого записывания подряд своих элементов, и так же читаются.

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

Кстати, и с массивом лонгов-адресов так же: можно высчитывать положение и брать только определенный адрес, а можно сразу прочитать весь массив. На сколько массив проредимишь, столько элементов и прочитается. Нужно, правда, хранить ещё и количество элементов (иначе, если выйдем за диапазон, или прочитаем какой-нибудь мусор, или - для структур - вылетим с ошибкой)

[LEV&n]Ага, ништяк... только в архиве нет ни модуля, ни формы

[iGrok]

Будет-будет (для очистки совести проверил). Массивы любых элементов, если они не внутри структуры, сохраняются без заголовков путём простого записывания подряд своих элементов, и так же читаются.

Ты проверял именно с массивом UDT, содержащих строки / массивы?

[arthur2]

Да, проверял со структурой, содержащей массив строк

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

Пусть myMassiv - массив пользовательского типа любой степени навороченности. Тогда:

Код: Выделить всё

for i=0 to ubound(mymassiv)
    put #f,,myMassiv(i)
next

и

Код: Выделить всё

put #f,,myMassiv

Приводят к созданию абсолютно одинаковых файлов
Поэтому

Код: Выделить всё

redim myMassiv(ub)
for i= 0 to ub
     get #f,,mymassiv(i)
next

и

Код: Выделить всё

redim myMassiv(ub)
get #f,,mymassiv

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

[dormouse]

Я поддержу Хакера, что вопросы надо держать отдельно от ответов. Это правильный подход к реализации любой базы данных.
А про защиту тектовых строк в этой базе у меня есть такое предложение, намёк на который уже был тут
Но надо не шифровать строку, а получать хэш от неё (желательно необратимым алгоритмом) и писать его тут же в этой записи, в другом поле. При чтении строки базы, сверяться с хэшем, и при несовпадении устраивать шум, что база злостно модифицирована.

[trash]

Что помешает пересчитать и переписать хеш?

(желательно необратимым алгоритмом)

Вообще-то смысл хеширования как раз в необратимости.
PS. Сподобился прочитать тему сначала. Примерно до середины) Если это компьютерный класс в учебном заведении, то рекомендую найти хотя бы один более-менее приличный комп, поднять на нем веб или какой-нибудь свой сервер, к которому будет обращаться остальной хлам за вопросами и отправлять ответы.

[Andrey Fedorov]

С таким вариантом частичная подгрузка точно не будет работать.

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

Да уж... А может все-же все в mdb-шку засунуть?

[dormouse]

Что помешает пересчитать и переписать хеш?

знание алгоритма и ключа шифрования
И для данного уровня задачи, вообще, не требуется что-то делать особо секретным, как я понял. Надо просто защитить базу от исправлений и возможности быстрого сопоставления вопросов-ответов. Кстати, если использовать структуру базы Номер_вопроса|Вопрос|хэш; Ответы|Индекс|хэш; Индекс|Номер_вопроса (со смещением), то в хэш надо бы включить оба поля. Тогда ещё и нельзя будет изменить количество записей в базе

[trash]

dormouse, для хеширования не нужен ключ. http://ru.wikipedia.org/wiki/%D0%A5%D0% ... 0%B8%D0%B5

[dormouse]

dormouse, для хеширования не нужен ключ. http://ru.wikipedia.org/wiki/%D0%A5%D0% ... 0%B8%D0%B5

может быть, я перепутал терминалогию... Хэш получает в качестве слова и ключа два соседних блока текста (поэтому ему не нужен какой-то сторонний ключ). Проводит над ними вычисление какой-то необратимой функции и результат использует в качестве ключа для следующей итерации. Суть в том, что получается сравнительно ооооочень короткая строка, в которой "упакована" длииииная строка. Обратно получить длинную невозможно, а чтобы опять (при попытке подделки) получить туже самую короткую, надо иметь в точности такую же длинную, какая была до шифрования. Я предлагаю на первой итерации цикла использовать не второй блок текста, а ключ, известный только программе. Суть предложения понятна? Теперь её можно назвать как угодно. Заранее извините за изобретение велосипеда

[arvitaly]

Что помешает пересчитать и переписать хеш?

Школьникам?

[iGrok]

Что помешает пересчитать и переписать хеш?

Школьникам?

Ты плохо знаешь школьников, как я погляжу...

[trash]

Что помешает пересчитать и переписать хеш?

Школьникам?

Ты плохо знаешь школьников, как я погляжу...

Достаточно одного головастого, чтобы эксплойт появился у всех

[Лаборатор]

Вообще-то я первым предложил правильное и самое простое (без лишних действий) решение. iGrok потом несколько раз на него ссылался.

Может я неправильно задал вопрос?
Надо паролировать все - и вопросы и ответы и номера ответов!!!(вопросов не более 50!)
Столько дискуссий, насчет правильности того или иного метода, а примеров нет!
Не понятно же! Я не настолько продвинутый, как Вы, поэтому и написал в разделе для начинающих пользователей!

[Лаборатор]

Доброго времени суток!
Тут у меня нарисовалась проблема, мож есть у кого мысли...
Короче, програмка у меня должна работать с компами очень древними (от 486 (помните еще такие) до P3-400), и она должна подгружать инфу из тестового файла(много инфы!!!!), короче даже при простом обращении (через оператор Open), при попытке полностью загрузить файл компы долго думают, ну я придумал алгоритм, как подгружать ее частями, дал файлам новое расширение - чтобы юзеры не лезли в них, но основа то всервно текстовая!!! Вот и чувствую, что текст то изменяют.
Короче надо запаролировать, но как, посимвольный XOR грузит полумерттвые машины, да и частичная подгрузка не работает, я ведь бил файл по строкам, а после кодирования - одни цифры.
Мож кто еще методы кодирования знает(не сильно грузящие комп), или алгорим работы с другим типом более "легких" файлов(у каждой программый ведь свой формат), хотя куда уж легче, чем Dos-текст!
HELPPPPPPPPPP!Я идиот! Убейте меня, кто-нибудь!Я идиот! Убейте меня, кто-нибудь!Я идиот! Убейте меня, кто-нибудь!Я идиот! Убейте меня, кто-нибудь!!

Кто поглумился над моим сообщением? Самим не противно выставлять человека дураком?

[Хакер]

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

И у нас вообще-то нет раздел для начинающих.

ОК. Пример чего ты хочешь получить? Только не говори, что пример всего.