Ну так софт-то все равно расшифровывать будет, а это значит, что специалист, в принципе, тоже может прочитать открытый текст. Механизм с автоматизированным софтом был доступен и раньше, без гомоморфного шифрования. Или я чего-то недопонял?
>Представьте, что вы отсылаете зашифрованную вашим закрытым ключом декларацию и получаете также зашифрованный результат от налогового специалиста, который не узнал ни бита информации о ваших доходах.
Да, мне тоже непонятно. Как специалист может анализировать данные, не расшифровывая их?
И какого рода результат он отправит мне в этом случае?
Респект вам за то, что докопались до истины. Обычно с этим проще — не работает — ну и фиг с ним, пробуем другую либу. Для меня чаще опыт пропатчивания опенсорс либ был связан с поведением самой библиотеки, а не с поддержкой конкретного контекста. Например, если джавовый commons fileupload не позволяет без выброса исключения отловить факт превышения лимита размера файла — берем код и либо делаем наследника от дефолтного класса, либо (если архитектура либы не позволяет) — копируем из исходников этот же класс, патчим, и вкладываем в наш jar. Джавовый класслоадер подцепит наш класс вместо дефолтного.
//
Жаль только, что с обновлением библиотек приходится заново смотреть на все эти вещи.
Эх, Deplhi, конечно, строгий язык, удобочитаемый код итд, но я не могу понять, почему раньше тот код с явным кастом не компилировался. Я так понимаю, в предыдущих версиях приходилось работать через промежуточный каст к Object'у?
//
Мне кажется, здесь действительно лучше всего — позиция Java и C#, в котором код, содержащий кастинг ссылочных объектов, будет в любом случае скомпилирован, а корректность кастинга проверяется в рантайме. Если уж нужна строгость и полный контроль за тем, что происходит — то лучше смотреть в сторону С++, где есть разные типы кастов (в данном случае, наиболее подходящим выбором будет dynamic_cast<ImplementationPointer*>.
Оптимальным — поскольку для реализации полноценного интеллисенса в С++ нужно очень много ресурсов, и такой парсер будет очень медленно работать из-за сложности грамматики. Я лично не знаю интеллисенсов в мире С++, по возможностям сравнимых с мощью решарпера или intellij IDEA, которые работают с языками C# и Java. Поэтому, на мой взгляд, имеет смысл ограничиться только самым необходимым функционалом (подстановка уже имеющихся в контексте литералов, автокомплит имен функций итд).
В Delphi грамматика попроще и построже, поэтому и хороший autocomplete — явление закономерное.
Я бы добавил, что подход, описанный в статье, реализован в утилитах, таких как NETZ (консольная), а также NBox (консольная, но собирает не из строки, а из нормального XML конфига). Последняя утилита — собственного написания, постоянно ей пользуюсь, недавно даже собрался и оформил краткий русский мануал.
Есть там интеллисенс, только он не особо intelli )
Он работает больше по принципу подстановки всех похожих лексем, нежели по принципу выбора подходящих по семантике. В принципе, этот путь мне кажется оптимальным подходом для С/C++. Отмечу, кстати, что в контексте конструкций, специфичных для Objective-C (посылка сообщения, к примеру), интеллисенс намного более интеллектуален.
//
Единственное, чего я не могу понять — почему интеллисенс в XCode вызывается по нажатию на клавишу (какую бы вы думали?) ESCAPE!
Расскажите в двух словах без деталей, если не трудно.
Мне приходит в голову либо добавить в структуру, оборачивающую выделенную память, свое собственное поле, в котором хранить ID пула, и задать макрос new для каждой группы классов, которые будут использовать этот пул. Это навряд ли получится, так как структура внутренняя.
Либо переопределить глобальный оператор new и уже с указателем, полученным из alloc'a, связать информацию о пуле. Соответственно, при выводе информации об утечках нужно каким-то способом прицепить туда эту информацию, выводя статистику по нужным пулам, или группируя.
Ага, я невнимателен, спасибо.
//
Жаль только, что можно работать только с одним, глобальным пулом памяти. Было бы здорово научиться выделять для различных групп объектов различные пулы памяти (прописывать имена пулов в классах), и затем сравнивать состояния в контрольных точках конкретных пулов. Это, мне кажется, упростило бы локализацию утечек.
Недопонял, как эту фишку можно поюзать, скажем, в готовом проекте, во время выполнения которого все время в памяти находится большое число связанных объектов (например, 3д игрушка с физикой — там будет куча моделек, текстур, сущностей, связанных между собой и взаимодействующих с их физическими моделями). Я так понял, что эта фича позволяет снять дамп памяти, в котором каждый объект несет информацию о том, где он был аллоцирован. Но как это поможет, если мы не в состоянии отделить зерна от плевел, т.е. объекты, которые должны быть живы, от тех, которые должны были быть уничтожены на момент снятия дампа?
Математический сопроцессор не нужен для целочисленной арифметики.
К тому же, бОльшую часть операций, необходимых в этом алгоритме, можно реализовать оптимизированным битовым сдвигом (например, сдвиг вправо на 1 бит эквивалентен делению на 2).
Плюс, есть методы, которые существенно (в 1.5 раза) повышают скорость кодирования/декодирования за счет незначительного (порядка сотых долей процента) уменьшения степени сжатия (интервальное кодирование Шиндлера).
В свете всего этого — действительно странно, почему по умолчанию эта опция отключена.
Зря иронизируете, все очень серьезно. Вот мы, к примеру, на военке попали во взвод связи — так у нас помимо ком. взвода, ком. отделений, писарей и парикмахера еще и должность «компьютерный гений» присутствует. :)
Попробуйте новый язык программирования, новую платформу освоить, авось, и придумаете, чем себя занять :) Хотя, конечно, если все уже изучено, то тогда — увы и ах, придется вам самим придумать что-нибудь совсем новое. :)
//
А я, к примеру, в программировании люблю возможность писать код по-разному. Таким образом, появляется возможность возвращаться к уже написанному коду время от времени и каждый раз балдеть от того, что ты можешь еще и еще улучшить безопасность по отношению к типам, согласованность интерфейсов, сделать код более прозрачным или более универсальным.
Особенно полезным считаю разработку реюзабельного кода. Разработка библиотек, особенно с поддержкой концепции обобщенного программирования, — непростая и часто очень интересная задача.
Я всегда говорил, что рано или поздно HTTP вместе с HTML/js будет постепенно заменен на более мощную штуку. И первым, кто осуществит этот переход, станет гугл. Сначала это будет преподнесено как некое усовершенствование HTTP 1.1, а затем появятся и принципиально новые решения. Пионером в поддержке этих новшеств призван стать google chrome.
Да, заметка сильно лаконичная.
Кому интересно прочитать про его главное творение — С++ — рекомендую прочитать книгу «Дизайн и эволюция С++» — pdf несложно найти в интернетах.
alenacpp.blogspot.com/2005/11/sequence-points.html
Да, мне тоже непонятно. Как специалист может анализировать данные, не расшифровывая их?
И какого рода результат он отправит мне в этом случае?
//
Жаль только, что с обновлением библиотек приходится заново смотреть на все эти вещи.
//
Мне кажется, здесь действительно лучше всего — позиция Java и C#, в котором код, содержащий кастинг ссылочных объектов, будет в любом случае скомпилирован, а корректность кастинга проверяется в рантайме. Если уж нужна строгость и полный контроль за тем, что происходит — то лучше смотреть в сторону С++, где есть разные типы кастов (в данном случае, наиболее подходящим выбором будет dynamic_cast<ImplementationPointer*>.
В Delphi грамматика попроще и построже, поэтому и хороший autocomplete — явление закономерное.
Он работает больше по принципу подстановки всех похожих лексем, нежели по принципу выбора подходящих по семантике. В принципе, этот путь мне кажется оптимальным подходом для С/C++. Отмечу, кстати, что в контексте конструкций, специфичных для Objective-C (посылка сообщения, к примеру), интеллисенс намного более интеллектуален.
//
Единственное, чего я не могу понять — почему интеллисенс в XCode вызывается по нажатию на клавишу (какую бы вы думали?) ESCAPE!
Мне приходит в голову либо добавить в структуру, оборачивающую выделенную память, свое собственное поле, в котором хранить ID пула, и задать макрос new для каждой группы классов, которые будут использовать этот пул. Это навряд ли получится, так как структура внутренняя.
Либо переопределить глобальный оператор new и уже с указателем, полученным из alloc'a, связать информацию о пуле. Соответственно, при выводе информации об утечках нужно каким-то способом прицепить туда эту информацию, выводя статистику по нужным пулам, или группируя.
//
Жаль только, что можно работать только с одним, глобальным пулом памяти. Было бы здорово научиться выделять для различных групп объектов различные пулы памяти (прописывать имена пулов в классах), и затем сравнивать состояния в контрольных точках конкретных пулов. Это, мне кажется, упростило бы локализацию утечек.
К тому же, бОльшую часть операций, необходимых в этом алгоритме, можно реализовать оптимизированным битовым сдвигом (например, сдвиг вправо на 1 бит эквивалентен делению на 2).
Плюс, есть методы, которые существенно (в 1.5 раза) повышают скорость кодирования/декодирования за счет незначительного (порядка сотых долей процента) уменьшения степени сжатия (интервальное кодирование Шиндлера).
В свете всего этого — действительно странно, почему по умолчанию эта опция отключена.
//
А я, к примеру, в программировании люблю возможность писать код по-разному. Таким образом, появляется возможность возвращаться к уже написанному коду время от времени и каждый раз балдеть от того, что ты можешь еще и еще улучшить безопасность по отношению к типам, согласованность интерфейсов, сделать код более прозрачным или более универсальным.
Особенно полезным считаю разработку реюзабельного кода. Разработка библиотек, особенно с поддержкой концепции обобщенного программирования, — непростая и часто очень интересная задача.
Кому интересно прочитать про его главное творение — С++ — рекомендую прочитать книгу «Дизайн и эволюция С++» — pdf несложно найти в интернетах.