Долгое время занимаясь разработкой под Android, я постепенно пришел к выводу, что многих вещей мне, как разработчику, сильно не хватает. Тогда, в начале 2010-го, не хватало только C++ exceptions и RTTI. Без них любой нетривиальный C++ код просто не мог быть портирован на Android и требовал практически полного переписывания. Это было очень существенное ограничение, которое никак не давало мне покоя. К счастью, Android — это open source, поэтому, вооружившись максимой «если тебе что-то нужно, сделай это сам», я засел за работу. К моему удивлению, сделать поддержку полноценного C++ с исключениями и RTTI оказалось довольно несложно. Потребовалось всего около недели работы. Далее был сделан сайт, на который и были выложены получившиеся пакеты для Windows, Linux и Mac OS X, а также патч и инструкция по сборке.

Привет всем!
По роду деятельности я программист на Java. Последние месяцы работы заставили меня познакомиться с разработкой под Android NDK и соответственно написание нативных приложений на С. Тут я столкнулся с проблемой оптимизации Linux библиотек. Многие оказались абсолютно не оптимизированы под ARM и сильно нагружали процессор. Ранее я практически не программировал на ассемблере, поэтому сначала было сложно начать изучать этот язык, но все же я решил попробовать. Эта статья написана, так сказать, от новичка для новичков. Я постараюсь описать те основы, которые уже изучил, надеюсь кого-то это заинтересует. Кроме того, буду рад конструктивной критике со стороны профессионалов.

Начиналось все как и в прошлый раз, достаточно прозаично: мне пришлось разработать *-надцать ViewModel-ей для своего MVVM-приложения.
Для того, чтобы они оптимально работали как ViewModel-и, мои классы должны были наследоваться от DependencyObject или же реализовывать заезженный до дыр интерфейс INotifyPropertyChanged (INPC).

Давно уже ни для кого не секрет, что DependencyProperty тормознее ручной реализации INPC. Мои тесты показывают, что запись в DependencyProperty в ~13 раз медленнее ручной реализации. Поэтому я, как неисправимый оптимизатор, склоняюсь именно к INPC. Тем более, что код поддержки INPC выглядит логичнее и органичнее, чем описание DependencyProperties.

Введение

Кому не приходилось изготавливать печатную плату? Дело это не очень сложное, а результат придаёт проекту завершённость. В этом посте я бы хотел рассказать о процессе создания печатной платы на дому. Я опишу фоторезистивный метод создания платы. Он довольно прост в применении и позволяет печатать весьма сложные платы. Более того, я обошёлся струйным принтером.

Пост содержит фотографии, видео и схемы.

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

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

Иллюстраций: 34, символов: 51 609.

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

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

В качестве вступления

Модель push-нотификаций является распространённой моделью для обмена сообщениями. Она подразумевает не получение информации по запросу, а немедленную её передачу отправителю при появлении этой информации на сервере.

Стандартный подход с ипользованием wsDualHttpBinding

Возможность создания push-механизма предоставляет и WCF. Этот фреймворк позволяет создать push-сервис с использованием wsDualHttpBinding контракта. Такой контракт позволяет для каждого запроса определить метод обратного вызова, который будет вызван при наступлении какого-либо события.
Если применить этот механизм к системе обмена сообщениями, то получим следующий алгоритм:

Думаю сейчас слова IoC, DI, IoC-контейнер, как минимум у многих на слуху. Одни этим активно пользуются, другие пытаются понять, что же это за модные веяния.

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

“C++11 feels like a new language.” – Bjarne Stroustrup

Не так давно Герб Саттер открыл на своём сайте новую страничку — Elements of Modern C++ Style, где он описывает преимущества нового стандарта и то, как они повлияют на код.

На днях нужно было написать программу, вычисляющую среднеквадратичное приближение функции, заданной таблично, по степенному базису — методом наименьших квадратов. Сразу оговорюсь, что тригонометрический базис я не рассматривал и в этой статье его брать не буду. В конце статьи можно найти исходник программы на C#.

Судя по всему, неделя исключений на хабре успешно наступила :). Накопив достаточную «подушку» кармы чтобы не бояться уйти в минус, я, пожалуй, тоже выскажу свое мнение по данному вопросу. Сразу оговорюсь, что мнение сугубо личное, основанное на небольшом практическом опыте коммерческой разработки: C++, Objective-C, C#, Java, Python, Ruby.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

В данной статье будет рассматриваться вызов управляемого C# — кода(.Net) из неуправляемого С — кода.
Как-то раз на работе дали проект, точнее даже не сам проект, а только его часть. Сам же проект состоял из двух частей: функционал, написанный на С (unmanaged code) и интерфейсная часть, написанная на C# (managed code). Моей задачей было написать интерфейс и связать его с функционалом.

Итак, Вы собираетесь создать новый [] функциональный, [] императивный, [] объектно-ориентированный, [] процедурный, [] стековый, [] мультипарадигменный, [] быстрый, [] статически-типизированный, [] динамически-типизированный, [] чистый, [] богатый, [] не-искусственный, [] наглядный, [] простой для новичков, [] простой даже для не-программистов, [] абсолютно непостижимый язык программирования.

Не получится. И вот почему.

Введение

В этой статье я хочу рассказать об использовании некоторых конструкций, применяющихся для осуществления неблокирующей синхронизации. Речь пойдёт о ключевом слове volatile, функциях VolatileRead, VolatileWrite и MemoryBarrier. Мы рассмотрим, какие проблемы вынуждают нас воспользоваться этими языковыми конструкциями и варианты их решения. При обсуждении барьеров памяти вкратце рассмотрим модель памяти .NET.

Около года назад я писал статью о том, как можно вызывать методы классов написанных на чистом Си++ из любой .NET программы не прибегая к регистрации COM библиотек, C++/CLI и т.п.

Сегодня я расскажу об еще одном оригинальном и весьма удобном подходе, а, кроме того, этот топик будет интересен всем хаброчитателям которые хотят побольше узнать о замечательном инструменте Reflection.Emit (на мой взгляд эта тема на хабре недостаточно хорошо освещена).

Достаточно большое название? Да? В этом посте я покажу Вам альтернативный подход в создании простого событийно-ориентированного HTTP-сервера на C#, используя мощь Reactive Extensions.