А ничего не произойдет. Выполнится 9-й инкремент и все.
А чего бы стоило ожидать? Ошибки доступа к памяти? Это все не имеет смысла.
Это же просто арифметика с оговоркой на размер типа данных. Никаких перескоков, зацикливаний и прочей мутной бурды ожидать не стоит. В арифметике все явно и однозначно.
То есть верно я понимаю вас?
Да, верно.
Или все таки Big Endian?
Порядок байт у системы спрашивай, у меня бесполезно.
Я ведь не знаю окружение, в котором ты собираешься и стартуешь. :)
synapse_people , по поводу выделения - все верно. 8 байт - это 2 по 4 байта. Твои 16 байт - это всего 4 uint32_t, так что ни о каких x32[14] и речи быть не может.
Порядок байт всегда системный. Он не зависит от приведения типов.
synapse_people , память будет переразмечена из типа uint8_t* в тип uint32_t*.
Адрес будет одинаковый, а вот операции с памятью уже будут как с беззнаковым целым длиной в 4 байта.
Каждая позиция x32 будет означать каждую четвертую позицию x.
Noortvel , не стоит это все писать в пояснениях к своему вопросу. Вопрос от этого понятнее не станет. :)
Тебе нужно отредактировать свой вопрос, записать развернутую постановку задачи.
В конечном итоге твоя будущая профессия начинается с грамотной постановки задачи. Иначе, хоть ты и сможешь отучиться, и если сможешь, ценности из себя представлять не будешь еще очень долго.
Ты все паришься со сборкой проекта в студенческой лаборатории? FastBuild все тот-же тебе поможет.
Проверь возможность запуска в лаборатории операцинки с флешки. Если сработает, ты решишь задачу малой кровью.
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++: Библиотека программиста от Джеффа Элджера.
Книги все старые, но понимание дадут. После этого добра можно будет и за Эффективный и современный С++ от Скотта Мейерса взяться.
А ничего не произойдет. Выполнится 9-й инкремент и все.
А чего бы стоило ожидать? Ошибки доступа к памяти? Это все не имеет смысла.
Это же просто арифметика с оговоркой на размер типа данных. Никаких перескоков, зацикливаний и прочей мутной бурды ожидать не стоит. В арифметике все явно и однозначно.
Да, верно.
Порядок байт у системы спрашивай, у меня бесполезно.
Я ведь не знаю окружение, в котором ты собираешься и стартуешь. :)