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

G>А разве ветка 1.xx не является стабильной ?

Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).

Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.

G>Одно время доверчивых программеров стращали грядущей веткой 3.хх — якобы Брайт при подстрекательстве одиозного Александреску сделает из Д что-то совсем непредставимое.

Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.

Александреску уже сделал для D2 что-то вроде адаптации C++ного STL (http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html , http://www.digitalmars.com/d/2.0/phobos/std_functional.html). И вообще, после подключения Александреску к разработке D появился очень серьезный крен в сторону поддержки ФП в языке (как раз константность, иммутабельность и pure-функции).

E>>Различие между hard- и soft-real-time заключается в том, что:
E>>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
E>>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.
G>Я бы поправил это таким образом : Софт-реалтайм означает, что заданный процент вычислений должен укладываться в заданный квант времени.

Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.

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

VD>>>И ведь ты как раз предпочел C# для решения тех самых офисных задач?
CC>>Не могу сказать что это было именно мое решение.
VD>Ну, вот видишь? Ты же не стал спорить или увольняться? Значит разделяешь это решение.
Я ж не фанатик

VD>Но при этом все же АПИ получился понятны, в отличие от того же АПИ Винды.
По мне так WinAPI достаточно понятен и прост. Впрочем кому как.

VD>Если ты не заметил, то разжовываю. Windows 7 не новая ОС. Там 90% старого кода.
Новых, чтоб совсем с нуля я в жизни вне тепличных условий вообще не встречал.

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

CC>>У меня по тестам разница между VC 7.1 и ICC 10.1
AVK>Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?
7.1 == VC2003.
В общем это не важно. Просто ICC у меня установлен под 2003-ю. Под ней и вся работа идет.
Я когда то сравнивал с 2005-й — соотношение было такое же.
Ставить монстра 2008 со всем его .NET-oriented говном чтоб писать на С++ — нафиг нафиг. У меня на работе весь зоопарк стоит, только пишу я тут под С#.
Чисто по работе с кодом 2003я из них самая шустрая.

ICC 10.1 уже относительно старенький
ICC 11.0 — свежий, но из за одного бага в оптимизаторе он VC7.1 на моих тестах как раз на криптухе слил Но на остальных тестах выиграл даже у 10.1, хотя и немного.
Жду вот, когда они пофиксят багу, чтоб по нормальному уже протестировать.

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

E>Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).
Да, но сам язык уже не меняется.

E>Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.
Дык ить, кто-то заставляет переходить 1.хх на 2.хх ? Выбор прост : нужно что-то новое — вперед, к ветке 2.хх и дальше. Не надо ничего нового — все устраивает — дык никто ветку 1.хх не закрывал

E>Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.
Читал на форумах, что собираются паттерн-матчинг присобачить. И сделать, наконец, нормальные тупли !
Я лично еще хочу легковесные изолированные процессы и обмен сообщениями ! А ! Чуть не забыл ! Еще встроенную сериализацию ( правда, для статически типизированного языка слабо представляю саму возможность этого ) 8))))

E>Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.
Насчет тяжести последствий : сбор данных о расходе энергии / жидкости / газа — это жесткий или мягкий реалтайм ?

VD>>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.
E>Ну-ну... Популярная и мощная СУБД, наверное?

Define: популярная
Define: мощная



Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху

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

AVK>>Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?
CC>7.1 == VC2003.

Я в курсе. RTM был в конце 2002 года.

CC>В общем это не важно. Просто ICC у меня установлен под 2003-ю. Под ней и вся работа идет.

И чего? От этого он оптимизирует на уровне ICC 7.0?

CC>Ставить монстра 2008 со всем его .NET-oriented говном

В этом плане 2008 ничем от 2003 не отличается, shell и базовые сервисы те же самые с мелкими багфиксами, ".NET-oriented говно" тебя ставить никто не заставляет. Ситуация немножко изменится только в 2010.

CC>ICC 10.1 уже относительно старенький
CC>ICC 11.0 — свежий

Ну понятно, все как я и ожидал — icc возрастом в год старенький, а vc возрастом 6 леи — новье. Больше вопросов нет.

CC>Жду вот, когда они пофиксят багу

Долго ждать будешь.

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

S> Даже в просто высоконагруженных системах с частыми обращениями в натив запиненые буфера вызывают преждевременную фрагментацию памяти; обходится это теми же мерами, что приведены выше.

В последнем СП предложено решение поинтереснее — можно получить нотификацию о пришествии GC. Это позволяет оповестить load balancer чтобы он не использовал в кластере узел, погруженный в GC.
Ну а в 4.0 обещают GC, который работает парналлельно и практически не использует локов.

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

M>Define: популярная
В % каких-нибудь не затруднит выразить популярность?
M>Define: мощная
Тоже интересно бы почитать сранвнение с ораклом, или с MSSQL, хотя бы...

M>

M>Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху
Да ладно. Ты прниводи объективные преимущества, которых люди не видят. Потому, как "прога хорошая, но пользователи слишком тупы, чтобы этим пользоваться" -- это не преимущество, а недостаток... IMHO...

Скажем мне не нужна зажигалка, на использование которой мне не хватает ума. И прога такая тоже не нужна...

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

AVK>Я в курсе. RTM был в конце 2002 года.
AVK>И чего? От этого он оптимизирует на уровне ICC 7.0?
С 2005-й тоже сравнивал, если ты не заметил.

CC>>Ставить монстра 2008 со всем его .NET-oriented говном
AVK>В этом плане 2008 ничем от 2003 не отличается, shell и базовые сервисы те же самые с мелкими багфиксами, ".NET-oriented говно" тебя ставить никто не заставляет. Ситуация немножко изменится только в 2010.
Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

CC>>Жду вот, когда они пофиксят багу
AVK>Долго ждать будешь.
Не думаю. Прошлую (с делением float на 10^х пофиксили довольно быстро)

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

CC>С 2005-й тоже сравнивал, если ты не заметил.

2004 год.

CC>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

А, религия. Ну тогда ладно.

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

FR>Затем что оба в одинаковой ж...

А как в D обстоят дела с интеропом с C++?
Когда я последний раз интересновался, все было, насколько я помню, не очень радужно — только через C.
Это довольно странно, ведь D позиционируется как замена C++.
Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

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

CC>>С 2005-й тоже сравнивал, если ты не заметил.
AVK>2004 год.
2010 еще не вышла.

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?
AVK>А, религия. Ну тогда ладно.
Т.е. нормальным считается понаставить кучу совершенно ненужного говна?

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

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?
AVK>А, религия. Ну тогда ладно.
Вдогон. Ты кстати видел что именно входит в список обязательно устанавливаемого?

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

E>>Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.
G>Насчет тяжести последствий : сбор данных о расходе энергии / жидкости / газа — это жесткий или мягкий реалтайм ?

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

По поводу сбора данных -- it depends. Насколько я помню, бывают счетчики с ограниченным диапазоном значений -- не успел вовремя вычитать, он уходит в ноль. Получается, что работа с таким оборудованием -- уже hard RT. Если сбор данных будет сопровождаться каким-то управлением (типа открывания/закрывания задвижек), то опять может быть hard RT (слишком позднее срабатывание задвижки черевато аварией). Если система строится на основе ОС, не предоставляющей hard RT гарантии, то все равно лучше soft RT может ничего не получится. И т.д.

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

E>>Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).
G>Да, но сам язык уже не меняется.

E>>Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.
G>Дык ить, кто-то заставляет переходить 1.хх на 2.хх ? Выбор прост : нужно что-то новое — вперед, к ветке 2.хх и дальше. Не надо ничего нового — все устраивает — дык никто ветку 1.хх не закрывал

Ситуация несколько сложнее. Язык версии 1.* вроде как есть и поддерживается пока только одним компилятором DMD на платформах x86 Windows и Linux. Под него существуют некоторые библиотеки. И все. Совершенствованием 1.* больше никто не занимается. Новые библиотеки создаются уже для 2.*. Даже у Tango появилась ветка для D 2.0, хотя сама Tango так до 1.0 пока и не дошла.

Т.е. если сейчас заложиться на диалект 1.* для долгосрочных проектов, то это означает, что в скором времени эти проекты окажутся привязанными к умершей ветке языка с ограниченным количеством инструментов и библиотек. Поскольку я не слышал о том, что кто-то хочет дальше заниматься D 1.0.

E>>Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.
G>Читал на форумах, что собираются паттерн-матчинг присобачить.

Я читаю только news.digitalmars.announce, про паттерн-матчинг не слышал.

G> И сделать, наконец, нормальные тупли !

Тупли там на основе шаблонов. Имхо, более простые в освоении и использовании, чем в C++0x.

G>Я лично еще хочу легковесные изолированные процессы и обмен сообщениями ! А ! Чуть не забыл ! Еще встроенную сериализацию

У вас же есть Erlang, зачем вам что-то еще?

G>(правда, для статически типизированного языка слабо представляю саму возможность этого ) 8))))

К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз.

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

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?
AVK>А, религия. Ну тогда ладно.

Вот нафига мне при установке ТОЛЬКО C++ без MSDN.

Document Explorer
Web Authoring
SQL Server Compact + SQL Server Design tools
SDK for .Net framework tools
SDK reference assemblies
SQL publishing Wizard

А оно ставится всегда и без спросу.

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

K>А как в D обстоят дела с интеропом с C++?
K>Когда я последний раз интересновался, все было, насколько я помню, не очень радужно — только через C.

Появилась ограниченная подержка C++ http://www.digitalmars.com/d/2.0/cpp_interface.html
Всегда была подержка COM http://www.digitalmars.com/d/2.0/COM.html

K>Это довольно странно, ведь D позиционируется как замена C++.

Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

Учитывая прозрачную связь с си http://www.digitalmars.com/d/2.0/interfaceToC.html и вышенаписанное у D в этом отношении все вполне нормально.
Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.

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

VD>>У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?
VD>>Если, нет, то чем занимаешся?

E>Другими задачами ИИ...

А, можно подробнее?

E>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего )

Ага. 640 Кбайт хватит всем (с) Бил Гейтс

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

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

Кстати Java библиотеки легко транслируются на D http://www.dsource.org/projects/dwt

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

VD>>Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?

E>Я разрабатываю настолько сложные алгоритмы, что такие мелкие подробности, на чём же они выражены, являются несущественными подробностями.
E>Недавно мы с двумя подчинёнными писали статью, описывающую один из наших алгоритмов. Написание статьи заняло почти две недели, она содержит доказательства кучи теорем, описание многих экспериментов и т. д. и т. п...

Я правильно понял, что ответ на мой вопрос — "нет"?

E>И в наших задачах, например, С++ очень удобен, так как представляет довольно адекватную абстракцию компьютера, с одной стороны, и при этом позволяет писать довольно абстрактный код, при этом имеющий строго определённую и понятную процедурную семантику...

Как ты можешь судить об удобстве чего-то не попробовав альтернативы?

E>Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится

Алгоритмы бывают весьма сложными. Например, алгоритм вывода типов в современном ЯП или алгоритм сжатия данных. Реализовывать их лопатой вроде С++, то реализация будет в десятки (а то и в сотни) раз сложнее спецификации. За тем и нужны более высокоуровневые и удобные языки, чтобы уменьшить разницу между спецификацией и реализацией. Кроме того обычно алгоритмы выражаются не четко и при их реализация почти всегда становится процессом творческим, что опять таки значительно проще осуществить используя удобный, мощный, высокоуровневый язык, нежели ассемблер с классами. Так что твои слова выглядят как хвастовства и бравада. Но понять ты это не сможешь если сам не освоишь хотя бы один более высокоуровневый язык.