Life

Так получилось, что по ряду причин я снова ищу работу, причем достаточно срочно.

Готов как на full-time, так и на part-time или разовые таски.

CV по ссылке: https://dl.dropboxusercontent.com/u/5521262/CV2015.pdf

Если вкратце - умею достаточно много всего, но основные скиллы находятся в области Windows(это как .NET, так и нейтив, на C++ и не только), Web-разработки (ASP.NET MVC, Silverlight, разнообразный client-side веб, вроде AngularJS, и т.д. и т.п.), Erlang, и конечно Lisp.

Предложения лучше всего слать на lovesan.ru at gmail.com

_{Тег lisp для попадания в рассылки.}

COM - очень хорошая штука. Очень.

На C++ невозможно писать без lightweight-вариации COM(т.е. IUnknown и все дела) или его аналога.

Управление памятью, ABI, инкапсуляция, динамические приведения типов. Очень удобно.

Я лично все свои проекты на C++ стараюсь завернуть в lightweight COM.

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

Как пример - отношение объектов родитель <-> ребенок(или часть <-> целое) - так как обе стороны отношения хранят ссылки друг на друга, и ни один умный указатель проблемы циклических ссылок не решает, за такими делами надо очень пристально следить и тестировать. Тут кстати надо заметить, что в реальной практике циклические ссылки очень часто встречаются опосредственно. Т.е. например один объект хранит указатель на второй объект, второй хранит указатель на третий, третий хранит на четвертый, четвертый на пятый, а пятый на первый. Ну и пиздец, стоит не продумать мельчайшую подробность в отношениях, и всё, целый граф объектов утекает. Это, кстати, по-моему, основная причина утечек памяти в современных веб-браузерах.

Проблемы эти неискоренимы покуда мы используем C++, вообще никаким образом. Потому что, да, GC нет.

Другой род проблем(который кстати затрагивает вышеупомянутое), как я уже, вроде бы, писал в juick - обработка событий. С lightweight COM я делаю outgoing-интерфейсы(конечно не с таким количеством boilerplate, как в ядре COM, а просто тупо позволяю объекту принимать интерфейсы, методы которых он вызывает при возникновении события). Это, кстати, и проще, и даже удобнее, чем Qt-шные сигналы и слоты(я их лично не перевариваю - они и выглядят угребско, и в использовании не особо удобны, и, опять же, с управлением памятью не все так гладко).

Короче, вердикт - C++ это пиздец говно. Не используйте C++. Ну, на крайний случай используйте C++/CX

https://github.com/Lovesan/D3DU

Добавил новый пример - кубик с фракталом Мандельброта на гранях, который рисуется пиксельными шейдерами(если поставить сильно большой MAX_ITERS в шейдерах, дико тормозит -- но, все-равно, отрисовка на порядки быстрее, чем на процессоре(даже если использовать SSE) -- на моей не сильно новой видеокарте например при 80 итерациях вполне себе живое и двигающееся изображение -- а если ту же фигню рисовать например через GDI+, то оно будет тормозить просто невозможно. Современные GPU таки великая вещь.).
https://github.com/Lovesan/D3DU/tree/master/MandelbrotCube
( картинка )

Также, добавил полезный интерфейс ID3DUFloatAnimation (сигнатуру практически украл из WPF, угу)
( Read more... )

Также, добавил три функции-обертки над D3DCompile:
( Read more... )

Так как у всего этого, как я уже говорил, lightweight-COM API, то использовать можно из любого языка, который способен вызывать сишный код.

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

Как известно, система пакетов Common Lisp является одним из его наиболее "слабых" и наименее продуманных мест.

Так вот, я тут думаю, какую бы систему неймспейсов добавить в свой Microlisp(и соответственно, во встроенный лисп, используемый в программе, которую я пишу для стартапа).

И вот такой возник вопрос:
Какая система разрешения имен неймспейсов вам кажется более удобной, логичной и продуманной:

Как в C++ или как в C#?

Конкретно, вот что я имею ввиду:
( Read more... )

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

Не перестают меня удивлять и заявления о том, что де, раз в C++ есть boost, с его shared_ptr и прочим, то проблема сборки мусора для C++ фактически решена.

Ладно уж, не будем о том, что счетчики ссылок неспособны разрешить циклические зависимости, просто сравним ту самую производительность, за которую писатели на C++ так трясутся.

Тест, который я придумал, очень прост, но в то же время очень показателен.

Заключается он в следующем:
Создаем вектор на 'length' элементов, заполняем его указателями на структуры, подобные лисповым cons-ячейкам, и 'n' раз прогоняем цикл, в котором создаем копию этого вектора, а старый удаляем(элементы при этом мы не копируем, а копируем только указатели на них). Указатели, в C++, естественно, используем "умные".
В качестве противника C++, то есть в качестве языка, в реализациях которого присутствует нормальный GC, я взял Common Lisp, если конкретно - SBCL.

( Read more... )

Все-таки, только пописав немного на плюсах, начинаешь понимать, как охуительно прекрасна объектная система Common Lisp.

( Read more... )