Скрытие информации структуры C (непрозрачный указатель)

Как вы уже поняли, при использовании непрозрачного типа, такого как этот, основной исходный файл не может получить доступ к членам структуры и фактически не знает, насколько велика структура. Из-за этого вам нужны не только функции доступа для чтения / записи полей структуры, но вам также нужна функция для выделения памяти для структуры, поскольку только источник библиотеки знает определение и размер структуры.

Итак, ваш заголовочный файл будет содержать следующее:

typedef struct _structName structType_t;

structType_t *init();
void setVarA(structType_t *ptr, int valueA );
int getVarA(structType_t *ptr);
void cleanup(structType_t *ptr);

Этот интерфейс позволяет пользователю создавать экземпляр структуры, получать и устанавливать значения и очищать их. Исходный код библиотеки будет выглядеть так:

#include "struct_test.h"

struct _structName
{
    int varA;
    int varB;
    char varC;
};

structType_t *init()
{
    return malloc(sizeof(structType_t ));
}

void setVarA(structType_t *ptr, int valueA )
{
    ptr->varA = valueA;
}

int getVarA(structType_t *ptr)
{
    return ptr->varA;
}

void cleanup(structType_t *ptr)
{
    free(ptr);
}

Обратите внимание, что вам нужно определить typedef только один раз. Это и определяет псевдоним типа, и вперед объявляет структуру. Затем в исходном файле появляется фактическое определение структуры без typedef.

Функция init используется вызывающей стороной, чтобы выделить место для структуры и вернуть на нее указатель. Затем этот указатель можно передать функциям получения / установки.

Итак, теперь ваш основной код может использовать этот интерфейс следующим образом:

#include "struct_test.h"

int main()
{
    structType_t *s = init();
    setVarA(s, 5);
    printf("s->a=%d\n", getVarA(s));
    cleanup(s);l
}

Моя основная путаница заключается в том, где будут данные объекта структуры?

Дело в том, что вы не используете представление struct (то есть его размер, поля, макет и т. Д.) В других единицах перевода, а скорее вызываете функции, которые делают эту работу за вас. Для этого вам нужно использовать непрозрачный указатель, да.

как я могу добиться этого на моем простом примере?

Вы должны поместить все функции, которые используют поля структуры (настоящая структура) в один файл (реализация). Затем в заголовке предоставьте только интерфейс (функции, которые вы хотите, чтобы пользователи вызывали, и которые принимают непрозрачный указатель). Наконец, пользователи будут использовать заголовок для вызова только этих функций. Они не смогут вызывать какие-либо другие функции, и они не смогут узнать, что находится внутри структуры, поэтому код, пытающийся сделать это, не будет компилироваться (в этом суть!).

Более того, я не вижу преимуществ этого в относительно небольших встраиваемых проектах, где я являюсь производителем и потребителем модулей.

Это способ заставить модули быть независимыми друг от друга. Иногда его используют, чтобы скрыть реализации от клиентов или гарантировать стабильность ABI.

Но да, для внутреннего использования это обычно является обузой (и мешает оптимизации, поскольку все становится черным ящиком для компилятора, кроме случаев, когда вы используете LTO и т. Д.). Для этого лучше подходит синтаксический подход, такой как _2 _ / _ 3_ в других языках, например C ++.

Однако, если вы обязаны следовать MISRA в такой степени (т.е.если ваш проект должен следовать этому правилу, даже если он носит рекомендательный характер), вы мало что можете сделать.

Может ли кто-нибудь объяснить мне, действительно ли этот метод разумен для малых и средних встроенных проектов с 1-2 разработчиками, работающими с кодом?

Это зависит от вас. Есть очень большие проекты, которые не следуют этому совету и приносят успех. Обычно достаточно комментария для закрытых полей или соглашения об именах.

В сообщении упоминается, что доступ осуществляется с помощью методов интерфейса set / get, поэтому я попытался добавить что-то подобное:

void setVarA ( _structName *ptr, int valueA )
{
  ptr->varA = valueA;
}

But this also doesn't work because now he tells me that _structName is unknown...

Тип не _structName, а struct _structName или (как определено) structType_t.

И мой более важный вопрос все еще остается, где объект моей структуры находится в памяти.

С помощью этого метода будет метод, который возвращает адрес такого непрозрачного объекта. Он может быть размещен статически или динамически. Конечно, также должен быть способ освободить объект.

Более того, я не вижу преимуществ этого в относительно небольших встраиваемых проектах, где я являюсь производителем и потребителем модулей.

Я согласен с тобой.