Вы, как владелец бизнеса заинтересованы чтобы было как можно меньше контроля.
Тогда в случае «аварии» можно легко заявить что дрон не ваш, а это конкуренты сделали его с вашим логотипом и убили случайного прохожего чтобы вас подставить.
Ваша логика прекрасно ложится на раздачу оружия без лицензии.
Ведь человек сам заинтересован, чтобы его оружие никого не убивало! Значит можно раздать всем стволы, и все будут очень аккуратно обращаться с оружием, чтобы не сесть.
Но практика почему-то отличается от этой логики. :)
А вообще, в чем вы видите сложность? В том, что стандартные парсеры это не поймут? Ну так это естественно. Речь же как раз о том, что нужно изменить, чтобы тот же json смог хранить бинари не хуже чем у вас.
Или вы видите проблему в том, чтобы написать парсер, который будет считать значения валидными, если они содержат любые символы, а не только unicode(как это по стандарту должно быть).
Если уж мы говорим о «декодировании», то тут тоже особых проблем нет.
Ничего не мешает сунуть бинарные данные в тот же json. Единственное что придется сделать — экранировать кавычки и бэкслэш.
С точки зрения скорости исполнения и сложности кода нет разницы, экранировать один символ(перенос строки) или два(кавычки и бэк слэш).
Реальным плюсом вашего формата стало бы хранение цельного блока бинарных данных, т.к. это позволило бы делать то, о чем вы говорили — ссылаться на документ не работая с бинарными данными отдельно. Но у вас этого плюса нет. как уже было выяснено.
Я вообще не обсуждал скорость.
Я обсуждал ваш конкретный довод — «выделять отдельную память».
Вывод тут ясен — довод не актуален и, судя по всему, вброшен без серьезного обдумывания.
Ну ок.
Довод «в других парсерах нужно отдельно выделять память» — отменяется, т.к. в этом пункте отличия вашего парсера от «других» нет никакого. Что там, что там придется выделять память и проводить определенные операции чтобы преобразовать данные представленные в формате в рабочие данные.
Вы привели код, после обработки парсером.
Ни о какой «ссылке на участок файла» речи здесь не идет.
С таким же успехом я и в xml запихаю бинарные данные в виде base64, распакую и верну результат.
Внимательно прочитайте цитату. Там вы говорите, что недостатком такого подхода является необходимость выделения отдельного буффера под данные перед их использованием.
Покажите код, который будет отдавать ссылку на int-10 без выделения дополнительной памяти под сборку этого самого инта.
И никто не будет отвечать в случае несчастного случая! Отлично же!
*сарказм*
Почему в попытке урегулировать работу с дронами все видят происки спец служб нацеленных на подавление народной воли и никто не видит очевидной необходимости дроны регулировать?
Когда дронов в небе — 1 штука на 1000 километров, они не нуждаются в регулировании.
Но очевидно, что в ближайшее время дроны будут чуть ли не над каждым домом. И в такой ситуации отсутствие регулирования приведет к несчастным случаям. Вообще и ждать не надо. Уже накопилась некоторая масса событий, включающих травмы и даже смерти в результате действий дронов и прочих летающих игрушек.
Ужесточение законов связанных с летающими игрушками неизбежно. Также как неизбежно было появление ПДД когда автомобилей в городе стало больше одного.
Я так понимаю вы намекаете на base64, base62 и другие способы конвертации бинарных данных в текстовые? Вот собственно эта фаза перекодировки и мешает. Она не позволяет просто потоком вгрузить файл в память и далее просто ссылаться на его участки — обязательно надо выделять отдельные куски памяти для отдельных декодированных значений.
Как в случае Tree будет выглядить «просто ссылка» на бинарную переменную int-10?
Ну не правда же.
Вот вы говорите, что преимуществом хранения бинарных данных в вашем формате перед base64 является то, что для хранения декодированного base64 кода надо отдельно место выделять при парсинге и нельзя просто дать указатель на блок данных в документе.
Но дело в том, что у вас тоже нельзя просто дать указатель на блок данных.
Потому что блок бинарных данных в вашем формате разделен на части.
Один хрен надо выделять память отдельно и там собирать бинарные данные в цельный кусок.
Вы просто не хотите видеть очевидные проблемы вашего формата. Что характерно — ровно теже самые проблемы в других форматах вами выцепляются.
Давно интересуюсь темой Андроид-часов…
Вообще, такие проекты уже существуют несколько лет. И все они плохи.
Данный проект ничем не выделяется на фоне плохих андроид часов. ИМХО
Обычная растеризация прекрасно параллелится. Собственно, каждую линию можно считать в отдельном процессе — никаких зависимостей за пределами линии нет.
Тут вопрос в конечной цели.
Спортивная стрельба — это один набор условий.
Практическая стрельба(не в смысле спортивной дисциплины, а в прямом значении) — другой набор.
Например, довелось отрабатывать упражнения в паре, когда вспышка, звук и летящая гильза напарника становились реально стрессовым фактором.
Если вдруг будут лишние деньги — посмотрите в сторону системы СКАТТ. Ну или на них можно посмотреть, чтобы свой клон сделать. :)
Там самая главная фишка — это контроль не только попадания, но и самого процесса выстрела. В итоге можно увидеть как оружие болталось в руках в момент спуска.
Силовики предпочитают работать с огнестрельным оружием все-таки. Лазер это баловство в основном. Максимум для чего используются лазер — это контроль спуска. А конкретно упражнения выполняются с огнестрельным оружием и «сенсорным» экраном, которые умеет обрабатывать попадание пули. Естественно стреляют не бронебойными, а обычными с малой навеской пороха.
А разве речь о том, что человек перестанет общаться? Нет, человек перестанет общаться в живую. А это разное.
Сейчас очень много проектов в интернете делается людьми, которые никогда друг друга вживую не видели. Лично я участвовал в нескольких законченных проектах в командах с людьми, которые даже не слышали никогда голоса друг друга.
Тогда в случае «аварии» можно легко заявить что дрон не ваш, а это конкуренты сделали его с вашим логотипом и убили случайного прохожего чтобы вас подставить.
Ваша логика прекрасно ложится на раздачу оружия без лицензии.
Ведь человек сам заинтересован, чтобы его оружие никого не убивало! Значит можно раздать всем стволы, и все будут очень аккуратно обращаться с оружием, чтобы не сесть.
Но практика почему-то отличается от этой логики. :)
А вообще, в чем вы видите сложность? В том, что стандартные парсеры это не поймут? Ну так это естественно. Речь же как раз о том, что нужно изменить, чтобы тот же json смог хранить бинари не хуже чем у вас.
Или вы видите проблему в том, чтобы написать парсер, который будет считать значения валидными, если они содержат любые символы, а не только unicode(как это по стандарту должно быть).
Ничего не мешает сунуть бинарные данные в тот же json. Единственное что придется сделать — экранировать кавычки и бэкслэш.
С точки зрения скорости исполнения и сложности кода нет разницы, экранировать один символ(перенос строки) или два(кавычки и бэк слэш).
Реальным плюсом вашего формата стало бы хранение цельного блока бинарных данных, т.к. это позволило бы делать то, о чем вы говорили — ссылаться на документ не работая с бинарными данными отдельно. Но у вас этого плюса нет. как уже было выяснено.
Я обсуждал ваш конкретный довод — «выделять отдельную память».
Вывод тут ясен — довод не актуален и, судя по всему, вброшен без серьезного обдумывания.
Довод «в других парсерах нужно отдельно выделять память» — отменяется, т.к. в этом пункте отличия вашего парсера от «других» нет никакого. Что там, что там придется выделять память и проводить определенные операции чтобы преобразовать данные представленные в формате в рабочие данные.
Ни о какой «ссылке на участок файла» речи здесь не идет.
С таким же успехом я и в xml запихаю бинарные данные в виде base64, распакую и верну результат.
Внимательно прочитайте цитату. Там вы говорите, что недостатком такого подхода является необходимость выделения отдельного буффера под данные перед их использованием.
Покажите код, который будет отдавать ссылку на int-10 без выделения дополнительной памяти под сборку этого самого инта.
Если опять не врут, конечно.
*сарказм*
Почему в попытке урегулировать работу с дронами все видят происки спец служб нацеленных на подавление народной воли и никто не видит очевидной необходимости дроны регулировать?
Когда дронов в небе — 1 штука на 1000 километров, они не нуждаются в регулировании.
Но очевидно, что в ближайшее время дроны будут чуть ли не над каждым домом. И в такой ситуации отсутствие регулирования приведет к несчастным случаям. Вообще и ждать не надо. Уже накопилась некоторая масса событий, включающих травмы и даже смерти в результате действий дронов и прочих летающих игрушек.
Ужесточение законов связанных с летающими игрушками неизбежно. Также как неизбежно было появление ПДД когда автомобилей в городе стало больше одного.
И тут я понял чей комментарий читаю…
Как в случае Tree будет выглядить «просто ссылка» на бинарную переменную int-10?
Вот вы говорите, что преимуществом хранения бинарных данных в вашем формате перед base64 является то, что для хранения декодированного base64 кода надо отдельно место выделять при парсинге и нельзя просто дать указатель на блок данных в документе.
Но дело в том, что у вас тоже нельзя просто дать указатель на блок данных.
Потому что блок бинарных данных в вашем формате разделен на части.
Один хрен надо выделять память отдельно и там собирать бинарные данные в цельный кусок.
Вы просто не хотите видеть очевидные проблемы вашего формата. Что характерно — ровно теже самые проблемы в других форматах вами выцепляются.
Вообще, такие проекты уже существуют несколько лет. И все они плохи.
Данный проект ничем не выделяется на фоне плохих андроид часов. ИМХО
Спортивная стрельба — это один набор условий.
Практическая стрельба(не в смысле спортивной дисциплины, а в прямом значении) — другой набор.
Например, довелось отрабатывать упражнения в паре, когда вспышка, звук и летящая гильза напарника становились реально стрессовым фактором.
Там самая главная фишка — это контроль не только попадания, но и самого процесса выстрела. В итоге можно увидеть как оружие болталось в руках в момент спуска.
При стрельбе из лазерного вырастает только один, но достаточно важный — скорость прицеливания.
Сейчас очень много проектов в интернете делается людьми, которые никогда друг друга вживую не видели. Лично я участвовал в нескольких законченных проектах в командах с людьми, которые даже не слышали никогда голоса друг друга.