Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Для новичков > Организация проекта

Автор: EvilsInterrupt 11.7.2012, 23:42

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

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

Цитата

$(SolutionDirectory)\
    doc\ ................ project documentation, notes, descriptions
    include\ ............ common headers
    libs\ ............... Application libraries written by solution author
        Lib1\ ............ *.hpp, *.cpp - Lib1library
        Lib2\ ...... *.hpp, *.cpp - Lib2 library
...
        LibN\ ............. *.hpp, *.cpp - LibN library
    src\ ................ *.hpp, *.cpp - Application
    tests\ .............. test-samples, expected test-reports
    third_party\ ........ *.h, *.c, *.hpp, *.cpp - Another developers libraries
    tools\ .............. Project helper tools
    unit-tests\ ......... *Test.cpp - Boost.test based C++ tests

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

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

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

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

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

Автор: boostcoder 12.7.2012, 01:48

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

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

Автор: Dem_max 12.7.2012, 05:43

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

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

Автор: EvilsInterrupt 12.7.2012, 08:25

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

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

Цитата

1) Может быть имеет разбить каждый Lib<number> на отдельные проекты и чтобы компилировались в *.lib файлы?

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

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

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

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

Автор: borisbn 12.7.2012, 13:56

Я уже http://forum.vingrad.ru/forum/topic-346882/unread-1.html. Почитай...

Автор: EvilsInterrupt 12.7.2012, 13:57

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

Автор: EvilsInterrupt 12.7.2012, 15:11

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

Автор: borisbn 12.7.2012, 20:55

Цитата(EvilsInterrupt @ 12.7.2012, 15:11

)

Также никто не поделился опытом написания class handle(класс дескриптор), т.е. когда приватные пользовательские типы прячутся в приватный класс доступный по ссылке. Помогают ли кому на практике? Были ли баги, которые были с ними связаны?

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

Цитата(EvilsInterrupt @ 12.7.2012, 15:11

)

стоит ли в папку с каждым модулем кинуть по копии или пусть будут errors.hpp-зависимы?

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

Автор: EvilsInterrupt 13.7.2012, 10:34

borisbn,

Цитата

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

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

Автор: borisbn 13.7.2012, 10:37

Цитата(EvilsInterrupt @ 13.7.2012, 10:34

)

Можешь поделиться своим опытом?

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

Автор: EvilsInterrupt 13.7.2012, 10:38

Цитата

закрытой от пользователя имплементацией...

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

Автор: boostcoder 13.7.2012, 10:53

Цитата(borisbn @ 13.7.2012, 10:37

)

закрытой от пользователя имплементацией

а это не PIMPL?

Цитата(borisbn @ 13.7.2012, 10:37

)

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

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

Автор: borisbn 13.7.2012, 12:46

Цитата(boostcoder @ 13.7.2012, 10:53

)

а это не PIMPL?

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

Код

// h
class PrivateClass;

class PublicClass
{
public:
    void foo();
private:
    PrivateClass * priv_ptr;
};
// cpp
#include "PrivateClass.h"
PublicClass::PublicClass() {
    priv_ptr = new PrivateClass();
}
void PublicClass::foo() {
    priv_ptr->foo_impl();
}

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

Код

// common h
class PublicIFace
{
public:
    virtual void foo() = 0;
};
PublicIFace * createPublicIFace();
// impl h
class PrivateClass : public PublicIFace
{
public:
    void foo();
};
// impl cpp
PrivateClass::foo() {
...
}

PublicIFace * createPublicIFace() {
    return new PrivateClass();
}

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

Автор: EvilsInterrupt 13.7.2012, 13:00

Цитата

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

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

Цитата

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

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

Автор: mes 13.7.2012, 18:12

Цитата(borisbn @ 13.7.2012, 11:46

)

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

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

Цитата(EvilsInterrupt @ 13.7.2012, 12:00

)

Простейшая фабрика,

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

Цитата(EvilsInterrupt @ 13.7.2012, 12:00

)

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

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

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

Цитата(EvilsInterrupt @ 12.7.2012, 07:25

)

Имеет ли смысл модули приложения оформлять в static-библиотеки, не смотря на то что они достаточно часто меняются?

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

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

Цитата(EvilsInterrupt @ 12.7.2012, 14:11

)

Никто не поделился опытом forward-деклараций и спасает ли он?

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

Автор: EvilsInterrupt 13.7.2012, 19:56

Цитата

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

Не только. Если верить С.Майерсу и правилу 31 в "Эффективное программирование", то спасает от долгой компиляции проекта,т.е. "экономит" время.

>>в библиотеку стоит выделять не потому что редко меняется, а потому что это законченный по сути модуль..
Вопрос не в том что делать или не делать модуль. Вопрос в другом:
1) Можно создать папку и туда сложить все *.{h|c}pp, *.c, *.h относящиеся к модулю, а потом подключить к проекту и компилировать в таком виде
2) А можно к тому что в п.1 еще создать проект статик-библиотеки и в проекте использовать уже скомпилированный вариант

Кто и как предпочитает использовать модули проекта? В виде Сорцов или статик-библиотеки вот в чем вопрос!

Автор: mes 13.7.2012, 21:16

Цитата(EvilsInterrupt @ 13.7.2012, 18:56

)

Не только. Если верить С.Майерсу и правилу 31 в "Эффективное программирование", то спасает от долгой компиляции проекта,т.е. "экономит" время.

нет, forward declaration сам по себе не экономит ни капли времени компиляции.. Его экономит отсутствие зависимостей, не вынуждая парсить лишнее и перекомпилировать каждый модуль.. Другими словами экономия достигается целым рядом мер, где форвард один из вспомогательных инструментов..

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

Цитата(EvilsInterrupt @ 13.7.2012, 18:56

)

1) Можно...
2) А можно...

Кто и как предпочитает использовать модули проекта? В виде Сорцов или статик-библиотеки вот в чем вопрос!

Стакой постановкой вопроса, сомневаюсь, что дождетесь вразумительного ответа..
Грубо: ввиде сорцов, но при этом (если модуль созрел) подключать его как библиотеку smile

Автор: borisbn 13.7.2012, 22:04

Цитата(mes @ 13.7.2012, 21:16

)

Грубо: ввиде сорцов, но при этом (если модуль созрел) подключать его как библиотеку

вот крутилось на языке...
Именно так всегда и поступаю. Единственный минус этого совета - каждый должен сам определить, "созрел" ли модуль

Автор: mes 13.7.2012, 22:46

Цитата(borisbn @ 13.7.2012, 21:04

)

Единственный минус этого совета -

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