LINUX.ORG.RU

Вышел CrystaX NDK 10.2.0

 , ,


1

3

Новая версия CrystaX NDK 10.2.0 (набор инструментов для разработки на C/C++/Objective-C под Android) доступна для скачивания.

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

  • Поддержка Objective-C v2 runtime и начальных Cocoa-совместимых фреймворков (Foundation и CoreFoundation).
  • Добавлены готовые к использованию библиотеки Boost 1.58.0. В рамках проекта CrystaX NDK ведется регулярное регрессионное тестирование Boost под Android, ведущее к улучшениям как в Boost, так и в CrystaX NDK.
  • Добавлен новый набор инструментов (toolchain) на основе clang-3.6, с переносом всех исправлений, сделанных в clang-3.4 и clang-3.5 в рамках проекта.
  • Добавлены готовые к использованию libpng-1.6.17, libjpeg-9a и libtiff-4.0.4beta.
  • А также большое количество исправлений и мелких улучшений, в сумме ведущих к более стандартному и предсказуемому поведению CrystaX NDK.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: crystax (всего исправлений: 1)

Ответ на: комментарий от anonymous

Из этого следует, что имеются некие преимущества у Си++ перед Си? Пожалуйста, назови их.

я не он, но, например, в MSVC++ не работает C99 чуть более чем вообще. поэтому если надо им собирать — то я бы наверное таки компилировал крестовым компилятором сишный код, чтобы пару дополнительных плюшек иметь.

хз, можно ли считать это преимуществом.

кроме этого никаких преимуществ не припоминаю. одни недостатки.

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

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

waker ★★★★★
()
Ответ на: комментарий от anonymous

Из этого следует, что имеются некие преимущества у Си++ перед Си? Пожалуйста, назови их.

Одно из самых главных преимуществ - деструкторы и связанная с ними концепция RAII. Контроль со стороны компилятора за scope leaving (неважно каким образом) - переоценить полезность очень сложно.

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

Лямбды в C++11/C++14 (и добавляющая им удобства новая семантика «auto»). Очень удобно для разработки и не привносит никакого overhead-а в run-time.

Это все, если крупным помолом. Есть еще много мелочей, не таких значимых, но тем не менее сильно упрощающих жизнь (этакая «малая механизация»).

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

Я и не указываю, я говорю, что с моей т.з. цепепе - говно.

С моей тоже. Но любим мы его не только за это.

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

Как верно сказал waker выше, это для эмуляции двух версий одной библиотеки. Вообще же да, условную компиляцию использую (в меру).

Тут как-то пробегал кукарекающий любитель шаблонов цепепе, который утверждал, что препроцессор ненужен и всё можно сделать на шаблонах :-) Они же тьюринг-полные :-) :-) :-)

На это остается только развести руками в недоумении.

crystax
() автор топика
Ответ на: комментарий от waker

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

Мне что, начать бить себя в грудь с криком «Поверьте мне! Поверьте! Умоляю!» ? Я все сказал, и даже привел работающий пример. Тем самым целиком опроверг ваши опрометчивые высказывания. Вам крыть нечем, поэтому вы теперь пытаетесь скрыться за жалко выглядящими фразами «не верю», «а вот сделай проект масштаба Qt» и т.д.

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

Говорю так, исходя из собственного жизненного опыта. Меня несколько раз в жизни крупно макали мордой в дерьмо, и макали заслуженно, т.к. я вел себя в этих ситуациях - дурак дураком! И, что характерно для дурака, крайне самоуверенно. Тем не менее, несмотря на то, что это было крайне неприятно в момент собственно макания, мне это сильно пошло на пользу. Сбило спесь и научило не быть слишком самоуверенным. Вам, очевидно, это еще предстоит осознать.

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

вот будет у тебя проект масштаба Qt, например, на крестах, с нативным крестовым API, и чтобы вот это все работало, как в твоем примере, на протяжении всего жизненного цикла (всмысле, как если бы Qt 1,2,3,4,5 были бы вот так друг с другом совместимы) тогда можно продолжать разговор.

No comments.

crystax
() автор топика
Ответ на: комментарий от crystax

Одно из самых главных преимуществ - деструкторы и связанная с ними концепция RAII. Контроль со стороны компилятора за scope leaving (неважно каким образом) - переоценить полезность очень сложно.

Согласен. Сама концепция RAII весьма полезная. А вот концепция исключений - ущербная. Рассмотрим код:

try {
  Transaction t;
  // работаем...
  t.commit();
} catch (Db_exception& e) {
  // здесь остаётся только послать пользователя подальше,
  // потому что стек уже раскручен, восстановиться не получится.
} catch (Commit_error& e) {
  // а вот здесь и вовсе беда, т.к. возникла ошибка
  // в ходе отправке команды COMMIT - какая-то непредвиденная
  // ошибка. Беда в том, что такое исключение должно быть
  // сгенерированно из деструктора ~Transaction(), но
  // генерировать исключения из деструктора - это очень
  // дурной стиль и чреват такими проблемами, которые нельзя
  // создавать пользователям библиотек. В частности, все библиотеки
  // цепепе для работы с БД, в которых есть класс Transaction -
  // поступают неправильно.

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

Шаблоны в цепепе очень ограничены. Я тебе приведу всё туже банальную задачу:

auto cn = init_connection();
cn->exec("f", 1, 2, 3); // использование variadic templates
// хочу, чтобы вызов выше преобразовался во время компиляции
// в SELECT * FROM f(1, 2, 3)
А ну ка, рискни и сгенерируй мне шаблонами строчку во время компиляции? :-) Только, пожалуйста, не приводи ссылки на извращения для выноса мозга, созданные реальными задротами. Что же касается макросов в цепепе или в це, то они - говно. Это же не лисповые макры :-)

Лямбды в C++11/C++14 (и добавляющая им удобства новая семантика «auto»). Очень удобно для разработки и не привносит никакого overhead-а в run-time.

Ну, во-первых, это «очень удобно» пришлось ждать больше 20-ти лет :-) А во-вторых, лямбды в цепепе неудобны уже тем, что явно надо замыкать переменные лексической видимости.

С моей тоже. Но любим мы его не только за это.

Хорошо, что ты - не упоротый фонат. Уважуха.

anonymous
()
Ответ на: комментарий от anonymous

опять ты мошнишь, пиписька коня? :-)

А вот и главный цепепешник и питонист пришёл :-) Додедал вспомогательный проект на питоне? :-)

anonymous
()
Ответ на: комментарий от anonymous

0ставьте этого нищего , он во всех тредах пытается оправдать свою жизнь.

Всё забыл со своим вспомогательным проектом на питоне :-) Он не нищий, а борщевик :-) Мамкин борщик то вкуснее всякого эвроговнеца, а ватничек - теплее и удобнее всяких д&г. Ну блинчики - то вообще цинус :-)

anonymous
()
Ответ на: комментарий от crystax

Я все сказал, и даже привел работающий пример.

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

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

да, извини что ответил тебе. больше не повторится.

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

Тем не менее, отвечу кратко по пунктам.

Согласен. Сама концепция RAII весьма полезная. А вот концепция исключений - ущербная.

С моей точки зрения, ничего ущербного в C++ exceptions нет. Это очень стройная и хорошо работающая система, которая позволяет сделать нормальное транзакционное поведение кода (не сама по себе, а в сочетании с другими особенностями C++, такими как RAII). Правда, сделать это непросто, и очень легко наплодить ошибок, под которыми и помереть легко. Но это так вообще всегда в C++, и не является отличительной чертой именно исключений.

Шаблоны в цепепе очень ограничены.

Для своих задач они - самое то!

А ну ка, рискни и сгенерируй мне шаблонами строчку во время компиляции?

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

Ну, во-первых, это «очень удобно» пришлось ждать больше 20-ти лет

Лучше поздно, чем никогда.

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

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

()[=] {}
или
()[&] {}
, которые замыкают все локальные переменные, как в других языках.

crystax
() автор топика
Ответ на: комментарий от crystax

Да и спать, откровенно говоря, очень хочется.

Понимаю, нет проблем. Сон - это хорошо :-)

С моей точки зрения, ничего ущербного в C++ exceptions нет. Это очень стройная и хорошо работающая система, которая позволяет сделать нормальное транзакционное поведение кода

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

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

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

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

Для меня это очень смешно звучит: «полный контроль над тем, что ты делаешь» :-) Да я и без закорючек ()[=] {} контролирую то, что я делаю. И я считаю тупостью инкапсуляцию и private/protected - это что, защита идиота от идиота? Раньше я верил всем этим сказкам про инкапсуляцию, про то, что методы должны быть публичными, а данные - приватными. Есть ещё адепты виртуальных ф-й, которые считают, что они должны быть в private. Ну для чего всё это? Можно простым человеческим языком сказать, что «не трогай это поле в структуре», или «эта функция является вспомогательной, не трогай», вместо огорода из public/private. Нормальный человек поймёт и будет придерживаться доки, а за ненормальных я и не ручаюсь. Мораль - лично мне такой самоконтроль не нужен. :-)

anonymous
()
Ответ на: комментарий от anonymous

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

Так ты ещё один try-catch создай и заканчивай его там, куда восстанавливаться будешь.

try {
  transaction t;
  
  try {
    t.work(1);
  } catch (Db_exception& e){
    // Попробуем поправить; если не получается, новое исключение упадёт во второй catch
    t.work(2);
  }
} catch (Db_exception& e) {
  // Шлём пользователя подальше, так как мы уже попробовали пофиксить, не получилось
} catch (Commit_error& e) {
GamePad64
()
Ответ на: комментарий от GamePad64

Так ты ещё один try-catch создай и заканчивай его там, куда восстанавливаться будешь.

А если вариантов для исправления штук 5, то должно быть ещё 4 уровня вложенности catch? :-) И ты называешь код со вложенными catch не ущербным? :-)

anonymous
()

boost.python for ndk

Уважаемый crystaх, я многолетний читатель лора, но впервые захотел здесь зарегаться и написать вам. Я не первый год занимаюсь коммерческими биндингами питона (3.3+) и boost.python под Windows/Linux/MacOSX. Я никогда особо не афишировал свои скилзы, но тут мне тема показалась весьма интересной. Мне было бы весьма интересно увидеть работающий boost.python на моем андроид-девайсе. В том, что я соберу чистый питон 3+ под андроид я честно-говоря даже не сильно сомневаюсь. Но вот boost.python - тут у меня много сомнений. Если Вы, crystаx, в случае чего, готовы помочь мне с вашей экспертной оценкой, я этим несомненно займусь. Займусь just for fun )) Если все так, то дайте мне весточку на vitaly дот murashev собака gmail дот com. На хабре я слегка засветился по ссылке http://habrahabr.ru/company/acronis/blog/208378/ , но это было сделано лишь для получения халявного хабр-аккауна

vet
()
Ответ на: boost.python for ndk от vet

В том, что я соберу чистый питон 3+ под андроид я честно-говоря даже не сильно сомневаюсь.

Само собой, ничего страшного там быть не должно. Надо просто потратить время и сделать. Мы и сами хотим это сделать, но руки не доходят. Если же вы за это возьметесь, и позволите нам использовать ваши результаты в CrystaX NDK - это будет просто великолепно!

Если Вы, crystаx, в случае чего, готовы помочь мне с вашей экспертной оценкой, я этим несомненно займусь.

Безусловно помогу. Это именно то, для чего я создавал свой проект - для совместной работы над тем, что нужно именно нам, программистам, а не корпорациям. Огромное спасибо за ваше желание внести свою лепту в общее дело!

Дальнейшее общение с обсуждением технических деталей предлагаю перенести в приват (e-mail).

crystax
() автор топика
Ответ на: комментарий от anonymous

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

Эта претензия вызывает недоумение. Да, C++ exceptions - это не Lisp continuations; это так, и глупо было бы на это возражать. Но предъявлять к ним подобную претензию - несколько неожиданно и как-то глуповато. Примерно как предъявлять претензию к std::shared_ptr на то, что он не является GC. В C++ много чего нет, что есть в других языках (тот же reflection, на котором свет клином сошелся у waker-а выше по треду), но это просто означает, что надо учитывать эти ограничения и проектировать систему с их учетом. Если же ограничения C++ по каким-то причинам неприемлемы, и условия задачи позволяют использовать Lisp, к примеру, ну так и используйте его на здоровье! В любом случае, C++ exceptions в том виде, каком они есть, прекрасно выполняют свою задачу, и их достаточно удобно использовать для построения транзакционной модели поведения кода.

Да я и без закорючек ()[=] {} контролирую то, что я делаю.

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

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

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

Поэтому надо просто работать и менять мир к лучшему. Без бессмысленных эмоций.

crystax
() автор топика
Ответ на: комментарий от crystax

Эта претензия вызывает недоумение. Да, C++ exceptions - это не Lisp continuations; это так, и глупо было бы на это возражать. Но предъявлять к ним подобную претензию - несколько неожиданно и как-то глуповато.

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

В C++ у вас есть для этого возможность.

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

но свобода действий в C++ несомненно гораздо выше, чем в Java

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

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

Пригодный на данном этапе эволюции, потому что в него напихали всего до кучи для решения многих сегодняшних задач. Но ты опять не уловил моей мысли. Как ты мне сказал, так и я тебе скажу - пиши на цепепе на здоровье. Если у тебя получается и есть хороший результат - флаг в руки, без иронии. Однако если ты замечаешь в один прекрасный день, что посвящаешь своему делу всё своё время, то не знаю, как ты, а мне это не по душе. А уж мыслить категориями и абстракциями цепепе я тем более не хочу. Цепепе, если он является единственным языком в распоряжении программиста, способствует однобокости и деградации мышления. Поэтому, для меня это всего лишь мерзкий язык, используется который когда нет альтернатив, а кодить надо. И мне всегда забавно наблюдать за фонатами, так рьяно его защищающих :-)

Поэтому надо просто работать и менять мир к лучшему. Без бессмысленных эмоций.

Вот хорошая мысль. Прежде всего, работать надо над собой. Ты же ведь сам говорил «Ну а я себе не очень доверяю.», значит, есть над чем работать :-) Всем есть над чем работать. И лениться нельзя. Если есть возможность, надо расширять кругозор и учиться мыслить критически. Ты в этом направлении, как я вижу, некоторые шаги сделал. Молодец. :-)

anonymous
()
Ответ на: комментарий от anonymous

класс Transaction, деструктор которого по определению должен освобождать ресурсы, т.е. завершать транзакцию путём отправки «COMMIT» на сервер

Тут проблема в голове разработчика, который пишет такой класс. А не в системе исключений C++.

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

По сравнению с чистым C они обеспечивают совсем другой уровень обеспечения надежности.

Ну и вообще непонятно, почему в топике про анонс инструмента для C++ вам захотелось пообсуждать преимущества Common Lisp над C++. Хотите программировать на CL — программируйте. Вынуждены писать на C++ — научитесь это делать. А то придумаете себе звать COMMIT в деструкторе класса Transaction, а потом утверждаете, что «цепепе говно».

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Тут проблема в голове разработчика, который пишет такой класс. А не в системе исключений C++.

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

По сравнению с чистым C они обеспечивают совсем другой уровень обеспечения надежности.

См. выше.

Вынуждены писать на C++ — научитесь это делать.
А то придумаете себе звать COMMIT в деструкторе класса Transaction, а потом утверждаете, что «цепепе говно».

Умею писать на цепепе. цепепе - говно. :-)

anonymous
()
Ответ на: комментарий от anonymous

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

Если вы это знаете, но упорно пытаетесь применять для чего-то другого (чему свидетельством приведенный вами пример), то это не проблемы C++.

Верить LOR-анонимам в том, что они «умеют писать на цепепе» нельзя в принципе. А уж когда они приходят в подобную тему, чтобы расхвалить любимый ими Lisp, тем более.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Т.е., нет никакой свободы. Все хорошие пацаны стремятся писать в «хорошем» стиле, и никак иначе.

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

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

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

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

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

Цепепе, если он является единственным языком в распоряжении программиста, способствует однобокости и деградации мышления.

В этом нет никаких сомнений. Но только это относится не к языку, а вообще к любой технологии.

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

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

crystax
() автор топика
Ответ на: комментарий от eao197

Если вы это знаете, но упорно пытаетесь применять для чего-то другого (чему свидетельством приведенный вами пример), то это не проблемы C++.

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

Верить LOR-анонимам в том, что они «умеют писать на цепепе» нельзя в принципе.

Я никого не хочу обидеть, так что давай не будем лучше про «умение писать на цепепе» и оставим за кадром анализ твоего кода :-)

anonymous
()
Ответ на: комментарий от anonymous

Или ты реально упоротый фонат :-)

Нет, просто достаточно долго в профессии, чтобы понять, что нет смысла ругать инструмент.

Я никого не хочу обидеть, так что давай не будем лучше про «умение писать на цепепе» и оставим за кадром анализ твоего кода :-)

Это было бы интересно. Но не в данной теме. Как и выливание говна на C++ и дифирамбы Common Lisp.

Имеете что сказать по поводу NDK — скажите. Если нет, хватит срать к комментах, тема не про вашу боль.

eao197 ★★★★★
()
Ответ на: комментарий от crystax

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

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

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

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

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

Давай закругляться. У меня очень много есть чего сказать ещё, но из уважения к тебе и к своему времени, стоп. :-) Удачи!

anonymous
()
Ответ на: комментарий от eao197

Нет, просто достаточно долго в профессии, чтобы понять, что нет смысла ругать инструмент.

Есть смысл ругать инструмент, чтобы те, кто в профессии не долго, мотали на ус. :-)

Как и выливание говна на C++ и дифирамбы Common Lisp.

Ну как, это уж каждому по заслугам :-)

Если нет, хватит срать к комментах, тема не про вашу боль.

Глупо возлагать на себя миссию модератора :-) Это не ваш ресурс, и эта темо тоже не про вашу боль :-) Если комменты позволяют писать, значит владельцу ресурса они нужны :-) cheers

anonymous
()
Ответ на: комментарий от anonymous

Правильно, только когда из-за цепепе у кого-то случился фэйл, то без эмоций трудно

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

crystax
() автор топика
Ответ на: комментарий от crystax

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Если нам нужен доступ к объекту Transaction и интересуют именно ошибки метода commit, то в чём проблема написать вот так?

Transaction t;
  // ...
try {
  t.commit();
} catch (Db_exception& e) {}

В частности, все библиотеки цепепе для работы с БД, в которых есть класс Transaction - поступают неправильно.

Ты валишь с больной головы на здоровую. Во первых, гарантии про commit/rollback - они на стороне БД. Во вторых, в таких проблемных местах, как собственно ты и продемонстрировал, предоставляют дополнительный метод commit, а не просто выполняют работу в деструкторе. То есть, если мы хотим обработать потенциальную ошибку, то зовём commit и ловим исключения. Если нет, то полагаемся на деструктор, который, действительно, принято делать не бросающим.

Да, тут RAII «не работает», но это проблема не именно в исключениях - если бы commit возвращала код ошибки, то ничего принципиально не поменялось бы.

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

Шаблоны в цепепе очень ограничены

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

Ну, во-первых, это «очень удобно» пришлось ждать больше 20-ти лет :-)

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

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Только их «язык» настолько ужасен, что сам цепепе даже рядом не стоял.

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

Да я и без закорючек ()[=] {} контролирую то, что я делаю

Да ладно? За тебя ГЦ проконтролирует и продлит время жизни, если надо. А в плюсах захватил что-то, оно сдохло - огребай проблем. Следствие низкоуровневости, опять же.

Можно простым человеческим языком сказать, что «не трогай это поле в структуре», или «эта функция является вспомогательной, не трогай», вместо огорода из public/private.

Хочешь сказать, что комментарии будут короче одного ключевого слова? Самому не смешно-то? Опять же, так не получится случайно обратиться к «закрытым» данным/функциям. Если всегда удерживаешь в голове ведь код, с которым работаешь, да ещё и с комментариями, то могу только порадоваться за тебя.

Если же смотреть шире, то паблик/приват лучше работают со IDE, то есть при автодополнении видно какой метод пытаешься вызвать. И не надо в комментарии лезть.

Только не надо опять заводить песню как у С++ плохо с ИДЕ. Да, не идеально, но многое работает. В лиспе вон тоже свои «проблемы» есть. Скажем, методы зовутся не через точку, так что с автодополнением сложнее. И да, я в курсе про мультиметоды, так что понимаю, что за фичи надо платить.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

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

С какой стати? Не все лямбды захватывают состояние. Опять же, оно сделано явным именно потому, что в разных случаях нужно разно. В расте выбрали подходящий дефолтный вариант (возможный благодаря тому, что есть borrow checker), но есть возможность (и бывает необходимость) указывать явно.

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

Вообще-то возможно. Саттер осуждает по другим причинам и правильно делает.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

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

Нет.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Ты валишь с больной головы на здоровую. Во первых, гарантии про commit/rollback - они на стороне БД.

Причём тут гарантии на стороне БД? Я говорю про то, что из деструктора нельзя сообщить вызывающему его коду о невозможности очистить ресурс. Поэтому классы типа Transaction - это напрасные потуги.

Да, тут RAII «не работает», но это проблема не именно в исключениях

Правильно, это проблема в дизайне цепепе :-)

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

О, к тебе приходит вменяемость :-) Так держать!

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

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

anonymous
()
Ответ на: комментарий от DarkEld3r

Да ладно? За тебя ГЦ проконтролирует и продлит время жизни, если надо. А в плюсах захватил что-то, оно сдохло - огребай проблем. Следствие низкоуровневости, опять же.

ГЦ - это ГЦ. Прекрасно, что он выполняет свою работу, и я о ней знаю. Но себя то я контролирую :-)

Хочешь сказать, что комментарии будут короче одного ключевого слова? Самому не смешно-то? Опять же, так не получится случайно обратиться к «закрытым» данным/функциям.

Хочу сказать, что ваша братия полная противочений. Одни заявляют, что на цепепе даёт максимум свободы, другие заявляют про случайное обращение к закрытым данным, а потому, надо защищать себя от себя :-) Странные какие-то :-)

Только не надо опять заводить песню как у С++ плохо с ИДЕ. Да, не идеально, но многое работает.

Да какие там IDE, в самом деле? :-)

В лиспе вон тоже свои «проблемы» есть. Скажем, методы зовутся не через точку, так что с автодополнением сложнее. И да, я в курсе про мультиметоды, так что понимаю, что за фичи надо платить.

Ну а здесь ты погорячился, потому что с автодополнением в лиспе всё супер. Лисп вообще самодокументируемый язык с полным отсутствием синтаксиса и прямой семантикой, что способствует созданию первоклассных IDE. Потому не надо мне рассказывать сказки про точечки, методы и мультиметоды :-)

anonymous
()
Ответ на: комментарий от anonymous

Поэтому классы типа Transaction - это напрасные потуги.

Напрасные потуги на что? Классы типа Transaction позволяют писать нормальный код для работы с СУБД. Правда, они не зовут, как у вас, commit в деструкторе, только rollback.

Но вас уже попросили представить тот вариант Transaction, который вам представляется нормальным. Сможете?

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от DarkEld3r

Нет.

На нет и суда нет. Для освобождения удалённых ресурсов деструкторы неприемлемы, и точка. (Иначе, твои библиотеки вменяемый пипл будет обходить стороной.) Деструкторы годятся только для вызова delete, или для уменьшения всяких счётчиков, типа счётчиков ссылок. Генерировать другие побочные эффекты, которые могут повлечь исключения в деструкторах, делается или от безисходности (авось, пронесёт), или от слабоумия :-)

anonymous
()
Ответ на: комментарий от anonymous

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

Ну так явите миру пример спасительной альтернативы!

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Классы типа Transaction позволяют писать нормальный код для работы с СУБД. Правда, они не зовут, как у вас, commit в деструкторе, только rollback.

Ну и как такие классы, что позволяют писать «нормальный код для работы с СУБД» поведут себя, если при отправки ROLLBACK произойдёт ошибка? Как они опять же оповестят вызывающего, что произошла ошибка? Здесь нет решения, тупик. :-)

anonymous
()
Ответ на: комментарий от eao197

Но вас уже попросили представить тот вариант Transaction, который вам представляется нормальным. Сможете?

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

anonymous
()
Ответ на: комментарий от anonymous

Ну и как такие классы, что позволяют писать «нормальный код для работы с СУБД» поведут себя, если при отправки ROLLBACK произойдёт ошибка?

Проглотят это исключение, т.к. оно происходит на том пути программы, когда это исключение никому не интересно.

Как они опять же оповестят вызывающего, что произошла ошибка?

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

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

Т.е. вы вообще пишете без исключений, все на кодах ошибки?

А в лиспе я просто отложу транзакцию, а когда сервер проснётся, то рестартну её коммит. :-)

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

Нужно. И 20 лет назад, и сегодня. И именно на низкоуровневых языках. Потому что прекрасные и идеальные всемогуторы, к сожалению, все ещё очень часто непригодны для решения фактических прикладных задач.

crystax
() автор топика
Ответ на: комментарий от eao197

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

А как же свобода, которую даёт цепепе? А как дух «вы не должны платить за то, что не требуете»? Как это разработчик библиотеки цепепе смеет решать, что ему будет интересно, а что - нет? :-) Ну а если серьёзно, то причин, по которым невозможно выполнить ROLLBACK может быть масса. И «проглатывать» эту ошибку является абсолютно неверным решением разработчика библиотеки. Я такой либой пользоваться бы не стал :-)

Т.е. вы вообще пишете без исключений, все на кодах ошибки?

Почему же, по-разному. :-)

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

Смайлик вообще везде уместен, т.к. приложение может умереть даже в момент отправки ROLLBACK из деструктора. Оно вообще может умереть в любой момент, особенно, если написано на цепепе :-) Мораль - это проблемы приложения, куда сохранить отложенную транзакцию, и сохранять ли на случай краха :-)

anonymous
()
Ответ на: комментарий от crystax

Нужно. И 20 лет назад, и сегодня. И именно на низкоуровневых языках. Потому что прекрасные и идеальные всемогуторы, к сожалению, все ещё очень часто непригодны для решения фактических прикладных задач.

Когда это действительно нужно, то лучше взять чистый Си (желательно, Си11) и заниматься низкоуровневым программированием, без всяких деструкторов и исключений, которые только мешают этому самому низкоуровневому программированию :-)

anonymous
()
Ответ на: комментарий от anonymous

Ну а если серьёзно, то причин, по которым невозможно выполнить ROLLBACK может быть масса.

Для ценителей таких ошибок у Transaction может быть два метода: commit и rollback, выпускающих наружу исключения. И деструктор, который зовет rollback, если не был вызван commit. Только в деструкторе все исключения из rollback-а проглатываются. Т.к. сам факт вызова rollback в деструкторе показывает, что пользователю Transaction эти ошибки не интересны. Он мог вызвать rollback явно, если ему эти ошибки нужны. Либо же деструктор вызван из-за раскрутки стека при наличии другого исключения.

При этом вызов rollback-а — это в прямом смысле слова очистка ресурсов, в первую очередь на стороне СУБД. Если rollback до сервера по какой-то причине не дошел (обрыв связи, скажем), то сервер сам откатит транзакцию по тайм-ауту или при обнаружении этого разрыва на своей стороне. Если rollback до сервера дошел, то какие-то другие ошибки в процессе выполнения rollback-а уже можно игнорировать.

Почему же, по-разному. :-)

Ну хорошо, покажите, как вы в присутствии и кодов ошибок, и исключений перепишете вот такой фрагмент C++ного кода (если вам не нравится проглатывание исключений rollback-а в деструкторе Transaction):

void some_controller::save_state()
{
  Transaction trx{ db_connection() };
  save_history();
  save_current_state();
  save_config();
  trx.commit();
}
Где внутри каждого save_* может быть множество операций с БД и много источников для выбрасывания исключений.

Мораль - это проблемы приложения, куда сохранить отложенную транзакцию

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

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

crystax
() автор топика
Ответ на: комментарий от eao197

При этом вызов rollback-а — это в прямом смысле слова очистка ресурсов, в первую очередь на стороне СУБД. Если rollback до сервера по какой-то причине не дошел (обрыв связи, скажем), то сервер сам откатит транзакцию по тайм-ауту или при обнаружении этого разрыва на своей стороне. Если rollback до сервера дошел, то какие-то другие ошибки в процессе выполнения rollback-а уже можно игнорировать.

В обоих случаях у вызывающего должна быть информация о том, что же произошло при вызове ROLLBACK. Как бы ты не изворачивался, а подавление информации, которая никак не может быть передана пользователю из деструктора, является костыльным подходом, ибо налицо потеря информации. Да не пытайся ты доказать, что деструкторы пригодны для таких задач. Бесполезно это. Не пригодны они. Только прямой вызов COMMIT/ROLLBACK и обработка кода ошибки. :-)

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

Нечего там показывать. Ну генерируются исключения из любой ф-ии, и что? Потери информации нет - отловил исключение и делай что хочешь. А класс Transaction в данном коде как не пришей кобыле хвост, ибо можно было написать что-нибудь вроде:

exec("BEGIN");
// работа
IF_ERROR(exec("COMMIT") : exec("ROLLBACK")) { // о ужас, это макрос!!11 Страуструп в шоке!
  // обработка локальной переменной code
}

А то получается, что во время on-line обработки транзакции у вас возникает исключение на Rollback-е и вы замораживаете обработку транзакции на неопределенный срок.

Не на rollbacke, а на commite.

И что делать инициатору операции все это время?

Фигня вопрос. :-)

anonymous
()
Ответ на: комментарий от anonymous

Вот такой код понятнее

exec("BEGIN");
// работа, результат которой в перем. ok
IF_ERROR(ok ? exec("COMMIT") : exec("ROLLBACK")) { // о ужас, это макрос!!11 Страуструп в шоке!
  // обработка локальной переменной code
}

anonymous
()
Ответ на: комментарий от anonymous

Любезнейший, когда вы общаетесь в таком духе, вы на что рассчитываете? Что вас посчитают адекватным разработчиком?

Вас попросили показать решение. Вы написали какой-то бред. Как в тексте, так и в примере кода.

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Вас попросили показать решение. Вы написали какой-то бред. Как в тексте, так и в примере кода.

Что же ты не комментируешь мой бредовый код? Неужто ты не понял, что там написано? А там действительно муть, потому что приведённый код на цепепе может семантически означать что угодно. А как ты хотел, это же цепепе и его прекрасная семантика :-) Чтобы ты меня понял, приведу др. код:

void f() {
  IF_ERROR(exec("BEGIN")) {
    // марка раскрывается в
    // const auto code = exec("BEGIN")
    // if (auto err = exec("BEGIN")) {
    //   // обработка объекта ошибки err
    //   // перем. err доступна тут
    // }
  }

  try {
    // какая-та твоя муть на функциях с исключениями
  } catch (Db_err& e) {
    // ...
  }

  // END - это COMMIT или ROLLBACK, см. стандарт SQL
  IF_ERROR(exec("END")) {
    // обработка ошибки, если есть
  }

Это нагляднее, проще для понимания и сопровождения. Кроме того, часто бывает нужно обработать одно и то же исключение по-разному, в зависимости от контекста. Т.е. сгруппировать исключения в одном блоке catch (Some_error& e) не получится, и придётся городить ублюдочный код:

try {
  f(); // генерирует E1
  g(); // генерирует E1
} catch (E1& e) {
  // упс, какая ф-я сгенерировала E1?
}

// придётся городить

try {
  f();
catch (E1& e) {
  // обработка для f()
}

try {
  g(); // генерирует E1
} catch (E1& e) {
  // обработка для g()
}

Лучше уж

auto r = f();
IF_ERROR(r) {
}

auto q = g();
IF_ERROR(q) {
}

Не мудрено, что исключения не используются в Qt - чуть ли не единственной адекватной библиотеке для цепепе. :-)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.