Здравствуйте, FR, Вы писали:
EP>>Нет. D-style range'и не добавляют ни параллельности, ни иммутабельности. FR>Потенциально добавляют,
Что именно они добавляют, чего нет в решении типа обёрток над парой итераторов?
FR>плюс возможность работать в compile time.
Я думаю это ортогонально нашей дискуссии. И по-идее итераторы точно также можно использовать в compile time.
FR>>>Что имеешь в виду под "мощнее" я не понял. EP>>Выше был пример find — даже реализация базовых возможностей не была продемонстрирована на D, не говоря уж об [prev(find(first, last)), last) FR>Это не мощнее, это значит только то что примитивы реализовать легче. Но это проблемы разработчика библиотеки FR>(Александреску кстати очень любит проблемы ),
Если программист не делает что-то совсем примитивное типа переливания из одного места в другое (для чего, кстати, часто подходят вообще динамические языки) — то ему рано или поздно понадобятся свои алгоритмы.
FR>для прикладного программиста это не имеет никакого значения FR>для него важнее легкость использования и возможность комбинирования, а в этом интервалы гораздо "мощнее".
Эта лёгкость комбинирования доступна и решению с итераторами, а не только в range-only.
Мне же интересно сравнение iterator+range vs range-only.
Здравствуйте, VladD2, Вы писали:
EP>>А где тут кто-то говорил про невероятную крутизну C++? VD>А разве не ты бросился отстаивать его превосходство над тем же D?
1.
EP>У каждого языка есть свои цели, свои design guidelines. Язык это не просто набор фич.
EP>Как известно, у C++ основным приоритетом является производительность.
EP>А в D спокойно могут пожертвовать производительностью ради других целей (об этом говорил A.A.).
2.
EP>Взять например те же ranges — они проигрывают итераторам по производительности by-design
И ровно в этих рамках я и пытаюсь остаться. Обсуждать метапрограммирование не особо интересно — так как все согласны что оно мощнее у D.
Где ты тут видишь "бросился отстаивать его превосходство над тем же D".
EP>>Я вот не пойму — откуда у программистов не пишущих на C++ к нему такая злость/зависть/etc? VD>Лично у меня злобы нет.
Да ладно:
1. Ты говоришь что я "бросился отстаивать его превосходство над тем же D".
2. Считаешь что программисты которые используют C++ — знают только один язык.
3. Говоришь что кто-то тут выдвигает тезис "С++ лучше"
4. Игнорируешь то, что тут все согласны что в D метапрограммирование лучше, и пытаешься поджечь холивар на эту тему.
и т.п.
Если это не от злобы, то от чего?
VD>Тут скорее есть некоторая злость на таких как вы, защищающих черт знает что не пробовав альтернатив. VD>У новых языков (D, Scala, F#, Nemerle, Kotlin, Haskel, ...) есть только одна проблема — размеры комьюнити. Куча народа, вроде вас, ходит и что-то там себе доказывает вместо того чтобы взять и начать помогать развивать перспективные языки.
Страуструп уже более 30 лет развивает язык, несмотря на его "неидеальность" — улучшает и улучшает.
Мог бы он бросить всё и создать "перспективный, динамично развивающийся и т.п."? — да конечно мог бы. Он мог бы делать также как и Вирт — сколько там у него языков было? — вот только где сейчас все эти перспективные и развивающийся?
VD>Ну, глупо в 21-м веке использовать языки в которых:
Глупо — это ждать того, что программисты внезапно бросят всё и присоединятся к комьюнити малоиспользуемого языка.
Глупо ждать того, что индустрия резко станет оказывать гуманитарную помощь "перспективным языкам".
VD>1. Не поддерживается модульность, а вместо нее есть препроцессор с инклюдами.
Это действительно проблема. Ведётся работа.
VD>2. 30 лет не могут создать полноценный интелисенс.
Ничего критичного.
VD>3. Скорость компиляции больших проектов чудовищно низкая.
Проблема есть, но не в "чудовищных" масштабах.
VD>4. Система метапрограммирования основана на побочных эффектах от других средств, а не разработа специально.
А кто сказал что нужна какая-то специально разработанная мета-система? Метапрограммирование — это практически хак, который приходит на помощь там где недостаточно мощи самого языка.
В большинстве кода нет ничего мета*, только потому, что и без него всё хорошо
VD>5. Нет бинарного ABI.
Действительно есть такая проблема, но совсем острая.
Если ограничится одной платформой, как делают некоторые языки, например .NET-ом, а-ля C++CLI/CX — то ABI получается что есть
VD>6. Нет даже соглашений по формированию имен функций в библиотеках.
Мелочь, причём спорная.
VD>7. Требуются предварительные декларации.
Мелочь.
VD>8. Нет даже опциональной системы автоматического управления памятью.
В ISO C++11 есть интерфейс для GC — но он вообще не популярен, что скорее говорит об востребованности
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вообще-то при работе из STL используются не только контейнеры, но и алгоритмы, причём алгоритмы намного разнообразней. EP>И в том же std.algorithm в D — там всё на range'ах, так что от них никуда не уйти.
Не, алгоритмы в D едят и просто массивы. И выдают их же при этом. Кстати, надо будет посмотреть как там в этом смысле с другими коллекциями, которые не встроенные — вдруг их тоже едят напрямую, без Range.
EP>Это не интересно — практически идентично переносится на C++: EP>
EP>BinarySearch(input[0..i], value);
EP>// versus
EP>BinarySearch(input | sliced(0,i), value);
EP>
Не, это не то. Ты же при этом заменил входные параметры функции с массивов на range. Вот если бы у range можно было вызывать функции массива (хотя в данном конкретном примере это и не пригодилось)...
EP>А вот попробуй сделать аналог std::partition_point
А что там такого? Ну будет например функция с прототипом вида Tuple!(T[], T[]) partition_point(T[], ...)
EP>Так в том то и дело, что они не то что стандартную — они вообще никакую деку не нашли.
Кстати, мне кто-то писал фразу что типа C# — это типа самый продвинутый язык из мейнстримовых. Я в ответ спросил как у нас с метапрограммированием в самом продвинутом языке. Мне в ответ гордо назвали T4 и Reflection.Emit, на что я предложил написать например Boost.Spirit на этом... А сейчас я представил себе как этот народ отреагировал бы на примеры, которые способен решать D.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если кто-то постоянно тем и занимается что итетрирует структуры данных, и ему не хватает текущих возможностей — то пусть отсылает proposal в reflection study group #7, его обязательно рассмотрят.
Вот как раз интроспекции времени компиляции (а не того ненужного недоразумения времени выполнения, как в жабке и шарпе) крайне не хватает в C++. Например для сереализации. Кстати, а RTTI я бы вообще из C++ выкинул — от него вред только один, т.к. не вписывается он до конца в концепцию C++ нулевых накладных расходов.
У нас тут сейчас один тестовый проект на D и некоторыми моментами реально можно наслаждаться именно из-за интроспекции. Т.е. код вида:
struct User{
string name;
int age;
};
Send(Json(User("Alex", 111)));
реально радует (Json естественно ничего не знает про User и вообще не нами написан). Причём т.к. это всё во время компиляции конструируется, оно ещё и очень быстрое.
Правда это всё примеры именно интроспекции, а не метапрограммирования, хотя они и связаны. А в метапрограммирование я могу очень просто объяснить любому специалисту по C++ преимущества D. Для этого я могу предложить им представить себе, чтобы они могли сделать в C++ при двух простейших дополнениях:
1. Если бы в C++ можно было параметризовать шаблоны строками
2. Если бы была функция, которая преобразовывает строку в код, размещаемый (причём с использованием локальных переменных, оптимизации и т.п.) по месту вызова этой функции.
Мне даже страшно себе представить, что бы натворили некоторые маньяки C++ (типа пишущих всякие Boost.Spirit и т.п.), если бы им дали в руки такой инструмент...
Здравствуйте, Erop, Вы писали:
E>Я даже больше имел в виду, у этого нового подинтервала будет, похоже, другой тип. Ну или я чего-то не понял. E>при этом если у нас где-то будет ветвление, ну, например вернуть элементы списка от начала до конца строки, но не больше 100 штук, как написать, я уже вообще не понимаю даже...
auto myfind(Range, T)(Range r, T t)
{
size_t n = 0;
auto left = r.save;
while(!r.empty && r.front != t) {
r.popFront();
n++;
}
return tuple(left.takeExactly(n), r);
}
myfind возвращает два интервала разных типов. У первой части результата — специальный тип который возвращает takeExactly.
Если нужно будет на этих двух range сделать что-то типа: [std::prev(std::find(first, last, x)), last) — видимо придётся вводить ещё два новых типа — один для chain, другой для взятия последнего элемента из первого интервала — вот только как это сделать эффективно? За O(1) — видимо не получится, так как left.takeExactly(n) не знает где середина, а только знает на каком она расстоянии от начала — для bidirectional это будет O(n).
E>То есть, или концепция какая-то совсем кривая, или я не понимаю чего-то самого главного...
Концепция нормально подходит только для single pass, для всего остального как-то не очень.
Здравствуйте, alex_public, Вы писали:
EP>>Вообще-то при работе из STL используются не только контейнеры, но и алгоритмы, причём алгоритмы намного разнообразней. EP>>И в том же std.algorithm в D — там всё на range'ах, так что от них никуда не уйти. _>Не, алгоритмы в D едят и просто массивы. И выдают их же при этом.
Ну так не одни же массивы используются.
EP>>Это не интересно — практически идентично переносится на C++: EP>>
EP>>BinarySearch(input[0..i], value);
EP>>// versus
EP>>BinarySearch(input | sliced(0,i), value);
EP>>
_>Не, это не то. Ты же при этом заменил входные параметры функции с массивов на range.
Всё то — в C++ вот такой массив int x[11] — тоже range.
_>Вот если бы у range можно было вызывать функции массива (хотя в данном конкретном примере это и не пригодилось)...
Какие?
EP>>А вот попробуй сделать аналог std::partition_point _>А что там такого? Ну будет например функция с прототипом вида Tuple!(T[], T[]) partition_point(T[], ...)
Только массивы вообще не интересны. std::partition_point работает даже с Forward итераторами. Попробуй сделать интерфейс, и хотя бы набросай реализацию (мелкие баги не имеют значения).
EP>>Так в том то и дело, что они не то что стандартную — они вообще никакую деку не нашли. _>Кстати, мне кто-то писал фразу что типа C# — это типа самый продвинутый язык из мейнстримовых. Я в ответ спросил как у нас с метапрограммированием в самом продвинутом языке. Мне в ответ гордо назвали T4 и Reflection.Emit, на что я предложил написать например Boost.Spirit на этом... А сейчас я представил себе как этот народ отреагировал бы на примеры, которые способен решать D.
Я предполагаю что Spirit-like там возможен двумя путями: через разбор встроенных в язык Expression Trees, либо через перегрузку операторов. Но видимо и там и там будет runtime overhead.
Здравствуйте, alex_public, Вы писали:
EP>>Если кто-то постоянно тем и занимается что итетрирует структуры данных, и ему не хватает текущих возможностей — то пусть отсылает proposal в reflection study group #7, его обязательно рассмотрят. _>Вот как раз интроспекции времени компиляции (а не того ненужного недоразумения времени выполнения, как в жабке и шарпе) крайне не хватает в C++. Например для сереализации.
Не хватает, но это не так критично как тут пытаются представить "omg нет reflection! все на D, Nemerle и т.п."
_>Кстати, а RTTI я бы вообще из C++ выкинул — от него вред только один, т.к. не вписывается он до конца в концепцию C++ нулевых накладных расходов.
А какие накладные расходы он по-твоему добавляет?
_>У нас тут сейчас один тестовый проект на D и некоторыми моментами реально можно наслаждаться именно из-за интроспекции. Т.е. код вида: _>[...] _>реально радует (Json естественно ничего не знает про User и вообще не нами написан). Причём т.к. это всё во время компиляции конструируется, оно ещё и очень быстрое.
Это всё понятно, и действительно круто. Но сейчас — отчасти решается макросами, либо с небольшим дублированием в виде описания схемы в одном из форматов(Boost.Fusion, или например Boost.Serialization).
Более того — у меня в одном из проектов есть большая схема, так она вообще в xml хранится, и код из неё нормально генерируется, и не программисты могут с ней работать + всякие xml утилиты, и как-то не комплексуем по поводу "ай-ай-ай, нет reflection, надо менять язык!".
_>А в метапрограммирование я могу очень просто объяснить любому специалисту по C++ преимущества D.
Да многие тут знают эти преимущества.
_>Для этого я могу предложить им представить себе, чтобы они могли сделать в C++ при двух простейших дополнениях: _>1. Если бы в C++ можно было параметризовать шаблоны строками
В C++11 можно (гугли "Using strings in C++ template metaprograms", + должно уже быть в библиотеках)
_>2. Если бы была функция, которая преобразовывает строку в код, размещаемый (причём с использованием локальных переменных, оптимизации и т.п.) по месту вызова этой функции.
Здравствуйте, VladD2, Вы писали:
EP>>В смысле? Study group для reflection появилась недавно. VD>Кого это трогает? Комитет по С++ существует не менее 20 лет. За это время гора родила мышь.
Понятное дело, что это плохое оправдание, но наличие (такого?) комитета скорее наоборот замедляет развитие языка: разные люди/организации — разные интересы. Майкрософт, например, забивает на реализацию некоторых вещей.
EP>>Или ты думаешь что создатели уже 30 лет думают как бы впихнуть reflection, да всё никак не получается? VD>Я не думаю. Я знаю об этом. Мы 10 лет назад обсуждали эту тему. А воз и ныне там.
Знаешь, что у них не получается? А какие принципиальные проблемы? Да, потеряли много времени, да иногда делали не то, что хотелось бы, но ведь будет и не так уж долго ждать осталось.
Пример, конечно, удачный и С++ тут сливает — сложно спорить. Но так ведь он не единственный.
VD>Я понимаю, Матумба — это такой матумба. Ему оскорбить окружающий что два пальца об освальт. Но выдвигая, в ответ его наездам, тезис — "С++ лучше", нужно его хоть чем-то обосновать.
Можно подумать, что в теме мало раз озвучивали мысль типа "С++ в среднем хуже, но недостаточно, в немалой степени, из-за сформировавшейся инфраструктуры". Да и развивается, плюс не так быстро как хотелось бы. Хотя сейчас может и прибавят темп.
Тема итераторов и правда поднадоела, но я вот тоже разделяю мнение, что они гибчи и рейнджи поверх добавить проще, чем наоборот. А стиль стандартной библиотеки всё-таки диктует стиль остальных (да хотя бы boost и Qt тоже итераторы поддерживают).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>_1 это библиотечная полиморфная лямбда, VD>>Давай поглядим на ее реализацию. Приведи, плиз.
EP>уже было выше
Дык там нигде реализации не приводилось. А она явно весьма объемная.
VD>>А 29 лет в нем вообще не было бямбд. Хотя лямбды старше С++ еще на 30 лет.
EP>Ты считаешь что в язык нужно тащить каждую фичу?
В хороший язык тащат только базовые вещи вроде полноценной поддержки метапрограммирования и средств расширения синтаксиса. Но С++ к этому классу языков отношения не имеет. По тому я последние 7 лет с удовольствием использую Nemerle вместо C++. С огромным удовольствием, надо заметить!
VD>>Библиотеки дело наживное.
EP>Естественно. Можно прям сегодня придумать супер-пупер язык, и сказать что библиотеки, компиляторы, и т.п. — всё наживное, и возмущаться — почему же никто не переходит на этот супер-пупер язык
Это демагогия. Компилятор, как ползователь, ты сделать не можешь. А библиотеки — без проблем. Тот же STL написал рядовой пользователь С++ работавший в HP.
VD>>Если бы люди вроде тебя вместо того чтобы искать фатальные достатки просто попробовали что-нить написать на Ди, то и библиотеки появились бы.
EP>А, ну то есть программисты во всём виноваты
Нет, часовинку это до вас — в 17 веке (с)
А так кто еще кроме нас виноват в том, что у нас чего-то нет? Если ждать дядю, то так и будешь чем попало пользоваться.
EP> — не пишут библиотеки для языка который непонятно взлетит или нет,
D появился в 1999 году, то есть ему лет немногим менее чем тебе, а ты все сомневаешься взлетит он или нет. Если он не взлетел, то у него комитов в репозитории не было бы.
EP> непонятно с каким runtime overhead'ом (см. выше интервью с автором). Да как они посмели!
И не поймешь, пока не попробуешь. Вот те кто пробовал говорят, что сравнимо с С. А остальные сомневаются и сомневаются.
Я вот использую язык рантаймом для которого является дотнет. Не самый производительный рантайм, да? Сборка мусора с сопутствующими мемори-барьерами и прочими велелостями. Но вот код в нашем современном проекте работат очень даже шутсро. Знаешь почему? Да потому что почти любой рантайм может быть вполне быстрым, если не пользоваться тем что вызывает тормоза.
Мы сейчас делаем генератор парсеров. Он вместо объектоного АСТ создает массив int-ов (точнее парочку). А код выглядит как-то так:
Ты на С++ такой писать не будешь, так как это жутко грязный низкоуровневый код.
А мы вот себе это позволить можем, хотя в отличии от вас у нас есть и GC, и полноценные замыкания (изменяемые и живущие любое время), и даже алгебраические типы с паттернматчингом. И можем мы это себе позволить потому что генерация кода в нашем языке — это шатная фича которая не ломает мозг и не нагибает компилятор.
VD>>Что касается ренджей, то они, скорее всего, и так достаточно быстрые и никому не нужно искать им замену.
EP>Помимо скорости, они ещё и менее удобные, и менее мощные.
Это в тебе Блаб говрит. Ты просто не умеешь их готовить. Точнее ты настолько уткнулся в детали реализации, что не можешь оторваться от них и посмотреть на то что они дают. Вот к примеру, что можно сделать на прототипе ренджей (энумераблах шарпа).
Вот этот код грузит объекты по описанию хмл-конфиге:
var root = XElement.Load(gonfigPath);
var libs = root.Elements("Lib").ToList();
var result =
libs.Select(lib => Utils.LoadAssembly(Path.GetFullPath(Path.Combine(rootPath, lib.Attribute("Path").Value)))
.Join(lib.Elements("SyntaxModule"),
m => m.FullName,
m => m.Attribute("Name").Value,
(m, info) => new { Module = m, StartRule = GetStratRule(info.Attribute("StartRule"), m) }));
А этот:
var libs = syntaxModules.GroupBy(m => MakeRelativePath(from:root, isFromDir:true, to:m.GetType().Assembly.Location, isToDir:false))
.Select(asm =>
new XElement("Lib",
new XAttribute("Path", asm.Key),
asm.Select(mod =>
new XElement("SyntaxModule",
new XAttribute("Name", mod.FullName),
mod.Rules.Contains(startRule) ? new XAttribute("StartRule", startRule.Name) : null))
));
return new XElement("Config", libs);
сериализует объекты обратно в конфиг.
Медленно ли работает этот код? В ГУЕ, где он применяется, времени его работы не видно в микроскоп. А вот времени он сэкномил массу.
И не надо мне рассказывать, что подобную лабуду ты сможешь написать и на С++. По целому ряду причин ФП неудобен в С++. Потому так пишут редко. Те же проблемы с интелисенсом не дают быстро написать такой "запрос".
VD>>Заметь в Nemerle if самый обыкновенный. static if не нужен, а кодом можно манипулировать как данными.
EP>В D можно манипулировать кодом как строкой — см. mixin.
Надеюсь человеку знакомому с прероцессором С не надо объяснять чем чреваты манипуляции строками? Да и выглядит это убого. В этом отношении у Ди серьезные проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Дык там нигде реализации не приводилось. А она явно весьма объемная.
Смотри внимательней, там под cut'ом.
VD>>>А 29 лет в нем вообще не было бямбд. Хотя лямбды старше С++ еще на 30 лет. EP>>Ты считаешь что в язык нужно тащить каждую фичу? VD>В хороший язык тащат только базовые вещи вроде полноценной поддержки метапрограммирования и средств расширения синтаксиса.
Хороший для чего?
VD>Но С++ к этому классу языков отношения не имеет. По тому я последние 7 лет с удовольствием использую Nemerle вместо C++. С огромным удовольствием, надо заметить!
Да я вижу — и тихо ненавидишь всех кто его не расширяет/не использует. Нет уж, спасибо.
VD>А библиотеки — без проблем. Тот же STL написал рядовой пользователь С++ работавший в HP.
Тут как раз уж и не рядовой. Он эти идеи вынашивал много лет, и до этого делал реализации на разных языках (Scheme, Ada, etc)
VD>Если он не взлетел, то у него комитов в репозитории не было бы.
Да уж — вот это взлёт.
VD>Мы сейчас делаем генератор парсеров. Он вместо объектоного АСТ создает массив int-ов (точнее парочку). А код выглядит как-то так: VD>
VD>
VD>Ты на С++ такой писать не будешь, так как это жутко грязный низкоуровневый код.
Там где не хватит скорости Spirit'а или подобного — я спокойно могу взять внешний генератор кода
Если приспичит, внешний генератор даже может подключатся к expression tree из кода — прям брать неопределённый символ с закодированной грамматикой из obj, и генерировать нужный код — но это только если делать нечего.
VD>А мы вот себе это позволить можем, хотя в отличии от вас у нас есть и GC, и полноценные замыкания (изменяемые и живущие любое время)
Что значит живущие любое время? А если там ресурс?
VD>>>Что касается ренджей, то они, скорее всего, и так достаточно быстрые и никому не нужно искать им замену. EP>>Помимо скорости, они ещё и менее удобные, и менее мощные. VD>Это в тебе Блаб говрит.
VD>Ты просто не умеешь их готовить. Точнее ты настолько уткнулся в детали реализации, что не можешь оторваться от них и посмотреть на то что они дают. Вот к примеру, что можно сделать на прототипе ренджей (энумераблах шарпа).
Да не надо сравнивать "энумераблы шарпа" с D-Range — они им и в подмётки не годятся
"энумерабл" это single pass — а в D далеко не одна категория Range, также как в STL
VD>>>Заметь в Nemerle if самый обыкновенный. static if не нужен, а кодом можно манипулировать как данными. EP>>В D можно манипулировать кодом как строкой — см. mixin. VD>Надеюсь человеку знакомому с прероцессором С не надо объяснять чем чреваты манипуляции строками? Да и выглядит это убого. В этом отношении у Ди серьезные проблемы.
Ну вроде бы всё ясно. "D хорош, но у него серьёзные проблемы — нужен Nemerle"
А вообще — если ты пытался разрекламировать Nemerle — то получилось всё как раз наоборот.
Да вот здесь (уперся в какую-то незначительную хрень неизвестно зачем): EP>>Как известно, у C++ основным приоритетом является производительность. EP>>А в D спокойно могут пожертвовать производительностью ради других целей (об этом говорил A.A.). EP>2. EP>>Взять например те же ranges — они проигрывают итераторам по производительности by-design EP>[/q]
EP>И ровно в этих рамках я и пытаюсь остаться.
Ага. Приводя говногод на мапах созданных из макросов вместо полноценных решений и называя при этом полноценные решения
EP>Обсуждать метапрограммирование не особо интересно — так как все согласны что оно мощнее у D.
Метапрограммирование способно заменить все твои абстракции и сделать код настолько быстрым насколько это позволяет железо. Я тебе уже говорил об этом. Но ты даже не смог понять моих слов. Начал какие-то ссылки на мат-библиотеки давать.
Пойми, если у тебя выбор между ренжами и итераторами, то у меня выбор между работой с указателями или прямым использованием массивов. Мой выбор априори не имеет оверхэда. И мне плевать, что ты в С++ сочтешь мой подход грязным и неприемлемым, так как я свой код руками писать не буду.
Мои абстракции — это макросы (синтаксические и типизированные) которые скрывают сложность и дерьмвость кода, а так же позволяют изменить реализацию, заменить типы контейнеров (по вашему) и вообще сделать все что угодно, просто заменим реализацию поры генерирующих функций.
Короче, совсем другие подход. Чем-то похоже на метапрограммирование на шаблонах, только без их тормозов, выноса мозга, ограничений и феерических сообщений об ошибках.
EP>Где ты тут видишь "бросился отстаивать его превосходство над тем же D".
Да вот же выше.
EP>>>Я вот не пойму — откуда у программистов не пишущих на C++ к нему такая злость/зависть/etc? VD>>Лично у меня злобы нет.
EP>Да ладно: EP>1. Ты говоришь что я "бросился отстаивать его превосходство над тем же D".
Что вижу, то и говорю. Ты еще довольно адекватен. Некоторые начинают доказывать крутость МП на шаблонах. Это вообще звиздец.
EP>2. Считаешь что программисты которые используют C++ — знают только один язык.
Не программисты, а конкретно ты. Я сам не мало писал на плюсах. Правда тогда они были несколько другими. А один мой коллега писал на плюсах еще 1.5 года назад и весьма в нем приуспел. Сейчас мы вот оба пишем на Nemerle полностью сходимся во мнении по поводу С++ — язык для выжимания битов.
EP>3. Говоришь что кто-то тут выдвигает тезис "С++ лучше"
А что ты тогда делаешь в это теме. Мы кажется выяснили, что твои тезисы не верны. Но ты продолжаешь их отстаивать, подменяя язык библиотекой и оправдываясь тем, что видите ли программистам некогда писать библиотеки.
EP>4. Игнорируешь то, что тут все согласны что в D метапрограммирование лучше, и пытаешься поджечь холивар на эту тему.
ты привел в каких целях? Там еще забавные слова есть:
И внезапно, полный код выглядит на порядок чище чем в D и Nemerle.
хотя решение — банальное мошенничество. Поставленную задачу не решает (и не может, по описанным тобой же причинам).
EP>Если это не от злобы, то от чего?
Поверь. Мне плевать на С++. Да и на D, тоже. Злобы у меня нет ни на гршь. Просто я моя ранимая душа не может спокойно смотреть на бессмысленные и некорреткные обоснования того что обоснования иметь не может, так как не верно.
Правда в том, что единственным реальным преимуществом С++ является его поддержка монстрами индустрии. Ну, и то что родился он в мего-корпорации. Все остальное — следствие.
С++, конечно, не некудышный язык. И он действительно позволяет писать быстродействующий код. Но Ди тут от него ничем не отличается. Да и разрыв между С++ и скажем дотнетом или Явой не так значителен как многие пытаются утверждать. Для большинства применений разница не критична, а стоимость разработки разница на порядки.
EP>Страуструп уже более 30 лет развивает язык, несмотря на его "неидеальность" — улучшает и улучшает.
Честь ему и хвала, претензии ведь не к нему. Он сделал что мог. Ну, возможно, затормоизл равитие языка. Но не это не его одного вина. Там ведь комитет. А комитет — это существо с множеством рук и ног и полным отсутствием головы.
EP>Мог бы он бросить всё и создать "перспективный, динамично развивающийся и т.п."? — да конечно мог бы. Он мог бы делать также как и Вирт — сколько там у него языков было? — вот только где сейчас все эти перспективные и развивающийся?
Не знаю. Мне по фиг. Лучшие языки создали без него. Но серые массыинтеллектуальное большинство вот уже 10 лет ищет оправдание том что мешает им хотя бы попробовать альтернативу. А менеджеры ищут оправдание почему тот или иной язык нельзя применять в разработке. И что характерно, успешно находят.
VD>>Ну, глупо в 21-м веке использовать языки в которых:
EP>Глупо — это ждать того, что программисты внезапно бросят всё и присоединятся к комьюнити малоиспользуемого языка.
Возможно. Я не жду. Моя вера в человеческий разум угасла много лет назад. Я просто пользуюсь тем, что мне удобно и помогаю делать это другим.
EP>Глупо ждать того, что индустрия резко станет оказывать гуманитарную помощь "перспективным языкам".
Глупо говорить о помощи самое себе. Перейдя на более перспективные языки и технологии "индустрия" могла бы повысить свое КПД. Это примерно как называть гуманитарной помощью использование научных достижений в производстве и сельском хозяйстве.
VD>>1. Не поддерживается модульность, а вместо нее есть препроцессор с инклюдами.
EP>Это действительно проблема. Ведётся работа.
Ага. Напомню, ведется 30 лет. Я лично ждал 5 лет и устал.
VD>>2. 30 лет не могут создать полноценный интелисенс.
EP>Ничего критичного.
Критично для производительности.
VD>>3. Скорость компиляции больших проектов чудовищно низкая.
EP>Проблема есть, но не в "чудовищных" масштабах.
Достаточно. Интерактивность разработки падает, а это резко снижает скорость продвижения вперед проекта.
Скажу тебе по серету, что похожая проблема есть в Немерле. Он выводит типы круто, но медленно. Не так медленно, чтобы по 15 минут ждать компиляции проекта, но все же по 2-3 минуты иногда приходится ждать. А это очень замедляет разработку.
По сему мы работаем над тем, чтобы сделать вторую версию лишенную этого недостатка. А вот терпеть — это не для нас. Это без нас как-нибудь.
VD>>4. Система метапрограммирования основана на побочных эффектах от других средств, а не разработа специально.
EP>А кто сказал что нужна какая-то специально разработанная мета-система?
Никто. А надо? Что это меняет?
EP>Метапрограммирование — это практически хак, который приходит на помощь там где недостаточно мощи самого языка.
Вот именно. А недостатков много. Так что Буст чуть менее чем полностью является такими вот костылями.
EP>В большинстве кода нет ничего мета*, только потому, что и без него всё хорошо
В большинстве кода есть мета* из библиотек. В купе с инклюдами это тормоза и невнятна диагностика.
VD>>5. Нет бинарного ABI.
EP>Действительно есть такая проблема, но совсем острая. EP>Если ограничится одной платформой, как делают некоторые языки, например .NET-ом, а-ля C++CLI/CX — то ABI получается что есть
А зачем ограничиваться, если тот же Ди его предоставляет? Может лучше стандартизировать объектно-функциональный ABI и перевести новую версию плюсов на нее? А еще лучше забыть про С++ и сделать новый язык / довести до ума один из имеющихся?
VD>>6. Нет даже соглашений по формированию имен функций в библиотеках.
EP>Мелочь, причём спорная.
Что там спорного? Из-за этого все библиотеки С++ распространяются в исходниках.
VD>>7. Требуются предварительные декларации.
EP>Мелочь.
Все мелочи. Но в купе набегает. И выходит, что язык сильно устарел, а новые не принимают.
VD>>8. Нет даже опциональной системы автоматического управления памятью.
EP>В ISO C++11 есть интерфейс для GC — но он вообще не популярен, что скорее говорит об востребованности
В С++ с его моделью памяти нельзя сделать поддержку точного GC, так что спека тут не поможет. А зачем нужно медленное и кривое решение?
Короче, проблем выше крыши. Они не решаются уже много много лет. И все это время люди упорно игнорируют решения в которых таких проблем нет. Ну разве что МС и Сан смогли протолкнуть языки на базе виртуальных машин. Но ни один нативный язык так в мэйнстрим и не пробился, если не считать дельфи который просто уничтожил МС сманив главного разработчика языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
EP> if (field.GetMemType().Equals(<[ ttype: int ]>))
EP> <[ result ^= this.$(field.Name : usesite) ]>
EP> else
EP> <[ result ^= this.$(field.Name : usesite).GetHashCode(); ]>
он генерирует разный код для разных типов полей. Где хотя бы это в твоем решении?
А где возможность добавить к произвольному классу атрибут (или что-то похожее) чтобы получить в нем метод?
Я не просил реализовывать операторы () и внешние функции.
EP>Разве не очевидно какой код второй по счёту пахнет резче остальных?
Очевидно, что ты решил другую, намного более простую, для тебя задачу. Очевидно, что это мошенничество. А оно меня не интересует.
Если бы в плюсах были средства подобные тем что есть в D и Nemerle, то я бы вряд ли бросил плюсы.
VD>>В твоем решении даже нет: VD>>1) проверки для int;
EP>Вообще-то boost::hash_combine вызывает нужную hash_value
Я наверно очень отстал от прогресса в С++. Покажи мне как это приводит к генерации разного кода для int-а, и других объектов.
Если что-то реализовано еще где-то, то надо было это привести. А то я тебе тоже могу библиотечный макрос привести и сказать, что у меня тут все очень кратко.
Интересные же возможности языка, а не библиотека которую уже кто-то написал.
VD>>2) формирования метода.
EP>Так а зачем мне метод, если спокойно реализуется внешней функцией, и более того — является стандартным интерфейсом.
Затем, что в задаче было такое условие.
EP>>>И внезапно, полный код выглядит на порядок чище чем в D и Nemerle
VD>>Это потому что ты знаешь ровно один язык.
EP>Твоя телепатия не работает.
Тут не нужно телепатии. Танцы с бубном ты называешь "порядок чище", а прямое создание нужного кода — чем-то грязным, очевидно.
VD>>Очень советую изучить тот же D и Nemerle, тогда ты подобные заблуждения высказывать не будешь.
EP>D — возможно, Nemerle — нет уж, спасибо
Ну, в принципе — да. Начинать надо с более легких задач. Потом может и до Немерла дорастешь. А то паттерн-матчинг и прочие алгебраические типы данных частенько плохо принимаются без должной подготовки.
VD>>Код по ссылке решает исходную задачу, а не подогнанную и упрощенную. И он таки проще, чем твой. Только надо иметь базовые знания для его понимания.
EP>ога, "код становится простым, после изучения малоиспользуемого языка"
Чтобы понимать код нужно знать идиомы использованные в нем. Лично мне твой код менее понятен, так как большая его часть просто скрыта от глаз в библиотеке. Код на Ди мне понятен, но я не знаю его АПИ (этих трейтсов). Код на немерле прост как три копейки, но я знаю все идиомы в нем использованные и знаю его АПИ. По сему мне проще читать код на Немерле. Дальше идет Ди, и только потом С++. И это при том что я на С++ писал лет 5 (если не считать времени когда писал на С).
Думаю, что если тебе дать пару пояснений, то и ты поймешь, что он очень прост.
EP>Практически все преимущества range-only решения, доступны для решения итераторы+обвёртки.
Ну, да. С помощью адаптеров из неудобных, но гибких итераторов можно сделать удобные ренжи или их аналоги. Бесспорно.
Возможно для Ди так и нужно было бы сделать. Ну, так это никогда не поздно сделать. Если конечно, обертка не будет давать оверхэд.
VD>>Ренжи — это аналоги ленивых списков из ФА или IEnumerable из дотнета.
EP>Это ты сильно льстишь IEnumerable — D-Range намного мощнее
Я говорю, что есть. Мощнее / слабее — без разницы. Ленивого списка достаточно для получения плюшек ФП. Да и не ленивый сойдет в 90% случаев.
VD>>Ленивые списки в купе с правильной библиотекой вроде linq-а повышают уровень кода в разы.
EP>Эта ленивость доступна и для STL итераторов, причём без бешеной abstraction penalty
Да понятно, что доступно. Просто авторы Ди, видимо, решили, что не нужды в создании прогладок и создали удобный механизм который и используют в свое удовольствие.
В С вот нет ни ренжей, ни итераторов, а не нем по прежнему большая часть Виндов и Линукса написаны. Стало быть не в абстракциях счастье. Функция тоже не плохая абстракция, в конце концов.
Все что я тебе пытался сказать, что ты прицепился к мелочи, которая, к тому же, легко исправляется. А вот обсуждать реальные преимущества и недостатки ты уже не хочешь. Все у тебя "незначительно" и "не важно".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
VD>>>Так уже лучше J>>ничего не изменилось, вообще-то Или ты про переименование?
VD>Ты просто невнимательно читаешь. Вот предыдущий пример: VD>
Здравствуйте, VladD2, Вы писали:
VD>Да вот здесь (уперся в какую-то незначительную хрень неизвестно зачем):
Ты сначала разберись о чём речь — и тогда не будет странных сравнений D-Range с примитивным IEnumerable
VD>Ага. Приводя говногод на мапах созданных из макросов вместо полноценных решений и называя при этом полноценные решения
Чего?
EP>>Обсуждать метапрограммирование не особо интересно — так как все согласны что оно мощнее у D. VD>Метапрограммирование способно заменить все твои абстракции и сделать код настолько быстрым насколько это позволяет железо. Я тебе уже говорил об этом. Но ты даже не смог понять моих слов. Начал какие-то ссылки на мат-библиотеки давать.
Библиотеки это пример того, что полноценная генерация произвольного кода нужна далеко не всегда — там нет ручных итераций, и при это всё оптимизируется на стадии компиляции
VD>Пойми, если у тебя выбор между ренжами и итераторами, то у меня выбор между работой с указателями или прямым использованием массивов. Мой выбор априори не имеет оверхэда.
Во многих случаях итераторы добавляют 0 оверхеда
VD>И мне плевать, что ты в С++ сочтешь мой подход грязным и неприемлемым, так как я свой код руками писать не буду.
Да ты наверно код генерирующий генератор генератора генератора кода пишешь
VD>Мои абстракции — это макросы (синтаксические и типизированные) которые скрывают сложность и дерьмвость кода, а так же позволяют изменить реализацию, заменить типы контейнеров (по вашему) и вообще сделать все что угодно, просто заменим реализацию поры генерирующих функций.
Я тебя поздравляю. Зачем ты мне об этом пишешь? Тем более если нормально не хочешь вести беседу?
EP>>2. Считаешь что программисты которые используют C++ — знают только один язык. VD>Не программисты, а конкретно ты.
Как ты пришёл к такому умозаключению?
VD>Я сам не мало писал на плюсах. Правда тогда они были несколько другими. А один мой коллега писал на плюсах еще 1.5 года назад и весьма в нем приуспел. Сейчас мы вот оба пишем на Nemerle полностью сходимся во мнении по поводу С++ — язык для выжимания битов.
Мне эти самые биты и нужно выжимать
EP>>3. Говоришь что кто-то тут выдвигает тезис "С++ лучше" VD>А что ты тогда делаешь в это теме.
VD>Мы кажется выяснили, что твои тезисы не верны.
Где? Кто вы?
VD>Но ты продолжаешь их отстаивать, подменяя язык библиотекой и оправдываясь тем, что видите ли программистам некогда писать библиотеки.
Да где я подменяю язык библиотекой?
VD>Поставленную задачу не решает (и не может, по описанным тобой же причинам).
А что из поставленной задачи он не решает?
То что аттрибута нет — так его и не будет, по очевидным причинам. Эта задача что-ли такая — за-использовать атрибут? Не — не интересно.
Добавить метод в класс? Тоже не серьёзно. Я бы этот метод не добавил в класс даже если бы код вручную писал, зачем он там?
То что вместо
?
Не — это всё несерьёзные придирки. Ты лучше в следующий раз что-нибудь посложнее придумай.
VD>>>4. Система метапрограммирования основана на побочных эффектах от других средств, а не разработа специально. EP>>А кто сказал что нужна какая-то специально разработанная мета-система? VD>Никто. А надо? Что это меняет?
Так ты же и говоришь, что "не разработана специальна -> является недостатком". Или нет?
EP>>Метапрограммирование — это практически хак, который приходит на помощь там где недостаточно мощи самого языка. VD>Вот именно. А недостатков много.
Выделенное относится не только к C++
VD>все библиотеки С++ распространяются в исходниках.
Ложь.
VD>>>7. Требуются предварительные декларации. EP>>Мелочь. VD>Все мелочи. Но в купе набегает. И выходит, что язык сильно устарел, а новые не принимают.
Куда не принимают? Это же свободный рынок.
Если твой язык позволяет решать задачи в 10x быстрее, генерировать в 10x более быстрый код, лёгок в изучении, поддержке и т.п. — то и компания которая его выберет будет в большом профите, всё элементарно
VD>>>8. Нет даже опциональной системы автоматического управления памятью. EP>>В ISO C++11 есть интерфейс для GC — но он вообще не популярен, что скорее говорит об востребованности VD>В С++ с его моделью памяти нельзя сделать поддержку точного GC, так что спека тут не поможет.
http://www.stroustrup.com/C++11FAQ.html#gc-abi
VD>Короче, проблем выше крыши. Они не решаются уже много много лет. И все это время люди упорно игнорируют решения в которых таких проблем нет. Ну разве что МС и Сан смогли протолкнуть языки на базе виртуальных машин. Но ни один нативный язык так в мэйнстрим и не пробился, если не считать дельфи который просто уничтожил МС сманив главного разработчика языка.
В Delphi как в языке нет ничего интересного/оригинального. Не спасла бы его Эмбаркадеро — был бы уже в истории
Здравствуйте, FR, Вы писали:
FR>На самом деле красиво FR>Но к сожалению Владовскую задачу не решает, член а класс не добавляет, а без этого на D легко FR>повторить также красиво.
Там и других "проблем" хватает. Проверки типа поля в коде нет. Она или есть в библиотеке, а значит решение представлено не полностью и оно уже точно не будет "таким красивым", или ее нет вовсе.
Плюс красота очень спорная. Я красивым считаю не количество букв, а соответствие решения намерениям. Если нам нужно добавить код, то хочется и видеть как это происходит, а не загадочные операторы () и прочие хелпер-классы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Evgeny.Panasyuk, Вы писали:
DM>>>Ты же все приставал с получением двух частей — до найденного элемента и от него дальше. Я показал.
EP>>Ну да, показал — неэффективное, негибкое, и более многословное:
FR>Реально же ерундой занимаетесь, сравниваете мягкое с зеленым. FR>Итераторы C++ и интервалы D слишком различны. Базовое различие все, включая и FR>меня, совсем упустили, интервалы D в отличии от итераторов не работают по месту, FR>а выдают новый интервал, по сути ближе к базовым ФВП из функциональщины FR>работающими со списками. Даже boost::range в основной массе этого не делает FR>а тоже работает по месту как и его базовые итераторы.
Адаптеры boost::range ленивые все. Пока ты не начнешь реально итерироваться по результату всех тих transformed|filtered|uniqued, ничего вообще не происходит.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не хватает встроенной в стандарт compile-time reflection — тогда от макроса можно было бы уйти.
Еще не хватает:
1. Прямых средств генерации кода, а не с помощью финтов ушами, множественного наследования на ровном месте и прочей фигни.
2. Возможности бинарной компиляции метакода, чтобы мета-решения не отличались по скорости от тех что встроены в компилятор. Этого, кстати, и в Ди нет, вроде бы.
3. Возможности внятного и удобного расширения и/или реинтерпретации синтаксиса, чтобы мета-решениям можно было придать логичный и удобный вид.
Если добавить эти мелочи, то... получится совсем другой язык.
EP>В С++ не принято добавлять члены в класс на каждый чих, наоборот — non-member предпочтительнее.
Это все оправдания. А по факту в С++ не принято решать проблемы просто и качественно. Все больше через зад, да автогеном.
Добавление метода может быть нужно просто для того, чтобы переопределить виртуальный метод. Не все проблемы, знаете ли, решаются в компайлтайме. Есть еще динамический полиморфизм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
_>Мне даже страшно себе представить, что бы натворили некоторые маньяки C++ (типа пишущих всякие Boost.Spirit и т.п.), если бы им дали в руки такой инструмент...
Что там представлять? Они и натварили. Сначала PegGrammar
, а потом и Nitra. В Nitra так и происходит. Берем строку... из файла на диске... читаем из нее грамматику и генерируем на выхде динамически расширяемый эффективный парсер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если кто-то постоянно тем и занимается что итетрирует структуры данных, и ему не хватает текущих возможностей — то пусть отсылает proposal в reflection study group #7, его обязательно рассмотрят.
Лет 10 как отправили. Нам сказали, что RTTI должно быть достаточно для любых задач .
EP>В разных языках разные подходы. Non-member функция hash_value — это стандартный протокол в C++. И я не вижу никакого смысла использовать функцию член, когда допустим хэш-таблица ожидает non-member, только ради какой-то синтетической задачи.
Да вопрос то не в хэше. Вопрос в возможности решить конкретную задачу. Представь, что ты делаешь некий компонентный фреймворк или плагин и тебе нужна динамика. Вот у нас, например, парсеры динамически грузятся и кобмбинируются в составные. Берем грамматику, расширяем на лету другой и получаем С++ с поддержкой алгебраических типов данных и паттерн-матчинга .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>так она вообще в xml хранится, и код из неё нормально генерируется, и не программисты могут с ней работать + всякие xml утилиты, и как-то не комплексуем по поводу "ай-ай-ай, нет reflection, надо менять язык!".
Вот это характерно! Ты программируешь на ХМЛ-е, а не на С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
),
