Здравствуйте, Cyberax, Вы писали:
C>Я настолько параноик, что такие ситуации (конкурентный вызов нескольких методов объекта) заранее себе запрещаю.
Это данность. Ничего с этим не поделать.
C>Плохое влияние Эрланга, однако.
Был бы это ерланг или любой другой язык со сборкой мусора то и этого вопроса небыло.
Но это С++.
C>Сделай mutexex_ptr. Что-то типа:
хъ C>Обернуть в политики и другие интересные штуки из Александреску по желанию.
Еще один.
Написать обертку не проблема.
Но от мъютекса она всеравно не избавляет.
C>А можно ли привязать по объекту-обработчику к каждому из потоков пула?
А толку? Обновлние карты всеравно никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Плохое влияние Эрланга, однако. > Был бы это ерланг или любой другой язык со сборкой мусора то и этого > вопроса небыло. > Но это С++.
Я не про GC, в Эрланге просто такой ситуации быть не может — мутирующие
объекты там не разделяются между потоками, я у себя сейчас так же делаю.
> C>Обернуть в политики и другие интересные штуки из Александреску по желанию. > Еще один. > Написать обертку не проблема. > Но от мъютекса она всеравно не избавляет.
Ну так от него избавится и не получится при всем желании. Точнее, если
уж совсем извращаться — то можно избавится.
> C>А можно ли привязать по объекту-обработчику к каждому из потоков пула? > А толку? Обновлние карты всеравно никто не отменял.
Так оно всегда будет в одном потоке — так что такие RC просто будут
невозможны.
Здравствуйте, Cyberax, Вы писали:
C>Я не про GC, в Эрланге просто такой ситуации быть не может — мутирующие объекты там не разделяются между потоками, я у себя сейчас так же делаю.
Так и я не шарю без крайней необходимости.
Сама карта не изменяемая.
Меняется только ссылка на нее.
C>Ну так от него избавится и не получится при всем желании. Точнее, если уж совсем извращаться — то можно избавится.
Я уж лучше мъютексом.
C>Так оно всегда будет в одном потоке — так что такие RC просто будут невозможны.
Так мне приходит одно сообщение о том что нужно обновить карту.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Я не про GC, в Эрланге просто такой ситуации быть не может — > мутирующие объекты там не разделяются между потоками, я у себя сейчас > так же делаю. > Так и я не шарю без крайней необходимости. > Сама карта не изменяемая. > Меняется только ссылка на нее.
Ссылка — это тоже изменяемый объект.
> C>Так оно всегда будет в одном потоке — так что такие RC просто будут > невозможны. > Так мне приходит одно сообщение о том что нужно обновить карту.
И обновляй — в это время никакие другие методы этого объекта исполняться
не будут, значит и RC отсутствует. А если у тебя и так пул потоков — то
почему бы так не сделать?
Кстати, именно такая модель используется в EJB в Java — там бины
привязаны к потоку из пула.
Здравствуйте, FR, Вы писали:
FR>И ты и Влад подразумеваете только один способ построения метасистемы работу с кусками AST, да в таком случае паттерн матчинг очень облегчает жизнь, но есть много других метасистем, где как раз можно прекрасно обходится без него. Да даже в лисповских макросах которые тоже по сути работа с AST полезность паттерн матчинга сомнительна.
1. Про много чистая лож. Я могу насчитать 3 штуки.
2. В любой метасистеме нужны средства композиции и декомпозиции. Мамый хреновый подход в этом плане это императивный (читай традицинной процедурно-ООП-ный).
3. Лисп это а) работа с программой в виде АСТ с теми самиыми квази-цитированиями и б) как раз в макросах для используется сопоставление с обрзцом.
4. Ты будешь смеяться, но метапрограммирование на шаблонах С++ использует ни что иное, как функциональный язык с паттерн-матчингом . И это при том, что в основной части языка С++ нет ни того, ни дргого. Вот такая, мля, силявя.
Так что сомнителен скорее твой опыт в этом вопросе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.
Макросы схемы и CL как раз и используют паттерн-матчинг. Просто он там не является штатной частью языка, а реализован средстваи языка. Достаточно поглядеть на то как описываются маросы в той же Схеме и все становится очевидно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
L>>А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.
BZ>имхо Влад как обычно превозносит до небес то, чем Немерле отличается от явы/с#. был бы там playching shatterle — он бы и в нм души не чаял
Паттерн-матчинг не выдуман в Немерле. А я излагаю только собственный опыт. Я сам пытался создать метасистему для C# и столкнулся с необъодимостью создания некого декларативного языка запросов для облегчения декомпозиции кода. Когда же я узнал о паттерн-матчинге в паре с квази-цитированием я понл, что это то что нужно.
Конечно могут быть альтернативы, но пока все что я видел или использовал паттерн-матчинг напрямую, или его анлоги. Даже МС в своих кодогенераторах дошле до идеи паттерн-матчинга (хотя отказались от квази-цитирования).
Квази-цитирование используется в:
1. MetaO'Caml, TemplateHaskell, Lisp.
Паттерн-матчинг тоже используется прямо или косвенно во всех успешных метасистемах.
Откровенно говоря я не заню что тут обсуждать то?
Приведите пример метасистемы без паттерн-матчинга и квази-цитирвоания и давайте обсудим ее приемущества. Сразу намек, С++ не приводить. Там как раз паттерн-матчинг используется .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>В Лиспе нет возможности конструировать типы так свободно, как в ML. Нет там повсеместного использования tuple и unions. Поэтому нет необходимости разбирать большие вложенные друг в друга конструкции (кроме списков), а значит нет необходимости в ПМ.
На самом деле есть. И на самом деле даже кое где применяется. Тот же синтаксис with-matrix по сути определяет паттерн. Если бы пришлось выскивать нужные паттерны вручную, то было бы вообще жуть.
И если бы в языке был штатный паттерн-матчинг, то и код бы выглядил бы несколько понятнее.
Q>ПМ — это очень удобный способ не писать кучу сравнений и присваиваний руками, поэтому это довольно нужная фича.
Скажем так, это уменьшат необходимость, но не убирает ее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Глупости какие. Твоё утверждение опровергается простейшим примером — в ST есть метасистема, но нет сопоставлений с образцом.
Это круто! Это их роднит с каменным топором.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Метасистема есть даже в C#. С помощью эмита, bltoolkit'а и такой-то матери я могу делать практически всё. Вопрос лишь в трудозатратах и пределеах возможностей. Про метасистему ST с удовольствием бы чего-нибудь почитал научно популярного, чтобы оценить простоту и мощь.
Увы, что подсказать для быстрого ознакомления я не знаю Может эту презентацию?
Но если в двух словах то... Есть классы, есть метаклассы (как first class object).
Система такая:
obj := Object new. "Создаём объект класса `Object`"
obj class. "=> `Object` - это класс объекта"
obj class class. "=> `Object class` - класс класса объекта. То бишь метакласс. Они неименованы (называются по имени соответствующего класса) и каждый класс-метакласс образуют пару (1-1)"
obj class class class. "=> `Metaclass` - общий класс всех метаклассов"
obj class class class class. "=> `Metaclass class`"
obj class class class class class. "=> `Metaclass`"
Создание новых классов/метаклассов это просто инстантиирование объектов соответствующего класса:
Object new. "Создаём объект класса `Object`"
Metaclass new. "Создаём метакласс"
Компиляция методов объекта производится вызовом метода #compile: у своего класса. Это позволяет переопределить компилятор для любого класса/иерархии. Например, в VisualWorks расширен компилятор классов связанных с FFI.
Сами методы класса лежат в словаре методов класса. Чтобы добавить добавить/заменить метод мы просто ложим в соответствующий словарь объект класса `CompiledMethod`:
Замечу, что можно создавать свои подклассы от CompiledMethod. Например иерархия в VisualWorks:
CompiledMethod
AnnotatedMethod "Метод с аннотациями (в VW они называются 'pragmas')"
MarkedMethod
UserPrimitiveMethod
ExternalMethod "Умеет делать вызов "внешних" функций - FFI"
ProbedCompiledMethod "Машинерия отладчика"
ProbedAnnotatedMethod
Чтобы создать скомпилированный метод можно либо скормить компилятору ST-код, либо создать метод самому или воспользоваться либой.
Вот как выглядит схема класса кода в VW:
Instance Variables:
mclass <Behavior> Класс в контексте которого был скомпилирован код
sourceCode <nil | Integer> Ссылка на исходный код во внешнем файле
bytes <SmallInteger | ByteArray> - байткод специфичный для VW.
(indexed instance variables) <Object> - литералы (индексированный переменные это те, к оторым обращение происходит не по имени, а по номеру).
Теперь чтобы, например, сделать так, чтобы у некоторого объекта был специфический только для этого объекта метод метод, нужно:
а) склонировать класс объекта: `anObject class copy`;
б) заменить метод с определённым именем на новый: `aClass methodDictionary at: #specificMethod put: aSpecificMethod`
в) поменять класс у объекта: `anObject adoptInstance: newClass`.
Или, например, можно ввести подсистему, которая будет базироваться не на классах, а на прототипах.
Можно добавить только, что есть такая штука, как CLOS MOP. Как это принято в Лиспе, там реализовано всё, что только можно придумать Не думаю, что там сопоставление с образцом играет жизненно важную роль.
Здравствуйте, WolfHound, Вы писали:
BZ>>>вплоть до написания thread-safe конструкторов копирования
КЛ>>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
WH>А что тебя так удивляет? WH>Возьмем например всеми любимый boost::intrusive_ptr WH>
WH>его конструктор компирования не является потокобезопасным.
Документацию по используемым компонентам читать нужно:
1) А кто обещал, что он будет "потокобезопасным"? Где-нибудь в документации это было сказано? (Ответ отрицательный).
2) shared_ptr такие гарантии дает.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, WolfHound, Вы писали:
WH>Тем не мение тут нужен либо внешний mutex либо конструктор копирования и оператор присваивания написанные в расчете на работу в разных потоках. WH>В системах с GC (если не вспоминать про того жутика у которого запись/чтение указателей не атомарно) такой проблемы нет.
Ерунда какая... Конечно, есть. В случае разделения объекта между потоками исполнения копирование объектов там тоже нужно будет делать с учетом возможных race conditions и т.п. (там это обычно называется clone или как-нибудь еще подобным образом из-за отсутствия внятной value семантики).
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ерунда какая... Конечно, есть. В случае разделения объекта между потоками исполнения копирование объектов там тоже нужно будет делать с учетом возможных race conditions и т.п. (там это обычно называется clone или как-нибудь еще подобным образом из-за отсутствия внятной value семантики).
Мне нужно скопировать ОДИН УКАЗАТЕЛЬ.
В С++ Я вынужден счелкать счетчиком ссылок и из-за этого копирование указателя не атомарно.
В системах с ГЦ копирование ссылки атомарно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Документацию по используемым компонентам читать нужно:
Я предпочитаю сырци. ПК>1) А кто обещал, что он будет "потокобезопасным"? Где-нибудь в документации это было сказано? (Ответ отрицательный).
А где я говорил что кто-то обещал?
Я просто сказал что иногда это может быть нужным. ПК>2) shared_ptr такие гарантии дает.
А если почитать сырци то ничего что могло бы дать подобные гарантии там не обнаружилось.
Вот посмотри на класс который считает ссылки:
WolfHound,
> ПК> Документацию по используемым компонентам читать нужно:
> Я предпочитаю сырци.
Хотя и не очень эффективный, но вполне рабочий подход для написания одноразового кода.
> ПК> 2) shared_ptr такие гарантии дает.
> А если почитать сырци то ничего что могло бы дать подобные гарантии там не обнаружилось. > <...> > Или я что-то не заметил?
Это я не заметил, что ты пытаешься обращаться к одному и тому же объекту из разных потоков, модифицируя его. Это, естественно, работать не будет. Дальше разговор можно не продолжать, пока не будет приведена здравая причина необходимости отсутствия синхронизации при обращении к модифицируемому разделяемому ресурсу.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Я предпочитаю сырци. ПК>Хотя и не очень эффективный, но вполне рабочий подход для написания одноразового кода.
Почему одноразового?
И вобще если не смотреть в сырци того что используешь можно нарваться по крупному.
ПК>Это я не заметил, что ты пытаешься обращаться к одному и тому же объекту из разных потоков, модифицируя его. Это, естественно, работать не будет. Дальше разговор можно не продолжать, пока не будет приведена здравая причина необходимости отсутствия синхронизации при обращении к модифицируемому разделяемому ресурсу.
Если все операции с данным объектом атомарны то синхронизация избыточна.
С логической точки зрения boost::intrusive_ptr является ссылкой на объект.
В системах с ГЦ операции с ссылками атомарны. Те синхронизация не нужна.
Операции с boost::intrusive_ptr не атомарны. Те синхронизация нужна.
Именно эта необходимость синхронизации на ровном месте меня несколько раздражает.
Кто тут любит говорить про zerro overhead? А тут целий мъютекс на ровном месте. Да еще и счетчиком ссылок счелкать постоянно надо. А interlocked функции особенно на многопроцессорном железе не дешевы.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Можно добавить только, что есть такая штука, как CLOS MOP. Как это принято в Лиспе, там реализовано всё, что только можно придумать Не думаю, что там сопоставление с образцом играет жизненно важную роль.
Очень похоже сделана эмуляция ООП в JS. Видимо дралось из ST. Но вопрос был немного не об этом. Похоже мы просто запутались в терминологии. Меня прежде всего интересуют возможности метапрограммирования. Как, например, в ST делается (если делается) обработка и преобразование AST или любого другого представления кода/метаданных программы?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
. И это при том, что в основной части языка С++ нет ни того, ни дргого. Вот такая, мля, силявя. 
Может эту презентацию?
Не думаю, что там сопоставление с образцом играет жизненно важную роль.
Если нам не помогут, то мы тоже никого не пощадим.
