Уже давно пробовал – предупреждение не исчезает.


Да я в курсе, но, по-моему, такое «убирание» предупреждений не есть хороший стиль программирования.


Чем же это плохочитабельно? И какова предлагаемая альтернатива?

За такое ты рискуешь получить "очень хорошие" рекомендации. Только солибной фирме ты так не сможешь нагадить. SVN\MS SS умеют выдергивать старые версии.
Добавлено @ 22:45

Виртуальные функции. Пример(пишу прямо тут, поэтому не обессудьте):
Добавлено @ 22:48
Далее, потребовалось добавить новый метод Draw. Код становится таким
Добавлено @ 22:51
Видишь switch-и плодятся! А теперь добавь еще один тип фигуры - треугольник. Во скольких местах тебе необходимо править код? Уже в двух, причем в реальном коде эти два(а ты уверен, что два? Ты все switch-и нашел? ) метода могут быть не рядом в одном файле, а в разных файлах\библиотеках

Насчет альтернативы и сопровождаемости DeadSoul уже написал. А плохо-читаемость из-за плохо-обозримости. "Хорошая" функция должна занимать не более пол-страницы, чтобы с одного взгляда можно было понять, что она делает. И делать она должна что-то одно. Мне же приходилось видеть функции со switch'ами страниц на 20. Вот счастье-то, когда что-то поправить нужно. Сразу чувствуешь себя ассенизатором: надеваешь прищепку на нос, рукавицы по локоть и ныряешь в это. Мне лично в таких случаях сразу хочется кого-нибудь убить.

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

Добавлено @ 14:14 
 - главное, чтобы глюков не было   , надёжность - главное! 

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

DeadSoul, да думаю, что даже полегче будет, чем тому, кто имеет великолепные рекомендации, но продукты которого периодически глючат. 

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

 

Ну если он опытный программист, то еще лучше =)))


А по теме: найти хорошее место работы при хороших проф. качествах и кол-ве смены рабочих мест, превышающих 7 в течение пяти лет, представляется сомнительным. 

Таких людей называют "Летуны" 

 и тогда то вот работодатель и заключает договор или контракт, в котором всё обговорено, а если контракта на бумаге нет, и ты понимаешь, что начиная писать, как я и говорил ранее "самокат", в итоге пишешь уже аэрокосмолет, то в таких фертелях ничего зазорного на мой взгляд нет. Да, платят то вот как за самокат   Но думаю, что про это хватит. Просто сотрудник должен не чувствовать себя обманутым, а лучше защищённым и довольным, тогда этого не будет. А про хорошие качества мои как программиста ничего сказать большего, чем в подписи не могу. Лично я могу выезжать лишь за счёт общей культуры проектирования(и то это моя субъективная оценка самого себя  ) 

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

Смысл - не вносить идентификаторы из пространства имен std в глобальное пространство имен 

Дополню:  "using namespace x" может привести к кофликту имен: допустим в твоем контексте есть имя Y. Неважно, откуда оно взялось: это может быть локальный символ или нечто из другого пространства имен (введенное директивой using). Если в пространстве имен x тоже определено имя Y, то каждый раз при использовании Y в нашем контексте будем получать стоны компилятора о неоднозначности.

Поэтому общий принцип такой: в заголовочных файлах вообще стараемся избегать директив using (даже using "конкретный символ", using namespace же запрещаем под страхом смерти). Чем шире используется заголовочных файл, тем сильнее избегаем.
Внутри cpp-файлов и тем более внутри функций - вполне допустимо, можно поступать так как в данном контексте удобно.  

Кто-то грозился книгу выслать... [email protected].  Сп.

Ткните пальцем в тот пост. В противном случае, ваше сообщение - оффтоп.