Не знаю может вас все таки заставит задуматься такой факт: компилятор не только должен найти функцию которая подходит по типам для опрерации, но и проверить разрешил ли прораммист использовать эту функцию для этой операции в контексте перечисленных типов.
Если есть функция, которая принимает на вход в точности указанные типы, то какое ещё разрешение нужно, чтобы её вызывать с указанными типами? Что вообще означает это "разрешил использовать для операции в контексте типов"? Можно пример какой-нибудь?
Я продолжаю утверждать, что для выражения математических операций не нужны классы, достаточно механизма перегрузки функций, возможности называть функции математическими символами и синтаксического сахара для инфиксных вызовов. Haskell не даст соврать.
ну расскажите тогда как компилятор должен искать функции с именами "+","-", которые принимают структуры в качестве аргументов. Это первое.
Вообще не проблема. Когда компилятор встречает объявление функции, он запоминает в своей глобальной таблице не только её символ-имя, но и типы аргументов. Когда встречается вызов, то поиск и выбор вызываемого кандидата происходят по имени и типам значений аргументов. Это ничем не отличается от перегрузки функции, имя которой не "+", какая разница, какие буквы входят в имя? Так работает перегрузка функций в C++, например. Да что далеко ходить, даже автор этой статьи осилил перегрузку, но у него структуры анонимны, а их тип составляется из типов полей, сути это не меняет. Заменить инфиксную запись a+b на синтаксис вызова +(a,b) элементарно на уровне парсера.
Еще попробуйте выбрать при компиляции правильный способ передачи параметров в функцию на уровне машинных инструкций. Сколько способов передачи параметров в функцию на уровне машинных инструкций вы знаете?
Вы задаёте очень простые вопросы таким важным тоном, будто спрашиваете что-то безумно сложное. Ответ простой: зависит от того, что есть в языке. Если язык поддерживает указатели, и в качестве типа аргумента указан указатель на структуру, то передать его хоть через стек, хоть в регистре, разница невелика. В Java/C# нет указателей, и структуры аллоцируются всегда в куче, а переменные/поля/аргументы хранят ссылки. Если структура передаётся не через указатель, и язык реализует семантику копирования, как C, то в кадре стека вызванной функции аллоцируется место под структуру и содержимое копируется туда.
Это не имеет никакого отношения к классам и к перегрузке функций, базовые вещи. Не понял, к чему был этот вопрос.
Действительно, если куда надо довезет извозчик (компилятор-интерпретатор) - нет никаких причин знать-изучать-понимать географию (методы компиляции)!
Вы не дождались ответа на свои вопросы, и заранее меня тупым пытаетесь выставить?
Нет, для "нормальных математических операций" достаточно было сделать возможность объявлять функции с именами "+","-", ... и принимать структуры в качестве аргументов. Нет никакой причины, по которой операция умножения вектора на скаляр должна быть членом класса вектора.
Это неправда, у вас именно что классы, только вместо ключевого слова class используется type, а синтаксис объявления метода сделан как частный случай объявления функции. Грубо говоря, нельзя сделать функцию, принимающую type как первый аргумент, и не создать при этом метод. Чего в этом хорошего, я хз. Выглядит как чисто синтаксическое упражнение.
Спасибо, дорогая LLM-ка. Ты не виновата, что не поняла, что мой вопрос был вопросом только по форме, а вообще это был намёк твоему хозяину, что плохо он напроектировал, и детальные подробности этого плохого проектирования не очень интересны.
Это можно было бы спроектировать иначе: передавать контекст сверху вниз в visitor, держать стек предков или разделить синтаксическое и семантическое деревья.
Вот видишь, LLM-ка, ты знаешь, а он не понимает. Как вниз по дереву идти, так визиторов понапишут, а потом внутри каждого визитора обратно вверх по дереву лезут уже без визиторов, с if-ами по типу операторов.
Зачем клонировать узлы AST? Чего там в них такого мутабельного, чего в них нужно хранить помимо, собственно, синтаксиса? Если это "class.field", то хоть в левой части присваивания, хоть в правой - какая разница?
Нет, мы не проводили исследований, в которых бы менялось количество подключений, количество трафика по каждому и прочее. У нас подключений немного (единицы), объём трафика - примерно 20-50 тысяч сообщений в секунду, по килобайту каждое, и хорошее железо. И мы сталкивались с проблемами репликационного трафика, и даже с осторожностью используем его непосредственно для репликации: какой-нибудь триггер в базе-получателе может всё тормознуть.
Если у нас читатель в принципе не успевает обрабатывать все сообщения в единицу времени, то без разницы что будет транспортом Kafka или WAL, рано или поздно и тот и другой потеряют сообщения из-за того, что хранилище переполнится.
Это правда. Но у kafka есть масштабирование и при отправке, и при обработке: можно запустить несколько обработчиков параллельно, развязав их по разным партициям.
В базе данные сохранятся в таблицах, они сами по себе никуда не потеряются, их можно будет прочитать и обработать в пакетном режиме.
Из Kafka тоже гораздо правильнее обрабатывать в пакетном режиме, вам брокер обеспечивает пачки. Как их обеспечить в протоколе репликации - я не проверял.
В статье пример использования Kafka для МСА, где каждый сервис выполняет свою полезную работу. Если Сервис просто пересылает сообщение в кафку, то никакой полезной работы он не выполняет. Можно клиентский запрос отправить сразу на целевой сервис.
Помимо неприятного LLM-ного стиля статьи, я осуждаю её основную мысль. Не надо использовать логическую wal-репликацию для Postgres, она плохо заменяет Kafka. Процесс walsender не очень хорошо масштабируется под большое количество соединений. Медленный получатель заставит wal расти. А если получатель отстанет достаточно сильно, то его подписку отменят, и он потеряет данные. Нет возможности распараллелить обработку данных. Debezium страдает от аналогичных проблем. Самый простой вариант: отослать в Kafka, чтобы сохранить в базу уже получателем, автор не рассмотрел.
Качество и признаки LLM - это несовместимые вещи. LLM очень плохо работает с объясняющими текстами, превращая предложения в рубленые лозунги. Если автор опустился до LLM, то на качество статьи ему однозначно похрен, ему главное - сокращение времени.
В противном случае не останется авторов, которые захотят эти статьи писать.
Во-первых, останутся. Во-вторых, количество публикаций уменьшится, и это будет прекрасно.
Spring JDBC - это когда ты пишешь текст запроса, а оно потом из ResultSet-а значения через reflection запихивает в поля объекта. Spring Data JDBC - это когда ты даже запросы не пишешь, оно на основе названия метода сгенерирует запрос (и через reflection запихивает значения из ResultSet-а в поля объектов).
Ну начинается виляние, "структура", связи, длина, и прочий терминологический шум. В газе шарики? Шарики. У вас в стекле тоже шарики. Значит, по вашему выходит, что стекло - газ. В МКТ в стекле не шарики. Значит, ваша попытка покритиковать МКТ состоит в том, чтобы приписать ей то, что она не утверждает. С самого начала статьи, с закона сохранения импульса для шариков.
Ешё со школьных уроков «физики» мы знаем, что согласно «молекулярно-кинетической теории» (МКТ) молекулы газа похожи на абсолютно упругие бильярдные шары, которые с высокой скорость стукаются об стенки сосудов и отскакивают от них с той же скоростью
И после этого автор молекулы стекла тоже рассматривает как шары, то есть стекло - газ?
Я был неправ. В Postgres строка при обновлении действительно блокируется до тех пор, пока обновляющая транзакция не завершится. Postgres при обновлении помечает предыдущую версию строки как удалённую, прописывая в xmax номер транзакции, и создаёт новую версию строки, у которой xmin будет с номером следующей транзации. Новая версия помечается как ещё невидимая, потому что транзакция ещё активна. и этот же признак, что удалившая предыдущую версию строки транзакция ещё активна, является блокировкой строки.
Какая связь между незавершающейся программой и подсчётом ссылок? Ну сделал он в примере new до цикла, а в примере посложнее сделал бы в каком-нибудь методе, который вызывается в цикле и возвращает это значение. В C для этого возвращался бы указатель.
Динамическое выделение памяти не является непозволительной роскошью, реально используемой динамической памяти в каждый момент времени обычно сильно меньше, чем если бы память под все используемые данные была бы выделена статически.
И утечки тут не при чём, утечка - это когда память выделяется и не освобождается, в языках с динамической памятью и сборкой мусора нет явного освобождения, и если ссылок не осталось, то утечек не будет.
Да, в комментах не очень удобно форматировать текст. Спасибо за ответ. На основе этого я бы сказал, что та цитата из статьи, к которой я прицепился, содержит неверную информацию: на RTTI в ОЗУ тратится два байта.
Насчёт наследования классов - нифига, принципиальной разницы с наследованием интерфейсов нет.
Заодно новый вопрос: а вам сильно помогает хранить размер объекта в ОЗУ ? Он же одинаков для всех объектов одного класса, и его можно получать, обратившись по METADATA_ADDR. Я ещё могу понять массивы, но предполагаю, что длина массива у вас хранится явно и отдельно.
Я вот тоже хотел спросить, ntdll.dll - это, конечно, круто, но user32.dll, gdi32.dll, comctl32.dll, comdlg32.dll кто будет эмулировать? WINE это делает.
Если есть функция, которая принимает на вход в точности указанные типы, то какое ещё разрешение нужно, чтобы её вызывать с указанными типами? Что вообще означает это "разрешил использовать для операции в контексте типов"? Можно пример какой-нибудь?
Я продолжаю утверждать, что для выражения математических операций не нужны классы, достаточно механизма перегрузки функций, возможности называть функции математическими символами и синтаксического сахара для инфиксных вызовов. Haskell не даст соврать.
Вообще не проблема. Когда компилятор встречает объявление функции, он запоминает в своей глобальной таблице не только её символ-имя, но и типы аргументов. Когда встречается вызов, то поиск и выбор вызываемого кандидата происходят по имени и типам значений аргументов. Это ничем не отличается от перегрузки функции, имя которой не "+", какая разница, какие буквы входят в имя? Так работает перегрузка функций в C++, например. Да что далеко ходить, даже автор этой статьи осилил перегрузку, но у него структуры анонимны, а их тип составляется из типов полей, сути это не меняет. Заменить инфиксную запись a+b на синтаксис вызова +(a,b) элементарно на уровне парсера.
Вы задаёте очень простые вопросы таким важным тоном, будто спрашиваете что-то безумно сложное. Ответ простой: зависит от того, что есть в языке. Если язык поддерживает указатели, и в качестве типа аргумента указан указатель на структуру, то передать его хоть через стек, хоть в регистре, разница невелика. В Java/C# нет указателей, и структуры аллоцируются всегда в куче, а переменные/поля/аргументы хранят ссылки. Если структура передаётся не через указатель, и язык реализует семантику копирования, как C, то в кадре стека вызванной функции аллоцируется место под структуру и содержимое копируется туда.
Это не имеет никакого отношения к классам и к перегрузке функций, базовые вещи. Не понял, к чему был этот вопрос.
Вы не дождались ответа на свои вопросы, и заранее меня тупым пытаетесь выставить?
Нет, для "нормальных математических операций" достаточно было сделать возможность объявлять функции с именами "+","-", ... и принимать структуры в качестве аргументов. Нет никакой причины, по которой операция умножения вектора на скаляр должна быть членом класса вектора.
Это неправда, у вас именно что классы, только вместо ключевого слова class используется type, а синтаксис объявления метода сделан как частный случай объявления функции. Грубо говоря, нельзя сделать функцию, принимающую type как первый аргумент, и не создать при этом метод. Чего в этом хорошего, я хз. Выглядит как чисто синтаксическое упражнение.
Когда нейронки пишут статьи, именно такая хрень и получается, что репозитории живут дольше разработчиков.
Спасибо, дорогая LLM-ка. Ты не виновата, что не поняла, что мой вопрос был вопросом только по форме, а вообще это был намёк твоему хозяину, что плохо он напроектировал, и детальные подробности этого плохого проектирования не очень интересны.
Вот видишь, LLM-ка, ты знаешь, а он не понимает. Как вниз по дереву идти, так визиторов понапишут, а потом внутри каждого визитора обратно вверх по дереву лезут уже без визиторов, с if-ами по типу операторов.
Я нифига не понял две вещи:
Зачем узлам AST ссылаться на родителей?
Зачем клонировать узлы AST? Чего там в них такого мутабельного, чего в них нужно хранить помимо, собственно, синтаксиса? Если это "class.field", то хоть в левой части присваивания, хоть в правой - какая разница?
не обманул!
Зачем здесь копия документации?
Нет, мы не проводили исследований, в которых бы менялось количество подключений, количество трафика по каждому и прочее. У нас подключений немного (единицы), объём трафика - примерно 20-50 тысяч сообщений в секунду, по килобайту каждое, и хорошее железо. И мы сталкивались с проблемами репликационного трафика, и даже с осторожностью используем его непосредственно для репликации: какой-нибудь триггер в базе-получателе может всё тормознуть.
Это правда. Но у kafka есть масштабирование и при отправке, и при обработке: можно запустить несколько обработчиков параллельно, развязав их по разным партициям.
Из Kafka тоже гораздо правильнее обрабатывать в пакетном режиме, вам брокер обеспечивает пачки. Как их обеспечить в протоколе репликации - я не проверял.
так и нужно делать.
Помимо неприятного LLM-ного стиля статьи, я осуждаю её основную мысль. Не надо использовать логическую wal-репликацию для Postgres, она плохо заменяет Kafka. Процесс walsender не очень хорошо масштабируется под большое количество соединений. Медленный получатель заставит wal расти. А если получатель отстанет достаточно сильно, то его подписку отменят, и он потеряет данные. Нет возможности распараллелить обработку данных. Debezium страдает от аналогичных проблем. Самый простой вариант: отослать в Kafka, чтобы сохранить в базу уже получателем, автор не рассмотрел.
Качество и признаки LLM - это несовместимые вещи. LLM очень плохо работает с объясняющими текстами, превращая предложения в рубленые лозунги. Если автор опустился до LLM, то на качество статьи ему однозначно похрен, ему главное - сокращение времени.
Во-первых, останутся. Во-вторых, количество публикаций уменьшится, и это будет прекрасно.
Очень много водянистых слов.
Spring JDBC - это когда ты пишешь текст запроса, а оно потом из ResultSet-а значения через reflection запихивает в поля объекта. Spring Data JDBC - это когда ты даже запросы не пишешь, оно на основе названия метода сгенерирует запрос (и через reflection запихивает значения из ResultSet-а в поля объектов).
Ну начинается виляние, "структура", связи, длина, и прочий терминологический шум. В газе шарики? Шарики. У вас в стекле тоже шарики. Значит, по вашему выходит, что стекло - газ. В МКТ в стекле не шарики. Значит, ваша попытка покритиковать МКТ состоит в том, чтобы приписать ей то, что она не утверждает. С самого начала статьи, с закона сохранения импульса для шариков.
И после этого автор молекулы стекла тоже рассматривает как шары, то есть стекло - газ?
"Я стреляю не рукой. Тот, кто стреляет рукой, забыл лицо своего отца. Я стреляю разумом."
Я был неправ. В Postgres строка при обновлении действительно блокируется до тех пор, пока обновляющая транзакция не завершится. Postgres при обновлении помечает предыдущую версию строки как удалённую, прописывая в xmax номер транзакции, и создаёт новую версию строки, у которой xmin будет с номером следующей транзации. Новая версия помечается как ещё невидимая, потому что транзакция ещё активна. и этот же признак, что удалившая предыдущую версию строки транзакция ещё активна, является блокировкой строки.
Какая связь между незавершающейся программой и подсчётом ссылок? Ну сделал он в примере new до цикла, а в примере посложнее сделал бы в каком-нибудь методе, который вызывается в цикле и возвращает это значение. В C для этого возвращался бы указатель.
Динамическое выделение памяти не является непозволительной роскошью, реально используемой динамической памяти в каждый момент времени обычно сильно меньше, чем если бы память под все используемые данные была бы выделена статически.
И утечки тут не при чём, утечка - это когда память выделяется и не освобождается, в языках с динамической памятью и сборкой мусора нет явного освобождения, и если ссылок не осталось, то утечек не будет.
Да, в комментах не очень удобно форматировать текст. Спасибо за ответ. На основе этого я бы сказал, что та цитата из статьи, к которой я прицепился, содержит неверную информацию: на RTTI в ОЗУ тратится два байта.
Насчёт наследования классов - нифига, принципиальной разницы с наследованием интерфейсов нет.
Заодно новый вопрос: а вам сильно помогает хранить размер объекта в ОЗУ ? Он же одинаков для всех объектов одного класса, и его можно получать, обратившись по METADATA_ADDR. Я ещё могу понять массивы, но предполагаю, что длина массива у вас хранится явно и отдельно.
Я вот тоже хотел спросить, ntdll.dll - это, конечно, круто, но user32.dll, gdi32.dll, comctl32.dll, comdlg32.dll кто будет эмулировать? WINE это делает.