воскресенье, 27 декабря 2009 г.

Обработка событий - что и как получать?

Варианты именно реализации подписки и обработки в самих потребителях событий здесь не буду рассматривать: все эти наследования реализации, наследования интерфейсов, утиные типизации, - все их плюсы и минусы уже неоднократно обсуждались и потому не вижу особого смысла обговаривать эти аспекты снова.

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

При обработке событий можно выделить 2 аспекта: как мы получаем событие и что мы получаем с событием вместе.

При получении событий от источника сообщений возможны следующие варианты:
  • мы подписываемся отдельными потребителями на сообщения от соответствующих объектов источника
  • мы подписываемся на сообщения от всей системы-источника сообщений(при этом можно указать, что такие-то события нам нужны, а такие-то нет, но источником событий у нас служит система целиком)
В варианте с целевой подпиской мы не тратим время на фильтрацию сообщений и не ломаем голову, что мы что-то куда-то не туда отправили на обработку. В варианте с общей подпиской мы твёрдо уверены что ничего не пропустили. Т.е. у каждого подхода есть свои плюсы и минусы, впрочем как всегда...

Причины приведённые выше будут влиять на архитектурные решения, какой из вариантов выбирать: вариант с целевой подпиской выгоден в пределах одной системы и нескольких подсистем(продукты одной фирмы будут прекрасным примером реализации доставки сообщений), вариант с общей подпиской выгоден при стыковке сильно разнородных систем (практически все стандартные протоколы: MAPI, TAPI и т.п.)

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

Примером варианта с целевой подпиской может служить реализация доставки событий в COM, а примером с общей подпиской - WinAPI.

При предоставлении дополнительной информации сейчас наибольшее распространение получили два подхода:
  1. мы передаём все данные о произошедшем событии в функцию обработчик события, надеясь, что разработчику будет в дальнейшем этого достаточно.
  2. мы ничего не передаём, кроме собственно самого извещения, что событие произошло - с надеждой что разработчик получит всю нужную ему информацию сам.
А вот в этих-то зарослях и спрятаны основные грабли:

В варианте №1 ОЧЕНЬ часто забывают добавить константность для передаваемых параметров. И тогда следующий зарегистрированый обработчик может получить отнюдь не то, что ожидалось. И вообще, строить механизм вычислений с помощью обработчиков событий - не совсем хорошая идея ;)

Ещё одни тщательно разбросанные грабли (особенно их часто можно увидеть в КОМе) - это параметр, который контролирует будет ли отправлено сообщение следующему обработчику. Единственный вариант, когда это необходимо - это ситуация когда, событие в системе должно быть обработано не больше 1-го раза. В общем же случае, когда разработчик не знает кто зарегистрировался до/после него для обработки события, этот аргумент становится бесполезным или даже вредным - ибо становится возможным поломать поведение не только своей системы или системы источников событий, а и сторонних систем (на такие случаи мне везло в плагинах к Ворду :( ).

А самые заботливо укрытые грабли лежат в в варианте №2, когда общение между системой источником и системой потребителем идёт по 1-му каналу - заботливо укрывает эти грабли тот факт, что их не видно в однопоточном приложении. Но вот если в системе крутится несколько потоков, причём два и больше потоков могут отправлять события, то тут всё и начинается.
Пример:
Есть система с 2-я потоками, каждый из которых изменяет некоторую структуру данных в памяти, в целях потокобезопасности доступ к структуре закрыт критическими секциями, события отправляются после каждого изменения, но в целях быстродействия отправка событий сделана асинхронно. Потребитель событий должен забрать данные из этой же структуры данных - доступ опять же организован безопасно. На события подписан только 1 потребитель. В определённый момент времени происходит следующая ситуация: поток1 получил доступ к данным, успешно их поменял и отправил извещение, что он закончил работу; поток2 со спокойной цифровой душой получает доступ к данным, тоже их изменяет и тоже отправляет сообщение "всё ок - принимайте данные". Потребитель событий начинает забирать даныые по 1-му отправленому извещению, но то ли такт процессорный неудачно лёг, то ли sleep студент поставил, ну в общем не успел забрать данные до того как поток2 их изменил. И вот что делать в такой ситуации? - событие мы обрабатываем мы ещё 1-е, а данные уже лежат для 2-го события.
Т.е. у нас классический Data Race заботливо подготовленный системой, которая отправляет события.
Решить эту ситуацию можно сделав структуру данных, к которой имеют доступ источник событий и их потребитель, неизменной для потребителя пока он не закончит обработку события - это либо передавать в виде параметра в функцию обработчик (на что никто не пойдёт, т.к. сигнатура функций не менялась уже лет 10), либо блокировать доступ к структуре данных пока все обработчики не закончат, на что опять же никто не пойдёт - т.к. это существенно замедлит работу основной системы.

Уменьшить вероятность проблем можно запустив отдельный поток, который будет обрабатывать сообщение и копировать структуру данных как можно ближе к моменту запуска сообщения. А функции-обработчики событий будут работать как в варианте №1. Но это не решит саму проблему с подходом №2 - просто уменьшит вероятность возникновения Data Race.

Выглядит описанная ситуация довольно надуманной, но это описание работы с реализацией TAPI от Cisco. :(

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

пятница, 13 ноября 2009 г.

Результаты October 2009 ISO C++ Standards Meeting


Общее итого: Афигеть!

Теперь по пунктам:
1. Стандарт так и не был не утверждён, и большая часть встречи была посвящена закрытию "тёмных углов". - Это понять можно. При этом, опять же, закрыли не все проблемные места. - А вот это уже понять сложно, т.к. разработчики C++ компиляторов уже начали наступать на эти грабли (для примера можно посмотреть объяснения от MS VC++ Team - почему они в срочном порядке доделывали null_ptr в своей бете2 студии 2010).

2. Следующая встреча в марте 2010 года. Посвящена будет оставшимся проблемным местам в стандарте. Вот не понял, зачем было откладывать на полгода - что ещё осталось шлифовать? Ладно, я ещё могу понять Python с их PEP3003, ибо надо чтобы альтернативные реализации догнали основную и наиболее популярные библиотеки вышли уже с поддержкой Python3. Но что хочет дождаться комитет для C++ - просто не понимаю...

3. Они умудрились потерять главного, по их же словам, организатора и текущего председателя комитета P.J. Plauger, который к тому же был самым опытным среди них во взаимодействии с ISO. При этом он не выдержал обычного 3-хлетнего срока - вот это понять даже сложнее, чем просто уход с поста председателя из-за перевыборов. О замене даже не договорились, хотя вызывается добровольцем Саттер, как председательствовавший предыдущие 2 срока. Но это немного не тот человека из-за того, что активная фаза создания стандарта уже закончена и надо заниматься политикой, а не разработкой.

С учётом вышеизложенного, текущих темпов, того, что на мартовской встрече понадобится закрыть баги и неясности, которые остались открыты после этой встречи, и если будет предложение очередной "новой маленькой" фичи, то как бы стандарт не стал C++0xB или даже C++0xC. Хотя в последнем есть своя суровая гармония. :(

P.S.

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

среда, 21 октября 2009 г.

Блог Саттера: Опрос

Герб Саттер проводит опрос на тему: какие темы в конкурентном программировании на C++ осветить в дальнейших постах. You're welcome to participate.

В целом его блог для программистов на C++ из набора "очень желательны к ознакомлению". А цикл статей "Effective Concurrency" - это уже из набора "обязательных к прочтению", - 90% вопросов, которые возникают в процессе работы и на собеседованиях уже освещены.
Очень советую к прочтению.

P.S.

Вот и как на русский перевести правильно concurrency programming?.. Многопоточное и конкурентное программирование это всё же другие оттенки смысла.

четверг, 15 октября 2009 г.

Сортировки и сборки...

В http://www.reddit.com/r/programming/comments/9jj5z/vladimir_yaroslavskiys_dualpivot_quicksort/ прочитал об улучшении классического quicksort'а при помощи добавления второго опорного элемента. Автор показывает, что для худшего случая время работы получается на 20% лучше, чем у стандартной реализации.

Меня это заинтересовало. Да и захотелось сравнить с другими сортировками, а то использую в рабочем коде только обощённый метод из стандартной библиотеки C++, а в быстрых поделках на колене - шеловскую сортировку (настолько к этому сочетанию уже привык, что кажется - подними с кровати, напишу использование на полном автомате, не просыпаясь).

Для сравнения были выбраны следующие сортировки: реализация quicksort'а в лоб без каких-либо улучшений, реализация quicksort'а с использованием сортировки вставкой на малых массивах, dual pivot quicksort, sort из стандартной библиотеки C++ (чтобы был наглядней результат), quicksort из C runtime(насколько я понимаю, тут используется реализация из стандартной библиотеки C) и сортировка Шела с шагами 2^n -1.

Измерения проводились на векторе в 5 миллионов int'ов. Использование обощенного контейнера было основано на необходимости использовать в сравнении обобщённый sort из стандартной библиотеки C++. Среди контейнеров же был выбран вектор, т.к. хотелось посмотреть на результат qsort из C Runtime Library.

Измерения выполнялись в MS VC++2005.

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

понедельник, 28 сентября 2009 г.

Unicode - Питон, PyQt, XML

В процессе написания небольшой тулзы для себя столкнулся с граблями при чтении/записи unicode строк полученых из QT-ишного элемента управления в xml и назад. Полдня потратил на раскапывание причин и борьбу с ними.

суббота, 26 сентября 2009 г.

No Time for JAVA

Конечно, вещь известная, но не могу удержаться :)

Lyrics by Herb Sutter

I've tried Pascal, time after time
I've done my COBOL but committed no crime
C pointer mistakes, I've made a few
I've had my share of Lisp and Haskel and Scheme but I still haven't a Clu
(and on and on and on and on)

We are the champions, O Bjarne!
And we'll keep compiling till the end
You've made us champions, we are the champions
No time for Java 'cause we are the champions
Of the world!

I've taken my macros, and my function calls
I've enjoyed speed and performance and everything that goes with C, I love them all
But C's been no bed of roses, and Ada's no pleasure cruise
I want abstraction and optimization both, so I ain't gonna use...
(and on and on and on and on)


среда, 26 августа 2009 г.

Популяризатор

Оформилось при написании предыдущего поста и разрослось в отдельный пост.

В C++ есть очень много возможностей/фич, которые в связке могут давать больший выигрыш, чем  каждое по отдельности – т.е. существуют некие наборы, для которых 2+2=5. Что-то наподобие паттернов, только на языковом уровне. Мне самому это находить пока навык не позволяет, только разве что почувствовать, что оно где-то рядом. Как пример того, что может дать больший полезный выхлоп чем кажется начально: лямбды и стандартные алгоритмы, Valarray, срезы и обработка больших массивов данных…

Но Community C++ сильно нехватает Популяризатора – да, именно популяризатора с большой буквы. Причём не только русскоязычному, а и мировому.

Нет человека, который выступил бы в некотором роде “локомотивом” для C++. У Python есть Гвидо ван Россум, у C# - Microsoft целиком, даже у Java есть(был?) Sun, который раскручивал этот язык.

А у C++ никого/ничего подобного нет: Страуструп ушёл в развитие возможностей языка, Эккель сам говорит, что его больше интересует Python по различным причинам, Александреску заблудился в “лабиринтах шаблонов”, Майерс – где-то рядом с Александреску ( пока… - хотя тут возможен вариант), Степанов – ближе к научному программированию, Саттер – он подходит больше всех сейчас на роль популяризатора , но у него, уже на момент публикации “Free lunch is over” в 2003, оформилась многопоточность и всё с ней связанное, как основной приоритет. Т.е. Личности в Community C++ есть, но нет именно Популяризатора.

А ведь ситуация сейчас складывается довольно выгодная для C++: выросший рынок мульти-платформенных приложений с появлением сильного Qt может быть почти полностью привязаться к C++ на ближайшие 5-10 лет, постоянно растущий рынок embedded с его требованиями к эффективности склонен использовать C++, а не Java, C#, Python и иже с ними.

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

Философия С++. Брюс Эккель.


По прочтении “Философия С++” Брюса Эккеля оформилось несколько мыслей, которые собственно и попытаюсь сформулировать.


  1. Основная мысль - Раньше её надо было прочитать, значительно раньше! Хотя бы сразу после “Паттерны проектирования” GoF. Ибо глава посвященная петтернам у Эккеля кроме собственно объяснений паттернов содержит реализацию паттернов на C++ и критику по паттернам. Т.е. позволяет паттерны хорошо утрясти в голове. При чём эккелевские примеры реализации содержат часто моменты, которые не видны при реализации “в лоб” при переносе оригинала с Java – соответственно мог переступить через несколько граблей, а не проверять их своим лбом. :(

  2. Возможности языка, которыми не владеешь хорошо, склонен рассматривать как зло предварительной оптимизации. А как только овладеваешь ими на уровне “Conscious Competence”, то уже перестаёшь понимать почему ты раньше так их боялся.

  3. В таблице моё впечатление от отдельных глав – насколько стоило их читать, т.е. что они позволяют достичь

Том/ГлаваЧто позволяет сделать

Том 1

повторить основы
Том 2
Главы 1-4повторить основы
Глава 5: Templates in DepthВдумчиво разобраться с механизмом
Глава 6-7: Generic Algorithms and ContainersОчень вдумчиво разобраться с описаными механизмами
Главы 8-9повторить основы
Глава 10: Design PatternsОчень вдумчиво разобраться
Глава 11: ConcurrencyПрочитать для интереса, за исключением Summary, которое стоит вдумчиво разобрать. Всё равно у Саттера лучше.



Да, C++Primer я читал – пока кажется “предварительной оптимизацией” ;)

среда, 22 июля 2009 г.

Новости из Франкфурта

Пришли новости из Франкфурта – Concept’ы убрали из черновика стандарта, при том, что идея Concept’ов была, так сказать, блокбастером этого стандарта. Зато должны теперь успеть в срок со стандартом.

Зато мелких изменений очень много; и судя по тому как легко эти изменения будет использовать, – влияние на C++ они окажут как бы не большее чем Concept’ы.

Официально о Concept’ах – “этой особенности языка надо ещё выстоятся”… Похоже не совсем знают, как адаптировать к другим “плюшкам” в срок. Это было видно ещё раньше – стандартная библиотека в версии на сентябрь не включала в себя шаблоны с применёнными к ним Concept’ами.

В большинстве применений Concept’ы позволяют просто получать более читаемые ошибки для template’ов на соответствие некоторому интерфейсу, но насколько же с ними было бы удобно это делать:

Для меня введение Concept’ов (в виде automatic "concepts", на котором настаивал
Страуструп) позволяло перейти к питонообразному подходу при работе с шаблонными
функциями и классами. – Получать такие же значащие сообщения об ошибках можно и
другим способом – хоть через попытки приведения к некоторому интерфейсу или
родительскому классу. Но всё таки отношения вида “работая с этим шаблоном вы
обязуетесь, что ваш объект соответствует некоторому интерфейсу и
обладает некоторыми свойствами”, удобней чем “работая с этим шаблоном вы
обязуетесь, что ваш объект реализует некоторый интерфейс”. Т.к. в 1-м
случае набор функций в интерфейсе можно получить от различных источников
наследования, а во втором случае надо наследоваться от обязательного интерфейса,
что порождает ненужную связь в архитектуре, да и усложняет работу вцелом.

Так что, ждём этого стандарта и готовимся к следующему, в котором Concept’ы уже надеюсь будут.

Ссылки по теме:

Саттер: http://herbsutter.wordpress.com/2009/07/21/trip-report/

Страуструп: http://www.ddj.com/architect/218600111?pgno=1

среда, 15 июля 2009 г.

4 уровня компетентности

The "Kirkpatrick Model" by Donald L. Kirkpatrick gives four levels of (increasing) competence:

  • Unconscious Incompetence = you don't know that you can't do it well.
  • Conscious Incompetence = you know you can't do it well.
  • Conscious Competence = you do it well, and you think about the work as you do it.
  • Unconscious Competence = you're so successful it's "automatic" -- you do it well, without thinking about it.

    Красиво сказано… На текущих задачах скорее на 3-м уровне со значительным сдвигом в сторону 4-го. Хотя управленческая часть работы - это скорее 2-й уровень и может изредка 3-й.

  • четверг, 9 июля 2009 г.

    Python декораторы

    Казалось бы всё просто: декораторы – это просто статические фукции.

    Но ведь это функции, а в функции вполне можно передавать различные параметры… Причём не обязательно это должны быть константные значение либо имена типов (как пользуются декораторами почти везде). В декоратор можно передать значения считаные из файла настроек; главное, чтобы значение было определено до того как объявляется применение самого декоратора к функции. Для примера декоратор @measures получает на вход 3 разных значения, а значит функции linerFib, linerFib1 и stubFib будут “обрамляться” разными строками.

      1: teststring = 'test1'
     2: teststring1 = 'test2'
     3:  
     4: ...
     5:  
     6: @measures(teststring)
     7: def linerFib( n ):
     8:     fn = f1 = f2 = 1
     9:     for counter in xrange(2, n):
     10:        fn = f1 + f2
     11:         f2, f1 = f1, fn
     12: return fn
     13:  
     14: @measures(teststring1)
     15: def linerFib1( n ):
     16:     fn = f1 = f2 = 1
     17:     for counter in xrange(2, n):
     18:         fn = f1 + f2
     19:         f2, f1 = f1, fn
     20: return fn
     21:  
     22: teststring1 = 'test xxx'
     23: @measures(teststring1)
     24: def stubFib( n ):
     25:     return 5

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

     1: class Drawer(object):
     2: def __init__(self, func, test):
    # подготовка и инициализация для вызова декорируемой функции
     3:     self.func = func
     4:     self.test = test
     5:  
     6: def __call__(self, *args):
    # сам вызов
     7:     print self.test
     8:     return self.func( *args )
     9:  
     10: def measures(test):
     11:     return lambda func: Drawer(func, test)

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

    вторник, 30 июня 2009 г.

    Защитное программирование

    Чтобы не забыть и чтобы было куда посылать...

    Часть мыслей честно утащена у Эккеля и других авторов, здесь сведено в одну таблицу и отражена суть что и где применять. Вопрос “когда применять” не рассматривается, ибо не корректен – применять надо всегда.

    Есть 3 вида конструкций для защитного программирования: исключения, assert’ы и проверки. Применять при:

      Исключения assert’ы логические проверки
    взаимодействия с внешними системами и сторонними модулями да нет да
    создание новых объектов да нет нет
    своя логика нет да да
    проверять юнит тестами поведение? нет да да
    оставлять в релиз версии да ? да

    Взаимодейстие с внешними системами/модулями – не известно, что там может произойти, как организован код сообщающий о ошибочных результатах и насколько безопасно сторонний код написан, потому лучше закрыть try/catch блоками для безопасности. Иногда для проверки результата действий может хватить и кода ошибки. Хотя проверять, что тебе отдали валидные данные, всё равно надо.

    Создание новых объектов – тут кроме исключений больше ничего не поможет защититься от ошибок.

    Своя логика – проверять что ты ничего вредного или чудного не передаёшь внутрь.

    С юнит тестами связан следующий момент: 
    все три конструкции должны проверять только важное на данном этапе, а не всё подряд – иначе это может привести к сложностям при написании юнит тестов. Подробней смотреть link.

    Оставлять в релиз версии – а вот тут есть разные мнения. Начиная от сравнения “ходить по суше в спасжилете, а перед выходом в море снимать его” и заканчивая “не нужно нам неконтролируемое падение системы”. Пмм, на этапе тестирования лучше иметь ассерты – более заметны, а соответственно лучше стимулируют исправление; а вот на этапе установки у заказчика лучше иметь логические проверки с логированием.

    пятница, 26 июня 2009 г.

    Новый Qt

    Вышел новый Qt/Qt Creator...

    По функционалу стремительно догоняет Visual Studio/Eclipse/NetBeans. А учитывая возможность интеграции в 1-е 2 упомянутых продукта, то появляется реально хорошая альтернатива Visual Studio и Eclipse при кросплатформенной разработке на C++.

    LGPL как базовая лицензия очень большой плюс для корпоративных кастомеров, по сравнению с предыдущей лицензионной политикой и текущей политикой от Майкрософта.

    Навязывание MVC/MVP как базового шаблона при построении архитектуры уже даёт большой плюс в усилении скилов сообщества разработчиков.

    А наличие биндингов для явы и питона ещё и приманивает соседей :)

    Интересно, ещё у кого-то остались сомнения о полезности покупки TrollTech Nokia'ей?

    среда, 10 июня 2009 г.

    Оценки времени выполнения задачи

    У Брюса Эккеля в его "Философии C++" натолкнулся на замечательную оценку времени необходимого для выполнения задачи:

    "Прикиньте, сколько времени потребует ваш проект, затем удвойте это число и прибавьте еще 10 %. Скорее всего, ваше внутреннее ощущениевас не подводит; вам действительно удастся получить нечто работоспособное за это время. Еще столько же времени уйдет на то, чтобы привести это «нечто» к более или менее приличномувиду, а последние 10 % уйдут на шлифовку и всякие мелочи...

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

    Собственно это классическая оценка с помощью числа Pi : "возьмите вашу оценку времени выполнения задачи и умножьте её на Pi, при этом Pi в зависимости от опыта может колебаться от 1,5 до 4"... :) Просто не ожидал её встретить у “самого Брюса”.

    Хотя для понимания откуда берётся это Pi в реальной оценке, лучше посмотреть следущее сообщение с rsdn.ru. Оно как-то более точно позволяет оценить время на выполнение задачи. Сам уже начал пользоваться этими пунктами :)

    Теперь разберем из чего состоит задача.
    1. Если код незнакомый, знакомство. Понимание через отладку. Если нужно рефакторинг. Понимание через рефакторинг.
    2. Проектирование нового функционала. Подробное. А не в уме, как на совещании было.
    3. Подготовка кода к внесению изменений. Опять рефакторинг.
    4. Собственно кодирование. Говорит неделя, ну так 40 часов и запишем. И это только на пункт 4. А вы говорите 16-32.
    5. Интеграция с остальным кодом. Это то что в пункте 3 делали, но теперь уже начисто.
    6. Тестирование (в это время можно программеру дать другое задание), либо дать на проверку код
    соседа, попросить отревьювить код и т.д. Опять же старые баги есть наверно.
    7. А теперь откровение. Оказывается после тестирования надо баги поправить. Иначе зачем тестировать-то. А потом снова на тестирование и снова баги.

    Ну допустим у меня один баг в неделю на 20 коммитов. Но это в неторопливой обстановке. А ктоме того еще штук десять в неделю "not a bug" и половинка "a change request"

    Далее пункты выполняемые совместно с остальными:
    8. Покрытие тестами.
    9. Документирование.
    10. Коммуникации с коллегами по работе, совещание.
    11. Коммуникации с начальством, отчеты, совещания.
    12. Чтение проф литературы, блогов, RSDN и т.д.
    13. Перерывы на отдых, чай, сигареты (кто курит), поболтать на различные темы.
    14. Обязательно поболтать с любимой/любимым по ICQ.

    А теперь начинаем думать. Я тут 14 пунктов перечислил, а программист (и я тож из таких) думает только про пункт 4.
    Причем если вам пункты 12 - 14 не нравятся, то программистам, да и вообще здоровым людям, они необходимы. За пункт 14 вообще перегрызу горло

    C++0x и NetBeans

    Не совсем понравилось экпериментировать с возможностями нового стандарта С++ на Eclipse, а потому до сих пор искал альтернативу. Реальных причин для отказа было 2, хотя уже сейчас могу придумать значительно больше:

    1. Неудачно выбраный порт с GCC: зачем выбрал Cygwin до сих пор понять не могу. Наверное сыграл инстинкт пользователя :), который долго воспитывали в Windows - "больше весит - значит лучше".
    2. Глюки. Как-то непривык при входе в отладку простого приложения наблюдать креш среды разработки.
    Ну и немного смущала заторможеность реакции среды на действия и слабая подсветка синтаксиса и подстановок по сравнению с Visual Studio/Visual Assist.

    Сейчас вроде бы нашёл альтернативу, где смогу вволю поэкспериментировать. Инструкция для тех, кому, возможно, будет интересно поиграться с C++0x на NetBeans в Windows.

    1. Скачать и установить NetBeans IDE у кого эта IDE ещё не стоит или добавить плагин C++ в уже установленую NetBeans IDE (http://www.netbeans.org/)
    2. Скачать MinGW порт c GCC версии 4.4. Выбрал MinGW, потому что он действительно min - весит меньше, а работает быстрее. На официальном сайте MinGW к сожалению последняя стабильная версия GCC ещё 3.4.5, кандидат 4.3., а нам нужна 4.4, в которой и сделана основная реализация фич из C++0x. Можно с взять с http://www.tdragon.net/recentgcc/ уже собраное с windows installer, а можно в классическом unix-way собрать самому из исходников - тут уж у кого как душа поёт.
    3. Также необходимо скачать и установить MSYS последней версии - сайт MinGW тут уже сможет помочь. Необходимо это, потому что NetBeans не дружит с MinGW make идущим в MinGW по умолчанию, да и на сайте MinGW настоятельно рекомендуется использовать make из MSYS.

    Теперь займёмся настройкой IDE:

    1. Запустить NetBeans IDE
    2. Выбрать Tools/Options/C++
    3. на закладке Build Tools настроить
    4. mingwsettings.JPG
    5. На закладке Code Assistance для C Compiler и C++Compiler надо нажать Reset settings для того, чтобы NetBeans IDE подхватило последнюю версию g++, а не расположеную в корне инсталяции MinGW. Почему не подхватить эти пути сразу - не знаю, наверное надо выделяться как-то на фоне Microsoft.
    6. migwincludes.JPG

    Общие настройки IDE закончены - остались только изменения в проекте.

    Теперь заголовки версии 4.4 подключаются в проект, но почему-то вся функциональность будущего стандарта не работает. Причина в том, что GCC требует включать эту поддержку дополнительной опцией, что в целом разумно, т.к. C++0x это ещё не утверждённый стандарт и работа с ним чревата изменениями, а потому строить production код на нём вряд ли кто-то будет. Выбрать настройки C++ проекта, перейти на группу C++ Compiler и поставить ввести "-std=gnu++0x" в Additional Options.

    среда, 13 мая 2009 г.

    Мысли о фишках C++0x

    Прочитал тут материалы проходящего БустКона и подумалось:

    Сейчас много идёт обсуждений о том, что будет реализовано в новом стандарте: лямбды, статические ассерты, концепты, аспектное программирование, rvalue references, variadic templates, новое поведение цикла for  и т.д. и т.п.

    Да, все эти вещи хорошо смотрятся и являются фишками стандарта. Можно даже сказать, что они рекламируют и вдыхают новую жизнь в C++. Но если реально  подумать, то наибольшее влияние окажут мелочи, которые будут применятся проще и чаще всего:

    • auto типизация - не морочим голову с тем как же пишется определения возвращаемых итераторов и лямбд, и смерть применению auto для локальных переменных;
    • списки инициализации - наконец-то простое заполнение контейнеров;
    • лямбда-функции и новое поведение for/for_each - перестаём ломать голову с функторами в обощённых алгоритмах;
    • строгая типизация enum - нет извращениям в преобразованиям к целочисленным типам и назад при работе с enum;
    • shared_ptr - garbage collector уже рядом.

    Эти "мелочи" за счёт своей легкости применения и чрезвычайно малого порога вхождения окажут наибольшее влияние на пишущих на C++. А вот тяжеловесные "новости" окажут очень слабое влияние - просто потому, что их будут применять чрезвычайно редко. Вон аспекты уже года 4 есть в C# - а как много людей пишет с их применением? Так что простота продолжит управлять миром.

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

    PS

    Вот интересно, как концепты уживутся с range'ами, которые начинает продвигать Александреску?

    вторник, 5 мая 2009 г.

    книга "My Job Went to India"

    Закончил чтение "My Job Went to India" Chad Fowler.

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

    А глава "If You Can’t Beat ’Em" достойна отдельного упоминания, т.к. показала причины проблем комуникаций с заказчиками в offshore программировании - честно говоря не ожидал такого хорошего разбора полетов. Сколько же наступал на эти грабли...

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