[c++] forward declaration для подструктуры.

typedef B::C * DataPtr;

Да. %)

т.е. A<B::C*> a;

> никому не кажется лишним правило о строгом порядке объявления?

Переходи на нормальные языки.

> P.S. никому не кажется лишним правило о строгом порядке объявления?

я считаю лишним

> Переходи на нормальные языки

на DCC? я там документации нашел 3 странички, а хаскель нормальным не считаю

s/DCC/DDC/

Убого же. Лучше вынести подструктуры во вне и typedef-ить всё подряд.

Я-то перешёл, а вот моя конторка не может себе позволить нанять цепепе-специалиста, студенты кругом. Какая уж тут речь о более других языках. Использование мною лиспа-то карается косыми взглядами, суки тупые.

> суки тупые

я вижу у вас здоровые отношения в коллективе

угу, троллинг наяву. %(

даже на чистом C желательно обьявлять, как

typedef struct mystruct {
...
} mystruct ;

> а хаскель нормальным не считаю

Твои проблемы.

>Убого же. Лучше вынести подструктуры во вне и typedef-ить всё подряд.

так в чем проблема вынести B::C наружу и не городить всякий говнокод?

>> P.S. никому не кажется лишним правило о строгом порядке объявления?

порядок пофиг

Структурированность - вещь, которую сложно понять другому человеку, имеющий, преимущественно, мусор в своей голове.

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

>Структурированность - вещь, которую сложно понять другому человеку, имеющий, преимущественно, мусор в своей голове.

это ты типа тонко тролльнул, да?

> вложенная запись читабельности не добавляет, а создание неймспейса дает такую же структурированность

Типа ты предлагаешь заменить родительскую структуру на якобы эквивалентный ей неймспейс?

>>Структурированность - вещь, которую сложно понять другому человеку, имеющий, преимущественно, мусор в своей голове.

это ты типа тонко тролльнул, да?

Это я послал луч дружбы.

>Это я послал луч дружбы.

Посылаю в ответку. Добро и любовь.

Так все-таки, что мешает вынести B::C в отдельный неймспейс?

> Типа ты предлагаешь заменить родительскую структуру на якобы эквивалентный ей неймспейс?

B, C в один неймспейс - и все дела( если хочется указать, что они стоят обособленно ), вообще во вменяемых проектах конструкции вроде

[code]
struct B {
struct C {
[/code]

практически не встречаются

> даже на чистом C желательно обьявлять, как
>
> typedef struct mystruct {
> ...
> } mystruct ;

И каков смысл такого действия в цепепе-коде?

>>Это я послал луч дружбы.
>Посылаю в ответку. Добро и любовь.
>Так все-таки, что мешает вынести B::C в отдельный неймспейс?

Уже можно создать экземпляр неймспейса? лол

Вы, лесторы, два брата-акробата и фанатики кривого стандарта?
Почему, всё то что нельзя сделать в рамках ебанутого стандарта признаётся как невменяемым?
Не встречается такое(?) видимо по причине недостаточной гибкости цепепе.

теперь понятно за что тебя не любят коллеги

>Уже можно создать экземпляр неймспейса? лол

????? скажите мне, что это тролль

Поподробнее, пожалуйста.

> Не встречается такое(?) видимо по причине недостаточной гибкости цепепе.

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

П.С. предлагаю спокойно продолжать обсуждение без взаимных оскорблений

> Поподробнее, пожалуйста.

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

>Не встречается такое(?) видимо по причине недостаточной гибкости цепепе.

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

Если очень хочется использовать в структуре другую, описанную в третьей, при этом используя первую из третьей, подумайте над тем, чтобы грамотно разнести описание структур в разные .h, максими возможного выносите в .cpp, а в .h пользуйтесь (по возможности) только объявлениями этих структур.

Но вообще такие перекрестные зависимости говорят о плохо продуманном интерфесе структур/классов или вообще всей программы.

P.S. не нравятся правила С++, используйте другой язык. Ибо он такой, какой он есть. Или сделайте свой с+++. Или пишите письма в комитет стандартизации языка. При текущем обосновании у вас, правда, нет шансов.

s/максими/максимум

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

struct Object1;
struct Object1::Data;
struct Object2;
struct Object2::Data;

struct Object1 {
  struct Data {
    ...
  };
  Data          *d1;
  Object2::Data *d2;
};

struct Object2 {
  struct Data {
    ...
  };
  Data *d2;
};

struct Object1Data;
struct Object2Data;

struct Object1 {
  typedef Object1Data Data;
  Data        *d1;
  Object2Data *d2;
};

struct Object2 {
  typedef Object2Data Data;
  Data *d2;
};

struct Object1Data {
  ...
};

struct Object2Data {
  ...
};

В первом варианте определение Data всегда перед глазами. Второй вариант чем читабельнее?

> По поводу тебя - это от опыта чтения твоих флеймов, а они лольные.

спасибо

В первом варианте определение Data всегда перед глазами

именно, что мешает рассматривать собс-но Object1 и Object2

во вменяемых проектах конструкции вроде

struct B {
struct C {

практически не встречаются

std::vector::iterator?

> std::vector::iterator?

ты правда посмотрел декларацию vector::iterator перед тем как привел его в пример?

>std::vector::iterator?

А что это? Мб имелось ввиду std::vector<T>::iterator?

>ты правда посмотрел декларацию vector::iterator перед тем как привел его в пример?

кстати да, там typedef

>>ты правда посмотрел декларацию vector::iterator перед тем как привел его в пример?

кстати да, там typedef

А что там ещё могло быть? Проблему в топике пока не решили, так что выбора нет. Я лишь хотел напомнить, что вложенные структуры бывают полезны. Но реализовывать их как вложенные, видимо, мешает фича языка.

фаел boost/smart_ptr/detail/spinlock_pool.hpp
подкласс template<int I> class spinlock_pool::scoped_lock

>> во вменяемых проектах конструкции вроде

struct B { struct C {

практически не встречаются

std::vector::iterator?

А что там ещё могло быть?

кажется кто-то уже забыл на что отвечал

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

приведя пример шаблонного класса без вложенной структуры

как бы классы( а тем более шаблонные ) - это отдельный разговор, мы ведь про структуры в стиле С изначально разговаривали, нет?

А что там ещё могло быть? Я лишь хотел напомнить, что вложенные структуры бывают полезны.

автору топика следовало бы сделать

struct CImpl{
    int ololo;
};

struct B
{
typedef CImpl *C;
C data;
}

тогда вариант B::C имеет право на жизнь.

Нет, мы ведём разговор о структурах в стиле цепепе, а в общем - о некоемых ADT завязанных друг на друге. %)

> Нет, мы ведём разговор о структурах в стиле цепепе

давайте тогда уточним - что кроме вложенности вам нужно от «структур в стиле цепепе»? я так понимаю в остальном вам нужен просто набор полей с данными?

> автору топика следовало бы сделать

Чистой воды воркэраунд. С шаблоном и то красивше смотрится. Давайте уже скажем, что прямолинейного решения поставленной задачи нет и тема рассосётся сама собой.

Какая разница-то? Нужна вся функциональность struct/class. Ты пытаешься найти изъян в дизайне?

> Какая разница-то? Нужна вся функциональность struct/class. Ты пытаешься найти изъян в дизайне?

а ты думаешь, что это нормальный дизайн, когда из B::C ты используешь А, полем которой B::C является? Да чтобы такое представить, нужно сойти с ума.

> а ты думаешь, что это нормальный дизайн, когда из B::C ты используешь А, полем которой B::C является?
Эмм... да, а что?
Можно узнать критерии нормальности дизайна или это как обычно - слепейший субъективизм?