возник такой вопрос
допустим имеется определение класса в который вложены определения других классов
естественно все это трудно читаемо
кошерно-ли вынести оперделения вложенных классов в отдельные файлы, а затем эти файлы вставить посредством #include?
пример:

a.def


b.def


c.h

а что мешает сделать так:

файл detail/C.h


файл С.h

Lazin, хорошее решение, однако не всегда применимое:


...хотя можно и зафрендить...
но думаю найдутся и другие недостатки

Это сообщение отредактировал(а) J0ker - 6.5.2009, 22:52

Так не пойдет?

Добавлено через 6 минут и 16 секунд
J0ker

Насчет варианта с индклудами - это на мой взгляд не кашерно, ибо обявление класса дублируется и несмотря на то что он обявлен в private секции методом инклуда, его обявлении прекрасно будет фигурировать в глобальном пространстве имен нарушая всю вашу инкапсуляцию  

думаю не стоит так делать.

мне кажетеся Вам подойдет такой вариант : 









Оп...оказывается я опоздал с предложением ;)


Это сообщение отредактировал(а) mes - 7.5.2009, 00:00

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


это каким таким образом?


каким образом оно попадет в глобальное пространство?

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

если да, то 

  

Это сообщение отредактировал(а) mes - 7.5.2009, 01:45

mes, спасибо было лень самому копать   

Это сообщение отредактировал(а) J0ker - 7.5.2009, 08:51

методом прямого инклуда файла a.def 
не знаю можно ли это считать нарушением инкапсуляции, на самом деле если человеку не терпится навредить себе, он это сделает..ведь

еще не отменяли  
но в любом случае, вышеупомянутый вариант - лучше

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

А я что-то другое сказал?

теперь если я - пользователь класса сделаю у себя в начале файла
#include "b.def"
класс В попадет в мое глобальное пространство имен, и он не будет защищен секцией private. Я об этом.
т.е. мы даем пользователю возможность включить этот файл у себя. Ничего особо страшного, но лучше этого не позволять.

Это сообщение отредактировал(а) azesmcar - 7.5.2009, 09:02

а кто разрешает пользователю инклудить "не инклудные" файлы ?! 
J0ker же специально обозвал его *.def   
В таком случае однозначно ответственность на юзере. 
Также как если вдруг ему захочется заинклудить *cpp файл (хотя бывают случаи и с таким применением  )

ну, с большей долей вероятности при включении *cpp файла он получит ошибку времени линковки.

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

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

но, имхо, дело не в пользователe, а в самой постановке кода. Если есть более чистый вариант, зачем прибегать к трюкам ?! 

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



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


Это сообщение отредактировал(а) mes - 7.5.2009, 09:40

ну я и говорю



это те cpp шники которые специально для этого разработаны, я говорил не о них а об обычных.

ну так а b.def разве не специально разработан ?!      



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

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

boost/mem_fn.hpp

boost/bind/mem_fn_template.hpp

J0ker  
mes сказал немного выше что так поступают в стандартных библиотеках..но только когда другого выхода нет.

а наш boost/bind/mem_fn_template.hpp предназначен для включения в публичную секцию (хотя никто не зарпещает включить его глобально)


Это сообщение отредактировал(а) J0ker - 7.5.2009, 17:05

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