[рукииз...] Как разрешить циклические зависимости?

Поступи так, как бы сделал любой человек, не знающий С.

Гуглить про forward declaration и incomplete type.

Это как?

Свалить всё в одну кучу.

мдя…))

struct _Window;
struct _Spots {
    ...
    struct _Window *window;
    ...
};

Не помогает. Как можно сделать forward declaration для структуры? А incomplete type тоже непонятно чем спасет.

Компилятор выдает такую ошибку:

ошибка: декларация 'struct _Window' внутри списка параметров

а, тьфу, функция…

struct _Window;
int func(..., struct _Window *, ...);

Спасибо! Я сначала extern перед struct _Window писал - компилятор матюкался. А так работает!..

В общем, если мне не хочется в каждом заголовочном файле дополнительно писать struct _Window, struct _Spots и т.п., то можно создать отдельный .h-файл, куда только это и записать, а его уже подключать в те файлы, где нужно разрешить циклическую зависимость?

struct _Window 

обращаю Ваше внимание на то что имена переменных начинающиеся с подчёркивания за которым идёт прописная буква зарезервированы для внутренних нужд, и, как минимум, их надо оборачивать в namespace, но лучше вообще не использовать

В общем, если мне не хочется в каждом заголовочном файле дополнительно писать struct _Window, struct _Spots и т.п., то можно создать отдельный .h-файл, куда только это и записать, а его уже подключать в те файлы, где нужно разрешить циклическую зависимость?

я обычно, увидев зачатки вот таких вот циклических зависимостей у себя в коде, начинаю подозревать bad design, ИЧСХ часто оказываюсь прав :)

Просто само имя Window у меня определяется как

typedef struct _Window Window;

Знаю, что это зло, но пока не нарывался, наступаю иногда на грабли...

Ну, я просто разнес функции, выполняющие разный функционал, в разные файлы. Файл gtk.c у меня и так уже за 1100 строк зашкалил - надо будет его тоже разбивать...

>А так работает!..

Это и есть forward declaration. Теперь надо изучить что такое incomplete type.

В общем, если мне не хочется в каждом заголовочном файле дополнительно писать struct _Window, struct _Spots и т.п., то можно создать отдельный .h-файл, куда только это и записать, а его уже подключать в те файлы, где нужно разрешить циклическую зависимость?

Использование #include в контексте .h файла надо минимизировать. Правда, это в первую очередь относится к С++.

это ты уже спроси совета у своего чувства прекрасного ;) но если тебе так часто приходится решать циклические зависимости, может проще навести порядок в хэдерах?

Это и есть forward declaration. Теперь надо изучить что такое incomplete type.

Честно говоря, чем там может спасти неполный тип, не представляю...

> typedef struct _Window Window;

typedef struct Window Window;

пока никто не отменял.

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

Да и не хочется лепить в один файл разнородные по смыслу функции.

Кроме того, не хочется слишком большие файлы лепить - ориентироваться в них очень тяжело (у меня и так перечень функций gtk.h в geany два экрана по вертикали занимает :) ).

Про такой вариант я и не подумал :)

ну сделайте

typedef struct { /* ... */ } Window;

или как-то по другому назовите, типа не _Window a window_struct, или, раз уж подчёркивание глянулось _window_struct, или ещё как (согласно Вашему code style)

и используйте первое подчёркивание только внутри своего namespace, иначе тоже можно налететь

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

> Честно говоря, чем там может спасти неполный тип, не представляю...

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

используйте первое подчёркивание только внутри своего namespace

У меня не «плюсы», а C.

А сделать

 typedef struct { /* ... */ } Window;

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

Спасибо, буду иметь в виду. Сейчас, пока не накопилось слишком много кода, поисправляю «косяки».

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

если не почистить, уйдёт гораздо больше времени, а уж если надо будет туда изменения вносить...

Да и не хочется лепить в один файл разнородные по смыслу функции.

Кроме того, не хочется слишком большие файлы лепить [..]

то, что Вы упомянули ни в коем случае не разгребание, это называется поддать огоньку

Так там же перекрестные ссылки. Дублировать заголовочные файлы не хочется. Да и у меня не библиотека, а небольшая программка.

У меня не «плюсы», а C.

Вы же Qt использовали, не?

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

не «можно», а только так и «нужно»

> Так там же перекрестные ссылки.

вот именно их я и предлагаю решить, отделив мух от котлет:

gtk.h:

typedef Window Window;

spots.h:

#include "gtk.h"
typedef Spots Spots;
int foo(Window *, Spots *);

gtk_p.h (приватный):

#include "gtk.h"
#include "spots.h"

struct Window {
	...
	Spots *spots;
	...
};

spots.c:

#include "gtk_p.h"
#include "spots.h"

struct Spots {
	...
};

int foo(Window *win, Spots *sp) {
	...
}

как-то так.

Нет, конечно. GTK.

Спасибо, понятно.