Oberon space
General Category => Общий раздел => Тема начата: Губанов Сергей Юрьевич от Февраль 06, 2012, 11:41:33 am
-
Первая версия там: Зачем сборщик мусора? (http://oberspace.dyndns.org/index.php/topic,175.0.html)
::) ::) ::) поскольку мне известен правильный ответ на вопрос "Зачем сборщик мусора?", то я решил написать его в новом топике ::) ::) ::)
Смысл в следующем. Есть проблема порчи памяти. Она устраняется герметичной системой типов. Только автоматическая сборка мусора гарантированно устраняет повисшие указатели. Поэтому сборщик мусора является неотъемлемой частью герметичной системы типов.
Короче, сборщик мусора имеет смысл в составе герметичной системы типов, которая используется для победы над проблемой порчи памяти. Это всё.
-
Погоди. Зачем мне сборщик мусора в языке с герметичной системой типов (в том числе ссылок/указателей)?
Порчи памяти можно избежать без использования сборщика мусора на самом деле. То есть принципиально это возможно.
Кроме того, наличие сборщика мусора не гарантирует того, что в языке система типов будет герметичной.
-
Что значит "герметичная система типов"?
Знаю, что оберонщики любят хвастать тем, что у них в обероне эта самая "герметичная система типов". Но что они имеют под этим в виду?
-
Что понимается под словами "порча памяти" - эффекты связанные с фрагментацией (т.е. невозможность выделить кусок определенного размера в некоторой области и или деградация производительности при выделении памяти...) ?
-
Погоди. Зачем мне сборщик мусора в языке с герметичной системой типов (в том числе ссылок/указателей)?
Чтобы повисших указателей не было.Порчи памяти можно избежать без использования сборщика мусора на самом деле. То есть принципиально это возможно.
По повисшему указателю пишем и запарываем память. Кроме того, наличие сборщика мусора не гарантирует того, что в языке система типов будет герметичной.
Поэтому я написал, что сборщик мусора является частью герметичной системы типов, а не наоборот. Что значит "герметичная система типов"?
Комплекс мер статической и динамической типизации (а так же проверки индексов массивов) гарантирующий, что память не запорешь.
-
Комплекс мер статической и динамической типизации (а так же проверки индексов массивов) гарантирующий, что память не запорешь.
Т.е , говоря по русски - обязательная проверка индексов массива и достаточно жесткие ограничения на преобразования типов?
-
Первая версия там: Зачем сборщик мусора? (http://oberspace.dyndns.org/index.php/topic,175.0.html)
Полностью согласен с Сергеем. Принципиальный момент в наличии сборщика - это именно возможность построить платформу, гарантирующию целостность на уровне отдельных объектов (памяти). Точнее, тут от обратного проще сформулировать - без сборщика невозможно такую систему построить. Т.е., если к плюсам прикрутить сборщик, то никаких гарантий, конечно, не появится (поэтому и смысла у него там исчезающе мало). Но если наравне со сборщиком есть гарантии защиты памяти от прямого ковыряния в ней, то все хорошо. Все остальные свойства, который придает сборщик (как в рекламах жабы - не надо вручную delete писать и т.д.) - это уже шашечки и следствия.
-
Погоди. Зачем мне сборщик мусора в языке с герметичной системой типов (в том числе ссылок/указателей)?
Порчи памяти можно избежать без использования сборщика мусора на самом деле. То есть принципиально это возможно.
Не представляю как это можно сделать, не наворотив что-то еще более сложное, чем сборщик :)
Кроме того, наличие сборщика мусора не гарантирует того, что в языке система типов будет герметичной.
Это да...
-
Полностью согласен с Сергеем. Принципиальный момент в наличии сборщика - это именно возможность построить платформу, гарантирующию целостность на уровне отдельных объектов (памяти). Точнее, тут от обратного проще сформулировать - без сборщика невозможно такую систему построить. Т.е., если к плюсам прикрутить сборщик, то никаких гарантий, конечно, не появится (поэтому и смысла у него там исчезающе мало). Но если наравне со сборщиком есть гарантии защиты памяти от прямого ковыряния в ней, то все хорошо. Все остальные свойства, который придает сборщик (как в рекламах жабы - не надо вручную delete писать и т.д.) - это уже шашечки и следствия.
Если это так, то следует из этого ЯП программирования с мусорозборником и "герметичной" системой типов не удобен для системного программирования (является по сути языком для создания высокоуровневых приложений)?
-
Что понимается под словами "порча памяти"
int x = GetRandom();
byte* p = (byte*)x;
*p = 42;
-
Если это так, то следует из этого ЯП программирования с мусорозборником и "герметичной" системой типов не удобен для системного программирования (является по сути языком для создания высокоуровневых приложений)?
Это почему? В "системном программировании" память портить можно что ли?
-
Что понимается под словами "порча памяти"
int x = GetRandom();
byte* p = (byte*)x;
*p = 42;
Да, спасибо - я знаю что такое висящие ссылки.
-
Если это так, то следует из этого ЯП программирования с мусорозборником и "герметичной" системой типов не удобен для системного программирования (является по сути языком для создания высокоуровневых приложений)?
Это почему? В "системном программировании" память портить можно что ли?
Конечно нет но важна эффективность и удобство низкоуровневых преобразований переменных различных типов, работа с нетипизированными указателями... (которые пресекаются в ЯП с герметичной системой типов).
-
Зачем мне сборщик мусора в языке с герметичной системой типов (в том числе ссылок/указателей)?
Порчи памяти можно избежать без использования сборщика мусора на самом деле. То есть принципиально это возможно.
Проблема, вроде, не в том, что программист по своему недомыслию не освободит какой-либо указатель, а в том, что зачастую программист В ПРИНЦИПЕ не может определить пора уже освобождать вот этот вот указатель, или нет. И, если верить Куно Пфистеру, то такая ситуация сплошь и рядом встречается в компонентно-ориентированном программировании. Готовы ли Вы оспорить Пфистера по этому вопросу?
(Про себя могу сказать, что я не готов спорить с Куно Пфистером, но хотел бы разобраться глубже в этом вопросе)
-
Проблема, вроде, не в том, что программист по своему недомыслию не освободит какой-либо указатель, а в том, что зачастую программист В ПРИНЦИПЕ не может определить пора уже освобождать вот этот вот указатель, или нет. И, если верить Куно Пфистеру, то такая ситуация сплошь и рядом встречается в компонентно-ориентированном программировании. Готовы ли Вы оспорить Пфистера по этому вопросу?
(Про себя могу сказать, что я не готов спорить с Куно Пфистером, но хотел бы разобраться глубже в этом вопросе)
Я этот случай описал. Но этот случай, когда сборщик мусора таки нужен, возникает ну о-очень редко. И в основном тогда, когда мы сами не знаем что творим, посему вместо продукта делаем конструктор.
-
в основном тогда, когда мы сами не знаем что творим
Точнее говоря, когда мы используем то, что творим не мы. ;) Например, когда загружаем компоненту по сети.
-
если верить Куно Пфистеру, то такая ситуация сплошь и рядом встречается в компонентно-ориентированном программировании. Готовы ли Вы оспорить Пфистера по этому вопросу?
(Про себя могу сказать, что я не готов спорить с Куно Пфистером, но хотел бы разобраться глубже в этом вопросе)
Оспорить?.. Пусть себе рассуждает... Принцип простой, не нужен компонент, удаляй... нужен - подгружай и используй. Если ОС умная, она сама закэширует компонент при выгрузке, чтобы минимизировать затраты на загрузку.
Тот же принцип справедлив для любых внешних ресурсов: файлов, пайпов, сокетов и пр.
Единственный случай, когда необходим посредник между программой и ресурсом - это в случае разделяемого использования ресурсов, когда один и тот же ресурс используется в разных программах/в разных частях программы. Но в этом случае опосредовано происходит и загрузка ресурса (и, по-хорошему, любое обращение к ресурсу). Сдаётся мне, что GC для этого маловато... нужна полноценная система с продуманными сервисами.
-
Принцип простой, не нужен компонент, удаляй... нужен - подгружай и используй.
Думаю, что всё не так просто. Компоненты в известной мере независимы друг от друга. Если какой-то компоненте А перестала быть нужна другая компонента В, то компонента А не может взять и запросто освободить (удалить) компоненту В, потому что компоненту В, возможно, использует так же компонента С, но компонента А про это знать не обязана.
Если ОС умная, она сама закэширует компонент при выгрузке, чтобы минимизировать затраты на загрузку.
ОС не решит за нас наши проблемы. Во всяком случае, я в "волшебную" ОС не верю.
Сдаётся мне, что GC для этого маловато... нужна полноценная система с продуманными сервисами.
Вы имеете в виду RTS, с её метаданными обо всех модулях, классах, объектах, типах и других программных сущностях?
-
Вы имеете в виду RTS, с её метаданными обо всех модулях, классах, объектах, типах и других программных сущностях?
Нет, я имею ввиду систему, созданную для решения задач в конкретной предметной области.
-
Насчет компонент (для который вроде как требуется сборщик мусора).. Предлагаю ответить на два вопроса:
1) Что такое компоненты?
2) Какую задачу они решают (зачем они нужны)?
-
Насчет компонент (для который вроде как требуется сборщик мусора).. Предлагаю ответить на два вопроса:
1) Что такое компоненты?
2) Какую задачу они решают (зачем они нужны)?
Вопросы очень правильные. Но вот чётких и внятных ответов на них мне у адептов компонентно-ориентированного программирования так и не удалось получить. :( Собственно, я ни у кого ничего не спрашивал, просто читал опубликованные материалы.
Я мог бы привести здесь своё мнение на этот счёт. Но это мнение слишком слабо подтверждено практикой, и потому не стоит упоминания.
-
Вы имеете в виду RTS, с её метаданными обо всех модулях, классах, объектах, типах и других программных сущностях?
Нет, я имею ввиду систему, созданную для решения задач в конкретной предметной области.
Если я Вас правильно понял, заточка под "конкретную предметную область" заключается в формировании карт распределения памяти (в том числе). Означает ли это, что Вы свои прожекты "строчите" на ассемблере (или с ассемблерными вставками)?
-
Вы имеете в виду RTS, с её метаданными обо всех модулях, классах, объектах, типах и других программных сущностях?
Нет, я имею ввиду систему, созданную для решения задач в конкретной предметной области.
Если я Вас правильно понял, заточка под "конкретную предметную область" заключается в формировании карт распределения памяти (в том числе). Означает ли это, что Вы свои прожекты "строчите" на ассемблере (или с ассемблерными вставками)?
Нет, Вы традиционно неправильно трактуете то, о чём я пишу (если в этом виновато моё косноязычие, то приношу извинения, если же Вы хотели наехать... то жду Ваших извинений).
- Речь идёт о разработке (не о "заточке"!) системы под предметную область;
- Карты распределения памяти делаются для каждого частного приложения/процесса/программы;
- Язык, на котором я "строчу" "прожекты", как правило, не один. На ассемблере я пишу редко, хотя по моему убеждению, знание ассемблера необходимо любому уважающему себя программисту... гораздо больше, чем медику необходимо знание латыни.
Всё сказанное... IMHO.
-
Вы традиционно неправильно трактуете то, о чём я пишу (если в этом виновато моё косноязычие, то приношу извинения, если же Вы хотели наехать... то жду Ваших извинений).
- Речь идёт о разработке (не о "заточке"!) системы под предметную область;
- Карты распределения памяти делаются для каждого частного приложения/процесса/программы;
- Язык, на котором я "строчу" "прожекты", как правило, не один. На ассемблере я пишу редко, хотя по моему убеждению, знание ассемблера необходимо любому уважающему себя программисту... гораздо больше, чем медику необходимо знание латыни.
Я спрашивал Вас искренне, никаких "наездов" не было. Что касается полезности знания ассемблера, то с этим я полностью с Вами согласен. И, как мне кажется, распределение памяти - это слишком интимный... я хотел сказать, машиннозависимый вопрос, потому у меня и возникла мысль об использовании ассемблерных вставок. Хотя, зависит ещё от основного языка, который Вы используете.
Что касается "строчу" и "прожекты", - это просто сленг такой (никаких наездов не означает).
-
Полностью согласен с Сергеем. Принципиальный момент в наличии сборщика - это именно возможность построить платформу, гарантирующию целостность на уровне отдельных объектов (памяти). Точнее, тут от обратного проще сформулировать - без сборщика невозможно такую систему построить.
Все-таки возмножно. Например, если совсем без динамической памяти.
-
Все-таки возмножно. Например, если совсем без динамической памяти.
Или если совсем без освобождения динамической памяти. Программа растёт-растёт-растёт, но успевает выполнить поставленную задачу и завершиться задолго до того как исчерпается вся память. У меня есть такая программа на С++, в ней нет ни одного delete. Некий транслятор: запускается, читает несколько файлов, пишет другой файл и завершается. Все объекты, которые она создаёт нужны ей до самого конца, а в конце нет нужды их специально удалять поскольку вся программа заканчивает свою работу ;)
-
Не, на самом деле trurl вел речь о том, что можно жить без динамической памяти вообще. И таки да, живем. В одной из наших программ нет ни одного new/malloc и ни одного delete/free. Рукописных менеджеров памяти также нет. Стандартные контейнеры также не используются.
-
Насчет компонент (для который вроде как требуется сборщик мусора).. Предлагаю ответить на два вопроса:
1) Что такое компоненты?
2) Какую задачу они решают (зачем они нужны)?
1 Базовое определение - часть некоторой составной системы , обладающая по крайней мере двумя свойствами
a) Относительно некоторого(ых) признака(ов) функционально законченная
б) Допускающая повторное использование
2. Понижают сложность создаваемой с помощью них системы
-
Если позволите я немного поправлю Ваше (реально!) очень хорошее определение:
Насчет компонент (для который вроде как требуется сборщик мусора).. Предлагаю ответить на два вопроса:
1) Что такое компоненты?
2) Какую задачу они решают (зачем они нужны)?
1. Базовое определение - часть некоторой составной системы , обладающая по крайней мере двумя тремя свойствами
я) Отвечающая заданному интерфейсу;
a) Относительно некоторого(ых) признака(ов) функционально законченная;
б) Допускающая повторное многократное использование, в том числе, внутри одной системы/программы;
2. Понижают сложность создаваемой с помощью них системы
2. Ускоряют процесс разработки, за счёт перехода к сборке из готовых блоков/компонент.
При этом ни на функциональность, ни на размер компонент ограничений, как правило, не накладывается, то есть, отдельный компонент сам может быть системой или набором компонент.
-
Чем в данном случае отличается: повторное и многократное ?
-
Чем в данном случае отличается: повторное и многократное ?
Это просто уточнение...
Повторное - от "повторить", то есть, один раз использовали, потом ещё... А "многократное" допускает одновременное и последовательное множественное использование. Так по смыслу ближе, IMHO.
-
1. Базовое определение - часть некоторой составной системы , обладающая по крайней мере двумя тремя свойствами
я) Отвечающая заданному интерфейсу;
a) Относительно некоторого(ых) признака(ов) функционально законченная;
б) Допускающая повторное многократное использование, в том числе, внутри одной системы/программы;
2. Понижают сложность создаваемой с помощью них системы
2. Ускоряют процесс разработки, за счёт перехода к сборке из готовых блоков/компонент.
При этом ни на функциональность, ни на размер компонент ограничений, как правило, не накладывается, то есть, отдельный компонент сам может быть системой или набором компонент.
НИ В КОЕМ СЛУЧАЕ - я говорил про БАЗОВОЕ определение - то есть наиболее общее , но тем не менее ПОЛЕЗНОЕ НА ПРАКТИКЕ
Ваше первое предположение ОГРАНИЧИВАЕТ рассматриваемые системы -пример CygWin - система содержащая компонетны (утилиты) БЕЗ ИНТЕРФЕЙСА, с другой стороны без ИНТЕРФЕЙСА НЕВОЗМОЖНО ПРИНЦИПИАЛЬНО взаимодействие компонент.
П2 - можно рассматривать как УТОЧНЕНИЕ понятия СЛОЖНОСТЬ применительно к КОНКРЕТНОЙ или к КЛАССУ систем.
-
1. Базовое определение - часть некоторой составной системы , обладающая по крайней мере двумя тремя свойствами
я) Отвечающая заданному интерфейсу;
a) Относительно некоторого(ых) признака(ов) функционально законченная;
б) Допускающая повторное многократное использование, в том числе, внутри одной системы/программы;
2. Понижают сложность создаваемой с помощью них системы
2. Ускоряют процесс разработки, за счёт перехода к сборке из готовых блоков/компонент.
При этом ни на функциональность, ни на размер компонент ограничений, как правило, не накладывается, то есть, отдельный компонент сам может быть системой или набором компонент.
НИ В КОЕМ СЛУЧАЕ - я говорил про БАЗОВОЕ определение - то есть наиболее общее , но тем не менее ПОЛЕЗНОЕ НА ПРАКТИКЕ
Тем не менее... Ваше определение получилось очень хорошим: полным, простым для восприятия и полезным. Мои поздравления!
Ваше первое предположение ОГРАНИЧИВАЕТ рассматриваемые системы -пример CygWin - система содержащая компонетны (утилиты) БЕЗ ИНТЕРФЕЙСА, с другой стороны без ИНТЕРФЕЙСА НЕВОЗМОЖНО ПРИНЦИПИАЛЬНО взаимодействие компонент.
Интерфейс - это нечто "между лицами", то, что делает возможным/упрощает взаимодействие "лиц". Интерфейсы, встроенные в языки/поддерживаемые языками программирования, просто частный случай. В общем случае интерфейсы могут быть явно не специфицированы/не объявлены, но без них взаимодействие невозможно.
П2 - можно рассматривать как УТОЧНЕНИЕ понятия СЛОЖНОСТЬ применительно к КОНКРЕТНОЙ или к КЛАССУ систем.
Я стараюсь избегать понятия "сложность". По семантике "сложный" значит "с ложью", поскольку одним из основных свойств истины является простота (и если не простой, значит и не истинный, т.е. ложный).
Компонент не может понизить "сложность" системы, поскольку не в его воле изменить количество и смысл уровней системы, но упростить решение задач, за счёт блочной сборки, он может (для этого он и предназначен).
-
Интерфейс - это нечто "между лицами", то, что делает возможным/упрощает взаимодействие "лиц". Интерфейсы, встроенные в языки/поддерживаемые языками программирования, просто частный случай. В общем случае интерфейсы могут быть явно не специфицированы/не объявлены, но без них взаимодействие невозможно.
ФУНДАМЕНТАЛЬНЫМ является понятие СИСТЕМЫ описывающей НЕКОТОРУЮ ИНТЕРЕСУЮЩУЮ НАС ЗАДАЧУ, ваше определение ограничивает системы случаем когда есть ВЗАИМОДЕЙСТВИЕ между компонентами
Я стараюсь избегать понятия "сложность". По семантике "сложный" значит "с ложью", поскольку одним из основных свойств истины является простота (и если не простой, значит и не истинный, т.е. ложный).
Компонент не может понизить "сложность" системы, поскольку не в его воле изменить количество и смысл уровней системы, но упростить решение задач, за счёт блочной сборки, он может (для этого он и предназначен).
1. :) А мне насрать на семантику -есть задача которую надо решить, есть система (возможно не единственная)которая ее описывает в каком -то приближении (или точно)...Я к чему это говорю - для определения можно использовать различные фундаментальных базовых понятий и категорий - главное чтобы результат был удовлетворительным (поставленные задачи решались).
2. а) Может б) это и есть сложность измеряемая в категориях затрат (по времени создания, по стоимости железа...). Скажем так, мне в ОДИНОЧКУ -НЕВОЗМОЖНО сделать современную ИДЕ (здесь иде рассматривкается как система решающая с приемлемым качеством ряд задач) для ОБЕРОНА за РАЗУМНОЕ время но с ГОТОВЫМИ компонентами - почему бы и нет :)
-
1. Если компоненты не взаимодействуют, то какую же систему они образуют? о_О
2. Компоненты снижают не сложность самой системы, а сложность её создания.
-
1. Если компоненты не взаимодействуют, то какую же систему они образуют? о_О
2. Компоненты снижают не сложность самой системы, а сложность её создания.
1) :) :) :) :) :) из НЕВЗАИМОДЕЙСТВУЮЩИХ (друг с другом) компонент ( но они ПРЕКРАСНО могут взаимодействовать с ОКРУЖАЮЩИМ миром - обьектами ВНЕШНИМИ по отношению к РАССМАТРИВАЕМОЙ системе (пример я привел))
2) это зависит от ОПРЕДЕЛЕНИЯ (уточнения ) понятия сложность :)
-
1. Если компоненты не взаимодействуют, то какую же систему они образуют? о_О
2. Компоненты снижают не сложность самой системы, а сложность её создания.
1) :) :) :) :) :) из НЕВЗАИМОДЕЙСТВУЮЩИХ (друг с другом) компонент ( но они ПРЕКРАСНО могут взаимодействовать с ОКРУЖАЮЩИМ миром - обьектами ВНЕШНИМИ по отношению к РАССМАТРИВАЕМОЙ системе (пример я привел))
2) это зависит от ОПРЕДЕЛЕНИЯ (уточнения ) понятия сложность :)
1) Это не система, а просто коробка с кучей запчастей.
2) Я имел в виду -- внутреннюю сложность системы, набор функций, которые она выполняет, что она из себя представляет внутри...
Компоненты уменьшают видимую сложность системы, оставляя при этом внутреннюю сложность неизменной...
ЗЫ. Хотя, если уменьшается сложность создания системы, то можно считать, что уменьшается и её внутренняя сложность, просто кирпичики, из которых она строится, становятся более высокоуровневыми.
Дома мы же строим не из песчинок, а из кирпичей, панелей, модульных блоков...
-
1) Это не система, а просто коробка с кучей запчастей.
2) Я имел в виду -- внутреннюю сложность системы, набор функций, которые она выполняет, что она из себя представляет внутри...
Компоненты уменьшают видимую сложность системы, оставляя при этом внутреннюю сложность неизменной...
ЗЫ. Хотя, если уменьшается сложность создания системы, то можно считать, что уменьшается и её внутренняя сложность, просто кирпичики, из которых она строится, становятся более высокоуровневыми.
Дома мы же строим не из песчинок, а из кирпичей, панелей, модульных блоков...
1. А если подумать? :D
2. Сами компоненты могут иметь сложную структуру (то есть рассматриваться как весьма сложная система) - ну а ЗЫ показывает что вы улавливаете то , о чем я пытаюсь сказать :)
-
Интерфейс - это нечто "между лицами", то, что делает возможным/упрощает взаимодействие "лиц". Интерфейсы, встроенные в языки/поддерживаемые языками программирования, просто частный случай. В общем случае интерфейсы могут быть явно не специфицированы/не объявлены, но без них взаимодействие невозможно.
ФУНДАМЕНТАЛЬНЫМ является понятие СИСТЕМЫ описывающей НЕКОТОРУЮ ИНТЕРЕСУЮЩУЮ НАС ЗАДАЧУ, ваше определение ограничивает системы случаем когда есть ВЗАИМОДЕЙСТВИЕ между компонентами
Есть много определений понятия "система", но большая часть из них сходится в том, что "система состоит из элементов и связей между элементами". Связи - это и есть взаимодействие (или описание взаимодействия). Систем, у которых элементы не взаимодействуют, не бывает, это просто нечто сложенное в кучу.
Связи, которые соединяют элементы/компоненты системы, называются "слабыми" ("сильные" связи образуют сами элементы). "Слабость" "слабых связей" заключается в том, система может их в любой момент разорвать/перестроить. Другими словами, слабые связи опосредованы, явно или скрыто. Но без связей... это не система.
Я стараюсь избегать понятия "сложность". По семантике "сложный" значит "с ложью", поскольку одним из основных свойств истины является простота (и если не простой, значит и не истинный, т.е. ложный).
Компонент не может понизить "сложность" системы, поскольку не в его воле изменить количество и смысл уровней системы, но упростить решение задач, за счёт блочной сборки, он может (для этого он и предназначен).
1. :) А мне насрать на семантику -есть задача которую надо решить, есть система (возможно не единственная)которая ее описывает в каком -то приближении (или точно)...Я к чему это говорю - для определения можно использовать различные фундаментальных базовых понятий и категорий - главное чтобы результат был удовлетворительным (поставленные задачи решались).
Такой подход возможен, и он давно известен. В программировании этот подход получил название "экстремального". Проблема только в том, что при данном подходе возникает проблема "отложенной сложности". То есть, берётся какая-то частная задача и решается (максимально быстро и эффективно). Заказчик доволен, программисты счастливы. Потом берётся другая задача и тоже решается быстро и эффективно. Однако наступает момент, когда приходит понимание, что между задачами существуют внутренние связи, и изменения, сделанные одной задачей, должны влиять на решение другой задачи. Наступает пора рефакторинга. И тут ВДРУГ выясняется, что внутренних связей много и задач... тоже много и переделывать надо всё, что было сделано... а заказчик уже недоволен, его приучили к быстрым решениям, и он хочет решения новых задач (в соответствии с бизнес-планом). Атмосфера накаляется, а появление удовлетворительного решения... откладывается. Вот и приходим к "отложенной сложности".
К семантике можно относится различно, главное, чтобы она к нам относилась... с пониманием... :)
-
1. Если компоненты не взаимодействуют, то какую же систему они образуют? о_О
2. Компоненты снижают не сложность самой системы, а сложность её создания.
1) :) :) :) :) :) из НЕВЗАИМОДЕЙСТВУЮЩИХ (друг с другом) компонент ( но они ПРЕКРАСНО могут взаимодействовать с ОКРУЖАЮЩИМ миром - обьектами ВНЕШНИМИ по отношению к РАССМАТРИВАЕМОЙ системе (пример я привел))
2) это зависит от ОПРЕДЕЛЕНИЯ (уточнения ) понятия сложность :)
Так нет же никакой "рассматриваемой системы"... если компоненты никак не соединены между собой, не взаимодействуют между собой, то это просто библиотека... а с внешним миром взаимодействует система (возможно с посредством компонентов). Она получает возмущение из-вне, распределяет работу между компонентами, выдаёт во-вне реакцию на внешнее или внутреннее возмущение (опять же возможно посредством компонентов).
-
Так нет же никакой "рассматриваемой системы"... если компоненты никак не соединены между собой, не взаимодействуют между собой, то это просто библиотека... а с внешним миром взаимодействует система (возможно с посредством компонентов). Она получает возмущение из-вне, распределяет работу между компонентами, выдаёт во-вне реакцию на внешнее или внутреннее возмущение (опять же возможно посредством компонентов).
Ну как нет - предположим вы хотите создать систему для улучшения производительности персонального ПК, ваша контора имеет ресурсов ровно на то, что бы обрабатывать часть этой задачи (оптимизация настроек системы) , без нормального дефрагментатора диска "жизни нет" - нет и нормальных денег. Но есть конторка которая умеет делать дефрагментаторы (быстрые , дешевые)- но.... ввиде ЗАМКНУТОГО НА СЕБЯ приложения. Хороший выход - включить этот дефрагментатор в СВОЮ систему. Легко убедится, что такая комбинированная система -БУДЕТ ОБЛАДАТЬ СВОЙСТВАМИ О КОТОРЫХ ГОВОРЮ я. ВАША точка зрения - частный случай (правда, часто в СОВРЕМЕННОЙ реальности реализуемый на практике).
-
Не, на самом деле trurl вел речь о том, что можно жить без динамической памяти вообще. И таки да, живем. В одной из наших программ нет ни одного new/malloc и ни одного delete/free. Рукописных менеджеров памяти также нет. Стандартные контейнеры также не используются.
Вопрос - принципиально можно ли порушить такую систему использованием НЕТИПИЗИРОВАННЫХ указателей и оператором ВЗЯТИЯ АДРЕСА?
-
Не, на самом деле trurl вел речь о том, что можно жить без динамической памяти вообще. И таки да, живем. В одной из наших программ нет ни одного new/malloc и ни одного delete/free. Рукописных менеджеров памяти также нет. Стандартные контейнеры также не используются.
Вопрос - принципиально можно ли порушить такую систему использованием НЕТИПИЗИРОВАННЫХ указателей и оператором ВЗЯТИЯ АДРЕСА?
Да нет, на самом деле ответ в том, что для "герметичной" системы типов не нужен GC. То есть GC не является ни необходимым ни достаточным условием. Он оной герметичности вообще побоку.
Тоесть тут есть корреляция, но нет причинно-следственной связи.
-
Да нет, на самом деле ответ в том, что для "герметичной" системы типов не нужен GC. То есть GC не является ни необходимым ни достаточным условием. Он оной герметичности вообще побоку.
Тоесть тут есть корреляция, но нет причинно-следственной связи.
Почему(я говорю про высказывание Trurlя) ?- посмотрите пример С.Губанова.
-
Да нет, на самом деле ответ в том, что для "герметичной" системы типов не нужен GC. То есть GC не является ни необходимым ни достаточным условием. Он оной герметичности вообще побоку.
Тоесть тут есть корреляция, но нет причинно-следственной связи.
Хорошо. Переформулирую: кроме GC ничего еще не придумали, чтобы обеспечить эту самую герметичность в условиях динамического распределения (с освобождением) памяти. Про то, как можно жить без динамической памяти - расскажите Губанову, он переделает свою прогу :)
-
Вопрос - принципиально можно ли порушить такую систему использованием НЕТИПИЗИРОВАННЫХ указателей и оператором ВЗЯТИЯ АДРЕСА?
А откуда возьмутся указатели, если динамической памяти нету?
-
А откуда возьмутся указатели, если динамической памяти нету?
Гм. У каждой переменной есть адрес. Адрес так или иначе можно получить любой переменной, в том числе и на стэке (автоматической памяти) или в статической памяти. Собственно даже в Обероне это можно (правда нужно будет подключить SYSTEM).
-
Интерфейс - это нечто "между лицами", то, что делает возможным/упрощает взаимодействие "лиц". Интерфейсы, встроенные в языки/поддерживаемые языками программирования, просто частный случай. В общем случае интерфейсы могут быть явно не специфицированы/не объявлены, но без них взаимодействие невозможно.
ФУНДАМЕНТАЛЬНЫМ является понятие СИСТЕМЫ описывающей НЕКОТОРУЮ ИНТЕРЕСУЮЩУЮ НАС ЗАДАЧУ, ваше определение ограничивает системы случаем когда есть ВЗАИМОДЕЙСТВИЕ между компонентами
Есть много определений понятия "система", но большая часть из них сходится в том, что "система состоит из элементов и связей между элементами". Связи - это и есть взаимодействие (или описание взаимодействия). Систем, у которых элементы не взаимодействуют, не бывает, это просто нечто сложенное в кучу.
Связи, которые соединяют элементы/компоненты системы, называются "слабыми" ("сильные" связи образуют сами элементы). "Слабость" "слабых связей" заключается в том, система может их в любой момент разорвать/перестроить. Другими словами, слабые связи опосредованы, явно или скрыто. Но без связей... это не система.
Я стараюсь избегать понятия "сложность". По семантике "сложный" значит "с ложью", поскольку одним из основных свойств истины является простота (и если не простой, значит и не истинный, т.е. ложный).
Компонент не может понизить "сложность" системы, поскольку не в его воле изменить количество и смысл уровней системы, но упростить решение задач, за счёт блочной сборки, он может (для этого он и предназначен).
1. :) А мне насрать на семантику -есть задача которую надо решить, есть система (возможно не единственная)которая ее описывает в каком -то приближении (или точно)...Я к чему это говорю - для определения можно использовать различные фундаментальных базовых понятий и категорий - главное чтобы результат был удовлетворительным (поставленные задачи решались).
Такой подход возможен, и он давно известен. В программировании этот подход получил название "экстремального". Проблема только в том, что при данном подходе возникает проблема "отложенной сложности". То есть, берётся какая-то частная задача и решается (максимально быстро и эффективно). Заказчик доволен, программисты счастливы. Потом берётся другая задача и тоже решается быстро и эффективно. Однако наступает момент, когда приходит понимание, что между задачами существуют внутренние связи, и изменения, сделанные одной задачей, должны влиять на решение другой задачи. Наступает пора рефакторинга. И тут ВДРУГ выясняется, что внутренних связей много и задач... тоже много и переделывать надо всё, что было сделано... а заказчик уже недоволен, его приучили к быстрым решениям, и он хочет решения новых задач (в соответствии с бизнес-планом). Атмосфера накаляется, а появление удовлетворительного решения... откладывается. Вот и приходим к "отложенной сложности".
К семантике можно относится различно, главное, чтобы она к нам относилась... с пониманием... :)
Ох
1. Мое определение не противоречит вашему (ваше вложено в него)
2.Свободная трактовка понятия "ЭКСТРЕМАЛЬНОГО ПРОГРАММИРОВАНИЯ" :) , но конечно согласен, что подобную ИДЕОЛОГИЮ можно использовать при ВЫБОРЕ конкретной системы,описывающей задачу. По поводу описанных недостатков = это просто получаемые с помощью такой идеологии решения тяжело поддерживать в течение длительного времени.
-
Вопрос - принципиально можно ли порушить такую систему использованием НЕТИПИЗИРОВАННЫХ указателей и оператором ВЗЯТИЯ АДРЕСА?
А откуда возьмутся указатели, если динамической памяти нету?
Ну вы даете, однако, - а как вы будете возвращать значения из процедур (в языке СИ) там ссылок нет, используя глобальные переменные?
-
Ну вы даете, однако, - а как вы будете возвращать значения из процедур (в языке СИ) там ссылок нет, используя глобальные переменные?
Можно возвращать через стек. То есть прям всю структуру целиком.
-
Ну вы даете, однако, - а как вы будете возвращать значения из процедур (в языке СИ) там ссылок нет, используя глобальные переменные?
Можно возвращать через стек. То есть прям всю структуру целиком.
Не понял
-
Можно возвращать через стек. То есть прям всю структуру целиком.
Не понял
typedef struct {int a; int b; int c;} A;
A foo() {A a; a.a = 42; return a;}
void main(){A b = foo();}
-
Можно возвращать через стек. То есть прям всю структуру целиком.
Не понял
typedef struct {int a; int b; int c;} A;
A foo() {A a; a.a = 42; return a;}
void main(){A b = foo();}
Да, конечно, просто я не использую термин СТЕК для этого способа.
-
Да, конечно, просто я не использую термин СТЕК для этого способа.
Тем не менее структура возвращается реально через таки стек :-) (если в регистр не влазит). Ну и наружу не торчат какие-либо указатели.
-
Тем не менее структура возвращается реально через таки стек :-) (если в регистр не влазит). Ну и наружу не торчат какие-либо указатели.
Это (реализация) меня не волнует - у меня достаточно других проблем.... Главное что формально таким образом возможно вернуть ВСЕ (или нет? не помню :) ) допустимые в языке значения переменных, другое дело , что это не всегда удобно...
-
Гм. У каждой переменной есть адрес. Адрес так или иначе можно получить любой переменной, в том числе и на стэке (автоматической памяти) или в статической памяти. Собственно даже в Обероне это можно (правда нужно будет подключить SYSTEM).
А ещё можно внести в язык оператор Polaarrebane.
-
А в чём смысл следующего пункта?
я) Отвечающая заданному интерфейсу;
Если он не отвечает заданному интерфейсу, то он не компонент? У двух разных компоентов разное назначение, а потому разные интерфейсы.
Каждый из них несовместим с интерфейсом своего соседа. Но от этого он не перестаёт быть компонентом.
Или бывает нечто, где отсутствует данный пункт, но имеются остальные два?
-
Ох
1. Мое определение не противоречит вашему (ваше вложено в него)
а) моего определения здесь вообще нет, я привёл часть принятого в Теории Систем определения;
б) Ваше определение противоречит принятому, в силу того, что оно не отличает целое и кучу разрозненных/несвязанных частей. А понятие целое пересекается с понятием цель... которое тоже является системным.
2.Свободная трактовка понятия "ЭКСТРЕМАЛЬНОГО ПРОГРАММИРОВАНИЯ" :) , но конечно согласен, что подобную ИДЕОЛОГИЮ можно использовать при ВЫБОРЕ конкретной системы,описывающей задачу. По поводу описанных недостатков = это просто получаемые с помощью такой идеологии решения тяжело поддерживать в течение длительного времени.
Да, согласен, хотя из без проблем поддержки экстремальное программирование плохо подходит для создания больших систем.
-
А в чём смысл следующего пункта?
я) Отвечающая заданному интерфейсу;
Если он не отвечает заданному интерфейсу, то он не компонент? У двух разных компоентов разное назначение, а потому разные интерфейсы.
Каждый из них несовместим с интерфейсом своего соседа. Но от этого он не перестаёт быть компонентом.
Или бывает нечто, где отсутствует данный пункт, но имеются остальные два?
Просто возникло разночтение. Речь о том, что в системе может быть несколько уровней. Интерфейсы определяются на стыке двух смежных уровней (определение интерфейсов - отдельная задача системного проектирования). Каждый компонент нижнего уровня системы может реализовывать какое-то подмножество (функционально-однородное, о чём говорил DIzer) интерфейсов. Разные компоненты могут реализовывать одно и тоже или разные подмножества интерфейсов.
Любое подмножество интерфейсов с полным правом можно назвать интерфейсом. То есть, один интерфейс может включать в себя группу других интерфейсов (рекурсии, как правило, запрещены... хотя бы исходя из здравого смысла).
Если компонент не реализует заданные интерфейсы, то он не имеет смысла... обращаться к нему просто не будут. Если компонент смешивает внутри себя интерфейсы разных уровней, то он является потенциальным источником проблем, поскольку связывает внутри себя реализации разных уровней. И при изменении одного из уровней, возможна утрата работоспособности других уровней.
Поясню этот момент на простой аналогии. Есть подпрограмма, её интерфейс - это список формальных параметров. Внутри подпрограммы могут быть другие подпрограммы. Теперь представим, что существует некоторый фрагмент кода, который взаимодействует с вложенными подпрограммами, минуя заголовки хозяйских подпрограмм. Если теперь изменить реализацию хозяйских подпрограмм, то этот фрагмент кода становится "убийцей", даже несмотря на то, что интерфейсы подпрограмм (список формальных параметров, тип вызова и пр.) были сохранены. Примерно тоже самое происходит и при нарушении инкапсуляции уровней системы отдельными компонентами.
-
А понятие целое пересекается с понятием цель... которое тоже является системным.
Теперь кажется я начинаю осознавать причину нелюбви к любителям семантики, спасибо :)
-
А понятие целое пересекается с понятием цель... которое тоже является системным.
Теперь кажется я начинаю осознавать причину нелюбви к любителям семантики, спасибо :)
:) В поисках смысла есть своя радость... Иногда читаешь какой-нибудь текст, пользуясь изначальным смыслом слов... и до того смешно получается... :) "Nam iustitia, quae suum cuique distribuit, quid pertinet ad deos?" Tullius Cicerō (вольный известный перевод: "Каждому своё" Марк Туллий Цицерон).
-
А понятие целое пересекается с понятием цель... которое тоже является системным.
Теперь кажется я начинаю осознавать причину нелюбви к любителям семантики, спасибо :)
:) В поисках смысла есть своя радость... Иногда читаешь какой-нибудь текст, пользуясь изначальным смыслом слов... и до того смешно получается... :) "Nam iustitia, quae suum cuique distribuit, quid pertinet ad deos?" Tullius Cicerō (вольный известный перевод: "Каждому своё" Марк Туллий Цицерон).
Точно, - понятие стол пересекается с понятием ствол (или пол)... которое тоже является системным, понятие жрать - с понятием срать....
-
Каждому свое ....
-
Точно, - понятие стол пересекается с понятием ствол (или пол)... которое тоже является системным, понятие жрать - с понятием срать....
Корни слов -- разные! :o Вы что??? ;D
-
Точно, - понятие стол пересекается с понятием ствол (или пол)... которое тоже является системным, понятие жрать - с понятием срать....
Корни слов -- разные! :o Вы что??? ;D
Я - ничего, а вот вы явно не "любитель семантики" ;D