Вышел CrystaX NDK 10.2.0

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

Скажи, а тебе обязательно, что бы это обеспечивалось конструкциями языка? Например, в Qt есть moc, который генерирует необходимую информацию и позволяет проверять наличие класса, смотреть какие у него есть сигналы/слоты, проперти, наконец конструировать объект по имени класса. Это не подходит?

Потому что взяв эту технологию можно сделать такую рефлексию о которой ява будет мечтать. :)

костыль остается костылем, как ты его не назови.

кстати, если moc это может — почему в Qt это не используется? (всмысле, для реализации BC)

зы: я знаю ответ, но тебе будет полезно попытаться на него ответить, можно даже не в тред, а просто прокрутить в голове

Нет, это, как минимум, проблема многих языков. И я ещё раз повторюсь - «классы типа Transaction» вполне себе могут существовать.

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

И я ещё раз повторюсь - «классы типа Transaction» вполне себе могут существовать. Иногда проблему можно проигнорировать. Скажем, не удалась запись в лог - плохо, но не смертельно.

Хоть 10 раз ещё повтори. Таких классов наплодили сплошь и рядом, однако это лишь подталкивает к отказу от Си++, т.к. я не понимаю вот этого чудесного подхода аля «русское авось» - «проблему можно проигнорировать. Скажем, не удалась запись в лог - плохо, но не смертельно.» Нравится теория вероятностей? Ну программируй в таком стиле :-) Только лучше бы твоими поделиями никогда не пришлось пользоваться мне. :-)

Скажи, а тебе обязательно

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

Хм, думал узнать что-то новое (ага, на Лоре :))) ), прочитав весь этот «интеллигентный» (ха ха) срач все таки склоняюсь к мысли что «кресты - говно».

P.S. Обороты тоже доставляют. В стиле «Один англичанин толкнул англичанина...». Нет бы сразу нахуй послать.

Лол, сказал поборник лиспа с его макросами.

Ты не в теме. Точно так же, как ты однажды облажался, заявив про отсутствие ф-ии /= в лиспе — пруф

Опять враньё.

Опять слажался. Цитата с их оф. сайта «Qt itself will not throw exceptions. Instead, error codes are used.» Вот пруф

PS. Вы меня утомили. Всем всех благ и хороших выходных :-) Я поехал на природу :-)

Нет бы сразу нахуй послать.

Вы так и делайте, не стесняйтесь. Это будет прекрасным дополнительным штрихом к вашему столь любовно и трудолюбиво создаваемому здесь образу.

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

Так же как и C#, java и objc. Когда ты чего-то не можешь, то инструмент мало чем сможет тебе помочь, вместе с рефлексией. :)

Ой, ты тут интеллигента не изображай. Если почитаешь свои ответы тому же walker-у сам поймешь. Да тут и понимать нечего, потому ты с этим комментом и вылез. Ответ анонимосу, нормально, че? Потому что правда глаза колет. И ты это понял. Образ я создаю? (кстати то был первый мой коммент в этой теме) Нет, дорогой, это ты создаешь его себе. Продолжай в том же духе, мне что с того?

P.S. Как ты тут любишь говорить, «нормальный человек давно бы признал свою неправоту». Промолчал бы, и принял к сведению. Или даже спасибо сказал.

P.P.S. Забавно, что интеллектуальная мощь не всегда приводит к уму.

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

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

Во вторых, я не фанат плюсов, просто это мой основной рабочий инструмент, ну и неудивительно, что я язык знаю. Причём получше тебя, судя по бреду, например, про специализацию шаблонов/перегрузку. И «защищаю» я только если реально пишут фигню.

В третьих, я с удовольствием смотрю на другие языки. Просто мне действительно нужна низкоуровневость плюсов. Опять же, динамические языки «не люблю», поэтому «чудодейственный» лисп мне, в любом случае, не особо подходит. Хотя, в своё время, и прочитал practical common lisp. Язык интересный, но мне не подходит. Да и ракет мне понравился больше. Опять же, на ним смотрел - не понравился, раст изучаю и на него большие надежды. Так что если кто-то и зацикливается на одном языке, то это ты.

т.к. я не понимаю вот этого чудесного подхода аля «русское авось» - «проблему можно проигнорировать.

Не понимаешь ты то, что тебе пишут. Повторюсь ещё раз, для особо собразительных: язык и «такие классы» дают возможность обработать ошибку. То, что ты упираешься как баран в деструкторы с исключениями этого не меняет.

Ты не в теме. Точно так же, как ты однажды облажался, заявив про отсутствие ф-ии /= в лиспе — пруф

Лол и не лень тебе было искать этот «пруф»? Я вообще-то поинтересовался всего-лишь. Более того, выяснилось, что /= не полноценная замена != так как работает только с числами.

Ну и по существу тебе, как обычно, нечего сказать.

Опять слажался.

Нет, ты. Внезапно, есть QException.

Ой, ты тут интеллигента не изображай. Если почитаешь свои ответы тому же walker-у сам поймешь. Да тут и понимать нечего, потому ты с этим комментом и вылез. Ответ анонимосу, нормально, че? Потому что правда глаза колет. И ты это понял. Образ я создаю? (кстати то был первый мой коммент в этой теме) Нет, дорогой, это ты создаешь его себе. Продолжай в том же духе, мне что с того?

P.S. Как ты тут любишь говорить, «нормальный человек давно бы признал свою неправоту». Промолчал бы, и принял к сведению. Или даже спасибо сказал.

P.P.S. Забавно, что интеллектуальная мощь не всегда приводит к уму.

Здесь прекрасно все, до последней буквы. Ни единого слова изъять или переставить нельзя - тут же нарушится внутренняя гармония. Это, вне всяких сомнений, признак шедевра. Я в восхищении.

Так же как и C#, java и objc. Когда ты чего-то не можешь, то инструмент мало чем сможет тебе помочь, вместе с рефлексией. :)

ессно. рад взаимопониманию.

Тут ты не прав практически во всём.

Да кто бы сомневался, что в глазах фоната цепепе, тот, кто усмехается над этим костыльным недоразумением, будет не прав практически во всём :-)

Во первых, это ты, а не я, бегаешь везде и орёшь какой С++ ужасный.

Ну да, я считаю цепепе говном и ору об этом везде, где считаю нужным :-)

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

Опять ты на мейнстримовые языки ссылаешься :-) Понял, что твой цепепе мокнули в дерьмо, теперь всячески пытаешься сгладить ситуацию. Но фэйл, фэйл, так как цепепе - это плохо спроектированный, уродливый, мерзкий язычок. И об этом не только я говорю, но и много других кое-что смыслящих в IT людей, тот же бородатый олдфаг Столман — «C++ is a badly designed and ugly language. It would be a shame to use it in Emacs.» пруф

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

Жаль тебя, правда :-)

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

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

Это досадный недостаток цепепе, который является краеугольным камнем в его плохом дизайне

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

Нет, ты. Внезапно, есть QException.

Ты даже английского не знаешь, упоротый фонатик, раз тебя даже документация Qt не может вразумить. Сказано ведь по-английски «Qt itself will not throw exceptions. Instead, error codes are used.» В ответ ты приводишь QException, который «base class for exceptions that can transferred across threads». Ты даже не понял из той ссылки, что я тебе дал, что разработчики Qt ведут работу (которая «Exception safety is not feature complete!») над тем, чтобы Qt предоставляла гарантии безопасности исключений, и QException является классом, который вписывается в эту их новую инфраструктуру безопасности исключений. Специально для незнающих английский и Qt знатоков цепепе: библиотека Qt не генерирует исключений, но её разработчиками ведутся разработки, чтобы она была безопасна в плане исключений.

Ты даже английского не знаешь, упоротый фонатик

Ну ты и тупой.

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

Женя, я просто хотел сказать, что деструкторы - это не панацея, и сама их концепция неявного вызова в ходе delete или при выходе из обл. видимости не всегда является преимуществом перед язывными вызовами в стиле Си. :-) Т.е. деструкторы предназначены лишь для частных случаев, в основном, для очистки данных объектов.

Не горюй, дядь Дима! Да мало ли таких анонимусов?

что деструкторы - это не панацея, и сама их концепция неявного вызова в ходе delete или при выходе из обл. видимости не всегда является преимуществом перед язывными вызовами в стиле Си.

Это крайне странное утверждение. Добавление классов (а значит и механизмов для корректного конструирования и разрушения экземпляров) не отменило явных вызовов в стиле Си. Кто хочет использовать plain old C style, тот использует.

Но при этом программирование на C++ в стиле plain old C имеет две проблемы:

1. Легко забыть очистить какие-то ресурсы при досрочном выходе из области видимости. Деструкторы дают способ преодолеть эту проблему. Конечно, не бесплатно. Но лучше иметь этот способ, чем программировать в стиле goto err и потом ловить баги из-за элементарной забывчивости.

2. Ситуация, когда после обнаружении ошибки X отменяется какое-то предыдущее действие и диагностируется ошибка Y легко возникает и при использовании plain old C. В итоге у нас есть два кода ошибки X и Y, но наверх нужно возвращать только один. Это фундаментальная проблема и «проглатывание» исключений в деструкторах является всего лишь одним из ее решений, адаптированных под сам факт того, что C++ поддерживает исключения.

Кроме того, язык C++ поддерживает исключения. После включения STL в стандарт языка уже можно говорить, что исключения используются повсеместно.

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

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

db_connection * db = new db_connection(
    driver_type("OCCI") | driver_type("ODBC") );
if( OK != db->connect( "guest", "" ) )
  goto err_destroy_db;
if( OK != db->begin_transaction( get_isolation_level( "SNAPSHOT" ) ) )
  goto err_disconnect;
...
err_disconnect:
  db->disconnect();
err_destroy_db:
  delete db;

По факту, за «тривиальным» кодом может скрываться много мест, откуда исключения могут вылететь. И таких мест станет еще больше при сопровождении кода. Так что проще положиться на работу деструкторов, чем доверять ручной работе с кодами возврата.

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

Вы так и не ответили, что именно вам нужно от буста.

где восприняли новость о включении Boost в состав NDK с радостью.

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

Так где вы узрели грубость в отношении вас?

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

Вот я и спрашиваю, где?

Это, кстати, очень далеко от истины:

Это и есть большая часть буста?
Вон BRE даже ответить не может, что именно он использует из буста.

Нет бы сразу нах*** послать

За это всем, кроме великого анонимуса, шкворец режут. Мало кто готов платить за удовольствие выражать свои эмоции прямо и без обиняков :)

Это крайне странное утверждение. Добавление классов (а значит и механизмов для корректного конструирования и разрушения экземпляров) не отменило явных вызовов в стиле Си. Кто хочет использовать plain old C style, тот использует.

Это крайне странное утверждение. Странность в том, что я говорю про ограниченность деструкторов, а мне в ответ говорят что «добавление классов не отменило явных вызовов в стиле Си». Женя, все знают, что в цепепе можно явно вызывать функции :-)

1. Легко забыть очистить какие-то ресурсы при досрочном выходе из области видимости.

Во-первых, для опытного программиста - это такая же небылица, как и возможность забыть использовать = вместо ==, и поэтому в if надо константу надо ставить слева от оператора. (Напоминает 1-й курс 1-й семестр.) :-) Даже в особо крупных проектах, в том же Postgres, написанном на Си, это не проблема. Во-вторых, в цепепе столько подводных камней, что там вообще много чего забыть, если не быть зубрилкой :-) И ты сам это продемонстрировал чуть ниже :-)

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

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

Ситуация, когда после обнаружении ошибки X отменяется какое-то предыдущее действие и диагностируется ошибка Y легко возникает и при использовании plain old C. В итоге у нас есть два кода ошибки X и Y, но наверх нужно возвращать только один.

Это та ситуация, когда нет лучшего решения, чем сигнальный протокол Common Lisp :-)

Это фундаментальная проблема и «проглатывание» исключений в деструкторах является всего лишь одним из ее решений, адаптированных под сам факт того, что C++ поддерживает исключения.

Это фундаментальная проблема исключений цепепе, т.к. генерация исключений раскручивает стек и вызывающий код обязан обрабатывать ошибку в условиях, кода вызванный им код свою работу уже завершил. А вот сигнальный протокол Common Lisp стек не раскручивает, поэтому код, что ниже по стеку, может обрабатывать сначала ошибку X, потом Y, не прекращая работы кода, в котором эти ошибки возникли.

А потом обнаружит, что driver_type получает аргумент типа const std::string, а не const char *. И что operator| для двух driver_type может бросать исключения, если пользователь пытается объединить несовместимые между собой драйвера. И что connect ждет аргументов типа std::string. И что get_isolation_level получает std::string, а кроме того, порождает исключение, если распарсить переданную строку не смог.

Вот и я за это. В цепепе на каждом шаге программиста подстерегает засада. Семантика цепепе отвратительна, даже в сравнении с Си. Если код в Си более-менее прямо выражает то, что он делает, и можно как-то ручаться за его побочные эффекты, то в цепепе надо всегда быть начеку, потому что ловушки расставлены везде, что ты и ещё раз продемонстрировал.

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

Ну это кому как. По мне так уж проще положиться на сборщик мусора, а когда нужно реально программировать на низком уровне, то взять Си.

Во-первых, для опытного программиста - это такая же небылица, как и возможность забыть использовать = вместо ==, и поэтому в if надо константу надо ставить слева от оператора.

Ничего подобного, это случается на каждом шагу. А при рефакторинге старого, да еще и чужого кода, допустить такую ошибку проще простого.

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

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

Для для очистки удалённых ресурсов лучше полагаться не на них, а управлять такими ресурсами явно.

Явное управление превращается в решето при наличии исключений. Причем это характерно для всех языков с поддержкой исключений, не только C++. Поэтому в C# сделали using, а в Java добавили аналогичный try-with-resources.

Это та ситуация, когда нет лучшего решения, чем сигнальный протокол Common Lisp

Во-первых, глупо приплетать Common Lisp в обсуждении инструмента для языка C++. Во-вторых, вы бы продемонстрировали на показанном выше примере, как бы это выглядело. Может статься, что красота решения на CL нравится только вам.

В цепепе на каждом шаге программиста подстерегает засада.

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

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

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

По мне так уж проще положиться на сборщик мусора, а когда нужно реально программировать на низком уровне, то взять Си.

А что делать для задач, где на GC не получается положиться, а C оказывается слишком низкоуровневым?

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

Это ещё почему? Только из-за std::exception?

Есть проект, который использует буст. Но без вашего ndk он использовать буст не может.

Никто не говорил, что не может. Утверждалось лишь, что с помощью нашего NDK это будет сделать намного удобнее.

Для меня это несколько странно.

Вот вам типичный пример:

Есть проект, в котором не используется Boost, по нескольким причинам, в основном религиозного свойства (т.е. никакого внятного технического обоснования таким причинам нет), но есть и существенные причины. Внутри же команды есть противоречия - многие хотели бы Boost использовать, но не могут оттого, что наложено вето со стороны лица, способного этому препятствовать. Двумя существенными (а не надуманными) причинами запрета использования Boost под Android являются а) сложность его сборки под Android и б) его неоттестированность (опять-таки под Android). Теперь, благодаря нашему проекту, эти проблемы снимаются. Именно это и радует людей, которые хотели бы использовать Boost под Android. Теперь у них есть аргументы, и они могут попытаться протолкнуть использование Boost.

Кроме того, не забывайте, что множество проектов создается каждый день. Далеко не все проекты на планете имеют продолжительную историю. Для таких проектов и вовсе факт наличия Boost в CrystaX NDK очень удобен - просто бери и пользуйся. Об этом вам уже говорили многие.

Вот я и спрашиваю, где?

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

Это ещё почему?

Из-за того, что new стал бросать исключения. А new много где в STL используется.

Это и есть большая часть буста?

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

Вон BRE даже ответить не может, что именно он использует из буста.

Это не имеет ни малейшего значения. Людей на планете много, и каждому что-то да нужно. Поэтому и Boost нужен многим, в том числе и его копилируемая часть. И при этом абсолютно неважно, нужно что-то из компилируемой части собственно BRE или нет. Т.к. целевая аудитория проекта - далеко не один BRE.

Вот вам типичный пример:

Этот пример был бы хорош, если бы вы проталкивали патчи в апстрим буста, а не бандлили его со своим ndk.

Теперь у них есть аргументы, и они могут попытаться протолкнуть использование Boost.

Так и вижу чудный аргумент - «давайте начнем использовать буст потому, что его саппортит команда сделавшая форк ndk». Если этот чудный аргументатор будет послан лесом, то я не удивлюсь.

Прочитайте ваши сообщения (сначала здесь, затем на известной вам площадке, где произошел конфликт), и попытайтесь взглянуть на них непредвзято.

Я знаю, что я писал и о чем я писал. Так что взгляните сами, но не с позиции принцессы на горошине, а непредвзято.

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

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

Поэтому и Boost нужен многим,

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

Т.к. целевая аудитория проекта - далеко не один BRE.

Целевая аудитория буста знает зачем им буст нужен и как его готовить. И вначале они решают нужен ли им буст в проекте, а потом уже смотрят, есть ли он в вашем ndk.

Этот пример был бы хорош, если бы вы проталкивали патчи в апстрим буста, а не бандлили его со своим ndk.

Вам уже было сказано, что патчи в апстрим мы отправляем и с разработчиками библиотек Boost работаем. Другое дело, что этих патчей мало, т.к. мы стараемся патчить не Boost для workaround-а кривостей Android, а сам NDK.

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

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

Остальное комментировать не вижу смысла.

А new много где в STL используется.

Это да, вот только bad_alloc всё равно мало кто обрабатывает.

ну ты чувак и тупой

Вам уже было сказано, что патчи в апстрим мы отправляем и с разработчиками библиотек Boost работаем.

Ну вот этого и достаточно, зачем бандлить буст в ndk?

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

Ого, у нас две принцессы на горошине, которые требуют к себе уважительного отношения. Только все ваше «уважай меня» - это соглашайся с вашим мнением.

Остальное комментировать не вижу смысла.

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

ну ты чувак и тупой

Количество аргументов зашкаливает :)

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

Нет. Просто предпочитают не связываться с хамством.

Ничего подобного, это случается на каждом шагу. А при рефакторинге старого, да еще и чужого кода, допустить такую ошибку проще простого.

Тем не менее, большие проекты уровня Postgres доказывают, что будучи написанными на Си, где нет деструкторов, они успешно развиваются и признаются во всём мире как надёжные системы.

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

Да уж куда там без зубрёжки то? Одно то, что из деструкторов нельзя генерировать исключения (при этом, компилятор никак на это не ругается, и позволяет выстрелить в ногу в рантайме, поэтому, это просто надо знать наизусть и забота полностью на плечах программиста), деструктор должен быть виртуальным, если класс абстрактный (потому что, если это не так, то опять же, оторвёт ногу, и за это тоже полностью отвечает программист). Ты можешь сказать, что с твоим 20-ти летним стажем, ты таких ошибок не допустишь, но я могу тебе сказать, на это, что сишник с таким же стажем не забудет вызвать free().

Явное управление превращается в решето при наличии исключений. Причем это характерно для всех языков с поддержкой исключений, не только C++. Поэтому в C# сделали using, а в Java добавили аналогичный try-with-resources.

Не надо заливать, Женя. Все дураки, один ты умный. Когда речь заходит о явном управлении ресурсами, то исключения вообще никто вменяемый не использует. Поэтому и рантаймы и ядра пишут на Си, где нет исключений, которые нафиг не нужны при ручном управлении ресурсами.

Во-первых, глупо приплетать Common Lisp в обсуждении инструмента для языка C++. Во-вторых, вы бы продемонстрировали на показанном выше примере, как бы это выглядело. Может статься, что красота решения на CL нравится только вам.

Во-первых глупо сначала заявить, что «глупо приплетать Common Lisp в обсуждении инструмента для языка C++», а потом просить, чтобы тебе нарисовали на «глупо приплетённом» языке решение, тем более, что мне уже досрочно понятна твоя реакция из-за твоего «красота решения на CL нравится только вам». Во-вторых, я не буду приводить тут тривиальные коды на лиспе. Если тебе или кому-то ещё реально интересно, то без труда можешь заглянуть в любую книгу по Common Lisp и прочитать. У того же Сайбеля объяснить и наглядно показать получится лучше, чем у меня. :-)

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

Цепепе высокоуровневый? :-) А вон, твой коллега Dark заявлял, что C++ - низкоуровневый :-) И я - тоже говорю, что он низкоуровневый. Да все говорят, что он низкоуровневый. То, что там деструкторы к структурам приклепали и понафигачили шаблонов не сделало его высокоуровневым. Просто к проблемам Си добавилось ещё куча других проблем.

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

Я не буду здесь спорить, что надо много кода писать на Си. Но в том же Postgres в некоторых местах используется setjmp/longjmp. По сложности сопровождения идентично.

А что делать для задач, где на GC не получается положиться, а C оказывается слишком низкоуровневым?

Как я уже сказал, и Си и Си++ одного уровня. Просто в Си++ добавлен функционал, который решает одни проблемы, но добавляет другие.

Кроме того, язык C++ поддерживает исключения. После включения STL в стандарт языка уже можно говорить, что исключения используются повсеместно.

Когда услышал про STL, не поленился и поднял архив почты Postgres. Вот, нашёл такое старенькое письмецо от одного из главных разработчиков: «libpq++ was a constant portability headache. This was in fact not libpq++'s fault; the problem was that C++ was a moving target, both as to the language itself and the expected standard library. Perhaps the C++ people have finally got their act together, but it's too late. We won't be buying back into that morass. Postgres is a C project and we have other things to do than cope with STL-flavor-of-the-month.»

Как бы всё расписано наглядно :-)

Тред поучителен во многих отношениях.

Нет. Просто предпочитают не связываться с хамством.

Так вы уже осилите показать, где я хамил?

Просто в Си++ добавлен функционал, который решает одни проблемы, но добавляет другие.

Вот это правильно. Только это не делает плюсы хуже си. Кому-то плюсы удобнее, кому-то си. О чем спор мне непонятно.

Тем не менее, большие проекты уровня Postgres доказывают, что будучи написанными на Си, где нет деструкторов, они успешно развиваются и признаются во всём мире как надёжные системы.

Проекты уровня Postgres сложно приводить в качестве примера, ибо:

• такие проекты имеют очень долгую историю и стартовали когда C++ был очень далек от своего сегодняшнего уровня;
• одним из требований к таким проектом была высокая переносимость, которой в прошлом было гораздо проще достичь на C, чем на C++ (впрочем, актуальность этот тезис сохраняет и сейчас);
• количество ресурсов, вовлеченных в разработку Postgres или другого OpenSource проекта, зачастую превышает объемы ресурсов, доступных для коммерческих проектов. Да и такое понятие, как дедлайн для OpenSource и коммерческого проекта несколько различаются.

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

Одно то, что из деструкторов нельзя генерировать исключения (при этом, компилятор никак на это не ругается, и позволяет выстрелить в ногу в рантайме, поэтому, это просто надо знать наизусть и забота полностью на плечах программиста),

А еще нельзя обращаться по неиницализированным указателям. Это одно из базовых правил, которое нужно соблюдать.

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

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

Ну и ошибаются люди, что поделать. Я не исключение. Поэтому использую техники, которые защищают от ошибок, в частности, сочетаю RAII и исключения. Т.к. это оказывается надежнее, чем коды возврата и практика goto err.

Все дураки, один ты умный.

Ну авторы C# вряд ли глупее меня. Скорее прямо наоборот. Аналогично и с людьми, которые добавляли try-with-resources в Java 8.

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

Смотря какие рантаймы и какие ядра. C++ные исключения разрешены даже в MISRA-C++.

Если тебе или кому-то ещё реально интересно, то без труда можешь заглянуть в любую книгу по Common Lisp и прочитать.

Ну вот я почитал про исключения в CL и про (restart-case). Тем не менее не понял, почему более простой и понятный подход C++ (а так же кучи других современных и не очень языков) плох. Для моего примера с СУБД так вообще.

Что-то похожее касательно исключений используется и в Eiffel. И, по-моему, геморроя с обработкой исключительных ситуаций там больше, чем в C++/Java/C#/Python/Ruby.

Так что постулат о том, что исключения в C++ плохи для управления ресурсами не раскрыт. Да и вряд ли у вас получится его раскрыть.

А вон, твой коллега Dark заявлял, что C++ - низкоуровневый

Я не знаю, с чем именно он сравнивает C++. Я сравниваю с C. По сравнению с C язык C++ высокоуровневый. Не хуже C# или Java по своим выразительным возможностям.

Так вы уже осилите показать, где я хамил?

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

Я общение на эту тему прекращаю. В этом нет ничего интересного ни для вас, ни для меня, ни для других читателей.

Если есть конкретные технические вопросы, готов обсуждать.

Вот, нашёл такое старенькое письмецо от одного из главных разработчиков: «libpq++ was a constant portability headache. This was in fact not libpq++'s fault; the problem was that C++ was a moving target

Date: 2003-12-22 05:04:05

Интересно, к каким временам относились описанные проблемы - 15 лет назад? 20?

Тут все совсем не так однозначно. Далеко не всегда нужно иметь виртуальный деструктор в абстрактном классе.

Абсолютно всегда, за исключением если разработчик библиотеки экстрасенс, и знает, что в подклассах никогда не понадобится деструктор. Поэтому, дефакто, это такое же правило, как и «не используй нулевой указатель».

Поэтому вопрос наследования требует пристального внимания.

Тем хуже для цепепе, где проектирование действительно качественных библиотек, а не того дерьма, которое образует большинство сегодняшних библиотек, было всегда большой головной болью и бессоницей. Александреску об этом в своей книге The Modern C++ Design написал, и таки попытался решить проблему проектирования библиотек с помощью метапрограммирования. И хвалёный boost только за счёт подхода метапрограммирования и является той самой главной «батарейкой» для цепепе. Только вот знатоков boost или идей Александреску среди программистов цепепе не много, а потому, большинство из них, генерируют дерьмо.

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

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

Ну авторы C# вряд ли глупее меня. Скорее прямо наоборот.

А причём тут C#? Я имел в виду, что много где ресурсами управляют врукопашную и получается далеко не решето. Это зависит от мастерства. Хороший сишник, вроде Линуса, за выходные тебе первую рабочую версию git напишет, как, впрочем, он и сделал :-)

Ну вот я почитал про исключения в CL и про (restart-case). Тем не менее не понял, почему более простой и понятный подход C++ (а так же кучи других современных и не очень языков) плох. Для моего примера с СУБД так вообще.

Ну тогда и забудь :-) Хорошо что я не потратил времени на написание кода :-)

Так что постулат о том, что исключения в C++ плохи для управления ресурсами не раскрыт. Да и вряд ли у вас получится его раскрыть.

Как-то ты постулат некорректно сформулировал. Исключения предназначены не для управления ресурсами, а для передачи ошибки в вызывающий код из кода, который «не знает» как такую ошибку обработать. (Если бы знал, то нахрен бы ему генерировать исключение? Обработал бы сам.) Что же касается несовместимости механизма исключений с низкоуровневым программированием ядер, то сошлюсь на слова того, кто в этом дока - Линус Торвальдс:

- the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can't see what he is writing is really just C anyway (c) was given an assignment in CS class to do so.

Не хуже C# или Java по своим выразительным возможностям.

А вот по семантике - заметно хуже. Потому то IDE для C++ и рядом не стояли с IDE для решётки и жавы. :-)

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

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

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

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

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

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

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

Я имел в виду, что много где ресурсами управляют врукопашную и получается далеко не решето.

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

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

Ну тогда и забудь

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

Что же касается несовместимости механизма исключений с низкоуровневым программированием ядер, то сошлюсь на слова того, кто в этом дока - Линус Торвальдс

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

Абсолютно всегда, за исключением если разработчик библиотеки экстрасенс, и знает, что в подклассах никогда не понадобится деструктор. Поэтому, дефакто, это такое же правило, как и «не используй нулевой указатель».

Тем хуже для цепепе, где проектирование действительно качественных библиотек, а не того дерьма, которое образует большинство сегодняшних библиотек, было всегда большой головной болью и бессоницей. Александреску об этом в своей книге The Modern C++ Design написал, и таки попытался решить проблему проектирования библиотек с помощью метапрограммирования. И хвалёный boost только за счёт подхода метапрограммирования и является той самой главной «батарейкой» для цепепе. Только вот знатоков boost или идей Александреску среди программистов цепепе не много, а потому, большинство из них, генерируют дерьмо.

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

А вот по семантике - заметно хуже. Потому то IDE для C++ и рядом не стояли с IDE для решётки и жавы. :-)

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

Парадокс только в том, что вам на это ни я, ни eao197 и не возражал. Возражения заключались совсем в другом. Если попробовать кратко свести их в один абзац, то получится примерно так:

Да, C++ неидеальный язык, и его грамотное использование требует большого практического опыта. Тем не менее, несмотря на все его минусы (довольно серьезные!), пользоваться им можно (зная его темные места), и зачастую выходит так, что это - наилучший инструмент для решения прикладных задач в определенных областях. Не потому, что он best ever. А потому, что другие (для решения этих задач) хуже, т.к. у этих других хватает своих минусов и темных мест. И ругать инструмент за его недостатки - как минимум глупо. Надо просто уметь им пользоваться. Или переходить на другой инструмент.

А в контексте CrystaX NDK - мне очень не нравится, что Google решает за меня, чем и как мне, как программисту, пользоваться. Я хочу решать это сам. Поэтому и работаю над CrystaX NDK, где, кстати, поддерживается не только С++, но также C и Objective-C - выбирайте сами, чем пользоваться; я вам ничего навязывать не собираюсь. И мы работаем над поддержкой других языков. Тот же Lisp я бы с удовольствием добавил в сборку CrystaX NDK, но для этого нужен хороший нижележащий POSIX layer, над созданием которого мы и работаем. И Boost вместе с другими проектами помогает этот POSIX layer хорошо тестировать.