Здравствуйте, VladD2, Вы писали:

VD>MS Forms, #GTK, WPF. Развитие недостижимое для С++-библиотек.

И какая часть из них — открытая? Точнее, больше интересует бесплатность для разработчика, в т.ч. проприетарного софта (ибо на дядю работаю).

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Disappear, Вы писали:

VD>Это набор фибий. То что ты называешь "ряд ограничений" — это на самом деле назвается более высокий уровень абстракции.
VD>Прирвывания и порты недоступны тебе так как сорверменная ОС не позоляют получить прямой доступ к ним. А через посредников ты можешь получить к ним доступ хоть из ЯваСкрип.
VD>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++. Ведь скорость исполнения не меняется (инструкции процессора то те же), а вот возможностей по алгоритмической отимизации у меня болше (потому что язык выше уровенм, и я заню по более).

К сожалению практика, подтверждает все эти фобии (тормозит так, что шум стоит)

D>>Это только минусы, есть конечно ряд хороших плюсов. Но как не печально, все это не подходит для C++ программистов, которые привыкли "ощущать" работу программы.

VD>Эти минусы ни что иное как фобии. Так что же ты хочешь когда сталкиваешся с такими же фобиями по отношению к Ди? Нормальный процесс.

Безусловно

Здравствуйте, VladD2, Вы писали:

VD>Как раз С++ показал, что множественное наследование (МН) — это не верный путь развития. Единственное разумное его применение — это подключение реализации интерфейсов. Но, к сожалению, МН создает ряд проблем вроде брилиантового наследования, которые очень неприятны.

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

P.S.

Надеюсь вы читали , что по этому поводу пишет Страуструп , ?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, konsoletyper, Вы писали:

D>>>Читал про nemerle немного.

K>>Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.

VD>Это как раз самое прикольное. Ведь он тут уже разбился об стену непонимания со стороны своих коллекг С++-ников которые точно так же "немного почитали о Ди".
VD>Но спроецировать на себя он это просто не в силах. Ведь то что он пока не постиг для него "что-то непонятное и закарючистое", а Ди понятен и логичен. Вот только чего при таком подходе ждать от других то? Для них Ди точно так же непонятен и закорючист.

Я ничего не имею против Nemerle. Просто речь то шла о конкуренте C++ — статически типизируемом языке со статической компиляцией.
Вот и спрашивается — причем тут Nemerle.

Здравствуйте, Disappear, Вы писали:

T>>Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?
D>Вопрос поставлен неправильно. Правильно он звучит так.
D>Зачем нам такое г@вно на D?

Вы только что назвали г@вном библиотеку, которая стабильно использовалась для написания невероятного количества кода. Рабочего, активно использующегося, стабильного. Хочу добавить — мою любимую библиотеку. Минус ставить не буду, но прошу сбавить градус снобизма.

D>Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.

А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?

T>>Или вы предлагаете хором перейти на VCL?
D>Нет, для MFC пожалуй не стоит использовать D.

Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?). В общем резюме такое — для разработки программ чуточку сложнее Hello World, язык D пока что не имеет ни достаточной инфраструктуры, ни средств для переноса на него существующих библиотек с C++.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Disappear, Вы писали:

D>>На D так:
D>>

D>>template factorial(int n)
D>>{
D>>  static if (n == 1)
D>>    const factorial = 1;
D>>  else
D>>    const factorial = n * factorial!(n-1);
D>>}
D>>

VD>Ну, вот и подумай насколько это глупый код!
VD>Ты не сможешь его вызвать из программы. Он доступен только во время компиляции.
VD>Я же свой код могу вызвать как во время компиляции, так и во время исполненения.
VD>Это будет один и тот же код. Более того, он будет скомпилированным! И выполнится очень быстро.
VD>Твой же код будет интерпретироваться компилятором. Конечно factorial-а это не проблема. Но мы же говорим не о нем?

Не понял что подразумевается под словом "использовать"?
Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.

VD>В том-то все и дело. Факториал — это примитившена.

VD>Тут (на этом форуме) как то народ попытася повторить прмитивнеший пример реализованный на Немерле — реалзовать автоматический генератор паттерна "Абстрактная фабрика". И что ты думашь? Ни на С++, ни на D этот пример полностью поторить так и не удалось!
VD>http://rsdn.ru/Forum/Message.aspx?mid=2311589&only=1

Автор: VladD2
Дата: 21.01.07

VD>Что-то удавалось, но на 100% все равно не получилось. Фабрика была или статичная, или ограниченная.
VD>И это в том время как у парня реализовавшего фабрику на макросах Немерле ушло на ее реализацию не более часа времени.

Опять Немерле.

Здравствуйте, Disappear, Вы писали:

D>Долой прошлое, господа!
D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?
D>Разве мы не заслужили

пора ^_^

Здравствуйте, Tilir, Вы писали:

T>Здравствуйте, Disappear, Вы писали:

T>>>Насколько я понимаю, ни то ни другое в D невозможно, правильно? Ну и зачем нам такое Д?
D>>Вопрос поставлен неправильно. Правильно он звучит так.
D>>Зачем нам такое г@вно на D?

T>Вы только что назвали г@вном библиотеку, которая стабильно использовалась для написания невероятного количества кода. Рабочего, активно использующегося, стабильного. Хочу добавить — мою любимую библиотеку. Минус ставить не буду, но прошу сбавить градус снобизма.

D>>Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.

T>А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?

Приходилось, все же с ATL удобнее. С Microsoft всегда удобно работать через инструменты от Microsoft, но на этом все заканчивается.
Да и причем тут COM — что, это панацея? Многие CORBA используют.

T>Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?). В общем резюме такое — для разработки программ чуточку сложнее Hello World, язык D пока что не имеет ни достаточной инфраструктуры, ни средств для переноса на него существующих библиотек с C++.

Да, за счет множественно наследования и неудачной организации процесса обработки сообщений, библиотеки ATL, MFC, WTL не годятся для современных языков. Приходилось мне, естественно, достаточно долго работать с каждой из этих библиотек.

Здравствуйте, Disappear, Вы писали:

D> Просто речь то шла о конкуренте C++ — статически типизируемом языке со статической компиляцией.
D>Вот и спрашивается — причем тут Nemerle.
Ну как бы у него статическая типизация и статическая компиляция имеется. В чем отличие от плюсов — принудительный GC и компиляция в байт-код.

Здравствуйте, Tilir, Вы писали:


T>Насколько я понимаю, для WTL D использовать тоже не стоит (множественное наследование, да?).

На самом деле для реализации ATL/WTL множественное наследование не нужно. Оно там используется для реализации миксинов (CRT pattern).
А в D миксины встроены в язык, так что никаких проблем перетянуть туда твои любимые либы не будет, если кто-то действительно этого захочет.
От себя добавлю, что и выглядеть оно будет покрасивше, без всяких static_cast<T *>(this)

Здравствуйте, Disappear, Вы писали:


D>Не понял что подразумевается под словом "использовать"?
D>Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.

Во время компиляции создаётся типа "мини-рантайм", считается всё что нужно статически посчитать (и что записано на том же самом языке, а не на специальном статическом подъязыке), затем компиляция продолжается дальше.

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Disappear, Вы писали:


D>>Не понял что подразумевается под словом "использовать"?
D>>Так что статические вычисления вообще получается не нужны? Путь в рантайме все считается.

D>Во время компиляции создаётся типа "мини-рантайм", считается всё что нужно статически посчитать (и что записано на том же самом языке, а не на специальном статическом подъязыке), затем компиляция продолжается дальше.

Хороший подход, мне нравится. В D какраз нечто-подобное используется.

Здравствуйте, VladD2, Вы писали:

[вытоптано]

VD>и на Nemerle:
VD>

VD>Factorial(n : uint) : ulong
VD>{
VD>    | 0 | 1 => 1
VD>    | _     => n * Factorial(n - 1)
VD>}
VD>

[тут тоже немного затоптано]

VD>На Nemerle мы получили просто функцю. Мы можем вызвать ее в программе как любую другую. Теперь чтобы вычислить эту функцию во время компляции мы просто помещаем ее вызов в макрос:
VD>

VD>macro CompileTimeFactorial(n : uint)
VD>{
VD>    def res = Util.Factorial(n);
VD>    <[ $(res : ulong) ]>
VD>}
VD>

VD>в котором мы производим вычисление и помещаем результат вычисления код генерируемый макросом.

Вот пример эквивалентного кода из D

ulong factorial(uint index)
{
    if (index == 0 || index == 1)
    {
        return index;
    }
    return index * factorial(index - 1);
}

и макроса который заставляет вычислить ф-цию в время компиляции

template eval(A...) { alias A eval; }

//использование
static result = eval!(factorial(5));

И в отличии от Nemerle не надо для каждой функции писать макрос обертку.


VD>В обличии от D или C++ мы вольны произвести в макросе вычисления любой сложности. Так если у нас уже есть нужная функция которую нужно вычислить во время компиляции, то мы просто вызваем ее в макросе и получаем требуемый результатм.
VD>То есть для нас нет разницы между кодом программы и метакодом. В D же и в С++ мы вынждены писать метакод на птичьех языках которые сильно отличаются от того языка что мы вынуждены применять в реальной программе.
Ну D это уже не относится.

Здравствуйте, Disappear, Вы писали:

D>>Во время компиляции создаётся типа "мини-рантайм", считается всё что нужно статически посчитать (и что записано на том же самом языке, а не на специальном статическом подъязыке), затем компиляция продолжается дальше.

D>Хороший подход, мне нравится. В D какраз нечто-подобное используется.

А для чего тогда отдельный статический подъязык в первой версии факториала?

Здравствуйте, Слоноежик, Вы писали:

С>

С>template eval(A...) { alias A eval; }

С>//использование
С>static result = eval!(factorial(5));

С>

Интересно-интересно. А способен eval отличить недетермирированные функции от детерминированных? Если нет — то это полная ж...
А вдруг:
1) функция factorial зависит от некторых глобальных переменных (которые инициализируются в main и соответственно не проиницализированы в момент выполнения этой функции на этапе компиляции);
2) функция factorial вызывает функции из внешних библиотек, о которых неизвестно детерминированы они или нет (я уж не говорю оразных версиях этих библиотек в момент компиляции и исполнения);
3) тупо зовет rand() или time();

Каким будет результат компиляции в этом случае? Или программист сам себе злой буратино, если написал такое? Если так, то чем это "лучше"
пресловутых граблей С/С++ с = & == ?

P.S. Вопрос относится не только к D, это скорее вопрос ко всем адептам compile-time вычислений. Если средства в современных языках, помогающие разруливать описанные ситуации? Если есть, то как?

Здравствуйте, jedi, Вы писали:

J>P.S. Вопрос относится не только к D, это скорее вопрос ко всем адептам compile-time вычислений. Если средства в современных языках, помогающие разруливать описанные ситуации? Если есть, то как?

В Хаскелле эта проблема решена радикально — там все функции чистые, то есть в твоей терминологии детерминированные. Поэтому в TemplateHaskell таких проблем при квазицитировании не возникает.

Здравствуйте, jedi, Вы писали:

J>Здравствуйте, Слоноежик, Вы писали:
J>Интересно-интересно. А способен eval отличить недетермирированные функции от детерминированных? Если нет — то это полная ж...
Относительно D cмотреть здесь

J>Каким будет результат компиляции в этом случае? Или программист сам себе злой буратино, если написал такое? Если так, то чем это "лучше"
Не скомпилируется.

J>пресловутых граблей С/С++ с = & == ?
В D эти грабли убрали

P.S. Адептом чего либо (в том числе и D) не являюсь.

Здравствуйте, Disappear, Вы писали:

D>Я не считаю, что если язык является static typed и native compiled, то его можно считать морально устаревшим.
D>Есть разные идеологии, и разные подходы. Для разработки ПО мирового масштаба по прежнему используются native языки.

Про статическую типизацию согласен. ИМХО чистую динамику в морг.
Но вот про нативность это ты зря.
Нет у нативности никаких преимуществ. Вобще никаких. Он не нужен нигде. Ну кроме может быть микрокода и чегото в этом духе.
А то что очень много чего до сих пор пишут под натив то это и есть костность мышления.

Здравствуйте, deniok, Вы писали:

D>В Хаскелле эта проблема решена радикально — там все функции чистые, то есть в твоей терминологии детерминированные. Поэтому в TemplateHaskell таких проблем при квазицитировании не возникает.

В Хаскелле нет возможности использовать внешние модули? Нет функций time() & rand().

P.S. Я спрашиваю потому что хочу знать, а не для того чтобы поподкалывать