Здравствуйте, adontz, Вы писали:
A>ИМХО вредный. Он не только не решает задачу в целом, но и создаёт дополнительные трудноуловимые проблемы.
Все Ваши негодования и возмущения проистекают от попыток использования языков с GC в системах, которые были спроектированы в рамках других идеологий. Если бы операционная система сама была спроектирована от и до в терминах объектно ориентированной идеологии со сборкой мусора, то у Вас бы никогда не возникло псевдопроблем с забытием закрыть файл или другой ресурс ОС. Ни Windows ни UNIX таковыми системами не являются. Таковыми системами являются, например, Обероны...
Здравствуйте, adontz, Вы писали:
A>Слышал такое "Бытие определяет сознание"? GC это как бы новый вид бытия который определяет новый вид сознания — пофигисты. Люди которым пофиг когда и что освободится. A>Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.
Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.
A>GC прививает плохой стиль работы с ресурсами вообще. Мозги у человека одни, а не 20. И помнить что надо освобождать все ресурсы проще, чем помнить что надо освобождать все кроме памяти.
Ты пробовал? А да. Не прививает.
A>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.
Ужас? Ты изучал код дотнета? Каким образом?
A>Я соглашусь, что в 90% случаев единственный используемый ресурс это память, но остальные 10 не дают мне спать спокойно
А ты попробуй. Может все не так ужасно?
AVK>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
A>Однако на практике их путать приходится
Расскажи о своей практике.
AVK>>А вот парсер R#, использующий System.String не останавливается.
A>Это потому что исходники пока маленькие
А тебе сколько надо? И для какого языка парсер значительно сложнее?
AVK>>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.
A>ИМХО вредный. Он не только не решает задачу в целом, но и создаёт дополнительные трудноуловимые проблемы.
AVK>>А вот парсер R#, использующий System.String не останавливается.
A>Это потому что исходники пока маленькие
Боюсь, что у тебя коммерческие проекты меньше. Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.
Что касается ЖЦ, то вся твоя теория рассылпается при упоминании простого факта. В реальных приложений написанных на Шарпе проблем с контролем ресурсов возникает очень мало. А в С++ хватает. Причем обычно народ ловит лики именно памяти.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>А вот парсер R#, использующий System.String не останавливается.
A>>Это потому что исходники пока маленькие
AVK>А тебе сколько надо? И для какого языка парсер значительно сложнее?
Кстати, да. Именно сложность парсера у Шарпа выше чем у большинства языков (если не у всех) в следствии тучи мелких фич типа событий, делегатов... С++ точно объем парсера имет меньший.
А при работе с семантикой строки уже не создаются, так что там разницы никакой.
В общем, по факту парсинг на Шарпе идет очень даже шустро, а все рассказы о тормозах работы со строками выдумка.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Боюсь, что у тебя коммерческие проекты меньше. Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.
Хи-хи.... Проект на С++ исходники метров эдак 20 — 30 ( точно трудно оценить — много подсистем ).
VD>Что касается ЖЦ, то вся твоя теория рассылпается при упоминании простого факта. В реальных приложений написанных на Шарпе проблем с контролем ресурсов возникает очень мало. А в С++ хватает. Причем обычно народ ловит лики именно памяти.
БРЕД СИВОЙ КОБЫЛЫ, извините. Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ.
Проектировать и разрабатывать просто надо уметь. Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.
Здравствуйте, VladD2, Вы писали:
VD>Причем обычно народ ловит лики именно памяти.
Это от бескультурия. Удачно подобрав умный указатель словить утечку памяти довольно сложно.
У меня конечно тоже бывают утечки, но они всегда только от ручной работы с выделением и освобождением ресурсов.
Посему я прежде чем пользоваться ресурсом пишу класс.
A>>Это потому что исходники пока маленькие VD>Боюсь, что у тебя коммерческие проекты меньше. Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.
Всего 3? У меня папка My Projects\Done (то что сделано и забыто) 13 МБ, а я папочки Release/Debug и всё другое лишнее оттуда потёр. А ещё текущие проекты...
Здравствуйте, LeeMouse, Вы писали:
LM>Хи-хи.... Проект на С++ исходники метров эдак 20 — 30 ( точно трудно оценить — много подсистем ).
Твоих или воообще?
LM>БРЕД СИВОЙ КОБЫЛЫ, извините. Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ. LM>Проектировать и разрабатывать просто надо уметь. Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.
Здравствуйте, LeeMouse, Вы писали:
LM>БРЕД СИВОЙ КОБЫЛЫ, извините. Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ. LM>Проектировать и разрабатывать просто надо уметь. Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.
Это так.
Только C# и парадигма GC позволяет использовать на пару соглашений меньше. И это хорошо! (ИМХО)
Кстати, в C# получить утечку памяти — легче легкого. Достаточно забыть присвоить в null указатель (например на один узелок в развесистом дереве), чтобы память несколлектилась.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, AndrewVK, Вы писали:
A>>Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте. AVK>Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.
То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.
A>>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас. AVK>Ужас? Ты изучал код дотнета? Каким образом?
IT Изучал.Во всяком случае он так утверждает.
AVK>>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые. A>>Однако на практике их путать приходится AVK>Расскажи о своей практике.
Файлы открывать надо? Всё, этого достаточно.
A>>Это потому что исходники пока маленькие AVK>А тебе сколько надо?
Здравствуйте, adontz, Вы писали:
A>>>Это потому что исходники пока маленькие AVK>>А тебе сколько надо? A>Мегабайт 50.
Тут не в объеме исходников дело и не в ГЦ, а в том как со строками обращаются. Дык вот если строки плодит только лексер, а парсер их только использует и не создает новых то тормозов не будет.
... << RSDN@Home 1.1.4 rev. 142 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
AVK>>Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.
A>То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.
Имеет. Однако IT свою статью писал когда только экспериментировал с дотнетом и еще свежи были плюсовые воспоминания. Спроси у него сейчас, вполне возможно что он относится к данному недостатку GC уже не так критически.
A>>>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас. AVK>>Ужас? Ты изучал код дотнета? Каким образом?
A>IT Изучал.Во всяком случае он так утверждает.
Понятно. Так бы и сказал что говоришь с чужих слов. А что и как IT на эту тему писал я знаю, мы в свое время этот вопрос с ним обсуждали. Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является. Тому свидетельство появление юзинга в VB.NET в 2.0 в практически таком же виде.
AVK>>>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые. A>>>Однако на практике их путать приходится AVK>>Расскажи о своей практике.
A>Файлы открывать надо? Всё, этого достаточно.
Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?
A>>>Это потому что исходники пока маленькие AVK>>А тебе сколько надо?
A>Мегабайт 50.
Здравствуйте, WolfHound, Вы писали:
WH>Тут не в объеме исходников дело и не в ГЦ, а в том как со строками обращаются. Дык вот если строки плодит только лексер, а парсер их только использует и не создает новых то тормозов не будет.
Здравствуйте, xvost, Вы писали:
X>Только C# и парадигма GC позволяет использовать на пару соглашений меньше. И это хорошо! (ИМХО)
X>Кстати, в C# получить утечку памяти — легче легкого. Достаточно забыть присвоить в null указатель (например на один узелок в развесистом дереве), чтобы память несколлектилась.
Ну это не так страшно, поскольку когда умрет дерево грохнется и эта ссылка. Хотя вашу специфику я понимаю.
Намного страшнее в этом плане делегаты. Вот тут можно попасть очень серъезно, поскольку это фактически публичный список и чисто психологически никто не задумывается что на ровном месте мы получаем накопление ссылок. Особенно неприятно когда событие статическое или принадлежит синглтону. В таком разе мы получаем самый натуральный лик.
Здравствуйте, AndrewVK, Вы писали:
AVK>А зачем их плодить?
Если ты про лексер то у него работа такая... исходник на лексемы нашинковать чтобы парсер работал на болие высоком уровне абстракции...
А если про парсер то и я думаю незачем... Хотя не извесно кто тот парсер на жабе писал который в даун уходит... Я однажды компилятор видел короче засасывается весь исходник в одну строку далие над этой строкой начинают измываться пока до байткода не доведет... Расказывать про скорость с которой это работало и про то как оно об ошибках сообщало я не буду... Но самое смешное что это работало
... << RSDN@Home 1.1.4 rev. 142 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Имеет. Однако IT свою статью писал когда только экспериментировал с дотнетом и еще свежи были плюсовые воспоминания. Спроси у него сейчас, вполне возможно что он относится к данному недостатку GC уже не так критически.
Вопрос не в том как относится к чему-то IT, вопрос в тмо есть недостаток (пусть и не большой) или нету.
AVK>Понятно. Так бы и сказал что говоришь с чужих слов.
А я и сказал
AVK>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.
А что это? Это очень хорошая заплатка, но именно заплатка. Эта конструкция создана под внутреннее устройство GC и никакой логики не несёт. Или несёт? Ведь в Си++ пишут
for (int i = 0; i < 3; ++i)
{
somestream mystream;
mystream << "text"
}
А в C# нужен using иначе на второй итерации можно получить облом.
AVK>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?
Я говорил о возможности ошибки, а не о наличии. Твой богатый опыт и знания могут даже незаметно для тебя, на интуитивном уровне, помогать избегать ошибок.
Здравствуйте, LeeMouse, Вы писали:
LM>Хи-хи.... Проект на С++ исходники метров эдак 20 — 30 ( точно трудно оценить — много подсистем ).
У тебя случаем не разделение личности? Я говорил о адонзе и его проектах.
К тому же я не утвреждал, что РШарп самый большой проект. Я просто сказал, что он очень не мальенький проект.
VD>>Что касается ЖЦ, то вся твоя теория рассылпается при упоминании простого факта. В реальных приложений написанных на Шарпе проблем с контролем ресурсов возникает очень мало. А в С++ хватает. Причем обычно народ ловит лики именно памяти.
LM>БРЕД СИВОЙ КОБЫЛЫ, извините.
Не хочется извинять.
LM> Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ.
Рад за тебя. И конечно никогда не было. Пишите без ошибок...
LM>Проектировать и разрабатывать просто надо уметь.
Это совет? Или констатация собственной крутости?
LM> Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.
А еще и без исключений. Ню-ню. Очень правильно. Поделись что пишешь то?
LM>Удач.
Тебе она нужнее.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xvost, Вы писали:
X>Кстати, в C# получить утечку памяти — легче легкого. Достаточно забыть присвоить в null указатель (например на один узелок в развесистом дереве), чтобы память несколлектилась.
Это не лик. Лик это недоступные ресурсы которые рельзя освободить. Лик можно сделать забыв отписавшись от события на синглонах.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Причем обычно народ ловит лики именно памяти.
A>Это от бескультурия.
Точно. И у тебя оново коенечно небыло. Ладно. До добра это не доведет. Завязываем.
A> Удачно подобрав умный указатель словить утечку памяти довольно сложно.
А не удачно?
A>У меня конечно тоже бывают утечки, но они всегда только от ручной работы с выделением и освобождением ресурсов.
А у всех так. Вон только ЛиСаус (так и тяне сказать Брюс ) имеет 20-30 (гы сам разбор смешен) и не имеет ни единой утечки. Причем никогда их не ловил.
A>Посему я прежде чем пользоваться ресурсом пишу класс.
Раньше я далал так же. Вот только ошибки... Да и код пишут разные люди. Ну, и не всегда обертки помогают. Есть и связь с системой, и другие фени. А я тепер очертки писать не надо. Просто пишешь прикладной код и все.
В общем, рассказ о трудности управления ресурсами в дотнете — это домыслы тех кто серьезно с ним не работал.
Любая обертка — это труд и правило которое нужно соблюдать.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
A>Всего 3? У меня папка My Projects\Done (то что сделано и забыто) 13 МБ, а я папочки Release/Debug и всё другое лишнее оттуда потёр. А ещё текущие проекты...
А ты еще потри все библиотечки, генерируемые файлы и т.п. А посчитай только рабчие файлы.
Хотя к делу это не относится. Думаю никто не осмелится назвать полноценный парсер в три метра исходников "малым количеством кода". Его боле чем достаточно для определения быстродействия... по крайней мере при работе со строками и большим количеством объектов. Так что забывай все эти догмы.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.
Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.
