> Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться.
Как некрасиво ты себя ведешь. Не побоюсь сказать уже все давно поняли твой залет, а ты все изображаешь разбирающегося в теме.
> Уже было сказано, что ключи вшиты в прогу жестко.
Напомню тебе твои же слова: "При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи". Это противоречит "вшиты в прогу жестко", если ты не понял.
Кароч, может ты все-таки почитаешь про шифрование, безопасность? Ключи генерируются парами — открытый и закрытый, если что. я тебе в первых строках упомянул несимметричное шифрование. RTFM в общем.
Но даже предположим ключиты вшиты, ты думаешь это дает тебе возможность взломать систему? Прослушать — да, управлять — нет.
Пока вместо ответов какие-то финты, балеринка ты наша.
> Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю.
Мне ты это зачем писал? Мне все-равно на это. У меня было маленькое замечание, ты мог просто признать свою ошибку и получать фан дальше, но ты предпочитаешь продолжать лажаться в теме.
> По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH... опять и снова показав, что дыра всегда в инфраструктуре.
Ну... ты вообще способен на теме диалога сосредоточиться? Ну зачем опять это вранье и хвастовство?
<...болтовня какая-то скипнута...>
> Сдается мне, что ты здесь вообще непонятно что делаешь в кач-ве писателя. Лучше читай и запоминай.
Что запоминать, твои сказочки? Нафиг?
Извини, но ты болтлив не по сути вопроса и постоянно уводишь диалог куда-то в сторону и не отвечаешь на вопросы. Я понимаю, это форум и люди приходят пообщаться, но все-равно должны быть какие-то рамки. Твой стиль нереально напрягает.
Кстати, до меня только сейчас дошло, почему я не могу воткнуть в ход твоих мыслей, а ты в ход моих.
В своих примерах ты пытаешься защищать иммутабельность. А я так даже вопрос ставить для себя не могу, поэтому не мог понять, что тебе непонятно. Фигли иммутабельность защищать-то? Прямо при создании/объявлении значения присвой ему const и оно будет заведомо защищено (если не придираться к хакам в современном С++). Или так разработай интерфейс объекта в ОО-программе, чтобы после создания объект был иммутабельным до конца своей жизни (это возможно даже на C# без const). То бишь, в плане иммутабельности никакой проблемы, ес-но, НЕТ. Защищать надо всегда мутабельное состояние, а не иммутабельное. "Контроллируемая мутабельность" именно это и означает, что я (и компилятор) смогут трекать происходящее с мутабельными данными в программе и быть уверенными в происходящем. В этом смысле const поможет проконторллировать, что конкретно по этой ссылке значение не изменят, а clean даст гарантии для неконстантных ссылок, что их не запомнят в каком-нить ненаблюдаемом, с т.з. вызывающего, контексте, и не будут дергать затем запомненное по ссылке значение одновременно с целевым императивным алгоритмом... который в этом случае перестаёт быть "контроллируемым".
Здравствуйте, vdimas, Вы писали:
V>В своих примерах ты пытаешься защищать иммутабельность. А я так даже вопрос ставить для себя не могу, поэтому не мог понять, что тебе непонятно. Фигли иммутабельность защищать-то?
Наивность, граничащая с некомпетентностью.
Я ещё раз поясняю: компилятор с раздельной компиляцией, не выполняя global flow analysis, не в состоянии извлечь из этой вашей "иммутабельности" ничего полезного. Именно из-за того, что ему неизвестно, ссылается ли переданная в данный фрагмент ссылка на const реально ссылкой на const или ссылкой на mutable.
А при выполнении global flow analysis компилятору совершенно наплевать на ваши ручные аннотации — он и так увидит, где имеет место ссылочная прозрачность, а где — нет.
Что тут непонятно?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Выходит, тот момент, где есть возникновение, а где распространение ссылочной прозрачности, оказался тебе не по зубам даже после разжевать и в рот положить... Казалось бы, показал как правильно пользоваться обсуждаемым инструментарием... ан нет... Смотришь в код и плаваешь в 3-х строчках, даже в собственных примерах...
Т.е. принятые в языке D концепции тебе, понятное дело, всё еще непонятны и бесполезны, с твоих же слов... ))
Ну ок, не смею больше беспокоить.
Здравствуйте, AlexRK, Вы писали:
V>>Существует — алиасинг типов. ARK>Поясните, пожалуйста, о чем речь. В моем представлении алиасинг — это просто назначение типу другого имени.
Я имею ввиду получение нового типа вместе с новым идентификатором. Ес-но typedef из C++ или using Identifier1 = Identifier2 из C# этим св-вом не обладают.
Здравствуйте, grosborn, Вы писали:
>> Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться. G>Как некрасиво ты себя ведешь. Не побоюсь сказать уже все давно поняли твой залет, а ты все изображаешь разбирающегося в теме.
Я не знаю, кто там и что понял на уровне вики. Всё что было понято — они уже написали и я уже отвечал. Или у оппонентов есть еще какие-то тайные знания?
>> Уже было сказано, что ключи вшиты в прогу жестко.
G>Напомню тебе твои же слова: "При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи". Это противоречит "вшиты в прогу жестко", если ты не понял.
Не противоречит. Есть режим запуска для регистрации с параметрами. Как вскрываются оба сценария — я уже говорил. Ну и исходник, опять же...
G>Кароч, может ты все-таки почитаешь про шифрование, безопасность? Ключи генерируются парами — открытый и закрытый, если что.
OMG. ))
G>я тебе в первых строках упомянул несимметричное шифрование. RTFM в общем.
Наивный.
G>Но даже предположим ключиты вшиты, ты думаешь это дает тебе возможность взломать систему? Прослушать — да, управлять — нет.
Ну не позорился бы уже.
1. Что вообще хотят добиться при взломе, не интересовался?
2. Как ты себе вообще представляешь в случае проксирования возможность слушать, но невозможность управлять? Что мне мешает полностью подменять трафик клиента?
Это просто пять баллов!!
G>Пока вместо ответов какие-то финты, балеринка ты наша.
Если ответ неудобен — твои проблемы.
G>Мне ты это зачем писал? Мне все-равно на это. У меня было маленькое замечание, ты мог просто признать свою ошибку и получать фан дальше, но ты предпочитаешь продолжать лажаться в теме.
Я не увидел от тебя ни полезной инфы, не замечаний по теме помимо тех, на которые уже отвечал. Прямо сейчас, например, ты упомянул о генерации ключей парами. Я расчитывал, что ты кормишь свою эрудицию гораздо оперативнее.
>> По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH... опять и снова показав, что дыра всегда в инфраструктуре.
G>Ну... ты вообще способен на теме диалога сосредоточиться? Ну зачем опять это вранье и хвастовство?
Это не то и не другое. Оппоненты на полном серьезе с умным лицом и ты в т.ч. рассказываете о многоуровневой инфраструктуре. Вольфхаунд о двухуровневой, коллега Дубров — аж о 3-хуровневой. К сожалению, независимый 3-й уровень в его модели заведомо признается скомпроментированным согласно обсуждаемой прикладной области, т.е. опять остается 2-хуровневая. Причем, все такие, блин, грамотные и даже не поинтересовались, сколькиуровневая система в реальных системах защиты важной информации... и эту защиту все-равно ломают. Реально ломают порядка 6-ти уровней (минимум дважды выполняется вход во вложенные защищенные области), в клинических случаях до 8-ми (доп. проверка-секрет на каждом из этих 2-х шагов). Мне даже лень спорить об 2-хуровневой инфраструктуре, если честно. Все ее сильные и слабые стороны ты можешь прочесть в Вики.
G>Что запоминать, твои сказочки? Нафиг?
Ну, извини, подробностей дать не могу. Но любопытные моменты — не жалко.
G>Извини, но ты болтлив не по сути вопроса и постоянно уводишь диалог куда-то в сторону и не отвечаешь на вопросы.
Я не могу отвечать 10 раз на одни и те же вопросы. Ты отставал по теме и дублировал остальных участников, поэтому можешь просто посмотреть все ответы рядом.
К тому же, будь любопытным, ты бы читал все за и контра и видел бы, где именно располагаются слабые моменты. Собсно, я сразу открестился от перебора/взлома ключей/паролей (не обратил внимание?) и обсуждаю сугубо инфраструктуру. Ты этого не понял, увы. Чтобы понять, почему именно инфраструктуру — поднимись чуть выше по ветке, восстанови контекст беседы целиком.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, AlexRK, Вы писали:
V>>>Существует — алиасинг типов. ARK>>Поясните, пожалуйста, о чем речь. В моем представлении алиасинг — это просто назначение типу другого имени.
V>Я имею ввиду получение нового типа вместе с новым идентификатором. Ес-но typedef из C++ или using Identifier1 = Identifier2 из C# этим св-вом не обладают.
Замечу, что в Oberon'e этого также нет. И, по моему, этого нет и в паскале. Но это есть в Аде.
В плюсах это (подобный механизм), как я понимаю, можно реализовать библиотечно (через шаблоны).
Здравствуйте, vdimas, Вы писали:
V>Это не то и не другое. Оппоненты на полном серьезе с умным лицом и ты в т.ч. рассказываете о многоуровневой инфраструктуре. Вольфхаунд о двухуровневой, коллега Дубров — аж о 3-хуровневой. К сожалению, независимый 3-й уровень в его модели заведомо признается скомпроментированным согласно обсуждаемой прикладной области, т.е. опять остается 2-хуровневая. Причем, все такие, блин, грамотные и даже не поинтересовались, сколькиуровневая система в реальных системах защиты важной информации... и эту защиту все-равно ломают. Реально ломают порядка 6-ти уровней (минимум дважды выполняется вход во вложенные защищенные области), в клинических случаях до 8-ми (доп. проверка-секрет на каждом из этих 2-х шагов). Мне даже лень спорить об 2-хуровневой инфраструктуре, если честно. Все ее сильные и слабые стороны ты можешь прочесть в Вики.
описал наивный обмен публичными ключами? Я тебе пытался показать, что а) Так делать не надо б) Есть способы сделать лучше. Опять же -- есть разделяемый секрет, пароль, этого уже вполне достаточно чтобы установить надёжное соединение. Можно даже ни с какими CA не заморачиваться. в) Если нет способа гарантировать доставку неизменённой программы, то о безопасности можно и не вспоминать.
Пример с SSH с "наивным" обменом ключами -- это кривой пример, не зря в OpenSSH поддержку CA сделали.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>Ладно, я ошибся. Проблема была не в этом...
V>Выходит, тот момент, где есть возникновение, а где распространение ссылочной прозрачности, оказался тебе не по зубам даже после разжевать и в рот положить... Казалось бы, показал как правильно пользоваться обсуждаемым инструментарием... ан нет... Смотришь в код и плаваешь в 3-х строчках, даже в собственных примерах...
V>Т.е. принятые в языке D концепции тебе, понятное дело, всё еще непонятны и бесполезны, с твоих же слов... )) V>Ну ок, не смею больше беспокоить.
Дарю : "Ладно, я слился. Но на всё есть много точек зрения и, следовательно, я не слился."
> V>Это не то и не другое. Оппоненты на полном серьезе с умным лицом и ты в т.ч. рассказываете о многоуровневой инфраструктуре. Вольфхаунд о двухуровневой, коллега Дубров — аж о 3-хуровневой. К сожалению, независимый 3-й уровень в его модели заведомо признается скомпроментированным согласно обсуждаемой прикладной области, т.е. опять остается 2-хуровневая. Причем, все такие, блин, грамотные и даже не поинтересовались, сколькиуровневая система в реальных системах защиты важной информации... и эту защиту все-равно ломают. Реально ломают порядка 6-ти уровней (минимум дважды выполняется вход во вложенные защищенные области), в клинических случаях до 8-ми (доп. проверка-секрет на каждом из этих 2-х шагов). Мне даже лень спорить об 2-хуровневой инфраструктуре, если честно. Все ее сильные и слабые стороны ты можешь прочесть в Вики. > > О какой многоуровневой системе идёт речь, когда ты в одном из первых сообщений
описал наивный обмен публичными ключами? Я тебе пытался показать, что а) Так делать не надо б) Есть способы сделать лучше. Опять же -- есть разделяемый секрет, пароль, этого уже вполне достаточно чтобы установить надёжное соединение. Можно даже ни с какими CA не заморачиваться. в) Если нет способа гарантировать доставку неизменённой программы, то о безопасности можно и не вспоминать. > > Пример с SSH с "наивным" обменом ключами -- это кривой пример, не зря в OpenSSH поддержку CA сделали.
Человек просто получает фан, рассказывая как он "взломал военную систему" в которой приложения работающие потом на мобильниках скачиваются рядовыми пехотинцами по интернету, а после скачивания пехотинцы должны еще зайти и зарегистрироваться в системе.
На простейшие вопросы (и мои в том числе http://www.rsdn.ru/Forum/?uid=34906) ответить не может. Объяснения не читает. О безопасности не имеет никакого понятия, рассматривает не систему в целом, а отдельные элементы. Считает, что взлом небезопасного (с вшитыми ключами) транспортного уровня ломает всю систему (провайдеры могут воровать у банков? О технических и организационных мерах безопасности не имеет представления. Более того, не имеет представления о таких бытовых вещах, как системы электронных платежей по интернету с подтверждением платежей по SMS (как простейший пример безопасности основанной на третьей стороне).
Ничего странного, что в его бурной фантазии рождаются какие-то сложные многоуровневые системы, которые он приписывает своим оппонентам.
Здравствуйте, vdimas, Вы писали:
V>Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться. Уже было сказано, что ключи вшиты в прогу жестко. Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю. В отличие от.
Сам с собой тут споришь исключительно ты.
Всё что я говорил это то что затраты на инфраструктуру бутылки будут на несколько порядков больше чем на инфраструктуру сингулярити.
И достигается это за счет правильного дизайна сингулярити.
V>По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH...
Всё больше и больше фактов.
Теперь оказывается не только, в программу вшиты ключи, но её еще и через https качают.
Единственное слабое место тут это CA.
Но если CA свой. И в браузере есть только корневой сертификат этого CA, то данная схема не ломается.
А на служебных девайсах так оно и будет.
V>опять и снова показав, что дыра всегда в инфраструктуре.
Ничего кроме своего невежества ты в очередной раз не показал.
V>Кароч, хоть ты сейчас и пытаешься делать вид, что что-то знал и понимал с самого начала — поздно, все ходы записаны. Каждый твой пост как буд-то не имеет связи с предыдущим, а весь смысл можно заменить на "Баба Яга против!".
Это ты про себя?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Дарю : "Ладно, я слился. Но на всё есть много точек зрения и, следовательно, я не слился."
Ну, ок, ты слился. ))
Нет никаких "много точек зрения" в природе. Определение ссылочной прозрачности простое и однозначное. Просто, любые рассуждения, что ссылочная прозрачность достижима без набившей оскомину имммутабельности, скажем так, не соответствуют "генеральной линии партии" на этом сайте... А кое-кому откровенно взрывает моск. ))
Здравствуйте, Иван Дубров, Вы писали:
ИД>Пример с SSH с "наивным" обменом ключами -- это кривой пример, не зря в OpenSSH поддержку CA сделали.
Я ХЗ почему это кривой пример, это наиболее популярный сценарий шифрования на сегодня. То, как оно обстоит на самом деле, это малость не то, как оно должно быть в идеальном мире. Просто тут некоторые тоже заведомо считали SHH вершиной безопасности, а я показываю свою практически ежедневную практику и эффект от того, что все прописанные процедуры поддержки инфраструктуры на самом деле сугубо вербальные соглашения, которые никто никогда не соблюдает. Пример насчет отпечатка — характерный. Насчет импорта неизвестных сертификатов — тем более.
Здравствуйте, grosborn, Вы писали:
G>Человек просто получает фан, рассказывая как он "взломал военную систему" в которой приложения работающие потом на мобильниках скачиваются рядовыми пехотинцами по интернету, а после скачивания пехотинцы должны еще зайти и зарегистрироваться в системе.
Почему пехотинцы-то? Что пехотинцы делают по всему миру?
G>Ничего странного, что в его бурной фантазии рождаются какие-то сложные многоуровневые системы, которые он приписывает своим оппонентам. G>Это либо клиника либо самозабвенный троллинг.
Дык, подрбности я даже в личке далеко не всем выдам. А насчет многоуровневости и где там надо считать уровни "прохождения" при ломке — показательно, что ты не понял ни слова.
Зато опять отметился в форуме. Ну, молоток.
Здравствуйте, WolfHound, Вы писали:
V>>Кароч, вода, одна вода. Тут уже всё было сказано более чем подробно, а ты продолжаешь вертеться. Уже было сказано, что ключи вшиты в прогу жестко. Исходник у меня. Пример я привел исключительно с целью показать для предыдущего спора об операцинках, что безопасность зависит не столько от безопасного языка (см. обсуждение), сколько от всей инфраструктуры. Коллега Wolfhound спорил с этим до хрипоты, а потом ровно это же мне опять до хрипоты доказывал. Я над ним измываюсь и получаю от этого фан, более ничего. Он уже дважды сам с собой в этой теме ожесточенно спорил. Но мне интересны доводы со всех сторон, ес-но, так что я этот спор с самим собой тоже внимательно читаю. В отличие от. WH>Сам с собой тут споришь исключительно ты.
Заметно. ))
WH>Всё что я говорил это то что затраты на инфраструктуру бутылки будут на несколько порядков больше чем на инфраструктуру сингулярити.
Описанный пример показывает, насколько это далеко от истины. Рассмотренной инфраструктуре вообще пофиг какая операционка.
WH>И достигается это за счет правильного дизайна сингулярити.
Идентичная внешняя безопасность достигается это за счет идентичной инфраструктуры. А насчет безопасности — см. мои посты об артефактах безопасности. Атрибуты в исходном коде в Сингулярити в сравнении с этим — детсад. Не пригодно для реальной работы.
V>>По конкретно приведенному мною факту никакой магии: помня, как я зарегистрировал свой тестовый виртуальный "девайс" в этой сети я увидел пример дыры в инфраструктуре. То бишь да, скачивать по и-нету эту прогу заведомо опасно. Но ее скачивают. Дают людям логины и пароли на https — они и качают. По мне — детсад, все замечания относительно технологии вокруг SLL я привел на примере SSH... WH>Всё больше и больше фактов. WH>Теперь оказывается не только, в программу вшиты ключи, но её еще и через https качают.
А есть принципиальная разница через https или SSH/SCP? А ты пользуешься только IE, который изкаробки, или ты шаришься по и-нету де-факто со стороннего браузера? ))
Спасибо за очередной фан.. впрочем, как всегда. Надеюсь, ты понял насчет неразвитой мысли о стороннем браузере. Для того, кому я отвечал предыдущим постом развивать нет смысла, ес-но.
WH>Единственное слабое место тут это CA. WH>Но если CA свой. И в браузере есть только корневой сертификат этого CA, то данная схема не ломается. WH>А на служебных девайсах так оно и будет.
Тебя забыли спросить, как оно будет. А по факту не так. Программа портирована на многие мобильные платформы, покупаешь девайс, качаешь ПО, регистрируешь ноду. Всё. Преднаначена для связи по всему миру, ес-но. Хочешь игнорить реальные сценарии — твои проблемы. Как можно добавить защиты — заведомо известно. Но я тебе уже приводил аналогию использования серверной ОС в кач-ве десктопной в ответ на твои предложения "всё запретить из коробки" для десктопных осей. Похоже, ты ниче не понял насчет неюзабельности.и как следствия нереальности таких сценариев.
V>>опять и снова показав, что дыра всегда в инфраструктуре. WH>Ничего кроме своего невежества ты в очередной раз не показал.
Толсто и как всегда умозрительно.
V>>Кароч, хоть ты сейчас и пытаешься делать вид, что что-то знал и понимал с самого начала — поздно, все ходы записаны. Каждый твой пост как буд-то не имеет связи с предыдущим, а весь смысл можно заменить на "Баба Яга против!". WH>Это ты про себя?
Это про любителей черпать знания из вики и размахивать затем ими.
Здравствуйте, Sinclair, Вы писали:
S>А при выполнении global flow analysis компилятору совершенно наплевать на ваши ручные аннотации — он и так увидит, где имеет место ссылочная прозрачность, а где — нет. S>Что тут непонятно?
Непонятна твоя т.з. до сих пор, более ничего. Ес-но меня global flow analisis не интересует, лично мне, как программисту, он не поможет никак. Пример с возможностью создать безопасный иммутабельный тип даже на C# без встроенной поддержки иммутабельных типов разве ни о чем тебе не говорит? (если не брать во внимание хаки через рефлексию)
Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ. Причем, мне эта безопасность требуется для мутабельного варианта в т.ч. Для мутабельных сценариев требуются гарантии видимости (то бишь локальности) происходящего и ничего более. Требовать иммутабельности для мутабельных сценариев — это какой-то заведомо цирк.
Как описывать это безопасное АПИ — я показал более одного раза. Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак. Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал. Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince? Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность? Аналогично насчет моих const и clean. Только мне легче гораздо, бо компилятор много чего контроллирует.
Да, модификатор const в С++ проблематичный, ес-но. Помимо встроенных в язык хаков, есть такая фигня, что константность не распространяется на мемберы ссылочных типов. В общем, в критике const в С++ ты ни разу не попал действительно по адресу реально существующих проблем, а только демонстрируешь раз за разом непонимание семантики const:
Именно из-за того, что ему неизвестно, ссылается ли переданная в данный фрагмент ссылка на const реально ссылкой на const или ссылкой на mutable.
Здравствуйте, vdimas, Вы писали:
V>Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ.
Инструмент для этого подходит любой. Безопасные АПИ можно клепать хоть на K&R С. Вот только доказать это не удастся.
V>Как описывать это безопасное АПИ — я показал более одного раза.
V>Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак.
Я показал, и неоднократно, как ваше "безопасное" АПИ ломается на раз-два.
V>Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал.
Да никак их не вылечить.
V>Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince?
Нет никакой rocket science. Есть упорное непонимание в лице одного субъекта того, как работает компилятор.
V>Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность? "Визуально"... Визуально я и в С могу найти. А могу — не найти. Нету в шарпе (и вообще в дотнете) средств статически проверить иммутабельность. Система типов не та.
V>Аналогично насчет моих const и clean. Только мне легче гораздо, бо компилятор много чего контроллирует.
Я же показал вам пример с вашим const и clean, который показывает, что никаких гарантий такой clean не даёт.
V>Да, модификатор const в С++ проблематичный, ес-но. Помимо встроенных в язык хаков, есть такая фигня, что константность не распространяется на мемберы ссылочных типов. В общем, в критике const в С++ ты ни разу не попал действительно по адресу реально существующих проблем, а только демонстрируешь раз за разом непонимание семантики const:
Ещё раз объясню: я прекрасно понимаю семантику const. Это вы не понимаете, почему она бесполезна.
Вы показали ровно один изолированный пример, где время жизни идентификатора полностью контролируется компилятором.
Шаг вправо-влево — и всё, никаких бенефитов. V>Вот этот пример читал: http://www.rsdn.ru/forum/philosophy/4838650.1.aspx
?
Читал. Отлично. То есть вся ссылочная прозрачность действует ровно в пределах одного метода, на локальную переменную, и только до тех пор, пока мы не произвели вызов, где ссылка на неё фигурирует в качестве не-конст параметра.
Это и есть ваше "константность прекрасно распространяется"?
В вашем примере компилятор не может оптимизировать код foo — по причине, которую я вам уже семь раз изложил, а вы полагаете эту причину "непониманием семантики const". Ну так код foo и надо в первую очередь оптимизировать! В случае нормальной архитектуры вы строите код из отдельных модульных кусочков. Вся реальная работа происходит где-то внутри функций, а не в клее, которым вы их соединяете. И как раз там нет никакой пользы от константности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
> G>Человек просто получает фан, рассказывая как он "взломал военную систему" в которой приложения работающие потом на мобильниках скачиваются рядовыми пехотинцами по интернету, а после скачивания пехотинцы должны еще зайти и зарегистрироваться в системе. > > Почему пехотинцы-то? Что пехотинцы делают по всему миру?
А кто, военные разведчики что ле? И сливают военные секреты в штаб по мобилам? И эту систему починить тебя просил какой-то штирлиц из соседнего подъезда, приехавший в отпуск на выходные? Ну типа "братан, помоги, когда отправляю разведданные в центр мобила пишет что-то не по нашенски".
Или может быть ракетные войска? Так-то обычно они по гугл-мапс наводятся, что наши что американы, но вот помня что американы все-время лажались из за того что мапс не обновлялась вовремя (то госпиталь разбомбят, то гостиницу с журналистами), наши решили отправлять наводчиков с мобилами на место перед бомбежкой, для надежности.
> G>Ничего странного, что в его бурной фантазии рождаются какие-то сложные многоуровневые системы, которые он приписывает своим оппонентам. > G>Это либо клиника либо самозабвенный троллинг. > > Дык, подрбности я даже в личке далеко не всем выдам. А насчет многоуровневости и где там надо считать уровни "прохождения" при ломке — показательно, что ты не понял ни слова. > Зато опять отметился в форуме. Ну, молоток.
Главный молоток тут ты. Насочинялся до взлома восьмиуровневых систем, когда не умеешь пользоваться даже одноуровневой.
Здравствуйте, Sinclair, Вы писали:
V>>Мне нужен ИНСТРУМЕНТ, чтобы я мог описывать типы с безопасными АПИ. S>Инструмент для этого подходит любой. Безопасные АПИ можно клепать хоть на K&R С. Вот только доказать это не удастся.
Из-за ссылочной непрозрачности, так ведь? На С++ сегодня аналогично — невозможно. Медицинский факт. Нужен некий предложенный мною clean (он же pure в D2). Нужно убрать хаки константности. Нужно распространять константность на значения, располагаемые по адресу из ссылочных типов.
V>>Как описывать это безопасное АПИ — я показал более одного раза. S>
V>>Что мне для этого надо — уже пояснил. Без хаков ты это безопасное АПИ не сломаешь никак. S>Я показал, и неоднократно, как ваше "безопасное" АПИ ломается на раз-два.
Оно никак не ломается даже в твоих примерах. Дай ссылку или скопируй сюда самый каверзный из приведенных — я разберу его пошагово. А так же покажу как допилить до безопасного варианта, если требуется. Безопасность определяется в ТЗ, ес-но, и более ничем.
Столкновение происходит сугубо в твоём понимании семантики const. Я специально заменил его на "ref in" на шарпоподобном языке, чтобы семантика более соответствовала названию модификатора переменной-аргумента. Другой семантики у const НЕТ, и ты ругаешь за то, что ееё нет. Но это обсуждение в никуда. Я вызвался расписать безопасный сценарий именно в этой семантике. Почему мне не нужна явная иммутабельность — уже говорил. Потому, что это прибитые гвоздями ограничения к типам, а мне надо над одними и теми же данными разрабатывать чистые и нечистые алгоритмы. Выделенное ключевое. Помнишь, я тебе обрисовывал сценарий устойчивого к исключениям кода? ИМХО, в пространстве иммутабельности это заведомо невоможно без лишних приседаний/копирований. Может я и ошибаюсь — тогда покажи как это возможно.
V>>Как вылечить твои примеры, чтобы они были безопасными — я тоже уже комментировал. S>Да никак их не вылечить.
Ты давай ТЗ, а я дам решение. А то пока что были сниппеты кода, от которых ты безосновательно много чего хотел.
V>>Ты можешь привести любой пример и я покажу как его вылечить. Я ХЗ где здесь rocket scince? S>Нет никакой rocket science. Есть упорное непонимание в лице одного субъекта того, как работает компилятор.
Он работает, как ему скажешь. Если ты ему дал кривой код, он честно его скомпилит и выполнит.
V>>Если бы ты описывал иммутабельный объект на C# разве ты был бы не в состоянии визуально обнаружить некую ошибку, нарушающую эту иммутабельность? S> "Визуально"... Визуально я и в С могу найти. А могу — не найти. Нету в шарпе (и вообще в дотнете) средств статически проверить иммутабельность. Система типов не та.
Воот, а в С++ есть. ))
Даже замечание насчет кривизны распространения константности на ссылочные переменные-мемберы разруливается устоявшимся способом:
template<typename T>
class SmartPtr {
T * target_;
...
T * get() { return target_; }
const T * get() const { return target_; }
}
Просто мне бы хотелось автоматического распространения... И, хотя для указателей это было бы проблематично из-за семантики адреса как значения, то уж для ссылок могло быть автоматом.
V>>Аналогично насчет моих const и clean. Только мне легче гораздо, бо компилятор много чего контроллирует. S>Я же показал вам пример с вашим const и clean, который показывает, что никаких гарантий такой clean не даёт.
Дает. Просто ты настаиваешь на гарантиях для вызываемого кода. Похоже, ты забыл какое отношение у вызываемого и вызывающего кода, оно многие к одному со стороны вызывающего кода. В тех случаях, где ссылочная прозрачность УЖЕ нарушена, там искать ее распространения наивно. Но в других сценариях, где ссылочная прозрачность некоего локального значения не нарушена, там вызов той же самой ф-ииеё НЕ нарушит. Только это мне и важно. Просто const и clean позволят не контроллировать сколь угодно глубоко зависимости визуально, накладывая транзитивно распространяемые ограничения.
V>>Да, модификатор const в С++ проблематичный, ес-но. Помимо встроенных в язык хаков, есть такая фигня, что константность не распространяется на мемберы ссылочных типов. В общем, в критике const в С++ ты ни разу не попал действительно по адресу реально существующих проблем, а только демонстрируешь раз за разом непонимание семантики const: S>Ещё раз объясню: я прекрасно понимаю семантику const. Это вы не понимаете, почему она бесполезна. S>Вы показали ровно один изолированный пример, где время жизни идентификатора полностью контролируется компилятором.
Ес-но. И трекается глазами программиста. Это необязательно могла бы быть константа. Это может быть откуда-то полученное значение, сохраненной во временной переменной. По-сути, каждая новая строчка кода может оперировать над данными, у которых ссылочная прозрачность соблюдена, а может нет. Я могу делать такие выводы, трекая в уме алгоритм, протаскивая по коду ссылочную прозрачность, ориентируясь на сигнатуры вызываемых ф-ий/методов. Заметь, operator=() [присвоение] — точно такая же сигнатура некоей ф-ии. Это ключ к пониманию твоих собственных примеров.
При наличии инструмента описания безопасного АПИ всех объектов, начиная с самого нижнего уровня, я просто буду охотиться за гораздо меньшим кол-вом ошибок в нейтивных программах. Ведь с виду в коде всегда всё правильно, но где-то "унутре" возникают самые разнообразные сочетания эффектов. А транзитивная распространяемость модификатора clean поможет мне в случае, если я забыл о нем на некоем низлежащем уровне, то уж вышестоящий мне "напомнит". И не будет никаких эффектов "унутре".
S>Шаг вправо-влево — и всё, никаких бенефитов. V>>Вот этот пример читал: http://www.rsdn.ru/forum/philosophy/4838650.1.aspx
? S>Читал. Отлично. То есть вся ссылочная прозрачность действует ровно в пределах одного метода, на локальную переменную, и только до тех пор, пока мы не произвели вызов, где ссылка на неё фигурирует в качестве не-конст параметра. S>Это и есть ваше "константность прекрасно распространяется"?
Да именно, это и есть определение ссылочной прозрачности. Я хочу точно знать, что происходит с КАЖДЫМ локальным значением в КАЖДОЙ ф-ии/методе, когда передаю не копию значения, а ссылку. Весь мой код состоит из ровно таких же ф-ий/методов, так что мне гарантий в пределах одного метода — более чем достаточно.
S>В вашем примере компилятор не может оптимизировать код foo — по причине, которую я вам уже семь раз изложил, а вы полагаете эту причину "непониманием семантики const". Ну так код foo и надо в первую очередь оптимизировать! В случае нормальной архитектуры вы строите код из отдельных модульных кусочков. Вся реальная работа происходит где-то внутри функций, а не в клее, которым вы их соединяете. И как раз там нет никакой пользы от константности.
==============
Почему я, собсно, мусолю эту тему. Низлежащая современная модель вычислений железок, увы, доживет до моей смерти как профессионала. До твоей тоже. Это очередной медицинский факт. То бишь надо исходить из того, что есть. За ситуацией в суперкомпиляции я слежу с периодичностью раз в год примерно... На сегодня эта ситуация еще не преодолела зачаточный уровень и не скоро преодолеет — никаких предпосылок. Буквально единицы лет назад в академических кругах научились делать "суперкомпиляторный анализ" императивного кода, до этого вообще был детский сад, представляющий из себя чуть продвинутую бета-редукцию над ФП. Почему так медленно идёт движение в этой области? Любое ветвление в программе — это лишний множитель комбинаторного кол-ва вариантов исполнения, то бишь сложность анализа от сложности алгоритма — степенная. Современные компиляторы проводят анализ в самых простейших случаях до 10 уровней глубины, в сложных — дай бог 2-3. Исходники gcc открыты, можно посмотреть самому. Понимаешь, из-за степенной природы происходящего, наблюдаемая вроде бы неплохая геометрическая прогрессия в росте мощщи железа ничего кроме пессимизма не вызывает. Ни ты, ни я не увидим "золотого века IT". Например, gcc в последних версиях медленно но верно догоняет MS VC по эффективности конечного образа. Именно поэтому gcc таки относительно скоро нагонит MSVC, что он его настигнет прямо в точке насыщения возможностей, выжимаемых из машин разработчиков. Это я всё к тому, что в течении ближайших 10-20 лет никакое самое вылизанное ФП по эффективности не догонит аналогично вылизанный императив даже близко. На плюсах я сижу неплотно лет 20, плотно более 15 лет. Все их достоинства и недостатки собственной задницей ощущал не раз, так же как знаю как с ними бороться. Я могу выжимать из машины максимум, умею это и люблю. Помимо выжимания, есть определенные способности находить нетривиальные ошибки даже в чужом коде. Считай, у меня в сформировалась некая статистика по причинам всех этих ошибок. Самые популярные, ес-но, не те ярлыки, которые навешивают на плюсы — типа выхода за границы диапазонов. Самые популярные сегодня — это неверное представление о работе собственных многопоточных программ, иногда откровенные гонки. Причем, эти гонки не из-за непоходимости разработчиков, ес-но, а из-за всего здесь обсуждаемого, из-за скрытого неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев. Обычный разработчик уже на глубину более 3-х уровней зависимостей смотрят с ооочень большим трудом и не часто. В идеале хотелось бы 1 уровень. И мне/нам обсуждаемые языковые ср-ва помогут заметно сэкономить на отладке. А если брать предлагаемую банальную иммутабельность — наоборот, добавит работы и снизит эффективность решения. С другой стороны, видя здесь резкую реакцию на "выскочку, идущую против генеральной линии партии", таки есть сомнения — что я еще не увидел? Вдруг есть еще кое-какие моменты?
Просто пока что в меня тыкали примерами, скажем, заведомо нерелевантными обсуждаемому. Все примеры отталкивались от некоего гипотетического требования к семантике const, которого (1) нет и (2) мне, как разработчику на этом языке — не нужно (по приведенным в 3-й раз причинам).
===========
