Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Приведи пруфлинки вот на это: EP>>>
EP>>>1. S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.
EP>>>2. S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.
EP>>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
EP>>Для сравнения C#, свежий пример
EP>>— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
EP>И где тут хотя бы что-то из подчёркнутого? Хотя бы отдалённо напоминающее? Споришь с собственным воображением?
Достаточно. То есть С++ значительно лаконичнее линка, ибо это пишут монстры от Сшарп. Твои слова.
А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный. Или я что то придумал?
И тебе наплевать, что реально на линке это можно написать компактнее чем на С++.
S>>>> Тогда о чем спор в этой ветке EP>>>Читай ветку, пересказывать всё заново не собираюсь. S>> То есть никакого отношения к названию "Тормознутость и кривость linq" эта ветка никакого отношения не имееет?
EP>Не я ветку называл.
S>>Предлагаю сделать ответвление и назвать "Теоретическая красота и скорость C++ при работе с БД
EP>Почему теоретическая-то? Вполне практическая — смотри ассемблерный вывод. Да и вообще C++ тут лишь как пример одного из языков где это реализуемо, а ты прицепился именно к нему
Ну вот еще раз подчеркиваю. Только вот в реалиях используется Линк и 1С. И никому не нужено смотреть ассемблерный код. Многие о нем вообще не знают. Да и я давно забыл.
Ваши практическое применение СкулСиПиПи вами так и не показано. Причем оба спорщика от С++ не работают с базами данных. Где же тут практическое. Это как анекдот про неуловимого Джо.
и солнце б утром не вставало, когда бы не было меня
Re[156]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
Здравствуйте, Serginio1, Вы писали:
EP>>>>Приведи пруфлинки вот на это: EP>>>>
EP>>>>1. S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.
EP>>>>2. S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.
EP>>>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
EP>>>Для сравнения C#, свежий пример
EP>>>— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
EP>>И где тут хотя бы что-то из подчёркнутого? Хотя бы отдалённо напоминающее? Споришь с собственным воображением? S> Достаточно. То есть С++ значительно лаконичнее линка, ибо это пишут монстры от Сшарп. Твои слова.
Причём тут LINQ вообще? Речь шла про реализацию алгоритма поиска минимального элемента
S>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный.
Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД".
S>Или я что то придумал?
Конечно, придумал и сам споришь с придуманным. Только не надо меня в этот спор впутывать.
S>>>Предлагаю сделать ответвление и назвать "Теоретическая красота и скорость C++ при работе с БД S> Ваши практическое применение СкулСиПиПи вами так и не показано.
А я где-то говорил что буду показывать это? Ты может ещё "голоса" слышишь, а?
Re[157]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>Приведи пруфлинки вот на это: EP>>>>>
EP>>>>>1. S>>>>>За то, говорить, что C++ лучший язык для работы с БД вы горазды всегда.
EP>>>>>2. S>>> Угу при этом ты же говорил, что С++ не уступает Linq, зато быстрее в 2 раза.
EP>>>>По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех.
EP>>>>Для сравнения C#, свежий пример
EP>>>>— на C++ десять строк (+ может несколько wrapper'ов, это максимум десятки строк), на C# — несколько сотен строк кода (è1 + è2) причём включая кодогенетратор, который генерирует èнесколько тысяч строк, а алгоритм-то совсем пустяковый.
EP>>>И где тут хотя бы что-то из подчёркнутого? Хотя бы отдалённо напоминающее? Споришь с собственным воображением? S>> Достаточно. То есть С++ значительно лаконичнее линка, ибо это пишут монстры от Сшарп. Твои слова.
EP>Причём тут LINQ вообще? Речь шла про реализацию алгоритма поиска минимального элемента
Во во. Там как раз было расширение для Linq . Казалось бы причем тут Linq?
S>>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный.
EP>Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД".
То есть С++ медленне? Тогда прошу прощения? Но С++ же "По алгоритмической выразительности среди мэйнстрима C++ сейчас впереди всех"
И приводишь пример sqlcpp. Или это не мои слова? При этом ты приводишь ассемблерный код? Дать пруф?
S>>Или я что то придумал?
EP>Конечно, придумал и сам споришь с придуманным. Только не надо меня в этот спор впутывать.
Ну конечно. Я в отличие от тебя признаю свои ошибки.
Но я тебе про тот алгоритм показал, что он будет короче на C# чем на С++. И ты с эти согласился.
А вот признать свои слова ошибочными по отношению выразительности C# это ты не можешь.
S>>>>Предлагаю сделать ответвление и назвать "Теоретическая красота и скорость C++ при работе с БД S>> Ваши практическое применение СкулСиПиПи вами так и не показано.
EP>А я где-то говорил что буду показывать это? Ты может ещё "голоса" слышишь, а?
Тогда при чем тут "практическое". Пока только "Теоретическая красота и скорость C++ при работе с БД"
и солнце б утром не вставало, когда бы не было меня
EP>>>>Как я уже неоднократно заявлял, с СУБД не работаю — не встречаются такие задачи, поэтому для меня вообще вся эта тема не имеет особой практической ценности.
I>>>>Zero Overhead тянет только на победу над языком. EP>>>Полученный Zero Overhead — это практические подтверждение озвученным ранее тезисам в этой/предыдущей теме. I>>"без особой практической ценности" @ Evgeny.Panasyuk
EP>Лично для меня да, по крайней мере прямо сейчас. Что тебя удивляет?
Прежде всего это объясняет, почему ты не слышишь аргументы. Собственно, это и ответ, как поступать с твоими аргументами. Удивляет, почему ты начинаешь обижаться.
Re[151]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>именно с этим никто не спорит.
EP>Вообще-то спорят Например ищи выше по ключевому слову "ad-hoc".
Вообще все, кроме тебя и alex_public, обсуждают вопрос имеющий практическую ценность, а ты суёте zero overhead к каждому вопросу.
I>>Если запрос статический, его перекладывают или на компилер,или на препроцессор. EP>А как же "главный козырь LINQ — type safety"?
Смотреть нужно с тз практической целесообразности, а не так, как у тебя "я за Zero Overhead а практичность мне по барабану"
I>>В С# для этого есть всё что нужно. EP>Да в общем-то для перекладывания на препроцессор особо ничего и не нужно Но это очевидно намного менее удобно чем EDSL.
Опять двадцать пять. Ты про zero overhead или практический интерес ? Если второе, то надо вспомнить, что препроцессоры всякие требуют умения писать тот же самый типичный код, что и везде — циклы, ветвления и тд
Темплейты С++ требуют писать совсем другой код, который много сложнее и понятен только малой части плюсовиков.
У нас очевидно разное понимание удобства. Ты под удобством понимаешь себя и тех, кто легко понимают темплейты. А я под удобством понимаю вообще весь контингент.
Re[152]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
EP>>>>>Как я уже неоднократно заявлял, с СУБД не работаю — не встречаются такие задачи, поэтому для меня вообще вся эта тема не имеет особой практической ценности.
I>>>>>Zero Overhead тянет только на победу над языком. EP>>>>Полученный Zero Overhead — это практические подтверждение озвученным ранее тезисам в этой/предыдущей теме. I>>>"без особой практической ценности" @ Evgeny.Panasyuk EP>>Лично для меня да, по крайней мере прямо сейчас. Что тебя удивляет? I>Прежде всего это объясняет, почему ты не слышишь аргументы.
Какие аргументы? Давай конкретный пример.
I>Собственно, это и ответ, как поступать
И как же?
I>с твоими аргументами.
Какими именно?
I>Удивляет, почему ты начинаешь обижаться.
На что вообще обижаться? На то что оппоненты скатились в наглое враньё? Так это их проблемы
Re[155]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>>Предлагаю сделать ответвление и назвать "Теоретическая красота и скорость C++ при работе с БД
EP>Почему теоретическая-то? Вполне практическая — смотри ассемблерный вывод. Да и вообще C++ тут лишь как пример одного из языков где это реализуемо, а ты прицепился именно к нему
Практическая — это когда можно на практике попробовать заявленые бенефиты. С linq все в порядке — подключил, написал сотню строк кода, сделал замеры.
То есть, практическая ценность — это время, пространтсво, деньги. DB EDSL в эту практику никак не вписывается. "Попробовать" оракл и db2 с заявлеными alex_public фичами вполне возможно — всего то пару лет работы. Подумаешь, мелочовочка
С С++ по факту только утверждения "всё реализуемо" а на деле у sqlpp ажно три с половиной БД, при чем, _без_ заявленых бенефитов — чудеса трансформации AST.
Все что можно на практике — убедиться, что ни sqlpp, ни его коннекторы не делают никакой трансформации.
P.S. Про "реализуемо" никто не спорит. За 10 лет до твоего пришествия сюда на этом форуме люди делились и парсером на темплейтах, и движком регекспов, и вычислением выражений.
Re[153]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>"без особой практической ценности" @ Evgeny.Panasyuk EP>>>Лично для меня да, по крайней мере прямо сейчас. Что тебя удивляет? I>>Прежде всего это объясняет, почему ты не слышишь аргументы.
EP>Какие аргументы? Давай конкретный пример.
Я уже привел пример с gangjustas. Ты не хочешь услышать чего он тебе говорит. У него интерес практический — вынь да положь. А у тебя теоретический: "всё реализуемо, смотри, вот EDSL !!!!!1111"
I>>Удивляет, почему ты начинаешь обижаться.
EP>На что вообще обижаться? На то что оппоненты скатились в наглое враньё? Так это их проблемы
Вот-вот. Такие обвинения и есть основной симптом обиды.
Re[152]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
Здравствуйте, Ikemefula, Вы писали:
I>>>именно с этим никто не спорит. EP>>Вообще-то спорят Например ищи выше по ключевому слову "ad-hoc". I>Вообще все, кроме тебя и alex_public, обсуждают вопрос имеющий практическую ценность, а ты суёте zero overhead к каждому вопросу.
Ты вообще не читаешь на что отвечаешь? Причём тут zero overhead и "ad-hoc типы"? Это может быть как zero, так и не zero.
I>>>Если запрос статический, его перекладывают или на компилер,или на препроцессор. EP>>А как же "главный козырь LINQ — type safety"? I>Смотреть нужно с тз практической целесообразности, а не так, как у тебя "я за Zero Overhead а практичность мне по барабану"
Ты на вопрос ответь.
I>>>В С# для этого есть всё что нужно. EP>>Да в общем-то для перекладывания на препроцессор особо ничего и не нужно Но это очевидно намного менее удобно чем EDSL. I>Опять двадцать пять. Ты про zero overhead или практический интерес ?
Я про то, что для использования препроцессора, каких-то особенных фич от языка не нужно. Ты же улетел в какие-то пространные рассуждения, к этой теме не относящиеся.
I>Если второе, то надо вспомнить, что препроцессоры всякие требуют умения писать тот же самый типичный код, что и везде — циклы, ветвления и тд I>Темплейты С++ требуют писать совсем другой код, который много сложнее и понятен только малой части плюсовиков.
А я не предлагаю писать конечному пользователю метапрограммы. Точно также как и пользователь linq2db не обязан ковыряться в его внутренностях.
Ты например не понял
код linq2db, тем не менее это не означает что ты не умеешь его использовать. Также например и с sqlpp11 — пользователь не обязан знать всех техники используемые при его реализации.
Re[156]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>именно с этим никто не спорит. EP>>>Вообще-то спорят Например ищи выше по ключевому слову "ad-hoc". I>>Вообще все, кроме тебя и alex_public, обсуждают вопрос имеющий практическую ценность, а ты суёте zero overhead к каждому вопросу. EP>Ты вообще не читаешь на что отвечаешь? Причём тут zero overhead и "ad-hoc типы"? Это может быть как zero, так и не zero.
zero overhead в моём словаре есть алиас для 'не имеющий практической ценности'
EP>>>А как же "главный козырь LINQ — type safety"? I>>Смотреть нужно с тз практической целесообразности, а не так, как у тебя "я за Zero Overhead а практичность мне по барабану" EP>Ты на вопрос ответь.
Все в порядке — в полный рост. Полная поддержка средств разработки, от компилятора до ИДЕ.
EP>Я про то, что для использования препроцессора, каких-то особенных фич от языка не нужно.
Правильно, не нужно. Более того, это вредит практической ценности. В С# как раз и нет никаких особенных фич.
I>>Если второе, то надо вспомнить, что препроцессоры всякие требуют умения писать тот же самый типичный код, что и везде — циклы, ветвления и тд I>>Темплейты С++ требуют писать совсем другой код, который много сложнее и понятен только малой части плюсовиков.
EP>А я не предлагаю писать конечному пользователю метапрограммы. Точно также как и пользователь linq2db не обязан ковыряться в его внутренностях.
Ну раз не предлагаешь, то linq2db уже победил — его практическая ценность доступна сходу искаропки. sqlpp требует N-человеколет на реализацию всех нужных коннекторов.
EP>Ты например не понял
код linq2db, тем не менее это не означает что ты не умеешь его использовать. Также например и с sqlpp11 — пользователь не обязан знать всех техники используемые при его реализации.
В sqlpp по факту надо писать свой коннектор. Опаньки ! А linq2db от этого как раз избавляет.
Re[157]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>P.S. Про "реализуемо" никто не спорит
EP>Вообще-то спорят, и не надо говорить за всех. Ещё раз, смотри конкретный пример про ad-hoc типы.
На тот момент alex_public презентовал sqlpp как либу для умной склейки строк. Он нигде не говорил, например, про то, что она работает унутре с SQL AST и подобными фокусами. Собственно именно тогда и появились все такие аргументы.
Собтсвенно, это ожидаемо, потому что шаблоны С++ непонятны даже большей части плюсовиков, не говоря о людях, которые ушли с него 10-15 лет назад.
Собтсвенно именно озвучивание этого факта, SQL AST, и сняло бОльшую часть вопросов. Зато дало новые
Re[158]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Ikemefula, Вы писали:
I>>>P.S. Про "реализуемо" никто не спорит EP>>Вообще-то спорят, и не надо говорить за всех. Ещё раз, смотри конкретный пример про ad-hoc типы. I>На тот момент alex_public презентовал sqlpp как либу для умной склейки строк. Он нигде не говорил, например, про то, что она работает унутре с SQL AST и подобными фокусами. Собственно именно тогда и появились все такие аргументы. I>Собтсвенно, это ожидаемо, потому что шаблоны С++ непонятны даже большей части плюсовиков, не говоря о людях, которые ушли с него 10-15 лет назад. I>Собтсвенно именно озвучивание этого факта, SQL AST, и сняло бОльшую часть вопросов. Зато дало новые
Вообще-то поддержка проекций/"ad-hoc типов" ортогональна тому что у нас за DSL — будь-то SQL AST, либо что-то LINQ'оподбное.
Так что озвучивание факта SQL AST в контексте "ad-hoc типов" ничего не меняет
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Собтсвенно именно озвучивание этого факта, SQL AST, и сняло бОльшую часть вопросов. Зато дало новые
EP>Вообще-то поддержка проекций/"ad-hoc типов" ортогональна тому что у нас за DSL — будь-то SQL AST, либо что-то LINQ'оподбное. EP>Так что озвучивание факта SQL AST в контексте "ad-hoc типов" ничего не меняет
Table вообще говоря встроеный тип в этом SQL AST. Именно за счет этого и поддерживаются ad-hoc типы.
Я не в курсе, как это правильно называть, так что можешь трактовать как угодно.
Возьми паузу — alex_public три месяца вводил людей в заблуждение, не мог рассказать внятно, что же за либу он презентует.
Аргумент про ad-hoc появился именно тогда, когда все думали что речь про либу склейки строк.
Здравствуйте, Ikemefula, Вы писали:
I>Возьми паузу — alex_public три месяца вводил людей в заблуждение, не мог рассказать внятно, что же за либу он презентует. I>Аргумент про ad-hoc появился именно тогда, когда все думали что речь про либу склейки строк.
Да не надо передёргивать что все не о том думали, все ходы записаны. Речь конкретна была про реализуемость
_>>>>Примера sql кода, ради написание которого на С++ по твоим словам "приходится вставать раком". "ad-hoc типы" — это у нас уже такой sql код? )
НС>>>
_>>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком".
НС>На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень?
Но ты конечно же можешь дальше петь песни что I>Про "реализуемо" никто не спорит, и прочие чудеса гимнастики а-ля I>Теоретически — не может. Гипотетически — может
Re[161]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Аргумент про ad-hoc появился именно тогда, когда все думали что речь про либу склейки строк.
EP>Да не надо передёргивать что все не о том думали, все ходы записаны. Речь конкретна была про реализуемость
Про наличие в С++ ad-hoc типов !!!
Цитирую
Дело в том что в С++ тебе приходится вставать раком, чтобы описать простейщие для SQL конструкции. Тебя не случайно постоянно тыкают, как котенка, в проекции. Нет в С++ ad-hoc типов. А в SQL в основном они есть.
Теперь цитирую alex_public "...умеет такое (правда ценой диких извратов внутри библиотеки," — немного про другое, но это мнение про сам движок.
На мой взгляд, "вставать раком" == "дикие извраты"
EP>
_>>>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком".
НС>>На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень?
Алё, ты видишь, что НС задал вопрос ?
Теперь на секундочку — каким чудом обеспечивается точная типизация этого фокуса с ad-hoc типами ? Отвечай прямо, перечисляя все языковые фичи необходимые для этого. Щас выясним, нужны ли "дикие извраты" @ alex_public для реализации ad-hoc типов.
Re[159]: [БД] Теоретическая красота и скорость C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Собтсвенно именно озвучивание этого факта, SQL AST, и сняло бОльшую часть вопросов. Зато дало новые
EP>Вообще-то поддержка проекций/"ad-hoc типов" ортогональна тому что у нас за DSL — будь-то SQL AST, либо что-то LINQ'оподбное.
Не надо вилять.
В языке эти типы отсутствуют ?
Значит ты создаёшь их сам.
Либа работает на основе AST ?
Значит сюда будет встроена работа с такими типами.
Вот и есть то само вставание раком, или, в терминологии alex_public "дикие извраты"
Здравствуйте, Ikemefula, Вы писали:
I>>>Аргумент про ad-hoc появился именно тогда, когда все думали что речь про либу склейки строк. EP>>Да не надо передёргивать что все не о том думали, все ходы записаны. Речь конкретна была про реализуемость I>Про наличие в С++ ad-hoc типов !!!
Что такое конкретно "ad-hoc" типы, он так и не пояснил. Как стало понятно из требуемого кода и вопроса про безликий tuple — речь шла про про реализуемость проекций, а конкретно синтезирование типов с нужными полями на месте (ad-hoc) — это в C++ есть
EP>>
_>>>>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком".
НС>>>На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень?
I>Алё, ты видишь, что НС задал вопрос ?
Конечно, сел в лужу и начал съезжать уже не так категорично. Это при том что из первого же примера sqlpp11 видно что это не tuple и не "нетипизированная хрень".
for (const auto& row : db(select(foo.name, foo.hasFun).from(foo).where(foo.id > 17 and foo.name.like("%bar%"))))
{
if (row.name.is_null())
std::cerr << "name is null, will convert to empty string" << std::endl;
std::string name = row.name; // string-like fields are implicitly convertible to stringbool hasFun = row.hasFun; // bool fields are implicitly convertible to bool
}
I>Теперь на секундочку — каким чудом обеспечивается точная типизация этого фокуса с ad-hoc типами ? Отвечай прямо, перечисляя все языковые фичи необходимые для этого.
Наследование, вывод типов, и желательно variadic templates (хотя можно и без них, но труднее — на C++1998). Я уже приводил минимальный пример на эту тему выше
Здравствуйте, Ikemefula, Вы писали:
I>За 10 лет до твоего пришествия сюда на этом форуме люди делились и парсером на темплейтах, и движком регекспов, и вычислением выражений.
Те кто заявляет о невозможности не в курсе всего этого
Собственно я выше уже говорил, что expression template больше двадцати лет, первые статьи по ним появлялись ещё до выхода первого стандарта C++.
Re[158]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Serginio1, Вы писали:
EP>>>>И где тут хотя бы что-то из подчёркнутого? Хотя бы отдалённо напоминающее? Споришь с собственным воображением? S>>> Достаточно. То есть С++ значительно лаконичнее линка, ибо это пишут монстры от Сшарп. Твои слова. EP>>Причём тут LINQ вообще? Речь шла про реализацию алгоритма поиска минимального элемента S> Во во. Там как раз было расширение для Linq . Казалось бы причем тут Linq?
Не причём — речь про раздутую реализацию. Что же там снаружи рояли не играет.
То есть из того что я сказал что реализация алгоритма раздутая, ты пришёл к выводу "C++ лучший язык для работы с БД"
S>>>А Линк применяется и для БД, а значит и С++ лучший язык и для БД. Он же самый выразительный. EP>>Ещё раз, приведи пруфлинки на подчёркнутое. То есть "быстрее в 2 раза" и "C++ лучший язык для работы с БД". S> То есть С++ медленне? Тогда прошу прощения?
С логикой беда? Я прошу привести пруфлинк на то что я говорил "быстрее в 2 раза", всё.
S>При этом ты приводишь ассемблерный код? Дать пруф?
Я действительно приводил ассемблерный код, вот только мне нужен пруф на "быстрее в 2 раза", а не на ассемблерный код
S> Но я тебе про тот алгоритм показал, что он будет короче на C# чем на С++. И ты с эти согласился.
Алгоритм не короче, а намного длиннее.
Короче лямбда, у которой меньше скобочек, нет auto и return — но это всё ортогонально реализации алгоритма
S>А вот признать свои слова ошибочными по отношению выразительности C# это ты не можешь.
Сколько строк для min/max item в CodeJam? (до генерации)
