Одним лишь военным могуществом нельзя покорить мир. Если тебя все ненавидят — то даже если их силы недостаточны, чтобы тебя свалить, то будут мелко пакостить, окажешься в международной изоляции, будет саботаж и противодействие. Будет также информационное воздействие, граждан такой страны все мировое сообщество будет убеждать в том, какая их страна плохая и как она портит всем жизнь. Граждане сами свергнут власть и откажутся от мирового военного диктата, если поверят, что они неправы. Именно это произошло с СССР, и не помогло никакое военное могущество.
Некоторые защитники патентов выдвигают тезис, что патентование способствует раскрытию изобретений, которые в противном случае остались бы конфиденциальными. Тем самым, заплатив временной монополией, общество получает взамен описание изобретения, которым впоследствии смогут пользоваться все. Недаром текст патентов начинается со слов «is disclosed». Разглашение, предоставление информации обществу — вот общественная польза от патентов.
Обратный пример — компания Кока-кола могла бы запатентовать свой напиток, но вместо этого она держит его формулу в секрете уже много десятков лет. То есть компания взвесила преимущества и недостатки патентования и приняла решение: не патентовать. Компания и так имеет по факту монополию на формулу, которая не ограничена временем, в отличие от патента.
Но патенты на очевидные, тривиальные решения как раз нарушают этот принцип. Обществу и без «разглашения» понятно, как сделать ту или иную вещь. Если она может быть изобретена независимо множеством людей за короткое время — то какая польза обществу от опубликования такого «изобретения»? Никакой. И предоставление монополии на них наносит обществу лишь вред. Не говоря уже о том, что современные патенты специально составляются так, чтобы по их описанию невозможно было бы повторить изобретение с заявленными характеристиками, а за недостающей информацией (которая остается конфиденциальной) приходится обращаться к владельцам патента за отдельную плату. Патентование идей лишает тексты патентов полноты, необходимой для воссоздания изобретения, поскольку всегда можно заявить, что это лишь идея, на основе которой теоретически можно воссоздать полезную модель, если добавить в реализацию дополнительные детали, которые не были разглашены в тексте патента.
Дизайн устройства, иконки и т.д. следовало бы защищать другим способом, чем патенты, если в такой защите действительно существует польза для общества и стимулирование прогресса. Например, такая защита могла бы обеспечиваться авторским правом или правом на торговую марку. Но такая защита не действует столь широко, как патентная, и поэтому позволяет с одной стороны оградить уникальный дизайн, а с другой стороны — не мешать тем, кто разрабатывает, хоть и похожие вещи, но сам.
Какое именно ПО — он рассказывал о сервере онлайн-рекламы, который должен быстро отвечать на запросы. Говорил, что разбор текстовых протоколов передачи данных занимает существенную часть времени, требуемого на формирование ответа, и поэтому оптимизация такого разбора себя оправдывает. Подробности мне неизвестны; за что купил — за то и продаю.
Я когда-то анализировал код библиотеки C++, занимающийся поточным вводом-выводом. Это какой-то кошмар и мрак. Сложно и неэффективно. Возможно, положения стандарта трудно реализовать лучше, но тогда это уже вопрос к авторам стандарта — почему принимался именно такой стандарт. Все равно для серьезных целей, вроде парсинга языка программирования, разборщики чисел из стандартной библиотеки плохо подходят. Они капризные, их поведение меняется от версии к версии и стандартом жестко не задано; отсутствует диагностика ошибок. Вдобавок, когда ввели интернационализацию формата чисел в стандартных библиотеках — это сломало мои программы загрузки данных из текстовых файлов или разбора командной строки. Пришлось все перекомпилировать, вставляя где надо инициализацию национального формата чисел.
Один знакомый программист, который разрабатывает серверное п/о, рассказывал, что ему приходится оптимизировать парсеры текста вплоть до перевода их на ассемблер с использованием SIMD-инструкций. Что такая оптимизация дает существенный прирост быстродействия, и для серверного п/о это важно.
Так что собственноручно написанные разборщики чисел — это далеко не учебная задача. Их приходится делать при создании компиляторов, парсеров для текстовых форматов файлов или текстовых протоколов передачи данных.
Совершенно верно. Есть Optical Music Recognition. Нотная запись по картинке распознается уже давно не хуже, чем обычный текст.
Есть также распознавание музыки на слух (анализ сигнала). Методы искусственного интеллекта в этой области зашли слишком далеко, чтобы можно было делать по-настоящему устойчивую музыкальную капчу. Аналогично с псевдокодом, фотографиями осциллографов и расчетом резисторов. Все эти процессы или хорошо автоматизируются (исполнение кода, расчет), или просто создается конечная база данных задач капчи, ведь сайт не располагает, например, десятком тысяч разных фотографий разных вольтметров.
Интересный, на мой взгляд, вариант капчи мог бы быть в рендеринге трехмерных объектов. Распознать объект по фотографии в общем случае — сложная задача, и решена она более-менее хорошо лишь для узких классов объектов, таких как лица.
Программисту несложно провести вычислительный эксперимент, чтобы «почувствовать», как это делается. Представьте себе круг, равномерно заполненный точками. Изначально эти точки покоятся, и тут мы имитируем ввод энергии в систему: придаем точкам начальные скорости, которые распределены в соответствии с законами распределения скоростей в статистической физике, и направлены в случайные стороны. Система, естественно, начнет разлетаться, но в ходе разлета произойдет некоторое количество столкновений частиц. Если энергия столкновения пары выше некоторого порога — то считаем, что между данной парой столкнувшихся частиц прошла реакция синтеза. Две частицы объединяются в одну; модуль и направление скорости получившейся большой частицы вычисляются исходя из законов сохранения энергии и импульса. И моделирование продолжается. В конце можно посчитать, какой процент частиц испытал столкновения с реакцией.
Давление не играет роли, важна только температура. Именно она определяет среднюю энергию столкновения ядер. И если эта энергия позволит преодолеть кулоновский барьер — то неважно, какое при этом было давление. Реакция все равно будет идти.
Идеал идеалу рознь. Понятное дело, что написанный вручную оператор сравнения быстрее, чем сгенерированный моими макросами. Тут разработчик стоит перед выбором, что ему важнее: скорость или удобство разработки и защищенность ее от ошибок на перспективу.
Хочу еще раз обратить ваше внимание, что накладные расходы у моих макросов очень низкие:
1) Информацию о членах несет не каждый экземпляр структуры, потому что эта информация хранится в статических членах, один экземпляр на всю программу.
2) Вследствие 1), конструкторы и деструкторы моих структур не занимаются инициализацией или освобождением массивов с информацией о структуре;
Имеющиеся накладные расходы:
1) На работу оператора сравнения — вызов функций по указателям;
2) При создании каждого экземпляра структуры — на проверку флага populate_statdata столько раз, сколько в структуре членов.
Больше накладных расходов нет. Мне кажется, что это вполне неплохой компромисс по сравнению с другими решениями, которые здесь рассматривались. К тому же, если объект содержит данные не простых типов, а сложные типы, контейнеры (string, map, vector и т.д.) — то при работе операторов сравнения именно сравнение членов будет доминировать во времени выполнения, а не проход по массиву с указателями на функции.
Ну и если описанные выше накладные расходы являются неприемлемыми — то и это еще не повод сдаваться и писать операторы сравнения вручную. Можно применить генерацию кода — я упомянул этот способ в статье.
В предложенном Вами варианте члены структуры надо указывать в двух местах, что является потенциальным источником ошибок. Задача ставилась так, чтобы объявлять член только в одном месте.
Спасибо за разъяснения. У вас тоже интересная конструкция получилась. Надо будет на досуге попробовать объединить идеи из моей и вашей реализации. Возможно, получится сделать систему с низкими затратами времени выполнения, но не на базе макросов, а на базе шаблонов.
Я пользуюсь этими макросами в нескольких своих проектах. Как только создал их — сразу почувствовал облегчение в работе. Главные аргументы я привел в статье. Это удобство и предохранение от ошибок. Член объявляется только в одном месте. Добавив или удалив член, не нужно менять расположенный в другом файле оператор сравнения. Ручное написание оператора почленного сравнения всегда имеет тот риск, что сравниваться будут не все члены. Забыть можно, проглядеть. Когда членов несколько десятков — то просто глазами трудно заметить, какой из них пропущен. А проявляться такой баг будет очень редко, как следствие — будет трудно его потом ловить.
Также я использую аналогичные макросы для автоматической генерации процедур загрузки и сохранения в файлы. Все три операции (сравнение, загрузка, сохранение) генерирует один вызов макроса. Так что, чисто по объему текста программы, получается даже экономия.
А что тут дебажить? Это структура данных. Отлаживать необходимо только сами макросы (которые уже отлажены). При отладке программы, использующей такие структуры, в отладчике VisualStudio видны члены данных. Служебные члены тоже видны, но за счет префиксов в их именах, разделить одни от других несложно. Сомневаюсь, что boost::fusion::map лучше визуализируются в отладчике.
Такие структуры не предназначены для хранения указателей, потому что тогда они перестают быть чисто структурами данных. Для них также теряет смысл копирование операторами по умолчанию.
Одна голова хорошо, а две — лучше! Надо будет попробовать. В самом деле, можно избавиться от нагрузки на создание структур во время выполнения программы.
Обратный пример — компания Кока-кола могла бы запатентовать свой напиток, но вместо этого она держит его формулу в секрете уже много десятков лет. То есть компания взвесила преимущества и недостатки патентования и приняла решение: не патентовать. Компания и так имеет по факту монополию на формулу, которая не ограничена временем, в отличие от патента.
Но патенты на очевидные, тривиальные решения как раз нарушают этот принцип. Обществу и без «разглашения» понятно, как сделать ту или иную вещь. Если она может быть изобретена независимо множеством людей за короткое время — то какая польза обществу от опубликования такого «изобретения»? Никакой. И предоставление монополии на них наносит обществу лишь вред. Не говоря уже о том, что современные патенты специально составляются так, чтобы по их описанию невозможно было бы повторить изобретение с заявленными характеристиками, а за недостающей информацией (которая остается конфиденциальной) приходится обращаться к владельцам патента за отдельную плату. Патентование идей лишает тексты патентов полноты, необходимой для воссоздания изобретения, поскольку всегда можно заявить, что это лишь идея, на основе которой теоретически можно воссоздать полезную модель, если добавить в реализацию дополнительные детали, которые не были разглашены в тексте патента.
Дизайн устройства, иконки и т.д. следовало бы защищать другим способом, чем патенты, если в такой защите действительно существует польза для общества и стимулирование прогресса. Например, такая защита могла бы обеспечиваться авторским правом или правом на торговую марку. Но такая защита не действует столь широко, как патентная, и поэтому позволяет с одной стороны оградить уникальный дизайн, а с другой стороны — не мешать тем, кто разрабатывает, хоть и похожие вещи, но сам.
Какое именно ПО — он рассказывал о сервере онлайн-рекламы, который должен быстро отвечать на запросы. Говорил, что разбор текстовых протоколов передачи данных занимает существенную часть времени, требуемого на формирование ответа, и поэтому оптимизация такого разбора себя оправдывает. Подробности мне неизвестны; за что купил — за то и продаю.
Один знакомый программист, который разрабатывает серверное п/о, рассказывал, что ему приходится оптимизировать парсеры текста вплоть до перевода их на ассемблер с использованием SIMD-инструкций. Что такая оптимизация дает существенный прирост быстродействия, и для серверного п/о это важно.
Так что собственноручно написанные разборщики чисел — это далеко не учебная задача. Их приходится делать при создании компиляторов, парсеров для текстовых форматов файлов или текстовых протоколов передачи данных.
Есть также распознавание музыки на слух (анализ сигнала). Методы искусственного интеллекта в этой области зашли слишком далеко, чтобы можно было делать по-настоящему устойчивую музыкальную капчу. Аналогично с псевдокодом, фотографиями осциллографов и расчетом резисторов. Все эти процессы или хорошо автоматизируются (исполнение кода, расчет), или просто создается конечная база данных задач капчи, ведь сайт не располагает, например, десятком тысяч разных фотографий разных вольтметров.
Интересный, на мой взгляд, вариант капчи мог бы быть в рендеринге трехмерных объектов. Распознать объект по фотографии в общем случае — сложная задача, и решена она более-менее хорошо лишь для узких классов объектов, таких как лица.
Хочу еще раз обратить ваше внимание, что накладные расходы у моих макросов очень низкие:
1) Информацию о членах несет не каждый экземпляр структуры, потому что эта информация хранится в статических членах, один экземпляр на всю программу.
2) Вследствие 1), конструкторы и деструкторы моих структур не занимаются инициализацией или освобождением массивов с информацией о структуре;
Имеющиеся накладные расходы:
1) На работу оператора сравнения — вызов функций по указателям;
2) При создании каждого экземпляра структуры — на проверку флага populate_statdata столько раз, сколько в структуре членов.
Больше накладных расходов нет. Мне кажется, что это вполне неплохой компромисс по сравнению с другими решениями, которые здесь рассматривались. К тому же, если объект содержит данные не простых типов, а сложные типы, контейнеры (string, map, vector и т.д.) — то при работе операторов сравнения именно сравнение членов будет доминировать во времени выполнения, а не проход по массиву с указателями на функции.
Ну и если описанные выше накладные расходы являются неприемлемыми — то и это еще не повод сдаваться и писать операторы сравнения вручную. Можно применить генерацию кода — я упомянул этот способ в статье.
Также я использую аналогичные макросы для автоматической генерации процедур загрузки и сохранения в файлы. Все три операции (сравнение, загрузка, сохранение) генерирует один вызов макроса. Так что, чисто по объему текста программы, получается даже экономия.
И почему «дичайший» оверхед?