Re[147]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.07.16 09:15
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Если использовать sqlpp11, то это будет выглядеть так:

_>
_>auto F=[](auto& q, optional<int> v) {if(v) q.where.add(Table.value==*v);};
_>


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


У тебя стало быть лямбда вызывается в компайл-тайм ? Эта лямбда, на секундочку, патчит запрос. Насколько качественно sqlpp работает с деревьями выражений, не ясно. Быстро не значит качественно.

>В отличие от Linq. )


Как работает linq — мы знаем, он может полностью изменить структуру запроса и решает вагон известных проблем. Чего и наблюдаем в тех примерах, которые ты продолжаешь игнорировать. И поддержка всех основных БД.
А вот в sqlpp это доступно только теоретически — если кто нибудь когда нибудь напишет супер-умный провайдер. С учетом трех с половиной бд — даже не смешно.
Re[124]: Тормознутость и кривость linq
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.07.16 09:18
Оценка:
Здравствуйте, alex_public, Вы писали:

IT>>>Добавил, начало скакать туда сюда, пришлось увеличить количество итераций и нивелировать порядок выполнения. Получилось так:

IT>>>
IT>>>LINQ: 1000000 in 00:00:56.0547832
IT>>>ADO:  1000000 in 00:00:49.1683344
IT>>>SQL:  1000000 in 00:00:48.4624714
IT>>>

A>>Я правильно подозреваю, в тесте все данные лежали в кэше на субд сервере? В реальности будут чтения с дисков, так что подобные сравнения — это замеры у кого ноль длиннее.

_>Если ты сделал свои выводы на основание предположения, что 1000000 — это число запросов в тесте, то твои выводы не верны вследствие не верности изначального предположения. )


Ты наверное не понял, но IT ошибся в твою пользу Влияние сети и бд в этих замерах было минимальным !
Re[144]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 13:06
Оценка:
Здравствуйте, artelk, Вы писали:

EP>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

A>Не напрягает, что SQL текстовой?

Кстати, подчеркну, там не только результирующий запрос идентичен, но и мэппинг результата.
Re[70]: Тормознутость и кривость linq
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 13:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Дайте паттерн матчинг в C# и отжать всё лишнее из генерируемого SQL вообще будет не проблема.


В C++ кстати есть PM для expression templates, причём аж в C++1998. То есть можно отматчить искомый фрагмент дерева запроса, и провести оптимизацию, или например выдать ошибку.
Я уже показывал
Автор: Evgeny.Panasyuk
Дата: 24.04.15
пример на эту тему:
template<typename _>
struct CheckGrammar
<
    Pipeline<Pipeline<Pipeline<_, Where>, Select>, Where> // Pattern matching
>
{
    using type = typename _::error_in_grammar_after;
};
Re[145]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.07.16 13:25
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

A>>Не напрягает, что SQL текстовой?

EP>Кстати, подчеркну, там не только результирующий запрос идентичен, но и мэппинг результата.


Мне конечно нравятся ваши теоретические споры. Но реалии таковы, что Linq to SQL использует огромное количество людей и не парятся о "тормознутости".
Тем же 1С кам наплевать на тормознутость 1С. Так как большинство задач упирается в БД. Но нужно писать тонны кода.
А сколько народу пишет на С++ для работы с БД?
и солнце б утром не вставало, когда бы не было меня
Re[148]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 13:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Так ты определись, или восторг по причине полезности, или по причине очередной победы над языком.

I>Если восторг про полезность, поделись выкладками, из которых следует эта полезность.

Ещё раз, внимательно:

EP>Как я уже неоднократно заявлял, с СУБД не работаю — не встречаются такие задачи, поэтому для меня вообще вся эта тема не имеет особой практической ценности.


I>Zero Overhead тянет только на победу над языком.


Полученный Zero Overhead — это практические подтверждение озвученным ранее тезисам в этой/предыдущей теме.
Re[146]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 13:32
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

A>>>Не напрягает, что SQL текстовой?
EP>>Кстати, подчеркну, там не только результирующий запрос идентичен, но и мэппинг результата.
S>Мне конечно нравятся ваши теоретические споры.

Почему теоретические? Вполне конкретный пример жеж.

S>Но реалии таковы, что Linq to SQL использует огромное количество людей и не парятся о "тормознутости".

S>Тем же 1С кам наплевать на тормознутость 1С. Так как большинство задач упирается в БД. Но нужно писать тонны кода.

А я разве говорил что кто-то из пользователей жалуется на "тормознутость" Linq? Или что 1С не практичен по причине "тормознутости"?
Цель твоего сообщения в очередной раз от меня ускользает

S> А сколько народу пишет на С++ для работы с БД?


Без понятия, лично у меня нет таких задач
Re[135]: Тормознутость и кривость linq
От: IT Россия linq2db.com
Дата: 08.07.16 13:33
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>P.S. Могу дать ссылки на соответствующие сообщения в данной темке.


Не надо. Восьмой раз по кругу одно и тоже. У меня уже голова закружилась.
Если нам не помогут, то мы тоже никого не пощадим.
Re[147]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.07.16 13:51
Оценка: 1 (1)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

A>>>>Не напрягает, что SQL текстовой?
EP>>>Кстати, подчеркну, там не только результирующий запрос идентичен, но и мэппинг результата.
S>>Мне конечно нравятся ваши теоретические споры.

EP>Почему теоретические? Вполне конкретный пример жеж.


S>>Но реалии таковы, что Linq to SQL использует огромное количество людей и не парятся о "тормознутости".

S>>Тем же 1С кам наплевать на тормознутость 1С. Так как большинство задач упирается в БД. Но нужно писать тонны кода.

EP>А я разве говорил что кто-то из пользователей жалуется на "тормознутость" Linq? Или что 1С не практичен по причине "тормознутости"?

EP>Цель твоего сообщения в очередной раз от меня ускользает
Да к тому, что никого аспект "тормознутости" не волнует. А развели на 45 страниц болтовни.

S>> А сколько народу пишет на С++ для работы с БД?


EP>Без понятия, лично у меня нет таких задач

Я думаю, что и у большинства С++. За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.
Я честно изучаю С++, многое понятно, но на твои примеры посмотришь, и думаешь если мои примеры на C# 1С ники не понимают, то про изыски С++ им и подавно не понять.
Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.
При этом я приводил пример что вакансий 1С ников больше чем С++ и Питон вместе взятых
и солнце б утром не вставало, когда бы не было меня
Re[148]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 14:12
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Да к тому, что никого аспект "тормознутости" не волнует.


Мой основной тезис о том что возможен статический EDSL запросов с нулевым или около того abstrasction penalty. Причём безотносительно конкретного языка — это может быть C++/D/Rust/Nemerle/etc.
Если бы против этого тезиса не было возражений (типа отсутствия И необходимости "ad-hoc типов", или вообще высказываний о "невозможности"), то я бы и не приводил примеры.

S>А развели на 45 страниц болтовни.


На что хочу на то и трачу личное время. Не нравиться — не читай

S>>> А сколько народу пишет на С++ для работы с БД?

EP>>Без понятия, лично у меня нет таких задач
S> Я думаю, что и у большинства С++. За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

Где я это говорил? Уже заколебало ваше враньё

S>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.


Ты о чём? Какие тонны кода?

S> При этом я приводил пример что вакансий 1С ников больше чем С++ и Питон вместе взятых


Вакансий продавцов ещё больше, И ЧО?
Re[149]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.07.16 14:17
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>> Да к тому, что никого аспект "тормознутости" не волнует.


EP>Мой основной тезис о том что возможен статический EDSL запросов с нулевым или около того abstrasction penalty. Причём безотносительно конкретного языка — это может быть C++/D/Rust/Nemerle/etc.

EP>Если бы против этого тезиса не было возражений (типа отсутствия И необходимости "ad-hoc типов", или вообще высказываний о "невозможности"), то я бы и не приводил примеры.
Он не нужен, так как основная масса запросов динамическая. А статические запросы компилируются и кэшируются в рантайме.
S>>А развели на 45 страниц болтовни.

EP>На что хочу на то и трачу личное время. Не нравиться — не читай

Во во ..

S>>>> А сколько народу пишет на С++ для работы с БД?

EP>>>Без понятия, лично у меня нет таких задач
S>> Я думаю, что и у большинства С++. За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

EP>Где я это говорил? Уже заколебало ваше враньё

Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.

S>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.


EP>Ты о чём? Какие тонны кода?

Я программист с БД и пишу тонны кода. Я знаю о чем говорю в отличии от

S>> При этом я приводил пример что вакансий 1С ников больше чем С++ и Питон вместе взятых


EP>Вакансий продавцов ещё больше, И ЧО?

А то, кто будет программировать БД на С++? Продавцы?
и солнце б утром не вставало, когда бы не было меня
Re[150]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 14:26
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Он не нужен, так как основная масса запросов динамическая.


Иди спорь в эту ветку
Автор: Ночной Смотрящий
Дата: 25.05.16
.

S>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

EP>>Где я это говорил? Уже заколебало ваше враньё
S> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.

Давай пруф-линки.

S>>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.

EP>>Ты о чём? Какие тонны кода?
S> Я программист с БД и пишу тонны кода. Я знаю о чем говорю в отличии от

Ещё раз, не увиливай, ответь на конкретный вопрос. Почему ты говоришь что на C++ будет много лишнего кода при обращении к БД.

S>>> При этом я приводил пример что вакансий 1С ников больше чем С++ и Питон вместе взятых

EP>>Вакансий продавцов ещё больше, И ЧО?
S> А то, кто будет программировать БД на С++? Продавцы?

Будет программировать тот кому это нужно. Я не предлагал пересаживать ни 1С-ников за C++, ни продавцов
Re[149]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.07.16 16:21
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Ещё раз, внимательно:

EP>

EP>>Как я уже неоднократно заявлял, с СУБД не работаю — не встречаются такие задачи, поэтому для меня вообще вся эта тема не имеет особой практической ценности.

I>>Zero Overhead тянет только на победу над языком.
EP>Полученный Zero Overhead — это практические подтверждение озвученным ранее тезисам в этой/предыдущей теме.

"без особой практической ценности" @ Evgeny.Panasyuk
Re[149]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.07.16 16:24
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Мой основной тезис о том что возможен статический EDSL запросов с нулевым или около того abstrasction penalty. Причём безотносительно конкретного языка — это может быть C++/D/Rust/Nemerle/etc.

EP>Если бы против этого тезиса не было возражений (типа отсутствия И необходимости "ad-hoc типов", или вообще высказываний о "невозможности"), то я бы и не приводил примеры.

Успокойся, именно с этим никто не спорит. Если запрос статический, его перекладывают или на компилер,или на препроцессор. В С# для этого есть всё что нужно.
Re[150]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 16:26
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>Ещё раз, внимательно:

EP>>

EP>>>Как я уже неоднократно заявлял, с СУБД не работаю — не встречаются такие задачи, поэтому для меня вообще вся эта тема не имеет особой практической ценности.

I>>>Zero Overhead тянет только на победу над языком.
EP>>Полученный Zero Overhead — это практические подтверждение озвученным ранее тезисам в этой/предыдущей теме.
I>"без особой практической ценности" @ Evgeny.Panasyuk

Лично для меня да, по крайней мере прямо сейчас. Что тебя удивляет?
Re[151]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.07.16 16:27
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>Он не нужен, так как основная масса запросов динамическая.


EP>Иди спорь в эту ветку
Автор: Ночной Смотрящий
Дата: 25.05.16
.


S>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

EP>>>Где я это говорил? Уже заколебало ваше враньё
S>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.

EP>Давай пруф-линки.

Да ты наехал на CodeJam и сказал, что все это из-за проблем платформы. Тебе привести пруфлинки?
S>>>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.
EP>>>Ты о чём? Какие тонны кода?
S>> Я программист с БД и пишу тонны кода. Я знаю о чем говорю в отличии от

EP>Ещё раз, не увиливай, ответь на конкретный вопрос. Почему ты говоришь что на C++ будет много лишнего кода при обращении к БД.

Я не говорю, что будет много лишнего кода. Я говорю о том, что его значительно сложнее писать, чем на 1С или Linq

S>>>> При этом я приводил пример что вакансий 1С ников больше чем С++ и Питон вместе взятых

EP>>>Вакансий продавцов ещё больше, И ЧО?
S>> А то, кто будет программировать БД на С++? Продавцы?

EP>Будет программировать тот кому это нужно. Я не предлагал пересаживать ни 1С-ников за C++, ни продавцов

Тогда о чем спор в этой ветке, если работой с БД занимаются в основном люди работающие на интерпретаторе.
и солнце б утром не вставало, когда бы не было меня
Re[150]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 16:37
Оценка: -2
Здравствуйте, Ikemefula, Вы писали:

EP>>Мой основной тезис о том что возможен статический EDSL запросов с нулевым или около того abstrasction penalty. Причём безотносительно конкретного языка — это может быть C++/D/Rust/Nemerle/etc.

EP>>Если бы против этого тезиса не было возражений (типа отсутствия И необходимости "ad-hoc типов", или вообще высказываний о "невозможности"), то я бы и не приводил примеры.
I>Успокойся,

Я спокоен.

I>именно с этим никто не спорит.


Вообще-то спорят Например ищи выше по ключевому слову "ad-hoc".

I>Если запрос статический, его перекладывают или на компилер,или на препроцессор.


А как же "главный козырь LINQ — type safety"?

I>В С# для этого есть всё что нужно.


Да в общем-то для перекладывания на препроцессор особо ничего и не нужно Но это очевидно намного менее удобно чем EDSL.
Re[152]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 16:47
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

EP>>>>Где я это говорил? Уже заколебало ваше враньё
S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.
EP>>Давай пруф-линки.
S> Да ты наехал на CodeJam и сказал, что все это из-за проблем платформы. Тебе привести пруфлинки?

Приведи пруфлинки вот на это:

1. S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

2. S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.


S>>>>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.

EP>>>>Ты о чём? Какие тонны кода?
S>>> Я программист с БД и пишу тонны кода. Я знаю о чем говорю в отличии от
EP>>Ещё раз, не увиливай, ответь на конкретный вопрос. Почему ты говоришь что на C++ будет много лишнего кода при обращении к БД.
S> Я не говорю, что будет много лишнего кода. Я говорю о том, что его значительно сложнее писать, чем на 1С или Linq

Расшифруй вот это:

S>>>>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.


S>>> А то, кто будет программировать БД на С++? Продавцы?

EP>>Будет программировать тот кому это нужно. Я не предлагал пересаживать ни 1С-ников за C++, ни продавцов
S> Тогда о чем спор в этой ветке

Читай ветку, пересказывать всё заново не собираюсь.
Re[153]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.07.16 17:39
Оценка: 3 (1) :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

EP>>>>>Где я это говорил? Уже заколебало ваше враньё
S>>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.
EP>>>Давай пруф-линки.
S>> Да ты наехал на CodeJam и сказал, что все это из-за проблем платформы. Тебе привести пруфлинки?

EP>Приведи пруфлинки вот на это:

EP>

EP>1. S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.

EP>2. S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.


https://rsdn.ru/forum/philosophy/6486253.1
Автор: Evgeny.Panasyuk
Дата: 29.06.16




По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
Для сравнения C#, свежий пример
— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.


S>>>>>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.

EP>>>>>Ты о чём? Какие тонны кода?
S>>>> Я программист с БД и пишу тонны кода. Я знаю о чем говорю в отличии от
EP>>>Ещё раз, не увиливай, ответь на конкретный вопрос. Почему ты говоришь что на C++ будет много лишнего кода при обращении к БД.
S>> Я не говорю, что будет много лишнего кода. Я говорю о том, что его значительно сложнее писать, чем на 1С или Linq

EP>Расшифруй вот это:

EP>

S>>>>>>Вопрос кто будет работать на C++ с БД? А там нужно писать тонны кода, если конечно это не специализированные БД с до 10 табличками.


Где ты здесь увидел лишнего. Я говорю о том, что работая с БД нужно писать много кода, и во главе угла стоит не скорость работы программы, а скорость разработки. Ну это во же вам не понять. Вы на компиляцию тратите кучу времени.

S>>>> А то, кто будет программировать БД на С++? Продавцы?

EP>>>Будет программировать тот кому это нужно. Я не предлагал пересаживать ни 1С-ников за C++, ни продавцов
S>> Тогда о чем спор в этой ветке

EP>Читай ветку, пересказывать всё заново не собираюсь.

То есть никакого отношения к названию "Тормознутость и кривость linq" эта ветка никакого отношения не имееет?
Предлагаю сделать ответвление и назвать "Теоретическая красота и скорость C++ при работе с БД
и солнце б утром не вставало, когда бы не было меня
Re[154]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
От: Evgeny.Panasyuk Россия  
Дата: 08.07.16 18:41
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Приведи пруфлинки вот на это:

EP>>

EP>>1. S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.
EP>>2. S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.

S> https://rsdn.ru/forum/philosophy/6486253.1
Автор: Evgeny.Panasyuk
Дата: 29.06.16

S>

EP>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
EP>Для сравнения C#, свежий пример
EP>— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.


И где тут хотя бы что-то из подчёркнутого? Хотя бы отдалённо напоминающее? Споришь с собственным воображением?

S>>> Тогда о чем спор в этой ветке

EP>>Читай ветку, пересказывать всё заново не собираюсь.
S> То есть никакого отношения к названию "Тормознутость и кривость linq" эта ветка никакого отношения не имееет?

Не я ветку называл.

S>Предлагаю сделать ответвление и назвать "Теоретическая красота и скорость C++ при работе с БД


Почему теоретическая-то? Вполне практическая — смотри ассемблерный вывод. Да и вообще C++ тут лишь как пример одного из языков где это реализуемо, а ты прицепился именно к нему
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.