Глубоко в Джунглях

02:34 am - Классический взлом

197x-год, машина PDP-10, операционная система TENEX -- одна из первых ОС с виртуальной памятью. Проверка пароля производится примерно таким кодом:

    int len = strlen(directoryPassword);

    for (i = 0; i <= len; i++)
    {
        if (directoryPassword[i] != passwordArgument[i]) 
        {
            return 1; // плохой пароль
        }
    }

    return 0; // хороший пароль

03:33 pm

Продолжая тему предыдущего поста :) Вообще, исходно он был совсем не про образование, а немного шире, именно про пользу от теории... Но потом куда-то свернули. Ну да ладно, свернули так свернули.

Вывод будет в конце.

lumag

ran_dom

ushastyi

lazy_frog

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


• Алгоритмы, математику вообще. В любом языке есть функция sort, есть hashmap, есть ассоциативный массив какой-нибудь. Что там ещё надо-то?


• SQL и реляционную алгебру. Современные ORM прекрасно справляются.


• Как устроены сети ниже уровня "поток байт". Концепция сокета прекрасно маскирует всё нижележащее начиная с 80-х. А по последним данным сетей вообще нет, удалённые вызовы ходят прозрачно.


• Концепция файла эффективно скрывает все детали реализации файловых систем, все эти сектора и кеши.


• Выделение памяти происходит тоже само.


• Без многопоточности можно прекрасно обойтись в 99% случаев. Более того, это таки действительно хороший стиль -- без неё обходиться.


• Детали реализации ОС тоже не нужны.


• Пролог, хаскель, схема и прочая такая же ботва

• Синтаксис языка программирования


• Любимая библиотека

plugimz

ran_dom

12:48 am - Теория

Почувствовал пользу от теории :) Весьма, гм, специфическую.

Был у нас такой предмет "Перспективные микропроцессоры", вёл его Юрий Евгеньевич Шейнин. Рассказывал про конвейеры, кеш, предсказание переходов, векторные инструкции, VLIW прочее подобное. Мужик он умный, знает много, рассказывал интересно. Да и материал благодатный: это как раз тот случай, когда нужно понимать логику архитекторов, т.е. думать головой.

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

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

А теперь посмотрим, как эта общая образованность мне пригодилась.

Я сейчас читаю доки по POWERx/PowerPC. И там довольно много пишут про кеши, конвейер, переходы и т.п. И благодаря тому, что я в курсе, что это такое, я понимаю, что по сути ничего особенного они не пишут :) Так вот, поинт в том, что развив здоровый пофигизм в отношении непонятных деталей, интуицию и уверенность в себе, этого результата можно было бы достичь и без теории вообще :) Более того, в 99% случаев можно и без интуиции.

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

Upd: Как обычно, в комментах пришёл к сути того, что хотел сказать.

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

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

Да, и конечно, общее образование полезно, и мозги развивает, и вообще. Но, может быть, это не самый эффективный способ расходования [учебного] времени?

Я правда не знаю. Общие слова про расширение кругозора и сознания я и сам могу сказать. И мне тоже кажется, что это важно. И я сам этим для себя занимаюсь. Но мало ли чем я занимаюсь. У есть некоторые сомнения в собственной адекватности, так что это не аргумент. Ещё у меня нет никаких экспериментальных данных, и я даже не знаю, какие измерения могли бы решить проблему, т.е. нет даже никаких конкретных утверждений. Есть пока только вот такие вот смехуечки над практической полезностью теории :)

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

12:16 pm - Виртуальная память - 1 (дополнение)

Предыдущая часть тут.

Intel x86 (32-битные): дополнительные главы

Глобальные страницы (начиная с Pentium Pro)

Пробиваем барьер 4 Гб: зачем и как

• Посредством каких-нибудь ОС-специфик заклинаний пользовательский процесс может попросить ОС отобразить часть его адресного пространства куда-нибудь в другое место в ОЗУ. Поработать там, а потом переключиться обратно. А потом ещё раз обратно. А потом ещё куда-нибудь... Так, манипулируя отображением на разные части ОЗУ, можно делать вид, что много-много памяти доступно почти напрямую. Очень неудобно, но куда деваться на 32-х разрядном процессоре. В Windows есть система соответствующих заклинаний.


• Менее извращённый вариант. По 64-м доступным гигибайтам можно распределить разные процессы. Переключение будет происходить естественным образом при переключении контекста. Больше данных влезет в ОЗУ, будет меньше свопинга и больше счастья, и всё абсолютно прозрачно для приложений. Это умеют все уважающие себя ОС.

Пробиваем барьер 4 Гб - I (начиная с Pentium Pro)

12:15 pm - Виртуальная память - 1

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

Вам не повезло. Или наоборот -- повезло. Как посмотреть. В общем, тему защищённого режима x86 я знаю довольно туго. Поэтому получилось длинно, подробно и с кучей ссылок свои на собственные статьи :) Вот только код пока заленился писать. Придётся, конечно, но чуть позже.

Разбил на две части, иначе как-то многовато, слишком высока вероятность, что не прочитает никто :)

Intel x86 (32-битные)

• Адрес, выставляемый процессором на системную шину называется физическим. В рассматриваемой серии Intel x86 максимум -- 36-и разрядов. Для краткости "физическое адресное пространство" я буду по бытовому называть "ОЗУ".


• Адреса, которые используют прикладные программисты -- логические, имеют форму <сегмент>:<смещение>. Смещение -- 32 разряда.


• Логические адреса преобразуются в линейные, по формуле <база сегмента> + <смещение>. В типичной современной ОС базы типичных сегментов -- 0 (могут быть специальные сегменты, например сегмент FS в Windows NT). Линейный адрес тоже ограничен 32-я разрядами (да, действительно можно устроить переполнение).


• Линейные адреса преобразуются в физические. Если страничная адресация отключена, то <физический> = <линейный>. Если включена, то начинается то, ради чего мы тут собрались :)

10:51 am - Виртуальная память - 0

Скорее всего, все знают, как устроена виртуальная память в Intel x86 ...

Не. Это вряд ли.

Скорее всего, многие видели картинки, более-менее изображающие устройство виртуальной памяти в Intel x86. Как выясняется, есть и другие забавные и поучительные варианты того же самого.

Это должен был быть один большой пост. Но он получается слишком большой и я его уже пишу слишком долго. Поэтому пусть будет много маленьких.

[Ликбез] Виртуальная память: что это и зачем

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


• Памяти мало. Всем сразу не хватает.


• Памяти мало. А она ещё и фрагментируется. Допустим, загрузили процесс в память, за ним загрузили следующий, потом первый выгрузили. Осталась дырка. Эту память можно использовать только если будет загружаться процесс, по размеру не превышающий первый.


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


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

Сегментная виртуальная память

• Есть редко работающий процесс. Например, он отзывается на какие-то внешние события, типа прихода данных из сети.


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


• И вот доходит дело до этого процесса. Он пытается обратиться к своему сегменту данных... Но тот помечен как выгруженный. ОС получает тревожный сигнал, загружает сегмент в память (возможно, выгрузив для этого что-то не нужное), помечает сегмент как нормальный, прописывает ему новый базовый адрес и просит процесс повторить попытку. Как в жизни.

• динамическим выделением памяти (в принципе решаемо, но тяжело)


• фрагментацией физической памяти (хотя сегменты и можно перемещать, это довольно затратно)

Страничная виртуальная память

• все страницы одинакового размера


• меньше дискретность


• В пределах ВАП элементарно регулируется объём используемой памяти, с точностью до страницы можно помечать память как используемую или как неиспользуемую процессом.

• Адресное пространство других процессов оказывается за пределами языка. Оно просто не адресуемо, нет таких адресов, которые ссылаются на другой процесс. Чтобы как-то читать/писать в память других процессов нужно специально думать.


• При попытке обратиться к неиспользуемой памяти, процесс тоже получит от ОС по башке.

04:23 am

Наконец начал статью про КС-грамматики и парсеры.

Я в курсе, что про это не писал только ленивый. Но:
-- мне процесс важнее "практической полезности результата"
-- я думаю, у меня получится лучше :)

И как-то это непросто, так что, видимо, по мере продвижения будет несколько постов на эту тему. С надеждой, что умные люди подскажут.

E --> T + E | T
T --> I * T | I
I --> (E) | number | name

E --> T + E | Т - E | T
T --> I * T | I / T | I
I --> (E) | number | name

   -
 /   \
2     +
     / \
    1   1

E --> E + T | E - T | T
T --> T * I | T / I | I
I --> (E) | number | name

E --> T + E | Т - E | T
T --> I * T | I / T | I
I --> (E) | number | name | -I | %I

09:14 am - Всё украдено до нас...

Готовя предыдущий пост я прочитал и просмотрел некоторое количество древних манускриптов, ссылки на них приведены там и немного тут... Короче, я в шоке.

Как в любом толковом магическом романе: уровень знаний древних потрясает. V и QuickSilver разработаны в конце 80-х. Это распределённые ОС с микроядром, поддерживающие многопоточность и миграцию процессов между машинами. QuickSilver и этого мало, в ней встроенные транзакции.

Для сравнения: MS Windows 1.0 вышла в 1985-м. Windows 3.0 в 1990-м. Это были убогие оболочки поверх ОС реального режима. С невытесняющей многозадачностью... Короче, каменный век. Микроядро это всё ещё "перспективное направление". Транзакции? О чём это вы? :) Распределённая ОС, миграция процессов? Ненененене.

Справедливости ради: первая ОС защищённого режима для PC появилась в 1985-м, это была OS/2 1.0. Но я не столько про PC, сколько про мейнстрим.

Однако, смотрим дальше. Из The V Distributed System:

The basic notion of an operating system kernel that only provides an interconnection mechanism for connecting applications to service modules, and avoids implementing the services directly is quite old (выделено мной; уже тогда "quite old", статья написана 20 лет назад, ага -- С.Х.). For instance, Brinch-Hansen [5] developed such a system, the RC 4000, in the late 1960s....

... This system, one of the first academically reported message-based systems, was characterized by an elegant design and problematic performance. Other systems followed, including Thoth [9, 14], DEMOS [3] and Accent [28], but performance remained a key concern.

09:07 am - Другие потоки

Во-первых, не stream, но thread. Называть их нитями я пока не привык, хотя это, видимо, не за горами. Во-вторых они и тут немного другие, про такие threadы вы, скорее всего, не слышали.

Читаю сейчас книжку Юреша Вахалия Unix изнутри. Не слишком полезно: половину я более-менее и так знаю, 95% никогда "в жизни" не пригодятся... Но иногда очень интересные вещи попадаются. Конечно, из того, что не пригодится :) Вот одна из них.

Три года назад Дима Голубев подарил эту книжку мне на день рождения по моей же просьбе, вот, руки дошли :) Кстати, по ссылке на сайте Питера очень ругают перевод. Ну не знаю, вообще, понять что имелось ввиду пока всегда было можно. Но английский вариант на всякий случай скачал.

Все представляют, как устроены стандартные виндовые/юниксовые потоки? Что для нас сейчас важно -- наличие двух стеков: для пользовательского режима и для ядра (кто не знает зачем это -- вот :)). Ну, вполне естественное решение. Поток живёт какой-то своей жизнью, сохраняет что-то в пользовательском стеке, когда переключается в режим ядра -- точно так же, никакой разницы. Логичный и простой вариант. Вахалия называет это моделью процесса.

( Модель прерываний )
( Продолжения )

06:35 am - Лики памяти

Просто подумалось. Программисты поймут :)

07:52 am - HOWTO: Свой поток ввода-вывода, beta-1

Коллеги, я опять написал статью и мне опять нужна ваша помощь.

Кто ещё С++ помнит, прочитайте пожалуйста. Статья не маленькая, но вроде простая как две копейки. Про то, как коварным наследованием подчинить себе iostream и использовать его в своих гнусных целях.

HOWTO: Свой поток ввода-вывода

Статья ещё не опубликована, так что просьба не выносить ссылку далеко. Давайте считать, что у неё TTL=2. И не забывайте вычитать.

Отзывы нужны любые, от "ничего не понял, ужасно" до "всё понял, ужасно" через "ну, типа, нормально, чё говорить-то". Я автор мнительный, в себе не уверенный, в собственной нормальности сомневающийся, сторонние подтверждения мне важны.

Более-менее осознанно я сам смогу читать статью только где-то через неделю, сейчас я ещё в горячке, так что ни один здоровый человек этого пока не читал.

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

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

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

Upd2: Чуть-чуть обновил, лежит там же. Второй раз читать смысла нет. Изменения:
- примечание к _Read_s (где-то тут)
- совет после basic_buffered_istreambuf (чуть вверх отсюда)
- последний эпиграф стал менее прямолинейным :)

Upd3: Окончательно обнаглел. Добавил в начало абзац:

Конечно, я уже знаю «правильный ответ», и мог бы объяснить его как-нибудь короче, понятнее и систематичнее… Но мне кажется более интересным провести вас тем же путём, которым шёл я сам, по сторонам открываются потрясающие виды. Следуйте за мной.

Ай да я, ай да Пушкин. Делать вид, что я пишу технические статьи с каждым разом всё труднее.

Upd4: Удивительно, но народ не жалуется. Хм. Тем временем, следующее обновление. Из заметного:
- поменялся конец раздела про обобщённые символы, теперь там немного больше полезной информации.
- мне объяснили, откуда взялось имя eback, я описал это в статье.

04:29 pm - Дожили

Никогда не понимал скриптов

# В URL что-то типа "http://server1.server2.yandex.ru/path/file.xml"

URL_HOST=`echo $URL | sed 's/^http:\/\///' | cut -d / -f 1`
URL_PATH="/"`echo $URL | sed 's/^http:\/\///' | cut -d / -f 2-`

printf "GET $URL_PATH?type=5&xmldata=test HTTP/1.1\r\nHost:$URL_HOST\r\n\r\n" | nc $URL_HOST 80

Удивительно, что я это не только понимаю, но и сам написал :)

11:46 pm - Теория вычислений, программа, beta-1

Чему я буду учить детей весной, если дело выгорит (громко не ржать!):

( Вступительное слово )

Программа

04:53 am - Пирамиды

Когда-нибудь это будет маленькая но гордая статья, пока - так.

06:43 am - Криптографические хеш-функции -II

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

Мартин Хеллман, да, это тот самый Хеллман, который вместе с Диффи. Кстати, недавно смотрел забавный фильм про его молодость. Мужик зажигал! Но, став отцом, видимо, пересмотрел взгляды на жизнь и двинул в науку.

Компромисс время-память (Time-Memory trade-off)

Задача

08:05 am - Криптографические хеш-функции -I

Конспективное изложение курса, прочитанного Ильёй Мироновым в CSClub-е 17-18-24-го мая 2008.

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

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

( Всё, что вы не хотели узнать про хеш-функции потому что не догадывались спросить. )

В следующем выпуске - чудеса обращения. Оставайтесь с нами!

01:15 am - Запятые продолжают плыть

Наконец победил лень и желание "сделать ещё как-то получше, хотя не понятно как, но вот что-то..". По результатам обсуждения статья "Плавающая запятая" наконец обновлена. Пока только у меня, но админу я новую версию послал, скоро, надеюсь и тут появится.

Нового кот наплакал: раздел Сравнения и ещё несколько мелочей. Хотелось больше, но как-то не получилось.

11:21 am - Эпиграф

Ядра - чистый изумруд

А.С.Пушкин о http://kernel.org

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

04:08 am - C++

Что было

• часто элементом задачи (или элементом очевидного оптимального решения) является «используя существующий код на …» Угадайте, на каком языке? На С, конечно; количество кода на других языках тогда было пренебрежимо мало по сравнению с С (ну, Фортран ещё, но Фортран из С/C++ использовать тоже можно, я даже сам как-то пробовал).


• а вторым элементом так же часто бывает «и чтобы работало быстро!» Причём на тех машинах, не на современных. Причём не просто «быстро», а «не медленнее, чем на С»


• третьим – необходимость писать код сегодня, а не переучиваться.


• четвёртым элементом... Опять же надо учесть время. Тогда писалось гораздо больше низкоуровнего системного софта.

• В цифрах:
  
  За двенадцать лет число пользователей С++ в среднем удваивалось каждые семь с половиной месяцев. (7.1) --- закон Мура отдыхает! - С.Х.
  
  Компания Rational поставляет С++-версию библиотеки The Booch Components, которую Грейди Буч (Grady Booch) первоначально реализовал на языке Ada. На С++ её переписали сам Буч и Майк Вило (Mike Vilot). Версия на Ada занимает 125 тыс. строк исходного текста без учёта комментариев, на C++ - всего 10 тыс. строк. (8.4.1) --- Оцените прорыв в выразительности языка. И это без ущерба для эффективности! Так что сравнения с "квиксорт на Хаскеле в 2 строчки" не корректно - С.Х.


• Цели и ограничения:
  
  С++ это язык, а не законченная система.[...] По своему замыслу С++ - это лишь один язык среди многих. (4.2)
  
  Не оставлять места языкам более низкого уровня, чем С++, исключая ассемблер (4.5)
  
  С++ проектировался как язык для системного программирования и разработки приложений, в которых есть большой системный компонент. (7.4.2)
  
  Если в компиляторы С++ не будет включён необязательный сборщик мусора, то в определенных областях С++ займёт невыгодные позиции, но я уверен, что такие компиляторы скоро появятся повсеместно. (9.3.2.2)
  
  C++ не является идеальным инструментом для приложений, где не нужны развитые системные компоненты, а требования к быстродействию и потреблению памяти не слишком жёсткие. Однако при поддержке со стороны библиотек и, возможно, сборщика мусора, он может найти применение и здесь. (9.3.2.5)


• ( Случаи из практики )


• ( Философское )

Чем сердце успокоилось

SH> Фокус в том, что правильно спроектировать библиотеку на C++ сложнее. ...
SH> Причина — С++ слишком заботится о байтах. О машинном представлении ...

Немного разверну.

В качестве "гарантированно переносимого" С++ предоставляет слишком низкоуровневые абстрации. Везде есть int, char, указатели. И, в общем, всё. Т.е., если библиотека хочет, чтобы её "понимали" все, она должна общаться с пользователем на языке, состоящем из int, char, указателей. Иначе это уже не просто библиотека, а, например, MFC-библиотека. Или ATL-библиотека. Или STL-библиотека. STL почти всем хороша, но её неудобно использовать из MFC-приложения..

Всё это усложняет совмещение нескольких библиотек, и/или фреймворков друг с другом. И написание "правильных" библиотек тоже усложняет.

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

Что будет

• ( Дополнительно о периоде 1991-1998 )


• ( Про новенькое )

• Много внимания уделено улучшениям шаблонов. Собираются (пока не приняты, но они очень стараются, правда) добавить понятие "концепции" (concept), позволяющее явно вводить ограничения на типы параметров шаблона. Уже приняты псевдонимы для шаблонов (насколько я понимаю, параметризованный typedef, но мне лень было разбираться). Шаблоны с переменным количеством аргументов (не вкурил пока, как это)... Ещё что-то куда-то туда же.


• Лямбда-функции. Гы :) Конечно, они получились "немного кастрированные" :) Если я не ошибся, то честных замыканий не получилось и вернуть лямбду в качестве результата работы функции нельзя. Ну, а чего ещё можно сделать в языке, который хранит локальные переменные в стеке. Но всё равно это немерянно круто, это расширяет использование всяких find_if и for_each до полного беспредела. Хотя это можно было и сейчас, т.е. это просто синтаксический сахар... Но сладенький :)


• Поддержка многопоточности делится между языком и библиотекой. Что куда я не понял :) Страуструп пишет, что язык поддержит TLS (ещё не принят) и атомарные операции (уже приняты, там вроде написано про библиотеку, не вникал). А библиотека реализует интерфейс к потокам в стиле Windows/POSIX (в каком-то виде уже принята, опять же не разбирался). Ну и ещё есть как минимум один связанный вопрос, про исключения в соединённых (joined) потоках (тоже принят).


• Сборки мусора, скорее всего, в этом стандарте не будет (но уже есть упоминания о C++1x).


• Куча мелких полезных улучшений. Вывод типа значения функции, например.. "Мелких" в том смысле, что они не меняют подход к программированию, но снимают некоторые мешающие ограничения или упрощают синтаксис.

Чем сердце успокоится

03:40 am - ..на полях..

Пишу сейчас здоровый пост про С++ :) Читаю http://www.research.att.com/~bs/hopl-almost-final.pdf Наткнулся на такое:

In October of 1976 I observed that a certain algorithm - parallel reduction - was associated with monoids: collections of elements with an associative operation. That observation led me to believe that it is possible to associate every useful algorithm with a mathematical theory and that such association allows for both widest possible use and meaningful taxonomy. As mathematicians learned to lift theorems into their most general settings, so I wanted to lift algorithms and data structures. One seldom needs to know the exact type of data on which an algorithm works since most algorithms work on many similar types. In order to write an algorithm one needs only to know the properties of operations on data. I call a collection of types with similar properties on which an algorithm makes sense the underlying concept of the algorithm. Also, in order to pick an efficient algorithm one needs to know the complexity of these operations. In other words, complexity is an essential part of the interface to a concept.

( ..more.. )