конечно нет толку, тем более для int. смысл есть в конструкциитолько она нереальна в C#. Смысл в том что я не хочу, при определенных условиях, давать возможность пользователям моего класса изменять содержимое объекта. 
Не тебе. А пользователю твоего класса, потому что не всегда проекты пишутся в одно лицо. 

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

И что-то я не нашел такого здесь: http://en.wikipedia.org/wiki/Const_correctness

P.S. 
int это был пример. не надо быть таким категоричным

Добавлено через 1 минуту и 14 секунд

А если не пометил, то что? Ее нельзя использовать? Требую пояснений.
(Прошу отнестись с пониманием. Я в плюсах не силен. И с такой фичей не сталкивался).

ну да, типа того. Только не должен помечать, а можешь - если хочешь. это синтаксис C++, помеченная таким образом функция говорит компилятору что содержимое объекта не будет изменено. Допустим у тебя есть класс контейнер. В нем находится мембер типа Закголовок. Пусть это будет какая-нибудь коллекция, описывающая заголовок таблицы.  Причем эта коллекция - самодостаточный класс, который может использоваться для других целей, абсолютно самостоятельно. Поэтому мы не хотим его специально переписывать для класса контейнера. Есть еще в классе контейнере сама таблица в виде какого-нибудь двумерного массива. Логичиски этот массив и заголовок связаны друг с другом. Одна из размернстей таблицы и размерность заголовка должну быть одинаковы. Если по С#-пному я открою доступ (пусть даже через ридонли свойство) к заголовку, пользователь моего класса сможет сделать заголовку какой-нибудь Clear() или Resize() и размерности перестану совпадать, и пойдут рантайм ошибки. Конечно это будут ошибки проектировщика, надо было предусмотреть такую фигню, но.. Если мы предоставим доступ к заголовку как константную ссылку, то компилятор не даст дергать эту ссылку за методы Clear() или Resize(), мы же их не пометили как const... и другой разработчик, который использует твой контейнер, не сможет навредить ему при всем желании, даже не удосужившись прочитать описание. Экономия времени по любому, тк не надо изыскивать красивые архитектурные решения, для обеспечения 100%-й инкапсуляции или заморачиваться на документацию, при отказе от полной реализации этой самой инкапсуляции... Ну как мог рассказал 

Добавлено через 9 минут и 3 секунды
в догонку
тогда появится смысл в конструкции 
 только опять же не int, а на основе вышесказанного что-то типа

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

Зато Вася Ламеров может спокойно удалить этот const (зачем он нужен, если компилятор на него раугается, а без него все ОК ;-)), компилятор все съест и поехало...

Нормально. Т.е. как я и думал.

 ну если в моем классе, мною созданный поток - я разработчик, то да.. я и дурак. А если другой товырисч извне - то фиг ему.. не выйдет. Разумеется все касаемо данной темы.
 а може забаится менят 

M mr.DUDA

Тема раскрыта полностью. Засим, во избежание дальнейших спекуляций, прикрываю её.