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

Это куда как проще оказывается. :-)))

У меня, скажем, как-то валялась статья, в которой я года 3 не мог разобраться. Ну не простой там был код, не простой. Пока, наконец, за одно утро, сидя в очереди к врачу, я не понял, что код - просто туфта. Т.е. показатель эффективности (отношение времени потраченного на разбор кода ко времени потраченному на его разгром) - несколько сотен. И если б это было единожды...

А не забавно ли, мягко говоря, что начинающий программист на Win32 мало того, что не способен написать thread-safe синглетон, но и, в сущности, вряд ли сможет понять мало-мальски эффективное решение, не прослушав перед этим получасовую, как минимум, лекцию?

http://community.livejournal.com/ru_cpp/366267.html

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


Кстати 1: на Висте вещи вроде pthread_once тоже есть.
Кстати 2: fast_pthread_once

В который раз немножко поговорили про тонкости мультитрединга на С и виндах.

http://community.livejournal.com/ru_cpp/347512.html

Пора бы как-то разобраться с ООП и закрыть эту тему для себя. По возможности, окончательно. Предварительные выводы, скорее уж проектируемые направления работы:

1. Типы (интерфейсы, наследование классов от интерфейсов, правила переопределения функций в производных классах) есть более или менее удачная попытка реализовать строгую типизацию языков ООП. Неудачная типизация ограничивает возможности языка и ограничивает мышление программиста, воспитанного на основе её изучения. Чтобы разобраться в ООП, типизацию необходимо послать подальше.

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

3. ООП не универсально. Не всё ложится в его схему, и не должно ложиться. Даже моделирование объектов внешнего мира может не уложиться в конкретную ООП-схему. Может ли уложиться хоть в какую-то -- вопрос открытый. Им стоит заняться.

4. Правильное построение механизма наследования и типизации есть крайне нетривиальная задача. Только после проработки первых трёх пунктов имеет смысл ей как-то заняться.

the term spaghetti stack is closely associated with implementations of programming languages that support continuations. Spaghetti stacks are used to implement the actual run-time stack containing variable bindings and other environmental features. When continuations must be supported, a function's local variables cannot be destroyed when that function returns: a saved continuation may later re-enter into that function, and will expect not only the variables there to be intact, but it will also expect the entire stack to be there, so it can return again! To resolve this problem, stack frames can be dynamically allocated in a spaghetti stack structure, and simply left behind to be garbage collected when no continuations refer to them any longer. This type of structure also solves both the upward and downward funarg problems, so first-class lexical closures are readily implemented in that substrate also.

via wikipedia

ой, какой раритет появился:
Пильщиков. "Язык Плэнер" (советская серия "библиотечка программиста")
[link]
да еще скан экземпляра за подписью автора.

Сейчас медитирую перед четырьмя небезынтересными и там-сям рекомендованными книшками:

Хендерсон П. - Функциональное программирование, применение и реализация -- пока напечатал и прочитал несколько десятков страниц, вводит в тему на неплохой очень скорости, изложение строится вокруг Лиспа. Интересно. Но пока мало прочитал.

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

John Harrison - Introduction to Functional Programming -- пока не открывал. Обсуждаемый язык - ML

Хювёнен, Сеппянен - Мир Лиспа. -- пол-первого тома мне показались фатально скучными. Потуги автора на оригинальность (какие-то иконки на полях книги) не вдохновили. Пожалуй, если бы не имел отрывочной информации по Common Lisp, то и не осилил бы. Второй том, впрочем, обещает быть очень насыщенным чем-то вполне нетривиальным. Кажется. Будет время - буду вычитывать дальше. Со стоном.

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

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

На знаменитом ныне sql.ru (где ксеноцефал) я недавно обнаружил упоминание работ Luca Cardelli из Microsoft Research.

На мой вкус, колоссальный чувак. ( Read more... )

Где ООП явно не в тему - это ГУИ (пример правильного построения гуя - Fudgets).

[link]

Я так-сяк повертел это заявление (и прочие, прочитанные на sql.ru), вспомнил некоторые почему-то не получившиеся для написания задачи из своей практики, равно как и некоторые "гениальные ООП решения", и сформулировал супер-радикальный тезис:

Объектно ориентированное программирование менее всего подходит для отображения объектов реального мира (включая сюда и объекты - элементы GUI) в объекты (в терминологии OOP/D) программы.

Пожалуй, истиннонсть этого тезиса мне пока трудно всерьез обосновать (ложность же напрашивается). Но что-то в этом есть. По крайней мере, стоит об этом тезисе вспоминать, прежде чем бросаться всё и вся выражать в виде объектов и протокола их взаимодействия, а потом тупо думать - что ж оно всё никак не выражается?

Почитать, что ли Симулу какую... Для избавления от ереси неверия в то, во что верил последние 14 лет.

Я даже не знаю, как это отрекламировать.

Короче, если Вы не гениальный программист, возможно, Вам стоит это почитать

избиение младенцев

на 6-й странице из 66 я понял, что мертв профессионально. Собственно, это и раньше подозревалось, но не с такой ощутимой ясностью.

Продолжаю читать дальше. Весело. Конспектируя ссылочки.

via potan

xref

upd: прочитал всё полностью. жутко доволен