И снова про константность
От: chudo19  
Дата: 19.11.05 11:06
Оценка:
В который раз декларирую функцию и по привычке из C++ тянет const написать для параметра.
И каждый раз эта ментальная ломка.

Не помойму я. Не ужели построение NET не позволяет добавить это в копилятор?
Как мне кажется это ни как не затрагивает внутренности .NET, а лишь касается компилятора.
Да и можно зделать это чуть красивше чем в C++ — чтоб обойти было не возможно всякими кросскастами.
Или у создателей личная неприязнь к const?




28.11.05 08:04: Перенесено модератором из '.NET' — TK
Re: И снова про константность
От: GlebZ Россия  
Дата: 19.11.05 12:32
Оценка: 7 (2)
Здравствуйте, chudo19, Вы писали:

Если кратко, то:
Константный параметр
Автор: korzey
Дата: 07.07.05

Константность.
Автор: Sir Wiz
Дата: 07.10.04

все-таки не пойму... почему в CLR нет константных ссылок?
Автор: Дарней
Дата: 08.12.03

ПОЧЕМУ В C# НЕТ КОНСТАНТНЫХ АРГУМЕНТОВ
Автор: XRonos
Дата: 27.09.02

Исследование readonly
Автор: Dr_Sh0ck
Дата: 02.06.03


С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: И снова про константность
От: Nickolay Ch  
Дата: 19.11.05 13:44
Оценка: -3
C>В который раз декларирую функцию и по привычке из C++ тянет const написать для параметра.
C>И каждый раз эта ментальная ломка.

Управляемая среда после неуправляемой — это в любом случае ментальная ломка.

C>Не помойму я. Не ужели построение NET не позволяет добавить это в копилятор?

C>Как мне кажется это ни как не затрагивает внутренности .NET, а лишь касается компилятора.
C>Да и можно зделать это чуть красивше чем в C++ — чтоб обойти было не возможно всякими кросскастами.
C>Или у создателей личная неприязнь к const?

Уже был хороший ответ с подборкой ссылок, но если коротко — то этот параметр лишний.
Re[2]: И снова про константность
От: chudo19  
Дата: 19.11.05 15:56
Оценка: +1 -1 :)
Здравствуйте, Nickolay Ch, Вы писали:


NC>Уже был хороший ответ с подборкой ссылок, но если коротко — то этот параметр лишний.

Читал я все это.
Как это лишний!?

Тогда как запретить модификацию дочернего объекта возвращаемого через проперти?
Только не надо насчет создания readonly интерфейсов.
это во первых не всегда возможно,во вторых очень убого и каряво если начать на каждый обект огород городить.
Re: И снова про константность
От: Аноним  
Дата: 20.11.05 01:48
Оценка: +3 :)
Здравствуйте, chudo19, Вы писали:


C>Или у создателей личная неприязнь к const?


Наверное. Если взять доступные С++ исходники от МS (MFC, ATL, MSDN samples) — const для парметров (кроме copy constructors and assignment operators) и функций-членов практ. не используется. Может у них запрещено? Да и вообще, только в ATL можно действительно "настоящий" С++ местами увидеть, остальное, IMHO, больше похоже на "первые шаги С программиста в С++".
Re[3]: И снова про константность
От: Codechanger Россия  
Дата: 20.11.05 09:39
Оценка:
Здравствуйте, chudo19, Вы писали:

C>Здравствуйте, Nickolay Ch, Вы писали:



NC>>Уже был хороший ответ с подборкой ссылок, но если коротко — то этот параметр лишний.

C>Читал я все это.
C>Как это лишний!?

C>Тогда как запретить модификацию дочернего объекта возвращаемого через проперти?

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

Ну как, как запретить... СОздать проперти, у которой метод set не реализовывать.
Re[4]: И снова про константность
От: IDecember Россия  
Дата: 21.11.05 07:01
Оценка:
Здравствуйте, Codechanger, Вы писали:

C>Ну как, как запретить... СОздать проперти, у которой метод set не реализовывать.


А так?

using System;
using System.Collections;

class Program
{
    [STAThread]
    static void Main(string[] args)
    {
        Test t = new Test();
        Console.WriteLine(t.Bar[0]);
        t.Bar[0] = 7777777;
        Console.WriteLine(t.Bar[0]);
    }
}

class Test
{
    private ArrayList bar;

    public Test()
    {
        this.bar = new ArrayList();
        for(int i = 0; i < 5; i++)
        {
            this.bar.Add(i);
        }
    }

    public ArrayList Bar
    {
        get
        {
            return this.bar;
        }
    }
}
Re: И снова про константность
От: chudo19  
Дата: 21.11.05 18:06
Оценка: :)
Предлагаю начать собирать подписи. Авось их проймет.
Re[2]: И снова про константность
От: GlebZ Россия  
Дата: 21.11.05 19:06
Оценка: +1
Здравствуйте, chudo19, Вы писали:

C>Предлагаю начать собирать подписи. Авось их проймет.

Собирать подписи легко. А теперь представь себе что у тебя есть несколько языков. Ну например тот-же паскаль. Интерфейс у тебя содержит константные параметры. Твоя задача написать реализацию данного интерфейса. Но это сделать нельзя, поскольку у языка нет такого понятия как константные параметры в принципе. И сэмулировать внутренними средствами нельзя. Результат понятен. Паскаль никогда не станет CRL совместимым языком. Поэтому к таким шнягам очень осторожно относятся.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: И снова про константность
От: _FRED_ Черногория
Дата: 21.11.05 22:09
Оценка: +1 :)
Здравствуйте, GlebZ, Вы писали:

GZ>А теперь представь себе что у тебя есть несколько языков. Ну например тот-же паскаль. Интерфейс у тебя содержит константные параметры. Твоя задача написать реализацию данного интерфейса. Но это сделать нельзя, поскольку у языка нет такого понятия как константные параметры в принципе. И сэмулировать внутренними средствами нельзя.


Ну и что? Во времена шестого басика тоже нельзя было ко многим интерфейсам доступ получить… И компоненты разделялись на "доступные из бейсика и недоступные"

Даже в ВБ.НЕТ поначалу беззнаковых целых небыло…

GZ> Результат понятен. Паскаль никогда не станет CRL совместимым языком. Поэтому к таким шнягам очень осторожно относятся.


Тююю… Бейсик же стал? (по сравнению с тем, что до дотНета было)
Help will always be given at Hogwarts to those who ask for it.
Re[2]: И снова про константность
От: Дарней Россия  
Дата: 22.11.05 02:56
Оценка:
Здравствуйте, Nickolay Ch, Вы писали:

NC>но если коротко — то этот параметр лишний.


а если правильно — то разработчики решили, что реализация будет слишком сложна и возможные преимущества не окупят затрат
так что нормальных констант в CLI нет, и судя по всему — не будет
другой вопрос — правы они были или нет. Проблемы с RPC, которые создаются из-за их отстуствия — это еще цветочки
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: И снова про константность
От: GlebZ Россия  
Дата: 22.11.05 09:35
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Ну и что? Во времена шестого басика тоже нельзя было ко многим интерфейсам доступ получить… И компоненты разделялись на "доступные из бейсика и недоступные"


_FR>Даже в ВБ.НЕТ поначалу беззнаковых целых небыло…

И непонятно зачем ввели CLS совместимый язык содержит только беззнаковые переменные
А теперь подумай, чем грозит ввод констант, чем грозит то, что модуль на другом языке изменит значение такого параметра.

_FR>Тююю… Бейсик же стал? (по сравнению с тем, что до дотНета было)

Ну VB.NET и VB6 — два разных языка с похожим синтаксисом. Есть возражения?

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: И снова про константность
От: _FRED_ Черногория
Дата: 22.11.05 12:15
Оценка:
Здравствуйте, GlebZ, Вы писали:

_FR>>Ну и что? Во времена шестого басика тоже нельзя было ко многим интерфейсам доступ получить… И компоненты разделялись на "доступные из бейсика и недоступные"


_FR>>Даже в ВБ.НЕТ поначалу беззнаковых целых небыло…

GZ>И непонятно зачем ввели CLS совместимый язык содержит только беззнаковые переменные
GZ>А теперь подумай, чем грозит ввод констант, чем грозит то, что модуль на другом языке изменит значение такого параметра.

Какого "такого"? Константного или беззнакового? Допустим, константного. Тут два варианта. Или "другой язык" понимает константность, но тогда неинтересно, либо не понимает. Тогда он её не видит и не может до неё доступиться. Не знает о ней и всё. И ничего страшного в этом нету. Обидно, когда вот такой метод понадобится… Но выкрутиться всегда можно (неконстантной обёрткой например на том же шарпе). Через одно место способ? Да. Но он есть. А константности нет

Хотя, пообвыкнув, замечаю, что не так уж она и необходима Можно завести свой ConstantAttribute и проверять его из FxCop или тем же R#. На этапе компиляции, думается мне, не такая уж это архисложная задача для того, кто по настоящему тоскует Уж всяк быстрее, чем подписи собирать и ждать того, чего, скорее всего, не будет.

_FR>>Тююю… Бейсик же стал? (по сравнению с тем, что до дотНета было)

GZ>Ну VB.NET и VB6 — два разных языка с похожим синтаксисом. Есть возражения?

Напротив, подтверждение! Кто мешает расширить синтаксис паскаля или создать на его основе новый язык
<< RSDN@Home 1.2.0 alpha rev. 616 >> =03:03= [Windows 2003 — 5.2.3790.65536]
under «*none*»
Help will always be given at Hogwarts to those who ask for it.
Re[6]: И снова про константность
От: GlebZ Россия  
Дата: 22.11.05 13:32
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Какого "такого"? Константного или беззнакового? Допустим, константного. Тут два варианта. Или "другой язык" понимает константность, но тогда неинтересно, либо не понимает. Тогда он её не видит и не может до неё доступиться. Не знает о ней и всё. И ничего страшного в этом нету. Обидно, когда вот такой метод понадобится… Но выкрутиться всегда можно (неконстантной обёрткой например на том же шарпе). Через одно место способ? Да. Но он есть. А константности нет

Ничего не понял.
Давай, немного опишу насколько сложно, нетривиально, и скорее всего не нужно.
Value объекты и muttable отметаем сразу. Они по определению константны.
Например у нас сеть метод.
void Brahmaputra(const Brahma putra)
{
putra.Meditiroval();
}
Итак, что мы здесь видим. Мы поставили const(также как в C++), который нам гарантирует что putra не изменит своего состояния.
Для того чтобы так было, у нас есть обязанность, чтобы язык который реализовал putra — должен поддерживать информацию о том, что метод putra.Meditiroval() — не изменяет внутреннего состояния объекта. Без такой информации, модель работать не может. Если Brahma написан на языке не поддерживающем константность, то как и не извращайся, то....... Вобщем лучше не извращаться.

_FR>Хотя, пообвыкнув, замечаю, что не так уж она и необходима Можно завести свой ConstantAttribute и проверять его из FxCop или тем же R#. На этапе компиляции, думается мне, не такая уж это архисложная задача для того, кто по настоящему тоскует Уж всяк быстрее, чем подписи собирать и ждать того, чего, скорее всего, не будет.

+1

_FR>>>Тююю… Бейсик же стал? (по сравнению с тем, что до дотНета было)

GZ>>Ну VB.NET и VB6 — два разных языка с похожим синтаксисом. Есть возражения?
_FR>Напротив, подтверждение! Кто мешает расширить синтаксис паскаля или создать на его основе новый язык
Не мало ли языков получается на душу населения. С паскалем будет еще просто. А как быть с SML.NET?

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: И снова про константность
От: _FRED_ Черногория
Дата: 28.11.05 01:12
Оценка:
Здравствуйте, GlebZ, Вы писали:

_FR>>Какого "такого"? Константного или беззнакового? Допустим, константного. Тут два варианта. Или "другой язык" понимает константность, но тогда неинтересно, либо не понимает. Тогда он её не видит и не может до неё доступиться. Не знает о ней и всё. И ничего страшного в этом нету. Обидно, когда вот такой метод понадобится… Но выкрутиться всегда можно (неконстантной обёрткой например на том же шарпе). Через одно место способ? Да. Но он есть. А константности нет

GZ>Ничего не понял.
GZ>Давай, немного опишу насколько сложно, нетривиально, и скорее всего не нужно.
GZ>Value объекты и muttable отметаем сразу. Они по определению константны.
GZ>Например у нас сеть метод.


GZ>void Brahmaputra(const /* сИнее!!!, а тег [с#] :о))) */ Brahma putra)
GZ>{
GZ>  putra.Meditiroval();
GZ>}

GZ>Итак, что мы здесь видим. Мы поставили const(также как в C++), который нам гарантирует что putra не изменит своего состояния.
GZ>Для того чтобы так было, у нас есть обязанность, чтобы язык который реализовал putra — должен поддерживать информацию о том, что метод putra.Meditiroval() — не изменяет внутреннего состояния объекта. Без такой информации, модель работать не может. Если Brahma написан на языке не поддерживающем константность, то как и не извращайся, то....... Вобщем лучше не извращаться.

И что плохого

_FR>>>>Тююю… Бейсик же стал? (по сравнению с тем, что до дотНета было)

GZ>>>Ну VB.NET и VB6 — два разных языка с похожим синтаксисом. Есть возражения?
_FR>>Напротив, подтверждение! Кто мешает расширить синтаксис паскаля или создать на его основе новый язык
GZ>Не мало ли языков получается на душу населения. С паскалем будет еще просто. А как быть с SML.NET?

Прогресс, блин То есть улучшение, то есть уточнение, то есть более подробная специфмкация (только чтоб без дырок).
Help will always be given at Hogwarts to those who ask for it.
Re[8]: И снова про константность
От: _FRED_ Черногория
Дата: 28.11.05 01:28
Оценка:
Здравствуйте, _FRED_, Вы писали:


GZ>>Например у нас сеть метод.
GZ>>void Brahmaputra(const Brahma putra)
GZ>>{
GZ>>  putra.Meditiroval();
GZ>>}

GZ>>Итак, что мы здесь видим. Мы поставили const(также как в C++), который нам гарантирует что putra не изменит своего состояния.
GZ>>Для того чтобы так было, у нас есть обязанность, чтобы язык который реализовал putra — должен поддерживать информацию о том, что метод putra.Meditiroval() — не изменяет внутреннего состояния объекта. Без такой информации, модель работать не может. Если Brahma написан на языке не поддерживающем константность, то как и не извращайся, то....... Вобщем лучше не извращаться.

_FR>И что плохого


В смысле, чем это отличается от того, что в Brahma есть одно единственное свойство Value типа uint??? Хуже — не будет, но верю, что потребует изменения «самых потрохов» и не настаиваю
<< RSDN@Home 1.2.0 alpha rev. 616 >> =04:28= [Windows 2003 — 5.2.3790.65536]
under «*none*»
Help will always be given at Hogwarts to those who ask for it.
Re[2]: И снова про константность
От: jazzer Россия Skype: enerjazzer
Дата: 28.11.05 08:25
Оценка:
Здравствуйте, Nickolay Ch, Вы писали:

NC>Уже был хороший ответ с подборкой ссылок, но если коротко — то этот параметр лишний.


Не лишний. Это — декларация о намерениях вызывающего кода, часть его контракта.
Сейчас возможности задать такой контракт в C# нет.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: И снова про константность
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.05 09:35
Оценка: 1 (1) +1
Здравствуйте, _FRED_, Вы писали:
GZ>>Для того чтобы так было, у нас есть обязанность, чтобы язык который реализовал putra — должен поддерживать информацию о том, что метод putra.Meditiroval() — не изменяет внутреннего состояния объекта. Без такой информации, модель работать не может. Если Brahma написан на языке не поддерживающем константность, то как и не извращайся, то....... Вобщем лучше не извращаться.

_FR>И что плохого

В смысле "что плохого"? Ты только что получил compiler error

OC8988: possible attempt to modify const object. Method Brahma.Meditiroval() misses the CompilerServices.ConstAttribute attribute

После этого ты вздыхаешь и убираешь const от параметра. Что тут же приводит к каскаду таких же ошибок там, где ты вызывал Brahmaputra().
Ты материшься и выполняешь контекстную замену "const" на "" по всему солюшну. После чего понимаешь, что const — штука хорошая, но нежизнеспособная.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: И снова про константность
От: _FRED_ Черногория
Дата: 28.11.05 10:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

_FR>>И что плохого

[…]
Согласен со всем

S>…После чего понимаешь, что const — штука хорошая, но нежизнеспособная.


Жизнеспособная, например, в рамках группы языков, поддерживающих константность. Этого более чем достаточно. Если же язык константность не поддерживает, то да, с ним и должно быть всё нехорошо. Например [могу грубо ошибиться, поправьте кто знает лучше], спецификация COM вроде бы не поддерживает константность и создавая обёртки над комовскими объектами приходится этим жертвовать даже во всемогущем С++.

З.Ы.
Кто такие
S>

OC8988: possible attempt to modify const object. Method Brahma.Meditiroval() misses the CompilerServices.ConstAttribute attribute

сообщения выдавать умеет?
<< RSDN@Home 1.2.0 alpha rev. 616 >> =01:19= [Windows 2003 — 5.2.3790.65536]
under «*none*»
Help will always be given at Hogwarts to those who ask for it.
Re[3]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 28.11.05 11:13
Оценка:
Здравствуйте, Дарней, Вы писали:

NC>>но если коротко — то этот параметр лишний.


Д>а если правильно — то разработчики решили, что реализация будет слишком сложна и возможные преимущества не окупят затрат

Д>так что нормальных констант в CLI нет, и судя по всему — не будет
Д>другой вопрос — правы они были или нет. Проблемы с RPC, которые создаются из-за их отстуствия — это еще цветочки

Неизменяемость объектов можно было бы обеспечить на уровне ВМ. Всё равно барьер записи используется сборщиком мусора.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: И снова про константность
От: Дарней Россия  
Дата: 28.11.05 11:23
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Допустим, константного. Тут два варианта. Или "другой язык" понимает константность, но тогда неинтересно, либо не понимает. Тогда он её не видит и не может до неё доступиться. Не знает о ней и всё. И ничего страшного в этом нету.


Например, такой вариант — "другой язык" не понимает, что такое константа, и радостно пытается модифицировать эту переменную. После чего ВМ выдает ему исключением по мордасам.
Разве плохо?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: И снова про константность
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.05 11:28
Оценка: 1 (1)
Здравствуйте, _FRED_, Вы писали:


_FR>Жизнеспособная, например, в рамках группы языков, поддерживающих константность.

_FR> Этого более чем достаточно.
В том-то вся и проблема, что недостаточно. Никакого интеропа с внешним кодом не будет.
То есть для начала нужно перекомпилять (переписав) всю FCL на одном из таких языков, иначе ты даже классом string в этом языке пользоваться не сможешь.
Далее ты увидишь, что огромное количество сторонних библиотек написаны на более простых языках. А ты только что отрезал себя от этого множества, потому что как я показал, "коготок увяз — всей птичке пропасть".

По-моему, ты до сих пор не вьехал в то, что в рамках одной платформы языки с const и языки без const несовместимы. Вообще.
Либо const понижается в должности до хинта, который не влияет на поведение компилятора. Поскольку в слишком большом количестве случаев компилятор не сможет выполнить проверку константности, и ему придется отойти в сторонку. В таком виде этот "модификатор" прекрасно себя чувствует в рамках XML comments, где его найдет разработчик.

_FR>З.Ы.

_FR>Кто такие
S>>

OC8988: possible attempt to modify const object. Method Brahma.Meditiroval() misses the CompilerServices.ConstAttribute attribute

_FR>сообщения выдавать умеет?
Гипотетический компилятор, который поддерживает константность ссылок.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: И снова про константность
От: Cyberax Марс  
Дата: 28.11.05 13:44
Оценка: +1
Sinclair wrote:

> _FR>И что плохого

> В смысле "что плохого"? Ты только что получил compiler error
> OC8988: possible attempt to modify const object. Method
> Brahma.Meditiroval() misses the CompilerServices.ConstAttribute attribute
> После этого ты вздыхаешь и убираешь const от параметра.

Нет. После этого смотрится нужна ли реально модификация, или можно
сделать локальную копию и использовать ее.

Если модификация действительно нужна, то можно использовать const_cast,
либо поставить mutable или убрать константность.

> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.


В С++ нормально работает.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: И снова про константность
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.11.05 04:02
Оценка: -3
Здравствуйте, Cyberax, Вы писали:

C>Нет. После этого смотрится нужна ли реально модификация, или можно

C>сделать локальную копию и использовать ее.
Гм. Вводить локальную копию только ради того, чтобы обойти отсутствие атрибута?
C>Если модификация действительно нужна, то можно использовать const_cast,
C>либо поставить mutable или убрать константность.
Гм. const_cast полностью противоречит идеологии безопасного программирования. Так же, как и reinterpret_cast. Если контракт так легко нарушить, то может быть не стоит его подписывать?
>> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.
C>В С++ нормально работает.
Неа. У Страуструпа, помнится, было упомянуто что-то типа "либо используйте const во всей-всей программе, либо не используйте вообще". По большей части народ пишет вторым способом. И это при том, что стандартная библиотека все-таки аккуратно написана с использованием const (что неверно для FCL, как я уже говорил).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: И снова про константность
От: anton_t Россия  
Дата: 29.11.05 05:26
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Например, такой вариант — "другой язык" не понимает, что такое константа, и радостно пытается модифицировать эту переменную. После чего ВМ выдает ему исключением по мордасам.

Д>Разве плохо?

И эта воображаемая ВМ имеет та-акую замечательную производительность, что застрелиться можно.
Re[8]: И снова про константность
От: Дарней Россия  
Дата: 29.11.05 05:37
Оценка: +1
Здравствуйте, anton_t, Вы писали:

_>И эта воображаемая ВМ имеет та-акую замечательную производительность, что застрелиться можно.


write barrier же живет, и ничего? хотя там потери должны намного побольше быть, если я правильно понимаю
к тому же, по хорошему, проверку корректности присваиваний можно выполнять всего один раз — при верификации кода
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: И снова про константность
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.05 07:11
Оценка: 7 (3) +3
Здравствуйте, Sinclair, Вы писали:

>>> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.

C>>В С++ нормально работает.
S>Неа. У Страуструпа, помнится, было упомянуто что-то типа "либо используйте const во всей-всей программе, либо не используйте вообще". По большей части народ пишет вторым способом.

Не верю.
Без const на C++ программируют только те, кто еще про const не знают. Или не хотят научиться нормально на C++ программировать.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 29.11.05 07:52
Оценка:
Здравствуйте, Дарней, Вы писали:

_>>И эта воображаемая ВМ имеет та-акую замечательную производительность, что застрелиться можно.


Д>write barrier же живет, и ничего? хотя там потери должны намного побольше быть, если я правильно понимаю

Д>к тому же, по хорошему, проверку корректности присваиваний можно выполнять всего один раз — при верификации кода

Кстати, что ВМ не воображаемая, а вполне реальная — VW ST. Инженер писал, что реализация immutability флага добавилась "на дармовщинку". Как оно там внутри устроено я не знаю, но кроме как утилизации барьера других путей в голову не приходит. Кстати, не-мутируемость можно вкл/выкл на лету, что полезно для всякой ерунды связанной с БД.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: И снова про константность
От: Дарней Россия  
Дата: 29.11.05 08:07
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Кстати, что ВМ не воображаемая, а вполне реальная — VW ST.


а не подскажешь, где почитать можно? а то по названию как-то не очень ищется
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 29.11.05 08:27
Оценка: 3 (1)
Здравствуйте, Дарней, Вы писали:

ANS>>Кстати, что ВМ не воображаемая, а вполне реальная — VW ST.


Д>а не подскажешь, где почитать можно? а то по названию как-то не очень ищется


Реч идёт о VisualWorks Smalltalk. Но боюсь, что о флаге неизменности найти инфу там будет трудновато. Я нашел обзор.

Если кратко, то у любого объекта можно установить флаг неизменности (immutability flag). При попытке изменения объекта выбрасывается исключение. В нём, например, можно запомнить изменённый объект, разрешить мутацию и перезапустить операцию. Плюс, со средой идёт фрейворк, который позволяет задавать различные полиси реакции на такое исключение.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: И снова про константность
От: jazzer Россия Skype: enerjazzer
Дата: 29.11.05 08:42
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Гм. const_cast полностью противоречит идеологии безопасного программирования. Так же, как и reinterpret_cast. Если контракт так легко нарушить, то может быть не стоит его подписывать?


Идеология тут не в том, чтобы сделать нарушение контракта максимально сложным хаком (потому что это противоречит целям гибкости языка), но в том, чтобы нарушение контракта было явным и не произошло случайно.
Согласись, довольно сложно случайно написать const_cast, не говоря уж о reinterpret_cast.
Суть в том, что компилятор — мужик, хорошо понимающий нужды программистов, и не желающий портить им жизнь. Он понимает, что раз уж программисту приходится кастить, то он это делает не от хорошей жизни, а из-за того, например, что та чудо-библиотека, которой он вынужден пользоваться, криво спроектирована, или еще по какой причине.
И он понимает, что, раз уж проргаммисту потребовалось кастить, то он найдет способ это сделать, так или иначе, и своего добьется, потому как царь зверей, так зачем заставлять его писать какие-то жуткие непереносимые хаки, если можно договориться полюбовно, а именно — просто попросив его высказать свои желания явно при помощи const_cast?

Так что явно контракт нарушить легко, неявно — невозможно.
Что и требуется, в общем-то.

>>> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.

C>>В С++ нормально работает.
S>Неа. У Страуструпа, помнится, было упомянуто что-то типа "либо используйте const во всей-всей программе, либо не используйте вообще". По большей части народ пишет вторым способом. И это при том, что стандартная библиотека все-таки аккуратно написана с использованием const (что неверно для FCL, как я уже говорил).

Ну, народ всякий бывает, это верно, некоторые вообще циклов не признают, все через goto :)

Что объезжать код таких чудо-деятелей, как раз и приходится кастить (у нас как раз такая кривая библиотека — после трех лет настойчивых просьб они наконец удосужились вставить в их класс хэша константную функцию поиска, а все эти три года да, приходилось кастить — ну а что делать, за все надо платить. Зато каждый каст явственно виден в программе и цель каждого каста предельно ясна — согласись, это гораздо лучше, чем не использовать констов вообще).
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: И снова про константность
От: GlebZ Россия  
Дата: 29.11.05 08:45
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет. После этого смотрится нужна ли реально модификация, или можно

C>сделать локальную копию и использовать ее.
Локальная копия чего? Класса? То это часто практически невозможно. Если ссылки — то это уже не const.

>> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.

C>В С++ нормально работает.
Не сравнивай. С++ — это один язык высокого уровня. В C++ можно по коду корректно проверить работает ли константность. В JIT компиляция происходит во время выполнения, не все сразу, и не пользуясь излишними ресурсами компьютера в виде памяти. Единственный выход — аттрибуты в информации о типах о которых знает компилятор языка. Но если попал на язык который не поддерживает константность, то ничего не поможет.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: И снова про константность
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.11.05 08:58
Оценка:
Здравствуйте, eao197, Вы писали:
E>Не верю.
E>Без const на C++ программируют только те, кто еще про const не знают. Или не хотят научиться нормально на C++ программировать.
Может быть.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: И снова про константность
От: Cyberax Марс  
Дата: 29.11.05 09:13
Оценка:
Sinclair wrote:

> C>Нет. После этого смотрится нужна ли реально модификация, или можно

> C>сделать локальную копию и использовать ее.
> Гм. Вводить локальную копию только ради того, чтобы обойти отсутствие
> атрибута?

Так ведь ради чего-то этот атрибут ставился? Возможно, что другой код
написан с рассчетом, что объект не будет меняться.

Например:
void log_name(const std::string &_name)
{
    std::transform(_name.begin(),_name.end(),to_upper_case()); //Упс... 
Ошибка компиляции
    cout<<_name;
}
...
std::string str=get_user_name();
log_name(str);


По-вашему, тут надо сразу снимать константность:
void log_name(std::string &_name)
{
    std::transform(_name.begin(),_name.end(),to_upper_case()); //А 
теперь компилиться
    cout<<_name;
}
...
std::string str=get_user_name();
log_name(str);
//А где-то здесь упадет....


Я знаю, что в C# строки иммутабельны (как раз по этой причине ), но
сам принцип, я надеюсь, понятен.

> C>Если модификация действительно нужна, то можно использовать const_cast,

> C>либо поставить mutable или убрать константность.
> Гм. const_cast полностью противоречит идеологии безопасного
> программирования. Так же, как и reinterpret_cast. Если контракт так
> легко нарушить, то может быть не стоит его подписывать?

Изредка бывает нужно. Точно так же как и касты Object->Concrete Class —
тоже ведь небезопасно, но иногда необходимо.

>>> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.

> C>В С++ нормально работает.
> Неа. У Страуструпа, помнится, было упомянуто что-то типа "либо
> используйте const во всей-всей программе, либо не используйте вообще".

Ну примерно так и получается. Можно перефразировать практически для
всего: "Либо используйте generic'и по всей программе, либо не
используйте вообще", "Либо используйте исключения..." и т.п.

> По большей части народ пишет вторым способом.


Я пишу аккуратно, boost тоже очень хорош в этом отношении, как и
остальные используемые мной библиотеки.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: И снова про константность
От: Cyberax Марс  
Дата: 29.11.05 09:29
Оценка:
GlebZ wrote:

> C>Нет. После этого смотрится нужна ли реально модификация, или можно

> C>сделать локальную копию и использовать ее.
> Локальная копия чего? Класса?

Значения переменной. В C# это называется "клонирование".

>>> После чего понимаешь, что const — штука хорошая, но нежизнеспособная.

> C>В С++ нормально работает.
> Не сравнивай. С++ — это один язык высокого уровня. В C++ можно по коду
> корректно проверить работает ли константность.

Вообще-то константность в С++ записывается в mangled name. То есть я
могу использовать реализации классов в сторонней библиотеке без боязни
случайно нарушить контсантность.

> Единственный выход — аттрибуты в информации о типах о которых знает

> компилятор языка. Но если попал на язык который не поддерживает
> константность, то ничего не поможет.

Выход простой — такой язык будет видеть только неконстантные методы.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: И снова про константность
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.11.05 09:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Так ведь ради чего-то этот атрибут ставился? Возможно, что другой код

C>написан с рассчетом, что объект не будет меняться.
Нет. Проблема как раз в том, что метод на самом деле не меняет объект. Просто у нас нет способа это проверить — он скомпилирован отсталым компилятором.
C>Изредка бывает нужно. Точно так же как и касты Object->Concrete Class —
C>тоже ведь небезопасно, но иногда необходимо.
Они безопасны потому, что в случае косяка мы получим не UB, а InvalidCastException. В дотнете нет сейф-аналога reinterpret_cast.
Если мы попробуем применить такой же подход в нашем случае, то просто отложим проблему в рантайм — среда все равно выкинет исключение при касте, т.к. объект действительно константный.

C>Я пишу аккуратно, boost тоже очень хорош в этом отношении, как и

C>остальные используемые мной библиотеки.
Ок, ладно, поверим в то, что в мире плюсов все хорошо. Я вот бегло глянул в MFC от 2005 студии — все в порядке, конст используется. Отлично.
Но перенести все то же в .Net, особенно "не затрагивая внутренности", как заказывал автор темы
Автор: chudo19
Дата: 19.11.05
, невозможно. Особенно "чтоб обойти было не возможно всякими кросскастами".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: И снова про константность
От: GlebZ Россия  
Дата: 29.11.05 10:31
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Значения переменной. В C# это называется "клонирование".

Начнем сначала. В C# есть два вида объектов — reference type и value type. Value type так и так по умолчанию передают копию(то есть read only). То есть половина функциональности const просто не нужна. Reference type — передается по ссылке. Но так же как и в С++, если нет конструктора копирования, то пообъектно ты не скопируешь. Только там не конструктор копирования а IClonable. При этом нужно учитывать что он реализуется только там, где он действительно нужен.

C>Вообще-то константность в С++ записывается в mangled name. То есть я

C>могу использовать реализации классов в сторонней библиотеке без боязни
C>случайно нарушить контсантность.
Можешь.

C>Выход простой — такой язык будет видеть только неконстантные методы.

Что и требовалось доказать. Значит мы ввалились в то, что в данных условиях мы противоречим самому духу Net(а именно многоязычности) и эта функциональность больше мешает чем от нее пользы.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: И снова про константность
От: Павел Кузнецов  
Дата: 29.11.05 14:33
Оценка: +1
Sinclair,

> C>Изредка бывает нужно. Точно так же как и касты Object->Concrete Class — тоже ведь небезопасно, но иногда необходимо.


> Они безопасны потому, что в случае косяка мы получим не UB, а InvalidCastException. В дотнете нет сейф-аналога reinterpret_cast. Если мы попробуем применить такой же подход в нашем случае, то просто отложим проблему в рантайм — среда все равно выкинет исключение при касте, т.к. объект действительно константный.


const вовсе не обязательно означает константность объекта; в большинстве случаев как раз наоборот, он означает константность пути доступа к нему. Например, какой из объектов константен в следующем случае?
class C { };

void f(C const& c)
{
}

int main()
{
   C c;
   f(c);
}
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[13]: И снова про константность
От: Cyberax Марс  
Дата: 29.11.05 14:35
Оценка:
Sinclair wrote:

> C>Так ведь ради чего-то этот атрибут ставился? Возможно, что другой код

> C>написан с рассчетом, что объект не будет меняться.
> Нет. Проблема как раз в том, что метод на самом деле *не меняет*
> объект. Просто у нас нет способа это проверить — он скомпилирован
> отсталым компилятором.

Тогда const_cast и надеяться, что он действительно объект не меняет.

> C>Изредка бывает нужно. Точно так же как и касты Object->Concrete Class —

> C>тоже ведь небезопасно, но иногда необходимо.
> Они безопасны потому, что в случае косяка мы получим не UB, а
> InvalidCastException. В дотнете нет сейф-аналога reinterpret_cast.
> Если мы попробуем применить такой же подход в нашем случае, то просто
> отложим проблему в рантайм — среда все равно выкинет исключение при
> касте, т.к. объект действительно константный.

Ну и вернемся к чему начинали — если не снимать const, то все нормально.
При использовании const_cast можем получить exception в runtime.
По-моему, вполне нормально.

> Но перенести все то же в .Net, особенно "не затрагивая внутренности",

> как заказывал автор темы
> <http://rsdn.ru/forum/Message.aspx?mid=1496478&amp;only=1&gt;
Автор: chudo19
Дата: 19.11.05
, невозможно.

> Особенно "чтоб обойти было не возможно всякими кросскастами".

А это уже недостатки .NET.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: И снова про константность
От: _Winnie Россия C++.freerun
Дата: 29.11.05 15:24
Оценка: -1
Не понимаю. Почему const нельзя сделать синтаксическим сахаром только одного языка? Скажем, W#

Ситуация W# зовет f(const TObject x) из W# — все нормально.
Ситуация С# зовет f(const TObject x) из W# — все нормально. Почему C# не должен видеть такие методы? Это ограничение на вызваемую сторону, а не на вызывающую.
Ситуация W# зовет f(TObject x) из C#, где TObject — всё плохо. Надо использовать const_cast и верить документации, что метод C# не будет менять объект. Если const_cast слишком много, то это повод что бы вообще отказатся в вызывающем коде от константности TObject(но только для него, а не для всего остального).
Правильно работающая программа — просто частный случай Undefined Behavior
Re[11]: И снова про константность
От: Павел Кузнецов  
Дата: 29.11.05 15:57
Оценка: +1
Sinclair,

> C>Если модификация действительно нужна, то можно использовать const_cast, либо поставить mutable или убрать константность.


> Гм. const_cast полностью противоречит идеологии безопасного программирования.


При наличии run-time проверок -- не в большей степени, чем любое приведение типов. Если бы const вводился в CLI, run-time проверки были бы.

"Проблемы с языками, не поддерживающими const", надуманы в той же степени, что и "проблемы с языками, не поддерживающими индексаторы или свойства". Иными словами, для таких языков можно было бы ввести соглашение, подобное соглашениям по именованию функций доступа к свойствам. Т.е. для каждого reference класса R можно было бы автоматически порождать базовый интерфейс const_R, содержащий константные методы данного класса:
// язык, поддерживающий const

void F(const C c)
{
}

void Main()
{
   C c = new C();
   F(c);
}

// язык, не поддерживающий const

void F(const_C c)
{
}

void Main()
{
   C c = new C();
   F(c);
}

const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[14]: И снова про константность
От: GlebZ Россия  
Дата: 29.11.05 16:03
Оценка:
Здравствуйте, _Winnie, Вы писали:

_W>Ситуация С# зовет f(const TObject x) из W# — все нормально. Почему C# не должен видеть такие методы? Это ограничение на вызваемую сторону, а не на вызывающую.

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

С уважением, Gleb
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: И снова про константность
От: GlebZ Россия  
Дата: 29.11.05 16:07
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.

А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: И снова про константность
От: Павел Кузнецов  
Дата: 29.11.05 16:08
Оценка:
GlebZ,

> ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.


> А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?


Приведи, пожалуйста, конкретный пример, в котором по-твоему будут проблемы...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[14]: И снова про константность
От: GlebZ Россия  
Дата: 29.11.05 16:19
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>GlebZ,


>> ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.


>> А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?


ПК>Приведи, пожалуйста, конкретный пример, в котором по-твоему будут проблемы...


public delegate String MyDelegate( const MyObject obj );
....
MyDelegate myD1 = new MyDelegate( obj.Method());
Delegate resDelegate=MyFunction(myDl);


С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: И снова про константность
От: vitaly_spb Россия  
Дата: 29.11.05 16:24
Оценка:
ID> public ArrayList Bar
ID> {
ID> get
ID> {
ID> return ArrayList.ReadOnly(this.bar);
ID> }
ID> }
ID>}
ID>[/c#]
...Ei incumbit probatio, qui dicit, non qui negat...
Re[15]: И снова про константность
От: Павел Кузнецов  
Дата: 29.11.05 16:45
Оценка:
GlebZ,

>>> ПК>const_cast с точки зрения run-time являлся бы обычным преобразованием типа со всеми вытекающими.


>>> А как быть с делегатами, которые могут быть как входными параметрами, так и результатом функции?


> ПК>Приведи, пожалуйста, конкретный пример, в котором по-твоему будут проблемы...

>
>
> public delegate String MyDelegate( const MyObject obj );
> ....
> MyDelegate myD1 = new MyDelegate( obj.Method());
> Delegate resDelegate=MyFunction(myDl);
>


И в чем конкретно здесь будет проблема?

/*
Язык, не поддерживающий const, видел бы все это в таком виде:
public delegate String MyDelegate( const_MyObject obj );
....
MyDelegate myD1 = new MyDelegate( obj.Method());
Delegate resDelegate = MyFunction(myDl);

*/
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[16]: И снова про константность
От: GlebZ Россия  
Дата: 29.11.05 19:58
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:


ПК>И в чем конкретно здесь будет проблема?


ПК>/*

ПК>Язык, не поддерживающий const, видел бы все это в таком виде:
ПК>
ПК>public delegate String MyDelegate( const_MyObject obj );
ПК>....
ПК>MyDelegate myD1 = new MyDelegate( obj.Method());
ПК>Delegate resDelegate = MyFunction(myDl);
ПК>

ПК>*/
Здоровски, правда делегат это свой тип. На лету переформировывать такое сложновато, так как запрашивается информация рефлекшон из сборки вызывающей. А она не очень понимает что const_MyObject это совсем не MyObject.
а если он сделает так
public void MyMethod(const_MyObject obj)
{
 (obj is INoConstObject).DoFormatHardDiskNaFig();
}



С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: И снова про константность
От: Павел Кузнецов  
Дата: 29.11.05 21:22
Оценка:
GlebZ,

> ПК>Язык, не поддерживающий const, видел бы все это в таком виде:

> ПК>
> ПК>public delegate String MyDelegate( const_MyObject obj );
> ПК>....
> ПК>MyDelegate myD1 = new MyDelegate( obj.Method());
> ПК>Delegate resDelegate = MyFunction(myDl);
> ПК>


> Здоровски, правда делегат это свой тип. На лету переформировывать такое сложновато, так как запрашивается информация рефлекшон из сборки вызывающей. А она не очень понимает что const_MyObject это совсем не MyObject.


Т.е.? const_MyObject и не являлось бы MyObject. const MyObject на уровне языка превращалось бы в const_MyObject на уровне CLI так же, как obj[i] на уровне C# превращается в obj.get_Item(i) на уровне CLI. Соответственно, ничего переформировывать не надо было бы: в сборке уже все было бы в виде "delegate String MyDelegate( const_MyObject obj )".

> а если он сделает так

>
> public void MyMethod(const_MyObject obj)
> {
>  (obj is INoConstObject).DoFormatHardDiskNaFig();
> }
>

>

Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[18]: И снова про константность
От: GlebZ Россия  
Дата: 30.11.05 12:00
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.

Почти. Есть еще CAS который может ограничить использование кода. Без всяких const.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: И снова про константность
От: Павел Кузнецов  
Дата: 30.11.05 15:26
Оценка:
GlebZ,

> ПК>Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.


> Почти. Есть еще CAS который может ограничить использование кода. Без всяких const.


Ты его для таких целей реально используешь?
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[20]: И снова про константность
От: GlebZ Россия  
Дата: 30.11.05 17:23
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>GlebZ,


>> ПК>Его право. Это как минимум не хуже, чем сегодня, т.к. сейчас он может безо всяких преобразований написать просто obj.DoFormatHardDiskNaFig(). Пожалуй, даже лучше, т.к. случайно получить доступ к неконстантным методам он бы уже не мог.


>> Почти. Есть еще CAS который может ограничить использование кода. Без всяких const.


ПК>Ты его для таких целей реально используешь?

Подколол? Нет, не было случая. Все объекты которые использую в названиях методов и по возвращаемому результату подразумевают изменяют ли они свое состояние или нет. Как то в отличие от С++ не замечал нужность const.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 05:04
Оценка:
Здравствуйте, chudo19, Вы писали:

C>Тогда как запретить модификацию дочернего объекта возвращаемого через проперти?


Понимаш ли... если мыслить объектами, а не ячейками памяти, то становится понятным, что неизменяемость — это свойство самого объекта, а не окружения в котором он обитает. Соотвественно окружение вольно только отдать ссылку на внутренний объект или не отадать.

При таком взгляде становится понятным, что запрет модификации извне объекта противоречит духу ООП.

Другое дело, что неизменяемость можно было бы декларировать для методов, свойств и классов. Это позволило бы повысить контроль и не допускать ошибки дизайна.

В общем то этот контроль можно сделать и извне. Например, с помощью атрибута и FxCop-а или R#-а.

Джиту же и CLR в целом все это без надобсности. Они и так могут обнаружить неизменяемые сущности.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 05:04
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Неизменяемость объектов можно было бы обеспечить на уровне ВМ. Всё равно барьер записи используется сборщиком мусора.


Барьер записи может исчезнуть как при смене алгоритма ЖЦ, так и при введении оптимизаций в этот алгоритм. Однако для контроля неизменяемости достаточно возможностей компилятора. Просто контролировать нужно не изменение объекта, а физическую возможность класса производить модификацию состояния. Ну, как со static-классами в которые нельзя добавить не static-метод.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 05:04
Оценка: 1 (1) +1 :)
Здравствуйте, chudo19, Вы писали:

C>Предлагаю начать собирать подписи. Авось их проймет.


А может собирать подписи за введения mutable, а по умолчанию чтобы все как в ФЯ?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 05:04
Оценка: -1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>const вовсе не обязательно означает константность объекта; в большинстве случаев как раз наоборот, он означает константность пути доступа к нему. Например, какой из объектов константен в следующем случае?

ПК>
ПК>class C { };

ПК>void f(C const& c)
ПК>{
ПК>}

ПК>int main()
ПК>{
ПК>   C c;
ПК>   f(c);
ПК>}
ПК>


Вот, дума, именно такие примеры и подталкнули разработчиков C# выкинуть const к чертям. Чтобы люди не тратили время на решение подобных шарад.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 05:04
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Реч идёт о VisualWorks Smalltalk. Но боюсь, что о флаге неизменности найти инфу там будет трудновато. Я нашел обзор.


ANS>Если кратко, то у любого объекта можно установить флаг неизменности (immutability flag). При попытке изменения объекта выбрасывается исключение. В нём, например, можно запомнить изменённый объект, разрешить мутацию и перезапустить операцию. Плюс, со средой идёт фрейворк, который позволяет задавать различные полиси реакции на такое исключение.


И if-ы в рантайме... Короче полный приплыз с точки зрения производительности. Тут народ все думает, как уменьшить накладные расходы связанные с райт-барьером, а эти...

И это при том, что все что унжно можно смело контролировать во врмемя компиляции.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: И снова про константность
От: Дарней Россия  
Дата: 05.12.05 05:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Понимаш ли... если мыслить объектами, а не ячейками памяти, то становится понятным, что неизменяемость — это свойство самого объекта, а не окружения в котором он обитает.


неизменяемость — это свойство ссылки на объект, а не самого объекта
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[13]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 05.12.05 07:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.


нельзя.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: И снова про константность
От: GlebZ Россия  
Дата: 05.12.05 11:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А может собирать подписи за введения mutable

А смысл? immutable в стрингах также нарушается в unsafe.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 19:04
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>неизменяемость — это свойство ссылки на объект, а не самого объекта


Уверен? А как же string, DateTime и т.п.?

Ну, а неизменяемость ссылки можно добиться банальной инкапсуляцией. Используй свойства без сеттеров и будет тебе щастье.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 19:04
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.


ANS>нельзя.


Серьезный аргумент.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: И снова про константность
От: Дарней Россия  
Дата: 06.12.05 02:43
Оценка:
Здравствуйте, VladD2, Вы писали:

Д>>неизменяемость — это свойство ссылки на объект, а не самого объекта


VD>Уверен? А как же string, DateTime и т.п.?


это просто особенности .NET-ной реализации
небольшой реверанс в сторону ФЯ
на самом же деле есть два подхода к этому вопросу
первый — это как раз ФЯ, где все объекты неизменяемы, а при необходимости изменить данные создается копия
второй — это обычный подход ИЯ, где разрешение или запрещение модификации объектов управляется ссылками на них, как например в C++

void foo(int& x)
{
  a = 5;
}
void bar(const int& x)
{
  a = 10; // хрен вам! :)
}

int a = 0;
foo(a);
bar(a);


VD>Ну, а неизменяемость ссылки можно добиться банальной инкапсуляцией. Используй свойства без сеттеров и будет тебе щастье.


заводить дополнительный неизменяемый интерфейс? я так и делаю, когда припрет. Другой вопрос, что
1. Это все равно костыли
2. Требует дополнительного ручного кодирования
полагаю, что такой распространенный паттерн следовало бы встроить в яызк
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[15]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.12.05 07:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.


ANS>>нельзя.


VD>Серьезный аргумент.


Твоя школа

А если, серьёзно, то проверку времени компиляции, можно использовать только во время компиляции, а ошибку времени выполнения, можно и во время выполнения. Пример, использования при работе с некой БД я как раз и привёл.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: И снова про константность
От: GlebZ Россия  
Дата: 06.12.05 09:46
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>это просто особенности .NET-ной реализации

Д>небольшой реверанс в сторону ФЯ
Это реверанс в сторону дефрагментирующего GC. Он не очень любит изменяемые по длине массивы.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.12.05 23:26
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>>>И это при том, что все что унжно можно смело контролировать во врмемя компиляции.


ANS>>>нельзя.


VD>>Серьезный аргумент.


ANS>Твоя школа


ANS>А если, серьёзно, то проверку времени компиляции, можно использовать только во время компиляции, а ошибку времени выполнения, можно и во время выполнения. Пример, использования при работе с некой БД я как раз и привёл.


Мы все еще ведем речь о константности? Причем тут БД?

Еще раз. Что мне потенциально помешает переложить контроль изменения объектов на джит? Предположим, что у каждого метода есть признак того что он не изменяет содержимое экземпляра и параметров. Далее остается только проверить, что все код обращающися к экземпляру вызвает только такие методы и не пытается самостоятельно изменить содержимое экземпляра.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.12.05 07:09
Оценка:
Здравствуйте, VladD2, Вы писали:

ANS>>А если, серьёзно, то проверку времени компиляции, можно использовать только во время компиляции, а ошибку времени выполнения, можно и во время выполнения. Пример, использования при работе с некой БД я как раз и привёл.


VD>Мы все еще ведем речь о константности? Причем тут БД?


VD>Еще раз. Что мне потенциально помешает переложить контроль изменения объектов на джит? Предположим, что у каждого метода есть признак того что он не изменяет содержимое экземпляра и параметров. Далее остается только проверить, что все код обращающися к экземпляру вызвает только такие методы и не пытается самостоятельно изменить содержимое экземпляра.


Ничего, кроме того, что для убеждения в том, что метод объект не меняет, частенько нужно будет этот метод выполнять. В конкретном контексте, естественно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: И снова про константность
От: jazzer Россия Skype: enerjazzer
Дата: 07.12.05 11:21
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Вот, дума, именно такие примеры и подталкнули разработчиков C# выкинуть const к чертям. Чтобы люди не тратили время на решение подобных шарад.


Влад, вот ты ведь умный квалифицированный программист, и С++ знаешь, так чего ж говоришь такие флеймовые глупости?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: И снова про константность
От: jazzer Россия Skype: enerjazzer
Дата: 09.12.05 09:07
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Понимаш ли... если мыслить объектами, а не ячейками памяти, то становится понятным, что неизменяемость — это свойство самого объекта, а не окружения в котором он обитает. Соотвественно окружение вольно только отдать ссылку на внутренний объект или не отадать.


VD>При таком взгляде становится понятным, что запрет модификации извне объекта противоречит духу ООП.


Ничему оно не противоречит, ибо ортогонально.

Простой пример из жизни — всеми любимый Microsoft Word.
Когда ты открываешь файл из диалога File -> Open, ты можешь нажать как кнопочку Open, так и кнопочку Open Read-Only, а также Open as Copy.

const в С++ — это именно та самая кнопочка Open Read-Only.
Декларация о намерениях пользователя и о его желаниях работать с объектом определенным образом (в данном случае — получая гарантии, что объект изменить не удастся, даже если он и неконстантный по сути).


Еще пример — файл в файловой системе, доступный для изменения одним пользователям и недоступный другим.
Никакого отношения к intrinsic неизменяемости самого файла (потому что она зависит совершенно от других вещей, например, от того, что файл находится на CD, а не на винте) способ доступа не имеет. Очевидно, что файл, лежащий на винте, является изменяемым, его можно стереть и еще много всяких вкусностей сделать.Однако если ты не хочешь, чтобы файл был случайно изменен, ты повесишь на него флажок read-only и получишь искомые гарантии от файловой системы, аналогичные гарантиям, которые получает программист C++ от компилятора, используя const. При этом файл вполне может оставаться не read-only для других пользователей.

Продолжать примеры? Рассказать про GRANT в SQL?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 02:38
Оценка: -1
Здравствуйте, jazzer, Вы писали:

J>Простой пример из жизни — всеми любимый Microsoft Word.

J>Когда ты открываешь файл из диалога File -> Open, ты можешь нажать как кнопочку Open, так и кнопочку Open Read-Only, а также Open as Copy.

Ворд фиговая аналогия. Он говорят на чистом С написан.

Что же до этого дела, то эти варианты могут быть организованы созданием разных обхектов или примененеием паттернов.

J>const в С++ — это именно та самая кнопочка Open Read-Only.


Ненадо провдить столь тонких аналогий со столь разными вещами.

J>Декларация о намерениях пользователя и о его желаниях работать с объектом определенным образом (в данном случае — получая гарантии, что объект изменить не удастся, даже если он и неконстантный по сути).


С точки зрения объекта именно он должен управлять своим состоянием. Если у того же документа ворда есть понятие Read-Only, то он должен генерировать исключения или возвращать код ошибки при попытке вызвать метод записи на диск. Но при этом сам документ остается редактируемым. Я могу изменить его как хочу и записать под другим именем.

Так что это как раз контроль скорее на уровне объекта. В нем ввели один флаг который проверяют в методе записи на диск.

J>Еще пример — файл в файловой системе, доступный для изменения одним пользователям и недоступный другим.


Ну, вот и представь себе. Есть объект отвечающий за открытый файл. В общекте вроде как запись совершить нельзя. Но отвечает за это один флаг. Так вот переменная указывающая на этот объект говорит, что я не могу менять этот флаг (да и весь объект), но я беру и делаю тайп_каст... в итоге я меняю флаг и пишу в защещенный от записи файл. Для С++ ситуация может и нормальная. Моле нефига объект держать в том же процессе ОС. А для управляемого кода ситуация не допустимая. Так что если этот const нельзя проконтролировать везде, то это уже не хорошее решение — дырка.


J>Продолжать примеры? Рассказать про GRANT в SQL?


Не стоит. Эти уже не состоятельны. Вообще делая столь далекие аналогии можно даже не напрягаться. Все равно ни на что кроме красноречия не годятся.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 02:38
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Вот, дума, именно такие примеры и подталкнули разработчиков C# выкинуть const к чертям. Чтобы люди не тратили время на решение подобных шарад.


J>Влад, вот ты ведь умный квалифицированный программист, и С++ знаешь, так чего ж говоришь такие флеймовые глупости?


Понимаш ли. То что тебе что-то кажется глупостью еще не означает, что это так на самом деле. Я просто уверен, что одна из причин по которой было решено не связываться с const или readonly было то, что это усложнит понимание программ. Ведь действительно readonly на указатель ещене значит readonly на объект.

В C#, как не странно это уже кое как проявилось. В нем есть ключевое слово readonly которое можено применять к полям. Однако означает оно именно константность полей (переменных, значит). Так что одна из забавных ошибок выглядит так:
class A
{
    public readonly int[] Array = new int[10];
}
...
A a = new A();
a.Array[0] = 1; // типа не сработает, так как readonly.

В итоге используется это readonly раз в год, а объяснять разным орлам, "почему не сработало ваше земное притяжение" (с) Альф приходится постоянно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 02:38
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ничего, кроме того, что для убеждения в том, что метод объект не меняет, частенько нужно будет этот метод выполнять. В конкретном контексте, естественно.


Ерунду не говори. Чтобы понять что метод не меняет содержимое параметров достаточно проанализировать его мсил.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 12.12.05 07:25
Оценка:
Здравствуйте, VladD2, Вы писали:

ANS>>Ничего, кроме того, что для убеждения в том, что метод объект не меняет, частенько нужно будет этот метод выполнять. В конкретном контексте, естественно.


VD>Ерунду не говори. Чтобы понять что метод не меняет содержимое параметров достаточно проанализировать его мсил.


if (bFlag) 
    setValue(value);
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[20]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.05 14:22
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Ерунду не говори. Чтобы понять что метод не меняет содержимое параметров достаточно проанализировать его мсил.


ANS>
ANS>if (bFlag) 
ANS>    setValue(value);
ANS>


И что? Если есть ссылка на метод модифицирующий состояние, значит все... метод уже не является константным. Анализ не может основываться на состоянии объекта.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: И снова про константность
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 12.12.05 15:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И что? Если есть ссылка на метод модифицирующий состояние, значит все... метод уже не является константным. Анализ не может основываться на состоянии объекта.


Ну! А я тебе о чем говорю?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[22]: И снова про константность
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.12.05 20:36
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>И что? Если есть ссылка на метод модифицирующий состояние, значит все... метод уже не является константным. Анализ не может основываться на состоянии объекта.


ANS>Ну! А я тебе о чем говорю?


Я не понял о чем ты говоришь, но анализу это не мешает. Если такой код есть, то метод помечается как модифицирующий состояние и все дела.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.