Я подозреваю, что компилятор не знает, сколько места ему нужно будет выделять для s [], если вы решите объявить с ним автоматическую переменную.
Я согласен с тем, что сказал Бен, объявить ваша структура
struct my_struct {
int n;
char s[1];
};
Кроме того, чтобы прояснить его комментарий о хранении, объявление char *s
не будет помещать структуру в стек (поскольку оно динамически распределено) и выделять s
в кучу, что он будет делать, это интерпретировать первые sizeof(char *)
байты вашего массива в качестве указателя, так что вы не будете работать с данными, которые, по вашему мнению, являетесь вами, и, вероятно, будут фатальными.
помните, что хотя операции с указателями и массивами могут быть реализованы одинаково, это не одно и то же.
Во-первых, для внешних библиотек я использовал бы vendor
, но это - просто предпочтение.
Во-вторых, я не думаю, что это - хорошая идея установить другие библиотеки в системном корне без пользовательского ведома. Самое главное, потому что это будет конфликтовать с более поздними установленными версиями тех библиотек. Таким образом, я думаю, что лучшее место для этих библиотек было бы в том же каталоге как Ваше приложение.
Вы могли также статически скомпилировать эти библиотеки в свою программу.
В предыдущем задании стандарт должен был установить их в каталоге, названном сторонним, и создать библиотеки тут же (в 3rdparty/LIBNAME/Debug, и т.д.).
Мы используем что-то с _ext или суффиксом _EXT (т.е. MyProject_EXT), чтобы показать, что это является внешним к нашему проекту сохранить исходный код внешних пакетов, против которых мы связываемся.
Я соглашаюсь с Peter. Внешние библиотеки должны быть не быть встроенными в системный корень, поскольку они могут вызвать конфликты. Я создал бы их в их каталоге и затем установил бы их в / каталог lib (или возможно/extlib), который уникален для Вашего приложения и ссылки на них там.