А драйвера всех видов и мастей, это тоже не Windows? Произвольно за/выгружаемые, написанные разными производителями, не имевшие представления друг о друге, работающие в многоуровневой связке (например файловая система: от драйвера накопителя и до самых до верхов)
Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релегиозную
Здравствуйте, VladD2, Вы писали:
A>>Это от бескультурия. VD>Точно. И у тебя оново коенечно небыло.
Было. Ноя быстро переучился.
A>> Удачно подобрав умный указатель словить утечку памяти довольно сложно. VD>А не удачно?
А их по сути всего триа auto_ptr, shared_ptr и com_ptr. перепутать их довольно сложно
VD>А у всех так. Вон только ЛиСаус (так и тяне сказать Брюс ) имеет 20-30 (гы сам разбор смешен) и не имеет ни единой утечки. Причем никогда их не ловил.
Я вообще не понял что ты хотел сказать
D>Любая обертка — это труд и правило которое нужно соблюдать.
Здравствуйте, VladD2, Вы писали:
A>>То есть статья IT Сжизнью ничего общего не имеет. Так и запишем. VD>Цитату, плиз, где он написал о сложности работы с ресурсами в дотнете.
Я говорю не о сложности (где ты это углядел?) а о необходимости заплатки using.
A>>Файлы открывать надо? Всё, этого достаточно. VD>Цитату, плиз.
Цитату на что? На то что в серьёзной программе естьработа с файлами?
VD>Да? И у тебя такая система есть? VD>Весь компилятор С++ занимает на порядок меньше кода.
Здравствуйте, WolfHound, Вы писали:
WH>Тут не в объеме исходников дело и не в ГЦ, а в том как со строками обращаются. Дык вот если строки плодит только лексер, а парсер их только использует и не создает новых то тормозов не будет.
Дык, а плодить лишних сущностей еще какой-то Кам говорил.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>А если про парсер то и я думаю незачем... Хотя не извесно кто тот парсер на жабе писал который в даун уходит...
Ну, так выводы то какие? Все же дело в руках? Я Яву знаю не шибко. Но и этого достаточно, чтобы утверждать, что значительно моедленее парсер не стал бы будь он переписан на ней.
WH>Я однажды компилятор видел короче засасывается весь исходник в одну строку далие над этой строкой начинают измываться пока до байткода не доведет... Расказывать про скорость с которой это работало и про то как оно об ошибках сообщало я не буду... Но самое смешное что это работало
Честно говря я даже не знаю как это возможно. Древние компиляторы делали несколько прохдов (чтений исходников). Далалось это из-за нехвтки памяти. Это сйчас можно мегабайтный исходник заглотить и не чавкнуть. А тогда... Вот они тормозили копитально. Но как можно по строчке компилировать? Это только для разных командных интепретаторов возможно.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.
Ну, решение все же не очень хорошее. Если бы не нацеленность на короткие захваты ресурсов, то они были бы бичем. Намного лучше было бы ввести класс типов — холдеры. А спасает именно то, что выбирается стратегия когда с ресурсом ведется работа в очень узком участке кода. Тут и юсинг работает неплохо. Но поять же это соглашение, а они не надежны. Всегда найдется орел который наплючет на на соглашения.
AVK>Тому свидетельство появление юзинга в VB.NET в 2.0 в практически таком же виде.
Помойму он имеет версию 8.0. Они не сбрасывали версии с шестой студии.
AVK>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?
Дык БД вообще пулится. Так что запросил — отпустил. Все в юсингах и терть нечего. Друое дело, что можно было бы и без них.
AVK>А что, в природе бывают парсеры такого объема?
Даже компиляторов не бывает. 50 мег на шарпе — это уже ОС.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Вопрос не в том как относится к чему-то IT, вопрос в тмо есть недостаток (пусть и не большой) или нету.
Не. Вопрос в том напрягает он или нет. Так вот не напрягает. Он тебе и говорит — чистая теория не подтверждающаяся на практике.
A>А что это? Это очень хорошая заплатка, но именно заплатка. Эта конструкция создана под внутреннее устройство GC и никакой логики не несёт.
Эта конструкция вообще к ЖЦ отношение не имеет. Она как раз позволяет автоматически контролировать все что вгодно кроме памяти.
A>Или несёт? Ведь в Си++ пишут A>
A>for (int i = 0; i < 3; ++i)
A> {
A> somestream mystream;
A> mystream << "text"
A> }
A>
A>А в C# нужен using иначе на второй итерации можно получить облом.
Когда мне нужо было писать много файлов (сотни) я сделал два вот таких хэлпера:
public static string ReadFile(string fileName)
{
using (StreamReader reader = new StreamReader(
fileName, Encoding.Unicode))
{
return reader.ReadToEnd();
}
}
public static void WriteFile(string fileName, string code)
{
using (StreamWriter writer = new StreamWriter(
fileName, false, Encoding.Unicode, code.Length))
{
writer.Write(code);
}
}
И далее чтение файлов вглядит как атомарная операция при которой не мыслимо не закрыть что-то:
Благадаря особенностям ЖЦ такой подход еще и поднимает скорость.
С 90% ресурсов можно ралотать так же. Ну, а с 10 прийдется поработать по плотнее. Но все равно сложностей особых нет.
Не за гормаи Лонгхорн с его выньФС. В нем вместо файлов будут объекты (дотнытные) и контролировать файлы как таковый зачастую просто не прийдется. С БД и ГДИ проблем нет уже сейчас. Так что все ОК, и ты просто не проникся.
A>Я говорил о возможности ошибки, а не о наличии.
Дык чем меньше контроля, тем меньше мест для ошибок. Пойми любой юсинг — это место для потенциальной ошибки. Но для С++ такие места при определении любой ссылочной переменной. В купе со стратегией минимизации времени блокировки фйлов и других ресурсов программировать становится реально проще. Возожно при наличии возможности создавать хэшперы-хэндлеры все было бы еще проще. Но и так намного проще чем в С++. Поверь, я все же не мало пописал на плюсах.
Я как м ты избегал исключений, делал обертки и т.п. Но вкусив Шарпа я понял, что 80% времени тратил на борьбу с ветренными мельницами.
A> Твой богатый опыт и знания могут даже незаметно для тебя, на интуитивном уровне, помогать избегать ошибок.
Так и есть. Есть куча ламеров которые просто не пользутся юсингами. Но поймать незакрытый файл очень просто. А вот проход по памяти или лик памяти порой очень сложно.
К сожалению приколы есть и в шарпе. Вот недавно в Янусе отловили багу которую повесил я. Дело втом, что я не отключался от событий при чтении данных (каждый раз подписываясь на них). В итоге количество обработчиков росло со временем и в конце концов приводило к тормозам (в 1.1. делегаты тормозят при больших количествах подключенных вызовов). Но эта была единственная серьезная оишибка связанная с забычивостью. На С++ таки трясся над подобными моментами.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Ну, решение все же не очень хорошее. Если бы не нацеленность на короткие захваты ресурсов, то они были бы бичем. Намного лучше было бы ввести класс типов — холдеры. А спасает именно то, что выбирается стратегия когда с ресурсом ведется работа в очень узком участке кода. Тут и юсинг работает неплохо. Но опять же это соглашение, а они не надежны. Всегда найдется орел который наплючет на на соглашения.
Вот-вот! вот об этом я и хочу сказать!
Влад, я опять с тобой согласен! Может я болею чем-то?
Здравствуйте, adontz, Вы писали:
A>Я говорю не о сложности (где ты это углядел?) а о необходимости заплатки using.
Вот история:
A>>Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.
AVK>Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.
То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.
A>Цитату на что? На то что в серьёзной программе естьработа с файлами?
Например, этого:
A>>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.
VD>>Да? И у тебя такая система есть? VD>>Весь компилятор С++ занимает на порядок меньше кода.
A>Настоящие ирокезы работают без IDE?
А IDE интегрирована в компилятор? Да и в студии тоже 50 метров вряд ли наберется.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mdw, Вы писали:
mdw>>>Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релИгиозную
VD>То есть тебе показалось мало оверквотинга в первом посте и ты решил увеличить его вдвое?
Виноват.
В любом случае, спасибо за релевантный и вежливый коментарий.
А что движок позволяет редактировать собственные сообщения?
Здравствуйте, adontz, Вы писали:
AVK>>Имеет. Однако IT свою статью писал когда только экспериментировал с дотнетом и еще свежи были плюсовые воспоминания. Спроси у него сейчас, вполне возможно что он относится к данному недостатку GC уже не так критически.
A>Вопрос не в том как относится к чему-то IT, вопрос в тмо есть недостаток (пусть и не большой) или нету.
Недостатки есть у всего. Но по твоим словам этот недостаток нивелирует преимущества GC, а это совсем не так.
AVK>>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.
A>А что это? Это очень хорошая заплатка, но именно заплатка. Эта конструкция создана под внутреннее устройство GC и никакой логики не несёт. Или несёт?
При чем тут несет/не несет? Это просто сокращенная запись try..finally..Dispose(). Чтобы писать меньше. Обычно такие вещи называют syntactic sugar, а не заплатка.
AVK>>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?
A>Я говорил о возможности ошибки, а не о наличии.
Нет уж, вот твои слова:
AVK>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
A>Однако на практике их путать приходится
Так что ты говорил о наличии
A> Твой богатый опыт и знания могут даже незаметно для тебя, на интуитивном уровне, помогать избегать ошибок.
Этот проект делаю не один я, а команда программистов разной квалификации. Проблем нет ни у кого.
AVK>>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.
VD>Ну, решение все же не очень хорошее. Если бы не нацеленность на короткие захваты ресурсов, то они были бы бичем. Намного лучше было бы ввести класс типов — холдеры. А спасает именно то, что выбирается стратегия когда с ресурсом ведется работа в очень узком участке кода. Тут и юсинг работает неплохо. Но поять же это соглашение, а они не надежны. Всегда найдется орел который наплючет на на соглашения.
Теоретически да, на практике к счастью не находится. Т.е. да, конечно было бы неплохо иметь какой то хитрый тип, но с другой стороны жизненной необходимости в нем нет. Впрочем это все теоретизирования, МС по этому пути не пошли. Пока они просо ввели возможность сказать что объект содержит дорогой ресурс и его нужно грохнуть как можно скорее.
AVK>>Тому свидетельство появление юзинга в VB.NET в 2.0 в практически таком же виде.
VD>Помойму он имеет версию 8.0. Они не сбрасывали версии с шестой студии.
Неважно.
AVK>>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?
VD>Дык БД вообще пулится.
Это не отменяет необходимости закрывать соединения явно.
AVK>>А что, в природе бывают парсеры такого объема?
VD>Даже компиляторов не бывает. 50 мег на шарпе — это уже ОС.
) имеет 20-30 (гы сам разбор смешен) и не имеет ни единой утечки. Причем никогда их не ловил.
короче засасывается весь исходник в одну строку далие над этой строкой начинают измываться пока до байткода не доведет... Расказывать про скорость с которой это работало и про то как оно об ошибках сообщало я не буду... Но самое смешное что это работало 
ИМХО правил 25 от силы наберётся.
