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

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

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Опять двойка по ассемблеру. Подумай, не может ли состояние стека измениться вообще без выполнения каких бы то ни было команд
S>>>Конечно же может. Но к модели "память/регистры" это по-прежнему ничего не добавляет.
PD>>К модели не добавляет. А вот к утверждению "это просто CISC-шорткат для инструкций косвенной адресации" еще как добавляет.
S>И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov?

Изменение стека помимо исполнения команды, являющейся шорткатом и т.д.

>Ты блин как прапорщик: "не из дерева, а из того же материала". Я советую тебе научиться отличать знание от понимания.

Ну опять ты... Надоело.

PD>>В .Net вы гарантируете, что никто без unsafe не сможет вообще никуда в неположенное место обращаться. Так что уж позаботьтесь о том, чтобы только реализация константных конструкторов могла туда обращаться. В конце концов этих самих адресов я в .Net вообще не вижу. они там внутри где-то. Ну и манипулируйте ими корректно.
S>Еще раз, медленно повторяю: поскольку мы уже гарантировали отсутствие обращений в неположенные места, никаких VirtualProtect не надо. Зачем заниматься этим онанизмом?

Что за чушь ? Я же вроде ясно написал — никаких VirtualProtect не надо. Ты идею понял или нет ?

S>Это же индусокод:

Отправлен к индусам.

PD>>Ну а в С++, конечно, никто такой гарантии не даст, но это обычная проблема — никто же не даст гарантии, что кто-то просто левым способом не испортит вполне обычную переменную.
S>Я тебе об этом и пишу. В одном мире эта идея бессмысленна, в другом — бесполезна.

Ну-ну

>Что не мешает ей оставаться красивой, как произведение программерского искусства

S>>>Наверное, лучше было бы сделать так, чтобы компилятор не давал делать такие вызовы, не так ли? Зачем компилировать заведомо некорректную программу?
PD>>Ну мы опять за то же. Нет, не лучше.
S>А можно пример, в котором компилируемость невалидной программы позволит получить хоть какие-то преимущества?

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

PD>>Я тебе уже говорил — ставя иммутабельность на тип, ты подвергаешься очень серьезным ограничениям. В реальной жизни нужно иметь и переменные этого типа и константы.
S>Павел, ты просто, похоже, не понимаешь, что такое "тип". Еще раз, медленно пишу, читай не торопясь: у тебя есть экземпляр a, класса A. Но у этого экземпляра запрещено вызывать метод A::setx(). Почему ты так настойчиво хочешь считать, что тип этого экземпляра — такой же, как и у экземпляра b? Ведь у экземпляра b можно вызывать метод setx()! С точки зрения математики, теории типов, да и просто здравого смысла a имеет совсем другой тип, чем b — у них разные контракты.

Меня эта схоластика мало интересует. Тип в данных рассуждениях — это просто тип в смысле языка, а это понятие 100% конкретное. Тот факт, что для некоторых экземпляров этого типа вызов некоторого метода будет работать, а для некоторых нет — это и есть мое утверждение. Философские рассуждения о том, что есть тип меня сейчас мало интересуют.

S>А вот если я "хочу получить сконструированный кем-то другим объект, который никто не может менять" — упс, облом.

Это почему же ? Если этот кто-то другой лежит в пределах моего процесса — ничего нового, если он сконструировал этот объект как константу. Если за пределами процесса — тогда вопрос, как он его передал — как константу или нет. Ничего нового.



S>Еще раз: поскольку ситуации, когда иммутабельный объект в течение своей жизни внезапно становится мутабельным, не бывает, то никакого смысла откладывать проверку до рантайма нет. Достаточно проверять всё статически.

Ладно, хватит. Либо ты не понял, либо из принципа делаешь вид, что не понял.

S>Павел, твоя идея просто не работает. Вот напиши мне пример функции, которая требует константный объект, сконструированный за её пределами.
S>На любом языке — С, С#, С++, Pascal.

Я тебе 10 раз повторял — речь идет о необходимости добавить кое-что для этой цели в язык.

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

PD>Если в существующем софте есть ошибка, то все возможно. Но по постингу WolfHound можно понять так, что достаточно переполнить буфер , и мы попадем в страницы, находящиеся под контролем системы. А причина банальная — он не вполне понимает отличие виртуальной памяти от физической, он считает, что если выйти за пределы страницы, то мы попадем на соседнюю страницу физической памяти, которая может принадлежать системе
Опять фантазируешь на тему того что я что-то не понимаю.
Просвещайся http://en.wikipedia.org/wiki/Buffer_overrun

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

S>Получается, что нужен какой-то другой язык. В котором правила совместимости типов жестче. Или не пользоваться зависимыми типами из С++, а вместо этого описывать иммутабл-тип руками для каждого конкретного случая (как и сделано в дотнете).
Еще раз: В С++ нет зависимых типов. Пожалуйста не разводи путаницу.

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

C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
Обязательно вытеснит, но не обязательно верифицмруемый.

C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Обязательно вытеснит, по крайней мере из прикладного кода.

C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Будет зависит от програмного и софтового окружения.

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

C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?
M>Обязательно вытеснит, но не обязательно верифицмруемый.
А на кой черт нужен не верифицируемый промежуточный код?
Это же не имеет никакого смысла.

Здравствуйте, Pavel Dvorkin, Вы писали:
S>>И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov?
PD>Изменение стека помимо исполнения команды, являющейся шорткатом и т.д.
Чего? Что такое "изменение стека"?

PD>Что за чушь ? Я же вроде ясно написал — никаких VirtualProtect не надо. Ты идею понял или нет ?
Я — понял. Я не понял зачем она. У нас уже гарантируется отсутствие попыток записи в иммутабл объект. Зачем еще RO флаги?

PD>А можно способ привести, с помощью которого для серьезной программы определяется, что валидно, а что нет ? Только не слова, а ссылку на реальный софт, которому я свою программу подсуну, а она пусть и скажет.
Ничего не понимаю. Вот ты привёл пример программы:

int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, heapsize,NULL);
    char* pHeapRW = (char*)MapViewOfFile(hMapping, FILE_MAP_WRITE, 0, 0, heapsize);
    char* pHeapRO = (char*)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, heapsize);
    delta = pHeapRW - pHeapRO;

        // все вышенаписанное, конечно, в класс HeapManager

    A* pA = (A*) pHeapRO; // прототип выделения памяти в куче, то есть операции newconst. Я просто беру начало кучи
    pA->Ctor(100); // прототип вызова конструктора
    int y = pA->getx(); // эту функцию можно вызывать, она объект не изменяет. Хотя явно const в ней специально не написано
    pA->setx(99); // а эту нельзя, здесь AV

    // очистка и обработка ошибок опущены

    return 0;
}

Она гарантированно невалидна — ты вызываешь в ней AV. Зачем ждать её запуска, если я и так могу сказать, что AV будет? Это должно быть ошибкой компиляции. Способ обнаружить это — очень простой: в месте вызова смотрим, какого типа pA, и определяем, можно ли для этого типа делать этот вызов. Тебя, я надеюсь, не удивляет, что компилятор пресекает попытки вызова private мемберов? А ведь тоже можно было бы эмулировать модификатор private при помощи аппаратной защиты. Я уверен — тебе не составит труда построить такой оператор newprivate, который подправит нужным образом значения слотов VMT.

PD>Меня эта схоластика мало интересует. Тип в данных рассуждениях — это просто тип в смысле языка, а это понятие 100% конкретное. Тот факт, что для некоторых экземпляров этого типа вызов некоторого метода будет работать, а для некоторых нет — это и есть мое утверждение. Философские рассуждения о том, что есть тип меня сейчас мало интересуют.
Это не схоластика. const int& — по-твоему схоластика? Ничего, что это другой тип, чем mutable int& ?

S>>А вот если я "хочу получить сконструированный кем-то другим объект, который никто не может менять" — упс, облом.
PD>Это почему же ? Если этот кто-то другой лежит в пределах моего процесса — ничего нового, если он сконструировал этот объект как константу.
Еще раз, пишу медленно: как ты обеспечишь выполнение этого "если"?

PD>Ладно, хватит. Либо ты не понял, либо из принципа делаешь вид, что не понял.
Это ты не понял. Мне твоя идея понятна на 100%, ничего в ней военного нет.
PD>Я тебе 10 раз повторял — речь идет о необходимости добавить кое-что для этой цели в язык.
Ну покажи пример того, о чём я говорю, на гипотетическом языке, в который это "кое-что" добавлено.

Здравствуйте, WolfHound, Вы писали:
WH>Еще раз: В С++ нет зависимых типов. Пожалуйста не разводи путаницу.
Некоторое подмножество-то есть.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>>>И что именно оно добавляет к этому утверждению? Что там такого происходит со стеком, что невыразимо в терминах inc ESP и mov?
PD>>Изменение стека помимо исполнения команды, являющейся шорткатом и т.д.
S>Чего? Что такое "изменение стека"?

PD>>Что за чушь ? Я же вроде ясно написал — никаких VirtualProtect не надо. Ты идею понял или нет ?
S>Я — понял. Я не понял зачем она.

Тьфу, черт! Вчера я предложил эту функцию использовать. Сегодня я отменил это предложение. Его больше нет. А мне в ответ — зачем она тут ? Как с тобой разговаривать-то ?


S>Ничего не понимаю. Вот ты привёл пример программы:

<skipped>

S>Она гарантированно невалидна — ты вызываешь в ней AV.

А откуда это тебе известно, если не секрет ? Это я тебе сказал. А мог бы и не сказать. Вот теперь забудь, что я тебе это сказал и докажи, что она невалидна. Автоматически. А хочешь, я ее мигом валидной сделаю (правда, она при этом перестанет делать то, для чего она написана). Для этого надо всего лишь FILE_MAP_READ на FILE_MAP_WRITE поменять, и будет 2 проекции, обе R/W, и никакого AV.

>Зачем ждать её запуска, если я и так могу сказать, что AV будет?

Вот и расскажи, как ты это можешь до запуска определить. А еще скажи, как ты это сможешь до запуска определить, если этот несчастный флаг окажется параметром командной строки или будет вводиться с консоли во время исполнения

Чепуху говорить не надо.

Все остальное skipped, поскольку надоело.

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

WH>>Еще раз: В С++ нет зависимых типов. Пожалуйста не разводи путаницу.
S>Некоторое подмножество-то есть.
Если так рассуждать то в любом статически типизированном языке есть некоторое подмножество
Как ты собираешься на С++ выразить

mult : ∀i , j , k : Nat ⇒ Matrix i j → Matrix j k → Matrix i k

при условии что i, j и k не известны на этапе компиляции?

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

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

C>>>Или его со временем полностью вытеснит верифицируемый промежуточный код?
M>>Обязательно вытеснит, но не обязательно верифицмруемый.
WH>А на кой черт нужен не верифицируемый промежуточный код?
WH>Это же не имеет никакого смысла.

Посмотри LLVM
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine

Думаю там можно найти и описание мотивации к созданию.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тьфу, черт! Вчера я предложил эту функцию использовать. Сегодня я отменил это предложение. Его больше нет. А мне в ответ — зачем она тут ? Как с тобой разговаривать-то ?
Нормально разговаривать. Например, попробовать всё-таки понять, какой именно выигрыш даст защита памяти (неважно, через вызов VirtualProtect или через аргумент FILE_MAP_READ) программе, про которую еще до запуска известно, что она не станет пытаться менять константные объекты.

PD>А откуда это тебе известно, если не секрет ? Это я тебе сказал. А мог бы и не сказать. Вот теперь забудь, что я тебе это сказал и докажи, что она невалидна.
PD>Автоматически.
Это понятно, что для твоей программы ничего доказать нельзя. Ну, потому что она написана на языке, который не позволяет выразить ничего полезного про иммутабилити.
И как раз в этом проблема и есть: ну сделал ты этот объект в защищенном регионе, и что с того? Какую пользу ты с этого получишь?
Ты же за пределами своего _tmain() не имеешь права полагаться на неизменность этого объекта. А именно это-то и нужно! Самой _tmain от неизменности *pA пользы нет. Польза была бы неким алгоритмам, в которые _tmain этот pA отдаёт.

PD>А хочешь, я ее мигом валидной сделаю (правда, она при этом перестанет делать то, для чего она написана). Для этого надо всего лишь FILE_MAP_READ на FILE_MAP_WRITE поменять, и будет 2 проекции, обе R/W, и никакого AV.
Не, не хочу.

>>Зачем ждать её запуска, если я и так могу сказать, что AV будет?

PD>Вот и расскажи, как ты это можешь до запуска определить. А еще скажи, как ты это сможешь до запуска определить, если этот несчастный флаг окажется параметром командной строки или будет вводиться с консоли во время исполнения
PD>Чепуху говорить не надо.
Вот это полностью применимо к предыдущей фразе. Павел, ты не виляй, ты покажи пример реальной проблемы, которую ты решаешь вот этой своей загогулиной. Покажи реальный пример, где константность либо неконстантность создаваемого объекта действительно может определяться в рантайме, "параметром командной строки".

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

WH>Если так рассуждать то в любом статически типизированном языке есть некоторое подмножество
Ну конечно же не в любом. Скажем, в Паскале нельзя взять, к примеру, тип "ссылка на А" и получить из него тип "константная ссылка на А".
Способы конструирования типов на С++, конечно же, не шибко развиты, но всё-таки они есть.

WH>Как ты собираешься на С++ выразить
WH>при условии что i, j и k не известны на этапе компиляции?
Никак не собираюсь. Поскольку язык статически типизирован, то и типы у него будут полностью статическими. Так что все зависимости тоже будут статически резолвится.
Увы, Павел не может понять даже такие, статически зависимые типы. Несмотря на то, что в его любимом языке они есть.

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

M>Посмотри LLVM
M>http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine
Я видел.

M>Думаю там можно найти и описание мотивации к созданию.
Бекенд для компилятором. Чисто чтобы каждый раз не писать кодогенератор и оптимизатор.
Проблема в том что LLVM не дает качественного улучшения программ.
А верифицируемый код дает.
Более того благодаря тому что для верифицируемого кода доступно множество доказательств его еще и оптимизировать можно сильнее.
Не говоря уже о том что верифицируемый код гораздо проще транслировать в разные волшебные базисы в которых легко делается суперкомпиляция.

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

M>>Думаю там можно найти и описание мотивации к созданию.
WH>Бекенд для компилятором. Чисто чтобы каждый раз не писать кодогенератор и оптимизатор.

Мне кажется основной мотив это переносимость и универсальность.

WH>Проблема в том что LLVM не дает качественного улучшения программ.
Не вижу способа который мог бы дать.

WH>А верифицируемый код дает.
Не вижу способа который мог бы дать.


WH>Более того благодаря тому что для верифицируемого кода доступно множество доказательств его еще и оптимизировать можно сильнее.
Уверен что ошибаешься.

WH>Не говоря уже о том что верифицируемый код гораздо проще транслировать в разные волшебные базисы в которых легко делается суперкомпиляция.
И тут ошибаешся.

Преимущество неверифицируемого байт кода в том, что на его основе можно сделать в том числе и верефицируемый байт код. А наоборот нельзя, не потеряв производительность.

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

S>Ну конечно же не в любом. Скажем, в Паскале нельзя взять, к примеру, тип "ссылка на А" и получить из него тип "константная ссылка на А".
В паскале просто нет константности.
Но и в С++ это никакой не зависимый тип.
Это просто привидение к интерфейсу содержащему только не меняющие состояния методы.
Не более того.
Те это легко выражается на любом языке где есть интерфейсы. Хоть на C# хоть на Java.

S>Способы конструирования типов на С++, конечно же, не шибко развиты, но всё-таки они есть.
Нет.

S>Никак не собираюсь. Поскольку язык статически типизирован, то и типы у него будут полностью статическими. Так что все зависимости тоже будут статически резолвится.
Так в том то и прикол зависимых типов что зависимости времени исполнения проверяются статически.
Если же система типов не может проверять согласованность значений времени исполнения статически то она не содержит зависимых типов.
Система типов С++ не может делать таких проверок. А Agda, Epigram и некоторые другие могут.

S>Увы, Павел не может понять даже такие, статически зависимые типы. Несмотря на то, что в его любимом языке они есть.
Он вообще ничего что выходит за рамки WinAPI понять не может.

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

M>Преимущество неверифицируемого байт кода в том, что на его основе можно сделать в том числе и верефицируемый байт код.
Сильное утверждение. Хотелось бы как-то его доказать. Ну или хотя бы намекнуть, к примеру, как сделать на основе "неверифицируемого байт-кода x86" "верифицируемый байт-код x86".

M> А наоборот нельзя, не потеряв производительность.
Это еще более сильное утверждение. Его бы тоже хотелось доказать. Ну или хотя бы увидеть набросок соображений, по которым верифицируемый код обязан быть менее производительным, чем неверифицируемый.

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

WH>>А верифицируемый код дает.
M>Не вижу способа который мог бы дать.
M>Уверен что ошибаешься.
M>И тут ошибаешся.
Все ясно. С верой спорить бесполезно.
Отправляйся к Дворкину.

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

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

M>>Преимущество неверифицируемого байт кода в том, что на его основе можно сделать в том числе и верефицируемый байт код.
S>Сильное утверждение. Хотелось бы как-то его доказать. Ну или хотя бы намекнуть, к примеру, как сделать на основе "неверифицируемого байт-кода x86" "верифицируемый байт-код x86".
Я такого не утверждал , как пример
из "неверифицируемого байт-кода x86" "верифицируемый байт-код JAVA".

M>> А наоборот нельзя, не потеряв производительность.
S>Это еще более сильное утверждение. Его бы тоже хотелось доказать. Ну или хотя бы увидеть набросок соображений, по которым верифицируемый код обязан быть менее производительным, чем неверифицируемый.

Ок, не буду обобщать. Вполне возможно что удасться с будущими верефицируемыми кодами и желехом.

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

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

WH>>>А верифицируемый код дает.
M>>Не вижу способа который мог бы дать.
M>>Уверен что ошибаешься.
M>>И тут ошибаешся.
WH>Все ясно. С верой спорить бесполезно.
WH>Отправляйся к Дворкину.

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