всем здрасте.

предыстория

Решил самостоятельно С НУЛЯ изучить с++ по самоучителю "С++ без страха" Б. Оверленд 2005г.

Код пишу в "Borland C++ v 4.5" 

Microsoft Visual C++ или Borland C++ Builder планирую начать использовать позже, когда появятся навык написания кода в простой среде разработки. чтоб ошибки программирования не путались с ошибками использования среды разработки. )) за это прошу не критиковать.



это была предыстория вопроса ;)



вот код программы





вопрос 1.

using namespace std

в книгах настоятельно рекомендуют вставлять в программу эту строку. Пишут что using позволяет обращаться к обьектам например std::cout напрямую. 

у меня в коде эта строка закомментирована потому что с ней не проходит компиляция. Пишет ошибка: "Declaration syntax error".

если закомментировать, то все работет нормально. при этом я же не прописываю вывод на экран std::cout хотя по книжке я именно так должен был сделать т.к. не прописал using?

в чем проблемма?



вопрос 2.

код тот же. У меня написано "iostream.h". А в книге говорят что надо писать без "*.h ", а без такого окончания опять не проходит компиляция. пишет что не может открыть файл iostream

в чем проблемма?



вопрос 3.

Еще проблемма с выводом русских букв на экран. Типа "cout << "tra-lya-lya!"". Русские ПРОПИСНЫЕ буквы отображает нормально, а строчные отображает, но не все, те которые не отбражает оставляет вместо них пробел. Еще в самом "Borland C++ v 4.5" русский текст печатается кракозябрами.

как это можно исправить?



з.ы.

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

спасибо за понимание. заранее благодарен. 

придется критиковать компилятор, т.к. он не соотвествует стандарту, на который опирается твоя книга.

не правильная позиция. ошибки использования среды не зависят от её новизны, а вот качетво компилятора зависит. сказчай VS 2005 express.

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

компилятор



взять другой компилятор

Комрад а если писать так:


а что бы русский шрифт в консоли работал номано юзай chelser функцию CharToOem   

Это сообщение отредактировал(а) mrbrooks - 10.10.2007, 13:43

Borland C++ был выпущен в 1994 году. STL была включена в стандарт С++ весной 1994 года.  Трудно требовать от компилятора полной поддержки стандарта, если компилятор писался во время или сразу после "по горячим следам" изменений стандарта. Но если ты собираешься изучать стандарт, то как начинающий начинающему посоветую поменять компилятор на более свежий.
(Кстати, не в самых новых учебниках прописывались такие ситуации (<iostream.h>).

официальный стандарт С++ появился в 1998 году.

А ну тогда все что я написал к коту под лохматый хвост    

Daevaorn, ты и сам ВСЕГДА пишешь std:: перед стандартными функциями?

тут же речь о мелких прогах идет, тут еще можно.
главное, не зацикливаться, ибо в больших проектах, согласен, std:: писать надо.

да

привычку надо отрабатывать всегда.

Удивительно (и очень часто встречаю) — неужели является секретом имя автора C++?

Почему изучение начинается с книг весьма и весьма экстравагантных?..

Почему бы не приобрести оригинал?..

Слухи о трудности книги Страуструпа (если они повлияли на выбор) — весьма преувеличены 

Кстати, вот работа Страуструпа Learning Standard C++ as a New Language

SergeCpp, поддерживаю. Иногда диву даешься сколько всякий "С++ без проблем", "С++ бархатный путь" и еще всяких извращений на полках книжных магазинов. А реально стоящих книг раз-два и все.

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

Добавлено через 3 минуты и 21 секунду
т.е. насколько я понял, то все мои вопросы сходятся к тому что я использую устаревший компилятор?

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

плз подскажите где можно скачать новый компилятор
и как заменить его

Я был чайником в данном вопросе (C++)

Взял и прочитал дома, тихо, спокойно, 1-е издание (самое старое) — полностью всё

Потом купил 2-е издание (в двух томах), таким же образом прочёл его — полностью всё

Сложностей при чтении особых не встретил

Интернетов с форумами не было да и незачем это (думать самому нужно)

абсолютно точно

Если канал широкий
http://msdn2.microsoft.com/en-us/evalcenter/bb655864.aspx
если нет, то
http://msdn2.microsoft.com/ru-ru/express/aa975050.aspx
хорошие, современные компиляторы с одними из лучших в индустрии IDE

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

SergeCpp
извините что задел ваше драгоценное самолюбие

Я вот всегда пишу - у меня это уже рефлекс... Даже в форумах, 2-3 строчные примеры пишу с std.


Я, имея огромный опыт работы на С++, испытывал огромные трудности при попытке объяснить другу некоторые примитивные понятия по Страуструпу. Сначала я читал и полчаса втыкал что же там написано, потом, ещё дольше пытался объяснить другу, что там написана чушь и только потом, за 10 минут объяснял ему что к чему. Естественно, чушью являлся не изложеный в Страустпупе материал, а пришедшее к другу понимание вопроса после прочтение страниц из Страуструпа, а это очень хорошо говорит о "таланте" Страуструпа писать книги.
OTOH, "D&E" - очень хорошая книга и, надо сказать, читать её было интересно, но даже такой интересный материал Страус умудрился изложить так, что порой приходилось пролистывать страницы(ибо скукотища).
ИМХО, если Страуса и нужно читать(я про "The C++ PL"), то, только после получения очень хороших навыков "мышления на С++", с той целью, чтобы уточнить нужные тонкости языка и то, только в том случае, если не хватает технического английского, чтобы читать Стандарт.

Прости дилетанта, но это не аргумент. Когда я читаю некоторые руководства, они рекомендуют конкретно прописывать std:: как раз при использовании в нескольких строчках кода (без указания using namespace std).
Еще прошу прощения. Вот я изучаю С++, бегиннер типа. Вы говорите, что std:: нужно прописывать всегда, потому что хороший стиль. У до чертиков авторов оно парабезразлично. Какие еще есть аргументы, кроме как авторы, не выучившие язык (названия обобщенных алгоритмов stl) и путающиеся в областях видимости и перегрузке, могут допустить "неотслеживамые" (для них) ошибки? Ведь мне, дилетанту, по сути дела все едино, писать ли using или нет, а лишние пять символов мне в ломы печатать сто раз на дню?
Простите, если что ляпнул не так. В целях ознакомления.

Некоторые руководства, думаю, расчитанные не на новичка, которые редко знают о возможности ограничить scope или не догадываются, что если и советуют писать using blablabla, то ни в коем случае не в заголовочном файле и т.д.



Хороший стиль всегда имеет объяснение почему именно он хороший, а другой плохой.
Здесь есть некоторая дискуссия на эту тему.
Вообще, по возможности нужно использовать полностью квалифицированные имена, а если это выглядит жутко, то локализовывать кусочек кода где очень часто используется определённое NS и именно там писать using namespace NS;

chelser, чтобы заюзать русские буквы есть 2 варианта
первый: заюзать функцию CharToOem

или выставить локаль


Добавлено через 3 минуты и 3 секунды
Локаль жрёт меньше ресурсов

прям так и говорят: "Не пишите std::cout - это плохо, пишите using namespace std; а потом просто cout - это хорошо"? 
Не верится что-то...

одно дело код примера - другое рабочий. Они и ошибки зачастую не проверяют все подряд. Тем более новичку будет проще воспринимать код без пространств имен.

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

Аргумент небезупречен. Что-то я не встречал "Не пишите никогда using namespace std; а потом просто cout - это плохо, пишите только std::cout - это хорошо".


это аргумент. Но у меня, новичка, не возникло бы никаких вопросов, если бы в начала цитаты не было бы слов "по возможности".


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

Давайте, предупреждение у меня уже есть. Модерируйте.

В задачках как правило используется не самый лучший стиль. Цель задачи описать проблему наиболее кратко и получить ответ на вопрос "умеет ли соискатель решать такого рода проблемы?".

Засоряется оно очень даже хорошо. Не раз сталкивался.

Я проше прощения за поднятие старой темы, но вопрос по сабжу.
Есть ли разница в оптимальности (расход памяти, быстродействие) при обращении std::string или к своим нэймспейсам или без префикса имени пространства имен?
Дело в том, что для решаемой в данный момент задаче этот вопрос очень актуален, ввиду того, что программа выполняет определенные функции раз в 10 ms, и таких функций может быть несколько.

Спасибо.

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

книги, в которых имеются такие рекомендации написаны либо для ламеров, либо ламерами. не исключён также и третий вариант, являющийся логическим объединением предыдущих двух... 

Rififi, простите, Герберт Шилдт - ламер?

Простите, позволю себе также ответить на поставленный вопрос: Герберт Шилдт — ламер. Последний перл: этот человек во вступлении к книжке по последней Java (6-ой, значится) все еще рассуждает на тему, является ли Java япом для интернета. Откопал экскременты мамонта, называется.

По сабжу: разницы нет. Все обращения, которые разнятся наличием квалификации пространства имен, связываются с объектами этих пространств имен на этапе компиляции. Упрощенно ситуацию можно представить так: на месте обращения к cout (квалифицированного или нет) компилятор вписывает адрес объекта. Пространства имен позволяют помочь компилятору понять, какой именно адрес написать (если имен cout несколько в разных пространствах имен). Как именно cout приписано к пространству имен (using или std::cout) компилятору неважно, лишь бы конфликтов не было. Он впишет нужный адрес и точка.

По сабжу выше: писать директивы включения пространст имен (using namespace ...) это nasty. Плохо, типа. В стендовых примерах можно. Ну, в тестовых рутинах, если очень уж неймется, с натяжкой. Но в продакш коде («библиотечном коде») никогда.

Это сообщение отредактировал(а) Ulysses4j - 11.7.2008, 05:29

Mal Hack, я дваждую то, что пространства имён важны только на этапе компиляции. Сгенериванный объектный код ничем не будет отличаться.

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

и так и не дали вразумительного ответа, хорошо или плохо писать в начале кода using namespace блаблабла;
мне, как ламеру, это представляется разумным, исходя из примера. берешь ты книгу со стеллажа (например cout), отходишь от стеллажа, читаешь, нужна еще одна книга (тот же std::cout) - опять идешь к стеллажу, тратишь ресурс на обращения к стеллажу (иллюстрирована конструкция std::cout), вместо того, чтобы стоять около стеллажа и доставать нужные тебе книги (не расходуя лишних ресурсов).
или все устроено совсем не так? только громко не смейтесь 

Henpyxa,  если приблизить к Вашему стилюм, то вот так себя чувствует компилятор:

берет cout , думает кто ж это такой, благо находит подходящий только в std:: и успокаивается, значит это он.
берет cin, думает кто ж такой? находит один в std:: и один в anynamespace:: и озадачивает себя и программиста вопросом, а кой же использовать ?!
берет std::cin и без всяких раздумий использует его 
  

А ты Саттера попробуй  
На самом деле Страуструп не для новичков пишет, осилить его книгу не так уж и просто, начни с чего нибудь попроще.


Его нет, это вопрос предпочтений. Что точно можно сказать так это то, что в заголовочных файлах using писать НЕ хорошо, а в cpp пиши если хочешь. Как будет удобно.

особенно весело бывает когда раскрываешь несколько namespace`ов, к примеру std, boost, boost::asio, boost::asio::ip::tcp. вот тогда-то и начинается все веселье  

Это сообщение отредактировал(а) boostcoder - 9.10.2010, 14:17

я всегда пишу в заголовке using std::something.

или если тип внутри класса юзается определяю новое имя через typedef

typedef std::Something _tSomething;

и дальше в коде использую Something.


Мне кажется в коде каждый раз писать namespace name тоже не очень кашерно. Для std::cout ещё ничего смотрится, но если там вложенные namespace-ы? например boost::unit_test::something - мне что каждый раз тятнуть за собой эту тягомотину?

но одно верно "using namespace std" - это зло.

и почему же?

Это сообщение отредактировал(а) azesmcar - 9.10.2010, 14:20

нет.
так:

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

azesmcar, наверно, я всё же слишком безапеляционно высказался насчёт "using namespace std."

Мне почему-то кажется, что вы готовы из рукава вытащить тройку-другую контраргументов для меня  которые, в свою очередь, также можно контраргументировать ... 

Правельнее было бы сказать, что  Я предпочитаю такой подход не использовать, однако, не настаиваю, что моё мнение единственно правельное.

Однако, по вашему вопросу - я так не пишу из 2х соображений:
1. Не очень будет приятно если что-то из std или из другого "густонаселённого" namespace-а начнёт конфликтовать с чем-то таким же загадочным из другого namespace-а.

2. Так более понятно какой именно функционал из какого namespace-а используется в данном модуле.

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



boostcoder, спасибо. Интересный вариант.

Единственное, что меня смущает это не запутается ли, читающий код человек, в таком лабиринте namespace-ов? 
Просто, все знают что такое boost::unit_test, а вот but придётся поискать определние. Если предположить что таких "петель" много, то можно основательно запутаться, наверно .... хотя, так во всём, если подходить к проблеме бездумно.

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

а насчет книги.. заметил где-то на форуме сообщение про http://worldcpp.vingrad.ru/, почитал, понравилось  хотя материала и много, но все же маловато для полного понимания азов. хотя бы про классы в С++: пытался написать простенькую программку, используя знания, полученные от чтения фака, что-то типа



и не вкурю никак про ошибку Run-Time Check Failure #3 - The variable 'iSellPrice' is being used without being defined. недостаточно там написано про классы  и в шапке все-таки использовал using namespace std;
имхо, удобней указать один раз в маленьком коде, чем каждый раз втыкать перед cout'ами и cin'ами. про длинные коды даже страшно думать..

Эта переменная не инициализирована


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

Можно использовать 



Это сообщение отредактировал(а) Crafty - 9.10.2010, 17:35

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

тоже впервые вижу.
а как часто обновляется? если обновляется вообще...

Да нет, для этого аргументов не нужно. Аргументы нужны для обоснования того, что using namespace - зло  


С предпочтениями конечно же спорить не имеет смысла, я и писал, что это вопрос личных предпочтений. Я тоже предпочитаю использовать std::, если речь зашла об этом.

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



вспомните народную мудрость "подальше положишь - поближе возьмешь".



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

вобщем найдите хороший компромис, и код будет красивым и удобным 

На самом деле, в случае использования using namespace произойдет следующее: взяли пару стеллажей (количество пространств + глобальное + локальное) и вывалили все его содержимое в кучу, затем сказали компилятору, а нука найди мне cout в этой кучи.

Лично я считаю, что using namespace:
1. в глобальной области видимости в хидерах недопустимо. Сам сталкивался...
2. в глобальной области видимости .cpp файлах нежелательно.
3. внутри функций использовать можно, но лучше использовать переименование. Например, в документации к boost::program_options приводится такая вещь: namespace po = boost::program_options.

  

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

спасибы, понял