- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
// https://godbolt.org/z/PPAWM0
#include <embed>
#include <cstdint>
constexpr std::uint64_t val_64_const = 0xcbf29ce484222325u;
constexpr std::uint64_t prime_64_const = 0x100000001b3u;
inline constexpr std::uint64_t
hash_64_fnv1a_const(const char* const ptr, std::size_t ptr_size, const std::uint64_t value = val_64_const) noexcept {
return (ptr_size == 1)
? value :
hash_64_fnv1a_const(&ptr[1],
ptr_size - 1,
(value ^ static_cast<std::uint64_t>(static_cast<char>(*ptr))) * prime_64_const);
}
int main () {
constexpr std::span<const char> art_data = std::embed("/dev/urandom", 32);
constexpr std::uint64_t actual = hash_64_fnv1a_const(art_data.data(), art_data.size());
return static_cast<int>(actual);
}
Follow us!
> Every C and C++ programmer -- at some point -- attempts to #include large chunks of non-C++ source into their code.
Если тупо нужно вклинить картинку в файл, можно обойтись и без этой хуйни. Можно объектник сделать из бинарника вот таким способом https://balau82.wordpress.com/2012/02/19/linking-a-binary-blob-with-gcc/
А если хотите крестовыми констэкспрами обрабатывать байтики которые подгружены из файлов, то вам наверно к врачу надо
Но можно ж встроить это в язык и не ебаться лишний раз?
JVM-поебень: умеет, никто не суёт видео
PHP (PHAR): умеет, никто не суёт видео
С++: лопаеца
> JVM-поебень: умеет, никто не суёт видео
> PHP (PHAR): умеет, никто не суёт видео
Что именно оно там умеет? Там в компилтайме можно допустим из встроенного видео взять такой-то кадр и сконвертить в JPG, байтики которого записать в массив? А в крестоговне это сделать вполне реально через эту хуйню, если переписать на constexpr-ы кодек для декодирования видео и конвертер в jpg.
Ну во-первых ресурсы можно хранить отдельными файлами, возьми какую-нибудь игрушку на ПК - там контент разбросан по разным файлам, и игра их подгружает в случае надобности. Нахуй все это запаковывать в один бинарник?
Если вспомнить например X-COM: UFO Defence https://ru.wikipedia.org/wiki/X-COM:_UFO_Defense
> Игра проходит в двух режимах, стратегическом («Geoscape») и тактическом («Battlescape»). Как считает автор GameSpy, игра объединяет игровой процесс серии Gold Box с 4X-игрой типа Master of Orion, и в результате получается смесь двух значительно разных игр. Технически в версии для DOS оба режима реализованы как два независимых исполняемых файла, которые вызывают друг друга при переходе игрока из одного режима в другой.
Т.е. там фактически было два разных бинарника. И ничего, никто от этого не умер.
Во-вторых, ладно хер бы с ним, пусть включают бинарник в файл какой-нибудь директивой, ну типа
Я против этого не возражаю, но мне это лично ничего не упрощает.
Но эти мудилы хотят этот файл обрабатывать в компилтайме крестовой constexpr метушней, вот это уже перебор.
http://govnokod.ru/25239#comment447520
чтобы поставлять это одним бинарником и не ебать мозг юзеру
Поэтому я за lua.
UE.
Насколько мне расказал знакомый, который думал где выбрать где разрабатывать игору. Посмотрел на UE, сказал что там на рендеринг такой жирнючий болт положили. Что в UE практически не возможно сделать песочницы, по типу майнкампфа. Зато зацените какой графоний, ну вы чего. В итоге знакомый плюнул на все эти движки и пошел свой писать на с++. Больше я его не видел.
другие движки не беру. Потому что блядогенератор в основном в этих "популиализированых" движков.
«JavaScript» от мира геймдева, чесслово.
Тогда лучше стрим на твиче.
в итоге разработчику просто она заебала, он решил бабос собрать и выпустил сырую игру как релиз и больше её не фиксит. Вот же гнида!
https://youtu.be/jKFKTkQKMf4
Для BW фиксы подвозят, но какие-то… мелкие. И раз в несколько месяцев, да.
Я не говорю, что всё всегда надо собирать одним бинарем, я говорю, что такая необходимость есть, и в вышеупомянутых языках она есть неспроста.
Нет, ты не понял. Эта херота в крестах только данные вклинивает (типа инициализируй мне вот такой-то массивчик байтиками из такого-то файла). Код ты так не вклинишь. Для вклинивания кода тебе надо статически линковать.
Или инклудить код в код
Интересно, через сколько десятилетий после введения этой фичи в Комитете обратят внимание на новомодные веяния под названием «ресурсы» — ну типа вон как в двадцатом веке в «PE»-файлах придумали, с типизацией и упорядоченностью.
> или генератор отчетов, который на выходе дает хтмл-страницу
Если ты засовываешь какой-то генератор отчетов в свою прогу, то ты очевидно засовываешь какой-то исполняемый код, который эти отчеты генерит (или я что-то не так понимаю?).
А вот эта херня из крестов, о которой этот говнокод - она позволяет только вставлять данные, не код.
Нет, ты конечно можешь допустим написать некий интерпретатор байткода (FORTH например), и потом через эту крестодрисню инжектить байткод, и потом его интерпретировать. Но это, как ты понимаешь, отдельный случай
Это типа как trial версии, когда спустя N дней прога перестает работать (только тут прога перестает компилироваться). Какие инновации)))
> To run your code, make sure you include an appropriate main() function, have the output window up, and then tick the ./a.out button!
Есть бекенд «ia16», генерирующий 16-битный код реального режима для 8086 (модель памяти только «Tiny», как для com-файлов). Можно попробовать его доработать, чтобы он не отдавал опкоды за пределами ASCII.
Есть готовый компилятор, генерирующий досовские экзешники, состоящие только из ASCII-кодов (модель памяти «Large», если не ошибаюсь):
http://tom7.org/abc/
Сам компилятор написан на языке «StandardML» (к сожалению, «OCaml» эти исходники не переваривает). Нидлес должен оценить.
http://tom7.org/abc/paper.txt
Для веса в неиспользуемые участки вложили текст документации. Сигнатура ZM вместо MZ, чтобы «Windows» не тратила время на поиск расширенной части (PE или NE).
Прочитать один оффсет и сравнить 4 байтика... Пиздец оптимизация, конечно.
А потом у меня появилась другая материнка, и апдейты я выпускать перестал.
The smalldatetime fields in SQL-Server databases will wrap around to January 1, 1900.
2067
... all sound recordings fixed before February 15, 1972, will enter the public domain in the U.S.
2038
32-bit computer clocks overflow to represent the date as December 13, 1901.
> The smalldatetime fields in SQL-Server databases will wrap around to January 1, 1900.
и ведь, сука, российские специалисты целой оравой будут бегать по всем стэковерфлоу, выясняя, что случилось.
те, кто поумнее - еще в 2079, но и в 2080 найдутся
2038-й год. Сломается весь софт, который хранит дату, как 32-битное смещение от начала UNIX EPOCH (1 января 1970).
В частности, тип TIMESTAMP в «MySQL»:
https://dev.mysql.com/doc/refman/5.7/en/datetime.html
Никто не запрещает хранить дату в 64-битном числе (BIGINT) или в DATETIME (поддерживает даты до 9999 года), но ведь для этого нужно успеть проинспектировать софт и заменить все упоминания типа TIMESTAMP.
Надо было дату в плавучих питухах хранить
В луникс-кернел то и дело мерджат патчи. Может всё и не сломается.
Но всяким андроидам (там до последнего времени было ядро 3.13) и "умному" китайскому ширпотребу, с vendor lockом, явно будет шандец.
У приложения может быть архив с фиксированным форматом дат. Кстати, а в каком формате сейчас хранится дата создания файла в популярных архиваторах? Перейдя на новый формат, сломаем совместимость. Понадобятся конверторы из одного формата в другой.
Да, андроидам и «умному» ширпотребу будет совсем плохо. Какие-то железки в один прекрасный момент могут превратиться в тыкву.
Включил и лег спать. На дворе шёл 2к38.
Проснулся: а кругом пожарные суетятся.
примерно так