Вышел Mono 3.0

C++:

ofstream( "results.txt" ) << outputText;

C#:

using (var fs = new FileStream("d:\\results.txt", FileMode.Create,
    FileAccess.Write, FileShare.Write))
  {
    byte[] data = UnicodeEncoding.Default.GetBytes(outputText);
    await fs.WriteAsync(data, 0, data.Length);
  }

Просто вы не привыкли писать на шарпе (c)

Просто посмотрите сколько полезного появилось за последние 10 лет в .NET, а сколько — в Java и с каким опозданием. Также Java не позволяет толком оптимизировать код. Ни тебе структур, ни указателей.

Разработчики твиттера прочитали твой пост и стремительно бросились переписывать свою инфраструктуру на моне

как ваш крестовой код будет реагировать на исключительные ситуации, а как будет реагировать шарповый?

Без пояснения всё выглядело как сравнение тёплого с мягким, а так почти всё так.

З.Ы. Пользуясь случаем, передаю привет из about'а KeePassX ;)

Смешно конечно, но некорректно какбэ. Можно на крестах написать длиннее, а на решетке короче.

File.WriteAllLines(«results.txt», outputText); ЧЯДНТ?

File.WriteAllLines(«results.txt», outputText); ЧЯДНТ?

не пишешь using + строку с открытием файла, using нужен т.к. в С# допотопное ручное управление ресурсами

как ваш крестовой код будет реагировать на исключительные ситуации, а как будет реагировать шарповый?

как захочу - захочу одной строкой исключения разрешу, захочу опять же одной строкой получу состояние, итого кода на обработку таких ситуаций будет столько же как и в C#, ну и в данном примере для С# исключительные ситуации тоже никак не обрабатываются

Using - это чтобы не писать за зря .Dispose(), плюс он отрабатывает в финалайзе, т.е. освобождение выполнится гарантировано. Не слышал, чтобы при разовой записи в файл это нужно. Если писать много и в один и тот же файл - то да, стрим.

как ваш крестовой код будет реагировать на исключительные ситуации,

кстати отдельных пару слов об этом - в С++ не надо помнить об using и ставить его везде, после исключения все закроется и освободится автоматом, чего не скажешь про C# :(

Не слышал, чтобы при разовой записи в файл это нужно

нужно, чтоб файл закрыть

Файл закроется, инфа сохранится, доступ освободится. Гарантировать не буду: сто лет так ни делал, потому что опасно в серьезных проектах, но вроде бы просто сработать должно.

Файл закроется

как только GC доберется до этого объекта, а пока ему будет «лень» - файл будет висеть открытым

нужно, чтоб файл закрыть

В данном случае не нужно, т.к. WriteAllLines - статический метод класса File, который (цитирую msdn) «Creates a new file, write the specified string array to the file, and then closes the file.»

В маленьком проекте он очень быстро доберется, про большой проект я уже писал)

File.WriteAllLines(«results.txt», outputText); ЧЯДНТ?

не пишешь using + строку с открытием файла, using нужен т.к. в С# допотопное ручное управление ресурсами

Ее и не надо писать. Открытие, закрытие и обработка исключительных ситуаций находится в потрохах метода WriteAllLines.

да, я уже понял, невнимательно читал, сорри

http://msdn.microsoft.com/en-us/library/92e05ft3.aspx

там вроде ничего сказано про реализацию метода и в частности про поведение при исключении при записи

там вроде ничего сказано про реализацию метода и в частности про поведение при исключении при записи

Благо все это - оупен сорс:

public static void WriteAllLines (string path, string [] contents)
{
	using (StreamWriter writer = new StreamWriter (path)) {
		WriteAllLines (writer, contents);
	}
}

static void WriteAllLines (StreamWriter writer, string [] contents)
{
	foreach (string line in contents)
		writer.WriteLine (line);
}

спасибо

А какие могут быть варианты кроме закрытия файла и выброса исключения наружу?

Вот реализация этих методов в mono:

public static void WriteAllLines (string path, string [] contents)
{
	using (StreamWriter writer = new StreamWriter (path)) {
		WriteAllLines (writer, contents);
	}
}

static void WriteAllLines (StreamWriter writer, string [] contents)
{
	foreach (string line in contents)
		writer.WriteLine (line);
}

могло быть без using, хотя конечно его написать было более чем логично

П.С. судя по всему, код в mono берется напрямую из первоисточника, что в принципе хорошо для совместимости

Этот дикий микс из var, let, select и using в непонятных местах совсем не похож на тот лаконичный синтаксис C#, который я видел в версии 2.0.

функцианальное программирование заполоняе

Это плохо?

Просто я не умею писать на шарпе

fixed

Спрашивали о ситуациях когда mono удобнее чем Qt и GTK+, а ответили про C# и написание веб приложений.

This is LOR, babe

Просто я не умею писать на шарпе

это конечно да, но от этого using не перестает быть очевидным костылем

В каком месте он костыль? То что Dispose при работе с каким-нибудь объектом, скажем при работе с классом, связанным с БД, не нужно ручками писать и в файналайз засовывать? А почему, если это ересь и костыль, недавно его аналог добавили в джаву?

Я в жабе не силен, но вроде оно там пишется как try( ... ) а не как using( ... )

Кто нить юзал связку linux+nginx+xsp? Если да, то как впечатления?

То что Dispose при работе с каким-нибудь объектом, скажем при работе с классом, связанным с БД, не нужно ручками писать и в файналайз засовывать?

а это недостаток реализации ЯП, который using прикрывает, GC не может эффективно и сразу освобождать ресурсы, потому часть его работы переложили на программистов

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

я только благодаря джаве и знаю, что это такое в С#, на последнем я даже Hello World не писал, и да - в джаве оно ничем не лучше

толсто

Но правда. Под андроид и айос – нативно. Под вп7 – тоже нативно, там абсолютно всё под дотнетом бегает.

Тебе было велено озвучить твое (ублюдочное и неправильное) определение виртуальной машины. Ты, школота, этого не сделало. Свободен, чмо.

Стоп. Интерфейс айдиспозбл вешается туды, где нужен тонкий контроль за ресурсами - соединения с БД и прочие вещи с ограниченным ресурсом. Ты можешь юзать страшный проект с огромной нагрузкой, и GC просто не сможет за всем успевать. Поэтому и Dispose, поэтому и Using(...). Это подстраховка такая, я считаю что если бы GC работал в 100500 раз лучше, Dispose() и using() стоило бы все равно оставить, хотя у меня нареканий к GC в шарпе, в общем, нет.

Тем более раз в конкуренте от другой корпорации зла все также, я не вижу резона ругать GC в шарпе - сравнить не с чем же по сути больше.

Ха, тема уже в топ-10, не знает границ моносрач)

Ленюсь

соединения с БД и прочие вещи с ограниченным ресурсом

да, «unmanaged» ресурсы, которые надо руками освобождать

и GC просто не сможет за всем успевать. Поэтому и Dispose, поэтому и Using(...)

ну вот возьмем случай с using - разве есть проблема компилятору определить, что объект реализует IDisposable и используется только в рамках «прямой» видимости? вряд ли, и значит можно сразу добавить код для освобождения ресурсов, не заставляя писать его вручную, но вероятно это посчитали неоптимальным или я просто узко посмотрел на задачу и не увидел важных деталей

Если я правильно помню, то фишка IDisposable и связанного с этим «сахара» в том, чтобы освободить ресурсы немедленно, а не уничтожить объект как таковой. Т.е. он не уничтожается после вызова .Dispose() и собирается GC на общих основаниях. Один из бонусов класического использования using(..) в том, что эта конструкция не только автоматически вызывает Dispose(), но и ограничивает область видимости переменной, так что на объект после выхода из блока более никто не ссылается, а значит это первый кандидат на сбор мусора.

Возможно, пришлось бы усложнять GC или другой компонент CLR. Усложнение, в этом случае, это практически неизбежно лишние тормоза. Вот на откуп кодерам и оставили этот момент.

Да, вы правы.

Имхо, Dispose+using все-таки не костыль, а фича)

освободить ресурсы немедленно, а не уничтожить объект как таковой.

да, я это и имел ввиду

но и ограничивает область видимости переменной

компилятор может и сам ее определить

компилятор может и сам ее определить

только область не видимости, а «жизни»

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

только в том частном случае, когда объект создали в начале метода и ссылку на него никуда не передали

во всех случаях, когда и используют using

не слишком надежно чтобы провоцировать людей не использовать явно освобождение ресурсов

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

А какие entepriZe приложения написаны на этой моне?

во всех случаях, когда и используют using

это знает программист, а компилятору прийдется пройтись по всему стеку вызовов от создания объекта, до выхода из метода и убедиться что ссылка не «ушла», в результате выйдет что то типа «automatic reference count» как в objective-c и прийдется выдумывать ключевое слово противоположное using, подсказывающее компилятору НЕ вызывать Dispose, т.к. опять же программист лучше знает что ему нужно.

а компилятору прийдется пройтись

мне его не жалко )

прийдется выдумывать ключевое слово противоположное using, подсказывающее компилятору НЕ вызывать Dispose, т.к. опять же программист лучше знает что ему нужно.

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

Но и не графический тулкит какой-нибудь который через слой абстракции можно поменять и продолжать писать дальше как ни в чём не бывало.

RAII это фича языка, от VM поддержки не требуется