Вы заставили меня очень сильно задуматься) В том смысле, что я фактически сейчас пишу проигрыватель с нуля не опираясь на ffplay и сейчас задаюсь вопросом, действительно ли оно мне надо - все-таки это не так просто, особенно в паре с аудио.
Я смотрел на реализацию плеера ffplay.c за вдохновением, но вдохновения не случилось, потому что там все очень заковыристо :) Но если пойти вашим путем и замести все эти заковырки за красивый фасад, то кому какое дело. Я попробую посмотреть в эту сторону, спасибо за идею
Очень интересное решение! Я правильно понял, что вы просто забрали исходный код и попытались скомпилировать его с нуля в обход их системы сборки?
Так же интересуют подробности по внедрению целого ffplay в свое приложение. Я знаком с ffplay, и даже использовал его несколько раз в своих нуждах. Но я так понимаю - это само по себе готовое приложение, использующее библиотеку ffmpeg, просто очень тесно вплетенное в репозиторий и даже собирающееся по дефолту системой сборки. Вы судя по всему просто адаптировали код ffplay.c под свои нужды и как-то встроили в код своего приложения? Фактически, это модификация ffplay, или обвязка вокруг него, если можно так сказать?
Да, при сборке ffmpeg можно конфигурировать очень гибко и повыбрасывать из него очень многое. Я не уверен, до каких пределов его можно ужать и, боюсь, это придется проверять экспериментально методом проб, ошибок и крашей, если вырезал слишком много
Ну, если следовать по проторенной инструкции, сложности нет :) А так вы правы - самое попившее кровь - это то, что вы перечислили. Просто мне не сразу довелось прийти к этим хакам - подсказки лежали то тут, то там в разных мануалах от разных людей
Даже не знаю, как реагировать. Давайте смотреть, что предложил этот ИИ:
Если вы хотите оставить массив структур (AoS), можно упаковать возраст, роль и ID в одно целое число.
В итоге в предложенном коде возраст, роль и ID упакованы в одно целое число не были. Уже весело.
Теперь к заявленным 12 байтам:
Вместо 8-байтного указателя на roleData (void* / variant), используйте 4-байтный индекс в отдельном массиве с данными ролей
То есть ИИ унесла часть данных неизвестно куда из структуры и даже не объяснила, куда конкретно, и как это будет работать для каждого сотрудника, и почему суммарная память (вместе с мифическим массивом) будет меньше того, что было
То, что размер структуры можно уменьшить еще больше - это 100%. Но то, что вы кинули называется AI-слопом.
UPD: я посчитал, что статья была бы неполной, если не привести известные мне способы увидеть глазами memory layout интересующей нас структуры. Заинтересованным читать главу "Appendix I. Узнаем memory layout".
Буду рад, если вы поделитесь своими способами - хорошими, плохими, злыми - любые подойдут.
Я прикрылся параграфом "Дисклеймеры, оговорки" :) Но в целом согласен - зоопарк возможных платформ бесконечен, поэтому ничего точного в абсолюте быть не может. Но это тем не менее не мешает людям рассуждать о порядке полей, padding и пытаться уменьшить свои структуры.
Я даже какое-то время поддерживал пропиетарный компилятор, где char был равен машинному слову, потому что почему бы нет, поэтому не понаслышке знаю, что все действительно возможно.
Ну а читать/писать сырые данные между платформами - это совсем иная история, статья не про это, тут надо писать отдельную. И ее лучше писать вам :) у вас, кажется, обширный опыт в этой теме. Я могу козырнуть лишь #pragma pack, но подозреваю, что это не панацея. Особенно если еще есть разница LE/BE
Ухх, какой подлый нюанс :) Он мне был не известен. Выходит, чтобы теоретически обезапаситься, есть два пути:
Пойти вашим путем и тотально замести все поля под private
Наоборот занести все под public, посыпать "приватные" поля комментариями "НЕ ТРОГАТЬ", а голову посыпать пеплом
Мне вот интересно, если есть компилятор, который пользуется этой лазейкой, то как мог бы выглядеть порядок полей у класса с public и private секцией? public в памяти четные, private - нечетные? :)
предлагаемый вами код не будет некорректным, но он и не обязателен для trivially constructible типов - UB не случится, поскольку для таких типо lifetime неявно начинается при первой записи в такой объект.
а по ревью Pool могу до кучи докинуть, что в ассерте
static_assert(sizeof(T) >= sizeof(FreeNode*), "Object too small for pool");
автор все же наверное имел в виду sizeof(FreeNode) (без указателя). правда для данной конкретной структуры эти размеры по счастливому совпадению равны, так что ошибка носит исключительно семантический характер
у вас статья не дочитана
Вы заставили меня очень сильно задуматься) В том смысле, что я фактически сейчас пишу проигрыватель с нуля не опираясь на ffplay и сейчас задаюсь вопросом, действительно ли оно мне надо - все-таки это не так просто, особенно в паре с аудио.
Я смотрел на реализацию плеера ffplay.c за вдохновением, но вдохновения не случилось, потому что там все очень заковыристо :) Но если пойти вашим путем и замести все эти заковырки за красивый фасад, то кому какое дело. Я попробую посмотреть в эту сторону, спасибо за идею
Очень интересное решение! Я правильно понял, что вы просто забрали исходный код и попытались скомпилировать его с нуля в обход их системы сборки?
Так же интересуют подробности по внедрению целого ffplay в свое приложение. Я знаком с ffplay, и даже использовал его несколько раз в своих нуждах. Но я так понимаю - это само по себе готовое приложение, использующее библиотеку ffmpeg, просто очень тесно вплетенное в репозиторий и даже собирающееся по дефолту системой сборки. Вы судя по всему просто адаптировали код ffplay.c под свои нужды и как-то встроили в код своего приложения? Фактически, это модификация ffplay, или обвязка вокруг него, если можно так сказать?
Да, при сборке ffmpeg можно конфигурировать очень гибко и повыбрасывать из него очень многое. Я не уверен, до каких пределов его можно ужать и, боюсь, это придется проверять экспериментально методом проб, ошибок и крашей, если вырезал слишком много
Ну, если следовать по проторенной инструкции, сложности нет :)
А так вы правы - самое попившее кровь - это то, что вы перечислили. Просто мне не сразу довелось прийти к этим хакам - подсказки лежали то тут, то там в разных мануалах от разных людей
Супер! Можно какую-то ссылку? Боюсь найти не то
очень даже нравится
да, мне нужна была кастомная сборка
мне если честно ваш вариант с форком не пришел в голову, так же как вам мой :) а что, таким образом можно будет получить сборку msvc-тулчейном?
Даже не знаю, как реагировать. Давайте смотреть, что предложил этот ИИ:
В итоге в предложенном коде возраст, роль и ID упакованы в одно целое число не были. Уже весело.
Теперь к заявленным 12 байтам:
То есть ИИ унесла часть данных неизвестно куда из структуры и даже не объяснила, куда конкретно, и как это будет работать для каждого сотрудника, и почему суммарная память (вместе с мифическим массивом) будет меньше того, что было
То, что размер структуры можно уменьшить еще больше - это 100%. Но то, что вы кинули называется AI-слопом.
шикарно, спасибо!
Мы так же от них отказались - есть опасения за совместимость с версиями игры под консоли
достойные извороты) прятать информацию в чужих битах - самое приятное
UPD: я посчитал, что статья была бы неполной, если не привести известные мне способы увидеть глазами memory layout интересующей нас структуры. Заинтересованным читать главу "Appendix I. Узнаем memory layout".
Буду рад, если вы поделитесь своими способами - хорошими, плохими, злыми - любые подойдут.
Я прикрылся параграфом "Дисклеймеры, оговорки" :) Но в целом согласен - зоопарк возможных платформ бесконечен, поэтому ничего точного в абсолюте быть не может. Но это тем не менее не мешает людям рассуждать о порядке полей, padding и пытаться уменьшить свои структуры.
Я даже какое-то время поддерживал пропиетарный компилятор, где char был равен машинному слову, потому что почему бы нет, поэтому не понаслышке знаю, что все действительно возможно.
Ну а читать/писать сырые данные между платформами - это совсем иная история, статья не про это, тут надо писать отдельную. И ее лучше писать вам :) у вас, кажется, обширный опыт в этой теме. Я могу козырнуть лишь #pragma pack, но подозреваю, что это не панацея. Особенно если еще есть разница LE/BE
Ухх, какой подлый нюанс :) Он мне был не известен. Выходит, чтобы теоретически обезапаситься, есть два пути:
Пойти вашим путем и тотально замести все поля под private
Наоборот занести все под public, посыпать "приватные" поля комментариями "НЕ ТРОГАТЬ", а голову посыпать пеплом
Мне вот интересно, если есть компилятор, который пользуется этой лазейкой, то как мог бы выглядеть порядок полей у класса с public и private секцией? public в памяти четные, private - нечетные? :)
пункт 2 про lifetime:
предлагаемый вами код не будет некорректным, но он и не обязателен для trivially constructible типов - UB не случится, поскольку для таких типо lifetime неявно начинается при первой записи в такой объект.
а по ревью
Poolмогу до кучи докинуть, что в ассертеавтор все же наверное имел в виду
sizeof(FreeNode)(без указателя). правда для данной конкретной структуры эти размеры по счастливому совпадению равны, так что ошибка носит исключительно семантический характермне чето как-то сразу вспомнились ffmpeg и компиляторы, и я орнул с тезиса
что это даст?
ааа, я-то думал, почему статья вскрыла столько желчных личностей. а это один и тот же образец
вы просто не в курсе, сколько стоит ваш час