Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Да не надо передёргивать что все не о том думали, все ходы записаны. Речь конкретна была про реализуемость I>>Про наличие в С++ ad-hoc типов !!!
EP>Что такое конкретно "ad-hoc" типы, он так и не пояснил. Как стало понятно из требуемого кода и вопроса про безликий tuple — речь шла про про реализуемость проекций, а конкретно синтезирование типов с нужными полями на месте (ad-hoc) — это в C++ есть
Судя по твоему ответу ниже — нету такого в С++, делать приходится или руками, или брать либу. То есть, идиома.
EP>Конечно, сел в лужу и начал съезжать уже не так категорично. Это при том что из первого же примера sqlpp11 видно что это не tuple и не "нетипизированная хрень".
Ты продолжаешь мерять по себе. Мне этот пример ни о чем не говорит даже сейчас. Для меня это просто фрагмент какого то кода, потому как в С++ я последний раз писал в продкшне почти 10 лет назад и почти ничего не знаю про нововведения.
Все что надо про sqlpp я выяснил у его автора.
I>>Теперь на секундочку — каким чудом обеспечивается точная типизация этого фокуса с ad-hoc типами ? Отвечай прямо, перечисляя все языковые фичи необходимые для этого.
EP>Наследование, вывод типов, и желательно variadic templates
То есть, ты уверен, что любой человек, который не пишет на С++ будет уверенно понимать такие фичи и их идиоматические возможности ?
Тебе не кажется это странным ? А вот ведь на практике тот же C++11 почему то не все плюсовики вкурили.
Re[157]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>За 10 лет до твоего пришествия сюда на этом форуме люди делились и парсером на темплейтах, и движком регекспов, и вычислением выражений.
EP>Те кто заявляет о невозможности не в курсе всего этого
Это зависит как ты либу и себя будешь презентовать. "умная склейка строк в компайл-тайм" — такое никто всерьез не принимает.
А если ты до кучи начнёшь юродствовать, как это любит делать alex_public, то все твои слова трактоваться соответствующе.
EP>Собственно я выше уже говорил, что expression template больше двадцати лет, первые статьи по ним появлялись ещё до выхода первого стандарта C++.
И что с того ? Пудозреваю, это стало более-менее удобоваримым только в последних стандартах и то не любой сиплюсник сможет такой или хотя бы знает о таком.
Почему ты требуешь, что бы все разделяли твою точку зрения — не ясно.
Re[159]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>И где тут хотя бы что-то из подчёркнутого? Хотя бы отдалённо напоминающее? Споришь с собственным воображением? S>>>> Достаточно. То есть С++ значительно лаконичнее линка, ибо это пишут монстры от Сшарп. Твои слова. EP>>>Причём тут LINQ вообще? Речь шла про реализацию алгоритма поиска минимального элемента S>> Во во. Там как раз было расширение для Linq . Казалось бы причем тут Linq?
EP>Не причём — речь про раздутую реализацию. Что же там снаружи рояли не играет. EP>То есть из того что я сказал что реализация алгоритма раздутая, ты пришёл к выводу "C++ лучший язык для работы с БД"
Твоя полная цитата, без твоих обрезок:
По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Для сравнения C#, свежий пример
— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
Ещё ДО отрабатывания T4, кода на C# больше, и его труднее поддерживать, ибо это склейка кода как текста.
Ты утверждаешь, что на C# нужно писать больше кода. Если бы ты сказал, что можно на C# сделать код значительно компактнее
то я бы понял, что данная реализация неоправданно раздута.
Ты же делаешь вывод по данному коду, что
По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех
То есть про утверждение, "По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех" сильно преувеличено? S>>>>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный. EP>>>Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД". S>> То есть С++ медленне? Тогда прошу прощения?
EP>С логикой беда? Я прошу привести пруфлинк на то что я говорил "быстрее в 2 раза", всё.
Мне лень искать, значит C# быстрее? Молчание знак согласия? И я зря просил прощения?
S>>При этом ты приводишь ассемблерный код? Дать пруф?
EP>Я действительно приводил ассемблерный код, вот только мне нужен пруф на "быстрее в 2 раза", а не на ассемблерный код
Ну тогда во сколько? Или я на порядки ошибся? S>> Но я тебе про тот алгоритм показал, что он будет короче на C# чем на С++. И ты с эти согласился.
Вот здесь ты приводишь ссылку на AWK где говрится про тормознутость компараторов, которые как на простых типах тормозят в 2 раза за счет неилайнового вызова метода.
То есть ты прямо не говорил, но привел пример почему C# тормознутее С++.
И так за каков поря док мне перед тобой извиниться?
EP>Алгоритм не короче, а намного длиннее. EP>Короче лямбда, у которой меньше скобочек, нет auto и return — но это всё ортогонально реализации алгоритма
То есть про утверждение, "По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех" сильно преувеличено?
S>>А вот признать свои слова ошибочными по отношению выразительности C# это ты не можешь.
EP>Сколько строк для min/max item в CodeJam? (до генерации)
А покажи внутренности std.
А C++ программисты всегда пишут лучший код. Ты сделал вывод на реализации расширения и на этом примере строишь свои доказательства о
"По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"
Или я опять, что то придумал?
Опять же про Expression Trees . В ваш спор про динамические запросы, и про динамическую инициализацию провайдера.
Тобой и Алексом было выдвинуто решение о том, что на этапе компиляции зашиваются все возможные реализации, а затем свичем выбираются нужные
провайдеры и динамическая склейка запроса? То есть, то что в .Net делается через динамическую компиляцию и ET.
То есть еще это еще один довод о
"По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"?
То есть алгоритмически лучше зашивать все возможные варианты, нежели использовать динамическую компиляцию и Expression Trees ?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Что такое конкретно "ad-hoc" типы, он так и не пояснил. Как стало понятно из требуемого кода и вопроса про безликий tuple — речь шла про про реализуемость проекций, а конкретно синтезирование типов с нужными полями на месте (ad-hoc) — это в C++ есть
Ага, теоретически. А на практике, как только ситуация стала чуть посложнее самой примитивной — пришлось городить дикие извраты на макросах. Т.е., как обычно, теоретически изывраты есть, а на практике толку от них в районе нуля.
Re[164]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Ikemefula, Вы писали:
EP>>>>Да не надо передёргивать что все не о том думали, все ходы записаны. Речь конкретна была про реализуемость I>>>Про наличие в С++ ad-hoc типов !!! EP>>Что такое конкретно "ad-hoc" типы, он так и не пояснил. Как стало понятно из требуемого кода и вопроса про безликий tuple — речь шла про про реализуемость проекций, а конкретно синтезирование типов с нужными полями на месте (ad-hoc) — это в C++ есть I>Судя по твоему ответу ниже — нету такого в С++, делать приходится или руками, или брать либу. То есть, идиома.
Идиома которой достаточно для реализации проекций, без "беликих tuple" и "нетипизированной хрени".
EP>>Конечно, сел в лужу и начал съезжать уже не так категорично. Это при том что из первого же примера sqlpp11 видно что это не tuple и не "нетипизированная хрень". I>Ты продолжаешь мерять по себе. Мне этот пример ни о чем не говорит даже сейчас. Для меня это просто фрагмент какого то кода, потому как в С++ я последний раз писал в продкшне почти 10 лет назад и почти ничего не знаю про нововведения.
Нововведения не причём.
Для того чтобы отличить tuple от типа с нормальными именованными полями никаких специальных знаний не требуется — достаточно знать что в tuple элементы не именованные (как и в других языках). Собственно и суть самой претензии к безликости tuple именно в том, что поля неименованные
I>>>Теперь на секундочку — каким чудом обеспечивается точная типизация этого фокуса с ad-hoc типами ? Отвечай прямо, перечисляя все языковые фичи необходимые для этого. EP>>Наследование, вывод типов, и желательно variadic templates I>То есть, ты уверен, что любой человек, который не пишет на С++ будет уверенно понимать такие фичи и их идиоматические возможности ? I>Тебе не кажется это странным ?
А не требуется всё это понимать, достаточно не делать заявлений о невозможности и т.п. при незнании топика.
I>А вот ведь на практике тот же C++11 почему то не все плюсовики вкурили.
Это вообще повсеместное явление, к языку не относящееся. Тут где-то недавно сетовали на то что далеко не все C#'исты знают основные возможности.
Re[160]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Serginio1, Вы писали:
EP>>Не причём — речь про раздутую реализацию. Что же там снаружи рояли не играет. EP>>То есть из того что я сказал что реализация алгоритма раздутая, ты пришёл к выводу "C++ лучший язык для работы с БД" S>Твоя полная цитата, без твоих обрезок: S>
...
S> Ещё ДО отрабатывания T4, кода на C# больше, и его труднее поддерживать, ибо это склейка кода как текста.
S> Ты утверждаешь, что на C# нужно писать больше кода.
Да, приводя конкретные примеры, написанные конкретными людьми с этого форума.
S>Если бы ты сказал, что можно на C# сделать код значительно компактнее то я бы понял, что данная реализация неоправданно раздута.
Так я же и не говорю что она неоправданно раздута
S> Ты же делаешь вывод по данному коду, что S>
S>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех
Лямбды лаконичнее — да, реализация алгоритма — нет.
Непонятно зачем ты патаешься оправдать раздутую реализацию алгоритма (простейшего!) лямбдами, впрочем мне это уже надоело.
S> То есть про утверждение, "По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех" сильно преувеличено?
Нет.
S>>>>>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный. EP>>>>Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД". S>>> То есть С++ медленне? Тогда прошу прощения? EP>>С логикой беда? Я прошу привести пруфлинк на то что я говорил "быстрее в 2 раза", всё. S> Мне лень искать, значит C# быстрее?
Нет, очевидно не значит.
S>Молчание знак согласия?
Детский сад.
EP>>Я действительно приводил ассемблерный код, вот только мне нужен пруф на "быстрее в 2 раза", а не на ассемблерный код S> Ну тогда во сколько? Или я на порядки ошибся?
Речь о том что я не давал оценку во сколько, ты же зачем-то приписываешь мне свои выдумки
S>>> Но я тебе про тот алгоритм показал, что он будет короче на C# чем на С++. И ты с эти согласился. S>https://rsdn.ru/forum/philosophy/6489092.1
S> Вот здесь ты приводишь ссылку на AWK где говрится про тормознутость компараторов, которые как на простых типах тормозят в 2 раза за счет неилайнового вызова метода.
1. Он там тоже не давал оценку во сколько они тормозят.
2. Даже если допустить что код C# с ними в два раза медленней чем код C# без них, то всё равно не понятно каким образом ты притянул C++ к этой оценке.
S>>>А вот признать свои слова ошибочными по отношению выразительности C# это ты не можешь. EP>>Сколько строк для min/max item в CodeJam? (до генерации) S> А покажи внутренности std.
Зачем?
S>То есть еще это еще один довод о S>"По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"? S> То есть алгоритмически лучше зашивать все возможные варианты, нежели использовать динамическую компиляцию и Expression Trees ?
К алгоритмам это не имеет практически никакого отношения. Скорее к метапрограмированию и поддержке EDSL времени компиляции.
Re[161]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Не причём — речь про раздутую реализацию. Что же там снаружи рояли не играет. EP>>>То есть из того что я сказал что реализация алгоритма раздутая, ты пришёл к выводу "C++ лучший язык для работы с БД" S>>Твоя полная цитата, без твоих обрезок: S>>
EP>...
S>> Ещё ДО отрабатывания T4, кода на C# больше, и его труднее поддерживать, ибо это склейка кода как текста.
S>> Ты утверждаешь, что на C# нужно писать больше кода.
EP>Да, приводя конкретные примеры, написанные конкретными людьми с этого форума.
Ну я могу написать кучу кода на С++ и буду по этому буду говорить, что С++ отстойный язык?
И все С++ программисты пишут оптимальный код?
На этом форуме иногда такого насмотришься
S>>Если бы ты сказал, что можно на C# сделать код значительно компактнее то я бы понял, что данная реализация неоправданно раздута.
EP>Так я же и не говорю что она неоправданно раздута
И из этого делаешь вывод, что
"По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"?
S>> Ты же делаешь вывод по данному коду, что S>>
S>>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех
S>> Или я опять, что то выдернул.
EP>Не только по этому, это лишь один из примеров.
Но ты приводишь как основной аргумент. Больше примеров ты не привел.
S>>Я тебе показал, что на Linq это будет лаконичнее чем на C++ S>>https://rsdn.ru/forum/philosophy/6489108.1
S>> Отличия минимальные — auto, return и скобочки.
EP>Лямбды лаконичнее — да, реализация алгоритма — нет.
Если ты про замыкания, то там строится класс компилятором.
EP>Непонятно зачем ты патаешься оправдать раздутую реализацию алгоритма (простейшего!) лямбдами, впрочем мне это уже надоело.
Я тебе показал реализацию которая компактнее реализации на C#. Ты же сам согласился выше. S>> То есть про утверждение, "По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех" сильно преувеличено?
EP>Нет.
Приводи доказательства. S>>>>>>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный. EP>>>>>Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД". S>>>> То есть С++ медленне? Тогда прошу прощения? EP>>>С логикой беда? Я прошу привести пруфлинк на то что я говорил "быстрее в 2 раза", всё. S>> Мне лень искать, значит C# быстрее?
EP>Нет, очевидно не значит.
То есть C++ все же быстрее? S>>Молчание знак согласия?
EP>Детский сад.
Ну да сделать выводы об алгоритмической отсталости C# на чьем то коде это верх серьёзности. EP>>>Я действительно приводил ассемблерный код, вот только мне нужен пруф на "быстрее в 2 раза", а не на ассемблерный код S>> Ну тогда во сколько? Или я на порядки ошибся?
EP>Речь о том что я не давал оценку во сколько, ты же зачем-то приписываешь мне свои выдумки
Ну прошу прощения что дал за тебя оценку в 2 раза.
Но при этом ьы говоришь, что С++ быстрее. За сколько раз я должен просить прощения?
S>>>> Но я тебе про тот алгоритм показал, что он будет короче на C# чем на С++. И ты с эти согласился. S>>https://rsdn.ru/forum/philosophy/6489092.1
S>> Вот здесь ты приводишь ссылку на AWK где говрится про тормознутость компараторов, которые как на простых типах тормозят в 2 раза за счет неилайнового вызова метода.
EP>1. Он там тоже не давал оценку во сколько они тормозят. EP>2. Даже если допустить что код C# с ними в два раза медленней чем код C# без них, то всё равно не понятно каким образом ты притянул C++ к этой оценке.
При том, что компараторы на простых типах медленне заинлайненых на С++. Я писал об этом, но решил это не писать. S>>>>А вот признать свои слова ошибочными по отношению выразительности C# это ты не можешь. EP>>>Сколько строк для min/max item в CodeJam? (до генерации) S>> А покажи внутренности std.
EP>Зачем?
А затем, что это расширение итераторов. S>>То есть еще это еще один довод о S>>"По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"? S>> То есть алгоритмически лучше зашивать все возможные варианты, нежели использовать динамическую компиляцию и Expression Trees ?
EP>К алгоритмам это не имеет практически никакого отношения. Скорее к метапрограмированию и поддержке EDSL времени компиляции.
А к чему?
и солнце б утром не вставало, когда бы не было меня
Re[164]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Что такое конкретно "ad-hoc" типы, он так и не пояснил. Как стало понятно из требуемого кода и вопроса про безликий tuple — речь шла про про реализуемость проекций, а конкретно синтезирование типов с нужными полями на месте (ad-hoc) — это в C++ есть НС>Ага, теоретически. А на практике, как только ситуация стала чуть посложнее самой примитивной — пришлось городить дикие извраты на макросах.
Какие именно макросы?
НС>Т.е., как обычно, теоретически изывраты есть, а на практике толку от них в районе нуля.
Даже если допустить справедливость высказывания что внутри реализации дикие извраты, то это не означает что конечному пользователю нужно знать эти технические детали. Точно также как ему не нужно знать например детали компиляции мэппинга внутри linq2db, и остальные десятки тысяч строк.
Re[162]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Serginio1, Вы писали:
S>>> Ты утверждаешь, что на C# нужно писать больше кода. EP>>Да, приводя конкретные примеры, написанные конкретными людьми с этого форума. S> Ну я могу написать кучу кода на С++ и буду по этому буду говорить, что С++ отстойный язык? S>И все С++ программисты пишут оптимальный код? S> На этом форуме иногда такого насмотришься
Я вот не думаю что авторы того кода неквалифицированны в C#, тем более там не один человек участвует. И исхожу из этого.
Если ты считаешь что они сделали какой-то ужас, то создай тему в соответствующем под-форуме с указанием на недостатки
S>>>
S>>> Отличия минимальные — auto, return и скобочки.
EP>>Лямбды лаконичнее — да, реализация алгоритма — нет. S> Если ты про замыкания, то там строится класс компилятором.
Я про синтаксис использования лямбд.
EP>>Непонятно зачем ты патаешься оправдать раздутую реализацию алгоритма (простейшего!) лямбдами, впрочем мне это уже надоело. S> Я тебе показал реализацию которая компактнее реализации на C#. Ты же сам согласился выше.
Какую конкретно реализацию?
S>>>>>>>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный. EP>>>>>>Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД". S>>>>> То есть С++ медленне? Тогда прошу прощения? EP>>>>С логикой беда? Я прошу привести пруфлинк на то что я говорил "быстрее в 2 раза", всё. S>>> Мне лень искать, значит C# быстрее? EP>>Нет, очевидно не значит. S> То есть C++ все же быстрее?
Из того что я не говорил "быстрее в 2 раза", не следует ни то что он медленнее, ни то что быстрее.
S>>>>>А вот признать свои слова ошибочными по отношению выразительности C# это ты не можешь. EP>>>>Сколько строк для min/max item в CodeJam? (до генерации) S>>> А покажи внутренности std. EP>>Зачем? S> А затем, что это расширение итераторов.
1. Этот код работает и без всякого STL, например с обычными массивами.
2. При чём здесь вообще итераторы которые реализованы в STL? Я разве где-то ссылался на код конкретных реализации IEnumerable?
S>>>То есть еще это еще один довод о S>>>"По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"? S>>> То есть алгоритмически лучше зашивать все возможные варианты, нежели использовать динамическую компиляцию и Expression Trees ? EP>>К алгоритмам это не имеет практически никакого отношения. Скорее к метапрограмированию и поддержке EDSL времени компиляции. S> А к чему?
Re[161]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>> Ты утверждаешь, что на C# нужно писать больше кода.
EP>Да, приводя конкретные примеры, написанные конкретными людьми с этого форума.
То есть, если я напишу на С++ алгоритм, который будет в 1000 раз больше этой C# версии, то С++ потеряет алгоритмическую выразительность ?
EP>Так я же и не говорю что она неоправданно раздута
Это принципиально невозможно или дело всего лишь в производительности ?
EP>>>Сколько строк для min/max item в CodeJam? (до генерации) S>> А покажи внутренности std.
EP>Зачем?
Известно зачем. Ты меряешь алгоритмическую выразительность в строчках кода написаной непойми кем либы для решения проблемы которая совсем не относится к алгоритму. Почему бы не посчитать и нам строчка в какйо нибудь либе в которую намутили решения самых разных проблем ?
Re[165]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>Т.е., как обычно, теоретически изывраты есть, а на практике толку от них в районе нуля.
EP>Даже если допустить справедливость высказывания что внутри реализации дикие извраты, то это не означает что конечному пользователю нужно знать эти технические детали. Точно также как ему не нужно знать например детали компиляции мэппинга внутри linq2db, и остальные десятки тысяч строк.
linq2db — не надо. А sqlpp — надо. Это полуфабрикат, он не является ни OR/M ни слоем абстракции, так утверждает его автор, поддерживает три с половиной БД. Следовательно — надо погружаться в дикие извраты, хотя бы для поддержки Оракла или DB2.
А для того, что бы реализовать нафантазированые тобой и alex_public бенефиты, навроде умной транcляции sql-sql, надо вообще потратить времени сравнимо с автором sqlpp
Re[163]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я вот не думаю что авторы того кода неквалифицированны в C#, тем более там не один человек участвует. И исхожу из этого. EP>Если ты считаешь что они сделали какой-то ужас, то создай тему в соответствующем под-форуме с указанием на недостатки
Ты ни разу не объяснил, почему оптимизацию под платформу надо записывать в алгоритмическую выразительность.
Я бы понял, если бы минимально работающая версия под C# требовала бы тысяч строк. Или ты намекаешь именно на этот вариант ?
Тогда напомни что за алгоритм, а то я уже забыл что там за фокусы.
Re[162]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ikemefula, Вы писали:
EP>>Да, приводя конкретные примеры, написанные конкретными людьми с этого форума. I>То есть, если я напишу на С++ алгоритм, который будет в 1000 раз больше этой C# версии
Десятки тысяч строк для поиска минимального элемента в последовательности? А я не удивлюсь, учитывая твои прежние алгоритмические достижения
S>> Ну я могу написать кучу кода на С++ и буду по этому буду говорить, что С++ отстойный язык? S>>И все С++ программисты пишут оптимальный код? S>> На этом форуме иногда такого насмотришься
EP>Я вот не думаю что авторы того кода неквалифицированны в C#, тем более там не один человек участвует. И исхожу из этого. EP>Если ты считаешь что они сделали какой-то ужас, то создай тему в соответствующем под-форуме с указанием на недостатки
Это ты считаешь. Мне все равно. Каждый сам решает, что и как. Но это не значит, что с точки зрения выразительности это хорошо.
И выоды надо делать на своих знаниях, а не о том, что кто то напел Паворотти.
Но вот делать выводы по этому никогда не стоит. Если, хочешь что то охаять изучи этот предмет. S>>>>
S>>>> Отличия минимальные — auto, return и скобочки.
// если это нуллабле тоvar СписокБезНулл=Список.Where(i =>i!=null);
// иначе
СписокБезНулл=Список;
///
//Если список пустой то вернуть default(TSource);то бишь нулл для нуллаблеvar МаксимальноеЗначение= СписокБезНулл.Max(i =>i.Value);
var рез=СписокБезНулл.Where(i =>i.Value==МаксимальноеЗначение).FirstOrDefault();
Они сделали оператор позволяющий использовать в одну строку как для Nullable так и для value типов.
Но ты так и не привел полный аналог на С++.
EP>Из того что я не говорил "быстрее в 2 раза", не следует ни то что он медленнее, ни то что быстрее.
Ты сам привел для аргумента недостака Сшарпа слова АВК о недостатков компараторов. И говорил на этом основании о недостатках платформы.
EP>1. Этот код работает и без всякого STL, например с обычными массивами. EP>2. При чём здесь вообще итераторы которые реализованы в STL? Я разве где-то ссылался на код конкретных реализации IEnumerable?
То есть итераторы не внутри СТЛ?
А вот ребята реализовали расширение для IEnumerable.
А я тебе могу скинуть реализации IEnumerable как на yield https://msdn.microsoft.com/ru-ru/library/9k7k7cf0.aspx
Здравствуйте, Ikemefula, Вы писали:
I>Ты ни разу не объяснил, почему оптимизацию под платформу надо записывать в алгоритмическую выразительность.
Потому что это реальный код, написанный из вполне практических соображений.
В отрыве от основной (практически единственной) платформы рассматривать смысла мало.
Даже в статьях по алгоритмам оценивается отображение на платформу, так как они работают не в сферическом вакууме.
I>Я бы понял, если бы минимально работающая версия под C# требовала бы тысяч строк. Или ты намекаешь именно на этот вариант ?
Нет, очевидно не на этот. Толку-то от минимально работающей если она не устраивает по разным параметрам?
На C++ минимально работающая и есть та которая реально используется, плюс может несколько десятков строк простых обёрток для Range-интерфейса.
I>Тогда напомни что за алгоритм, а то я уже забыл что там за фокусы.
Здравствуйте, Serginio1, Вы писали:
EP>>Я вот не думаю что авторы того кода неквалифицированны в C#, тем более там не один человек участвует. И исхожу из этого. EP>>Если ты считаешь что они сделали какой-то ужас, то создай тему в соответствующем под-форуме с указанием на недостатки S> Это ты считаешь. Мне все равно. Каждый сам решает, что и как. Но это не значит, что с точки зрения выразительности это хорошо.
Так о том и речь что плохо
EP>>Я про синтаксис использования лямбд. S> По мне так все сообразно функциональным языкам. Автоматический вывод типа.
И? Ты вообще не понимаешь о чём идёт речь? Я говорю что синтаксис лямбд лаконичней в C# — нет лишних скобок, return и auto.
EP>>>>Непонятно зачем ты патаешься оправдать раздутую реализацию алгоритма (простейшего!) лямбдами, впрочем мне это уже надоело. S>>> Я тебе показал реализацию которая компактнее реализации на C#. Ты же сам согласился выше. EP>>Какую конкретно реализацию? S> Хотошо. Напомню.https://rsdn.ru/forum/philosophy/6489023.1
Здравствуйте, Ikemefula, Вы писали:
НС>>>Т.е., как обычно, теоретически изывраты есть, а на практике толку от них в районе нуля. EP>>Даже если допустить справедливость высказывания что внутри реализации дикие извраты, то это не означает что конечному пользователю нужно знать эти технические детали. Точно также как ему не нужно знать например детали компиляции мэппинга внутри linq2db, и остальные десятки тысяч строк. I>linq2db — не надо. А sqlpp — надо. Это полуфабрикат, он не является ни OR/M ни слоем абстракции, так утверждает его автор, поддерживает три с половиной БД. Следовательно — надо погружаться в дикие извраты, хотя бы для поддержки Оракла или DB2.
1. В данном контексте речь идёт про проекции, а не про конкретно sqlpp11.
2. Даже если брать sqlpp11 с его проекциями, то отсутствие поддержки Oracle вообще параллельно тому получится ли у конечно пользователя использовать проекции на других базах. Это очередное передёргивание с твоей стороны
I>А для того, что бы реализовать нафантазированые тобой и alex_public бенефиты, навроде умной транcляции sql-sql, надо вообще потратить времени сравнимо с автором sqlpp
Где я говорил про трансляцию из sql в sql?
Как вообще наличие такой трансляции относится к использованию проекций пользователем?
Re[163]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Да, приводя конкретные примеры, написанные конкретными людьми с этого форума. I>>То есть, если я напишу на С++ алгоритм, который будет в 1000 раз больше этой C# версии
EP>Десятки тысяч строк для поиска минимального элемента в последовательности? А я не удивлюсь, учитывая твои прежние алгоритмические достижения
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Ты ни разу не объяснил, почему оптимизацию под платформу надо записывать в алгоритмическую выразительность.
EP>Потому что это реальный код, написанный из вполне практических соображений.
Следовательно, если я напишу на С++ тот же код из десяти тысяч строк, это и будет доказательством более худшей алгоритмической выразительности языка С++.
EP>Нет, очевидно не на этот. Толку-то от минимально работающей если она не устраивает по разным параметрам?
Что бы оценивать свойства компилятора отдельно от свойств платформу и все это отдельно от свойств языка.
Иначе получается какой то заговор — С++ лучше всех как по отдельности, так и разом, только на ём почему то мало кто пишет.
I>>Тогда напомни что за алгоритм, а то я уже забыл что там за фокусы. EP>Поиск минимального/максимального элемента последовательности — сотни строк плюс текстовая кодогенерация. Круто, да?
Нормально. И это никакая не выразительность. Это свойства компилятора и платформы.
Re[167]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>linq2db — не надо. А sqlpp — надо. Это полуфабрикат, он не является ни OR/M ни слоем абстракции, так утверждает его автор, поддерживает три с половиной БД. Следовательно — надо погружаться в дикие извраты, хотя бы для поддержки Оракла или DB2.
EP>1. В данном контексте речь идёт про проекции, а не про конкретно sqlpp11.
"Точно также как ему не нужно знать например детали компиляции мэппинга внутри linq2db, и остальные десятки тысяч строк"
Не надо знать — потому что Linq2Db все заявленое умеет и все нужные базы тоже умеет. А если вдруг он начнет ровно три с половиной базы поддерживать, то каждому юзеру придется полностью раздраконить не только маппинг, но и вообще всё.
EP>2. Даже если брать sqlpp11 с его проекциями, то отсутствие поддержки Oracle вообще параллельно тому получится ли у конечно пользователя использовать проекции на других базах. Это очередное передёргивание с твоей стороны
Вообще то либа на данный момент предполагает написание коннектора. Вот когда она обрастет провайдерами не хуже Linq2Db, вот тогда и будешь говорить "не надо погружаться".
I>>А для того, что бы реализовать нафантазированые тобой и alex_public бенефиты, навроде умной транcляции sql-sql, надо вообще потратить времени сравнимо с автором sqlpp
EP>Как вообще наличие такой трансляции относится к использованию проекций пользователем?
Когда пользователь с зоопарком разных БД захочет заявленых бенефитов, то я совсем не удивлюсь, если либу вдруг придется переписать
