Здравствуйте, CreatorCray, Вы писали:
CC>В С++ декларируется "принцип платишь только за то, что реально используешь". В соответствии с ним — поставляется жизненно необходимый минимум.
Ерунда. На каждый момент времени "жизненно необходимый минимум" есть вполне конкретное понятие. И в 2009 году, когда даже зачуханный стобаксовый сотовый телефон спокойно поддерживает CLDC-1.1/MIDP-2.0/JSR 135/ещё много чего, стандартная библиотека C++ — реликт каменного века.
CC>Вот мне всегда было непонятно, почему в плюс языка всегда пытаются отнести большую стандартную библиотеку?
Потому что у нормальных людей есть дела поважнее изобретения велосипедов и ковыряния в compatibility issues. Посему они и выбирают не языки, а платформы.
CC>ИМХО появление новых языков с большими библиотеками в комплекте необходимая мера в последнее время.
Это "последнее" время длиться уже как минимум 15+ лет.
CC>Во сколько раз меньше народу в момент появления той же Java стало бы писать на ней не будь под нее большой библы с готовыми велосипедами?
"Большая" она сейчас, а "в момент появления" ничего особо большого там не было. Только "жизненно необходимый минимум"
Пацак пишет:
> MZ>Имеется в виду то, что GC — и есть одна большая утечка памяти. > MZ>Постоянная. Мнение — не моё, ещё раз. > > Ну считай, что минусы тогда тоже не тебе.
CreatorCray пишет:
> Вот мне всегда было непонятно, почему в плюс языка всегда пытаются > отнести большую стандартную библиотеку?
Потому что на таком языке легче писать переносимые и кроссплатформенные
программы. Это, конечно, в современном мире ни на фиг никому не надо,
но всё же.
> Это конечно плюс, но не самого языка.
Если эта стандартная библиотека стандартизована и её реализация
обезательна, то -- для самого языка.
Здравствуйте, Аем Вопля, Вы писали:
П>>Офигеть! А почему мы тогда не говорим о вредном воздействии java-программ на вселенскую энтропию?
АВ>Это вы к чему?
К тому что "обобщать — так уж обобщать".
АВ>Не вижу связи.
Равно как и я — между приведенным кодом и утечками памяти.
D>Не очень понятно что Вы конкретно имели в виду, однако, в любом случае, утечка всё равно не вытанцовывается. D>Ну не вызвали Dispose() у FileStream'а, и что ? "Распределённой на энергонезависимом запоминающем устройстве" памяти в виде файла от этого ни холодно, ни жарко. Как был файл, так он и остался. Особенно при работе "только на чтение"
Ладно, я вижу, шутки вы не поняли. Если так, то расскажу вам то, что вы и так прекрасно знаете: когда вы открываете файл, выделяются некие ресурсы, необходимые для работы с этим файлом, включая оперативную память, кроме того, доступ к файлу может быть эксклюзивным. Если не вызвать Dispose по выходу из функции, файл не закроется, а это может вызвать некоторые проблемы. Такие ситуация обычно и называется утечкой ресурсов.
И основная проблема как раз в том, что вызывать Dispose нужно вручную, отслеживая все ветви выполнения, а это ничем не лучше старого доброго C, хотя, казалось бы, с появлением GC все должно делаться автоматически.
И тут оказывается, что C++ имеет даже некоторое преимущество в этом отношении, так как поддерживает автоматический вызов деструкторов при выходе из области видимости.
Пример с файлом был не самым удачным, просто пример с памятью мне было придумывать лень. Если вы программировали на Джаве или C#, думаю вы и сами таких примеров придумаете достаточно. Допустим, это может быть создание объектов в цикле.
Неграмотное использование GC легко может привести к созданию программы, низкая эффективность которой не влезет ни в какие ворота. А такая ситуация у меня плохо ассоциируется с «автоматикой». Для меня, «автоматическое» — это то, что делается само, не требуя от меня никакого участия. А GC — это такая «квазиавтоматика», когда ты все равно должен держать в голове, как этот GC работает.
И на практике получается так, что из-за GC управление ресурсами в .Net и Джаве становится местами даже еще более «ручным», чем в C++.
Я не прав? Если я не прав, зачем тогда ввели ключевое слово using в C#, а? Если и так все «автоматическое»?
Хм...
АВ>когда вы открываете файл, выделяются некие ресурсы, необходимые для работы с этим файлом, включая оперативную память
Не катит. Файлы в программах открываются гораздо реже простого ручного выделения памяти и едят ее как правило гораздо меньше. А автоматические деструкторы для их закрытия — настолько же вред, насколько и польза.
АВ>Пример с файлом был не самым удачным, просто пример с памятью мне было придумывать лень.
А, вон как...
АВ>Если вы программировали на Джаве или C#, думаю вы и сами таких примеров придумаете достаточно. Допустим, это может быть создание объектов в цикле.
Рассмотрим простейший:
for (int i=0; i<1000000; i++) {
Foo foo = new Foo();
bar(foo);
}
Разницу в поведении для C++ и java объяснять надо или все понятно и так?
АВ>Неграмотное использование GC легко может привести к созданию программы, низкая эффективность которой не влезет ни в какие ворота.
...равно как и неиспользование. Только последнее, как любой ручной процесс, еще и чревато трудноуловимыми багами.
АВ>Я не прав?
Нет.
АВ>Если я не прав, зачем тогда ввели ключевое слово using в C#, а?
Без понятия, равно как и о многом другом в C#. Но мы сейчас таки не о нем, а о C++ vs Java.
Аем Вопля пишет:
> И основная проблема как раз в том, что вызывать Dispose нужно вручную, > отслеживая все ветви выполнения, а это ничем не лучше старого доброго C, > хотя, казалось бы, с появлением GC все должно делаться автоматически.
Ну тут конечно не надо смешивать эти две проблемы — автоматическое
освобождение памяти, и автоматическое освобождение любых ресурсов вообще,
но ... на деле оказывается они действительно связаны.
Ну и я хотел бы добавить, что в Java даже нет средств расширения языка,
которые могли бы позволить, скажем, программисту, пишушему класс для работы
с файлом, сделать что-то, что позволило бы программисту, использующему
этот класс, НЕ ДУМАТЬ О ЗАКРЫТИИ ФАЙЛА.
Единственное, что приходит на ум, это решение в стиле Java
-- реализовать класс-стратегию для работы с файлом, которая бы открывала
файл, вызывала пользоват. код и закрывала бы файл
-- реализовать интерфейс для осуществления операций с файлом
-- дать пользователю реализовать этот интерфейс, создать стратегию,
и имплементацию этого интерфейса, и, слив это всё в едином экстазе,
вызвать главный метод стратегии, который бы всё делал.
Но это, как вы понимаете,
-- выглядит гораздо сложнее, чем
try
{
}
finally { file.close() }
-- никак не решает проблемы, потому что пользователю всё равно
придётся заботится о том, чтобы файл закрывался сам, оформляя весь
код имменно таким образом,
-- и наконец просто слишком сложно для того, чтобы не забыть
закрыть файл.
> Я не прав? Если я не прав, зачем тогда ввели ключевое слово using в C#, > а? Если и так все «автоматическое»?
Ну отчасти не прав. В том, что GC всё-таки работают, как идея, и реальные
системы на них и на Java тоже работают. Может, требуют больше ресурсов.
Но работают -- это надо признать, хотя я тоже от этого не в восторге.
Здравствуйте, MasterZiv, Вы писали:
MZ>Ну и я хотел бы добавить, что в Java даже нет средств расширения языка, MZ>которые могли бы позволить, скажем, программисту, пишушему класс для работы MZ>с файлом, сделать что-то, что позволило бы программисту, использующему MZ>этот класс, НЕ ДУМАТЬ О ЗАКРЫТИИ ФАЙЛА.
Вопрос в том, так ли уж часто это надо пользователю. Как правило если пользователь хочет "не думать о файлах", то он хочет не думать именно о файловом вводе/выводе вообще, получив взамен нечто более высокоуровневое — типа, скажем, такого:
Задача программиста, пишущего либу — дать ему такую возможноть. И это будет всяко красивее и читабельнее, чем манипуляции с try ... finally или неявными действиями в деструкторе.
