В понедельник, 18-го июня, в развитии языка D произошло очередное эпохальное событие: язык разделился на две ветви, D 1.0 и D 2.0.
Напомню хронологию событий. 2-го января 2007 года была выпущена "стабильная" версия 1.000. Слово "стабильная" взято в кавычки не зря. По некоторым слухам выпуск версии 1.000 был всего лишь попыткой обозначить тот факт, что после семи лет разработки язык D достиг некоторого значимого уровня. Вроде как Брайта достали пользователи языка вопросом "Ну когда же?", на что эти Брайт среагировал "Хотели? Получите!".
После этого в язык было добавлено еще несколько важных дополнений, например, версия 1.005: добавлены строковые mixin-ы (т.н. mixin statements, mixin expressions и mixin declarations) и импорт содержимого любых файлов (т.н. import expression); версия 1.006: поддержка исполнения некоторых фрагментов кода во время компиляции (т.н. compile time execution); версия 1.014: поддержка литералов для ассоциативных массивов. Плюс большое количество исправленных багов разной степени тяжести.
В это же самое время для языка D оказалось сразу две библиотеки, претендующих на звание стандартных: C-подобная библиотека Phobos, входящая в состав компилятора DMD (можно сказать де-юре стандарт) и альтернативная ей, полностью объектно-ориентированная Tango (имеющая все шансы стать де-факто стандартом). Причем Tango пока существует в виде второго релиз-кандидата, но финальной версии еще нет.
А второй D-шный компилятор, GDC, пока остановился на уровне DMD v.1.007 (речь о GDC v 0.23).
И вот в таких условиях, когда казалось бы, что жизнь начала налаживаться, что D достигнет достаточной степени стабильности, что GDC перестанет отставать от DMD, что Tango полностью заменит Phobos, что для D будут написаны необходимые руководства и, может быть, книги, начинают происходить, как мне казалось, странные вещи.
Сначала Брайт начал намекать, что у него есть идеи по добавлению в язык некоторой макросистемы. Какой -- никто из широкой публики не знает. Но в версию 1.011 даже было введено новое служебное слово macro.
Затем, с подачи Андрея Алексендреску, в D начали добавлять поддержку константности, даже большую, чем в C++.
В отличии от макросов, константность широко обсуждалась в news-группах digitalmars.D и digitalmars.D.announce. Из этих обсуждений стало понятно, что в рамки ветки 1.0 константность ну никак не ляжет. Поэтому и произошло выделение ветви 2.0. Первая альфа-версия DMD 2.000 с поддержкой константности и была опубликована 18-го июня. Версия 1.0 будет существовать как "стабильная" версия, последующие релизы в которой будут всего лишь баг-фиксами.
Что же представляет из себя константность в D 2.0? Подробнее об этом можно прочитать на сайте языка D, вот здесь. Если же говорить в двух словах, то в язык добавлены новые модификаторы:
* final, который указывает, что имя переменной не может быть связано с другим значением. Хотя, если переменная является указателем или ссылкой, то объект, на который указатель указывает, изменяться может. Например:
final int x = 0;
x = 3; // Ошибка! Имя x не может быть связано с другим значением.int y = 0;
final int * py = &y;
*py = 0; // Ok, изменяется не py, а значение, на которое py указывает.
py = null; // Ошибка, py не может принять новое значение.
* invariant, который указывает, что значение изменяться не может. Вообще. Поскольку такое значение не может изменяться, то оно либо может размещаться в ROM, либо вообще подставляться компилятором в место использования. Поэтому нельзя взять адрес инварианта:
invariant int x = 0;
x = 3; // Ошибка! Нельзя изменить инвариант.
invariant int * px = &x; // Ошибка! Нельзя взять адрес инварианта.
* const, который является аналогом const в C++. По сути, это объявление того, что через константную переменную нельзя изменить значение. Но значение может измениться через другие ссылки на него:
const int x = 0;
x = 3; // Ошибка! Нельзя изменить x.int y = 0;
const(int *) py = &y;
*py = 3; // Ошибка!
y = 3;
assert( *py == 3 ); // *py изменилось через другую ссылку на значение.
Значение инварианта должно быть вычислимо во время компиляции. Неявно указатель к инварианту не приводится. Т.е. следующая конструкция не должна пройти:
int y = 0;
invariant(int *) p = &y; // Ошибка! Значение *p может быть изменено через y,
// а это нарушение инварианта.
Так же строковые литералы теперь имеют тип invariant(char)[], вместо char[]. Что делает нелегальной запись:
auto s = "Hello";
s ~= ", World"; // Ошибка, поскольку s нельзя изменять.
При сильном желании инвариантность и константность можно снять при помощи кастов. Сделано это для того, чтобы позволить программистам работать с левыми библиотеками, исправить которые мы не в состоянии. Например;
// An interface for some third-party library
// (which is probably written in some exotic language).extern(C) void initSomeSubsystem(char * initializationString);
int main()
{
invariant char * initString = "...";
// Cast away invariantness of initString so we can pass it to the C
// function; be it on your head if the function tries to change it!
initSomeSubsystem( cast(char*)initString );
}
Главное отличие кастов в D от кастов в C++ в том, что в C++ разрешено использование результирующего значения после снятия константности:
const int * pc = ...;
int * p = const_cast< int * >( pc );
*p = 0; // Well-defined.
а в D подобная конструкция является undefined behaviour. Т.е. желающим оставлен способ отстрелить себе обе ноги и кое-что еще, если есть очень уж сильное желание.
Такие вот пироги. Существует вероятность, что константность еще притерпит некоторые изменения. И, возможно, вызовут еще некоторые изменения в языке. Т.е. в D начался очередной виток нестабильности в стремлении к совершенству.
С одной стороны, это хорошо. После C++ было тяжеловато привыкать к C++подобному языку без const-ов. Но с другой -- какой смысл сейчас что-то делать на D 1.0, если это уже тупиковая ветка и переход на D 2.0 все равно неизбежен? В digitalmars.D несколько человек, в том числе и я, уже высказались в том духе, что развитие -- это хорошо, но развиваться можно до бесконечности. Пора бы взять тайм-аут на пару-тройку лет и пописать на D, инструменты для него сделать, документацию, реальных проектов в разных проблемных областях. Но нас пока не слушают И караван идет...
Так что есть шансы, что C++0x появится раньше, чем D 2.0. Будем посмотреть
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>В понедельник, 18-го июня, в развитии языка D произошло очередное эпохальное событие: язык разделился на две ветви, D 1.0 и D 2.0...
Трудно с такими новостями воспринимать его как стабильный ЯП для коммерческой разработки.
Здравствуйте, _nn_, Вы писали:
E>>Так что есть шансы, что C++0x появится раньше, чем D 2.0. Будем посмотреть
__>Напрашивается сделать D++ и решить все проблемы D
Имхо, у D сейчас одна проблема, которая описывается народной мудростью "Лучшее -- враг хорошего". D community настолько увлеклось созданием лучшего языка, что забывает, что язык -- это всего лишь инструмент. Отсутствие которого в нужном месте в нужное время делает его просто-напросто невостребованным.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, _nn_, Вы писали:
E>>>Так что есть шансы, что C++0x появится раньше, чем D 2.0. Будем посмотреть
__>>Напрашивается сделать D++ и решить все проблемы D
E>Имхо, у D сейчас одна проблема, которая описывается народной мудростью "Лучшее -- враг хорошего". D community настолько увлеклось созданием лучшего языка, что забывает, что язык -- это всего лишь инструмент. Отсутствие которого в нужном месте в нужное время делает его просто-напросто невостребованным.
Что-то в этом есть.
На мой взляд надо выкинуть DMD и Phobos и сосредоточить разработку под GPL лицензией.
А серьезно, таким темпом разработки практического применение пока я не вижу.
С++ хоть и не идеал, но к сожалению D долек от идеала тоже. Тем более когда добавляют UB в язык осознанно
Поэтому единственный вариант это заняться разработкой идеального языка на благо всего RSDN-а
Здравствуйте, _nn_, Вы писали:
__>На мой взляд надо выкинуть DMD и Phobos и сосредоточить разработку под GPL лицензией.
Что-то в этом есть
Но это нереально
Сам факт того, что есть и Phobos и Tango, и не видно, чтобы Брайт отважился на выбрасывание Phobos и включение в свой дистрибутив Tango уже печален.
__>А серьезно, таким темпом разработки практического применение пока я не вижу.
Ну дык в том-то и дело.
Я уж начал небольшие программки на D для работы делать, на DMD 1.014 и Tango. Уже начали реализовываться планы были по портированию на D некоторых C++ библиотек. Думал, ну вот, пока я тут повожусь с портированием и Tango 1.0 выйдет и D от багов очистят... Редиски, короче.
И есть у меня подозрение, что D2.0 введением константности не ограничится. Слишком уж удобный момент, чтобы в язык еще что-нибудь втянуть. Макросы те же самые. А это означает, что стабильная версия 2.0 появится еще очень не скоро. А там горячие головы придумают что бы такого несовместимого в 3.0 добавить
Пока развитие D шло именно таким образом ((
__>С++ хоть и не идеал, но к сожалению D долек от идеала тоже. Тем более когда добавляют UB в язык осознанно
Ну пока на D, в отличии от C++, программировать приятней за счет:
* наличия вывода типов и ключевого слова auto (а ведь, оказывается, Страуструп мог ввести это в C++ еще в 1982(!), но тогда конструкция auto i = 0 была легальной конструкцией языка C, назначавшая переменной i тип int );
* наличия делегатов и lazy параметров;
* очень быстрой компиляции.
Вывод типов в C++0x уже добавили, есть еще надежда, что кто-нибудь из коммитета удобные лямбды в язык добавит. И получится тогда удобный C++, да еще совместимый с унаследованным C++ кодом. Неудел тогда вечно развивающийся D останется. Одной быстрой компиляцией и консервативным сборщиком мусора сыт не будешь.
__>Поэтому единственный вариант это заняться разработкой идеального языка на благо всего RSDN-а
Не-а, стар я уже для этого. Ericsson-ы вон свой отличный язык Erlang начали двадцать лет назад делать. И только сейчас он приобретает достаточную известность.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, _nn_, Вы писали:
__>>На мой взляд надо выкинуть DMD и Phobos и сосредоточить разработку под GPL лицензией.
E>Что-то в этом есть E>Но это нереально E>Сам факт того, что есть и Phobos и Tango, и не видно, чтобы Брайт отважился на выбрасывание Phobos и включение в свой дистрибутив Tango уже печален.
__>>А серьезно, таким темпом разработки практического применение пока я не вижу.
E>Ну дык в том-то и дело. E>Я уж начал небольшие программки на D для работы делать, на DMD 1.014 и Tango. Уже начали реализовываться планы были по портированию на D некоторых C++ библиотек. Думал, ну вот, пока я тут повожусь с портированием и Tango 1.0 выйдет и D от багов очистят... Редиски, короче.
Я не понимаю чем Брайт мотивирует.
Если он создает язык для практического применения пора подумать о практике.
E>И есть у меня подозрение, что D2.0 введением константности не ограничится. Слишком уж удобный момент, чтобы в язык еще что-нибудь втянуть. Макросы те же самые. А это означает, что стабильная версия 2.0 появится еще очень не скоро. А там горячие головы придумают что бы такого несовместимого в 3.0 добавить E>Пока развитие D шло именно таким образом ((
О макросах там давно говорили.
Если их прикрутят в язык, то будет каша там.
__>>С++ хоть и не идеал, но к сожалению D долек от идеала тоже. Тем более когда добавляют UB в язык осознанно
E>Ну пока на D, в отличии от C++, программировать приятней за счет: E>* наличия вывода типов и ключевого слова auto (а ведь, оказывается, Страуструп мог ввести это в C++ еще в 1982(!), но тогда конструкция auto i = 0 была легальной конструкцией языка C, назначавшая переменной i тип int ); E>* наличия делегатов и lazy параметров; E>* очень быстрой компиляции.
E>Вывод типов в C++0x уже добавили, есть еще надежда, что кто-нибудь из коммитета удобные лямбды в язык добавит. И получится тогда удобный C++, да еще совместимый с унаследованным C++ кодом. Неудел тогда вечно развивающийся D останется. Одной быстрой компиляцией и консервативным сборщиком мусора сыт не будешь.
Вот-вот, к сожалению это не решаюшие факторы в выборе D вместо С++
__>>Поэтому единственный вариант это заняться разработкой идеального языка на благо всего RSDN-а
E>Не-а, стар я уже для этого. Ericsson-ы вон свой отличный язык Erlang начали двадцать лет назад делать. И только сейчас он приобретает достаточную известность.
Здравствуйте, _nn_, Вы писали:
__>>>А серьезно, таким темпом разработки практического применение пока я не вижу.
E>>Ну дык в том-то и дело. E>>Я уж начал небольшие программки на D для работы делать, на DMD 1.014 и Tango. Уже начали реализовываться планы были по портированию на D некоторых C++ библиотек. Думал, ну вот, пока я тут повожусь с портированием и Tango 1.0 выйдет и D от багов очистят... Редиски, короче.
__>Я не понимаю чем Брайт мотивирует. __>Если он создает язык для практического применения пора подумать о практике.
Я несколько раз ему это говорил и прямым текстом спрашивал, планируется ли вообще какая-нибудь пауза в развитии языка. Но мне он не отвечал. Зато он придерживается такой линии: есть типа стабильный D1.0 и для создания production кода и использования в реальных проектах нужно брать именно D1.0.
Его понять можно. Так же самая константность, точнее ее отсутствие -- это такой косяк, который хорошо бы исправить. И раз уж он решил добавить в язык константность, так пусть делает это раньше. Тем более, что многие из D community очень восторженно приветствуют такой ход событий и так же указывают: "мол чего народ баламутишь, есть D1.0, пользуйся им".
Радует, что я там не один такой, кто говорит, что пора бы уже заниматься продвижением D, а не развитием. Так что есть шансы, что к нам будут больше прислушиваться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, _nn_, Вы писали:
__>>>>А серьезно, таким темпом разработки практического применение пока я не вижу.
E>>>Ну дык в том-то и дело. E>>>Я уж начал небольшие программки на D для работы делать, на DMD 1.014 и Tango. Уже начали реализовываться планы были по портированию на D некоторых C++ библиотек. Думал, ну вот, пока я тут повожусь с портированием и Tango 1.0 выйдет и D от багов очистят... Редиски, короче.
__>>Я не понимаю чем Брайт мотивирует. __>>Если он создает язык для практического применения пора подумать о практике.
E>Я несколько раз ему это говорил и прямым текстом спрашивал, планируется ли вообще какая-нибудь пауза в развитии языка. Но мне он не отвечал. Зато он придерживается такой линии: есть типа стабильный D1.0 и для создания production кода и использования в реальных проектах нужно брать именно D1.0.
E>Его понять можно. Так же самая константность, точнее ее отсутствие -- это такой косяк, который хорошо бы исправить. И раз уж он решил добавить в язык константность, так пусть делает это раньше. Тем более, что многие из D community очень восторженно приветствуют такой ход событий и так же указывают: "мол чего народ баламутишь, есть D1.0, пользуйся им".
Ну константность, которая добавляенна увы не панацея.
Там UB на ровном месте с кастом из инварианта.
За что боролись на то и
На мой взгляд правильно если делать маршаллинг то делать его или нормально в языки или в виде библиотеке, но не с UB.
E>Радует, что я там не один такой, кто говорит, что пора бы уже заниматься продвижением D, а не развитием. Так что есть шансы, что к нам будут больше прислушиваться.
К сожалению не думаю, что Брайт серьезно к этому отнесется..
Здравствуйте, _nn_, Вы писали:
E>>Его понять можно. Так же самая константность, точнее ее отсутствие -- это такой косяк, который хорошо бы исправить. И раз уж он решил добавить в язык константность, так пусть делает это раньше. Тем более, что многие из D community очень восторженно приветствуют такой ход событий и так же указывают: "мол чего народ баламутишь, есть D1.0, пользуйся им".
__>Ну константность, которая добавляенна увы не панацея. __>Там UB на ровном месте с кастом из инварианта. __>За что боролись на то и
Здесь как раз все понятно. Ведь D -- это в первую очередь язык для околосистемного программирования, когда безопасность временами можно принести в жертву производительности. Если уж кому-то сильно приспичило снять константность -- пусть он будет сам себе злобным буратино. Без обеих ног.
Тем более, что use-case для снятия константности вполне понятный и прозрачный: когда приходится передавать указатели на D-шные объекты в строронюю библиотеку, поправить которую у тебя нет возможности. Ну, например, есть какой-нибудь генератор кода (вроде yacc-а, IDL-транслятора или ASN.1 компилятора), который генерирует декларации функций без константности. Выход тут либо в применении каких-то средств модификации сгенерированного этим инструментом кода, либо снятием константности в месте вызова.
При обсуждении этого use-case появилась идея сделать специальный вариант cast-а для таких случаев:
int * p = cast(break const)const_ptr;
чтобы такие касты были хорошо заменты в исходном коде.
__>На мой взгляд правильно если делать маршаллинг то делать его или нормально в языки или в виде библиотеке, но не с UB.
Я так понимаю, UB возникает только при изменении данных после снятия константности. Что, в общем-то и понятно. Если изменения данных не происходит, то нет и UB.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, _nn_, Вы писали:
E>>>Его понять можно. Так же самая константность, точнее ее отсутствие -- это такой косяк, который хорошо бы исправить. И раз уж он решил добавить в язык константность, так пусть делает это раньше. Тем более, что многие из D community очень восторженно приветствуют такой ход событий и так же указывают: "мол чего народ баламутишь, есть D1.0, пользуйся им".
__>>Ну константность, которая добавляенна увы не панацея. __>>Там UB на ровном месте с кастом из инварианта. __>>За что боролись на то и
E>Здесь как раз все понятно. Ведь D -- это в первую очередь язык для околосистемного программирования, когда безопасность временами можно принести в жертву производительности. Если уж кому-то сильно приспичило снять константность -- пусть он будет сам себе злобным буратино. Без обеих ног.
E>Тем более, что use-case для снятия константности вполне понятный и прозрачный: когда приходится передавать указатели на D-шные объекты в строронюю библиотеку, поправить которую у тебя нет возможности. Ну, например, есть какой-нибудь генератор кода (вроде yacc-а, IDL-транслятора или ASN.1 компилятора), который генерирует декларации функций без константности. Выход тут либо в применении каких-то средств модификации сгенерированного этим инструментом кода, либо снятием константности в месте вызова.
E>При обсуждении этого use-case появилась идея сделать специальный вариант cast-а для таких случаев: E>
E>int * p = cast(break const)const_ptr;
E>
E>чтобы такие касты были хорошо заменты в исходном коде.
+1
__>>На мой взгляд правильно если делать маршаллинг то делать его или нормально в языки или в виде библиотеке, но не с UB.
E>Я так понимаю, UB возникает только при изменении данных после снятия константности. Что, в общем-то и понятно. Если изменения данных не происходит, то нет и UB.
Угу.
Но в таком случае следует еще и предоставить вариант без UB в ущерб производительности.
Скажем:
f(cast(invariant char*)"abc");
f(cast(no ub invariant char*)"abc"); // тут будет копия и UB не будет никогда
_nn_ wrote:
> f(cast(no ub invariant char*)"abc"); // тут будет копия и UB не будет никогда
А что это разве возможно, чтобы любой объект умел копироваться? А если только частный случай для строковых литералов, то
нафиг не надо.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, _nn_, Вы писали:
E>>Я так понимаю, UB возникает только при изменении данных после снятия константности. Что, в общем-то и понятно. Если изменения данных не происходит, то нет и UB.
__>Угу. __>Но в таком случае следует еще и предоставить вариант без UB в ущерб производительности. __>Скажем: __>
__>f(cast(invariant char*)"abc");
__>f(cast(no ub invariant char*)"abc"); // тут будет копия и UB не будет никогда
__>
Все зависит от прототипа f(). Скажем, если он такой:
void f( invariant(char)[] str );
то следующий код будет корректным, т.к. строковые литералы имеют тип invariant(char)[]:
f( "abc" );
а вот код ниже будет некорректным:
char[] something = ...;
f( something ); // Error! char[] к инварианту не приводится!
Его нужно сменить на:
f( something.idup ); // Передается копия.
Если f() получает константный указать на char:
void f( const(char)[] str );
то нет проблем ни в одном из случаев:
f( "abc" ); // Инвариант неявно приводится к const.
f( something ); // char[] неявно приводится к const(char)[].
Если же нам нужно сделать копию, которую требуется передать в f(char[]) чтобы не было UB, то можно сделать тривиальный dup вместо кастинга:
f( "abc".dup );
Так что UB, имхо, можно легко избежать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ., Вы писали:
.>_nn_ wrote:
>> f(cast(no ub invariant char*)"abc"); // тут будет копия и UB не будет никогда .>А что это разве возможно, чтобы любой объект умел копироваться? А если только частный случай для строковых литералов, то .>нафиг не надо.
AFAIK, свойство dup есть только у векторов. При этом для вектора ссылок происходит лишь поверхностное копирование -- новый вектор со старыми ссылками внутри.
Если же речь идет о произвольном объекте, то вопрос усложняется очень серьезно.
Однако, снятие инвариантности/константности для произвольного объекта, имхо, это очень редкий случай. Ведь D-шная объектная модель ни с кем не интероперабельна, поэтому вероятностью передачи D-шного объекта в левую сторонюю библиотеку можно пренебречь. Следовательно, со снятием инвариантности/константности с произвольного D-шного объекта на практике можно и не встретиться.
А вот char[] или int[] -- совсем другое дело, ведь такими объектами можно с библиотеками на C/C++/Java/... обмениваться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ., Вы писали:
.>_nn_ wrote:
>> f(cast(no ub invariant char*)"abc"); // тут будет копия и UB не будет никогда .>А что это разве возможно, чтобы любой объект умел копироваться? А если только частный случай для строковых литералов, то .>нафиг не надо.
Здесь было конкретно про строки.
В любом случае "объекты" которые есть в функциях С они копируются, так что проблем с этим нет
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, _nn_, Вы писали:
E>>>Я так понимаю, UB возникает только при изменении данных после снятия константности. Что, в общем-то и понятно. Если изменения данных не происходит, то нет и UB.
__>>Угу. __>>Но в таком случае следует еще и предоставить вариант без UB в ущерб производительности. __>>Скажем: __>>
__>>f(cast(invariant char*)"abc");
__>>f(cast(no ub invariant char*)"abc"); // тут будет копия и UB не будет никогда
__>>
E>Все зависит от прототипа f(). Скажем, если он такой: E>
E>void f( invariant(char)[] str );
E>
E>то следующий код будет корректным, т.к. строковые литералы имеют тип invariant(char)[]: E>
E>f( "abc" );
E>
E>а вот код ниже будет некорректным: E>
E>char[] something = ...;
E>f( something ); // Error! char[] к инварианту не приводится!
E>
E>Его нужно сменить на: E>
E>f( something.idup ); // Передается копия.
E>
Я понимаю, что приведедния string -> invariant string не существует.
Вопрос почему?
И как тогда idup работает ?
E>Если f() получает константный указать на char: E>
E>void f( const(char)[] str );
E>
E>то нет проблем ни в одном из случаев: E>
E>f( "abc" ); // Инвариант неявно приводится к const.
E>f( something ); // char[] неявно приводится к const(char)[].
E>
E>Если же нам нужно сделать копию, которую требуется передать в f(char[]) чтобы не было UB, то можно сделать тривиальный dup вместо кастинга: E>
И караван идет...
