Если изменение объекта константы является неопределенным поведением тогда, как конструкторы и деструкторы действуют с доступом для записи?

Вот способ, которым игнорирование стандарта может привести к неправильному поведению. Рассмотрим ситуацию, подобную этой:

class Value
{
    int value;

public: 
    value(int initial_value = 0)
        : value(initial_value)
    {
    }

    void set(int new_value)
    {
        value = new_value;
    }

    int get() const
    {
        return value;
    }
}

void cheat(const Value &v);

int doit()
{
    const Value v(5);

    cheat(v);

    return v.get();
}

При оптимизации компилятор знает, что v является константой, поэтому может заменить вызов v.get () на 5 .

Но, скажем, в другой единице перевода вы определили cheat () следующим образом:

void cheat(const Value &cv)
{
     Value &v = const_cast<Value &>(cv);
     v.set(v.get() + 2);
}

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

вот как я его использую:

function customRange(input)
{
    var min = new Date();
    return {
        minDate: ((input.id == "txtStartDate") ? min : (input.id == "txtEndDate" ? $("#txtStartDate").datepicker("getDate") : null)),
        maxDate: (input.id == "txtStartDate" ? $("#txtEndDate").datepicker("getDate") : null)
    };
}

Подробнее о том, что сказал Джерри Коффин: стандарт делает доступ к объекту const неопределенным, только если этот доступ происходит в течение жизни объекта.

7,1,5,1/4:

За исключением того, что любой член класса, объявленный изменяемым (7,1,1), может быть изменен, любая попытка изменить объект const в течение его жизни (3,8) приводит к неопределенному поведению.

Время жизни объекта начинается только после завершения конструктора.

3,8/1:

Время жизни объекта типа T начинается, когда получается:

• место хранения с надлежащим выравниванием и размером для типа T, и
• , если T является типом класса с нетривиальным конструктором (12,1), вызов конструктора завершен.

В стандарте не очень много говорится о том, как реализация заставляет это работать, но основная идея довольно проста: const применяется к объекту, а не (обязательно) к памяти, в которой хранится объект. Поскольку ctor является частью того, что создает объект, он не является объектом до тех пор, пока (через некоторое время после) ctor не вернется. Аналогично, поскольку dtor принимает участие в уничтожении объекта, он также больше не работает с полным объектом.

Константность для определяемого пользователем типа отличается от константности для встроенного типа. Константность при использовании с пользовательскими типами называется "логической константностью". Компилятор следит за тем, чтобы на const-объекте (или указателе, или ссылке) можно было вызывать только функции-члены, объявленные как "const". Компилятор не может выделить объект в некоторой области памяти, доступной только для чтения, потому что non-const функции-члены должны иметь возможность изменять состояние объекта (и даже const функции-члены должны иметь такую возможность, если переменная-член объявлена mutable).

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