Конечно нет, но тем не менее постоянно появляются индивиды, которым спокойно не живётся и они обязательно должны открыть оффшор. Так, наверное, жить веселее, чтоли.
А еще на хабре технически грамотные, но сложные статьи получают гораздо меньше внимания(сиречь плюсов) чем новости и статья для «школьников». Как Вы думаете, стоит ли после этого слушать «большинство» хабра?
Ну и не стоит, конечно, воспринимать слова наших академиков РАН всерьез, после подобных заявлений: сообщения электронной почты не являются личными письмами в традиционном смысле слова
Сообщения электронной почты являются личной перепиской. Более того, ни в Российской империи, ни в СССР не было никакой другой адресной переписки кроме личной. Именно поэтому я считаю вполне правомочным экстраполировать понятие личной переписки на любую адресную переписку, коей являются: мессенджеры, форумы(читай хабр) и прочие места где люди обращаются друг к другу непосредственно.
Товарищ linuxoid, что-то я в упор не вижу, чтобы в приведенных Вами статьях подтверждались Ваши слова. Эти статья как минимум можно трактовать в том ключе, что «Вы» в интернет переписке можно заменять на «вы». Там не написано, что использование «Вы» в подобном ключе некорректно. Нет там этого.
Если там рекомендовано 3 или 4 пункта, это не значит, что других пунктов нет. Это значит, что там рекомендовали 3 пункта. Вот и всё.
Ну и напоследок, как Вы считаете, что означаете следующая фраза, точнее к какому количеству людей она обращена? «вы всё делаете не правильно», а эта «Вы всё делаете неправильно»? Не кажется ли Вам, что вторая фраза менее двусмысленна?
1. Если все будут заниматься алгоритмами, то UI и прочего мы не увидим.
2. Если Вы будете заниматься алгоритмами(хотя бы уделять им немного времени), то Ваш уровень вырастет.
Никаких «ему дано, а мне нет», тут нет. Алгоритмы просто часть разработки ПО, и чтобы поднатореть в них нужно ими заниматься. Это как с DB, regexp и прочим. Разницы нет никакой.
moadib, приведенный Вами код не компилируется в силу того, что на момент выхода November CTP Stephen не успел обновить STL. Когда CTP превратиться в релиз(или RC) то Вы обязательно скомпилируете этот код. Ждать следующей стадии в CTP осталось не долго, я полагаю.
И Вам не зря указали на выступления Герба; на данный момент Microsoft действительно заинтересовано в скорейшей имплементации стандарта в своём компиляторе. Поэтому есть все основания полагать, что в 2013 году мы увидим полную поддержку стандарта в студии(тем более, что из сложных фич не реализовано только constexpr, насколько я помню)
Если говорим про C++11, то там есть emplace, move тут явно не к месту.
Это уже конструктор вашего объекта, тут много простора для действий.
Нет тут никакого простора, мы обсуждаем конкретную ситуацию. Нет смысла достигать нейтральности исключений тем способом, что Вы указали, т.к. она нарушается конструктором объекта помещаемого в контейнер. Другими словами, reserve применён Вами избыточно и он не гарантирует нейтральности исключений по отношению к контейнеру. Контейнер всё еще может содержать один элемент и не содержать второй.
А как гарантировать отсутствие исключения во время push_back(конструктор объекта)?
reserve решает проблему push_back, но не решает проблему конструктора, а значит не имеет смысла его использование в данном контексте, т.к. гарантии как не было так и нет.
Бесспорно. Но это в том случае если есть с кем данный опус обсудить. Но если автор выложил опус и не появляется в комментариях, то данный опус не является дискуссионным. Именно поэтому подобные опусы интереса не представляют. Тем более, что качество оных оставляет желать лучшего.
Ваш пример с вектором не состоятелен по 2 причинам:
1) Имплементация вектора в любом STL имеет запасы даже тогда, когда пользователь об этом не просил. reserve стоит использовать только в случаях, когда вы точно знаете, что вам нужно добавить много элементов и вы не хотите реаллокаций.
2) Выделив память reserve'ом Вы забываете о конструкторах элементов. В примере у Вас int, но мы же говорим в общем ;). Так что Ваши потуги с ранним reserve для сохранения нейтральности исключений вряд-ли будут плодотворны.
Вы не можете меня убедить, я 2 года работаю на одеске и за эти 2 года я изменил своё мнение от Вашего(у меня было такое же мнение) к тому, что имею сейчас. У меня есть причины так считать, я видел и вижу как работают другие люди. Как работаю я сам. Что мотивирует и что нет. Я говорю за себя, и за то, что я видел за свой не долгий рабочий стаж(~4 года в офисе и ~2 во фрилансе). Надзор делает только хуже, при разработке софта. Все плюсы разбиваются о море минусов.
2. Иностранным заказчикам абсолютно фиолетово где у Вас зарегистрирована фирма.
Сообщения электронной почты являются личной перепиской. Более того, ни в Российской империи, ни в СССР не было никакой другой адресной переписки кроме личной. Именно поэтому я считаю вполне правомочным экстраполировать понятие личной переписки на любую адресную переписку, коей являются: мессенджеры, форумы(читай хабр) и прочие места где люди обращаются друг к другу непосредственно.
Если там рекомендовано 3 или 4 пункта, это не значит, что других пунктов нет. Это значит, что там рекомендовали 3 пункта. Вот и всё.
Ну и напоследок, как Вы считаете, что означаете следующая фраза, точнее к какому количеству людей она обращена? «вы всё делаете не правильно», а эта «Вы всё делаете неправильно»? Не кажется ли Вам, что вторая фраза менее двусмысленна?
2. Если Вы будете заниматься алгоритмами(хотя бы уделять им немного времени), то Ваш уровень вырастет.
Никаких «ему дано, а мне нет», тут нет. Алгоритмы просто часть разработки ПО, и чтобы поднатореть в них нужно ими заниматься. Это как с DB, regexp и прочим. Разницы нет никакой.
Можно в цифрах?
И Вам не зря указали на выступления Герба; на данный момент Microsoft действительно заинтересовано в скорейшей имплементации стандарта в своём компиляторе. Поэтому есть все основания полагать, что в 2013 году мы увидим полную поддержку стандарта в студии(тем более, что из сложных фич не реализовано только constexpr, насколько я помню)
Нет тут никакого простора, мы обсуждаем конкретную ситуацию. Нет смысла достигать нейтральности исключений тем способом, что Вы указали, т.к. она нарушается конструктором объекта помещаемого в контейнер. Другими словами, reserve применён Вами избыточно и он не гарантирует нейтральности исключений по отношению к контейнеру. Контейнер всё еще может содержать один элемент и не содержать второй.
reserve решает проблему push_back, но не решает проблему конструктора, а значит не имеет смысла его использование в данном контексте, т.к. гарантии как не было так и нет.
1) Имплементация вектора в любом STL имеет запасы даже тогда, когда пользователь об этом не просил. reserve стоит использовать только в случаях, когда вы точно знаете, что вам нужно добавить много элементов и вы не хотите реаллокаций.
2) Выделив память reserve'ом Вы забываете о конструкторах элементов. В примере у Вас int, но мы же говорим в общем ;). Так что Ваши потуги с ранним reserve для сохранения нейтральности исключений вряд-ли будут плодотворны.
Задачу достоверного анализа работы трекинговые программы не решают.