Здравствуйте, IT, Вы писали:
K>>А const позволяет все закрыть и грамотно все спроектировать. Конечно щас кое кто возразит что можно заюзать const_cast? но это уже не мои проблеммы. Почему бы сразу не заюзать format c:? IT>Вот именно. Кто хочет тот добъётся. Так зачем тогда вообще всё это нужно?
А зачем тогда вобще типизация нужна? Назад к ассемблеру?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Kluev, Вы писали:
IT>>Грамотнее уже дальше некуда.
K>Уважаемый IT я не понимаю на что ты жалуешься? Если ты юзаешь в С++ const_cast это значит что ты изучил классцы и знаешь что делаешь.
Знаешь что ты только что сказал? Примерно следующее. У нас есть классная фича в виде const, но иногда она не работает, поэтому у нас есть const_cast, стандартное средство для обхода классной фичи, а по сути грязный стандартизированный хак, встроенный непосредственный язык.
K>В С# вася пупкин напишет immutable-proxy и прийдется только через рефлекшн лезть в обход private (еще хуже чем конст_каст).
Вася не будет этого делать. Если Васе очень будет это надо, то скорее всего он откажется от столь "грамотно всё спроектированного" и напишет свой велосипед, не столь "грамотно спроектированный", но делающий то, что ему надо.
K>Или самому все переписать и кататся на своих собственных велосипедах.
Вот-вот. Так обычно и происходит с черезчур "грамотным проектированием".
K>Проблема не в констах а в вася-пупкиных. Только в С++ проще — написал const и спи отдыхай. А в С# прийдется пыхтеть для каждого класса readonly-прохор писать. Или вообще забить на константность. Только это тоже не выход. Забиваем на константноть потребуется писть доку: что можно, а что нельзя. Забиваем на доку — нужен самодокументируемый внятный код. Иными словами троерожный бес — как не кинь всегда рогом вверх.А const позволяет все закрыть и грамотно все спроектировать.
Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
K>>Уважаемый IT я не понимаю на что ты жалуешься? Если ты юзаешь в С++ const_cast это значит что ты изучил классцы и знаешь что делаешь. IT>Знаешь что ты только что сказал? Примерно следующее. У нас есть классная фича в виде const, но иногда она не работает, поэтому у нас есть const_cast, стандартное средство для обхода классной фичи, а по сути грязный стандартизированный хак, встроенный непосредственный язык.
const_cast это такойже грязный хак как добираться до приватных методов через рефлекшен.
У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
IT>Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast.
Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>const_cast это такойже грязный хак как добираться до приватных методов через рефлекшен. WH>У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
Только почему-то эту мегафичу хотят заиспользовать в основном те, кто раньше жить не мог без const_cast. Странное совпадение.
IT>>Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast. WH>Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
Я уже три года пишу под .NET, а до этого с 88 по 2003 писал на C/C++ и всегда использовал const как завещал великий Страуструп. Но что забавно, под .NET я великолепно обхожусь без const и его отсутствие мне не досаждает. А вот на плюсах доводилось периодически материться. А так как я человек, не ищущий приключений на свою задницу в виде рефлекшинов и const_cast, то чаще всего приходилось выпиливать свои велосипеды.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, c-smile, Вы писали:
CS>Я правильно тебя понял? CS>Или я неправильно тебя понял?
Да
const очень неоднозначная конструкция. И очень часто решая одну проблему, порождает массу дргих. Соответствовать доказывать её экстраординарность глупо. Именно это я и хотел сказать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ты это расскажи всё тем кто пишет и использует .NET Framework. Расскажи им, что они все лохи, потому что не используют const и, главное, потом не обходят его с помощью const_cast.
Незнаю, но от readonly для внутренних переменных и содержимого массива я бы не отказался. Хотя конечно товарищи пропагандирующие const явно преувеличивают его необходимость.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
Оно, кстати, защитой регулируется. Настрой палитику и фига два ты доберешся до скрытых членов.
WH>Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
Ты явно преувеличиваешь. Да и ключевое слово const тут не очень уместно. Но readonly для локальных переменных и содержимого массивов было бы поиметь очень приятно. Тут я с тобой согласен. Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах) и для инкапсуяции части реализации класса. Но это все же не так критично как тут пояют артодоксальные плюсовики.
WH>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения.
Зато это намного более надежное решение, и как следсвие лучший дизайн.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Я правильно тебя понял? CS>>Или я неправильно тебя понял?
IT>Да
IT>const очень неоднозначная конструкция. И очень часто решая одну проблему, порождает массу дргих. Соответствовать доказывать её экстраординарность глупо. Именно это я и хотел сказать.
То что const не решает каких-то проблем известно.
В начальном послании я хотел узнать альтернативы. Они есть?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
WH>>У нас в .НЕТ есть такая мегафича как модификаторы доступа но иногда она не работает потомучто у нас есть стандартное средство для ее обхода.
VD>Оно, кстати, защитой регулируется. Настрой палитику и фига два ты доберешся до скрытых членов.
WH>>Я почти год пишу практически только под .НЕТ и могу сказать что авторы .НЕТ сильно облажались не введя модификатор const(с этим даже Влад согласен).
VD>Ты явно преувеличиваешь. Да и ключевое слово const тут не очень уместно. Но readonly для локальных переменных и содержимого массивов было бы поиметь очень приятно. Тут я с тобой согласен. Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах) и для инкапсуяции части реализации класса. Но это все же не так критично как тут пояют артодоксальные плюсовики.
WH>>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения.
VD>Зато это намного более надежное решение, и как следсвие лучший дизайн.
В ответ на
VD>Как меня раздражает эта твоя "импелементации"... если бы ты знал.
Спешу заверить в аналогичном:
Ортодоксальные, и политику, доберешься ... и так далее
Здравствуйте, c-smile, Вы писали:
CS>То что const не решает каких-то проблем известно. CS>В начальном послании я хотел узнать альтернативы. Они есть?
Не знаю Хотя... Например, в .NET строчку нельзя изменить. Нельзя! Вообще никак. Любые манипуляции над строкой всегда возвращают новый экземпляр. Поначалу напрягало, такие вещи воспринимались как дикость:
string s = "111";
s[1] = '2'; // error CS0200: Property or indexer 'string.this[int]' cannot be assigned to -- it is read only
Особенно в голову лезли всякие дурацкие мысли о производительности.
Сейчас как дикостью воспринимается обратная ситуация.
CS>В любом случасе спасибо за участие.
Дык, you are welcome!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах)
internal — редкостная дрянь, впрочем не на много хуже чем friend в плюсах.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Незнаю, но от readonly для внутренних переменных
А чем свойства не устраивают?
VD>и содержимого массива я бы не отказался. Хотя конечно товарищи пропагандирующие const явно преувеличивают его необходимость.
А как в строке сделан индексер?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Знаешь что ты только что сказал? Примерно следующее. У нас есть классная фича в виде const, но иногда она не работает, поэтому у нас есть const_cast, стандартное средство для обхода классной фичи, а по сути грязный стандартизированный хак, встроенный непосредственный язык.
Во первых в этом несовершенном мире не может быть совершенных решений. Поэтому у const есть и достоинства и недостатки. Лично мне конст помогает избежать многих ошибок: имеешь read-only доступ к агрегатам класса, а модификация только через обьект владелец (пример я уже приводил). А "грязный хак" const_cast мне приходилось использовать всего два раза. Так то я не вижу никаких проблем и считаю критику конст необоснованой.
З.Ы. То что const нет в шарпе еще не повод его критиковать. Я вот попробовал на шарп перелезть и оказалось, что для меня он не подходит совершенно.Для моих задач основной тип данных — интрузивные списки, а шарп для их реализации может только copy-paste предложить. Т.к. интрузивные списки — это тот редкий случай когда нужно либо множественное наследование либо указатели на члены.
Здравствуйте, IT, Вы писали:
IT>Только почему-то эту мегафичу хотят заиспользовать в основном те, кто раньше жить не мог без const_cast. Странное совпадение.
Я почемуто прекрасно обходился без const_cast. Что я делал не так?
IT>Я уже три года пишу под .NET, а до этого с 88 по 2003 писал на C/C++ и всегда использовал const как завещал великий Страуструп. Но что забавно, под .NET я великолепно обхожусь без const и его отсутствие мне не досаждает. А вот на плюсах доводилось периодически материться. А так как я человек, не ищущий приключений на свою задницу в виде рефлекшинов и const_cast, то чаще всего приходилось выпиливать свои велосипеды.
В С++ с const у меня ниразу небыло проблем. А под .НЕТ я уже несколько раз матерился из-за того что мне на ровном месте приходилось писать immutable proxy там где в С++ я просто напсал бы const.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
WH>>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок. Причем если в С++ это встроено в язык и не вызывает накладных расходов во в .НЕТ мне пришлось повозиться и смириться с мение понятным кодом который жрал ресурсы во время исполнения. VD>Зато это намного более надежное решение, и как следсвие лучший дизайн.
Когда я в С++ помечаю методы модификатором const я фактически описываю интерфейс класса который содержит методы которые не могут менять содержимое класса.
Те примерно так
C++
Итого: В С++ мы имеем поддержку языка что позволяет не писать дополнительных интерфейсов, правильность реализации константных методов контролирует компилятор...
А теперь объясни с какого перепугу решение на C# болие надежно?
Короче const рулит. Никаких аргументов против я до сих пор не услышал.
Единственное что смогли придумать это то что некоторые несознательные личности ставят const не там где он нужен. Но дело в том что таже проблема есть у модификаторов доступа и следуя этой логике нужно отменить private, protected, internal... оставляем все public и радуемся жизни
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>А чем свойства не устраивают?
Под "внутренними" я понимаю "локальные" переменные и параметры.
Кстати, readonly не устраивает тем, что оно защищает переменную. В случае ссылки на массив оно не работет. Даже вводит в заблуждение:
class A
{
readonly int[] _array = new int[] { 1, 2 };
public void X()
{
_array[0] = 123; // OK :(
}
}
IT>А как в строке сделан индексер?
Я как бы не против ООП-зашиты и все такое. Но расширенная семантика readonly явно каши не испортила бы.
Кстати, я бы еще ввел понятие immutable-класса. Чтобы контроль таких классов как string осуществлялся бы не разработчиком, а компилятором. А то ведь ничего не стоит по шибке залепить модифицирующий метод. Во втором фрэймворке ввели static-классы. Почему бы был не ввести immutable-классы?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>То что const не решает каких-то проблем известно. CS>>В начальном послании я хотел узнать альтернативы. Они есть?
IT>Не знаю Хотя... Например, в .NET строчку нельзя изменить. Нельзя! Вообще никак. Любые манипуляции над строкой всегда возвращают новый экземпляр. Поначалу напрягало, такие вещи воспринимались как дикость:
IT>
IT>string s = "111";
IT>s[1] = '2'; // error CS0200: Property or indexer 'string.this[int]' cannot be assigned to -- it is read only
IT>
IT>Особенно в голову лезли всякие дурацкие мысли о производительности.
IT>Сейчас как дикостью воспринимается обратная ситуация.
А если так?:
s[1] = '2';
s[2] = '3';
s[3] = '4';
Создастся три строки? Если нет то как это сделано?
reference counting?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>c-smile,
>> IT>
>> IT>string s = "111";
>> IT>s[1] = '2'; // error CS0200: Property or indexer 'string.this[int]' cannot be assigned to -- it is read only
>> IT>
>> IT>Особенно в голову лезли всякие дурацкие мысли о производительности. >> IT>Сейчас как дикостью воспринимается обратная ситуация.
>> А если так?: >>
>> s[1] = '2';
>> s[2] = '3';
>> s[3] = '4';
>>
>> Создастся три строки?
ПК>Нет, это просто не скомпилируется: содержимое объекта System::String менять нельзя.
Mea culpa, проглядел комментарий
Да и знаю же сам про StringBuffer/Builder...
).
Если нам не помогут, то мы тоже никого не пощадим.
