Хочу чтобы опытные товарищи глянули и высказали критику.

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




В рамках проекта возникают модули, которые я делю на Lib1, Lib2, ..., LibN.
Для каждого Lib<number> создаю так сказать 'agregate'-хидер.

Все хидера складываю в один общий stdafx.hpp и делаю проект с опцией /Yc,
т.е. precompiled-headers.

Все компилируется. Разве что boost не компилируется )

Вопросы:
1) Может быть имеет разбить каждый Lib<number> на отдельные проекты и чтобы компилировались в *.lib файлы?
2) Я почему-то парюсь по поводу слишком много third-party библиотек. К примеру если уже boost есть, то врядли суну еще и Qt. Как часто у других возникает ситуация когда надо сунуть в проект казалось бы одинаковые по целям(хоть в чемто одинаковые)?

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

совершенно не понял вопроса...

мне только вот что интересно: stdafx.hpp - что означает это имя? как расшифровывается?

При создании нового проекта C++ Visual Studio генерит кучку файлов, которые составляют костяк приложения. Среди этих файлов имеются stdafx.h. В нем хранятся все "основные" include-ы проекта, но, как правило, не входящие в сам проект, т.е. файлы типа windows.h, stdio.h, afxwin.h.
Тока не понятно почему ТС переобозвал его в stdafx.hpp

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

Это сообщение отредактировал(а) Dem_max - 12.7.2012, 05:45

>>Тока не понятно почему ТС переобозвал его в stdafx.hpp
Потому что он немного отличается по строению от того файла что генерит студия по умолчанию.
Как правило делаю пустой проект, а потом создаю этот хидер руками и сам же потом донастраиваю
проект до компиляции с precompiled headers. Поэтому мне надо как-то сказать будущему читателю кода что мой stdafx отличается от стандартного и мне ничего лучшего не приходит в голову, кроме как сменить расширения.

>>это дело скомпилировать в LIB и скормить основному проекту.
Я уже задавал этот вопрос:


Сейчас при разработке проекта я логически разделяю приложение на компоненты, которые называю условно библиотеками, это и есть Lib1, Lib2, ... , LibN. Другое удачное название это "модуль". Реализация моих компонентов достаточно часто меняется, что-то фиксится, что-то добавляется, а что-то и удаляется. Как вывод при оформлении в static-либы может и не принести выигрыша, т.к. все равно будет компилироваться.

Добавлено через 7 минут и 22 секунды
По сути мой вопрос выливается в:
Имеет ли смысл модули приложения оформлять в static-библиотеки, не смотря на то что они достаточно часто меняются?
Частота изменения 1-2 раза в неделю.

Сейчас у меня произошла ситуация когда модуль получился достаточно удачным и я его решил использовать в другом приложении. В результате и возникла мысль о static-библиотеках и мне захотелось узнать, а как другие организовывают проекты? Может у них со временем из удачных компонентов вырастают собственные Framework-и?

Вобщем мне хочется чтобы другие поделились своим опытом

Я уже поднимал подобный вопрос. Почитай...

borisbn, 
Спасибо!!!

borisbn, 
Тема интересная, моя тема по сути-аналог src vs lib. Но там не освещен ряд вопросов которые мне интересны:
1) С.Майерс правил №30 стр.144 Эффективно программирование на С++. Никто не поделился опытом forward-деклараций и спасает ли он? Также никто не поделился опытом написания class handle(класс дескриптор), т.е. когда приватные пользовательские типы прячутся в приватный класс доступный по ссылке. Помогают ли кому на практике? Были ли баги, которые были с ними связаны?
2) Также никто не поделился опытом организации библиотек, пока нашел это на хабре: http://habrahabr.ru/post/138438/ ну и первая статья этого же автора
3) Также никто не сказал о том стоит ли стремиться сделать независимыми друг от друга и удается ли? К примере есть Errors.hpp объявленные ошибки в котором используются в двух модулях, стоит ли в папку с каждым модулем кинуть по копии или пусть будут errors.hpp-зависимы?

См. исходники КуТи

ИМХО, вопрос риторический

borisbn, 

Ну мне только смотреть и догадываться до тех или иных мотивов разработчиков QT и не факт что мои догадки будут верны. Мне куда интересней опыт людей до которых я хоть как-то могу дотянуться ) Можешь поделиться своим опытом?

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

т.е. простое размещение мемберов в private ?

а это не PIMPL?


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

Может я не так понимаю PIMPL... Я считал, что это типа такого

Я же использую такое

IMHO, немного отличается...
или же я ошибаюсь и оба варианта в общем называется PIMPL ?

Я тоже считаю это PIMPL


Простейшая фабрика, только в данный момент пришел к выводу что лучше использовать "Фабричный метод"

нет, только разновидности первого варианта..


фабрика там не центральный узел.. ее к примеру и в первый пример можно вставить..


так от задачи зависит же..

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

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

Добавлено через 8 минут и 41 секунду

спасает ? от чего ? 
он полезен при отделеннии зависимостей, чтоб получить чистый интерфейс (термин использован в общем  его значении)..