LINUX.ORG.RU

[3 часа ночи][C++] что не так в системе хедеров?

 


0

0

main.cpp:

#include "a.h"
#include "b.h"

int main() {}

a.h:

#ifndef A_H
#define A_H

#include "b.h"

struct A {
    bool someFlag;
    A (B inB);
};

#endif

b.h:

#ifndef B_H
#define B_H

#include "a.h"

struct B {
    bool someFlag;
    void SomeFunct (A inA);
};

#endif

a.cpp:

#include "a.h"

A::A(B inB) {
  flag=!inB.flag;
}

b.cpp:

#include "b.h"

void B::SomeFunct(A inA) {
  flag=inA.flag;
}

Попытка скомпилить:

% g++ ./main.cpp
In file included from ./a.h:4,
                 from ./main.cpp:3:
./b.h:8: ошибка: ‘A’ has not been declared

Что не так с инклудами и хедерами?

★★★★★

Последнее исправление: Obey-Kun (всего исправлений: 1)
Ответ на: комментарий от Obey-Kun

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

И тут: TestClass (Phased *inPhased) Вы определили конструктор принимающий указатель, а передаёте совсем не указатель: TestClass myTestClass(myPhased);

Booster ★★
()
Ответ на: комментарий от dilmah

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

а оверхед на копирование полей, хранящихся по значению тебя не смущает?

jtootf ★★★★★
()
Ответ на: комментарий от Booster

> И тут: TestClass (Phased *inPhased) Вы определили конструктор принимающий указатель, а передаёте совсем не указатель: TestClass myTestClass(myPhased);

Извиняюсь, это опечатка, исправил.

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

Как написать дефолтный конструктор? :S

Obey-Kun ★★★★★
() автор топика
Ответ на: комментарий от Obey-Kun

>Как написать дефолтный конструктор? :S
Phased(); То есть конструктор без параметров.

Booster ★★
()
Ответ на: комментарий от Booster

Стандартные решения в виде guard macro и #pragma не устраивают?

потому что они не решают этой проблемы, например. этого достаточно, чтобы они меня не устраивали

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>потому что они не решают этой проблемы, например. этого достаточно, чтобы они меня не устраивали
Аргументируйте.

Booster ★★
()
Ответ на: комментарий от Booster

пример проблемы - в топике, вот пояснение, почему оно не компилируется. guard'ы, как ты можешь заметить, на месте

неужели тебе действительно надо объяснять настолько очевидные вещи?

jtootf ★★★★★
()
Ответ на: комментарий от Booster

>>потому что они не решают этой проблемы, например. этого достаточно, чтобы они меня не устраивали

Аргументируйте.

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

Absurd ★★★
()
Ответ на: комментарий от Booster

#pragma тоже в этом случае не работает?

не работает

jtootf ★★★★★
()
Ответ на: комментарий от Booster

если у классов такие зависимости, то это признак чего-то плохого

не обязательно: альтернативы могут быть куда уродливей

jtootf ★★★★★
()
Ответ на: комментарий от Absurd

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

не без этого

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

Здесь аргумент лучше передавать по ссылке, с forward declaration. А если есть мемберы друг на друга, то это задача без указателей или ссылок вообще не решаема.

Booster ★★
()
Ответ на: комментарий от linuxfan

> А так предстваь себе квадратные глаза разработчика, когда он иклюдит хидер твоей библиотеки, а в ответ ему портянка из «не знаю, что такое int32_t/time_t».

пример более чем натянут

1. в «моем» стиле от простого инклуда никаких ошибок не будет, так то
2. проинклудив произвольный хедер большинства библиотек ты получишь гору ошибок - так как многие хедера и не должны использоваться «напрямую»
3. я всегда использую pch - потому «разработчик», если не поленится прочитать README, сразу найдет тот единственный хедер, который ему надо
4. ну и как раз хедеры из stdlib я не «стесняюсь» инклудить по месту надобности

lester ★★★★
()
Ответ на: комментарий от Miguel

Так хорошие практики или на C++?

компромисс, который хуже любой из альтернатив

jtootf ★★★★★
()
Ответ на: комментарий от lester

>2. проинклудив произвольный хедер большинства библиотек ты получишь гору ошибок - так как многие хедера и не должны использоваться «напрямую»

Правильно говорить «плюсовых горе-библиотек».

4. ну и как раз хедеры из stdlib я не «стесняюсь» инклудить по месту надобности

Чем хидер из stdlib отличается от любого другого? Включать общие хидеры один из другого — нормальная общепринятая практика. Скрывать детали реализации надо не в заголовочных файлах, включение которых приводит к ошибкам компиляции, а в откомпилированном исходном коде библиотек, хотя у плюсовки тут опять-таки огромные проблемы из-за горе-шаблонов.

linuxfan
()
Ответ на: комментарий от linuxfan

> Правильно говорить «плюсовых горе-библиотек».

да нет - как раз в основном это сишные библиотеки

Чем хидер из stdlib отличается от любого другого?


тем что нет смысла делать forward declaration для того же int32_t - почему догадайся сам

lester ★★★★
()
Ответ на: комментарий от lester

>тем что нет смысла делать forward declaration для того же int32_t - почему догадайся сам

А о существовании функций мы как-то забываем? Почему бы не зафорвардить всякие malloc'и?

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

linuxfan
()
Ответ на: комментарий от linuxfan

> Почему бы не зафорвардить всякие malloc'и?

ты идиот и это не лечится, malloc в хедере просто быть не должен

lester ★★★★
()
Ответ на: комментарий от lester

>ты идиот и это не лечится, malloc в хедере просто быть не должен

Что? Объявлений функций в хидере быть не должно? Плюсовики-затейники такие затейники :D

linuxfan
()
Ответ на: комментарий от lester

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

LamerOk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.