Здравствуйте!
Имеется проект, содержащий большое количество взаимодействующих между собой классов с большим количеством полей и методов в каждом из них.
Мы пожелали использовать внутри своего проекта стороннюю библиотеку, для чего добавили в текущий проект заголовочные файлы.
После попытки скомпилировать проект выяснилось, что данная сторонняя библиотека содержит в себе уже используюмую переменную в нашем проектею
Получился конфликт имен.
Выходом из такой ситуации считается заключить переменную с одинаковым именем (но разными типами) в нашем проекте в отдельную область видимости и для каждого обращения к этой переменной в нашем проекте добавить спецификатор данной области видимости.
Вполне логичное решение, за исключением того, что размеры проекта немаленькие и изменения могут занять большое количество времени.
Существуют ли какие-либо альтернативные методы разрешения конфликта имен кроме указанного мною?
Спасибо.
Алексей

Напишите класс-фасад к этой библиотеке, а к ваших исходникам подключайте только заголовочный файл этого класса-фасада.

On 01/26/2012 04:22 PM, Handler wrote:

Если платформа Win32/64, и НЕЛЬЗЯ изменять код,
и эти переменные с одинаковыми именами используются только
соответственно в этой новой библиотеке и в вашей библиотеке,
то есть ещё возможность разрешить конфликт при помощи использования
разделения по исполняемым модулям, т.е. динамического сзязывания.
(положить ваш код и код новой библиотеки в разные .dll или .exe)

Здравствуйте, Handler, Вы писали:

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

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, Handler, Вы писали:

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

К моем большому сожалению, мой уровень не позволяет мне пока называться программистом — я только учусь. Поэтому я не использовал до сих пор технологию неймспейсов так как небыло в том необходимости.
С другой стороны, я не могу просто в заголовочном файле написать
using namespace mySpace;
Мне приходится для каждой переменной явно указывать область видимости, и Вы сами понимаете, как это громмоздко.
Вот поэтому я и спросил про методы разрешения конфликтов имен здесь.
Способ разделения по модулям интересный

On 01/30/2012 04:37 PM, Handler wrote:
> С другой стороны, я не могу просто в заголовочном файле написать
> using namespace mySpace;

Никогда не пиши
using namespace XXX;
в заголовочных файлах.

Здравствуйте, Handler, Вы писали:

H>К моем большому сожалению, мой уровень не позволяет мне пока называться программистом — я только учусь. Поэтому я не использовал до сих пор технологию неймспейсов так как небыло в том необходимости.
H>С другой стороны, я не могу просто в заголовочном файле написать
H>using namespace mySpace;

module1/a.h

#include "module2/a.h"

using namespace Module2_NS;  // в h файле нельзя
namespace Module1_NS
{
  // писать Module1_NS нигде не нужно
  // но Module2_NS нужно:
  Module2_NS::A a;
}

module1/a.cpp

#include "a.h"
#include "module2/b.h"

using namespace Module2_NS;  // в cpp файле можно
namespace Module1_NS
{
  // писать Module1_NS нигде не нужно
  // Module2_NS можно не писать, но можно и писать
  Module2_NS::b ...;
}

Мы используем один namespace на подсистему. Имеет смысл не изолировать в namespace какую-то переменную, а сразу подсистемы.
Казалось бы, обернуть в namespace подсистему не очень сложно. Какой у вас объём проекта?

H>что данная сторонняя библиотека содержит в себе уже используюмую переменную в нашем проекте
Как-то настораживает... переменную, неужели глобальную???

Дело в том, что проект достаточно большой и мне достался по наследству, поэтому некоторые конструктивные особенности проектирования имеют недостатки.
Как насчет фреймворков? Какие кто использует?
Первое что я нашел — это платинум

Здравствуйте, MasterZiv, Вы писали:

>> С другой стороны, я не могу просто в заголовочном файле написать
>> using namespace mySpace;

MZ>Никогда не пиши
MZ>using namespace XXX;
MZ>в заголовочных файлах.

О! наконец-то знающий человек, может, расскажешь, как все-таки делать правильно?

Здравствуйте, Handler, Вы писали:

H>Существуют ли какие-либо альтернативные методы разрешения конфликта имен кроме указанного мною?
Обернуть библиотеку в namespace?

namespace AlienLib
{
    #include "AlienLib.h"
}

Здравствуйте, johny5, Вы писали:
J>Обернуть библиотеку в namespace?
Сломается при линковке.

Здравствуйте, Handler, Вы писали:

H>Выходом из такой ситуации считается заключить переменную с одинаковым именем (но разными типами) в нашем проекте в отдельную область видимости и для каждого обращения к этой переменной в нашем проекте добавить спецификатор данной области видимости.

Проходишь по всем файлам своего проекта (и сишным, и хедерам) и содержимое каждого файла заключаешь в пространство имен проекта (т.е. добавляешь в каждом файле строчку "namespace the_first_namespace_in_my_life {" в начале файла (после инклудов и стража включения) и закрывающую фигурную скобку в конце файла (до стража включения)).
Т.е. файлы твоего проекта должны выглядеть так:
.h

#ifndef HEADER
#define HEADER

#include... // тут все инклуды

namespace the_first_namespace_in_my_life {

... // тут содержимое файла

} // namespace the_first_namespace_in_my_life
#endif //HEADER

.cpp

#include... // тут все инклуды

namespace the_first_namespace_in_my_life {

... // тут содержимое файла

} // namespace the_first_namespace_in_my_life

Всё. Никаких квалификаций делать нигде не придется, так как ты все время находишься в своем собственном пространстве имен.
Ну, кроме функции main, которая все же должна быть в глобальном пространстве имен, и специализаций всякой шаблонной байды из других пространств имен (std/boost), если такое у тебя есть.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, uzhas, Вы писали:

U>в своем проекте вы используете неймспейсы?

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

> О! наконец-то знающий человек, может, расскажешь, как все-таки делать правильно?

Как делать правильно ЧТО ?

Здравствуйте, Handler, Вы писали:

H>Здравствуйте!
H>Имеется проект, содержащий большое количество взаимодействующих между собой классов с большим количеством полей и методов в каждом из них.
H>Мы пожелали использовать внутри своего проекта стороннюю библиотеку, для чего добавили в текущий проект заголовочные файлы.
H>После попытки скомпилировать проект выяснилось, что данная сторонняя библиотека содержит в себе уже используюмую переменную в нашем проектею
H>Получился конфликт имен.

используйте при импорте rename или если конфликтный обьект из импортируемой билблиотеки вами не испльзуется — exlude
#import <ХХХ.tlb> rename("Конфликтпеременная, "_Конфликтпеременная")
или
import <ХХХ.tlb> exclude("Конфликтпеременная1, "Конфликтпеременная2",...)