Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.147.89.85] |
|
Страницы: (37) « Первая ... 18 19 [20] 21 22 ... 36 37 ( Перейти к последнему сообщению ) |
Сообщ.
#287
,
|
|
|
Не-а.
Цитата Авторство цитаты проставь сам.Почему я это сделал? Потому что могу. Цитата D_KEY @ У меня ошибка не может возникнуть там, где находится моя сфера ответственности, поэтому обрабатывать я её просто не обязан. Сообщить о ней – возможно, но даже тут это куда лучше решается методами не моего приложения, а в высококритичных системах вообще обязано мониториться на системном уровне.Что-то принципиально меняется от того, где написан блок закрытия файла? У тебя ошибка может возникнуть при закрытии ресурса, будь то соединение, файл, память или ещё что-то. Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Будь то нехватка места, бэд-сектора, отсутствие прав на запись (для открытого на чтение потока, например) или при потере коннекта. close() же только лишь освобождает занятый у операционного окружения общий ресурс. Любые проблемы в этой точке являются проблемами окружения, и меня волновать не должны. Другое дело, когда ошибка связана с моими некорректными действиями. Там у тебя C-код, там адресная арифметика, там отсутствуют гарантии языка, в частности завязанные на пары конструктор/деструктор, итп. Там многое делается руками. У меня же нет сырых указателей, у меня контейнеры, адресная арифметика на итераторах, и я всецело использую потенциал гарантий языка. Уже давно, причём, не менее 15-лет. Примерно столько же времени я не сталкиваюсь с подобного рода багами в своих продуктах, которые до сих пор волнуют Сшников, которые всё продолжают и продолжают искать утечки памяти и двойные очистки. У меня проблем не было, не будет их и в дальнейшем, пока я пишу на Плюсах, а не в Сях. Так что да, что-то меняется принципиально. Потому что close() не деструктор, а кроме конструктора есть ещё open(). А ещё потому, что это старый компонент stl. Его интерфейс по сути является расширением легаси из конца 80-ых. Как следствие, он не полностью соответствует RAII. Была б моя воля, сегодня std::basic_streambuf<> был бы абстрактным классом, как и классы до std::basic_(i|o)stream<> в иерархии, а open() с close() отсутствовали бы вовсе. Цитата D_KEY @ Тебе который раз, третий?, указать, что выбор никто не осуждает? А пример я привел для иллюстрации того, что выбор C++ был плохим решением для той команды (поскольку ухудшил результат). Добавлено Прикинь, я тоже. Потому и делал там выше оговорку, ссылаясь на твоё мнение об этом его посте. Добавлено Цитата Астарот @ Ох, не напоминай. Я как раз им последний год эпизодически – слава богу, что лишь эпизодически – занимаюсь, т.к. на нём нужно писать скрипты для Rational Test RealTime. С одной стороны могу только покрутить пальцем у виска, если кто-то скажет мне, что "перл - отличный язык", ну не могу я даже хорошим назвать язык, в котором валидный код можно получить ударом лица о клавиатуру Добавлено Э-э-э... стебанутый? Добавлено Цитата D_KEY @ D_KEY, а почему должно смущать сознательное использование фичи, сознательное введённое в язык? Тебя не смущает потенциальная возможность вызова статических функций из других модулей? Или даже доступ к приватным полям? C++ как раз тем и удобен, что практически на каждый запрет можно найти обходной путь, если приспичит. Однако при этом чем опаснее такой обход, тем сложнее его сделать случайно. Ты вот зачем там {} расположил? Намерено? Для чего? Для чего вообще {} предназначены, напомнить? Но судя по тому, что тебя совершенное не беспокоит дефолтное создание объекта с удаленным вроде бы дефолтным конструктором, ты довольно всеядный Добавлено Цитата Flex Ferrum @ Упс. Давай, делай зеркало этой темы там. Вдруг Торвальдс прочтёт, давай его позлим. Флекс сейчас постепенно в твиттер переползает и начинает писать про C++ по-английски. |
Сообщ.
#288
,
|
|
|
Цитата Qraizer @ Упс. Давай, делай зеркало этой темы там. Вдруг Торвальдс прочтёт, давай его позлим. Я скорее об обратном варианте думаю - сделать зеркало оттуда сюда. А Торвальдс на мой акк даже не посмотрит - фолловеров мало да и богомерсссский C++ в дескрипшене торчит. |
Сообщ.
#289
,
|
|
|
Цитата Qraizer @ Конкретнее, я не осуждаю. Я осуждаю лишь форму аргументации этого выбора. Что он там пишет? Ах-ах, если вдруг корневая абстракция окажется неудачной, придётся все классы переписывать. А если в C такое случится, то не надо, надо полагать, да? Ой-ой, если при использовании какой-то либы бяка, то надо разбираться, что где не так, и кто виноват и что делать. А если в C такое же, то не надо. Ок, понял. И после этого он ещё не Тебе который раз, третий?, указать, что выбор никто не осуждает? Добавлено Цитата Flex Ferrum @ А ты его пригласи. Прям сюда, в эту тему. Всю жизнь мечтал кого-нибудь из ярких имён забанить за нарушение Правил . А Торвальдс на мой акк даже не посмотрит - фолловеров мало да и богомерсссский C++ в дескрипшене торчит. |
Сообщ.
#290
,
|
|
|
Цитата Qraizer @ А ты его пригласи. Прям сюда, в эту темы. Пока могу только хаскелиста, члена комита по стандратизации хаскеля зазвать. Но только в другую ветку. |
Сообщ.
#291
,
|
|
|
Цитата Qraizer @ Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Будь то нехватка места, бэд-сектора, отсутствие прав на запись (для открытого на чтение потока, например) или при потере коннекта. close() же только лишь освобождает занятый у операционного окружения общий ресурс. А как же буферизация, flush и всё такое? Если flush явно вызывать до деструктора, не будет ли это тем же самым, что и в примере с term? Или flush не должен бросать исключений? Мне это видится более вероятным, чем выброс исключения из write, который может просто в буфер байтиков накидать. Или они (исключения от flush) должны обрабатываться в деструкторе объекта file? Или я чего-то не понял? |
Сообщ.
#292
,
|
|
|
Вот это дельное замечание, кстати. Из-за того, что кеширование никак не стандартизируется, всплывают всякие разные имплементейшн-дефинед. close() естественно сам по себе на это никак не завязан, как и деструктор, однако конкретные реализации могут.
|
Сообщ.
#293
,
|
|
|
Ну давай на твою Яву посмотрим Вот как-то я писал код на Перл 5 для теста многопоточной записи в БД PostgreSQL. Если не лениво - покажи как бы это было бы написано на Яве. Лучше-худше - тут сложно будет оценить, разве только что по количеству написанных буквоф. |
Сообщ.
#294
,
|
|
|
Цитата JoeUser @ Ну давай на твою Яву посмотрим Вот как-то я писал код на Перл 5 для теста многопоточной записи в БД PostgreSQL. Если не лениво - покажи как бы это было бы написано на Яве. Лучше-худше - тут сложно будет оценить, разве только что по количеству написанных буквоф. Во-первых она не моя, а своя собственная. Во-вторых лениво. Добавлено А! В-третьих - твой "бенчмарк" что бенчит-то? И бенчит ли вообще?.. |
Сообщ.
#295
,
|
|
|
Цитата Астарот @ Во-первых она не моя, а своя собственная. Во-вторых лениво. Тогда остановимся на том, что Перл - замечательный язык Цитата Астарот @ А! В-третьих - твой "бенчмарк" что бенчит-то? И бенчит ли вообще?.. Бенчит разные способы записи логов в БД PostgreSQL. Описывать зачем это было сделано - не буду, ибо есть все в теме, на которую есть ссылка. |
Сообщ.
#296
,
|
|
|
Цитата JoeUser @ Тогда остановимся на том, что Перл - замечательный язык Перл - кошмарный язык. Но ты волен его любить Цитата JoeUser @ Бенчит разные способы записи логов в БД PostgreSQL Судя по тому, что я вижу - нихрена оно не бенчит Оно как-то замеряет время, которое ушло на вычисление NOW(), на подстановку параметров, на сам инсерт, на нужное_вписать, и все это один раз, но в десять потоков. Это - не бенчмарк, строго говоря. Это ты "что-то померял", в лучшем случае. |
Сообщ.
#297
,
|
|
|
Цитата Астарот @ Это ты "что-то померял", в лучшем случае. Можно было бы конечно запустить N-раз программно. Но я руками запускал 5-7 раз. Результаты не сильно отличались. Мне было важно оценить разницу в скоростях записи логов по первому и второму варианту. Разница сохранялась примерно одинаковой. |
Сообщ.
#298
,
|
|
|
Ну, я и говорю - что-то померял Хотя по уму, если уж мерить скорость вставки, то замер должен происходить на стороне БД, что бы ты видел сколько времени трарит твоя БД на вставку, а не искажал результат сетью, скриптами, и так далее. Ну, и запускать нужно хотя бы пару сотен раз, а не ручками разок-другой
|
Сообщ.
#299
,
|
|
|
Ээээ... А тут точно про C++ vs C?
|
Сообщ.
#300
,
|
|
|
Цитата Qraizer @ У меня ошибка не может возникнуть там, где находится моя сфера ответственности, поэтому обрабатывать я её просто не обязан На уровне работы конкретного кода "освобождения", который вызывает некую функцию, способную "ошибиться", у тебя в случае деструктора нет возможности даже сообщить о том, что "вне сфере твоей ответственности" произошел какой-то сбой. Ты считаешь, что можно замолчать проблему. Я думаю, что это не во всех случаях правильно. Логирование же в деструкторах будет не полным, поскольку у тебя нет никакой информации о контексте, в котором происходит завершение. Это не говоря уже о том, что ты потащишь систему логирования в деструктор каждого объекта, который "освобождает" ресурсы. Добавлено Цитата Qraizer @ но даже тут это куда лучше решается методами не моего приложения, а в высококритичных системах вообще обязано мониториться на системном уровне. Когда ты пишешь нечто того же nginx, у тебя нет никакого представления о том, кто, как и где тебя будет запускать Выдвигать слишком сильные требования к окружению в данном случае бессмысленно. Добавлено Цитата Qraizer @ Ты пойми, что закрытие файла не связано с передачей данных. Это не write(), который передаёт данные вовне и потому ожидаемо может столкнуться с невыполнением собственно своего собственного контракта. Вообще-то с точки зрения возможности зафейлиться это почти равноправные функции. По крайней мере в некоторых случаях. И да, если у тебя есть некоторый протокол обмена, например, то "закрытие" может подразумевать и обмен данными с внешней средой. Добавлено Цитата Qraizer @ Любые проблемы в этой точке являются проблемами окружения, и меня волновать не должны. Они тебя должны волновать с точки зрения информации. Хотя бы залогировать это дело тебе во многих случаях нужно. |