Создаю прогу с пом. ATL, не хочу исп.MFC.
Нужно создать массив строк. Пытаюсь объявить. В заголовке как в книжке
#include <string>
#include <vector>
В проге
vector<string> sRegNum;
Ни vector, ни string при сборке не опознаны.
Добавляю в заголовок
using namespace std;
Ошибок... УУУУУУ...
Подскажите... Может чего-то надо подключить?

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

A>Создаю прогу с пом. ATL, не хочу исп.MFC.
A>Нужно создать массив строк. Пытаюсь объявить. В заголовке как в книжке
A>#include <string>
A>#include <vector>
A>В проге
A>vector<string> sRegNum;
A>Ни vector, ни string при сборке не опознаны.
A>Добавляю в заголовок
A>using namespace std;
A>Ошибок... УУУУУУ...
A>Подскажите... Может чего-то надо подключить?
A>

Ты уверен, что это ошибки? Может, варнинги? Если это так, то надо сделать следующее: добавить в начало файла такие строки:

# pragma warning( disable: 4786 )
# pragma warning( disable: 4503 )

Посмотри теперь, что получится. Ошибки есть?

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

A>Создаю прогу с пом. ATL, не хочу исп.MFC.
A>Нужно создать массив строк. Пытаюсь объявить. В заголовке как в книжке

A>#include <string>
A>#include <vector>
...
// Перед использованием
A>using namespace std;
// Либо
using std::string;
using std::vector;
...
A>vector<string> sRegNum;

A>Ни vector, ни string при сборке не опознаны.
Теперь опознаны?

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

A>Создаю прогу с пом. ATL, не хочу исп.MFC.
A>Нужно создать массив строк. Пытаюсь объявить. В заголовке как в книжке
A>#include <string>
A>#include <vector>
A>В проге
A>vector<string> sRegNum;
A>Ни vector, ни string при сборке не опознаны.
A>Добавляю в заголовок
A>using namespace std;
A>Ошибок... УУУУУУ...
A>Подскажите... Может чего-то надо подключить?
A>
Пиши

#include <vector>
#include <string>

std::vector<std::string> str_vector;

Проблема с кучей предупреждений — это особенность VC
Дело в том, что при разворачивании шаблонов длина имени типа получается очень большой, более 255 символов, о чем VC и предупреждает со всей старательностью. На результат компиляции однако это предупреждение не оказывает влияния.
Можно попытаться указать #pragma warning(disable:4786) до включения каких бы то ни было файлов директивами #include, я это делаю в самом начале stdafx.h
Однако и это не всегда помогает — в VC есть баг, о котором пишут в MSDN — предложенная прагма работает не всегда
А пользоваться using namespace std; не рекомендуется — так сводятся на нет все изолирующие преимущеста пространств имен.

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

B>Однако и это не всегда помогает — в VC есть баг, о котором пишут в MSDN — предложенная прагма работает не всегда
Это помогает всегда, если эти строки вставлять не в текст заголовка, а в такст каждого использующегося своего .cpp-файла. Правда, для переносимости кода на другие компиляторы стоит вставлять вокруг этих строк такие:

# ifdef _MSC_VER
...
# endif // _MSC_VER

С уважением

Здравствуйте Kaa, Вы писали:
Kaa>Это помогает всегда, если эти строки вставлять не в текст заголовка, а в такст каждого использующегося своего .cpp-файла.
Возможно. Хотя Микросоыт думает немного иначе. Вот цитата из MSDN, статья "BUG: C4786 Warning Is Not Disabled with #pragma Warning":

The information in this article applies to:
Microsoft Visual C++, 32-bit Editions, versions 5.0, 6.0
--------------------------------------------------------
SYMPTOMS
Warnings similar to the following are generated even if you use the warning pragma to disable the warning:

warning C4786:
'std::rb_tree<CAiSpanningTree<State,std::less<State>>::TransClosureNode, CAiSpanningTree<State,std::less<State>>::TransClosureNode,std::ident<Cai SpanningTree<State,std::less<State>>::TransClosureNode,CAiSpanningTree<S tate,std::less<State>>::TransClosureNode>,std::less<CAiSpanningTree<Stat e,std::less<State>>::TransClosureNode>>' : identifier was truncated to '255' characters in the debug information

STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.

MORE INFORMATION
This warning can be ignored. However, the identifier may not be accessible or viewable in the debugger.

Ну и далее по тексту...
Плохо то, что эта проблема мешает просматривать в дебаггере объекты стандартных STL-типов...

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

Ну что-ж, неплохой способ разговора — нулями кидаться. Прийму к сведению.

Существует большой опыт использования stl, и один из способов борьбы с этим злом (данным багом) — это расставление в правильных местах данных конструкций. Это ОЧЕНЬ ЧАСТО (мне еще не встречалась ситуация, когда бы это не сработало, но, наверное, можно слово "всегда" заменить на это) помагает. Этот метод действительно не помагает при помещении его в заголовки, но достаточно действенный при описанной выше стратегии.

Сами попробуйте, убедитесь.

С уважением

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

Kaa>Ну что-ж, неплохой способ разговора — нулями кидаться. Прийму к сведению.
Приношу свои извинения. Я действительно не придал большого значения "нулю", а лишь руководствовался "хинтом" для оного, который гласит "я так не думаю". Вот и все. Я и правда придерживаюсь иного инения, хотя, с учетом Вашей уверенности и ссылкой на значительный опыт, видимо, ошибочного. Приму к сведению на будущее.

Kaa>Это ОЧЕНЬ ЧАСТО (мне еще не встречалась ситуация, когда бы это не сработало, но, наверное, можно слово "всегда" заменить на это) помагает. Этот метод действительно не помагает при помещении его в заголовки, но достаточно действенный при описанной выше стратегии.

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

Что до разницы между "часто" и "всегда"... Я несколько обостренно реагирую на нее, особенно после того, как пришлось общаться с одним уважаемым товарищем, утверждавшим, что он делал "вот эдак, и всегда было хорошо", хотя его методика и противоречила многим источникам, в том числе и стандарту С++.
Отсюда и неадекватные реакции

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

B>Что до разницы между "часто" и "всегда"... Я несколько обостренно реагирую на нее, особенно после того, как пришлось общаться с одним уважаемым товарищем, утверждавшим, что он делал "вот эдак, и всегда было хорошо", хотя его методика и противоречила многим источникам, в том числе и стандарту С++.
B>Отсюда и неадекватные реакции

Все нормально. Я впредь буду более осторожен в высказываниях, когда не привожу цитат.

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

A>Создаю прогу с пом. ATL, не хочу исп.MFC.
A>Нужно создать массив строк. Пытаюсь объявить. В заголовке как в книжке :)
A>#include <string>
A>#include <vector>
A>В проге
A>vector<string> sRegNum;
A>Ни vector, ни string при сборке не опознаны.
A>Добавляю в заголовок
A>using namespace std;
A>Ошибок... УУУУУУ...
A>Подскажите... Может чего-то надо подключить?
A> :crash:


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

#include <vector>
#include <string>
using namespace std;

После этого юзай, должно сконтачить(у меня, например, работает).

Спасибо всем за помощь...
Я вчера додумался до реализации, которую предложил Brother.
Все таки пишет ошибки а не предупреждения, когда я вставляю
using namespace std;
Вот такие: (обрезал)
d:\program files\microsoft visual studio\vc98\include\ios.h(146) : error C2872: 'streambuf' : ambiguous symbol
.....
d:\program files\microsoft visual studio\vc98\include\streamb.h(91) : error C2872: 'streampos' : ambiguous symbol

Конфликт stl <...stream> со стандартным <...stream.h>. Так что совет Каа, по использованию:
using std::string;
using std::vector;
тоже прекрасно сработал... Еще раз спасибо...

А стоит ли их (STL-шаблоны) вообще использовать в VC?
Я хочу например исп. их в сервере приложений.
Нужна обработка строк и безразмерный массив.

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

A>А стоит ли их (STL-шаблоны) вообще использовать в VC?
A>Я хочу например исп. их в сервере приложений.
A>Нужна обработка строк и безразмерный массив.

А почему нет-то?
мне вот например гораздо приятнее работать с контейнерами stl...

кстати возвращаясь к проблеме с ошибками — ты using namespace std не в stdafx.h (или в каком-нибудь другом хедере) писал?

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

B>кстати возвращаясь к проблеме с ошибками — ты using namespace std не в stdafx.h (или в каком-нибудь другом хедере) писал?

Нет, я прямо в .cpp открывал. А что, так лучше?

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

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

B>>кстати возвращаясь к проблеме с ошибками — ты using namespace std не в stdafx.h (или в каком-нибудь другом хедере) писал?

A>Нет, я прямо в .cpp открывал. А что, так лучше?

да нет, наоборот хуже
просто сталкивался с подобной проблемой — имелся довольно большой проект, в котором в некоторых хедерах было прописано using namespase std
так вот пока я все это дело из хедеров не поубирал — ошибок таких же было ... много в общем
так что using namespase std лучше писать в cpp — файлах, да и то если они не очень большие...

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

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

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

B>>>кстати возвращаясь к проблеме с ошибками — ты using namespace std не в stdafx.h (или в каком-нибудь другом хедере) писал?

A>>Нет, я прямо в .cpp открывал. А что, так лучше?

B>да нет, наоборот хуже
B>просто сталкивался с подобной проблемой — имелся довольно большой проект, в котором в некоторых хедерах было прописано using namespase std
B>так вот пока я все это дело из хедеров не поубирал — ошибок таких же было ... много в общем
B>так что using namespase std лучше писать в cpp — файлах, да и то если они не очень большие...

Конкретнее:
"using-объявление вводит локальный синоним. Такие синонимы селдует делать как можно более локальными во избежание конфликтов имен." (Страуструп, п. 8.2.2).

И расположение тут не причем, будь то заголовок или cpp-файл. В заголовках их тоже можно использовать, но только внутри методов (inline-методов, inline-функций, т.д.) во избежание проблем с появлением одинаково проименованных сущностей.

С уважением

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


Kaa>И расположение тут не причем, будь то заголовок или cpp-файл.

ну как же, ведь именно расположение определяет степень "локальности"
ведь если using-объявление расположено в хедере (причем не в функции ), то вполне вероятна ситуация, что это объявление распространиться на несколько cpp-файлов, в которые этот хедер будет подключен...

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

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


Kaa>>И расположение тут не причем, будь то заголовок или cpp-файл.

B>ну как же, ведь именно расположение определяет степень "локальности"
B>ведь если using-объявление расположено в хедере (причем не в функции ), то вполне вероятна ситуация, что это объявление распространиться на несколько cpp-файлов, в которые этот хедер будет подключен...

Именно поэтому я и написал, что использовать их надо внутри чего-нибудь (в общем случае). Этим чем-нибудь могут быть фугции, методы классов, namespace-ы. Мы же все понимаем, что существует много библиотек, к-рые не содержат никаких других файлов, кроме заголовков. И при этом, в них допускается использование using-декларации. И правильное использование не приведет к конфликту имен.

А вот если не в другой области видимости, а в глобальном пространстве имен — тогда трабл. Я все это описал с первого раза.

С уважением

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


Kaa>Именно поэтому я и написал, что использовать их надо внутри чего-нибудь (в общем случае). Этим чем-нибудь могут быть фугции, методы классов, namespace-ы. Мы же все понимаем, что существует много библиотек, к-рые не содержат никаких других файлов, кроме заголовков. И при этом, в них допускается использование using-декларации. И правильное использование не приведет к конфликту имен.

Kaa>А вот если не в другой области видимости, а в глобальном пространстве имен — тогда трабл. Я все это описал с первого раза.

Kaa>С уважением


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

Здравствуйте
Решил влезть в ваш разговор поскольку проблема моя касается
vector
Я переделываю проект с VisualC под embedded Visual
проблема в том что я не могу подключить директорию
Include из каталога Visual поскольку хренова туча конфликтов
имен.
А по моим глубоким убеждениям чтобы подключить просто vector
нужно подключить vector.h и vector.obj но ничего подобного
я не нашел.
Если кто понял вопрос , скажите в каком месте я дурак
и как мне выйти из этого места.
Поскольку половина проекта завязана на векторе
если его не использовать то придется перелопачивать половаину кода
а это немало

A>Нужно создать массив строк. Пытаюсь объявить. В заголовке как в книжке

так и нужно делать:


#include <string>
#include <vector>
using namespace std;

void funct()
{
vector<string> sRegNum;

}

VC правда при компиляции выдаст тебе кучу варнингов (а не ошибок), насчет "обрезания имен" так что ты в самом верху добавь еще строчку

#pragma warning(disable: 4786 )

компилируй все будет тип топ