Noortvel , зачем тебе такая штука? Что ты с ней собрался делать? Какая у нее цель существования? Какой круг решаемых задач?
В какой "один файл" эта штука должна все собирать? Что "все" надо собирать? Какие #include и #define она должна вставлять, куда она должна их вставлять?
Почему компилятор должен уметь что-то декомпилировать?
Сделай, пожалуйста, развернутую постановку вопроса. Из текущего сумбура ничего непонятно.
Виталий Катомин , слой API я бы тоже рекомендовал выделить в отдельную подсистему.
Думай в этом плане инструментами. Мы всегда сперва делаем простой инструмент, а потом с его помощью делаем более сложный.
Уровень API имеет свой смысл, свои правила и свои зависимости. На этом уровне уже совершенно незачем знать о механизмах работы подсистем данных. API надо уметь легко вводить и менять, поэтому на этом уровне лучше всего оперировать утилитарными подсистемами.
А вот на счет утилитарных подсистем можно сказать так. Это не важно, как именно подсистема выполняет свои функции. Если у тебя есть возможность сделать так, чтобы от фильмов получить один кусок, от актеров - другой, от рейтингов - третий, потом ничего о самих этих данных не зная собрать из них прямой SQL-запрос, то можно так и сделать.
Важно понимать только одно, структуру данных в хранилище знает только подсистема данных, она может помочь сформировать более специализированный запрос для драйвера хранилища.
Если же такой возможности нет, то функциональность надо вводить любым другим разумным и доступным способом.
Артем Филимонов , это отладочная куча MSVC++.
Это не очень удобный интерфейс. Он тебе не даст стека места выделения памяти, не даст типа, который был использован для выделения. Он просто скажет, что память потекла.
Вот тут есть статья по этому вопросу. До VLD я использовал отладочную кучу и сильно напрягал моск в случае утечек. Отлов места утечки становится не совсем удобным.
Искандер Мамедов , C - это ограничение? C++ и STL нельзя? А если и можно, то можно ли C++11/14?
На счет буферов. Ring buffer рассматривал, знаком с термином? Его можно использовать или нужна именно пачка буферов постоянной длины? Или можно/нужно использовать пачку циклических буферов?
Циклический буфер можно сделать по принципу Lock-Free, тогда у тебя не будет проблем синхронизации чтения и записи, а throttling с обоих концов сделается без проблем.
Не могу на это ответить. Не знаю.
Мои принципы разработки позволяют мне отлаживаться только в MSVC++, где и применяется VLD, а на все остальные платформы я собираюсь без опаски.
Denis Gaydak , еще, обычно, текстуры так готовят перед сжатием в аппаратные форматы. ATC/PVR или DXT могут давать артефакты на границах альфы. Это очень неприятно выглядит и сильно бросается в глаза.
Заливка фона темным не решает эту проблему, а вот bleeding ее безвозвратно устраняет.
Laguna_Seca , ссылку на приложение в вопрос. Чтобы уж точно знать, кого банить за накрутку.
А если приложение и правда годное и ты действительно уже вложился в его качество, то тем более давай ссылку, тебе каждый мимо проходящий просто честно отзыв сделает и, может, даже по виралке пустит.
Alex Void , больше информации!
Что за клиент? Что за сервер? Почему выбраны именно эти языки и именно в таком порядке? Почему не наоборот? Какие целевые платформы клиента? Какова частота обмена данными? Каковы ожидания по средней и пиковой полосе пропускания исходящего трафика с клиента, каковы - с сервера? Покажи графики расчетов по ожидаемой динамике сетевого обмена.
На каком основании форматом данных выбран json? Почему не бинарный? Почему не любой другой?
Любое инженерное решение - это результат выверенных расчетов и ряда экспериментальных проверок. Решение выводится на основе имеющихся данных, а данных-то, собственно, и нету. Не с потолка же люди будут брать все эти данные чтобы посоветовать тебе определенные решения? :)
Если такие типы тебе не знакомы, то сперва тебе стоит ознакомиться с поясняющей литературой относительно STL.
Например, подойдет Стандартная библиотека C++ Николая Джосаттиса или что-нибудь от Греба Саттера или Скотта Мейерса.
А для понимания принципов работы стандартной библиотеки тебе стоит прочитать как минимум Шаблоны C++ Девида Вандервуда или хотя бы C++: Библиотека программиста от Джеффа Элджера.
Книги все старые, но понимание дадут. После этого добра можно будет и за Эффективный и современный С++ от Скотта Мейерса взяться.
Frip , это не массив классов. Это массив объектов определенного класса.
У тебя все непонятно потому что ты термины используешь не так, как люди привыкли.
Напиши кодом прямо в вопросе. Возможно тогда на вопрос получится ответить.
sudo rm -rf / , добавлю свои 5 копеек ответу Сергея.
Код и правда странный. Для обеспечения совместимости с разными контейнерами куда удобнее использовать std::begin и std::end.
все эти новомодные 21:9 или тем более 32:9 мутанты, прости господи. Не забывайте, что программист работает с листингами текста
21:9 - это игровые или медийные решения. С такими мониторами удобнее работать в программах обработки видео или звука (где много длинных таймлайнов). Опять же, медицинский софт лучше выглядит на мониторе 21:9. 32:9 монитор системными средствами бьется на два рабочих стола по 16:9, в каждом из которых помещаются все нужные инструменты. Они создаются уже для этого.
Плюсами такого оборудования будут:
- Неразрывность пространства между рабочими столами (нет физических смещений, перекосов и толстой черной рамки двух соседствующих мониторов),
- единая цветопередача (как матрицы разных мониторов не настраивай, а показывать будут разное),
- возможность быстрой реконфигурации в три или четыре рабочих стола на лету (не надо дергать провода и выключать мониторы).
А параболическое искривление экрана дает практически одинаковое расстояние взгляда по всей площади монитора.
В общем, 32:9 - это инструмент, смысл и удобство которого еще только предстоит понять.
Qubc , en.cppreference.com/w/cpp/language/main_function
Более полной формой определения main является третий вариант. Все остальные - лишь сужения этой формы.
Форма void main(void) является самой узкой и, как видишь, отсутствует в стандарте, она нестандартна. Не все компиляторы согласятся воспринимать ее.
В какой "один файл" эта штука должна все собирать? Что "все" надо собирать? Какие #include и #define она должна вставлять, куда она должна их вставлять?
Почему компилятор должен уметь что-то декомпилировать?
Сделай, пожалуйста, развернутую постановку вопроса. Из текущего сумбура ничего непонятно.