Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Очередная дрисня http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1040r0.html в крестоговне, теперь можно через std::embed прочитать какое-то говно и даже в constexpr с ним что-то делать, например считать хеш-сумму. Можно constexpr-компилятор сделать, который бы читал код через std::embed и через constexpr хуиту его обрабатывал и компилировал. Скажите им еще про миксины из D
А стоит ли встраивать в язык всякую такую поебень? Он не лопнет? Может еще сделать чтоб SVG и AVI файлы можно было прям в код в комментарии вставлять в качестве иллюстраций? Типа вот написал ты алгоритм бинарного поиска, и туда еще рядом хуйнул в коммент видео с лекцией о том, как это работает и что вот там логарифмическая сложность. Заебись фича же!
Или еще сделать чтоб ИИ в компилтайме прослушивал эту лекцию и на основе нее генерил код для бинарного поиска. И в разных компиляторах будут разные встроенные ИИ, некоторые при этом будут багнутый код генерить, и тогда надо будет лекцию фиксить. Программисты вместо программирования будут снимать лекции и встраивать их в код, а ИИ-компиляторы будет на их основе писать функции
> С#: умеет, никто не суёт видео
> 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 оба режима реализованы как два независимых исполняемых файла, которые вызывают друг друга при переходе игрока из одного режима в другой.
Т.е. там фактически было два разных бинарника. И ничего, никто от этого не умер.
Во-вторых, ладно хер бы с ним, пусть включают бинарник в файл какой-нибудь директивой, ну типа
char somefile[] = @@INCFILE(somefile.bin);
Я против этого не возражаю, но мне это лично ничего не упрощает.
Но эти мудилы хотят этот файл обрабатывать в компилтайме крестовой constexpr метушней, вот это уже перебор.
Я запихивал текстовый файл в бинарь на go, чтобы его нельзя было отредактировать просто так. Но делать такое на уровне метапрограммирования это как продолжение анекдота про молоток и гвозди
> Ну во-первых ресурсы можно хранить отдельными файлами, возьми какую-нибудь игрушку на ПК - там контент разбросан по разным файлам, и игра их подгружает в случае надобности. Нахуй все это запаковывать в один бинарник?
чтобы поставлять это одним бинарником и не ебать мозг юзеру
Ага, а обновления не связанные с кодом (например обновления графики и музыки) будут патчить бинарник. Охуенно придумал. И мододелы будут довольны, надо будет распидорашивать бинарник, менять размеры каких-то секций и прочей хуйни, если захочешь новый контент впихнуть или заменить старый.
Ну и кстати если всю хуйню тупо впихнуть в один исполняемый файл, то у тебя возможно оперативки не хватит. Call of Duty: Modern Warfare (2019) например 175 GB на диске требует со всякими там текстурами и прочей дрисней, и если ты это все засунешь в файл как массивы - догадайся что будет.
По этому я в своих разработках лоадю все говно по мере надобности. И по мере ненадобнасти шлю в помойку уже отработаное. Лоадить естественно надо отдельными потоками. А то я знаю такие инди и не только. Которые либо не знают что надо свою дрисню загружать по мере надобности. Лобо знают но не знают что такое многопоток, ох же весело.
Знаю одну индюшатинку, которая свои четыре гига ресов перед каждой загрузкой меню (начальный старт, каждый выход с сервера) грузит с ссд минуты по полторы… Я когда в первый раз увидел — натурально охуел.
поэтому я против unity подобие. Забавно что там обучают долбоебы которые даже не знают как правильно программировать игры, хотя они и знакомы с программированием в целом. В целом конторы которые ведут обучалку только и зарабатывают этим. развод. Там лишь из сотни единицы думают. И получаем огромный генератор блядоигор которые именно работают как из жопы а не как 1 doom.
UE.
Насколько мне расказал знакомый, который думал где выбрать где разрабатывать игору. Посмотрел на UE, сказал что там на рендеринг такой жирнючий болт положили. Что в UE практически не возможно сделать песочницы, по типу майнкампфа. Зато зацените какой графоний, ну вы чего. В итоге знакомый плюнул на все эти движки и пошел свой писать на с++. Больше я его не видел.
другие движки не беру. Потому что блядогенератор в основном в этих "популиализированых" движков.
Точно! Индоговно на «Unity» вселило в меня стойкое отвращение к этой быдлоплатформе. Вижу заставочное окошко «Unity» (ну, то, в котором ещё предлагается выбрать графоний и разрешение экрана) — понимаю, что, с очень большой вероятностью, после него будет крайне кривое, тормозное и глючное поделие, написанное дегенератами, не отличающими «C» от «C++».
да, я тоже возлагал большие надежды на игору под название "Kenshi".
в итоге разработчику просто она заебала, он решил бабос собрать и выпустил сырую игру как релиз и больше её не фиксит. Вот же гнида! https://youtu.be/jKFKTkQKMf4
Я не про колл оф дьюти, я про всякие консольные утилиты, которым часто нужна какая-то херота (тот же gradlew/gradle.jar например засунуть, или генератор отчетов, который на выходе дает хтмл-страницу). Которые весят по десятку мегабайт со всеми ресурсами.
Я не говорю, что всё всегда надо собирать одним бинарем, я говорю, что такая необходимость есть, и в вышеупомянутых языках она есть неспроста.
> тот же gradlew/gradle.jar например засунуть, или генератор отчетов, который на выходе дает хтмл-страницу)
Нет, ты не понял. Эта херота в крестах только данные вклинивает (типа инициализируй мне вот такой-то массивчик байтиками из такого-то файла). Код ты так не вклинишь. Для вклинивания кода тебе надо статически линковать.
> типа инициализируй мне вот такой-то массивчик байтиками из такого-то файла
Интересно, через сколько десятилетий после введения этой фичи в Комитете обратят внимание на новомодные веяния под названием «ресурсы» — ну типа вон как в двадцатом веке в «PE»-файлах придумали, с типизацией и упорядоченностью.
ресурсы влинковывались в файлы, и в этом нет ничего дурного. Линекр может насрать сколько нужно секций, ведь по сути влинковывание порнокартиники ничем не отличимо от влинковывания статического кода
А тут же речь о том, что это будет делать копулятор а это, согластесо, совсем другой калл-линкор
Ну так я и веду к тому, что, коли эту фичу с std::embed введут, её будут усиленно абузить для встраивания в бинарник всяческих картиночек, музычек и прочего говна. А через много лет Комитет посмотрит на это говно и заговностандартизирует какую-нибудь говно в виде «std::embed_resource», повторяющее (криво, косо и многословно) то, что сейчас наблюдается в PE/jar/etc.
> или генератор отчетов, который на выходе дает хтмл-страницу
Если ты засовываешь какой-то генератор отчетов в свою прогу, то ты очевидно засовываешь какой-то исполняемый код, который эти отчеты генерит (или я что-то не так понимаю?).
А вот эта херня из крестов, о которой этот говнокод - она позволяет только вставлять данные, не код.
Нет, ты конечно можешь допустим написать некий интерпретатор байткода (FORTH например), и потом через эту крестодрисню инжектить байткод, и потом его интерпретировать. Но это, как ты понимаешь, отдельный случай
Ну ок, можете засовывать. Я вообще нихуя не знаю что там у вас в жабах принято куда засовывать, я пишу прошивки для калькуляторов контроллеров и на всякие там жабы и шарпы смотрю сами знаете как на что.
Ещё с «Borland C» и «Borland Pascal» поставлялась программка «binobj.exe», которая из бинарника делала объектный файл, в котором объявлена публичная метка, чтобы его можно было прилинковать к программе и читать как массив.
Да и почему ограничились лишь чтением файлов? Давайте еще внедрим фичи чтоб файлы можно было записывать, удалять, создавать директории в компилтайме, и сокеты чтоб! Охуенно же, можно будет прямо в компилтайме спиздить какие-то файлы, или криптолокер запилить. Тогда антивирусным программам придется парсить крестоговно при проверке компа на компилтайм-вирусню, разве не охуенно?
Через сокеты в компилтайме в пределах одной машины это как-то анскильно, лучше shared memory в компилтайме. А через сокеты можно перебрасывать метушню если на нескольких отдельных компах компилировать одновременно, типа как OpenMPI какой-нибудь
Можно создать свои инпуты типа /dev/urandom с побочными эффектами, например:
/dev/write/start - очистить буфер, и открыть буфер контента
/dev/write/write/a - записать символ 'a' в буфер
... ну вы понели
/dev/write/file - очистить буфер, и открыть буфер имени файла
/dev/write/write/b
/dev/write/write/a
/dev/write/write/g
/dev/write/write/o
/dev/write/write/r
/dev/write/write/dot
/dev/write/write/t
/dev/write/write/x
/dev/write/write/t
/dev/write/flush
Чтобы «gcc» высирал ASCII-коды, нужно для него собрать специальный бекенд.
Есть бекенд «ia16», генерирующий 16-битный код реального режима для 8086 (модель памяти только «Tiny», как для com-файлов). Можно попробовать его доработать, чтобы он не отдавал опкоды за пределами ASCII.
Есть готовый компилятор, генерирующий досовские экзешники, состоящие только из ASCII-кодов (модель памяти «Large», если не ошибаюсь): http://tom7.org/abc/
Сам компилятор написан на языке «StandardML» (к сожалению, «OCaml» эти исходники не переваривает). Нидлес должен оценить.
Для веса в неиспользуемые участки вложили текст документации. Сигнатура ZM вместо MZ, чтобы «Windows» не тратила время на поиск расширенной части (PE или NE).
Тут, скорее всего, дело не в оптимизации, а в том, что то самое поле, которое должно содержать указатель на расширенную часть экзешника, может содержать некорректные данные.
https://en.wikipedia.org/wiki/2080s
2085
The Sega Dreamcast's internal clock will reach its limit. Any attempt to add a year to the date will result in the current year being shown as 1950
У меня была материнская плата под 80486 (сдохла из-за расслоения проводников во внутреннем слое) с «Award BIOS 4.5G» (не путать с «4.51PG»). Если поставить системную дату после 31 декабря 1999, то каждую полночь год сбрасывается на 2080 (или на какой-то другой, но я точно помню, что на нереальный). Разработчики не думали, что это говно доживёт до двухтысячного года. Я написал программу, которая считывает системную дату и меняет год на 2001. Прописал её в «AUTOEXEC.BAT». Это была моя первая программа на ассемблере. Занимала 15 байтиков. В следующем году выпустил апдейт этой программы: заменил 2001 на 2002.
А потом у меня появилась другая материнка, и апдейты я выпускать перестал.
> 2079
> The smalldatetime fields in SQL-Server databases will wrap around to January 1, 1900.
и ведь, сука, российские специалисты целой оравой будут бегать по всем стэковерфлоу, выясняя, что случилось.
те, кто поумнее - еще в 2079, но и в 2080 найдутся
Никто не запрещает хранить дату в 64-битном числе (BIGINT) или в DATETIME (поддерживает даты до 9999 года), но ведь для этого нужно успеть проинспектировать софт и заменить все упоминания типа TIMESTAMP.
Оттого, что в луникс-кернеле что-то пропатчат, тип даты в прикладных приложениях не изменится. Нужно, чтобы производитель программы что-то исправил. Нужно, чтобы пользователь обновил программу. Пользователем, кстати, может быть организация с суровой бюрократией.
У приложения может быть архив с фиксированным форматом дат. Кстати, а в каком формате сейчас хранится дата создания файла в популярных архиваторах? Перейдя на новый формат, сломаем совместимость. Понадобятся конверторы из одного формата в другой.
Да, андроидам и «умному» ширпотребу будет совсем плохо. Какие-то железки в один прекрасный момент могут превратиться в тыкву.
> 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 например), и потом через эту крестодрисню инжектить байткод, и потом его интерпретировать. Но это, как ты понимаешь, отдельный случай
/dev/write/start - очистить буфер, и открыть буфер контента
/dev/write/write/a - записать символ 'a' в буфер
... ну вы понели
/dev/write/file - очистить буфер, и открыть буфер имени файла
/dev/write/write/b
/dev/write/write/a
/dev/write/write/g
/dev/write/write/o
/dev/write/write/r
/dev/write/write/dot
/dev/write/write/t
/dev/write/write/x
/dev/write/write/t
/dev/write/flush
Это типа как trial версии, когда спустя N дней прога перестает работать (только тут прога перестает компилироваться). Какие инновации)))
P.S. Как в ебаном годболте код запустить? Не могу свою петушню проверить.
> 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 байтика... Пиздец оптимизация, конечно.
сколько раз соберешь -- столько раз получится разный код!
2085
The Sega Dreamcast's internal clock will reach its limit. Any attempt to add a year to the date will result in the current year being shown as 1950
какой бугор
А потом у меня появилась другая материнка, и апдейты я выпускать перестал.
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.
Проснулся: а кругом пожарные суетятся.
примерно так
Ну как, сказали?