Используйте находят от заголовка алгоритма stl. Я проиллюстрировал его использование с международным типом. Можно использовать любой тип, который Вы любите, пока можно выдержать сравнение для равенства (перегрузка ==, если Вы должны для своего пользовательского класса).
#include <algorithm>
#include <vector>
using namespace std;
int main()
{
typedef vector<int> IntContainer;
typedef IntContainer::iterator IntIterator;
IntContainer vw;
//...
// find 5
IntIterator i = find(vw.begin(), vw.end(), 5);
if (i != vw.end()) {
// found it
} else {
// doesn't exist
}
return 0;
}
Было проведено несколько исследований, показывающих, что строгий Приверженность последовательному визуальному стилю помогает опытным программистам сохранять в памяти большую часть локальной проблемы без необходимости запоминать отдельные элементы проблемы.
Это связано с тем, как работает человеческая память. Это называется разбиением на части . Например, хорошо изученный феномен шахматных мастеров намного лучше запоминает шахматные позиции, чем люди, не знакомые с игрой. Но это только в том случае, если фигуры находятся в «естественных положениях», которые могут иметь место в обычной игре. Если вы разместите шахматные фигуры в случайном порядке, шахматные мастера не лучше , чем не шахматисты , в запоминании позиций на доске.
То же самое относится и к программистам. Когда стили кодирования согласованы, конструкции кодирования кажутся программисту «естественными», и большие части кода легче усваивать. Наша кратковременная память имеет емкость примерно «семь плюс-минус два» фрагмента, поэтому, чем больше эти знакомые фрагменты, тем больше сырых данных наш разум может активно удерживать в памяти ( Джордж Миллер ).
Столкнувшись со случайно отформатированным кодом, программисты должны тратить дополнительную умственную энергию, чтобы вручную проанализировать отдельные части проблемы, над которой они работают. Это лишает возможности удерживать в памяти более крупные фрагменты проблемы, чтобы работать над ними. Это также означает, что требуется больше времени, чтобы достичь точки, в которой программист продуктивно решает поставленную задачу.
Вы когда-нибудь замечали, что проблема кажется такой ясной, пока вы продолжаете работать над ней, но затем вы кажется, что «теряете информацию», когда вернетесь к проблеме позже; т.е. разорвать время потока? Время выполнения хорошо задокументировано в Peopleware (обязательное чтение для всех программистов). Время выполнения - это когда программисты выполняют большую часть работы, и достигается только тогда, когда вы работаете над проблемой в течение длительного, непрерывного периода времени. Это связано с тем, что программисту требуется определенный период времени, чтобы ассимилировать достаточное количество проблемы в когнитивной памяти, чтобы эффективно работать над проблемой. Хорошо отформатированный код помогает нашей визуальной обработке изображений, что означает, что программисты намного быстрее достигают времени выполнения.
Я разработал стандарты кодирования в нескольких компаниях-разработчиках программного обеспечения. Очень жаль, что многие программисты считают, что стандарты кодирования - это просто средство утверждения ненужного контроля над тем, как они что-то делают; форма творческой цензуры. По правде говоря, редко имеет значение, каковы настоящие стандарты. Ценность состоит в том, чтобы заставить всех в команде быть последовательными, даже если это означает принятие часто произвольного решения между тем, чтобы сделать это моим способом или сделать это своим способом.
Здесь несколько ссылок, которые я упомянул выше:
Наши исследования подтверждают утверждение о том, что знание планов программирования и правил дискурса программирования может иметь значительное влияние на понимание программы. В своей книге «Элементы стиля [программирования]» Керниган и Плаугер также определяют то, что мы бы назвали правилами дискурса. Наши эмпирические результаты подтверждают следующие правила: писать программы в определенном стиле - это не просто вопрос эстетики. Скорее, существует психологическая основа для написания программ обычным способом: программисты сильно ожидают, что другие программисты будут следовать этим правилам дискурса. Если правила нарушаются, то полезность, предоставляемая ожиданиями, которые программисты создавали с течением времени, фактически сводится к нулю. Результаты экспериментов с начинающими и продвинутыми студентами-программистами, а также с профессиональными программистами, описанные в этой статье, ясно подтверждают эти утверждения.
Эмпирические исследования знаний в области программирования. Солоуэй и Эрлих.
Место, где я получил наиболее полное представление об этом вопросе:
Стандарты кодирования C ++: 101 правила, рекомендации и передовой опыт (Саттер, Александреску)
Это стоит прочитать даже если вы не работаете на C ++.