Что отличает юниора от более продвинутого

по факту eao197 один из немногочисленных людей на ЛОРе кто действительно знает C++

Да я понял, все остальные прикидываются. Но сам eao197 снизошёл и общается с холопами тут.

Да я понял, все остальные прикидываются. Но сам eao197 снизошёл и общается с холопами тут.

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

Список популярных архитектур, где int не 4 байта в студию (микроконтроллеры пропускаем).

Срачей на эту тему ни счесть. Там уже всё написано.

Можно разницу между этими понятиями. Ну так, в ознакомительных целях.

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

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

Это у тебя миссия такая? Нести правильный с++ в массы?

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

Да я понял, все остальные прикидываются. Но сам eao197 снизошёл и общается с холопами тут.

Предлагаю eao197 выдвинуть в комитет по стандартизации от ЛОРа :-) Глядишь, в стандарте появится акторный фрейморк и тогда цепепе зацветёт новыми красками и наступит новая эпоха программирования :-)

i286. Этого достаточно. Ну и этого достаточно, чтобы догадаться что и long - это не 8 байт. А там уже список архитектур и граблей шире.

Нюанс в том, что я не считаю себя спецом в C++. Просто мне приходится на нём писать, и это боль.

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

Это если сам ошибаешься в написании.

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

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

i286 и есть микроконтролер, о чём я упомянул.

Нюанс в том, что я не считаю себя спецом в C++. Просто мне приходится на нём писать, и это боль.

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

Это Turbo C++ под DOS (т.е. скорее архитектура 8086). Ну а про порочность подобных оценок уже упомянул. С long всё значительно интереснее.

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

Так он уже и так рассудил, что цепепе становится ненужным и уже пишет на Rust :-) Ему просто приходится писать на цепепе (пока) :-)

А как они должны использоваться? Где есть хорошее описание?

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

Вот простой пример:

Это неполный пример. В нем не хватает самого важного: что именно вы делаете в своих обработчиках исключений?

Поэтому и боль.

Ну вот в Java они есть, там работа с исключениями имеет свои причудливые формы. А в более свежих языках для JVM (Scala, Ceylon, Kotlin) от checked exceptions отказались.

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

В третьем издании, Женя :-) Стареешь? :-)

То есть проблема IDE в том, что вы её не используете?

у Страуструпа в C++ Programming Language

Читал. Не дочитал. Ибо уж очень тяжело заходит. А вот в гугле статеек почти нет толковых. Большинство просто не использует исключения, а остальные используют их как-то криво.

что именно вы делаете в своих обработчиках исключений?

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

Любители джавы-на-бекэнде советуют просто «падать» и перезапускать процесс. Но на десктопе это не прокатит.

Придраться не удалось? Жаль.

в смысле? это не 4 байта - это всё, что я хотел сказать.

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

Ты привёл лишь крайний случай. В общем же случае наличие виртуальных функций подразумевает классы с общим интерфейсом. Так же как и мой комментарий про указатели. Ибо в крайнем случае использовать их всё равно придётся.

ну вот например по этой теме можно сказать что тебе стоит подучить C++

А его постоянно учу.

чтобы общаться с ним хотя бы на равных

Нет, спасибо. Моё ЧСВ предпринимало попытки вырасти, но я решил, что лучше от этого не будет.

А его постоянно учу.

ты или тупой, или врешь :-)

Читал. Не дочитал.

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

А какая разница?

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

Исходить при наличии исключений нужно из того, что исключение может вылететь откуда угодно (кроме функций/методов, помеченных noexcept). Соответственно, код должен быть написан так, чтобы при появлении исключения обеспечивалась хотя бы базовая гарантия безопасности исключений. Это ведет к тому, что вместо того, чтобы писать гроздья catch-ей, внутри которых что-то делается, код представляет из себя последовательность создания RAII-объектов, в деструкторах которых откатываются сделанные ранее изменения.

Где-то сверху, где есть возможность рестартовать операцию или предпринять какое-то осмысленное действие, ловится только std::exception. Ну или еще пара-тройка хорошо известных исключений.

Сейчас, все-таки не 90-е годы, библиотеки, которые свои исключения не наследуют от std::exception еще нужно поискать.

ты или тупой, или врешь :-)

Да, я тупой. А ещё гей.

Ты привёл лишь крайний случай. В общем же случае наличие виртуальных функций подразумевает классы с общим интерфейсом. Так же как и мой комментарий про указатели. Ибо в крайнем случае использовать их всё равно придётся.

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

Зачастую - 4. Это то, что хотел сказать я.

Да. Если наплевательское отношение к коду это нормально, можно сказать, что проблема IDE в том, что мы её не используем.

Ты в основном пишешь код один, или в проектах участвует много людей?

Сейчас, все-таки не 90-е годы, библиотеки, которые свои исключения не наследуют от std::exception еще нужно поискать.

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

Список популярных архитектур, где int не 4 байта в студию

x86

В магазинах продаётся достаточно много ноутбуков и компьютеров с FreeDOS, а там int состоит из двух байт.

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

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

последовательность создания RAII-объектов, в деструкторах которых откатываются сделанные ранее изменения

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

в том, что вы её не используете?

При чём тут «не используете». Я например быстро набираю и мне бывает проще стразу набрать название, чем ждать автокомплит. Проблема имеет место быть, сам не раз напарывался - то букву не ту напишут, то местами переставят.

Перевожу. Крайний случай: наличие виртуальных функций у неполиморфных объектов.

У каждой библиотеки свой базовый класс для искюлчений.

Парочку примеров не затруднит?

кроме функций/методов, помеченных noexcept

Ибо прога просто упадёт. Я так наделся, что noexcept аналог @nogc из D. То есть проверка на этапе компиляции. А на деле - просто напоминание для программиста без каких-либо гарантий.

в деструкторах которых откатываются сделанные ранее изменения.

А откуда они знаю, что произошло исключение? Или я вас не так понял? Или «откат» это просто очистка памяти и подобное?

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

Да банальный make_unique из современного C++ в качестве примера. С ним у нас получается так:

void f() {
  auto p = std::make_unique<my_object>(...);
  ...
}

void f() {
  my_object * p = new my_object();
  try {
    ...
  }
  catch(...) {
    delete p;
    throw;
  }
}

В основном - один.

Ибо прога просто упадёт. Я так наделся, что noexcept аналог @nogc из D. То есть проверка на этапе компиляции. А на деле - просто напоминание для программиста без каких-либо гарантий.

ты не знаешь что такое noexcept

А откуда они знаю, что произошло исключение? Или я вас не так понял? Или «откат» это просто очистка памяти и подобное?

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

Как так? У x86 4 байта же. Или это у самого FreeDOS 2?

Перевожу. Крайний случай: наличие виртуальных функций у неполиморфных объектов.

Вы, явно, тупой. Это все про то, что std::vector<Derived> в C++ вовсе не всегда должен быть заменен на std::vector<Base*>. И далеко не всегда std::vector<Base*> должен использоваться вместо std::vector<Derived>.

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

чем ждать автокомплит

Может стоит использовать быструю IDE/нормальное железо?

Проблема имеет место быть

Я с этим и не спорю, но это не проблема IDE.

ты не знаешь что такое noexcept

Расскажите.

деструкторы вызываются при выходе из области видимости

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

Это банальный RAII. Исключения тут не при чём.

А на деле - просто напоминание для программиста без каких-либо гарантий.

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

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

Обычно это делается как-то так:

class rollback_changes_on_exception {
  bool commited_{false};
  ...
public :
  rollback_changes_on_exception(...) : ... {}
  ~rollback_changes_on_exception() {
    if(!commited_) {
      ... // Some rollback actions.
    }
  }
  void commit() { commited_ = true; }
};
...
void f() {
  ... // Do some changes.
  rollback_changes_on_exception rollbacker;
  ... // Some more actions.
  rollbacker.commit();
}

Расскажите.

ага, щас, сам прочтешь, не маленький

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

загугли uncaught_exception(s)

Парочку примеров не затруднит?

http://www.boost.org/doc/libs/1_64_0/libs/exception/doc/exception.html
https://developer.gnome.org/glibmm/stable/classGlib_1_1Exception.html

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

вообще говоря это скорее подсказка программиста компилятору

Это банальный RAII.

Да.

Исключения тут не при чём.

Еще как при чем.

В основном - один.

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

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

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