Вышел CrystaX NDK 10.2.0

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

Извини, дядя, но на это довелось говорить не только тебе в твоём бложике, но и Страуструпу. (Но ты, видимо, не в курсе, т.к. читаешь только свой блог.)

So, if you feel the urge to add a final specifier, please double check that the reason is logical: Would semantic errors be likely if someone defined a class that overwrote that virtual function? Adding final closes the possibility of a future user of the class might provide a better implementation of the function for some class you haven't thought of.

пруф И кто из вменяемых программистов будет закрывать возможность определять деструктор абстрактного класса? :-)

В общем, вы в очередной раз пытаетесь представить себя знатоком C++ и у вас это не получается.

Батхерт засчитан раз :-)

Это вам кажется. В силу незнания C++ и неумения им пользоваться.

Батхерт засчитан два :-)

Такая макаронная фабрика этот ваш механизм conditions в Common Lisp, что даже цензурных эпитетов не подберешь.

Слив засчитан раз :-)

Ок, Торвальс не считает возможным использовать C++ и C++ные исключения в ядре Linux-а. Но я, например, не зарабатываю на жизнь разработкой для ядра Linux-а. А вы?

И я :-)

Итого, 2 батхерта и 1 слив :-)

И ругать инструмент за его недостатки - как минимум глупо. Надо просто уметь им пользоваться. Или переходить на другой инструмент.

Ну я умею им пользоваться, но с удовольствием перешёл на лисп, чего и всем желаю :-)

А в контексте CrystaX NDK - мне очень не нравится, что Google решает за меня, чем и как мне, как программисту, пользоваться. Я хочу решать это сам.

Прекрасные слова. Это одна из причин, по которой я не использую технологии вроде Java и C#.

Удачи! :-)

Весь этот бла-бла-бла оставьте для легковерных первокурсников.

Оу, батхерт засчитан три :-)

Ну и продолжайте в том же духе. Только вот умные люди, стоящие за разработкой C++ придумали деструкторы. Умные люди, стоящие за разработкой C# придумали using, умные люди утащили его в Java под видом try-with-resources. Умные люди придумали в D конструкцию scope(). Умные люди сделали в Go конструкцию defer... Мне кажется, что далеко не всем нравится управлять ресурсами вручную.

PS. И поэтому умные люди придумали сборщик мусора, который впервые появился несколько десятилетий тому назад в Лиспе :-)

So, if you feel the urge to add a final specifier, please double check that the reason is logical: Would semantic errors be likely if someone defined a class that overwrote that virtual function? Adding final closes the possibility of a future user of the class might provide a better implementation of the function for some class you haven't thought of.

Какое отношение эта цитата имеет к тому, что у абстрактного класса деструктор всегда должен быть виртуальным?

Итого, 2 батхерта и 1 слив :-)

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

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

Сборщик мусора не имеет отношения к управлению ресурсами в общем случае. Ну и если бы в вашей голове было меньше Lisp-ового говна, вы бы разузнали, для каких целей существуют using в C#, scope() в D и defer в Go.

Оу, батхерт засчитан три

Внимательный вы наш, в разговоре с вами я пытаюсь выяснить всего лишь одну простую вещь: почему вы считаете RAII в C++ плохим механизмом для освобождения ресурсов. Но вы, вместо того, чтобы говорить что-либо конкретное (хотя бы привести пример кода на любимом вами Lisp-е), все время пускаетесь в какую-то пространную демагогию про то, какой C++ говно вообще, какие говеные на нем библиотеки, насколько много укушенных Александреску и насколько мало вменяемых программистов.

Может быть с вами кто-то хочет посдискутировать по этим вопросам в данной теме. Но это не я. Поэтом не нужно в ответах мне заводить такую пластинку.

Можете сказать что-то конкретное про ущербность деструкторов и исключений — говорите. Не можете, держите свои потоки сознания в своей голове.

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

А я больше на цепепе не пишу :-) Я на Лиспе пишу. :-) От того и столько смайликов :-)

Сборщик мусора не имеет отношения к управлению ресурсами в общем случае.

Ну в общем случае (это когда исключения используются) и деструкторы цепепе не имеют отношения к управлению ресурсами, т.к. исключение не должно покидать деструктор. :-) Подумаешь :-)

Ну и если бы в вашей голове было меньше Lisp-ового говна, вы бы разузнали, для каких целей существуют using в C#, scope() в D и defer в Go.

Дядя, Лисп был пионером многих-многих парадигм, техник и технологий, которые до сих в зоопарке недоязычков нереализованы. Там для управления ресурсами есть вещи вроде unwind-protect и общирные техники на базе идиомы макр with-. Я когда знакомился с Лиспом, то понял, откуда в цепепе заимствовано множество идей, в т.ч. и пресловутый RAII. Только в Лиспе это сделано красиво и со вкусом, не то, что в цепепе. Ты просто не в теме :-)

Внимательный вы наш, в разговоре с вами я пытаюсь выяснить всего лишь одну простую вещь: почему вы считаете RAII в C++ плохим механизмом для освобождения ресурсов.

А ты - невнимательный. :-) Я не считаю RAII плохим механизмом. Я считаю C++ плохим языком. :-) Ну я так считаю, и не я один. :-)

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

Да, я согласен! :-)

Может быть с вами кто-то хочет посдискутировать по этим вопросам в данной теме. Но это не я. Поэтом не нужно в ответах мне заводить такую пластинку.

Тебя никто не заставляет сидеть здесь и читать. Впрягся в дискуссию - будь готов отвечать :-)

Можете сказать что-то конкретное про ущербность деструкторов и исключений — говорите. Не можете, держите свои потоки сознания в своей голове.

Женя, смотри на вещи проще :-)

и деструкторы цепепе не имеют отношения к управлению ресурсами, т.к. исключение не должно покидать деструктор

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

Там для управления ресурсами есть вещи вроде unwind-protect и общирные техники на базе идиомы макр with-.

Можно порадоваться за Lisp и за сделанные вами в нем открытия. Но приведенные примеры из «недоязычков» показывают, что освобождать ресурсы вручную многим не нравится. Вы же сами упоминаете соответствующие инструменты из Lisp-а, но при этом ратуете за то, чтобы деструкторами в C++ не пользовались, а делали управление ресурсами вручную через вызовы функций.

Запутались в скобочках?

Впрягся в дискуссию - будь готов отвечать

Ну так ответьте внятно хотя бы на один вопрос.

Высеров про то, какое C++ говно и без вас хватает.

Вы дебил или прикалываетесь? То, что исключение не должно покидать деструктор никак не противоречит освобождению ресурсов.

Разве ты ещё не понял? :-) Противоречит, потому что с т.з. нормальных разработчиков и реальных требований к надёжности, программа должна вести себя предсказуемо. Поэтому ни о каком подавлении исключения деструкторе речь идти не может - только прямой вызов ф-ии освобождени ресурса и обработка ошибки в зависимости от контекста.

Напротив, подавленная ошибка при освобождении одного какого-то ресурса позволяет перейти к освобождению оставшихся.

В этом месте свой первый вопрос адресуй себе :)

Ну так ответьте внятно хотя бы на один вопрос.

Я уже ответил. Вменяемый люди уже прочли и согласились :-) А тебя всё бомбит и бомбит :-)

Высеров про то, какое C++ говно и без вас хватает.

Конечно, не только я говорю, что это говно. Почитай Coders At Work. Там дают интервью много именитых разработчиков, которые далеко не в восторге от Си++. :-)

Конечно, не только я говорю, что это говно. Почитай Coders At Work. Там дают интервью много именитых разработчиков, которые далеко не в восторге от Си++. :-)

От Lisp-а, справедливости ради, тоже далеко не все в восторге. И от C. И от Java. Так что прекращайте троллить.

Разве ты ещё не понял?

Разве вы что-нибудь объяснили?

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

ХЗ каких нормальных разработчиков вы подразумеваете. Так же ХЗ как очистка ресурсов в деструкторах противоречит предсказуемости.

Это уж скорее рестарты в Common Lisp-е делают поведение программы непредсказуемой.

Поэтому ни о каком подавлении исключения деструкторе речь идти не может - только прямой вызов ф-ии освобождени ресурса и обработка ошибки в зависимости от контекста.

Да почему???

Конечно, не только я говорю, что это говно. Почитай Coders At Work.

Т.е. вы хотите таким образом поставить себя в один ряд с этими самыми Coders-ами?

От Lisp-а, справедливости ради, тоже далеко не все в восторге. И от C. И от Java. Так что прекращайте троллить.

Верно, не спорю. Ладно, Дмитрий, это твой тред про твой NDK. Поэтому ты здесь и арбитр. Надо здесь сворачиваться. Если у меня будет время и желание - продолжу в другой раз и в другом треде :-)

Всем спасибо. Кого задел или обидел - прошу простить. Ведь я всего лишь развлекаюсь, пользуясь интерфейсом, который мне предоставляет LOR :-) До скорых встреч! :-)

А я больше на цепепе не пишу :-) Я на Лиспе пишу. :-) От того и столько смайликов :-)

А мне кажется, причина смайликов примерно такая.

На каждом шагу. Видимо, вы просто этого не замечаете.

Гордая принцесса на горошине не желает общаться на эту тему. Вам не кажется, что ваше заявление в этом ключе несколько необоснованно?