ПРИМЕЧАНИЕ. Это очень похоже на ограничить квалификатор и арифметику указателя , но не является дубликатом. Автор этого поста присвоил результат операций над указателем restrict
тому же указателю, а я присвоил результат операций над указателем restrict
в качестве аргумента параметру функции restrict
.
Я понимаю значение restrict
по большей части, и я начинаю привыкать объявлять параметры функции restrict
всякий раз, когда это применимо. Но я не уверен, злоупотребляю ли я этим здесь или нет.
struct DynArray
{
void* data;
size_t elemCount;
size_t len;
};
void dyn_append(DynArray* restrict dst, const void* restrict src, size_t srcLen, size_t elemSize)
{
size_t oldElemCount = dst->elemCount;
dyn_setElemCount(dst, dst->elemCount + srcLen, elemSize); // might write to `*dst`
if (dst->data) // `dst->data` is set to `NULL` if reallocation fails.
// The next line might violate "restrict-ness" of `dst`.
memcpy((char*)dst->data + elemSize*oldElemCount, src, elemSize * srcLen);
}
В частности, я имею в виду (char*)dst->data + elemSize*oldElemCount
в вызове memcpy
. Если бы я передал сам dst
, а не приведенный выше аргумент, я знаю, что он был бы верным, поскольку я бы присвоил его параметру функции, которая сама является restrict
. Изменяет ли дело в данном случае тот факт, что аргумент является результатом операций над dst
, а не над самим dst
? Я полагаю, что гарантия того, что аргумент не будет псевдонимом, содержится в гарантии того, что dst
не будет псевдонимом.
dyn_setElemCount
не может записать вdst
, потому что он передается по значению. Если вы имеете в виду, что он записывает в память, на которую указываетdst
, то, пожалуйста, обновите вопрос, чтобы сказать об этом. Как обстоят дела, вопрос не ясен. - person M.M   schedule 15.12.2018dst->data
не наследуетrestrict
-ностьdst
- person M.M   schedule 15.12.2018src
сdst->data
. - person chux - Reinstate Monica   schedule 15.12.2018