Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Курилка, Вы писали:

К>>Ага, а функции работы с матрицами — методами матриц, с числами — методами чисел (например sin, cos) и т.д.

FDS>Смотря как они реализованы. Или ты считаешь, что если объект представляет матрицу, то это уже не объект???

Ну да, если у тебя в руках молоток...
Просто надо осторожней с фанатизмом, каждому инструменту своё применение

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, McSeem2, Вы писали:
MS>>Ты ошибаешься. Структура FILE непрозначна. Точнее, в некоторых реализациях она может быть обыччной struct, но все равно, надо к ней относиться как к непрозрачной.
S>К ней нельзя относиться как к непрозрачной. Потому, что она всё-таки прозрачна. Это как "не думать о белой обезьяне": как же я могу о ней не думать, если структура у меня видна, как на ладони? Она во всех реализациях — обычная struct.

Если структура FILE стандартизована, и одинакова во всех реализациях — тогда она прозрачна. А если нет — то нет. И неважно, можно к ней добраться, или нельзя. Также как и недокументированные функции API — ты можешь их использовать, но этого делать нельзя — они не являются частью стандартизованного public интерфейса, и могут в следующей версии вообще уйти. И не важно, пусть даже эта недокументированная функция сейчас присутствует во всех реализациях.

Я к приватным данным твоего класса тоже пролезу без проблем, кстати, если захочу. #define private public, #include "you_private_class" — и вперед. Вывод? Да С++ говно язык, не ООП ни разу, никакой инкапсуляции не обеспечивает . Как я могу думать об инкапсуляции, если они, privat-ы, у меня как на ладони?

L>>Ну НЕ ПРОСТО это Никак не просто
AS>Так непросто или невозможно? Мне показалось, что ты утверждаешь второе. Наверно, не так тебя понял...
Конечно же возможно Но делается это как бы так сказать — per rectum, извините за латынь... Я всего лишь забыл добавить слово "просто" в конце предложения о том что "не решается", я сам виноват — криво выразился .

>>что мешало, к примеру, в оконную процедуру передавать не 4 параметра а 1 — указатель на структуру. А в эту структуру впихнуть контекст. Вот это — простое решение — и работает и для С и для С++. Контекст нужен практически в любом окне, а там где он не нужен — он никому не мешает.
AS>Если хочешь обсудить альтернативный дизайн, опиши конкретнее, как это всё будет выглядеть в тех случаях, что я рассмотрел в предыдущем сообщении. А то не очень понятно, о чём речь идёт.

Ну как один из вариантов — в функцию CreateWindow передаётся lparam, который потом приходит в оконную процедуру для ВСЕХ сообщений. Неважно, отдельным ли параметром или в виде одного из полей структуры, в которую сведены все параметры оконной процедуры.

Ещё один вариант — в функцию CreateWindow передаётся lparam который АВТОМАТИЧЕСКИ ставится в специальное WindowProperty ДО прихода каких-либо сообщений.

Здравствуйте, VladD2, Вы писали:

API Виндвос и Линукс имеют выраженную ООП архитектуру.

В общем да. Можно используя язык С применять ООП, а можно используя С++ применять процедурное программирование.

Здравствуйте, Left2, Вы писали:

L>Ну как один из вариантов — в функцию CreateWindow передаётся lparam, который потом приходит в оконную процедуру для ВСЕХ сообщений. Неважно, отдельным ли параметром или в виде одного из полей структуры, в которую сведены все параметры оконной процедуры.

Информация, которая передаётся в CreateWindow — это по сути дела то, что передаётся конструктору объекта окна. Поэтому она и доступна только в обработчике WM_(NC)CREATE. А дальше ты либо запоминаешь её во внутренних переменных объекта окна (то есть в window data), либо как-то используешь для инициализации и забываешь про неё. Передавать одно и то же постоянно как параметр — это просто лишние тормоза без видимых на то причин. Такие данные должны храниться внутри объекта окна.

А в случае сабклассинга lparam в CreateWindow уже кто-то передал до тебя, и тебе он вообще никак не поможет — всё равно придётся обратиться к SetProp. Где счастье?

L>Ещё один вариант — в функцию CreateWindow передаётся lparam который АВТОМАТИЧЕСКИ ставится в специальное WindowProperty ДО прихода каких-либо сообщений.

ОК. Сейчас в Win32 мы имеем:

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
   switch(uMsg)
   {
   case WM_CREATE:
   case WM_NCCREATE:
      LPVOID pCreateParam = ((CREATESTRUCT*)lParam)->lpCreateParams;
   }
}

Ты предлагаешь:

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
   switch(uMsg)
   {
   case WM_CREATE:
   case WM_NCCREATE:
      LPVOID pCreateParam = (LPVOID)GetWindowLong(hWnd, GWL_CREATEPARAM);
   }
}

Что-то я не уловил принципиальной разницы.

L>>Ну как один из вариантов — в функцию CreateWindow передаётся lparam, который потом приходит в оконную процедуру для ВСЕХ сообщений. Неважно, отдельным ли параметром или в виде одного из полей структуры, в которую сведены все параметры оконной процедуры.

AS>Информация, которая передаётся в CreateWindow — это по сути дела то, что передаётся конструктору объекта окна. Поэтому она и доступна только в обработчике WM_(NC)CREATE. А дальше ты либо запоминаешь её во внутренних переменных объекта окна (то есть в window data), либо как-то используешь для инициализации и забываешь про неё. Передавать одно и то же постоянно как параметр — это просто лишние тормоза без видимых на то причин. Такие данные должны храниться внутри объекта окна.

Тут получается что мне нужно пропихивать сначала LPARAM в WM_CREATE, а потом его как-то ещё куда-то сохранять. А зачем? Мне всего-то надо иметь сразу ассоциированый с окном контекст и ВСЁ — это перекрывает все мои use cases.

Ну и про тормоза не нужно Всё-таки пропихнуть ещё один 4-х (8-ми) байтный параметр в оконную процедуру — этого вообще никто не заметит

AS>А в случае сабклассинга lparam в CreateWindow уже кто-то передал до тебя, и тебе он вообще никак не поможет — всё равно придётся обратиться к SetProp. Где счастье?

L>>Ещё один вариант — в функцию CreateWindow передаётся lparam который АВТОМАТИЧЕСКИ ставится в специальное WindowProperty ДО прихода каких-либо сообщений.

AS>ОК. Сейчас в Win32 мы имеем:

... код поскипан ...

AS>Что-то я не уловил принципиальной разницы.

Тем не менее ИМХО она есть:
1. Я могу без проблем обработать сообщения, которые приходят ДО WM_CREATE. Контекст у меня будет всегда, а не только начиная с определённого момента.
2. Если мне нужно обрабатывать WM_CREATE — то я могу его и не обрабатывать, не плодя код без необходимости.

Здравствуйте, Left2, Вы писали:

L>Тут получается что мне нужно пропихивать сначала LPARAM в WM_CREATE, а потом его как-то ещё куда-то сохранять. А зачем? Мне всего-то надо иметь сразу ассоциированый с окном контекст и ВСЁ — это перекрывает все мои use cases.

Хех. Скажи пожалуйста, зачем люди пишут:

class CMyClass
{
private:
   int m_nParam;

public:
   CMyClass(int nParam) : m_nParam(nParam) {}
};

...

CMyClass my(1234);

вместо того чтобы передавать 1234 во все методы объекта my?

Если развить твою мысль, нужно было ввести в стандарт С++ пункт, что компилятор должен где-то сохранять параметр, передаваемый в конструктор, и затем передавать его во все методы. Ведь это позволило бы тебе сэкономить целую строчку на написание конструктора! И это покрыло бы все твои use cases!

AS>>Что-то я не уловил принципиальной разницы.

L>Тем не менее ИМХО она есть:
L>1. Я могу без проблем обработать сообщения, которые приходят ДО WM_CREATE. Контекст у меня будет всегда, а не только начиная с определённого момента.

А можно огласить весь список "сообщений, которые приходят ДО WM_CREATE"? WM_NCCREATE — это самое первое сообщение, которое получает окно. В своём примере я специально подчеркнул, что create param в обработчике этого сообщения доступен.

L>2. Если мне нужно обрабатывать WM_CREATE — то я могу его и не обрабатывать, не плодя код без необходимости.

Угу, и конструкторы в С++ можно не писать, не плодя код без необходимости. См. выше.

В мире Win32 WM_CREATE — это твой конструктор. А WM_DESTROY — деструктор. И относиться к ним нужно соответственно. Твоё нежелание их писать не имеет ничего общего с хорошим или плохим дизайном Win32.

Здравствуйте, FDSC, Вы писали:

К>>Ага, а функции работы с матрицами — методами матриц, с числами — методами чисел (например sin, cos) и т.д.

FDS>Смотря как они реализованы. Или ты считаешь, что если объект представляет матрицу, то это уже не объект???

Нет, не объект. Всё-таки даже в не всё должно быть объектом. Например, числа никогда объектами не являются. Если мы объявляем переменную типа int, то мы потом можем сколько угодно раз изменять её. Но мы не можем, присовив этой переменной, скажем, единицу, изменить саму единицу. Единица в данном случае — нечто целое и неделимое.

Думаю, ООП работает не только с объектами, но и со "значениями". Значениям нельзя посылать сообщения, их внутренняя структура неизменна, у них по-другому определятеся identity. Значения могут передаваться в сообщениях. Как представлять данную сущность — через значение или через объект — решается на основе опыта.

Приведу пример с теми же матрицами. Если матрицу сделать объектом, то матрица должна быть изменяемой. Т.е. должны быть такие сообщения, которые изменяют отдельные компоненты. При этом разумно к объекту "матрица" прикрутить события. Иначе, если мы присвоим матрицу 4-го порядка чему-нибудь вроде RenderingDevice, а потом станем изменять её компоненты, то это никак не затронет картинку, воспроизводимую RenderingDevice. Кроме того, уже не будет объекта IdentityMatrix типа Matrix, поскольку его можно будет изменить и это будет уже не IdentityMatrix. Вместо этого нужно будет иметь singletone-объект IdentityMatrixMaker, который будет посылать данной матрице такую серию сообщению, которая сделает её единичной.

Если же рассматривать матрицу как значения типа Matrix, то указанные проблемы отпадают. Правда, появляется проблема с тем, что Matrix — неизменяемое значение. Но это легко исправить, введя объект типа MatrixBuilder.

AS>Если развить твою мысль, нужно было ввести в стандарт С++ пункт, что компилятор должен где-то сохранять параметр, передаваемый в конструктор, и затем передавать его во все методы. Ведь это позволило бы тебе сэкономить целую строчку на написание конструктора! И это покрыло бы все твои use cases!

Не надо развивать мою мысль подобным образом, это уже утрирование получается Скажу так — лично я инкапсулирую переменные только примерно в 25% классов — которые торчат наружу дизайна. И всё! А писать конструктор в КАЖДОМ классе, даже если он просто связывает две-три сущности, да ещё и обьявлен внутри функции или cpp-файла — это конечно концептуально, но лично я не хочу делать лишнюю работу только ради концептуальности.


AS>Угу, и конструкторы в С++ можно не писать, не плодя код без необходимости. См. выше.
Именно!

AS>В мире Win32 WM_CREATE — это твой конструктор. А WM_DESTROY — деструктор. И относиться к ним нужно соответственно. Твоё нежелание их писать ничего общего не имеет с хорошим или плохим дизайном Win32.
Скажем так — в С++ я МОГУ не писать конструктор когда он мне не нужен. И если бы компилятор С++ требовал бы наличия конструктора у КАЖДОГО класса — программисты бы взвыли. И называли бы это кривизной дизайна. И я бы взвыл первым В конце концов — и компиляторы, и API пишутся для программистов. А программисты — это люди. И им должно быть удобно. А если им неудобно — это кривой дизайн.

Ещё раз попробую перефразировать — если для решения ТИПОВОЙ задачи мне нужно написать КУЧУ кода — то дизайн кривой. Особенно хорош в этом плане Symbian. Вроде бы в нём всё OOP — никаких тебе свободных функций, одни классы. Но когда начинаешь решать типовые задачи и видишь что для этого тебе надо написать десяток классов — то извините, это API кривое. Мне не нужны шашечки, мне бы ехать

Здравствуйте, Gaperton, Вы писали:
G>Если структура FILE стандартизована, и одинакова во всех реализациях — тогда она прозрачна. А если нет — то нет. И неважно, можно к ней добраться, или нельзя. Также как и недокументированные функции API — ты можешь их использовать, но этого делать нельзя — они не являются частью стандартизованного public интерфейса, и могут в следующей версии вообще уйти. И не важно, пусть даже эта недокументированная функция сейчас присутствует во всех реализациях.
Недокументированность функций имеет слабое отношение к теме вопроса. Речь о том, что handle — это не указатель на структуру, а некоторый селектор в неизвестно куда. И работать с ним можно исключительно путем вызова функций, пусть даже и недокументированных.

G>Я к приватным данным твоего класса тоже пролезу без проблем, кстати, если захочу. #define private public, #include "you_private_class" — и вперед. Вывод? Да С++ говно язык, не ООП ни разу, никакой инкапсуляции не обеспечивает . Как я могу думать об инкапсуляции, если они, privat-ы, у меня как на ладони?
Ну, по крайней мере, ты сделаешь это осознанно. А написать file->pos тебе поможет среда с автодополнением, и компилятор ничего плохого не скажет.

Ребята, может хватит детский сад разводить? Вам что, в школе не преподавали структурное программирование? Или вы его узнать не можете, даже посмотрев на него вплотную?

Здравствуйте, konsoletyper, Вы писали:


K>Нет, не объект. Всё-таки даже в не всё должно быть объектом. Например, числа никогда объектами не являются.
Ничего подобного. С точки зрения практической реализации — да, числа объектами не являются.
Однако с точки зрения теории кристалла, никаких препятствий к тому, чтобы сделать числа объектами, нет.
Для этого достаточно сделать их immutable, и считать, что все четыре миллиарда значений int32 кем-то были созданы еще до начала работы программы.
В переменных хранятся ссылки на эти значения. Все операции с интами возвращают указатель на подходящий инт.

K>Если мы объявляем переменную типа int, то мы потом можем сколько угодно раз изменять её. Но мы не можем, присовив этой переменной, скажем, единицу, изменить саму единицу. Единица в данном случае — нечто целое и неделимое.
Да-да, единица — это некоторый объект класса Int32. Отличается от всех остальных объектов этого класса тем, что результат x.Multiply(1) для любого x будет по-прежнему равен x.


K>Приведу пример с теми же матрицами. Если матрицу сделать объектом, то матрица должна быть изменяемой.
Не обязательно. Запросто можно заставить матрицу быть неизменной. Если изменяем компонент — мы получаем новую матрицу.

K>Если же рассматривать матрицу как значения типа Matrix, то указанные проблемы отпадают. Правда, появляется проблема с тем, что Matrix — неизменяемое значение. Но это легко исправить, введя объект типа MatrixBuilder.

Sinclair wrote:
> Для этого достаточно сделать их immutable, и считать, что все четыре
> миллиарда значений int32 кем-то были созданы еще до начала работы
> программы.
Кстати, примерно так и было сделано в Smalltalk.

Здравствуйте, Sinclair, Вы писали:

S>Ничего подобного. С точки зрения практической реализации — да, числа объектами не являются.
S>Однако с точки зрения теории кристалла, никаких препятствий к тому, чтобы сделать числа объектами, нет.
S>Для этого достаточно сделать их immutable, и считать, что все четыре миллиарда значений int32 кем-то были созданы еще до начала работы программы.

Кстати в Хаскелле они похожим образом трактуются. Тип Int — как длиннющее перечисление, а Integer — вообще бесконечное.

Здравствуйте, Sinclair, Вы писали:

K>>Нет, не объект. Всё-таки даже в не всё должно быть объектом. Например, числа никогда объектами не являются.
S>Ничего подобного. С точки зрения практической реализации — да, числа объектами не являются.
S>Однако с точки зрения теории кристалла, никаких препятствий к тому, чтобы сделать числа объектами, нет.
S>Для этого достаточно сделать их immutable, и считать, что все четыре миллиарда значений int32 кем-то были созданы еще до начала работы программы.
S>В переменных хранятся ссылки на эти значения. Все операции с интами возвращают указатель на подходящий инт.

Да, вот только САМ int мы не можем изменить. Мы не можем сказать 1.Increase() и потом получить истинное утверждение 1 == 2. Наконец, значения сравниваются не по ссылке, а по значению. Это позволяет нам относиться к матрице как просто к представителю некоторого уже существующего множества, а не к созданному из небытия объекту. Методы вроде BuildMatrix — это всего лишь посылка сообщению некоторому MatrixBuilder, который выбирает нужное значние из множества матрици возвращает его.

K>>Если мы объявляем переменную типа int, то мы потом можем сколько угодно раз изменять её. Но мы не можем, присовив этой переменной, скажем, единицу, изменить саму единицу. Единица в данном случае — нечто целое и неделимое.
S>Да-да, единица — это некоторый объект класса Int32. Отличается от всех остальных объектов этого класса тем, что результат x.Multiply(1) для любого x будет по-прежнему равен x.

Да мы вообще никаких совйств единицы изменить не можем. Что ж, если кому-то не нравится моя терминология, то можно сказать так: существуют изменяемые и неизменяемые объекты. Изменяемые могут создаваться и уничтожаться, а так же мы можем изменять их внутреннюю структуру. Кроме того, два по-отдельности созданных изменяемых объекта никогда не могут быть равны. Неизменяемые объекты неявно существуют всегда, мы не можем их создать или уничожить, но мы можем выбрать нужные из множества.

K>>Приведу пример с теми же матрицами. Если матрицу сделать объектом, то матрица должна быть изменяемой.
S>Не обязательно. Запросто можно заставить матрицу быть неизменной. Если изменяем компонент — мы получаем новую матрицу.

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

Здравствуйте, konsoletyper, Вы писали:
K>Да, вот только САМ int мы не можем изменить. Мы не можем сказать 1.Increase() и потом получить истинное утверждение 1 == 2.
Я и не предлагал.
Просто результатом 1.Increase() будет ссылка на другой Int, и утверждение 1.Increase() == 2 будет истинным.
K>Наконец, значения сравниваются не по ссылке, а по значению.
Совершенно необязательно. Если value-объекты неизменны, то нет никакой разницы, сравнивать их по значению или по ссылке. Все ссылки на двойку будут одинаковы просто потому, что сушествует ровно один экземпляр двойки.

K>Это позволяет нам относиться к матрице как просто к представителю некоторого уже существующего множества, а не к созданному из небытия объекту.
Совершенно верно. Создание из небытия — это уже реализация, экономящая память (очевидно, что хранение полного набора возможных матриц 4*4 является типичным примером преждевременной оптимизации).
K>Методы вроде BuildMatrix — это всего лишь посылка сообщению некоторому MatrixBuilder, который выбирает нужное значние из множества матрици возвращает его.

K>Да мы вообще никаких совйств единицы изменить не можем. Что ж, если кому-то не нравится моя терминология, то можно сказать так: существуют изменяемые и неизменяемые объекты.
Совершенно верно.
K> Изменяемые могут создаваться и уничтожаться, а так же мы можем изменять их внутреннюю структуру.
Уничтожение объектов нам, собственно говоря, не очень нужно.
K>Кроме того, два по-отдельности созданных изменяемых объекта никогда не могут быть равны.
Ну, я бы сказал, не "равны", а "идентичны".
K>Неизменяемые объекты неявно существуют всегда, мы не можем их создать или уничожить, но мы можем выбрать нужные из множества.
Можно и так считать. Поскольку они неизменяемые, то вопрос о том, существовали ли конкретные экземпляры до того, как мы их впервые использовали, является теологическим. Точно так же, как и вопрос о том, что происходит с объектами, на которые не остается ссылок.

S>>Не обязательно. Запросто можно заставить матрицу быть неизменной. Если изменяем компонент — мы получаем новую матрицу.
K>Нет, мы к матрице можем прикрутить метод, который по номеру строки и столбца а так же по некоторому значению возвращает новую матрицу, в которой в указанная компонента будет принимать новое значение. Т.е. будет взята матрица из множества всевозможных матриц, а не изменена структура имеющейся.
Да.

Здравствуйте, Sinclair, Вы писали:

K>>Да, вот только САМ int мы не можем изменить. Мы не можем сказать 1.Increase() и потом получить истинное утверждение 1 == 2.
S>Я и не предлагал.
S>Просто результатом 1.Increase() будет ссылка на другой Int, и утверждение 1.Increase() == 2 будет истинным.

Ну, так 1.Increase() не поменяет структуру объекта 1. Просто это способ получить доступ к объекту 2 из множества целых чисел.

K>>Наконец, значения сравниваются не по ссылке, а по значению.
S>Совершенно необязательно. Если value-объекты неизменны, то нет никакой разницы, сравнивать их по значению или по ссылке. Все ссылки на двойку будут одинаковы просто потому, что сушествует ровно один экземпляр двойки.

+1. Только обычно имеет место эмуляция такого поведения с соответствующим переопределением смысла отношения "равно".

K>>Это позволяет нам относиться к матрице как просто к представителю некоторого уже существующего множества, а не к созданному из небытия объекту.
S>Совершенно верно. Создание из небытия — это уже реализация, экономящая память (очевидно, что хранение полного набора возможных матриц 4*4 является типичным примером преждевременной оптимизации).

Но вопрос лишь в том, как относиться к этому. Множество представимых в памяти компьютера матриц конечно. Мы можем выбрать элемент, тем или иным способом точно указав на него. Но т.к. память компьютера всех матриц не удержит, то мы эмулируем такое поведение переопределением отношения равенства для неизменяемых объектов и созданием "новых" матриц. С изменяемыми объектами всё по-другому — мы можем выбрать "какой-нибудь" объект из бесконечного множества, причём мы не можем точно указать на него до того, как он выбран.

Хочу ещё раз подчеркнуть, что вообще, да, всё есть объекты. Но мы на этих объектах эмылируем то, что я называю "значениями", или "неизменяемыми объектами", которые имеют несколько иное поведение.

K>>Методы вроде BuildMatrix — это всего лишь посылка сообщению некоторому MatrixBuilder, который выбирает нужное значние из множества матрици возвращает его.

K>>Да мы вообще никаких совйств единицы изменить не можем. Что ж, если кому-то не нравится моя терминология, то можно сказать так: существуют изменяемые и неизменяемые объекты.
S>Совершенно верно.

Ну раз так, то можно и по другому переформулировать моё предположение: раз есть mutability, то это не значит, что стоит его использовать где попало. Более того, в конкретном случае с матрицами в большинстве случаев (например, для тех же 3D-рендереров) гораздо более грамотной является архитектура с immutable-матрицами, хотя, как говорится, it depends.

K>> Изменяемые могут создаваться и уничтожаться, а так же мы можем изменять их внутреннюю структуру.
S>Уничтожение объектов нам, собственно говоря, не очень нужно.

Ага.

Здравствуйте, konsoletyper, Вы писали:

K>Ну, так 1.Increase() не поменяет структуру объекта 1. Просто это способ получить доступ к объекту 2 из множества целых чисел.
Я с этим в очередной раз не спорю. ООП здесь в том, что именно объект 1 решает, какой объект вернуть в ответ на сообщение Increase. Другое дело, что его состояние никогда не меняется, и результат операции 1.Increase() (как, впрочем, и любой другой) всегда будет одним и тем же.

K>+1. Только обычно имеет место эмуляция такого поведения с соответствующим переопределением смысла отношения "равно".
С точки зрения теории кристалла это совершенно ненужная, а иногда и вредная оптимизация.

K>Но вопрос лишь в том, как относиться к этому. Множество представимых в памяти компьютера матриц конечно. Мы можем выбрать элемент, тем или иным способом точно указав на него. Но т.к. память компьютера всех матриц не удержит, то мы эмулируем такое поведение переопределением отношения равенства для неизменяемых объектов и созданием "новых" матриц.
Смешиваешь две несвязанные вещи. Создание новых матриц — это аналог "виртуальной" памяти. Т.е. потребителю всё равно кажется, что матрицы были там всегда.
Способ сравнения двух матриц на равенство никак с этим не связан. Генератор матриц всегда можно написать так, чтобы он никогда не создавал матрицу, если такая уже есть. В таком случае не будет риска получения двух неидентичных, но эквивалентных матриц. В противном случае генератор не является "прозначным": наличие в программе одновременно двух различных ссылок на одинаковые объекты противоречит наличию где-то склада готовых матриц, где каждая матрица представлена ровно один раз.

Замечу также, что генератор не обязан в течение всего времени жизни программы отдавать одну и ту же матрицу по одному и тому же адресу (иначе бы у него не хватило адресного пространства). Достаточно обеспечить все одновременно используемые матрицы различными адресами; те матрицы, которые больше не используются, могут быть безболезненно убиты и затем воссозданы уже с другим адресом. Это ничего не нарушит, т.к. чтобы обнаружить это, коду нужно сравить "новый" адрес со "старым", а для этого "старый" адрес должен был где-то храниться, а стало быть матрица не могла быть убита.

K>Хочу ещё раз подчеркнуть, что вообще, да, всё есть объекты. Но мы на этих объектах эмылируем то, что я называю "значениями", или "неизменяемыми объектами", которые имеют несколько иное поведение.
Видишь ли, это вопрос концептуальной чистоты. Либо мы специально вводим некие особые сущности — примитивные типы, как это делают Java и .Net, и усложняем модель, либо мы просто декларируем Immutable Object Pattern и говорим, что всё, что надо, эмулируется при помощи этого паттерна. В том числе и строки, и прочее.

Естественно, вопрос о применимости такого подхода в реальной жизни достаточно риторический. Даже если построить исполняющую среду, которая не будет сливать по производительности менее математизированным реализациям, то всё равно удобнее опираться на несколько более богатый набор примитивов out of the box.

K>Ну раз так, то можно и по другому переформулировать моё предположение: раз есть mutability, то это не значит, что стоит его использовать где попало. Более того, в конкретном случае с матрицами в большинстве случаев (например, для тех же 3D-рендереров) гораздо более грамотной является архитектура с immutable-матрицами, хотя, как говорится, it depends.
Совершенно верно.

Здравствуйте, Sinclair, Вы писали:

K>>+1. Только обычно имеет место эмуляция такого поведения с соответствующим переопределением смысла отношения "равно".
S>С точки зрения теории кристалла это совершенно ненужная, а иногда и вредная оптимизация.

А это что такое?

K>>Но вопрос лишь в том, как относиться к этому. Множество представимых в памяти компьютера матриц конечно. Мы можем выбрать элемент, тем или иным способом точно указав на него. Но т.к. память компьютера всех матриц не удержит, то мы эмулируем такое поведение переопределением отношения равенства для неизменяемых объектов и созданием "новых" матриц.
S>Смешиваешь две несвязанные вещи. Создание новых матриц — это аналог "виртуальной" памяти. Т.е. потребителю всё равно кажется, что матрицы были там всегда.

Это я не смешиваю две вещи, а просто говорю об одном из способов эмулировать нужную сущность. Просто очень привык к подходу Java/.NET с переопределением Equals.

K>>Хочу ещё раз подчеркнуть, что вообще, да, всё есть объекты. Но мы на этих объектах эмылируем то, что я называю "значениями", или "неизменяемыми объектами", которые имеют несколько иное поведение.
S>Видишь ли, это вопрос концептуальной чистоты. Либо мы специально вводим некие особые сущности — примитивные типы, как это делают Java и .Net, и усложняем модель, либо мы просто декларируем Immutable Object Pattern и говорим, что всё, что надо, эмулируется при помощи этого паттерна. В том числе и строки, и прочее.

Правильно, можно сам язык и рантайм (если таковой имеется) основать на нескольких простейшимх вещах. Но это никак не должно мешать нам о некоторых вещах думать немного-по другому. Более того, это не должно принципиально запрещать эмуляцию таких вещей. Но всё же лучше, если язык имеет немного сахару, автоматизирующего использование паттернов, а рантайм имеет "сахар", позволяющий получить оптимальный код.

Здравствуйте, Alexander Shargin, Вы писали:

AS>По поводу HANDLE. У разработчиков WinAPI было два варианта:
AS>- Ввести уникальный тип хэндла для каждого объекта ядра. Например, HFILE, HCONSOLE и т. д. Это позволило бы разрулить проблему, о которой ты говоришь. Зато при вызове функций, общих для всех типов объектов (CloseHandle, DuplicateHandle, WaitForSingleObject и т. д.) потребовалось бы явное приведение типа.
AS>- Оставить один общий тип для всех хэндлов. При этом "лишние" приведения типа не требуются, но теоретически может возникнуть неоднозначность.

AS>Разработчики из МС выбрали второй путь.

Они выбрали оба пути. По крайней мере ранние SDK имели вариант компиляции, при котором все эти HWND, HFILE... превращались в разные объекты (фактически примерно так:

typedef struct { что-то; } FAR *HFILE;

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

AS>>Разработчики из МС выбрали второй путь.

N>Они выбрали оба пути. По крайней мере ранние SDK имели вариант компиляции, при котором все эти HWND, HFILE... превращались в разные объекты (фактически примерно так:

typedef struct { что-то; } FAR *HFILE;

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

Есть, точно есть. В VC 2005 по умолчанию это именно так.