operator using and IDisposable

[hick91]

какая раздница между оператором using и методом Dispose?
В плане где нужно использовать первое, где второе? в чем различие?
PS: Ведь using использует реализацию данного интерфейса, дак зачем тогда использовать метод dispose в ручную?

[Пепел Феникса]

using это концепция RAII, просто синтаксический сахар.(удобный кстати)
не нравится(или не подходит, ибо using это один блок, между процедурами не передашь ресурс) используйте интерфейс напрямую.

[hick91]

Ответ верный, но я немного не правильно задал вопрос.
Эм конкретизируем для маленького блока:
Using ( для объекта p выделяем ресурсы )
{
/.../
}

и

для объекта p выделяем ресурсы
/.../
p.Dispose();

в чем раздница? ( раздница есть, я сам точно не знаю в чем, но препод тонко намекнул на работу Сборщика мусора )

[Пепел Феникса]

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

[Reskov]

если произойдет экзепшион в блоке using то ресурс все равно будет освобожден, во втором подходе ресурсу будет освобожден только при сборе мусора
using разворачивается в нечто подобное

try
  {
    byte charset = font1.GdiCharSet;
  }
  finally
  {
    if (font1 != null)
      ((IDisposable)font1).Dispose();
  }

[Selestis]

то его освобождение произойдет только при сборке мусора.

Всё гораздо хуже)
Веселье в том, что упомянутый сборщик мусора IDisposable сам по себе нифига не освобождает. Сборщик вызывает только финалайзер ~Class() (если есть), из которого обычно дергают Dispose, да и то не факт что вызовет сразу как собрал. В обычном случае с бесхитростным IDisposable не произойдет вообще ничего, и ресурсы останутся занятыми. Так что в любом случае оставлять IDisposabl'ы на волю сборщика не следует.

[Пепел Феникса]

Сообщение от Selestis

Всё гораздо хуже)
Веселье в том, что упомянутый сборщик мусора IDisposable сам по себе нифига не освобождает. Сборщик вызывает только финалайзер ~Class() (если есть), из которого обычно дергают Dispose, да и то не факт что вызовет сразу как собрал. В обычном случае с бесхитростным IDisposable не произойдет вообще ничего, и ресурсы останутся занятыми. Так что в любом случае оставлять IDisposabl'ы на волю сборщика не следует.

ну да, кривые классы я не учел.

[Mixim]

Сообщение от hick91

Ответ верный, но я немного не правильно задал вопрос.
Эм конкретизируем для маленького блока:
Using ( для объекта p выделяем ресурсы )
{
/.../
}

и

для объекта p выделяем ресурсы
/.../
p.Dispose();

в чем раздница? ( раздница есть, я сам точно не знаю в чем, но препод тонко намекнул на работу Сборщика мусора )

Вот смотри, имеем код (некоторая часть позаимствована с MSDN):

protected MyMethod(String SmtpServerAddress)
{
// Command line argument must the the SMTP host.
            SmtpClient client = new SmtpClient(SmtpServerAddress);
            // Specify the e-mail sender.
            // Create a mailing address that includes a UTF8 character
            // in the display name.
            MailAddress from = new MailAddress("jane@contoso.com", 
               "Jane " + (char)0xD8+ " Clayton", 
            System.Text.Encoding.UTF8);
            // Set destinations for the e-mail message.
            MailAddress to = new MailAddress("ben@contoso.com");
            // Specify the message content.
            MailMessage message = new MailMessage(from, to);
            message.Body = "This is a test e-mail message sent by an application. ";
            // Include some non-ASCII characters in body and subject.
            string someArrows = new string(new char[] {'\u2190', '\u2191', '\u2192', '\u2193'});
            message.Body += Environment.NewLine + someArrows;
            message.BodyEncoding =  System.Text.Encoding.UTF8;
            message.Subject = "test message 1" + someArrows;
            message.SubjectEncoding = System.Text.Encoding.UTF8;
            // Set the method that is called back when the send operation ends.
            client.SendCompleted += new 
            SendCompletedEventHandler(SendCompletedCallback);
            // The userState can be any object that allows your callback 
            // method to identify this send operation.
            // For this example, the userToken is a string constant.
            string userState = "test message1";
            client.SendAsync(message, userState);
}

Как можно заметить, в этом коде создается экземпляр класса SmtpClient, который отправляет сообщение на электронную почту. Указанный класс имеет реализацию интерфейса IDisposable, но в сумотохе забыли написать в конце:

client.Dispose();

Теперь представим, что указанный метод вызывается каждые 2 секунды в течении 1 часа. Не факт, что сборщик мусора сможет после каждого исполнения собрать всю память => из-за нашей забывчивости, за этот час уйдет в небытие столько памяти, что стыдно становится. Потом сидишь и с помощью отладчика разбираешься где утечка памяти (есть даже специальные дополнения к VS для этого) и вновь не факт, что ты быстро найдешь причину ошибки. В свою очередь, если бы все классы, которые имеют реализацию интерфейса IDisposable были бы обернуты в блок using, проблемы бы вообще не было. Это я привел упрощенный пример.
Сам стараюсь всегда все что только возможно оборачивать в using - дает о себе знать моя скупость на динамическую память.
Также советую перевести и прочесть небольшую статью на CodeProject, где описывается в какое количество строк рукописного кода может выльиться оператор using. Цитирую и вставляю пару комментариев от себя:

IDisposable x = ...;//создаем объект, имеющий реализацию интерфейса IDisposable
//оборачиваем весь код, где он используется в try{...}finally{}
try {
 
} 
//при любых условиях выполнить следующий блок
finally 
{ 
x.Dispose(); 
}

Согласись, что кода намного больше