Здравствуйте, WolfHound, Вы писали:
>>> Я предпочитаю сырци.
ПК>>Хотя и не очень эффективный, но вполне рабочий подход для написания одноразового кода.
WH>Почему одноразового?
Потому что, если полагаться на реализацию вместо published specification, то никаких гарантий того, что использованное поведение останется именно таким, при дальнейшей поддержке кода не будет.
WH>И вобще если не смотреть в сырци того что используешь можно нарваться по крупному.
Тестировать нужно.
ПК>>Это я не заметил, что ты пытаешься обращаться к одному и тому же объекту из разных потоков, модифицируя его. Это, естественно, работать не будет. Дальше разговор можно не продолжать, пока не будет приведена здравая причина необходимости отсутствия синхронизации при обращении к модифицируемому разделяемому ресурсу.
WH>Если все операции с данным объектом атомарны то синхронизация избыточна.
Атомарности операций для отсутствия необходимости синхронизации недостаточно: в общем случае нужен еще memory barrier для устранения эффектов переупорядочивания этих операций.
WH>Кто тут любит говорить про zerro overhead?
Не знаю. До некоторых пор я скорее любил говрить о premature optimization. Теперь подпись окупирована другим.
WH>А тут целий мъютекс на ровном месте.
Т.е. мотивация -- "ускорение"? Это не кажется здравой причиной для отсутствия синхронизации при периодическом перечитывании конфигурации из разделяемого объекта.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Ага, ага. Текстуальня компиляци без единой проверки и без возможности декомпозиции кода.
Ну, так мы дойдем, что и C# обладает охриниельной системой метапрограммирования, так как есть библиотеки компиляции кода на лету и возможность его испонять в рантайме.
В гробу я такие системы метапрограммирования имел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
VD>>Скромный вопрос... Что есть выделенные фрагменты?
Q>pat & ar — первые два элемента списка. &body body — остаток списка. Т.е Q>
Q>(with-array ((a 0 0) (d 1 1) (i 2 2)) ar
Q> (values a d i))
Q>
Q>pat — pattern = ((a 0 0) (d 1 1) (i 2 2)) Q>ar — array Q>&body = (values a d i)
Не, нет. Как это называется?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
ПК>>Ерунда какая... Конечно, есть. В случае разделения объекта между потоками исполнения копирование объектов там тоже нужно будет делать с учетом возможных race conditions и т.п. (там это обычно называется clone или как-нибудь еще подобным образом из-за отсутствия внятной value семантики). WH>Мне нужно скопировать ОДИН УКАЗАТЕЛЬ. WH>В С++ Я вынужден счелкать счетчиком ссылок и из-за этого копирование указателя не атомарно. WH>В системах с ГЦ копирование ссылки атомарно.
В чем-то Паша прав. Ни C# ни С++ не рассчитаны на многопоточность и в программах на них написанных всегда можно найти тучу мест где можно словить трудно-уловимые ошибки. Хотя конечно сам ЖЦ резко упрощат жизнь. Но по-моему не на столько на сколько нужно для комфортного программирования.
В идиале, я вообще не должен думать о блокировках, гонках и т.п. Тут нужен или фрэйворк или поддержка со стороны языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну, надоело, чесс-слово.
Тебе нужно побуквенное совпадение названия макры? Суть патерн-матчинга, как я уже неоднократно говорил, в двух действиях — деструктинге (разборе списка на составные части) и байдинге.
Или тебе не нравится то, что это макра, а не вколоченная гвоздями сущность?
Здравствуйте, VladD2, Вы писали:
VD>Ага, ага. Текстуальня компиляци без единой проверки и без возможности декомпозиции кода.
Какая текстуальная компиляция? Окстись. Я жу написал, если нужен класс создаём объект и всё. Никакой компиляции вообще.
VD>Ну, так мы дойдем, что и C# обладает охриниельной системой метапрограммирования, так как есть библиотеки компиляции кода на лету и возможность его испонять в рантайме.
Срочно читать мой пост еще раз.
VD>В гробу я такие системы метапрограммирования имел.
Здравствуйте, IT, Вы писали:
IT>Очень похоже сделана эмуляция ООП в JS. Видимо дралось из ST. Но вопрос был немного не об этом. Похоже мы просто запутались в терминологии. Меня прежде всего интересуют возможности метапрограммирования. Как, например, в ST делается (если делается) обработка и преобразование AST или любого другого представления кода/метаданных программы?
Возможно есть действительно недопонимание друг друга.
Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть. Только оно осуществляется не манипулированием ни АСТ, ни текстуальным представлением программы, а манипулированием теми сущностями, которые есть результат кодогенерации в других языках. То бишь, если в Nemerle тебе, для создания класса нужно произвести манипуляции с AST, то в ST достаточно сделать `Metaclass new`. Всё, наш новый класс можно использовать в программе.
Добавлю, что в ST нет разницы между write time/compile time/run time. Это важное идеологическое отличие от других систем, где все три этапа четко отличимы. Например, когда я в ИДЕ в ST добавляю класс, то он в самом низу создаётся при помощи того же `Metaclass new`. То есть сама ИДЕ метапрограммирует программу.
Что касается инструментария, который работает с исходным кодом (Ref.Browser, напр), то там естественно есть и AST и визиторы . Но назвать это метапрограммированием у меня язык не поворачивается.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Возможно есть действительно недопонимание друг друга.
ANS>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть.
Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции. В моём понимании метапрограммирование — это программирование программ, которые в свою очередь создают программы. Например, макрос Немерле, анализируя контекст вызова может порождать принципиально разный код. А твой пример — это не более чем манипулирование таблицей виртуальных методов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ANS>>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть.
IT>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
Видимо, имеется в виду, что в С нельзя создать код этих функций.
Здравствуйте, lomeo, Вы писали:
IT>>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
L>Видимо, имеется в виду, что в С нельзя создать код этих функций.
Так создание/генерацию кода я как раз нигде и не увидел.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, lomeo, Вы писали:
IT>>>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции.
L>>Видимо, имеется в виду, что в С нельзя создать код этих функций.
IT>Так создание/генерацию кода я как раз нигде и не увидел.
Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
Здравствуйте, lomeo, Вы писали:
IT>>Так создание/генерацию кода я как раз нигде и не увидел.
L>Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
А как быть с декомпозицией кода?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
ANS>>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть.
IT>Не совсем. Подобное можно сэмулировать даже в С с помощью указателей на функции. В моём понимании метапрограммирование — это программирование программ, которые в свою очередь создают программы.
Вот смотри. В ST есть объекты (методы и классы это first class objects), которым можно посылать сообщения.
Программирование в ST это последовательное создание нужных объектов — последовательное изменение состояния, которое хранится в образе (image). Когда мы создаём класс в ИДЕ, на самом деле создаётся объект-класс.
Когда мы добавляем метод в наш класс, в этот объект-класс ИДЕ добавляет объект-метод. То есть, чтобы в класс добавить метод, нужно в колекцию методов класса просто положить метод. Что бы создать метод, нужно создать экземпляр класса `CompiledMethod` и напихать в него байт-коды. Байт-коды хранятся в списке в этом объекте. Естественно они специфичны для разных ВМ. Но если учитывать, что в ST-языке есть единственная операция — посылка сообщения, то байткодов много знать не нужно. (Есть даже люди, которые считаю, что ST это ОО-ассемблер). На практике же, компилятор среды обычно выполняет ряд (отключаемых) оптимизаций. Например, код '1000 timesDo: [ ... ]' не компилируется в отправку сообщения, а компилируется непосредственно в цикл. То есть чистота, принесена в угоду практичности. Хотя, если вызвать метод `timesDo:` у объекта-числа через рефлексию, то всё будет работать. Сейчас уже эти оптимизации уже не играют такой важной роли как в 80-х гг.
IT> Например, макрос Немерле, анализируя контекст вызова может порождать принципиально разный код.
Ну, так и любая ST-программа может, например, скомпилировать регэксп непосредственно в ST-байткод. Все манипуляции с кодом, выполняются манипулированием соответствующими объектами. Есть тулзы которые автоматизируют наиболее частые задачи.
IT>А твой пример — это не более чем манипулирование таблицей виртуальных методов.
Почти. Если чуть доработать эту систему, то получится ST-машины. В соответсвии с законом Гринспуна
Если нам не помогут, то мы тоже никого не пощадим.
Потом даём компилеру. Ну или байткод генерить.