Я недавно понял, что совершенно не понимаю зачем нужна сериализация. Т.е. не то, чтобы совсем не понимаю... Ну вот смотрите: сериализация — это прямой перевод структур данных в бинарный вид. Если структура данных поменялась в новой версии программы, значит старый вариант уже работать не будет. Т.о. передачи или сохранение сериализованных данных имеет крайне узкую область применения. Однако, очень многие пишут сериализацию и как существуют даже целые библиотеки под эту функциональность. Зачем так делать?

Здравствуйте, B0FEE664, Вы писали:

BFE>Я недавно понял, что совершенно не понимаю зачем нужна сериализация. Т.е. не то, чтобы совсем не понимаю... Ну вот смотрите: сериализация — это прямой перевод структур данных в бинарный вид. Если структура данных поменялась в новой версии программы, значит старый вариант уже работать не будет. Т.о. передачи или сохранение сериализованных данных имеет крайне узкую область применения. Однако, очень многие пишут сериализацию и как существуют даже целые библиотеки под эту функциональность. Зачем так делать?

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

Здравствуйте, icWasya, Вы писали:

BFE>>Я недавно понял, что совершенно не понимаю зачем нужна сериализация. Т.е. не то, чтобы совсем не понимаю... Ну вот смотрите: сериализация — это прямой перевод структур данных в бинарный вид. Если структура данных поменялась в новой версии программы, значит старый вариант уже работать не будет. Т.о. передачи или сохранение сериализованных данных имеет крайне узкую область применения. Однако, очень многие пишут сериализацию и как существуют даже целые библиотеки под эту функциональность. Зачем так делать?

W>Как раз сериализация — это не прямой перевод в бинарный вид.
Если это так, то чем она отличается то записи ini-файла?

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

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

Здравствуйте, B0FEE664, Вы писали:

BFE>Я недавно понял, что совершенно не понимаю зачем нужна сериализация. Т.е. не то, чтобы совсем не понимаю... Ну вот смотрите: сериализация — это прямой перевод структур данных в бинарный вид. Если структура данных поменялась в новой версии программы, значит старый вариант уже работать не будет. Т.о. передачи или сохранение сериализованных данных имеет крайне узкую область применения. Однако, очень многие пишут сериализацию и как существуют даже целые библиотеки под эту функциональность. Зачем так делать?

Для вашего случая — можно написать upgrade.

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

В нашей программе есть структура, мы её хотим отправить по HTTP другой программе? Обычно структуру сереализуют в JSON и на другом конце JSON десереализуют обратно.

Задача сериализации — она обыденная.

Здравствуйте, minorlogic, Вы писали:

M>СТО

Популярно объясняют:

https://www.youtube.com/watch?v=N4phAOorG-A

Здравствуйте, B0FEE664, Вы писали:

BFE> Я недавно понял, что совершенно не понимаю зачем нужна сериализация. Т.е. не то, чтобы совсем не понимаю... Ну вот смотрите: сериализация — это прямой перевод структур данных в бинарный вид. Если структура данных поменялась в новой версии программы, значит старый вариант уже работать не будет. Т.о. передачи или сохранение сериализованных данных имеет крайне узкую область применения. Однако, очень многие пишут сериализацию и как существуют даже целые библиотеки под эту функциональность. Зачем так делать?
Потому что слово serialize это от слово serial, т.е. перевод произвольной структуры данных в последовательную цепочку бит. А куда потом это дело пойдёт — в сокет, по serial порту или на диск в виде файла — дело десятое.
Совместимость версий потока бит вещь опциональная, но обычно очень полезная, поэтому во многих библиотеках нередко встречается.
Притом сохранение (или даже передача) структуры данных не всегда делается сериализацией. Например, можно данные сохранить в виде записей в таблицах СУБД или подветке реестра. А проблемы с версиями те же...

Здравствуйте, lazy/cjow/rhrr, Вы писали:

LCR>Я не понимаю Теорию Категорий

Вот самая простая книга по теории категорий:
Lawvere F. W., Schanuel S. H. Conceptual mathematics: A First Introduction to Categories
Взгляните еще сюда
Я сам просмотрел по диагонали более сложные книги, поэтому что-либо объяснить не смогу.

Здравствуйте, Dair, Вы писали:

D>Для меня загадка — современные алгоритмы шифрования (криптографии). Мат.аппарата не хватает

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

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

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

Различные виды шифрования используют разные комбинации этих методов итеративно (например, 32 раза в одном из популярных алгоритмов), каждая итерация — это плюс 1 к степенной N в оценке O^N*K*L ресурсов, необходимых на взлом, где К — длина ключа, L — некая исходная характеристика алгоритма (+ конкретных таблиц подмены).

Вот хорошее описание популярной "механики" над битами в процессе шифрования:
ГОСТ 28147-89

DES/AES используют примерно те же шаги.

У нас были алгоритмы, подобные AES, еще в 92-м году (т.е. раньше, чем был опубликован AES). Довелось общаться с разработчиками этого алгоритма на конференции, обменивались идеями о его аппаратной реализации. Но конечные версии этих алгоритмов остались закрытыми для широкой публики, использовались (не знаю как сейчас) в секретной связи и военке. Наработки когда-то отдали в военный ВУЗ, последний раз я о них слышал в 93-м году как о законченном алгоритме, т.е. всё еще на 5 лет раньше выхода AES. ))

Прикольно, что самый простой вид шифрования на сегодня является самым надёжным:
https://ru.wikipedia.org/wiki/%D0%A8%D0%B8%D1%84%D1%80_%D0%92%D0%B5%D1%80%D0%BD%D0%B0%D0%BC%D0%B0
но он неприемлем из-за сложностей в организации надёжной инфраструктуры.

Именно из-за требований к "обычной" инфраструктуре получили распространения менее криптонадежные алгоритмы, типа public/private key, зато более практичные. Для сравнения, на сегодня симметричные системы считаются надежными от 128 бит, а несимметричные от 1024 бит (и то, поговаривают, что это слишком оптимистичная оценка).


D>На практическом уровне — public key/private key понятно, но чо там внутри — чисто магия.

Если сосредоточиться только на сути получения public key/private key, то никакой магии, у одной стороны есть свой приватный полу-ключ 1 и чужой публичный полу-ключ 2, у другой стороны есть публичный 1 и приватный 2. Есть алгоритм, который порождает одинаковый ключ шифрования К из обоих вариантов {pub1, pri2} и {pri1, pub2}. Далее идёт терминологическая путаница, потому что именно полученный К является тем самым ключом шифрования. А в "базе" несимметричных алгоритмов сидит какая-нить разновидность симметричного.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>>>Я недавно понял, что совершенно не понимаю зачем нужна сериализация. Т.е. не то, чтобы совсем не понимаю... Ну вот смотрите: сериализация — это прямой перевод структур данных в бинарный вид. Если структура данных поменялась в новой версии программы, значит старый вариант уже работать не будет. Т.о. передачи или сохранение сериализованных данных имеет крайне узкую область применения. Однако, очень многие пишут сериализацию и как существуют даже целые библиотеки под эту функциональность. Зачем так делать?

W>>Как раз сериализация — это не прямой перевод в бинарный вид.
BFE>Если это так, то чем она отличается то записи ini-файла?

Можно рассматривать запись ini-файла как один из видов сериализации

Здравствуйте, Artem Korneev, Вы писали:

AK>vim я использовал для кодинга на с/с++/erlang/tcl/python/bash много лет. Потом решил освоить emacs, но за несколько лет так и не смог отучить его от некоторых неприятных особенностей поведения. Главной неприятностью оказалась его принципиальная однопоточность, а следовательно всякие медленные операции вроде парсинга исходников нельзя перевести в фон.

Это так звучит, как будто у vim с эти дела обстоят лучше (хотя возможно и не это имелось в виду).
В Emacs можно запускать фоновые процессы, асинхронную обработку и т.п. Но нельзя запускать параллельно внутренние скрипты Lisp (то есть если парсинг исходников написан на самом Lisp'е, то будет подвисание).
https://blogs.rsdn.ru/kaapython/5658256#5658311
http://www.gnu.org/software/emacs/manual/html_node/elisp/Asynchronous-Processes.html
http://www.youtube.com/watch?v=I6pvC3_zeP4

Здравствуйте, Greeter, Вы писали:

G>Или не до конца понимаете в программировании? Для меня вот например Oracle это что-то типа пятого измерения В теории какбы понятно — деревья, логарифмические алгоритмы, интерпретаторы с перкомпиляцией, кэши разные. Но как оно все вместе так хитро собрано, и почему оно такое пц быстрое, и при этом устойчивое, и как работает его оптимизатор? Вообще не представляю.

Не понимаю, как программы до сих пор работают, немотря на то, что в них столько ошибок.

Здравствуйте, alex_public, Вы писали:

_>

_>int prev=0, count=0;
_>bool up=true;
_>for(;;){
_>    this_thread::sleep_for(chrono::seconds(1));
_>}
_>

_>в такой
_>

_>void Analyze(int val)
_>{
_>}
_>for(;;){
_>    Analyze(rand());
_>    this_thread::sleep_for(chrono::seconds(1));
_>}
_>

_>Ну если кому-то это сложно, то сорри... )

Кстати говоря, вернулся посмотреть, не вернулся ли ты и заметил важную вещь, которую пропустил на прошлом разе. Ты привел код не того алгоритма. Исходный — парсер последовательности с неоднозначной грамматикой. А у тебя вышел парсер с однозначной грамматикой и он выдает немного другой результат. В некоторых последовательностях выдаст тот же, а в некоторых — другой. Вот такое у тебя решение.
Так часто бывает, когда матан пытаются подменить эвристикой. Годы работало, а потом — опаньки !

Здравствуйте, Greeter, Вы писали:

G>Или не до конца понимаете в программировании? Для меня вот например Oracle это что-то типа пятого измерения В теории какбы понятно — деревья, логарифмические алгоритмы, интерпретаторы с перкомпиляцией, кэши разные. Но как оно все вместе так хитро собрано, и почему оно такое пц быстрое, и при этом устойчивое, и как работает его оптимизатор? Вообще не представляю.
Не понимаю свободные переменные и замыкания. Зачем всё это нужно если можно передать параметр по ссылке, например.

Здравствуйте, Kernan, Вы писали:

K>Не понимаю свободные переменные и замыкания. Зачем всё это нужно если можно передать параметр по ссылке, например.

Замыкания — это технология по сути предоставляющая альтернативу ООП. В каких-то областях она хуже, а в каких-то лучше ООП. К примеру она позволяет удобным образом создавать объекты без всяких предварительных описаний классов и т.п., на лету (но при этом это не какая-то кривая динамика, а нормальная статика со всеми проверками на этапе компиляции).

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

Здравствуйте, achp, Вы писали:

IT>>Я не то что подкатывал, но даже несколько раз понимал.
A>Мне почему-то сразу вспомнился анекдот про поручика Ржевского («Мадам, разрешите вам впердолить!»)

Странно. Тут все же явно напрашивается анекдот

- Бросить курить? Да это очень просто, уж поверьте мне, я сколько раз уже бросал!

Здравствуйте, Kernan, Вы писали:

K>Не понимаю свободные переменные и замыкания. Зачем всё это нужно если можно передать параметр по ссылке, например.

а иначе писанины много. Больше низачем. Чистое удобство.

You will always get what you always got
  If you always do  what you always did