1. C# / Говнокод #24197

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    using (var stream = File.Open(inFile, FileMode.Open))
    using (var reader = new StreamReader(stream))
    using (var csvReader = new CsvReader(reader, new Configuration
    {
    HeaderValidated = HeaderValidated,
    MissingFieldFound = null,
    PrepareHeaderForMatch = header =>
        CultureInfo.CurrentCulture.TextInfo.ToTitleCase(header)
    }))
    using (var outStream = File.Open(outFile, FileMode.CreateNew, FileAccess.Write, FileShare.Read))
    using (var writer = new StreamWriter(outStream))
    using (var csvWriter = new CsvWriter(writer))

    Запостил: mazhuravlev, 26 Апреля 2018

    Комментарии (43) RSS

    • Ничего не понял. Переведи на "PHP".
      Ответить
    • Где тут говно, C#?
      (разве что в самом языке, %username%, - в плюсах можно было бы просто завести локальную переменную, а тут нужно не забыть using - напишешь просто new и будет непонятное поведение...)
      Ответить
      • Непонятно повёл себя с твоим анусом.
        Ответить
      • Да, using (точнее говоря IDisposable) это забавный костыль, затыкающий собой неизвестность момента когда вызовется финалайз/~.

        GC собирает свой урожай глупости: приходится платить за право не думать про управление памятью
        Ответить
        • Ну using это еще структурно и системно, а вот с полями классов...
          C++:
          File m_file; // Этот объект будет автоматически разрушен
          Object *m_parent; // Внимание! Это указатель, будьте осторожны.


          C#:
          File m_file; // Это ссылка. Не забыть вызвать Dispose() во всех местах!!!

          ЗАТО НЕТ ЭТИХ ДУРАЦКИХ ЗВЕЗДОЧЕК А ТО УКАЗАТЕЛИ ЭТО СЛОЖНА Я ИХ НЕ ПОНИМАЮ
          Ответить
          • File m_file; // Этот объект будет автоматически разрушен

            Объект-то разрушен будет, а ресурсы не освободит, если это не происходит в деструкторе, а нужно, например, вызвать метод вроде Dispose у IDisposable. Тут речь не про GC, он в любом случае все соберет, а про управление ресурсами.
            Ответить
            • Говоришь про до-диез, а комментируешь строчечку C++
              Ответить
              • Нет, про С++ говорю. Dispose() в C# это совсем не то же самое, что delete в С++. Вне блока using объект попадет под GC не потому, что using автоматически задиспозил его, а потому, что выполнение вышло из области видимости, где он был объявлен.
                Ответить
                • Вне блока using объект попадет под GC потому что у CLR кончилась память.
                  Она может кончиться через 5 лет или через 200 лет. Десктрутор может не вызваться никогда
                  Ответить
                  • > Десктрутор может не вызваться никогда
                    Там вроде по таймеру GC запускается как раз для таких случаев.
                    Ответить
            • > а ресурсы не освободит
              Из-за исключений в крестах сложно контролить вызов всех этих close() — заебёшься try расставлять да руками каскадить для полей. Поэтому все вменяемые классы соблюдают RAII и в десктрукторе освобождают ресурсы.

              А вот в джаве и шарпе до сих пор руками солнце закатывают (using спасает далеко не во всех случаях). Плата за недетерминированность GC.
              Ответить
              • >using спасает далеко не во всех случаях
                Просвятишь?
                Ответить
                • Поля объектов.
                  Ответить
                  • Что с ними?
                    Ответить
                    • Из dispose() объекта надо дёргать dispose() его полей.
                      Ответить
                      • Казалось бы, причём тут делфи.
                        Ответить
                      • Ответить
                      • Ответить
                      • Ответить
                      • И тут пользователи референс каунтинга в очередной раз прыснули над маркетинговым булщитом про крутизнуGC;)
                        Ответить
                        • > крутизнуGC
                          Ну GC таки крут -- для других объектов этот dispose дёргать не надо. Да и мелкие временные объекты быстро зачищает.
                          Ответить
                          • А так же быстро и дешево выделяет память и хендлит циклы

                            Но вот невозможность быстро и гарантированно что-то очистить действительно напрягает и заставляет делать такие костыли как IDisposable. Это не только .NEt, я и в проектах на Java такое видал
                            Ответить
                        • > прыснули над маркетинговым булщитом

                          Вы там как, односвязные списки без переполнения стека уже научились освобождать?
                          Ответить
                          • Односвязные списки - это прошлый век и вообще немодно. Не нужны!
                            Ответить
                          • У всех свои недостатки, мы еще и референс циклы вручную хендлим.

                            На самом деле мне нужно было писать зеленым, потому что у меня нет strong opinion на этот счет
                            Ответить
                          • Расскажите юннатам про проблему
                            Ответить
                            • Что-то вроде
                              http://govnokod.ru/19104

                              В плюсах аналогичную проблему легко сделать явно:
                              struct node<T> {
                                T data;
                                std::unique_ptr<node<T>> next;
                              };
                              Если сделать длинный-длинный (зависит от размера стека, у нас в проде это несколько килобайт) список, то деструктор порвёт стек.
                              Ответить
                              • Так а в чем проблема руками написать деструктор?
                                Ответить
                                • В том, что эта проблема обычно возникает не на нахуй никому не нужном односвязном списке из смартпоинтеров, а на разрушении большой кучи разнородных объектов и коллбеков.
                                  Ответить
                              • Проверил на свежем XCode и Swift4.1; забавно, что в Release-конфигурации всё работает окей (оптимизация?), в Debug'е всё так же валится. Но
                                var _a : R?
                                по идее можно заменить на
                                weak var _a : R?
                                Ответить
                      • Казалось бы, в каком ЯП это делать не надо
                        Ответить
                        • В крестах деструкторы полей вызываются сами.
                          Ответить
                          • > SMTP Error: Data not accepted. The following From address failed: [email protected]

                            Страйкир получает все коменты себе на почту? Или это адрес dm_fomenok'а? Или это адрес ОПа?
                            Ответить
                            • >>>"SMTP Error: Data not accepted. The following From address failed: [email protected] "

                              >>>"The following From address failed: [email protected] "

                              >>>"From address"

                              >>>"From"

                              >>>"From"

                              >>>"From"

                              >>>"From"

                              >>>"From"
                              Ответить
                            • > Страйкир получает все коменты себе на почту?
                              Может, он любит обмазываться свежими комментами и читать?
                              Ответить
                          • Докажи
                            Ответить
        • В чем проблема-то?
          Ответить

    Добавить комментарий