Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата KILLER @ 01.10.10, 19:17

Цитата kanes @ 01.10.10, 19:15

если только сильно попозже.

только не сильно позже(в течении недели этой хотябы...)

Это было бы уже не "пиво ушел пить", а "ушел в запой".

Добавлено 01.10.10, 19:19

Цитата KILLER @ 01.10.10, 19:18

D_KEY, может ты объяснишь ?

Чего объяснить? Почему там не стоит использовать сборщик мусора?

Цитата D_KEY @ 01.10.10, 19:07

Все правильно. Только ты забыл выделить еще:

Цитата

Причина этому кроется в широко известной
проблеме висячих ссылок : мы выделяем память под ячейку, содержащую число, сохраняем ссылку на нее в некоторой структуре данных, какое-то время ей пользуемся, затем освобождаем ее и выделяем
новую ячейку, содержащую булевское значение. При этом, возможно, используется то же самое место
в памяти.

Так вот, если ты используешь другие механизмы автоматического контроля за ресурсами, то этой проблемы ты избегаешь. Остается лишь проблема "ручной" заботы о времени жизни объекта. Опциональный сборщик эту проблему решает. И не будем забывать, что нет в программировании универсальных приемов. В тех же системах реального времени сборка мусора будет смотрется несколько странно.

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


а никто и не говорит про GC в RTOS, хотя и в этом направлении наработки существуют =)

Цитата D_KEY @ 01.10.10, 19:17

Ник у тебя, надеюсь, не отражает результаты твоей работы?

Нет, ник из кваки , работаю я очень тесно с медициной... мне это интересно... если нужно могу в пм отписать чем занимаюсь...

Добавлено 01.10.10, 19:21

Цитата D_KEY @ 01.10.10, 19:18

Чего объяснить? Почему там не стоит использовать сборщик мусора?

Да!!

Цитата KILLER @ 01.10.10, 19:20

Цитата D_KEY @ 01.10.10, 19:18

Чего объяснить? Почему там не стоит использовать сборщик мусора?

Да!!

потому что сборка мусора в общем случае может запуститься в произвольный момент и тем самым нарушить план работы/выполнения процессов, что непозволительно для ОСРВ

читал ведуться исследования (возможно уже есть конкретные наработки) "планируемой" сборки мусора, дабы планировщик процессов ОСРВ мог ей управлять. ну или как-то так, в общем исследования по приспособлению GC для работы в ОСРВ ведутся и не безуспешно =)

Сообщение отредактировано: korvin - 01.10.10, 19:26

Цитата korvin @ 01.10.10, 19:20

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

Доказать нельзя. А верификацию провести можно. Так что не аргумент.
ИМХО, вообще единственное преимущество сборки мусора - отсутствие необходимости заботится о времени жизни, о циклических ссылках и т.д. и т.п.
Именно поэтому я считаю, что сборщик должен быть в языке опциональным.

Добавлено 01.10.10, 19:26
korvin, если есть еще аргументы в тему GC(не в таких языках, как лисп), то выкладывай. Вдруг я что-то упускаю из виду.

Цитата D_KEY @ 01.10.10, 19:24

Доказать нельзя. А верификацию провести можно. Так что не аргумент.
ИМХО, вообще единственное преимущество сборки мусора - отсутствие необходимости заботится о времени жизни, о циклических ссылках и т.д. и т.п.
Именно поэтому я считаю, что сборщик должен быть в языке опциональным.

Добавлено 01.10.10, 19:26
korvin, если есть еще аргументы в тему GC(не в таких языках, как лисп), то выкладывай. Вдруг я что-то упускаю из виду.

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

(на рукипедии какая-то убогая статья про формальную верификацию, есть другой русскоязычный материал?)

Сообщение отредактировано: korvin - 01.10.10, 19:32

Цитата korvin @ 01.10.10, 19:23

потому что сборка мусора в общем случае может запуститься в произвольный момент и тем самым нарушить план работы/выполнения процессов, что непозволительно для ОСРВ

Ммм ? мы сейчас говорим о современных компьютерах ? или я невъехал ??
Если речь идет об автономном аапарате, я все пойму, если речь идет о ПО, то я чегото явно не понимаю

Цитата KILLER @ 01.10.10, 19:45

Ммм ? мы сейчас говорим о современных компьютерах ? или я невъехал ??
Если речь идет об автономном аапарате, я все пойму, если речь идет о ПО, то я чегото явно не понимаю

http://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8

суть примерно в том, что планировщик процессов ОСВР гарантирует выполнение процесса за указанный промежуток времени и/или до указанного момента времени независимо от остальных процессов, запущеных в системе (причём для них тоже гарантируются соблюдение их критериев выполнения).

естественно софт для ОСВР пишется с соблюдением некоторых правил, дабы соблюдались условия выполнения, накладываемые на программу в ТЗ. а GC в общем случае не позволяет соблюдать эти правила

в смысле при строго ручном управлении ресурсами (в частности памятью) разработчик может с достаточно высокой вероятностью "гарантировать" время реакции программы и/или время её выполнения. с GC это время в общем случае никак не гарантировано

т.е. например согласно табличке на вике:

Цитата

Основная задача ОСРВ -- Успеть среагировать на события, происходящие на оборудовании

если на момент прихода сигнала с оборудования в программе обработки этих сигналов запустился GC, то она (программа) из-за этого может не успеть обработать сигнал

вообще, имхо, достаточно останавливать сборку мусора при возникновении события "из вне". но опять же ОС не знает на каком языке писана программа: на языке с GC или без.

Сообщение отредактировано: korvin - 01.10.10, 20:09

Цитата korvin @ 01.10.10, 19:59

если на момент прихода сигнала с оборудования в программе обработки этих сигналов запустился GC, то она (программа) из-за этого может не успеть обработать сигнал

Вроде понял, но опять же неужели GC стока ресурсов хаввает что событие не успеет произойти в нужный момент времени ?

Цитата KILLER @ 01.10.10, 20:18

Вроде понял, но опять же неужели GC стока ресурсов хаввает что событие не успеет произойти в нужный момент времени ?

Поди посмотри системные требования(!!!) к сборщику мусора языка go хотябы. Это далеко не эталон конечно, но просто я очень удивился самому факту что ЯП выставляет системные требования.

Сановцы вроде уже давно скрестили ГЦ и РТ...
http://java.sun.com/javase/technologies/realtime/index.jsp

Цитата KILLER @ 01.10.10, 20:18

Вроде понял, но опять же неужели GC стока ресурсов хаввает что событие не успеет произойти в нужный момент времени ?

не обязательно "стока", достаточно лишней миллисекунды, а то и микросекунды, чтобы всё испортить

Цитата D_KEY @ 01.10.10, 19:24

ИМХО, вообще единственное преимущество сборки мусора - отсутствие необходимости заботится о времени жизни, о циклических ссылках и т.д. и т.п.

Это не так уж и мало

Цитата D_KEY @ 01.10.10, 19:24

Именно поэтому я считаю, что сборщик должен быть в языке опциональным.

Зачем оно нужно ? Я вот, например, ни разу не испытывал желания удалить объект руками. Хотя в шарпе работать с неуправляемой кучей, создавать объекты на стеке при желании вполне возможно, и без бубна.

Цитата Повстанець @ 01.10.10, 20:22

я очень удивился самому факту что ЯП выставляет системные требования.

а что в этом удивительного? ЯВУ всё дальше и дальше уходят от машины, понятно, что рано или поздно они станут невыполнимы на машинах с ограниченными ресурсами. попробуйте рантайм С++ запихнуть в какой-нибудь примитивный микроконтроллер.

и компилятор/интерпретатор -- это такая же программа, как и любая другая, почему он не может предъявлять системные требования?

Сообщение отредактировано: korvin - 01.10.10, 20:38

Цитата KILLER @ 01.10.10, 17:42

Вопрос: полноценая ? т.е. я могу спокойно писать на виндовз, любую программу, любой сложности, будет ли это выполняться аналогично на перечисленных системах ?

Да, будет. Только писать не "под виндовз", а под моно. Потом ставишь моно на любую из указанных систем, включая винду, и запускаешь под неё свою программу. В общем, аналогия с джавой.
Если под "писать под виндовз" ты имеешь в виду под MS .Net Framework, то тут нет гарантий, т.к. библиотеки фреймворка и моно пересекаются частично.

Сообщение отредактировано: IL_Agent - 01.10.10, 20:41