В первой версии статьи, безжалостно отброшенной редактором, последний абзац был такой «Даже немного жаль, что продукция Intel очень надежна и слышать любимые мелодии вам придется мягко говоря нечасто.»
Думали. Но некоторые инженеры считали, что в любой работоспособной системе обязательно должен присутствовать звук бубна, а другие — возражали. Так что пока предложение нереализуемо.
Голосовое сообщение может быть также загружено в Intel Sound Control наряду с мелодией. Дискриминации по этому признаку (голос\инструмент), конечно же, не планируется!
С предустановленными мелодиями, конечно же, все совершенно легально. А вот с пользовательскими — проблемы могут возникнуть если серверная является публичным местом, например, пивным баром. Но и в этом случае ответственность за нелицензионную музыку лежит на установившем ее пользователе, а не на компании-производителе.
Хороший вопрос, простой ответ — значит, кроме считывания (и записи, которая также входит в тест) происходит что-то еще. Что именно — в данном случае неважно. Предпоследний абзац исходного текста, однако. Другие платформы — любопытно, да. Но мы сравниваем с WIC, которого там (пока) нет
Да, я ждала, что в комментариях еще библиотек напредлагают. Может, кто-нибудь когда-нибудь за это и возьмется. Задача — очень несложная, студенческая :). Плюс интересно не только и не сколько загрузка-сохранение, но и фильтрация, конвертация цвета и другие операции (хотя там наверняка победит Intel IPP)
На самом деле, спорить тут бесполезно — это вопрос из серии «Является ли фраза „варкалось, хливкие шорьки пырялись по мове“ написанной на русском языке или нет?» Но даже в вашей трактовке — код с UB -именно часть стандарта, так как он там есть. Т.е. в стандарте С нет ничего про нарисованные смайлики или ключевое слово class тк это — не часть языка С. А вот про выход за границу массива есть — именно что в этом случае поведение неопределено, т.е. это — часть языка.
Самое интересное из всех наблюдений. Спасибо! видимо, логика компилятора тут будет «раз вы сами так наплевательски к оптимизации относитесь, то и я вам ничего оптимизировать не буду» :)
Говоря про мой случай, я имею в виду не конкретный компилятор и систему, а то, что у меня подряд 2 массива из 4 int каждый. В таких условиях я не могу представить ни одной ситуации, когда компилятору зачем-либо понадобится вставить между ними что-либо. Перед первым — да, между — нет. Если вы сможете ее придумать, буду благодарна.
Но, считайте, что вы меня убедили и надо для полноты картины в начале вставить прагму компилятора, прямо запрещающую padding.
В моей структуре между двумя массивами без специальных ухищрений (=ключей компилятора) — не может. Это легко проверяемо. А в общем случае — да, бывает padding. Но мы его не рассматриваем.
Это — не особенность реализации, это — ваша особенность :) В смысле — у вас какие-то особенные структуры или особенный С. Цитата из стандарта «A structure type describes a sequentially allocated nonempty set of member objects
(and, in certain circumstances, an incomplete array), each of which has an optionally
specified name and possibly distinct type.»
Тут есть еще интересный момент. Компилятору в случае E1[E2] проверить выход за границу массива и, при желании, оптимизировать, элементарно. А вот как понять, что за границу массива вышел указатель? Компилятор единственное, что может сделать — разыменовать его и или дать элемент оттуда или, если это недоступная область памяти, выдать исключение (ошибку). Тем более, если я не как в примере возьму само имя массива в качестве указателя, а просто возьму «левый» указатель и присвою ему адрес начала массива. То есть, на практике UB в этом случае не будет никогда — только в теории. А для массивов — как видите, есть и в реальности
Но, считайте, что вы меня убедили и надо для полноты картины в начале вставить прагму компилятора, прямо запрещающую padding.
(and, in certain circumstances, an incomplete array), each of which has an optionally
specified name and possibly distinct type.»