[HEX 0]

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

Литература на это тему есть?

[zltigo 0]

А без "литературы", просто подумать и сделать так, как разумно для этого случая?

[rezident 0]

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

У меня используется структура подкаталогов. Хидеры в каталоге _INC лежат, исходники в каталоге _LIB. Все пути в исходниках использую относительные. Общие для нескольких проектов исходники и хидеры лежат в одноименных каталогах, но уровнем выше. Перенести проект на другой диск или в другой подкаталог с сохранением структуры проекта не составляет особой сложности.

[HEX 0]

А без "литературы", просто подумать и сделать так, как разумно для этого случая?

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

[HEX 0]

У меня используется структура подкаталогов. Хидеры в каталоге _INC лежат, исходники в каталоге _LIB. Все пути в исходниках использую относительные. Общие для нескольких проектов исходники и хидеры лежат в одноименных каталогах, но уровнем выше. Перенести проект на другой диск или в другой подкаталог с сохранением структуры проекта не составляет особой сложности.

 

С хидерами вроде понятно, для подключения пишем:

#include "..\_LIB\file.h"

(порядок включения, как я понимаю, - после хидеров проекта, перед стандартной библиотекой)

Можно наврное, добавлять путь"..\_INC\" в опциях предпроцессора, но тогда будут проблемы при однаковых именах хидеров, и менее наглядно, чем "..\_LIB\file.h" - сразу видну что хидер из библиотеки.

 

А исходники библиотеки придется добовлять в проект? Чего лучше использовать исходники или объектные?

 

И еще вопрос, в чем приимущества перед размещением в toolkit_dir?

[zltigo 0]

С хидерами вроде понятно, для подключения пишем:

#include "..\_LIB\file.h"

Ну "наглядность" наглядностью, а возможность тасовки исходников резко снижается. Оптимальнее пути поиска все-же указывать компилятору.

(порядок включения, как я понимаю, - после хидеров проекта, перед стандартной библиотекой)

Ну для начала стандартные указвабтся прежде всего, ибо по опредлению совершенно не зависят от того, что Вы дальше напишите. Остальное.

А исходники библиотеки придется добовлять в проект? Чего лучше использовать исходники или объектные?

Лучше ни то, ни другое - лучше библиотеки. Ну они именно для этого сосданы и именно так и называются :)

[HEX 0]

Лучше ни то, ни другое - лучше библиотеки. Ну они именно для этого сосданы и именно так и называются :)

А как будет происходить отладка? можно будет посмотреть чего делается в модулях библиотеки?

 

Ну для начала стандартные указвабтся прежде всего, ибо по опредлению совершенно не зависят от того, что Вы дальше напишите. Остальное.

В умных книжках рекомендует включать хидеры от специализированных к более общим, цитата (в цитате) из книги Брюс Эккель Филосовия С++:

 

Заголовки включаются в порядке "отспециализированных к общим". Иначе говоря сначала включаются все заголовочные файлы в текущим каталоге, затем заголовочные файлы личного инструментария автора, затем заголовки стандартной библиотеки С++ и наконец, - заголовочные файлы библиотеки С.

Джон Лакос в своей книги "Large-Scale C++ Software Deign" так обосновывает эту последовательность

Автономная обработка h-файлов компонента (без внешних объявлений и определений) помогает предотвратить скрытые ошибки. Включение h-файла в самой первой строке c-файла гарантирует присутствие всей критически важной информации, относящейся к физическому интерфейса компонент (или ее отсутствие обнаружиться немедленно при попытке откомпилировать c-файл).

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

[Itch 0]

>>>Заголовки включаются в порядке "отспециализированных к общим".

 

Считаю это неправильным, т.к. я могу в своих *.h файлах задефайнить какое-нибудь слово, и оно вполне возможно, что уже продефайнено где-то еще, в стандартных библиотеках. То что продефайнил сам, то помнишь и используешь нормально. Если вдруг надо использовать дефайн из стандартной библиотеки, то тоже вероятность обнаружить коллизию больше.