Эта функция будет вызвана ВСЕГДА, когда класс разрушается.
Во-первых, не класс, а объект класса. Во-вторых, новичкам, на которых якобы ориентирован пост, не всегда и очевидно, когда объект на самом деле «разрушается», об этом дальше.
Не важно что произошло, выход из функции посередине или даже выброшенное исключение, деструктор класса будет вызван в любом случае, пока программа работает.
Ну вот например так:
Class* object = new Class();
throw std::bad_alloc();
delete object;
Да, утечка объекта, но в тексте выше ничего не сказано о том, что речь-то идет только об автоматических переменных, а «разрушаются» они при выходе из области видимости.
На C деструктор вызывается вручную, что заставляет писать много лишних подробностей.
Печально, когда в качестве агрументов в пользу Git приводятся отсутствие необходимости делать «check out» и легкая установка на Ubuntu (есть подозрение, что Subversion тоже обладает вторым свойством, а первым точно обладает). Гораздо полезнее, что это система без центрального репозитория со всеми вытекающими отсюда достоинствами.
Хорошо, сочленения, находящиеся на штанге, таким образом какое-то время не были в поле зрения камеры. Но почему исчезло место крепления штанги к корпусу марсохода?
Раз уж поднята эта тема, я не понимаю, почему не видно штангу, на которой крепится выносная камера. Результат ретуши при склейке или какая-то другая причина?
Нет, это слово дополняет предыдущее. Логика примерно такая: благодаря облакам теперь с «большими данными» наконец-то можно многое сделать.
В презентациях обычно рассказывают ужасы о том, сколько петабайт данных повсюду генерируется в единицу времени, как объем данных удваивается каждые сколько-то лет или месяцев, и как бы подразумевается, что это все нужно непременно обрабатывать. В прежние времена проблема решалась игнорированием тех данных, которые обработать не успевают, а теперь, посколько провайдерам облаков нужно кому-то продавать ресурсы, таким образом создается потребность в облачных вычислениях.
Рассмотрим, например, std::vector. Когда он разрушается или из него удаляются элементы, для этих элементов вызываются деструкторы, скорее всего, для этого используется цикл. Очевидно, если элементы такого типа, что у них деструкторы тривиальны, то деструкторы вызывать не нужно и цикл как таковой тоже не нужен. Способность компилятора удалять мертвый код позволит вам просто написать этот цикл и расчитывать на то, что компилятор в каждом конкретном случае сможет правильно решить, нужен этот цикл или нет.
Этот вызывающий вопросы кусок поста написан в предположении, что в случае, когда компилятор точно знает, что этот указатель указывает на данные, которые не объявлены volatile, он имеет право считать их не volatile.
Не перестала, вопрос в том, где говорится, что использование указателя на volatile для доступа к данным, которые не объявлены как volatile, требует обращения такого же обращения с этими данными, как будто они объявлены volatile.
В этом случае, естественно, компилятор не видит устройство вызываемого кода при компиляции вызывающей стороны. Я имел в виду, например, случай, когда вызываемый код находится в статической библиотеке, которая скомпилирована с LTCG.
Перезапись нулями — очень простой кусок машинного кода, компилятор вполне может его встроить по месту и еще оптимизировать с окружающим кодом. Опять же перезаписаь может выполняться как ради перезаписи, так и ради инициализации и придется анализировать много случаев.
Перезапись чем-то нетривиальным может быть выявить проще, потому что она делается сложнее и реже и благодаря этому соответствующий ей шаблон проще искать.
Откуда такая трактовка? Пусть через указатель, но мы меняем именно данные с квалификатором volatile, соответственно это должно быть наблюдаемое поведение.
Такая трактовка от того, что после очень тщательных поисков мне так и не удалось найти, где именно Стандарт гарантирует доступ к не-volatile данным через указатель на volatile.
Обратите внимание, я буду рад оказаться неправым в этой части поста, потому что это будет означать, что использование указателей на volatile — просто идеальное решение рассмотренной изначальной проблемы.
Более того тогда как трактуется «volatile char[100] a»?
Visual C++ трактует это как синтаксически неверный код. Видимо, вы имели в виду что-то другое.
Во-первых, не класс, а объект класса. Во-вторых, новичкам, на которых якобы ориентирован пост, не всегда и очевидно, когда объект на самом деле «разрушается», об этом дальше.
Ну вот например так:
Да, утечка объекта, но в тексте выше ничего не сказано о том, что речь-то идет только об автоматических переменных, а «разрушаются» они при выходе из области видимости.
В C нет деструкторов.
В презентациях обычно рассказывают ужасы о том, сколько петабайт данных повсюду генерируется в единицу времени, как объем данных удваивается каждые сколько-то лет или месяцев, и как бы подразумевается, что это все нужно непременно обрабатывать. В прежние времена проблема решалась игнорированием тех данных, которые обработать не успевают, а теперь, посколько провайдерам облаков нужно кому-то продавать ресурсы, таким образом создается потребность в облачных вычислениях.
Перезапись нулями — очень простой кусок машинного кода, компилятор вполне может его встроить по месту и еще оптимизировать с окружающим кодом. Опять же перезаписаь может выполняться как ради перезаписи, так и ради инициализации и придется анализировать много случаев.
Перезапись чем-то нетривиальным может быть выявить проще, потому что она делается сложнее и реже и благодаря этому соответствующий ей шаблон проще искать.
Может при использовании LTCG или ее аналогов.
Такая трактовка от того, что после очень тщательных поисков мне так и не удалось найти, где именно Стандарт гарантирует доступ к не-volatile данным через указатель на volatile.
Обратите внимание, я буду рад оказаться неправым в этой части поста, потому что это будет означать, что использование указателей на volatile — просто идеальное решение рассмотренной изначальной проблемы.
Visual C++ трактует это как синтаксически неверный код. Видимо, вы имели в виду что-то другое.