Всё-таки есть разница между тем, чтобы обработать один набор данных несколькими алгоритмами полностью, и обработать тот же набор частично до получения нужного результата? Ну, например, вместо алгоритма sort применять partial_sort или nth_element. Так же описанный в статье подход позволит реализовать концепцию ленивых вычислений (не обрабатывать весь набор данных сразу, а элемент за элементом по мере необходимости). Также он может упросить восприятие сложных конструкций, если над элементом данных надо последовательно выполнить несколько преобразований. В общем, хотя на первый взгляд ваш пример и пример из статьи эквивалентны, описанный в статье вариант обладает большем потенциалом.
Создатели Visual Studio никогда не отличались большим мастерством в плане разработки IntelliSence для C++. Не знаю, как в 2012, но вплоть до 2010 нормально можно было пользоваться только Visual Assist'ом.
Скажем так. Это не получится в рамках действующего стандарта (C++11). В рамках C++14 — по идее, может получиться. Если объединить полиморфные лямбды и что-то в стиле expression templates (только в рантайме), то на выходе вполне можно будет иметь и сконструированный sql-запрос, и анализатор полученного рекордсета.
Собственно, в этом заключается основная причина, по которой я практически перестал использовать MSVC в своих проектах. Для таких экспериментов gcc и clang подходят куда как лучше. :) Сейчас использую связку QtCreator + mingw gcc. Удачи вам в ваших экспериментах!
Теперь понятно. Но ведь никто не мешает вам использовать следующие методы:
1. auto:
auto oDelegate1 = MakeDelegate(&oA, &A::f1);
auto oDelegate2 = MakeDelegate(&oA, &A::f2);
2. decltype:
decltype(MakeDelegate(nullptr, &A::f1)) oDelegate1;
decltype(MakeDelegate(nullptr, &A::f2)) oDelegate1;
Второй вариант можно использовать при объявлении членов класса. Вот как-то так.
Есть, кстати, ещё один вариант, при котором такой расклад может быть возможен. Девушка «села» на некоторый проект, и в итоге оказалась единственным экспертом по коду. В этом случае ценны не столько знания вообще, а находящаяся в голове экспертиза по коду. Начальство понимает, что если она уходит — проекту станет очень тяжело. Вот и удерживает такими способами.
Ну, с учётом того, что описанное происходило при очередном пересмотре зарплаты (а это врятли чаще, чем раз в квартал), то как минимум испытательный она прошла (а это 3 месяца), и ещё минимум месяца три отработала. Т. е. к тем 25-ти занятиям добавилось полгода боевого опыта. Если девушка реально гений — то история имеет право на жизнь. Иначе повышать зарплату за раз более, чем на тысячу баксов, нет смысла. Нередко для этого повышение в должности требуется, иначе просто в зарплатные вилки не влезет.
Скажем так. Судя по всему, требования в вакансии просто были завышены. Если бы требовался действительно сеньёр, то 8-мимесячный опыт (вместо 3х лет) быстро бы вскрылся.
> Но, программист — это совсем другое. Программист — это тот, кто владеет и математическим (алгоритмическим) аппаратом, и навыками кодирования примерно в равной и хорошей степени.
Лет 30 назад — возможно. Сейчас же… Далеко не во всех прикладных и системных областях требуются знания математического (алгоритмического) аппаратов. Знание фреймворков, особенностей операционок, собственно языков, их библиотек, умение грамотно (не на одну сотню килострок) развернуть решение сугубо прикладной задачи… Да ещё всё это запроектировать с учётом разного рода требований… Это не значит, что мат. программирование мертво (ни в коем случае), это значит, что это — одна из ниш. И ещё. Если программист имеет хорошую мат. и алгоритмическую базу, знает CS — это ещё не значит, что он сможет написать красивый код, реализующий придуманный им элегантный алгоритм.
Более того, многие современные программисты могут легко (в голове) развернуть какую-нибудь замороченную систему с применением ООД, расчертить связи, коллаборации, сиквенсы и т. п., но при этом впадут в ступор от предложения реализовать алгоритм FFT. Это просто разные области.
Опыт если есть — то он есть. Если есть собственные проекты — это даже лучше, поскольку это верифицируемый опыт. Этот код можно принести, показать, рассказать: что как и почему делалось. А опыт работы над проектами, обложенными NDA — это таки абстракция, которую верифицировать не так то и просто.
С одной стороны, начинание автора хорошее. Девиз «Программирование — это просто» и всё такое прочее, с другой — приведённые в статье примеры несколько удручают и вызывают определённые вопросы. Очень хорошо, что ученики учатся работать в команде… А потом учатся эти команды кидать в погоне за очередной сотней баксов к зарплате. Программирование — это не только просто, но и ответственно. Перед тем, с кем ты работаешь, перед работодателем, перед конечным заказчиком. И цена ошибки варьируется от нулевой до цифр со многими нулями и человеческими жизнями. Приписанный опыт? В одном случае — сойдёт. В другом — грозит факапом проекта просто потому, что у человека не хватило как раз тех двух-трёх-четырёх приписанных месяцев, чтобы быстро въехать в проект и адекватно работать пусть даже и на подхвате. Или говнокод с таким количеством этого «говно», что тестеры зашиваются, и не успевают оттестировать релиз к сроку. Или ревью простейших компонент/классов зависают на месяца, выматывая нервы и авторам и ревьюверам.
Вооружившись принципом «я с тем, кто платит больше» недописанные куски проектов кидаются на более ответственных «сеньёров» у которых цель — таки допилить проект, а не свалить на более высокую зарплату. И они вкалывают по выходным, разгребая спагетти брошенного кода, пытаясь скрестить получившихся ежей и ужей.
А в остальном… Да. Программирование — это просто.
1. auto:
auto oDelegate1 = MakeDelegate(&oA, &A::f1);
auto oDelegate2 = MakeDelegate(&oA, &A::f2);
2. decltype:
decltype(MakeDelegate(nullptr, &A::f1)) oDelegate1;
decltype(MakeDelegate(nullptr, &A::f2)) oDelegate1;
Второй вариант можно использовать при объявлении членов класса. Вот как-то так.
Лет 30 назад — возможно. Сейчас же… Далеко не во всех прикладных и системных областях требуются знания математического (алгоритмического) аппаратов. Знание фреймворков, особенностей операционок, собственно языков, их библиотек, умение грамотно (не на одну сотню килострок) развернуть решение сугубо прикладной задачи… Да ещё всё это запроектировать с учётом разного рода требований… Это не значит, что мат. программирование мертво (ни в коем случае), это значит, что это — одна из ниш. И ещё. Если программист имеет хорошую мат. и алгоритмическую базу, знает CS — это ещё не значит, что он сможет написать красивый код, реализующий придуманный им элегантный алгоритм.
Более того, многие современные программисты могут легко (в голове) развернуть какую-нибудь замороченную систему с применением ООД, расчертить связи, коллаборации, сиквенсы и т. п., но при этом впадут в ступор от предложения реализовать алгоритм FFT. Это просто разные области.
Вооружившись принципом «я с тем, кто платит больше» недописанные куски проектов кидаются на более ответственных «сеньёров» у которых цель — таки допилить проект, а не свалить на более высокую зарплату. И они вкалывают по выходным, разгребая спагетти брошенного кода, пытаясь скрестить получившихся ежей и ужей.
А в остальном… Да. Программирование — это просто.