Здравствуйте, Serginio1, Вы писали:
C>>В Rust такая конструкция просто не скомпилируется: S> Так и в C# такая конструкция вроде не скомпилируется. Еще с первых версий нельзя производить действия с итератором.
Ещё как скомпилируется, и сломается потом в рантайме. Действия идут не с итератором, а со словарём, который итерируется.
S>Хотя для словаря это не критично. Вернее для определенных его вариантов.
Это один из простых примеров, когда возникает ошибка из-за aliasing'а данных.
S>>> Что такое ET? C>>Expression Tree — второй лик LINQ'а. S> Ну на самом деле надо просто на этом руку набить.Отдельная специализация. Правда когда очень припрет
Ну вот и не надо делать из LINQ'а манну небесную — для коллекций это просто удобный синтаксический сахар. А работа с БД для С++ не особо актуальна.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>>>В Rust такая конструкция просто не скомпилируется: S>> Так и в C# такая конструкция вроде не скомпилируется. Еще с первых версий нельзя производить действия с итератором. C>Ещё как скомпилируется, и сломается потом в рантайме. Действия идут не с итератором, а со словарём, который итерируется.
Да точно вспомнил. Сам же когда свой словарь делал вставлял это ограничение.
S>>Хотя для словаря это не критично. Вернее для определенных его вариантов. C>Это один из простых примеров, когда возникает ошибка из-за aliasing'а данных.
S>>>> Что такое ET? C>>>Expression Tree — второй лик LINQ'а. S>> Ну на самом деле надо просто на этом руку набить.Отдельная специализация. Правда когда очень припрет C>Ну вот и не надо делать из LINQ'а манну небесную — для коллекций это просто удобный синтаксический сахар. А работа с БД для С++ не особо актуальна.
Ну тут то предлагают делать на C++ все, что только можно.
Просто реально Linq очень удобен и прежде всего при работе с Базами данных. И в основном не делают своих провайдеров а используют Linq to EF. Со всеми его достоинствами и недостатками. Как программист 1С основная лимитирующая часть, это доступ к БД.
А с остальным справляется даже интерпритатор.
Хотя народ и пишет расширения LINQKit Dynamically Composing Expression Predicates https://msdn.microsoft.com/ru-ru/library/bb546158(v=vs.110).aspx
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
C>>Ну вот и не надо делать из LINQ'а манну небесную — для коллекций это просто удобный синтаксический сахар. А работа с БД для С++ не особо актуальна. S> Ну тут то предлагают делать на C++ все, что только можно.
Конечно. И даже очень многие вещи очень удобно.
S> Просто реально Linq очень удобен и прежде всего при работе с Базами данных. И в основном не делают своих провайдеров а используют Linq to EF. Со всеми его достоинствами и недостатками. Как программист 1С основная лимитирующая часть, это доступ к БД.
Ну вот потому С++ для прикладных программистов 1С особо не актуален, хотя сама 1С написана именно на нём.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>>>Ну вот и не надо делать из LINQ'а манну небесную — для коллекций это просто удобный синтаксический сахар. А работа с БД для С++ не особо актуальна. S>> Ну тут то предлагают делать на C++ все, что только можно. C>Конечно. И даже очень многие вещи очень удобно.
S>> Просто реально Linq очень удобен и прежде всего при работе с Базами данных. И в основном не делают своих провайдеров а используют Linq to EF. Со всеми его достоинствами и недостатками. Как программист 1С основная лимитирующая часть, это доступ к БД. C>Ну вот потому С++ для прикладных программистов 1С особо не актуален, хотя сама 1С написана именно на нём.
Только вот если бы была написана на C# то эволюционировала бы быстрее. Все таки C# очень удобный и простой язык.
Но если сравнивать C# как язык для массового использования, то для меня он даже проще чем 1С, так как сочетает и динамику и статику и кучу сахара для быстрого кодирования.
Хотя для прикладных решений, там где нужно много кодить я бы предпочел TypeScript или Kotlin. Так или иначе нужен Вэб клиент, и у 1С в одном месте пишется как клиентская так и серверная часть (методы подразделяются на клиентские и серверные. Серверные вызываются из клиентских. Все прозрачно)
У каждого языка своя ниша.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Это не в тему. Смотри пример по ссылке — await из bar'а возвращает управление на самый вверх, в C# пришлось бы ставить await bar внутри foo, добавлять async, и так на всех уровнях. Тут же можно вызывать await на самом глубоком уровне, не меняя код на промежуточных. S>> Так await и показывает, что функция асинхронная. А вот вызов просто bar воспринимается как синхронная. Где логика?
EP>Логика в том, что синхронный по форме код не нужно засорять await'ом по всему callstack. И не нужно писать две версии отличающиеся только наличием await+async. И можно взять уже готовый код типа getline, и передать в него stream который внутри делает await. Смотри пример
Асинхронный код должен сраз показывать, что он асинхронный. getline со стримом это пример "я могу штаны через голову". Именно эта асинхронщина и даёт проблемы, т.к. изначально однозадачный и возможно даже нереэнтерабельный код превращается в многозадачный реэнтерабельный.
await в дотнете это абстракция — абсолютно без разницы, где работает Task, в текущем потоке, в другом, размазывается по пулу или эвентлупу.
Похоже, что за три года обсуждений ты так и не понял это, но все еще борешься с частным случаем от частного случая при помощи stackfull корутин.
Здравствуйте, Ikemefula, Вы писали:
I>await в дотнете это абстракция — абсолютно без разницы, где работает Task, в текущем потоке, в другом, размазывается по пулу или эвентлупу.
Так и в случае await на stackful coroutines можно перебрасывать корутины между потоками
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>await в дотнете это абстракция — абсолютно без разницы, где работает Task, в текущем потоке, в другом, размазывается по пулу или эвентлупу.
EP>Так и в случае await на stackful coroutines можно перебрасывать корутины между потоками
Тогда на ровном месте возникнут проблемы с обращением к объектам которые привязаны к конкретному потоку.
Здравствуйте, Ikemefula, Вы писали:
I>>>await в дотнете это абстракция — абсолютно без разницы, где работает Task, в текущем потоке, в другом, размазывается по пулу или эвентлупу. EP>>Так и в случае await на stackful coroutines можно перебрасывать корутины между потоками I>Тогда на ровном месте возникнут проблемы с обращением к объектам которые привязаны к конкретному потоку.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Так и в случае await на stackful coroutines можно перебрасывать корутины между потоками I>>Тогда на ровном месте возникнут проблемы с обращением к объектам которые привязаны к конкретному потоку.
EP>Точно также как и в случае с C# await
Здравствуйте, Serginio1, Вы писали:
S>>>Это не факт, что это нужно делать ради Перформанс. EP>>Авторы этого кода сделали. S>>> Это недостаток не Linq, а .Net. EP>>Я не говорил что это недостаток LINQ. S> На самом деле этот недостаток происходит от достоинства, а именно простоты и лаконичности использования.
Нет, это ортогонально простоте и лаконичности использования. Ты непонятно зачем пытаешься любыми средствами оправдать этот недостаток — пока у тебя это совсем не получается
S>А вот когда начинаю выжимать копейки, то это уже недостаток не языка, а в мозгах.
Авторы CodeJam, вы слышали? Тут Serginio1 передаёт вам привет
S>>>>>и простоте расширяемости. EP>>>>В чём именно? S>>> В том, что людям захотелось создать свой MinItem они его и сделали. EP>>А я сделал свой min_element S>>>В том числе и для IQueryable. EP>>В том числе для встроенных массивов и всех контейнеров поддерживающих стандартный интерфейс ForwardIterator. S> А как насчет IQueryable
И причём тут IQueryable и C++?
S>На Linq проще он поддерживает IEnumerable. Еще раз он поддерживает SQL подобный синтаксис. А как в C++?
Декларативный синтаксис Boost.Range.
S>Все я завязываю этот бесполезный спор. Соглашусь, что ребята затеяли совсем ненужную возню с генерацией кода, где проще было обойтись стандартными подходами Linq. Причем они не ушли от компаратора. Во всяком случае с MinItem. S> В итоге нельзяделать выводы, по деятелльности отдельных пусть и уважаемых программистов. Мухи в голове бывают у всех. Особенно года времени куча.
Авторы CodeJam, вам привет №2
S> Но если пройтись по библиотеке. То увидим Action Func c кучей перегрузок по количеству параметров по моему до 64 аргументов. S>Я на xamarin наткнулся, что больше 4 там не понимает. Вот это недостаток.
Это от отсутствия variadic generics.
S> То есть можно ввести заинлайненную специализацию только для примитивных типов
А на C++ это всё работает автоматом для всех типов
Здравствуйте, Ikemefula, Вы писали:
EP>>>>Так и в случае await на stackful coroutines можно перебрасывать корутины между потоками I>>>Тогда на ровном месте возникнут проблемы с обращением к объектам которые привязаны к конкретному потоку. EP>>Точно также как и в случае с C# await I>Неверно. await в C# ничего не перебрасывает.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>Тогда на ровном месте возникнут проблемы с обращением к объектам которые привязаны к конкретному потоку. EP>>>Точно также как и в случае с C# await I>>Неверно. await в C# ничего не перебрасывает.
EP>Код после await может проснуться в другом потоке
Здравствуйте, Ikemefula, Вы писали:
I>>>>>Тогда на ровном месте возникнут проблемы с обращением к объектам которые привязаны к конкретному потоку. EP>>>>Точно также как и в случае с C# await I>>>Неверно. await в C# ничего не перебрасывает. EP>>Код после await может проснуться в другом потоке I>Тем не менее сам await ничего не перебрасывает.
А я не говорил что сам await перебрасывает. Я тебе указал на то что там ситуация аналогичная.
Ты уже от недостатка аргументов скатился к придирке к словами Всё, совсем не интересно, удачи.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Код после await может проснуться в другом потоке I>>Тем не менее сам await ничего не перебрасывает.
EP>А я не говорил что сам await перебрасывает. Я тебе указал на то что там ситуация аналогичная. EP>Ты уже от недостатка аргументов скатился к придирке к словами Всё, совсем не интересно, удачи.
Не аналогичная. Ты предлагаешь неявный механизм, который меняет втихаря вообще все. Я говорю о явном, безопасном механизме.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>>Это не факт, что это нужно делать ради Перформанс. EP>>>Авторы этого кода сделали. S>>>> Это недостаток не Linq, а .Net. EP>>>Я не говорил что это недостаток LINQ. S>> На самом деле этот недостаток происходит от достоинства, а именно простоты и лаконичности использования.
EP>Нет, это ортогонально простоте и лаконичности использования. Ты непонятно зачем пытаешься любыми средствами оправдать этот недостаток — пока у тебя это совсем не получается
У меня нет проблем с этим недостатком. Учитывая, что я еще программирую на 1С, в том числе и на С++.
S>>А вот когда начинаю выжимать копейки, то это уже недостаток не языка, а в мозгах.
EP>Авторы CodeJam, вы слышали? Тут Serginio1 передаёт вам привет
Они мне тоже самое говорили когда то, когда я выжимал в разы. В конечном итоге я последовал их срвету. S>>>>>>и простоте расширяемости. EP>>>>>В чём именно? S>>>> В том, что людям захотелось создать свой MinItem они его и сделали. EP>>>А я сделал свой min_element S>>>>В том числе и для IQueryable. EP>>>В том числе для встроенных массивов и всех контейнеров поддерживающих стандартный интерфейс ForwardIterator. S>> А как насчет IQueryable
EP>И причём тут IQueryable и C++?
Это тот же Linq S>>На Linq проще он поддерживает IEnumerable. Еще раз он поддерживает SQL подобный синтаксис. А как в C++?
EP>Декларативный синтаксис Boost.Range.
Что то я там не увидел аналога
string[] teams = {"Бавария", "Боруссия", "Реал Мадрид", "Манчестер Сити", "ПСЖ", "Барселона"};
var selectedTeams = from t in teams where t.ToUpper().StartsWith("Б") orderby t select t;
// выполнение LINQ-запросаforeach (string s in selectedTeams)
Console.WriteLine(s);
Мне это пригодится в дальнейшем. S>>Все я завязываю этот бесполезный спор. Соглашусь, что ребята затеяли совсем ненужную возню с генерацией кода, где проще было обойтись стандартными подходами Linq. Причем они не ушли от компаратора. Во всяком случае с MinItem. S>> В итоге нельзяделать выводы, по деятелльности отдельных пусть и уважаемых программистов. Мухи в голове бывают у всех. Особенно года времени куча.
EP>Авторы CodeJam, вам привет №2
S>> Но если пройтись по библиотеке. То увидим Action Func c кучей перегрузок по количеству параметров по моему до 64 аргументов. S>>Я на xamarin наткнулся, что больше 4 там не понимает. Вот это недостаток.
EP>Это от отсутствия variadic generics.
Думаю решат в следующих версиях. S>> То есть можно ввести заинлайненную специализацию только для примитивных типов
EP>А на C++ это всё работает автоматом для всех типов
На самом деле в первой версии для Arrray они так и поступали.
И еще раз тот Java, C#, JS и даже 1С прекрасно себе живут без пресловутой скрорсти, зато скорость и надежность кодирования значительно выше.
и солнце б утром не вставало, когда бы не было меня
S>> Имея расширения мне нужно всего навсего добавиить лямбду доступа к полю. Как это выглядит на C++?
EP>Например: EP>
EP>auto it = min_element(source, [](auto &i){ return i->value; });
EP>
S>>И как в итоге будет выглядеть итератор.
EP>В каком смысле?
S>> По алгоритму указанному в MinItem. А именно null не сравниваются для указателей.
EP>Добавь filtered во внутрь обёртки, при этом алгоритм фильтрации не нужно расписывать вручную — его заинлайнит компилятор. EP>
EP>source | filtered([](auto &x){ return x != nullptr; })
EP>
Здравствуйте, kaa.python, Вы писали:
KP>Довольно интересная новость от Dropbox, которые переписали свое хранилище с Go на Rust в целях оптимизации. Что показательно, не с Go на C++, а на Rust, что мне видится очень логичным и правильным ходом.
Здравствуйте, Nuzhny, Вы писали:
N>Ещё новость: svgcleaner переписали на Rust. Теперь уже с C++ и получили ускорение в 3 раза.
Очень круто! Похоже, что Rust очень хорош до те пор, пока не нужно сталкиваться с FFI. А вот сочетания FFI С Rust мне показалось просто редкостным трешем, фактически как JNI по уровню кошмара.
Всё, совсем не интересно, удачи.
