На самом деле как обычно — XP была на extended support (который у семерки будет до 2020-го), и тот ей продляли несколько раз, так что она была скорее исключением из правила.
По себе судить опасно. Я вот, наоборот, постоянно пользуюсь гуглмапсом в целях нахождения чего-нибудь нового и интересного на предмет хорошо поесть. А также для того, чтобы уточнить время работы, если забыл.
А сколько людей в общем этим пользуются — это надо статистику собирать. Но судя по тому, как ругаются хозяева ресторанов, когда на гугле кто-нибудь пишет ревью с одной звездой, это немаловажно.
>> Отсутствие возможностей переделать синтаксис языка «под себя» как по мне — только плюс, хоть бы потому, что в среде разработки на функцию можно попасть в один клик, а перегруженный оператор поди найди — где и как.
Это скорее претензии к тем IDE, которые не умеют делать Go to Definition на операторах. Например, VS это замечательно умеет для C# — если навести мышой на оператор, подсказка дает его полное название (включая класс, где он определен) и сигнатуру, а Go to Definition прыгает туда.
Вот грустно это, что на дворе 21-й век, космические корабли бороздят просторы хабра, а гугл релизит язык с претензиями на мэйнстрим, и без вменяемой поддержки generic programming. Ну не такая это сложная штука, и много где уже реализована, так что задизайнить базовую поддержку вполне можно было (вариантность, сложные type constraints и прочее можно оставить на потом, это все прекрасно прикручивается поверх).
Не соглашусь. Макросы — это не синтаксический сахар. Точнее, один конкретно взятый макрос — это сахар, но сама концепция в целом — нет, т.к. без макросов эквивалентные вещи описываются только с повторениями. Так можно договориться до того, что функции тоже сахар (а что, их же можно руками поинлайнить).
То, что это будет неудобно на практике с s-выражениями в плюсах — это другой разговор.
>> Далеко не факт, что лисповская система макросов (и common lisp, и scheme) может быть построена над плюсами.
Лисповская система макросов может быть построена над любым языком, поскольку любую грамматику можно записать в виде s-выражений — нужно просто добавить преобразование туда и обратно.
На практике, конечно, неплохо еще иметь какой-нибудь сахар для обычный грамматики, с quotations и всем таким прочим. Но это именно сахар.
>> Если не использовать небезопасную публикацию this изнутри конструктора DummyInstance, то у вас никак не получится добраться до неинициализированного (в части final полей) объекта из другого потока. В этом суть freeze action.
Долго думал, все равно не понял. Поясните на пальцах, каким образом можно получить null через get(), если тот поток, который его дергает, не будет видеть недоинициализированный DummyInstance (причем не важно, почему он недоинициализировался «на самом деле»- с т.з. этого потока с равным успехом можно считать, что конструктор «еще не выполнился», т.к. его единственный эффект — это инициализация поля)?
Если он видит что-то другое, то это либо инициализированный DummyInstance (и тогда все ок), либо SynchrnoizedFunction (и тогда уже возьмется лок, и вторая проверка будет под ним — и он увидит синглтон, если его уже создал другой поток).
>> По-моему, тут вы ошибаетесь, всё же тут есть freeze action после выполнения конструктора, который сериализует инициализацию поля instance и публикацию accessor'а.
Только с точки зрения того потока, который позвал конструктор. Для остальных (если они не используют барьеры) никаких гарантий нет.
>> Проблема в публикации самого экземпляра через поле instance.
Поле instance для данного конкретного экземпляра записывается только один раз (причем под synchronized), так что я не вижу тут проблем. Единственный способ прочитать там что-то не то — это позвать get на неинициализированном экземпляре DummyInstance.
Речь идет о доступе к accessor — он у вас не final и не volatile. Соответственно, один из потоков может получить DummyInstance, у которого instance==null (т.к. конструктор еще тупо не успел выполниться).
Вы все правильно написали. Если volatile нет, то запись в поле ссылки на неинициализированный объект валидна, потому что данный поток её не может увидеть (т.к. следом сразу же зовется конструктор), а другие потоки значения не имеют, т.к. им никаких гарантий и не подразумевается. Если volatile есть, то (в Java 5 и выше), VM должен предусмотреть одновременное чтение с разных потоков — а стало быть, записать ссылку только после полной инициализации объекта.
На корпоративном блогохостинге MS пару лет назад был забавный инцидент — работник-китаец никак не мог запостить анонс продукта в блог своей собственной команды.
Как выяснилось в результате разбора полетов, на хостинге был список нецензурных слов, который — поскольку блоги там на самых разных языках — покрывал все эти языки скопом. Включая всевозможные транслит-варианты.
Имя у китайца было — Hui (очень часто встречающееся среди китайцев, кстати)…
www.lua.org/work/doc/#changes
А как можно вообще умудриться написать кодогенератор, который привязан к WinXP SP2?
Мне реально интересно. Просто кодогенератор — это обычно консольное приложение, которое работает только с входными и выходными файлами…
А сколько людей в общем этим пользуются — это надо статистику собирать. Но судя по тому, как ругаются хозяева ресторанов, когда на гугле кто-нибудь пишет ревью с одной звездой, это немаловажно.
Это скорее претензии к тем IDE, которые не умеют делать Go to Definition на операторах. Например, VS это замечательно умеет для C# — если навести мышой на оператор, подсказка дает его полное название (включая класс, где он определен) и сигнатуру, а Go to Definition прыгает туда.
То, что это будет неудобно на практике с s-выражениями в плюсах — это другой разговор.
One IDE to rule them all :)
Лисповская система макросов может быть построена над любым языком, поскольку любую грамматику можно записать в виде s-выражений — нужно просто добавить преобразование туда и обратно.
На практике, конечно, неплохо еще иметь какой-нибудь сахар для обычный грамматики, с quotations и всем таким прочим. Но это именно сахар.
Долго думал, все равно не понял. Поясните на пальцах, каким образом можно получить null через get(), если тот поток, который его дергает, не будет видеть недоинициализированный DummyInstance (причем не важно, почему он недоинициализировался «на самом деле»- с т.з. этого потока с равным успехом можно считать, что конструктор «еще не выполнился», т.к. его единственный эффект — это инициализация поля)?
Если он видит что-то другое, то это либо инициализированный DummyInstance (и тогда все ок), либо SynchrnoizedFunction (и тогда уже возьмется лок, и вторая проверка будет под ним — и он увидит синглтон, если его уже создал другой поток).
Только с точки зрения того потока, который позвал конструктор. Для остальных (если они не используют барьеры) никаких гарантий нет.
>> Проблема в публикации самого экземпляра через поле instance.
Поле instance для данного конкретного экземпляра записывается только один раз (причем под synchronized), так что я не вижу тут проблем. Единственный способ прочитать там что-то не то — это позвать get на неинициализированном экземпляре DummyInstance.
На корпоративном блогохостинге MS пару лет назад был забавный инцидент — работник-китаец никак не мог запостить анонс продукта в блог своей собственной команды.
Как выяснилось в результате разбора полетов, на хостинге был список нецензурных слов, который — поскольку блоги там на самых разных языках — покрывал все эти языки скопом. Включая всевозможные транслит-варианты.
Имя у китайца было — Hui (очень часто встречающееся среди китайцев, кстати)…