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

То есть нужно модифицировать классы или использовать доп. обёртки с лямбдами?

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

Но идёт прикольная, нужно будет опробовать. Никогда такую реализацию не видел.

Знал же, что нет смысла отвечать анониму...

Как так? У x86 4 байта же.

Машинное слово в 16-битном (реальном) режиме имеет размер 16 бит. Размер int зависит от компилятора, но те компиляторы, которые я видел, имели 16-битный int.

только нужно помнить, что rollback тоже бывает валится, и даже (о боже!) может кинуть эксэпшн с последующим «упс!».

хм. прости, но я не понял, как связаны отказ от гроздьев catch и автоматические вызовы деструкторов (откаты) при выходе из области видимости. т.е то, что ненужно делать delete p; и обработка самого исключения.

возможно, пример слишком банальный.

Ну и я говорю, что как же ты определил то, ты ошибся или опечатка в названии функции которую ты вызываешь? Скопировал название да дальше пошёл. Пусть живут годами, если не у кого руки не доходят сделать refactor -> rename для кода - значит никому не мешает. Надуманная проблема, по-моему.

Не пойму о каком конкретно x86 идёт речь. Если про старые, 16-и битные, то ок, но современные же 32-х битные.

Или мы всё ещё о 8086/i286?

но современные же 32-х битные.

Даже современные x86 запускаются в реальном режиме.

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

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

но это не проблема IDE

Нет, это проблема, которая может возникать при использовании IDE.

Я всегда настраиваю на 1 секунду

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

Ок, зайдём с другой стороны. Если я запущу прогу с sizeof(int) собранную gcc/clang - она выдаст 4 или 2?

То есть вы сами создали себе проблему

То есть простив «школоло и с IDE вообще не знаком» возражений нет? Ок, так и запишем. Дальше разговаривать не вижу смысла.

http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/random_r.c;hb=glibc-2....

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

А смысл мне реагировать не бессмысленные наезды?

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

сам-то понял что написал?

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

она выдаст 4 или 2?

Любое число не меньше 1. И даже на x86-64 имеет право быть 2.

http://www.boost.org/doc/libs/1_64_0/libs/exception/doc/exception.html

Вы бы хоть читали документацию на то, что приводите: http://www.boost.org/doc/libs/1_64_0/libs/exception/doc/frequently_asked_ques....

Why doesn't boost::exception derive from std::exception?

Despite that virtual inheritance should be used in deriving from base exception types, quite often exception types (including the ones defined in the standard library) don't derive from std::exception virtually.

If boost::exception derives from std::exception, using the enable_error_info function with such user-defined types would introduce dangerous ambiguity which would break all catch(std::exception &) statements.

Of course, boost::exception should not be used to replace std::exception as a base type in exception type hierarchies. Instead, it should be included as a virtual base, in addition to std::exception (which should probably also be derived virtually.)

https://developer.gnome.org/glibmm/stable/classGlib_1_1Exception.html

Ну от этих чего угодно можно ожидать. Особенно с учетом их возраста.

не меньше 2

https://en.wikipedia.org/wiki/C_data_types#Basic_types

INT_MIN

This is the minimum value that can be represented by a signed int. On most machines that the GNU C Library runs on, an int is a 32-bit quantity.

ключевое - «on most». а по какие там DSP портирован GCC - это в сорцы лезть нужно.

Так я об этом же, что обычно 4.

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

Тут, блин, все ходы записаны:

> В C++ конечно тоже можно напортачить с итераторами, но язык и стандартная библиотека минимизирует количество мест, в которых необходимы танцы с указателями.

Дважды лол

Вот это «дважды лол» после внимательного прочтения было написано, полагаю.

не меньше 2

Нет, не меньше 16 бит, а это не одно и то же.

Проблема в слове «обычно» в том, что оно не имеет никакого смысла, если писать библиотечный код.

А так не спорю - для большинства платформ общего назначения де-факто - 4 байта.

не меньше 2
https://en.wikipedia.org/wiki/C_data_types#Basic_types

ты читал что сам по ссылке скидываешь-то ? «it is at least 16 bits in size.» означает что может быть и 1

в очередной раз подтверждаешь что дебил

Ну от этих чего угодно можно ожидать. Особенно с учетом их возраста.

Красиво съехал, я понял. Хотя в чём-то ты прав. Нужно и у того класса базовым сделать std::exception.

Вот это «дважды лол» после внимательного прочтения было написано, полагаю.

Нет, конечно.

То есть нужно модифицировать классы или использовать доп. обёртки с лямбдами?

Похоже, здесь проще на примере конкретном показать. Допустим, у нас есть класс с двумя контейнерами внутри. И есть метод add_data(name, value). Нам нужно в add_data модифицировать оба контейнера. Например, что-то вроде:

void example::add_data(const string & name) {
  active_users_.push_back(name);
  user_appearances_[name] = current_timestamp();
}

Мы можем ничего с этим не делать. Ну возникнет, ну и останется example в неконсистентном состоянии. В каких-то задачах этого может быть достаточно.

Но, допустим, мы хотим сохранить консистентность example. Тогда у нас есть выбор. Либо написать так:

void example::add_data(const string & name) {
  active_users_.push_back(name);
  try {
    user_appearances_[name] = current_timestamp();
  }
  catch(...) {
    active_users_.pop_back();
    throw;
  }
}

class rollback_user_add {
  active_users_container & container_;
  bool commit_{false};
public :
  rollback_user_add(active_users_container & c) : container_{c} {}
  ~rollback_user_add() {
    if(!commit_)
      container_.pop_back();
  }
  void commit() { commit_ = true; }
};
void example::add_data(const string & name) {
  active_users_.push_back(name);
  rollback_user_add(active_users_);
  user_appearances_[name] = current_timestamp();
  rollback_user_add.commit();
}

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

void example::add_data(const string & name) {
  active_users_.push_back(name);
  do_with_rollback_on_exception( [&] {
      user_appearances_[name] = current_timestamp();
    },
    [&] { active_users_.pop_back(); });
  }
}

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

Это будет видно при первом же прогоне кода.

Красиво съехал, я понял.

Никуда не съезжал:

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

Этот glibmm наверняка возрастом постарше 20 лет будет. Тогда от std::exception не всегда можно было в принципе отнаследоваться. Но сейчас std::exception есть везде. И сложно найти библиотеку, которая бы появилась после 2000-го, но в которой собственные исключения никак не связаны с std::exception.

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

То, что ты тут показал (do_with_rollback_with_exception) на фоне лисповых макросов выглядит бледно :-) Современный цепепе, новомодный стандарт, а выглядит всё равно уныло :-)

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

То есть я бы такой код не написал бы изначально.

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

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

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

Если я запущу прогу с sizeof(int) собранную gcc/clang - она выдаст 4 или 2?

Не уверен, что GCC умеет производить исполняемые файлы под реальный режим. DJGPP использует расширитель, переводя процессор в защищённый режим.

Тот же Qt практически не использует исключений вообще.

Это да :-) Но пионэры то думают, что наличие класса QException говорит о том, что в Qt исключения во все поля :-)

Тот же Qt практически не использует исключений вообще.

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

Qt не новая библиотека. Она начала разрабатываться или в 1992-ом или в 1993-ем. Тогда std::exception в принципе не было.

Да, я об этом же. В общем случае - 4, но естественно по-стандарту может и не 4.

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

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

Это может потребовать доп. структур или даже временного вектора

Ну да, память не ресурс.

Когда вы не можете делать и модифицировать копии этих структур, какие у вас еще есть возможности?

Справедливости ради, Qt4 был написан с нуля и зарелизен в 2005-м. Но был построен на C++98.

Справедливости ради, Qt4 был написан с нуля и зарелизен в 2005-м.

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

У меня обычно нет таких жёстких требований.

Суть в том, что я предпочитаю явный if/? неявным исключениям. Это упрощает понимание кода.

Он вообще ничего общего с Qt3 не имеет. Вы путаете Qt4 и Qt5.

Он вообще ничего общего с Qt3 не имеет. Вы путаете Qt4 и Qt5.

Ну если вы посмотрите на документацию по QWidget для Qt3 и для Qt4, то найдете не так уж и мало пересечений.

Переход с Qt3 на Qt4 был непростым (в Qt4 даже некоторый слой совместимости был, емнип), но тотального переписывания кода не было.

Суть в том, что я предпочитаю явный if/? неявным исключениям. Это упрощает понимание кода.

Как минимум, отказ от исключений усложняет работу с классами. Вместо нормального подхода с конструкторами нужно использовать two phase init со всеми вытекающими прелестями.

Как минимум, отказ от исключений усложняет работу с классами.

То-то сам Страуструп признаётся в своей книге, что предпочитает работать с потоками (это которые streams) без использования исключений :-) Говорит, что с if получается понятнее :-) Ты, похоже, забыл, о чём писал создатель C++ :-) Лол :-)

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

А ещё лучше скачайте сорцы Qt3 и Qt4. У них нет ничего общего.

Всегда есть статические методы.

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

А если найду? size - size

pos - pos

isHidden - isHidden

И еще с десяток таких наберется.

А ещё лучше скачайте сорцы Qt3 и Qt4. У них нет ничего общего. Вообще.

Да вам верить — это себя не уважать. Проекты такого масштаба с нуля не переписываются. Вообще.

В общем случае - 4

В общем случае — ≥ 16 бит.

-- Петька, приборы?
-- 42!
-- Что «42»!
-- А что приборы?

Вот тоже самое про two phase init и «всегда есть статические методы».