C vs C++ , Не опять а снова

Цитата OpenGL @ 14.03.18, 14:03

А Флекс заходит и ничего не пишет

https://twitter.com/flex_ferrum/status/973161369104273408

Цитата Астарот @ 14.03.18, 03:59

Ага, напоминает. Тебя. Я угадал ожидаемый тобой ответ?

Не-а.

Цитата

Почему я это сделал? Потому что могу.

Авторство цитаты проставь сам.

Цитата D_KEY @ 14.03.18, 05:48

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

У меня ошибка не может возникнуть там, где находится моя сфера ответственности, поэтому обрабатывать я её просто не обязан. Сообщить о ней – возможно, но даже тут это куда лучше решается методами не моего приложения, а в высококритичных системах вообще обязано мониториться на системном уровне.
Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Будь то нехватка места, бэд-сектора, отсутствие прав на запись (для открытого на чтение потока, например) или при потере коннекта. close() же только лишь освобождает занятый у операционного окружения общий ресурс. Любые проблемы в этой точке являются проблемами окружения, и меня волновать не должны. Другое дело, когда ошибка связана с моими некорректными действиями. Там у тебя C-код, там адресная арифметика, там отсутствуют гарантии языка, в частности завязанные на пары конструктор/деструктор, итп. Там многое делается руками. У меня же нет сырых указателей, у меня контейнеры, адресная арифметика на итераторах, и я всецело использую потенциал гарантий языка. Уже давно, причём, не менее 15-лет. Примерно столько же времени я не сталкиваюсь с подобного рода багами в своих продуктах, которые до сих пор волнуют Сшников, которые всё продолжают и продолжают искать утечки памяти и двойные очистки. У меня проблем не было, не будет их и в дальнейшем, пока я пишу на Плюсах, а не в Сях. Так что да, что-то меняется принципиально.

Цитата D_KEY @ 14.03.18, 05:48

Почему их close может выставить/кинуть "ошибку"?

Потому что close() не деструктор, а кроме конструктора есть ещё open(). А ещё потому, что это старый компонент stl. Его интерфейс по сути является расширением легаси из конца 80-ых. Как следствие, он не полностью соответствует RAII. Была б моя воля, сегодня std::basic_streambuf<> был бы абстрактным классом, как и классы до std::basic_(i|o)stream<> в иерархии, а open() с close() отсутствовали бы вовсе.

Цитата D_KEY @ 14.03.18, 05:48

А пример я привел для иллюстрации того, что выбор C++ был плохим решением для той команды (поскольку ухудшил результат).

Тебе который раз, третий?, указать, что выбор никто не осуждает?

Добавлено 14.03.18, 15:09

Цитата Астарот @ 14.03.18, 07:01

Он не имеет права? Так и вижу эту беседу.
...
Ну, или как-то так

Прикинь, я тоже. Потому и делал там выше оговорку, ссылаясь на твоё мнение об этом его посте.

Добавлено 14.03.18, 15:13

Цитата Астарот @ 14.03.18, 07:24

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

Ох, не напоминай. Я как раз им последний год эпизодически – слава богу, что лишь эпизодически – занимаюсь, т.к. на нём нужно писать скрипты для Rational Test RealTime.

Добавлено 14.03.18, 15:17

Цитата Астарот @ 14.03.18, 08:16

Цитата negram @ 14.03.18, 08:10

Перл отличный язык!

Вот! Что и требовалось доказать! Плохой negram специалист?

Э-э-э... стебанутый?

Добавлено 14.03.18, 15:25

Цитата D_KEY @ 14.03.18, 13:27

Но судя по тому, что тебя совершенное не беспокоит дефолтное создание объекта с удаленным вроде бы дефолтным конструктором, ты довольно всеядный

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

Добавлено 14.03.18, 15:28

Цитата Flex Ferrum @ 14.03.18, 14:32

Флекс сейчас постепенно в твиттер переползает и начинает писать про C++ по-английски.

Упс. Давай, делай зеркало этой темы там. Вдруг Торвальдс прочтёт, давай его позлим.

Цитата Qraizer @ 14.03.18, 15:06

Упс. Давай, делай зеркало этой темы там. Вдруг Торвальдс прочтёт, давай его позлим.

Я скорее об обратном варианте думаю - сделать зеркало оттуда сюда. А Торвальдс на мой акк даже не посмотрит - фолловеров мало да и богомерсссский C++ в дескрипшене торчит.

Цитата Qraizer @ 14.03.18, 15:06

Тебе который раз, третий?, указать, что выбор никто не осуждает?

Конкретнее, я не осуждаю. Я осуждаю лишь форму аргументации этого выбора. Что он там пишет? Ах-ах, если вдруг корневая абстракция окажется неудачной, придётся все классы переписывать. А если в C такое случится, то не надо, надо полагать, да? Ой-ой, если при использовании какой-то либы бяка, то надо разбираться, что где не так, и кто виноват и что делать. А если в C такое же, то не надо. Ок, понял. И после этого он ещё не мудозвон ну хорошо, жирнючий тролль?

Добавлено 14.03.18, 15:37

Цитата Flex Ferrum @ 14.03.18, 15:33

А Торвальдс на мой акк даже не посмотрит - фолловеров мало да и богомерсссский C++ в дескрипшене торчит.

А ты его пригласи. Прям сюда, в эту тему. Всю жизнь мечтал кого-нибудь из ярких имён забанить за нарушение Правил .

Сообщение отредактировано: Qraizer - 14.03.18, 15:39

Цитата Qraizer @ 14.03.18, 15:36

А ты его пригласи. Прям сюда, в эту темы.

Пока могу только хаскелиста, члена комита по стандратизации хаскеля зазвать. Но только в другую ветку.

Цитата Qraizer @ 14.03.18, 15:06

Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Будь то нехватка места, бэд-сектора, отсутствие прав на запись (для открытого на чтение потока, например) или при потере коннекта. close() же только лишь освобождает занятый у операционного окружения общий ресурс.

А как же буферизация, flush и всё такое? Если flush явно вызывать до деструктора, не будет ли это тем же самым, что и в примере с term? Или flush не должен бросать исключений? Мне это видится более вероятным, чем выброс исключения из write, который может просто в буфер байтиков накидать. Или они (исключения от flush) должны обрабатываться в деструкторе объекта file? Или я чего-то не понял?

Вот это дельное замечание, кстати. Из-за того, что кеширование никак не стандартизируется, всплывают всякие разные имплементейшн-дефинед. close() естественно сам по себе на это никак не завязан, как и деструктор, однако конкретные реализации могут.

Цитата Астарот @ 14.03.18, 07:24

Но если на перле кто-то выдает результат лучший, чем я на java

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

Цитата JoeUser @ 15.03.18, 00:04

Цитата Астарот @ 14.03.18, 07:24

Но если на перле кто-то выдает результат лучший, чем я на java

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

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

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

Цитата Астарот @ 15.03.18, 04:05

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

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

Цитата Астарот @ 15.03.18, 04:05

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

Бенчит разные способы записи логов в БД PostgreSQL. Описывать зачем это было сделано - не буду, ибо есть все в теме, на которую есть ссылка.

Цитата JoeUser @ 15.03.18, 06:41

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

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

Цитата JoeUser @ 15.03.18, 06:41

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

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

Цитата Астарот @ 15.03.18, 07:04

Это ты "что-то померял", в лучшем случае.

Можно было бы конечно запустить N-раз программно. Но я руками запускал 5-7 раз. Результаты не сильно отличались. Мне было важно оценить разницу в скоростях записи логов по первому и второму варианту. Разница сохранялась примерно одинаковой.

Ну, я и говорю - что-то померял Хотя по уму, если уж мерить скорость вставки, то замер должен происходить на стороне БД, что бы ты видел сколько времени трарит твоя БД на вставку, а не искажал результат сетью, скриптами, и так далее. Ну, и запускать нужно хотя бы пару сотен раз, а не ручками разок-другой

Ээээ... А тут точно про C++ vs C?

Цитата Qraizer @ 14.03.18, 15:06

У меня ошибка не может возникнуть там, где находится моя сфера ответственности, поэтому обрабатывать я её просто не обязан

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

Добавлено 15.03.18, 08:44

Цитата Qraizer @ 14.03.18, 15:06

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

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

Добавлено 15.03.18, 08:45

Цитата Qraizer @ 14.03.18, 15:06

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

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

Добавлено 15.03.18, 08:48

Цитата Qraizer @ 14.03.18, 15:06

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

Они тебя должны волновать с точки зрения информации. Хотя бы залогировать это дело тебе во многих случаях нужно.