Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот только это тоже можно переписать в стиле линка, не потеряв в скорости.

OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту. Пока его не будет, говорить с тобой на эту тему дальше бессмысленно.

НС>Напоминаю, ты так и не смог рассказать, что же ты понимаешь под "sql синтаксиcом".

Мы можем играться в слова сколько угодно, но реальность это не изменит. Все прекрасно видели как красивый код на linq из примера 1 превратился в дикий ужас на примере 2, в котором просто слегка поменяли условие фильтрации исходных данных. Так что любому вменяемому человеку очевидно, что есть класс задач где использовать linq глупо.

И это всё уже никак не связано с быстродействием.

НС>Но split не обязан что либо копировать. И уж точно не имеет отношения к линку.

Факт наличия split в коде программы имеет прямое отношение к linq. В то время как сама по себе задача не требует наличия split.

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

_>OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту.

Сколько заплатишь?

НС>>Напоминаю, ты так и не смог рассказать, что же ты понимаешь под "sql синтаксиcом".

_>Мы можем играться в слова сколько угодно

Играешься ты. Потому что не в состоянии ответить ни на один из конкретных вопросов, которые тебе задали.

_>И это всё уже никак не связано с быстродействием.

Ты с темы не уходи. Тебе задали вопросы про именно быстродействие и про твой загадочный sql стиль.

НС>>Но split не обязан что либо копировать. И уж точно не имеет отношения к линку.

_>Факт наличия split в коде программы имеет прямое отношение к linq.

Нет.

_> В то время как сама по себе задача не требует наличия split.

Задача требует деления строки по разделителю. Стандартно есть только один метод, который это делает — string.Split.

А>А что Вы думаете по этому поводу?

Принципы хорошие, как и любые другие, которые вам позволяют писать хороший надёжный код. Хоть вообще совсем другие.

Q>Ну вот Кормен—Лейзерсон—Ривест — это подходящая книжка по алгоритмам? Там то, что в C++ называется std::list, называется singly linked list.
Почему singly-то? По нему можно в обратном направлении пройтись.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту.
НС>Сколько заплатишь?

))) Ну всё должно быть в соответствие с C++ программистом. Давай посчитаем... Ему на эти две строчки на Boost потребовалось бы наверное секунд 30. Ну накинем ещё 30 на проверку на тестовом файле. В итоге минута. Если возьмём за среднюю зарплату допустим 100К р/м, то получаем... Вот, 10 рублей дам за решение.

А вообще, главным выводом этого всего для тебя должно быть, что если не можешь ответить за свои слова, то и не вылезай лучше.

НС>Ты с темы не уходи. Тебе задали вопросы про именно быстродействие и про твой загадочный sql стиль.

К linq в этой теме было два отдельных вида претензий.
1. По быстродействию. Демонстрировалось на примере1. Там со всем разобрались, разве что кроме твоей упёртости. Соответственно беседовать тут дальше бесполезно, пока не предоставишь linq вариант работающий со скоростью C++.
2. По красоте кода. Сильно зависит от условия задачи и в определённых случаях (а всего то чуть изменили условии фильтрации) может получаться дикий ужас. Это демонстрировалось на примере2.

Быстродействие в примере2 никто уже не тестировал, т.к. смысла не было. В примере1 у нас был хотя бы красивый код — соответственно было понятно ради чего жертвовать быстродействием. А тут уже и сам код жуть. Хотя думаю что если протестировать linq код из второго примера, то вообще дикие тормоза будут. )))

_>>Факт наличия split в коде программы имеет прямое отношение к linq.
НС>Нет.


НС>Задача требует деления строки по разделителю. Стандартно есть только один метод, который это делает — string.Split.

Если задача этого обязательно требует, то тогда какой магией работает тот императивный код? Там никаких массивов строк не создаётся. Только один проход по изначальной строке и всё — печатаем результат.

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

_>А вообще, главным выводом этого всего для тебя должно быть, что если не можешь ответить за свои слова, то и не вылезай лучше.

Ясно. На сем я с тобой разговор закончил.

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

Клиника. В сад, к землеройкам.

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

_>OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту. Пока его не будет, говорить с тобой на эту тему дальше бессмысленно.

Александреску продолжает измываться над D, и вот докатился практически до того же синтаксиса что и в linq

http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/

auto answer = recurrence!"a[n-1] + a[n-2]"(1, 1)
              .until!"a > 4_000_000"()
              .filter!"a % 2 == 0"()
              .reduce!"a + b"();

в теории это должно насмерть оптимизироваться практически в аналог кода написанного
в лоб так как все это основано на range, надо будет проверить, погонять.

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

FR>Александреску продолжает измываться над D, и вот докатился практически до того же синтаксиса что и в linq

Ох, ну когда же они уже зафиксируют стандарт языка, что быть дать ему шанс завоевать своё место. Такими темпами он никогда не сумеет выйти за пределы интересов фанатов. Вот уж насколько он мне нравится, но я до сих пор не рискнул применить нигде в реальном деле.

FR>http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
FR>

FR>auto answer = recurrence!"a[n-1] + a[n-2]"(1, 1)
FR>              .until!"a > 4_000_000"()
FR>              .filter!"a % 2 == 0"()
FR>              .reduce!"a + b"();
FR>

Не плохо. Надо бы взглянуть на детали.

FR>в теории это должно насмерть оптимизироваться практически в аналог кода написанного
FR>в лоб так как все это основано на range, надо будет проверить, погонять.

Вообще говоря в теории с помощью STL тоже можно провернуть подобное, благодаря фирменной особенности — итератором может служить не только какой-то спец. класс, но и любой указатель. Т.е. мы можем задавать куски большой строки просто двумя указателями внутри неё, передавая их как итераторы в различные алгоритмы. Но это уже будет не так симпатично как в D, т.к. тут у нас многие другие обычные функции (типа преобразования в int) не рассчитаны на этот подход — их тогда надо дописывать.

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

M>Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.

я ниразу в жизни не юзал printf- может вы типа сишного динозовра и вам пора поботать что-то новое, ну там boost::format к примеру?

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

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

_>>>Хы, одному мне кажется что потоки и контейнеры C++ тут обсуждают больше всего C# люди, которые уже "забыли всё" (или вообще не знали)? )))

Q>>Не больше, чем люди, которые кроме C++ ничего во внешнем мире не видели, и сравнивать могут лишь с Си.

M>Что-то видел, что-то нет. C++ довольно сложен и многословен. Но после всех его минусов — auto уже есть в последнем стандарте, остался только форматный вывод. Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.

Он уже есть, гугль в помощь.
Навскидку:
http://abel.web.elte.hu/mpllibs/safe_printf/printf.html
https://github.com/c42f/tinyformat

You will always get what you always got
  If you always do  what you always did