На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (37) « Первая ... 18 19 [20] 21 22 ...  36 37  ( Перейти к последнему сообщению )  
> C vs C++, Не опять а снова
    Цитата OpenGL @
    А Флекс заходит и ничего не пишет :(

    https://twitter.com/flex_ferrum/status/973161369104273408
    :D
    "If someone claims to have the perfect programming language, he is either a fool or a salesman or both"(c) Bjarne Stroustrup
      Цитата Астарот @
      Ага, напоминает. Тебя. Я угадал ожидаемый тобой ответ?
      Не-а.
      Цитата
      Почему я это сделал? Потому что могу.
      Авторство цитаты проставь сам.
      Цитата D_KEY @
      Что-то принципиально меняется от того, где написан блок закрытия файла? У тебя ошибка может возникнуть при закрытии ресурса, будь то соединение, файл, память или ещё что-то.
      У меня ошибка не может возникнуть там, где находится моя сфера ответственности, поэтому обрабатывать я её просто не обязан. Сообщить о ней – возможно, но даже тут это куда лучше решается методами не моего приложения, а в высококритичных системах вообще обязано мониториться на системном уровне.
      Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Будь то нехватка места, бэд-сектора, отсутствие прав на запись (для открытого на чтение потока, например) или при потере коннекта. close() же только лишь освобождает занятый у операционного окружения общий ресурс. Любые проблемы в этой точке являются проблемами окружения, и меня волновать не должны. Другое дело, когда ошибка связана с моими некорректными действиями. Там у тебя C-код, там адресная арифметика, там отсутствуют гарантии языка, в частности завязанные на пары конструктор/деструктор, итп. Там многое делается руками. У меня же нет сырых указателей, у меня контейнеры, адресная арифметика на итераторах, и я всецело использую потенциал гарантий языка. Уже давно, причём, не менее 15-лет. Примерно столько же времени я не сталкиваюсь с подобного рода багами в своих продуктах, которые до сих пор волнуют Сшников, которые всё продолжают и продолжают искать утечки памяти и двойные очистки. У меня проблем не было, не будет их и в дальнейшем, пока я пишу на Плюсах, а не в Сях. Так что да, что-то меняется принципиально.
      Цитата D_KEY @
      Почему их close может выставить/кинуть "ошибку"?
      Потому что close() не деструктор, а кроме конструктора есть ещё open(). А ещё потому, что это старый компонент stl. Его интерфейс по сути является расширением легаси из конца 80-ых. Как следствие, он не полностью соответствует RAII. Была б моя воля, сегодня std::basic_streambuf<> был бы абстрактным классом, как и классы до std::basic_(i|o)stream<> в иерархии, а open() с close() отсутствовали бы вовсе.
      Цитата D_KEY @
      А пример я привел для иллюстрации того, что выбор C++ был плохим решением для той команды (поскольку ухудшил результат).
      Тебе который раз, третий?, указать, что выбор никто не осуждает?

      Добавлено
      Цитата Астарот @
      Он не имеет права? Так и вижу эту беседу.
      ...
      Ну, или как-то так
      Прикинь, я тоже. Потому и делал там выше оговорку, ссылаясь на твоё мнение об этом его посте.

      Добавлено
      Цитата Астарот @
      С одной стороны могу только покрутить пальцем у виска, если кто-то скажет мне, что "перл - отличный язык", ну не могу я даже хорошим назвать язык, в котором валидный код можно получить ударом лица о клавиатуру
      Ох, не напоминай. :wacko: Я как раз им последний год эпизодически – слава богу, что лишь эпизодически – занимаюсь, т.к. на нём нужно писать скрипты для Rational Test RealTime.

      Добавлено
      Цитата Астарот @
      Цитата negram @
      Перл отличный язык! :tong:

      Вот! Что и требовалось доказать! :D Плохой negram специалист?
      Э-э-э... стебанутый? :scratch:

      Добавлено
      Цитата D_KEY @
      Но судя по тому, что тебя совершенное не беспокоит дефолтное создание объекта с удаленным вроде бы дефолтным конструктором, ты довольно всеядный
      D_KEY, а почему должно смущать сознательное использование фичи, сознательное введённое в язык? Тебя не смущает потенциальная возможность вызова статических функций из других модулей? Или даже доступ к приватным полям? C++ как раз тем и удобен, что практически на каждый запрет можно найти обходной путь, если приспичит. Однако при этом чем опаснее такой обход, тем сложнее его сделать случайно. Ты вот зачем там {} расположил? Намерено? Для чего? Для чего вообще {} предназначены, напомнить?

      Добавлено
      Цитата Flex Ferrum @
      Флекс сейчас постепенно в твиттер переползает и начинает писать про C++ по-английски.
      Упс. Давай, делай зеркало этой темы там. Вдруг Торвальдс прочтёт, давай его позлим.
      Одни с годами умнеют, другие становятся старше.
        Цитата Qraizer @
        Упс. Давай, делай зеркало этой темы там. Вдруг Торвальдс прочтёт, давай его позлим.

        Я скорее об обратном варианте думаю - сделать зеркало оттуда сюда. :) А Торвальдс на мой акк даже не посмотрит - фолловеров мало да и богомерсссский C++ в дескрипшене торчит. :D
        "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
        Морган Фриман
        Реализация шаблонов Jinja2 для C++ Jinja2 C++
          Цитата Qraizer @
          Тебе который раз, третий?, указать, что выбор никто не осуждает?
          Конкретнее, я не осуждаю. Я осуждаю лишь форму аргументации этого выбора. Что он там пишет? Ах-ах, если вдруг корневая абстракция окажется неудачной, придётся все классы переписывать. А если в C такое случится, то не надо, надо полагать, да? Ой-ой, если при использовании какой-то либы бяка, то надо разбираться, что где не так, и кто виноват и что делать. А если в C такое же, то не надо. Ок, понял. И после этого он ещё не мудозвон ну хорошо, жирнючий тролль?

          Добавлено
          Цитата Flex Ferrum @
          А Торвальдс на мой акк даже не посмотрит - фолловеров мало да и богомерсссский C++ в дескрипшене торчит.
          А ты его пригласи. Прям сюда, в эту тему. Всю жизнь мечтал кого-нибудь из ярких имён забанить за нарушение Правил :wub: .
          Сообщение отредактировано: Qraizer -
          Одни с годами умнеют, другие становятся старше.
            Цитата Qraizer @
            А ты его пригласи. Прям сюда, в эту темы.

            Пока могу только хаскелиста, члена комита по стандратизации хаскеля зазвать. Но только в другую ветку. :)
            "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
            Морган Фриман
            Реализация шаблонов Jinja2 для C++ Jinja2 C++
              Цитата Qraizer @
              Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Будь то нехватка места, бэд-сектора, отсутствие прав на запись (для открытого на чтение потока, например) или при потере коннекта. close() же только лишь освобождает занятый у операционного окружения общий ресурс.

              А как же буферизация, flush и всё такое? Если flush явно вызывать до деструктора, не будет ли это тем же самым, что и в примере с term? Или flush не должен бросать исключений? Мне это видится более вероятным, чем выброс исключения из write, который может просто в буфер байтиков накидать. Или они (исключения от flush) должны обрабатываться в деструкторе объекта file? Или я чего-то не понял?
              “Object-oriented design is the roman numerals of computing.” — Rob Pike
              All software sucks
                Вот это дельное замечание, кстати. Из-за того, что кеширование никак не стандартизируется, всплывают всякие разные имплементейшн-дефинед. close() естественно сам по себе на это никак не завязан, как и деструктор, однако конкретные реализации могут.
                Одни с годами умнеют, другие становятся старше.
                  Цитата Астарот @
                  Но если на перле кто-то выдает результат лучший, чем я на java

                  Ну давай на твою Яву посмотрим :lol:
                  Вот как-то я писал код на Перл 5 для теста многопоточной записи в БД PostgreSQL.
                  Если не лениво - покажи как бы это было бы написано на Яве. Лучше-худше - тут сложно будет оценить, разве только что по количеству написанных буквоф.
                  Мои программные ништякиhttp://majestio.info
                    Цитата JoeUser @
                    Цитата Астарот @
                    Но если на перле кто-то выдает результат лучший, чем я на java

                    Ну давай на твою Яву посмотрим :lol:
                    Вот как-то я писал код на Перл 5 для теста многопоточной записи в БД PostgreSQL.
                    Если не лениво - покажи как бы это было бы написано на Яве. Лучше-худше - тут сложно будет оценить, разве только что по количеству написанных буквоф.

                    Во-первых она не моя, а своя собственная. Во-вторых лениво.

                    Добавлено
                    А! В-третьих - твой "бенчмарк" что бенчит-то? И бенчит ли вообще?..

                    Право — это возведенная в закон справедливость. Закон есть этика, высеченная в логике.
                      Цитата Астарот @
                      Во-первых она не моя, а своя собственная. Во-вторых лениво.

                      Тогда остановимся на том, что Перл - замечательный язык :lol:

                      Цитата Астарот @
                      А! В-третьих - твой "бенчмарк" что бенчит-то? И бенчит ли вообще?..

                      Бенчит разные способы записи логов в БД PostgreSQL. Описывать зачем это было сделано - не буду, ибо есть все в теме, на которую есть ссылка.
                      Мои программные ништякиhttp://majestio.info
                        Цитата JoeUser @
                        Тогда остановимся на том, что Перл - замечательный язык :lol:

                        Перл - кошмарный язык. Но ты волен его любить :yes:

                        Цитата JoeUser @
                        Бенчит разные способы записи логов в БД PostgreSQL

                        Судя по тому, что я вижу - нихрена оно не бенчит :crazy: Оно как-то замеряет время, которое ушло на вычисление NOW(), на подстановку параметров, на сам инсерт, на нужное_вписать, и все это один раз, но в десять потоков. Это - не бенчмарк, строго говоря. Это ты "что-то померял", в лучшем случае.

                        Право — это возведенная в закон справедливость. Закон есть этика, высеченная в логике.
                          Цитата Астарот @
                          Это ты "что-то померял", в лучшем случае.

                          Можно было бы конечно запустить N-раз программно. Но я руками запускал 5-7 раз. Результаты не сильно отличались. Мне было важно оценить разницу в скоростях записи логов по первому и второму варианту. Разница сохранялась примерно одинаковой.
                          Мои программные ништякиhttp://majestio.info
                            Ну, я и говорю - что-то померял :D Хотя по уму, если уж мерить скорость вставки, то замер должен происходить на стороне БД, что бы ты видел сколько времени трарит твоя БД на вставку, а не искажал результат сетью, скриптами, и так далее. Ну, и запускать нужно хотя бы пару сотен раз, а не ручками разок-другой :D

                            Право — это возведенная в закон справедливость. Закон есть этика, высеченная в логике.
                              Ээээ... А тут точно про C++ vs C? :)
                              "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
                              Морган Фриман
                              Реализация шаблонов Jinja2 для C++ Jinja2 C++
                                Цитата Qraizer @
                                У меня ошибка не может возникнуть там, где находится моя сфера ответственности, поэтому обрабатывать я её просто не обязан

                                На уровне работы конкретного кода "освобождения", который вызывает некую функцию, способную "ошибиться", у тебя в случае деструктора нет возможности даже сообщить о том, что "вне сфере твоей ответственности" произошел какой-то сбой.
                                Ты считаешь, что можно замолчать проблему. Я думаю, что это не во всех случаях правильно.
                                Логирование же в деструкторах будет не полным, поскольку у тебя нет никакой информации о контексте, в котором происходит завершение. Это не говоря уже о том, что ты потащишь систему логирования в деструктор каждого объекта, который "освобождает" ресурсы.

                                Добавлено
                                Цитата Qraizer @
                                но даже тут это куда лучше решается методами не моего приложения, а в высококритичных системах вообще обязано мониториться на системном уровне.

                                Когда ты пишешь нечто того же nginx, у тебя нет никакого представления о том, кто, как и где тебя будет запускать :) Выдвигать слишком сильные требования к окружению в данном случае бессмысленно.

                                Добавлено
                                Цитата Qraizer @
                                Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта.

                                Вообще-то с точки зрения возможности зафейлиться это почти равноправные функции. По крайней мере в некоторых случаях. И да, если у тебя есть некоторый протокол обмена, например, то "закрытие" может подразумевать и обмен данными с внешней средой.

                                Добавлено
                                Цитата Qraizer @
                                Любые проблемы в этой точке являются проблемами окружения, и меня волновать не должны.

                                Они тебя должны волновать с точки зрения информации. Хотя бы залогировать это дело тебе во многих случаях нужно.
                                "If someone claims to have the perfect programming language, he is either a fool or a salesman or both"(c) Bjarne Stroustrup
                                1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (37) « Первая ... 18 19 [20] 21 22 ...  36 37


                                Рейтинг@Mail.ru
                                [ Script Execution time: 0,1764 ]   [ 14 queries used ]   [ Generated: 21.11.19, 07:48 GMT ]