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

A>>Не знаю как у кого, но лично мне практически при каждом серьёзном использовании COM приходится несколько раз ручками вызывать AddRef() при передаче указателей на COM-объекты. Конечно, это не слишком актуально для "одноразовых" объектов, но когда объект глобальный и длительного использования — приходится для надёжности. Только так есть гарантия, что все экземпляры классов и все потоки не получат "мусор", уже удалённый кем-то.

F>Как-то звучит подозрительно, видимо, я не очень хорошо понимаю? Что значит "для надежности"? А присваивание по два раза для надежности вы не пишете?

Не пишу, да и в чушь не пишите... Вызов AddRef() гарантирует, что СОМ-объект будет удалён только после освобождения всеми использующими его экземлярами классов в моей программе (соответственно, он освобождается в деструкторах). А также даёт мне возможность не реализовывать хитрую сложную логику ("а нет ли у нас сейчас кого-то, кому ЭТО ещё может понадобиться? Освобождать ли объект?"), а просто написать obj->Release() по мере необходимости.

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

M>Наткнулся на следующее выражение в книге "Прорри Гаттер. Двенадцать повигов Сена Аесли. Подвиги 9-12":
M>

M>Я люблю вовсе не расчеты, а рассуждения. Настоящей, чистой теории не нужны ни расчеты, ни наблюдения, ни подтверждения опытными фактами. А самое главное – у теории не должно быть практических применений, иначе она не будет теорией

M>Эту фразу можно применить к доброй половине высказываний в этой ветке

А еще есть мысль, что

Нет ничего более практичного чем хорошая теория

Хорошая теория — это мощный инструмент практика.
Но данный топик — это не тот случай

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

M>

M>Я люблю вовсе не расчеты, а рассуждения. Настоящей, чистой теории не нужны ни расчеты, ни наблюдения, ни подтверждения опытными фактами. А самое главное – у теории не должно быть практических применений, иначе она не будет теорией

Конструктор Трурль создал однажды машину, которая умела делать все на букву "Н"...
...
...Пригласил он тогда к себе конструктора Клапауция, представил его машине и
так долго расхваливал ее необычайные способности, что тот разозлился
втайне и попросил, чтобы и ему разрешили приказать машине что-нибудь
сделать.
— Изволь, — сказал Трурль, — только это должно быть на букву "Н".
— На "Н"? Хорошо. Пускай сделает Науку. Машина заурчала, и вскоре
площадь перед домом Трурля заполнилась толпой ученых. Одни потирали лбы,
писали что-то в толстых книгах, другие хватали эти книги и драли в клочья,
вдали виднелись пылающие костры, на которых поджаривались мученики науки,
там и сям что-то громыхало, возникали странные дымы грибообразной формы,
вся толпа говорила одновременно, так что нельзя было понять ни слова,
составляла время от времени меморандумы, воззвания и другие документы, а
чуть поодаль сидели несколько одиноких старцев; они беспрерывно мелким
бисерным почерком писали на клочках рваной бумаги.
— Ну, скажешь, плохо? — с гордостью воскликнул Трурль. — Признайся,
вылитая наука! Но Клапауций не был удовлетворен. — Что? Вот эта толпа и
есть наука? Наука — это нечто совсем иное!
— Так, пожалуйста, скажи, что именно, и машина тут же это сделает! —
возмутился Трурль.
Но Клапауций не знал, что сказать...

(с) Станислав Лем "Как уцелела вселенная".

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

F>Антоним для практически любого слова, если он существует, не единственный. Так что то, что вы написали — правда, но не вся правда. Также антонимами могут быть CreateInstance, MakeInstance, BuildInstance и еще куча других.
Оттенки смысла у разных глаголов разные. Если уж подбирать пару, то именно противоположностей, а не "почти противоположностей". Дискуссия на эту тему была в "Проблемах перевода".

F>Потому что программист пишет именно в терминах этого паттерна (не всегда, конечно).
Это бред. Программист пишет в рамках и совершенно других паттернов. Множество объектов он получает вовсе не при помощи CreateInstance. И что теперь, объявлять IConnection.CreateCommand обратной к Release? Не слишком ли много антонимов к одному Release получится?
F>Ну вот видите, сами нашли ответ.
Нет.
F>Вообще, все эти рассуждения никак не опровергают тех тезисов, которые я здесь продвигаю, и которые повторю еще раз:
F>1. Действие должно обозначаться глаголом.
F>2. Противоположные по смыслу действия должны обозначаться противоположными по смыслу словами (одной и той же грамматической категории).
Ну то есть COM неверен, так? Ведь там противоположные по смыслу действия не обозначаются противоположными по смыслу словами.
F>Найдется ли смелый человек, который прямо выступит против этих тезисов, без увода разговора в сторону? Например, прямо скажет: тезис 1 неправильный, действие может обозначаться как угодно, например, существительным, наречием, предлогом и т.п. (Естественно, весь разговор ведется в рамках языков программирования). Или скажет про тезис 2: он неверный, противоположные действия могут обозначаться синонимами (создать объект с помощью ключевого слова yes, а удалить — ключевым словом of_course).
Тезис 1 неправильный, действие может обозначаться как угодно, например существительным, наречием, пригагательным, предлогом. Главное — чтобы применение было очевидным и не вызывало отторжения.

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

A>Не пишу, да и в чушь не пишите... Вызов AddRef() гарантирует, что СОМ-объект будет удалён только после освобождения всеми использующими его экземлярами классов в моей программе (соответственно, он освобождается в деструкторах). А также даёт мне возможность не реализовывать хитрую сложную логику ("а нет ли у нас сейчас кого-то, кому ЭТО ещё может понадобиться? Освобождать ли объект?"), а просто написать obj->Release() по мере необходимости.

Ну это-то понятно, на то AddRef() и нужен. Просто ваше первоначальное описание процесса выглядело так, словно вы получаете объект, делаете на него подряд штук пять AddRef()-ов (для надежности ) и только потом работаете. Не сочтите за наезд

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

J>Здравствуйте, Mr. None, Вы писали:

J>>>Потому что этот класс — не POD-тип, так как имеет определенный пользователем конструктор.
MN>>Не конструктор, а деструктор . Наличие конструктора не превращает класс в POD-тип:

J>Ты хотел сказать, в не-POD-тип?

Ага...

J>

MN>>Стандарт, 9.4
MN>>...A POD-struct is an aggregate class that has no nonstatic data members of type pointer to member, non-POD-struct,
MN>>non-POD-union (or array of such types) or reference, and has no userdefined copy assignment operator and no userdefined destructor...

J>Превращает.
J>

J>Стандарт, 8.5.1/1
J>An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3).

Странно... выходит если я добавлю закрытое поле — это уже будет не-POD-тип... Ну ладно — комитету по стндартизации виднее...
Но конкретно в данном случае (goto через определение) студия реагирует ошибкой именно на деструктор — конструктор ей по барабану, на него она реагирует предупреждением...

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

F>А что, ключ реестра — это объект ядра?

А что, он чем то принципиально отличается от файла? Все те же самые хэндлы, никакой разницы я не вижу

F>К тому же тезис о глаголах, обознающих действия создания/открытия и о противоположных словах для противоположных действий эта функция только подтверждает.

Просто здесь так принято

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

F>>А что, ключ реестра — это объект ядра?

Д>А что, он чем то принципиально отличается от файла? Все те же самые хэндлы, никакой разницы я не вижу

Там не HANDLE, а HKEY. И ключ реестра — не объект ядра. Видимо, функции для работы с объектами ядра контролировала другая группа разработчиков. А может быть, одна и та же, и названия специально сделали разными, чтобы не путаться.

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

S>Оттенки смысла у разных глаголов разные. Если уж подбирать пару, то именно противоположностей, а не "почти противоположностей". Дискуссия на эту тему была в "Проблемах перевода".

Естественно, оттенки разные, потому и антонимов много (и синонимы не означают совершенно одного и того же). Выбор, что же является "точной противоположностью" среди множества "почти противоположностей" — зачастую вопрос вкуса, привычки и традиции. И по большому счету не так уж важен (особенно для нас, у кого английский язык не родной). Гораздо важнее следование сделанному выбору.

F>>Потому что программист пишет именно в терминах этого паттерна (не всегда, конечно).
S>Это бред. Программист пишет в рамках и совершенно других паттернов. Множество объектов он получает вовсе не при помощи CreateInstance. И что теперь, объявлять IConnection.CreateCommand обратной к Release? Не слишком ли много антонимов к одному Release получится?

Вам что, жалко? Паттернов, конечно, много, но тот, о котором мы говорим, описывается простой схемой: произвести действие, в результате которого в наше распоряжение поступит объект (это может произойти в результате CreateInstance(), IConnection.CreateCommand(), AddRef() и еще кучи других), поработать с ним, после чего произвести действие, в результате которого система, с которой мы работаем (в данном случае COM) будет считать, что эта "единица владения" объектом (в случае COM реализованная как счетчик ссылок) нам больше не нужна. Эти два действия описываются глаголами, противоположными по смыслу. Мои тезисы подтверждаются.

F>>Вообще, все эти рассуждения никак не опровергают тех тезисов, которые я здесь продвигаю, и которые повторю еще раз:
F>>1. Действие должно обозначаться глаголом.
F>>2. Противоположные по смыслу действия должны обозначаться противоположными по смыслу словами (одной и той же грамматической категории).
S>Ну то есть COM неверен, так? Ведь там противоположные по смыслу действия не обозначаются противоположными по смыслу словами.

По крайней мере они обозначаются глаголами с более-менее противоположным смыслом. Хотя, конечно в паре AddRef/Release шероховатость есть (Release() можно было бы назвать RemoveRef() или UnRef()), тем не менее, она гораздо меньше, чем в паре new/delete.

S>Тезис 1 неправильный, действие может обозначаться как угодно, например существительным, наречием, пригагательным, предлогом. Главное — чтобы применение было очевидным и не вызывало отторжения.

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

Кстати, а второй тезис верный? Тогда в паре new/delete все равно есть несообразность — слова разных грамматических категорий и не противоположные по смыслу.

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

F>Вам что, жалко? Паттернов, конечно, много, но тот, о котором мы говорим, описывается простой схемой: произвести действие, в результате которого в наше распоряжение поступит объект (это может произойти в результате CreateInstance(), IConnection.CreateCommand(), AddRef() и еще кучи других), поработать с ним, после чего произвести действие, в результате которого система, с которой мы работаем (в данном случае COM) будет считать, что эта "единица владения" объектом (в случае COM реализованная как счетчик ссылок) нам больше не нужна. Эти два действия описываются глаголами, противоположными по смыслу. Мои тезисы подтверждаются.

Я боюсь, что если для тебя глагол "Создать экземпляр" является антонимом глаголу "Отпустить", то дальше дискутировать не о чем.
F>По крайней мере они обозначаются глаголами с более-менее противоположным смыслом. Хотя, конечно в паре AddRef/Release шероховатость есть (Release() можно было бы назвать RemoveRef() или UnRef()), тем не менее, она гораздо меньше, чем в паре new/delete.
Еще раз: new является аналогом CreateInstance в том смысле, что может включать в себя скрытый вызов чего-то с функциональностью create. А может и не включать, если аллокатор ничего не создает, а возвращает готовый объект — главное, чтобы он был новым в том смысле, который заложен в него разработчиком.
F>Приведите, пожалуйста, примеры, когда действие обозначается предлогом, причем это очевидно и не вызывает отторжения. Аналогично для наречия.

MyObject as IInterface

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

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

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

A>>Не пишу, да и в чушь не пишите... Вызов AddRef() гарантирует, что СОМ-объект будет удалён только после освобождения всеми использующими его экземлярами классов в моей программе (соответственно, он освобождается в деструкторах). А также даёт мне возможность не реализовывать хитрую сложную логику ("а нет ли у нас сейчас кого-то, кому ЭТО ещё может понадобиться? Освобождать ли объект?"), а просто написать obj->Release() по мере необходимости.

F>Ну это-то понятно, на то AddRef() и нужен. Просто ваше первоначальное описание процесса выглядело так, словно вы получаете объект, делаете на него подряд штук пять AddRef()-ов (для надежности ) и только потом работаете. Не сочтите за наезд
Он имел в виду, что хитрые пацаны могут рисковать не вызывать AddRef для временных ссылок с гарантированно коротким временем жизни. При помощи статического анализа можно доказать для конкретного случая валидность такого поведения; при этом не вызывается дорогостоящая операция интерлокед инкремента/декремента. Внутри циклов это может оказать существенное влияние на производительность. Небезопасность такого подхода в том, что последующие изменения, внесенные в код (например, добавление еще одного потока, работающего с данным объектом), могут привести к потере инвариантов и устареванию результатов того самого статического анализа.

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

S>Он имел в виду, что хитрые пацаны могут рисковать не вызывать AddRef для временных ссылок с гарантированно коротким временем жизни. При помощи статического анализа можно доказать для конкретного случая валидность такого поведения; при этом не вызывается дорогостоящая операция интерлокед инкремента/декремента. Внутри циклов это может оказать существенное влияние на производительность. Небезопасность такого подхода в том, что последующие изменения, внесенные в код (например, добавление еще одного потока, работающего с данным объектом), могут привести к потере инвариантов и устареванию результатов того самого статического анализа.

Вроде был, то ли в MFC, то ли просто так, класс, оборачивающий AddRef/Release в конструктор/деструктор? Кстати, а если завернуть COM-объект в обычный shared pointer (возможно, через промежуточный класс), мы разве что-то потеряем (в однопоточном случае, конечно)?

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

F>Там не HANDLE, а HKEY. И ключ реестра — не объект ядра.

Есть точные данные?

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

S>Я боюсь, что если для тебя глагол "Создать экземпляр" является антонимом глаголу "Отпустить", то дальше дискутировать не о чем.

"Создать экземпляр" — это не глагол. Понятие создания экземпляра может быть и противоположно понятию "отпустить", зависит от многих факторов. Кстати, почему именно "отпустить"? www.lingvo.ru выдает довольно много вариантов для release, есть из чего выбрать.

S>Еще раз: new является аналогом CreateInstance в том смысле, что может включать в себя скрытый вызов чего-то с функциональностью create. А может и не включать, если аллокатор ничего не создает, а возвращает готовый объект — главное, чтобы он был новым в том смысле, который заложен в него разработчиком.

А вызов CreateInstance() обязан всегда создавать новый объект? В чем же разница, и кто неправ? И потом, не так уж важно, что он делает на самом деле — логически вызов new создает новый объект (то, что повторно используется старый — деталь реализации. Ведь память new тоже выделяет, но явно не вставляет в компьютер новые DIMM-ы, а повторно использует уже существующую память). Да еще и конструктор вызывает.

F>>Приведите, пожалуйста, примеры, когда действие обозначается предлогом, причем это очевидно и не вызывает отторжения. Аналогично для наречия.
S>

S>MyObject as IInterface
S>

S>Это выражение включает в себя вызов действия QueryInterface, который в свою очередь может повлечь создание агрегированного объекта, если используется схема инициализации по требованию. Тем не менее, никакого отторжения не происходит.

Вызов QueryInterface и возможное создание объекта — это деталь реализации. Логически здесь действия не происходит, просто меняется точка зрения на объект. Эдак что угодно можно объявить действием, хоть with в Паскале (тоже, кстати, предлог) или using в C# (в любом из смыслов).

S>Остальное оставляю в качестве упражнения — мне еще и работать иногда надо.

То есть ответа нет. Так и запишем.

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

F>>Там не HANDLE, а HKEY. И ключ реестра — не объект ядра.

Д>Есть точные данные?

По крайней мере в MDSN их нет в списке объектов ядра. (Но вообще этот список отражает нелегкий путь, по которому двигалась разработка WinAPI )

Здравствуйте, faulx, Вы писали:
F>Вроде был, то ли в MFC, то ли просто так, класс, оборачивающий AddRef/Release в конструктор/деструктор?
Есть такой класс.
F>Кстати, а если завернуть COM-объект в обычный shared pointer (возможно, через промежуточный класс), мы разве что-то потеряем (в однопоточном случае, конечно)?
Конечно потеряем. Завертывание может привести только к удорожанию операции, но никак ее не удешевит.

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

F>"Создать экземпляр" — это не глагол. Понятие создания экземпляра может быть и противоположно понятию "отпустить", зависит от многих факторов. Кстати, почему именно "отпустить"? www.lingvo.ru выдает довольно много вариантов для release, есть из чего выбрать.
Ок, нет проблем. Покажи мне вариант из лингвы, противоположный "созданию". Уж не "опубликовать" ли?

оффтоп поскипан.
F>Вызов QueryInterface и возможное создание объекта — это деталь реализации. Логически здесь действия не происходит, просто меняется точка зрения на объект.
Я проавильно понимаю, что логически в данном контексте означает "можно подтасовать под мою точку зрения"? new, который логически всего лишь возвращает новый объект, значит не устраивает. А as, который выполняет запрос интерфейса, значит не устраивает. Такая логика далеко тебя заведет.
F>Эдак что угодно можно объявить действием, хоть with в Паскале (тоже, кстати, предлог) или using в C# (в любом из смыслов).
Совершенно верно. Ну, with мы вряд ли объявим действием, хотя в старые времена оно имело вполне конкретный смысл и действие таки выполнялось. Молодец, пять.
S>>Остальное оставляю в качестве упражнения — мне еще и работать иногда надо.
F>То есть ответа нет. Так и запишем.
А зачем? Ты вон уже и сам привел примеры — with и using

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

F>>Вроде был, то ли в MFC, то ли просто так, класс, оборачивающий AddRef/Release в конструктор/деструктор?
S>Есть такой класс.

Тогда зачем вызывать AddRef/Release руками?

F>>Кстати, а если завернуть COM-объект в обычный shared pointer (возможно, через промежуточный класс), мы разве что-то потеряем (в однопоточном случае, конечно)?
S>Конечно потеряем. Завертывание может привести только к удорожанию операции, но никак ее не удешевит.

Я имел в виду, что если мы работаем с COM-объектом из одного потока, то можно делать по крайней мере одно из трех:

1. Не считать ссылки на него.

2. Считать их с помощью AddRef/Release

3. Считать их с помощью, например, boost::shared_pointer

Если вариант 1 по каким-либо причинам не устраивает, есть ли разница (не в производительности) между вариантами 2 и 3? И если нет, то, как мне кажется, по соображениям той же производительности, лучше использовать вариант 3. Напоминаю, что речь идет об однопоточном приложении. Я прав?

Здравствуйте, faulx, Вы писали:
F>Тогда зачем вызывать AddRef/Release руками?
Этот вопрос в данном контексте не нужен.
F>Я имел в виду, что если мы работаем с COM-объектом из одного потока, то можно делать по крайней мере одно из трех:
F>1. Не считать ссылки на него.
F>2. Считать их с помощью AddRef/Release
F>3. Считать их с помощью, например, boost::shared_pointer
Вариант 1 — это как раз рискованный способ, о небезопасности которого писал Amidlokos.
F>Если вариант 1 по каким-либо причинам не устраивает, есть ли разница (не в производительности) между вариантами 2 и 3?
Есть. вариант 3 укорачивает запись, вариант 2 поддерживается везде (напомню, что COM работает не только в С++).
F> И если нет, то, как мне кажется, по соображениям той же производительности, лучше использовать вариант 3. Напоминаю, что речь идет об однопоточном приложении. Я прав?
По соображениям производительности вариант 3 гарантированно не лучше, чем вариант 2. Ты не прав.

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

F>>"Создать экземпляр" — это не глагол. Понятие создания экземпляра может быть и противоположно понятию "отпустить", зависит от многих факторов. Кстати, почему именно "отпустить"? www.lingvo.ru выдает довольно много вариантов для release, есть из чего выбрать.
S>Ок, нет проблем. Покажи мне вариант из лингвы, противоположный "созданию". Уж не "опубликовать" ли?

Насчет "опубликовать" — это надо спросить у писателей. Очень может быть Есть и другие варианты, например "сбросить бомбы".

А если серьезно, то нам трудно рассуждать о значении слов неродного языка. Перевод не дает всего. Даже если пройтись по синонимам release, можно найти много интересного, например dismiss. У него есть значения "распускать (организацию, общество и т.п.)", "отвергать". Уже ближе. В любом случае, даже если мы согласимся, что Release — не точный антоним Create, значения у них лежат в противоположных смысловых полях.

Однако вспомним, из-за чего возникла дискуссия. Хорошо, пусть у CreateInstance нет противоположного действия. Пусть Release — антоним только к AddRef (с этим-то вы согласны? Впрочем, я уже говорил, что пара AddRef/Release не кажется мне слишком удачной). Мои тезисы, которые я повторял столько раз, что уже устал, эти факты только подтверждают.

S>оффтоп поскипан.

Жаль. Не такой это форум, чтобы "оффтопы скипать"

F>>Вызов QueryInterface и возможное создание объекта — это деталь реализации. Логически здесь действия не происходит, просто меняется точка зрения на объект.
S>Я проавильно понимаю, что логически в данном контексте означает "можно подтасовать под мою точку зрения"? new, который логически всего лишь возвращает новый объект, значит не устраивает. А as, который выполняет запрос интерфейса, значит не устраивает. Такая логика далеко тебя заведет.

Да ведь все просто. new Object(a, b) заведомо предполагает выполнение некоторого кода — кода конструктора. new не просто возвращает новый объект, он создает его (логически), выполняет конструктор, в котором может быть куча побочных эффектов. Если бы объявление и создание нового объекта были бы разделены, вопросов бы не было:

Object *a = new Object(...);
create a;
a->do();
delete a;

Разница же с вашим примером простая: если мы будем думать о new как о декларативной операции, мы напоремся на какую-нибудь неожиданную неприятность гораздо раньше, чем когда мы полагаем декларативной операцией As. Это в первую очередь относится к C++ (а мы именно о нем и говорим), где полагание чего бы то ни было декларативным — очень рискованное занятие.

Кстати, какой был язык в вашем примере? VB или C#? В любом случае, явно не C++.

S>А зачем? Ты вон уже и сам привел примеры — with и using

Это не действия, это инструкции компилятору У меня есть примеры и получше — скажем, лисповский with-open-file. Но это тоже не действие.