Допустим, есть некий класс и в зависимости от того, является ли экземпляр const или non-const у этого экземпляра либо нет реализации деструктора, либо она есть. Кто как решает подобную задачу?

egorych, есть необходимость изменить поведение экземпляра класса, когда он const, но если обычные методы можно сделать const и они будут вызываться только для const указателя/ссылки на объект, то конструкторы и деструкторы сделать const, разделив таким образом поведение при создании/разрушении, нельзя.

Вот я и спрашиваю - кто и как решал подобную задачу?

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

PS смотри в stl, там сделали отдельные классы для таких извращённых случаев, iterator и const_iterator как примерВ том-то и дело, что при инициализации константного объекта он может быть проинициализирован константными значениями без их копирования в кучу, т.е. ссылаться на них, а при разрушении, естественно, не должен пытаться очистить эти ресурсы. Совершенно не хочется проверять в деструкторе, где именно находится ресурс - в куче или в ресурсах бинарного модуля. По всей видимости, придётся как-то выкручиваться через спецификацию шаблона.

CEMbЕсли я всё правильно понял, конструкторы вызываются для константных и не константных объектов. Разница только в точке вызова.И точка вызова у них может быть одна и та же. Разница лишь в том, что при вызове константного метода ему прилетает константный this со всеми вытекающими.

blonduser, что мешает проверить?

Результат компиляции:

blonduserЭто происходит только в момент компиляции.Естественно! Где же еще? :)
Скомпилированный бинарный модуль не хранит информацию о спецификаторах. Ты же понимаешь, что доступ к любому члену экземпляра класса осуществляется по неявному указателю this, который можно указывать, а можно и не указывать в реализации метода, а доступ по константному указателю, это доступ read-only.

P.S. Кстати, попробуй в моём примере строку с ошибкой заменить на строку из комментария. ;)

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

MasterZivrdb_devДопустим, есть некий класс и в зависимости от того, является ли экземпляр const или non-const у этого экземпляра либо нет реализации деструктора, либо она есть. Кто как решает подобную задачу?

Ты неправ, деструктор у класса есть всегда, и он всегда вызывается.
Реализация при этом одна и та же.Я знаю, что деструктор есть всегда, поэтому и написал не "нет деструктора", а "нет реализации деструктора", имея в виду ~T() {}

blonduser, не дождешься!
С дедукцией не получается, а без неё выходит банальный exactly specialized template, который даже школьник напишет.

CEMbЭто разница - для компилятора . Код не различает const. Я думаю, компилятор при генерации отличает ctor/dtor-ы от остальных методов. Т.е. ты не сможешь сам его позвать явно (не скомпилируется).Я так и написал: 21428334

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

Ещё раз, при этом дифференцировать объекты по const|не const тебе придётся руками. Для упрощения можно ещё запрятать
создание экземпляров в фабрику.

P.S. да, задача идиотская, я согласен со всеми, кто так высказывался. Всё против объектной модели С++.Неа, объявить const конструктор не могу! Конструкторы и деструкторы не могут иметь cv квалификаторы.
В итоге получается два точно специализированных шаблона класса-обёртки (для const и не const) к интересующему классу, плюс typedef'ы для них. Вот так - банально и скучно. Нет возможности специализировать шаблон по объявлению lvalue.


Вообще, в C++ очень много "недосказанности". К примеру:
* Есть возможность "сказать" new const Type(), но нет возможности этот const хоть как-то "услышать" в реализации перегруженного оператора new, конструктора или деструктора класса;
* Есть возможность переопределить placement new, но компилятор не симулирует его вызов при определении экземпляра объекта на стеке, хотя, такое поведение было бы логичным;
* Можем специализировать шаблоны с дедукцией по параметрам конструктора, но не можем специализировать шаблоны с дедукцией по типу и квалификаторам объявления lvalue;