Статью можно рассматривать как упражнение в метапрограммировании. В случае, когда надо сохранить порядок полей, можно вернуться к std::tuple. Пример, когда порядок полей важен, это синтаксис инициализации. Например, определённый порядок полей "красиво" вписывается в логику предметной области, а поменять его ради оптимального хранения в памяти - каждый раз глаз будет спотыкаться.
то размер будет 5, это неправильно (он должен быть 8)
Хорошее замечанение. Если это так, то серьёзная ошибка. Я проверил на godbolt, размер 8. Видимо, когда компилятор видит alignas перед массивом, он корректирует его sizeof до этого выравнивания.
Best Practices для современных ORM, типа Entity Framework, рекомендуют описывать "чистые" классы данных, без всякой ORM-разметки (так их можно переиспользовать например в клиентских проектах, не таща на фронт-энд в зависимости ORM-либы), а разметку выносить в отдельный модуль, который подключен только к бекэнду.
Я так понимаю, поле Name должно быть не как в БД - string, а свой тип, чтобы перегрузить оператор = Значит, классы моделей надо дублировать - для генератора запросов своё, для загрузки в них записей из БД - своё?
А ещё непонятно, в выражении Where(User.Name = 'Dan') что есть User? Как будто глобальная переменная, иначе как в этом контексте это становится синтаксически корректно.
То есть, "User" это какой-то искусственный класс, предназначенный только лишь для этого генератора, а User.Name - свойство с искусственным типом, которому надо перегрузить операции (арифметику, булевские и т.п.)?
Мобильные приложения, кстати, на Delphi создаются быстрее
До тех пор, пока не надо взаимодействовать с java-библиотеками. А то разработчик каких-нибудь смарт-часов выдаст в виде набора jar-файлов свою SDK, где надо регистрировать ресиверы в AndroidManifest и реализовывать их в виде своих классов, отнаследованных от его библиотечных, и приехали. Ну или какой-то клиент закапризничает и захочет нативный контрол, который 100 лет есть в XML-разметке Android Layout, но в FMX его нет / выглядит иначе.
Это следующий шаг после лямбд, который сделал C#. В данном выражении mydb.customers.Where(x => x.Name == "John") функция внутри скобок - не лямбда (т.е. не обычная функция, скомпилированная в код), а так называемое "дерево выражений" - это AST, который компилятор преобразовал в некоторый объект, данные которого доступны к анализу в рантайме, и его можно использовать во фрейморках, рекурсивно проходя по структуре выражения и транслируя его в SQL, например. Тут нужна серьёзная поддержка со стороны компилятора, но и возможности можно получить интересные.
А у вас на собеседовании можно пользоваться гуглом? Я вот тоже оцениваю свой SQL на 8 баллов, но не помню наизусть синтаксис круглых скобочек вокруг этих OVER и PARTITION BY. Когда мне надо написать запрос с оконной функцией, а это требуется примерно раз в полгода, я открываю справку по СУБД и переписываю оттуда.
На SO этот вопрос разобран (к сожалению, ответ не помечен как верный)
OWASP recommends that "[e]xcept for alphanumeric characters, [you should] escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of [an] attribute." So here's a function that does that, with a usage example:
function escapeHTML(unsafe) {
return unsafe.replace(
/[\u0000-\u002F\u003A-\u0040\u005B-\u0060\u007B-\u00FF]/g,
c => '&#' + ('000' + c.charCodeAt(0)).slice(-4) + ';'
)
}
Вообще странно что причиной проблемы тут указывается отсутствие encoding. Настоящая причина - весь пользовательский ввод, отображающийся в HTML, должен проходить через escape-фунцию, которая заменит <script> на < script >, а коды типа 0x1b на . Если так сделать, то и отсутствие encoding не позволит что-то эксплуатировать.
Просто добавление encoding не закрывает XSS-инъекции, при отсутствии экранирования пользовательского ввода. То есть, слона то вы и не заметили.
Характеристическая функция множества удобнее. Которая возвращает 0/1 (принадлежит/не принадлежит аргумент множеству). Тем более, у вас она явно присутствует под именем some_check. Не понимаю смысл такой обёртки, вижу лишь проблемы. Например, для классических характеристических функцих можно создавать комбинации. Типа
ВисокосныйГод(x) = ДелитсяНа4(x) И НЕ ДелитсяНа100(x)
Вы передаёте x=2024, и id-функция для ДелитсяНа100 - не определена, всё выражение - не определено. А должно быть определено.
плюс периодически засылать информацию о криптосделках
Не вижу разницы, что скрыть часть кошельков биткойна, что скрыть часть транзакций на кошельке zcash - ответственность одинаковая, для соглядатаев прозрачность та же самая.
Когда появились 64-битные армы, они позволяли выполнять 32-битный код. И в Android-прошивках была та же котовасия, что у Windows с SysWOW64 - отдельные папки с 32-битными либами для legacy приложений.
Сложно отделить, что есть векторизация, а что - жизненная необходимость. Сейчас все современные компиляторы генерят обычный, не векторный код работы с double/float под SSE 4.2, потому что там обычная арифметика на XMM-регистрах работает намного быстрее, чем FPU x87. Тот же Photoshop - нормальный софт? У него нет fallback на процессоры ниже Intel Core 2.
Что говорить под линукс, где всё собирается с максимальными оптимизациями, а исходники коммерческого софта часто недоступны, сами вы собрать не сможете.
Статью можно рассматривать как упражнение в метапрограммировании.
В случае, когда надо сохранить порядок полей, можно вернуться к std::tuple.
Пример, когда порядок полей важен, это синтаксис инициализации. Например, определённый порядок полей "красиво" вписывается в логику предметной области, а поменять его ради оптимального хранения в памяти - каждый раз глаз будет спотыкаться.
Хорошее замечанение. Если это так, то серьёзная ошибка. Я проверил на godbolt, размер 8.
Видимо, когда компилятор видит
alignasперед массивом, он корректирует егоsizeofдо этого выравнивания.Best Practices для современных ORM, типа Entity Framework, рекомендуют описывать "чистые" классы данных, без всякой ORM-разметки (так их можно переиспользовать например в клиентских проектах, не таща на фронт-энд в зависимости ORM-либы), а разметку выносить в отдельный модуль, который подключен только к бекэнду.
https://learn.microsoft.com/en-us/ef/core/modeling/
Fluent API вместо Data Annotation.
А неплохо. Плавает, как утка, крякает, как утка. Почти неотличимо от expression trees, но тут есть множество нюансов и ограничений.
Я так понимаю, поле Name должно быть не как в БД - string, а свой тип, чтобы перегрузить оператор =
Значит, классы моделей надо дублировать - для генератора запросов своё, для загрузки в них записей из БД - своё?
А ещё непонятно, в выражении
Where(User.Name = 'Dan')что естьUser?Как будто глобальная переменная, иначе как в этом контексте это становится синтаксически корректно.
То есть, "User" это какой-то искусственный класс, предназначенный только лишь для этого генератора, а User.Name - свойство с искусственным типом, которому надо перегрузить операции (арифметику, булевские и т.п.)?
Не понимаю, как это работает, если у java свой runtime. Банально, тип string от java не совпадает со string от delphi.
Да, это оно. Это рабочий пример?
Интересно, как оно реализовано.
Например, параметр функции Where имеет какой тип?
До тех пор, пока не надо взаимодействовать с java-библиотеками. А то разработчик каких-нибудь смарт-часов выдаст в виде набора jar-файлов свою SDK, где надо регистрировать ресиверы в AndroidManifest и реализовывать их в виде своих классов, отнаследованных от его библиотечных, и приехали. Ну или какой-то клиент закапризничает и захочет нативный контрол, который 100 лет есть в XML-разметке Android Layout, но в FMX его нет / выглядит иначе.
Это следующий шаг после лямбд, который сделал C#.
В данном выражении
mydb.customers.Where(x => x.Name == "John")функция внутри скобок - не лямбда (т.е. не обычная функция, скомпилированная в код), а так называемое "дерево выражений" - это AST, который компилятор преобразовал в некоторый объект, данные которого доступны к анализу в рантайме, и его можно использовать во фрейморках, рекурсивно проходя по структуре выражения и транслируя его в SQL, например. Тут нужна серьёзная поддержка со стороны компилятора, но и возможности можно получить интересные.
Троеточие в арифметическом выражении выглядит как псевдокод. Но ведь компилируется!
А у вас на собеседовании можно пользоваться гуглом? Я вот тоже оцениваю свой SQL на 8 баллов, но не помню наизусть синтаксис круглых скобочек вокруг этих OVER и PARTITION BY. Когда мне надо написать запрос с оконной функцией, а это требуется примерно раз в полгода, я открываю справку по СУБД и переписываю оттуда.
На SO этот вопрос разобран (к сожалению, ответ не помечен как верный)
Вообще странно что причиной проблемы тут указывается отсутствие encoding.
Настоящая причина - весь пользовательский ввод, отображающийся в HTML, должен проходить через escape-фунцию, которая заменит
<script>на< script >, а коды типа 0x1b на. Если так сделать, то и отсутствие encoding не позволит что-то эксплуатировать.Просто добавление encoding не закрывает XSS-инъекции, при отсутствии экранирования пользовательского ввода. То есть, слона то вы и не заметили.
Характеристическая функция множества удобнее. Которая возвращает 0/1 (принадлежит/не принадлежит аргумент множеству). Тем более, у вас она явно присутствует под именем some_check. Не понимаю смысл такой обёртки, вижу лишь проблемы. Например, для классических характеристических функцих можно создавать комбинации. Типа
Вы передаёте x=2024, и id-функция для ДелитсяНа100 - не определена, всё выражение - не определено. А должно быть определено.
Так и работает
Не вижу разницы, что скрыть часть кошельков биткойна, что скрыть часть транзакций на кошельке zcash - ответственность одинаковая, для соглядатаев прозрачность та же самая.
Не поможет. Регулирование приходит и к тем, кто варится в своём закрытом котелке
Когда появились 64-битные армы, они позволяли выполнять 32-битный код. И в Android-прошивках была та же котовасия, что у Windows с SysWOW64 - отдельные папки с 32-битными либами для legacy приложений.
Сложно отделить, что есть векторизация, а что - жизненная необходимость.
Сейчас все современные компиляторы генерят обычный, не векторный код работы с double/float под SSE 4.2, потому что там обычная арифметика на XMM-регистрах работает намного быстрее, чем FPU x87.
Тот же Photoshop - нормальный софт? У него нет fallback на процессоры ниже Intel Core 2.
Что говорить под линукс, где всё собирается с максимальными оптимизациями, а исходники коммерческого софта часто недоступны, сами вы собрать не сможете.
Да, именно фреймворк (необходимые приложению части) сейчас можно собрать вместе с приложением, и это обойдётся в 100-200 MB.