Деструкторы не нужны (?)

Ну а если потребовалось воспользоваться C++, то можно сколько угодно исходить на говно на LOR-е, но C++ от этого не изменится.

Ну зачем же так. Бывает в таких обсуждениях и что-то интересное. Опять же, влиять на развитие С++ можно, пусть и не на лоре.

объединять исключения в цепочки

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

А так я могу написать On Error Resume Next перед вызовом библиотечного кода

Ок, этот нюанс я упустил.

какие-то непонятные жабопроблемы. у нормальных программистов все работает без всякого сборщика мусора. а те кому он нужен почему-то вайнят на С++ вместо того, чтоб не пользоваться им.

Если бы евангелисты Си++ не расписывали его как истинно ООП язык, идеально подходящий для решения любой прикладной задачи, вопросов бы не было совсем.

Вы, часом, с Java не перепутали?

Про C++ _никогда_ не говорили, что это «истинно ООП» язык. В отличии от SmallTalk, Eiffel, Java и т.п.

Это и плохо.

Плохо, но идеального и универсального решения я не вижу. С «писать сообщение и приостанавливать работу» свои проблемы. Хотябы в том, что никак не заставить человека обрабатывать эти ситуации. В расте, который мне весьма симпатичен, полностью от паник тоже не смогли уйти. Как раз потому, что если проблему в 99% случаев обрабатывать не надо, то если этого всё-таки требовать, то пользоваться языком будет очень неудобно.

P.S. Написал на почту.

Вы, часом, с Java не перепутали?

Когда пиарили C++ и ООП, Java ещё и в проекте не было. Java как раз рекламировалась как «безопасный Си++». Мол, выкинули все опасные конструкции и добавили сборщик мусора.

В отличии от SmallTalk, Eiffel

Не помню их рекламы. И в школе/институте чтобы их преподавали тоже не помню. Поэтому ООП в Си++ рекламировалось на фоне Си (устаревший) и Паскаля (пригоден только для обучения). А если студента пять лет учат, что ООП — это где у объекта можно вызвать метод, то ООП Smalltalk'а с сообщениями воспринимается как исторический курьёз.

«Современными языками объектно-ориентированного программирования являются С++ и Java.» (с) http://bourabai.kz/alg/classification02.htm,

Хотябы в том, что никак не заставить человека обрабатывать эти ситуации.

Почему? Даже в MS DOS было «Abort, Retry, Ignore». Поэтому если потенциально есть возможность "... Retry, Ignore", то зачем сразу программе аборт делать?

Написал на почту.

В почте нету. Точно адрес верный? Kalimehtar@mail.ru

Затем по этому списку можно повторно периодически пытаться выполнить удаление ссылок на элемент.

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

Когда пиарили C++ и ООП, Java ещё и в проекте не было.

Это когда, интересно? Когда Java не было, всерьез ООП можно было использовать только в C++, SmallTalk и Eiffel. Уж не помню, когда Object Pascal и Objective-С реально вышли в массы.

Не помню их рекламы.

Ну значит этого не было!

Вообще-то я говорил не про рекламу, а про то, что C++ никогда не декларировался как чисто ООП язык. В отличии от SmallTalk и Eiffel, которые таковыми как раз и являются.

http://bourabai.kz/alg/classification02.htm,

Это что за источник такой?

Это лучше, чем аварийно всё завершать.

А попробовать что-то сделать с этим «зависшим окном» можно?

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

Так деструктор ведь обязан вернуть управление. А после этого объекта уже нет.

Вот пример: класс — временный файл. Конструктор создаёт временный файл и открывает его на чтение/запись. Деструктор/финализатор должен удалить этот файл.

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

Даже в MS DOS было «Abort, Retry, Ignore».

Да и не только в MS DOS. В винде такое тоже бывало (а может и сейчас есть). Вот только сколько помню «Retry» не помогало. Да и зачем пользователя грузить непонятной фигней? Если проблема не критичная и игнорировать можно, то пусть это тихо делается. С записью в лог, при желании. А если игнор все данные может испортить, то наоборот вреден. В общем, это только иллюзия выбора и перекладывания проблем с разработчика на пользователя.

Но я немного о другом говорил. «Даже» сейчас исключения нередко «обрабатывают» просто проглатывая и игнорируя. Осмысленно обработать не просто одно исключение, а сразу кучу, причём с разных логических уровней, сложно. В 90% (если не больше) программ всё равно будет, в лучшем случае (насчёт «лучшести» тоже можно спорить), «не удалось закрыть файлы А, Б, Ц», а более вероятно просто «не удалось закрыть (некоторые) файлы». А уж если речь идёт о чём-то более серьёзном, чем закрытие файлов, то всё становится ещё веселее.

Ты ж сам говоришь: если хочется какой-то сложной логики, то её написать можно и сейчас. Если нет, то все эти навороты будут просто мёртвым грузом. И да, найдутся недовольные расходами. (:

Точно адрес верный?

Вроде, да. На всякий случай, написал с другого ящика, но тоже gmail. Может попало в спам?..

А программа запущена под оффтопиком и этот временный файл прямо сейчас удалить нельзя — его антивирус проверяет. На С++ придётся падать.

И почему же «придется»? Как и в примере с VB и Racket, почему бы не оставить мусор, но продолжить работать? Программы на Си++ обязательно должны падать?

С финализатором алгоритм я описал. С деструктором я не понял, что ты предлагаешь.

Да хоть точно такую же логику. Завести на старте программы поток и список «проблемных файлов». В какие-то моменты проверять его и пытаться повторно закрыть.

Это когда, интересно?

Примерно 1990-1991. Turbo Pascal с объектами тогда уже был. Но C++ был гораздо круче.

Objective C на Макинтошах в те же годы был вообще чуть ли не единственным языком.

Когда Java не было, всерьез ООП можно было использовать только в C++, SmallTalk и Eiffel.

Ну покажи мне хоть один курс по ООП на базе SmallTalk и Eiffel или хоть одну крупную программу на них написанную. Про языки эти мнение было примерно как про Лисп или Пролог. Даже хуже. Лисп и Пролог хоть в вузах преподавали.

Завести на старте программы поток и список «проблемных файлов».

А как из деструктора отменить удаление? this в список положить-то можно, но ведь он сразу же станет невалидным.

Программы на Си++ обязательно должны падать?

По новому стандарту — да. Деструкторы теперь считаются noexcept: Деструкторы не нужны (?) (комментарий)

Вот только сколько помню «Retry» не помогало.

Под Windows на «Insufficient disk space» и даже на «Insufficient memory» очень даже помогало. Позакрывал всё остальное, поудалял лишние файлы, почистил корзину, нажал Retry и драгоценная дипломная работа всё-таки сохранилась на диск. :-)

А был бы тогда C++11 и было бы всё печальней.

«Даже» сейчас исключения нередко «обрабатывают» просто проглатывая и игнорируя.

Согласен. Но возможность проглотить должна быть! А её отбирают!!!

Если нет, то все эти навороты будут просто мёртвым грузом. И да, найдутся недовольные расходами.

С этим согласен.

что C++ никогда не декларировался как чисто ООП язык

ОК. Говорили не чисто ООП язык, а лучший ООП язык.

Это что за источник такой?

Казахстанский университет, курс по языкам программирования.

Ну покажи мне хоть один курс по ООП на базе SmallTalk и Eiffel

Полагаю, в ВУЗах бывшего СССР? :)

или хоть одну крупную программу на них написанную.

Полагаю, про такой продукт, как Visual Age for SmallTalk от IBM вы никогда не слышали? SmallTalk, как и Eiffel, раньше использовались для разработки больших, но отнюдь не публичных проектов. Что и позволяло продавать те же Visual Age и EiffelStudio за очень немаленькие деньги.

Программы на Си++ обязательно должны падать?

По новому стандарту — да

Несите нового плюсохейтера, этот порвался.

ОК. Говорили не чисто ООП язык, а лучший ООП язык.

Страуструп говорил, что C++ - язык, который лучше, чем C и поддерживает ООП :-)

ОК. Говорили не чисто ООП язык, а лучший ООП язык.
Казахстанский университет, курс по языкам программирования.

Очевидно, у нас с вами сильно разные евангелисты C++.

В Qt есть «точно такие же» смарт поинтеры: всякие там QScopedPointer и QSharedPointer.

Эти всякие там не обнаружены в QWidget::~QWidget() :-) Не очень то нужны, видимо :-)

Опять же, влиять на развитие С++ можно, пусть и не на лоре.

Сильно не верю в то, что кто-то из читателей LOR-а и уж тем более участников подобных споров возьмут и сделают что-то для C++. Или родят язык вроде Rust-а, который бы пытался стать альтернативой C++ для ниши C++.

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

-- А почему вы используете C++, ведь на C было бы проще и быстрее?
-- Задача слишком большая и сложная. На C будет долго и дорого, да и ошибок в C-шном коде окажется больше, т.к. язык низкоуровневый...
-- Но ведь на C++ ошибок будет еще больше?!
-- Нет, в C++ есть средства для уменьшения их числа: шаблоны, деструкторы, более жесткий контроль типов, ссылки...
-- Да что вы мне рассказываете: шаблоны — это всего лишь что-то типа макросов, деструкторы не годятся для написания надежного кода, а ООП и виртуальные методы ведут к тормозному коду. Так почему же вы собираетесь использовать С++ вместо C?

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

Полагаю, в ВУЗах бывшего СССР? :)

Можешь любой русскоязычный. Мы же на linux.org.ru

Программы на Си++ обязательно должны падать?

По новому стандарту — да

Несите нового плюсохейтера, этот порвался.

Так вот же пруф:

$ g++ test.cpp
$ ./a.out
ok
$ g++ -std=c++11 test.cpp
$ ./a.out
terminate called after throwing an instance of 'int'
Аварийный останов

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

Думаешь, Линус Торвальдс начитался баек и страшилок? Его мнение: http://harmful.cat-v.org/software/c /linus

C++ is a horrible language. It's made more horrible by the fact that a lot 
of substandard programmers use it, to the point where it's much much 
easier to generate total and utter crap with it. Quite frankly, even if 
the choice of C were to do *nothing* but keep the C++ programmers out, 
that in itself would be a huge reason to use C.

Можешь любой русскоязычный. Мы же на linux.org.ru

Вы в своем уме? Русскоязычные курсы по языкам, чей золотой век пришелся на конец 80-х и начало 90-х?

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

Да сколько же можно?!

Во-первых, когда это было сказано?

Во-вторых, Торвальдс занимается очень специфической темой, в которой C++ в неурезанном виде вряд ли применим.

В-третьих, ресурсами, которыми располагает Торвальдс, вряд ли располагает какой-нибудь коммерческий проект.

В-четвертых, Торвальдс, в отличии от разработчиков коммерческих проектов, вряд ли связан такими вещами, как дедлайны и бюджеты.

измерять восстребованость языков программирования в те времена по тому, что преподавали в бывших советских ВУЗ-ах

Я и востребованность измеряю в бывшем Советском Союзе. И живу в нём.

Ладно, этот вопрос за отсутствием точек соприкосновения предлагаю закрыть. А то, боюсь, нацпол начнётся.

плюсоЦарь в треде, все в машину!

Я и востребованность измеряю в бывшем Советском Союзе.

Здесь никакой политики, сугубая объективность: программирование в СССР до его распада развивалось своим уникальным путем и технологии с Запада проникали к нам с трудом. Потом, в 90х, была серьезная просадка из-за тогдашней экономической ситуации. Ну а затем, за счет дешевой рабочей силы, на просторах бывшего СССР пышным цветом расцвел аутсорс и это накладывало свой отпечаток.

В наших палестинах и сейчас аутсорс — это чуть не 99% рынка.

Так вот же пруф:

Фанатики пруфы игнорят, если что :-)

Так вот же пруф:

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

Во-первых, когда это было сказано?

В 2007 году. С тех пор C++ перестал привлекать «substandard programmers» и поощрять использование абстракций, приводящих к неэффективному коду?

Во-вторых, Торвальдс занимается очень специфической темой, в которой C++ в неурезанном виде вряд ли применим.

На C++ нельзя написать систему контроля версий? В чём её специфика?

В-третьих, ресурсами, которыми располагает Торвальдс, вряд ли располагает какой-нибудь коммерческий проект.

Гм... А он наоборот считает, что именно ввиду ограниченности ресурсов надо писать на Си. Иначе на борьбу с ошибками слишком много ресурсов придётся потратить.

В-четвертых, Торвальдс, в отличии от разработчиков коммерческих проектов, вряд ли связан такими вещами, как дедлайны и бюджеты.

Это да. Но в этом случае вообще Java/С# лучше. Потому что на Си работа медленнее, качество лучше, уровень программистов примерно одинаковый за счёт фильтра трудоёмкости. На Си++ много поверивших в то, что шаблоны и деструкторы защищают от ошибок. В результате сроки и стоимость проектов на Си++ в зависимости от квалификации программистов отличаются в 15 раз. Планировать почти невозможно. На Java/C# большую часть ошибок Си++ сделать нельзя, поэтому скорость выполнения низкоквалифицированными программистами резко возрастает, хотя качество результата предсказуемо падает.

пруфом чего это является

Того, что по старому стандарту программа не должна падать, а по новому должна.

Во-первых, когда это было сказано?

А что поменялось? :-) Ах да, лямбды же добавили и auto с variadic templates :-) Теперь то, наверное, Торвальдс считает C++ хорошим языком :-)

В-третьих, ресурсами, которыми располагает Торвальдс, вряд ли располагает какой-нибудь коммерческий проект.

Ты правда считаешь, что проекты на C++ дешевле проектов на C? :-) Благодаря деструкторам, наверное :-) Нет, из-за STL, видимо :-)

В-четвертых, Торвальдс, в отличии от разработчиков коммерческих проектов, вряд ли связан такими вещами, как дедлайны и бюджеты.

Да, только вот сплошь и рядом пользуются его Git, написанной на C :-) Кто-то его тогда спросил про C++ в Git, на что получил такой вот милый ответ — «horrible language» :-)

на просторах бывшего СССР пышным цветом расцвел аутсорс

Когда аутсорс появился, всё равно не видел на job.ru вакансий на Eiffel и Smalltalk. Впрочем, «по языкам, чей золотой век пришелся на конец 80-х и начало 90-х...». Может они уже померли к тому моменту.

С тех пор C++ перестал привлекать «substandard programmers» и поощрять использование абстракций, приводящих к неэффективному коду?

Интерес к C++ стал падать, на моей памяти, где-то с 2000-го. После 2004-го пошел просто массовый отток. Сейчас, как мне представляется, средний уровень C++разработчиков даже выше, чем был в 2007-м.

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

На C++ нельзя написать систему контроля версий? В чём её специфика?

Так ведь и Git не был написан целиком на C. Как так? Торвальдс противоречит самому себе?

Применительно к околосистемному софту до сих пор существует такой фактор, как переносимость. Компиляторы C есть везде. Компиляторы C++, особенно приличного качества, где-то могут и отсутствовать. Так что для вещей вроде git или svn использование C могло иметь смысл исходя из этих соображений.

Гм... А он наоборот считает, что именно ввиду ограниченности ресурсов надо писать на Си. Иначе на борьбу с ошибками слишком много ресурсов придётся потратить.

Ну можете поверить Торвальдсу, который занимается OpenSource. А можете посмотреть на компании, которые делают ставку на C++ в разработке важного для их деятельности софта.

На Си++ много поверивших в то, что шаблоны и деструкторы защищают от ошибок. В результате сроки и стоимость проектов на Си++ в зависимости от квалификации программистов отличаются в 15 раз.

Откуда дровишки?

Интерес к C++ стал падать, на моей памяти, где-то с 2000-го. После 2004-го пошел просто массовый отток.

Закономерным итогом должна получится маргинальщина с кучей легаси :-)

когда есть cstdio и своя обёртка типа file_wrapper под конкретные нужды - ничего не имею против.

когда тихая, однотипная «очистка» ресурсов идёт, например, с плюсовым драйвером для базы данных от производителя - тут буду недоумевать. как в анекдоте про советского изобретателя автомата для стрижке получается - "- а как она разных людей стрижёт? головы-то разные; - а это только до первой стрижки". и, кстати, не могу однозначно сказать, что в деструкторе должно быть тут - rollback или commit. но это не так важно.

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

и, кстати, не могу однозначно сказать, что в деструкторе должно быть тут - rollback или commit.

По вашим словам и, главное, по вашему коду, это сильно заметно.

файл должен закрываться, если он не закрывается, то что-то не так с вашей ОС или использованием API.

никогда место на диске не заканчивалось неожиданно? fclose() сливает буфер на диск, в том числе.

драверов базы данных не писал. а хамить не надо.

В результате сроки и стоимость проектов на Си++ в зависимости от квалификации программистов отличаются в 15 раз.

Откуда дровишки?

В объяснениях какой-то конторы, почему она перевела свои проекты с C++ на Java. Мол, сроки теперь выдерживать гораздо проще, так как производительность программистов стала более-менее одинаковой. Было это 10 лет назад, поэтому подробностей не помню.

никогда место на диске не заканчивалось неожиданно? fclose() сливает буфер на диск, в том числе.

И что дальше? fclose() закрывает файл в любом случае.