Re[57]: benchmark
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.01.17 13:01
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Эта инструкция тебе вообще не нужна. Это о том как собрать отладочный дистрибутив CEF. А у тебя он уже собран и лежит в папке Debug.


Спасибо. Понял.
S>>Чтобы из VS отлаживать.

_>Отлаживать что? Свой C++ код? Свой JS код? Или внутренности CEF? )



Нашел CMake support in Visual Studio 2017

В нем видно весь проект. Попробую отладку
S>> ES6 кстати работает. Проверил.
S>>Спасибо буду разбираться. Просто иногда проще взять шаблон (для VS их много) и переделывать под себя.
S>>Поищу может для CEF есть шаблоны.

_>Я же говорю, тебе надо определиться со способом работы с GUI. Вот например https://github.com/joinAero/qtcefclient простейший вариант на Qt. А в поставку CEF входит пример с использованием нативных функций ОС (но на мой взгляд он ужасен, если говорить именно об этой части).


Спасибо! Посмотрю.
Но мне бы просто пока универсальную обертку для .Net Core классов сделать и показать. Я ведь это для себя по сути делаю.
Никому не интересно. Хотя тот же 1С язык можно капитально расширить. Но ...
Мне просто нужна реализация идей. А в cefclient окно есть. Вот на его основе и попытаюсь сделать приложение. Мне то только JavaScriptIntegration нужна.
и солнце б утром не вставало, когда бы не было меня
Re[39]: Словарь
От: Qbit86 Кипр
Дата: 16.01.17 13:16
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Т.е., суть техники в том, что можно разработать некий тип и рядом с ним "словарь" операций над ним.

V>Схематично:
V>[cs]
V>interface IMath<T>
V>{
V> T Add(T a, T b);
V> T Sub(T a, T b);
V> T Mul(T a, T b);
V> T Div(T a, T b);
V>}

Дело говоришь. Не далее как вчера мне приходилось описывать аналогичное (моноид с `Identity` и `Combine()`).

V>Разве что потребуется каждый раз подавать этот словарь как аргумент — либо как обычный аргумент, либо как генерик параметр примерно так:


В стандартной библиотеке .NET конкретно для этих распространённых интерфейсов (`IComparer<T>`, `IEqualityComparer<T>`) принято передавать их как есть, а не как констрейнты дженерика. То есть просто обычный динамический полиморфизм.

V>Ну или можно представить некий сложный алгоритм как объект (структуру) и параметризировать этот объект словарём лишь однажды.


Всё так. Вместо «свободной» функции с десятком аргументов делать метод типа, замыкающего в конструкторе часть этих аргументов как фиксированные параметры экземпляра.
Глаза у меня добрые, но рубашка — смирительная!
Re[57]: benchmark
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.01.17 13:22
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Я же говорю, тебе надо определиться со способом работы с GUI. Вот например https://github.com/joinAero/qtcefclient простейший вариант на Qt. А в поставку CEF входит пример с использованием нативных функций ОС (но на мой взгляд он ужасен, если говорить именно об этой части).


Огромнейшее спасибо!!! То, что надо!
Cmake и с файлами потом буду разбираться
и солнце б утром не вставало, когда бы не было меня
Re[58]: benchmark
От: alex_public  
Дата: 16.01.17 13:23
Оценка: 3 (1)
Здравствуйте, Serginio1, Вы писали:

S> Нашел CMake support in Visual Studio 2017

S> В нем видно весь проект. Попробую отладку

Ну CMake — это про сборку (замена убогих настроек проекта в VS), а не про отладку. ))) Но да, вещь полезная.

_>>Я же говорю, тебе надо определиться со способом работы с GUI. Вот например https://github.com/joinAero/qtcefclient простейший вариант на Qt. А в поставку CEF входит пример с использованием нативных функций ОС (но на мой взгляд он ужасен, если говорить именно об этой части).

S> Мне просто нужна реализация идей. А в cefclient окно есть. Вот на его основе и попытаюсь сделать приложение. Мне то только JavaScriptIntegration нужна.

Ещё раз повторяю, в cefclient используется ужасный древний способ работы с GUI через системное API винды (вызовы RegisterClassEx, CreateWindow и дальнейшие ужасы игр с HWND, утомившие ещё в 90-ые). Ты можешь полюбоваться на конкретный код в файле tests/cefclient/browser/root_window_win.cc. Это всё во-первых неудобно, а во-вторых не кроссплатформенно (а у тебя же вроде такая цель).

Но для просто проверки работоспособности идеи или теста это всё конечно тоже пойдёт. Так что можешь просто вставить нужный тебе код прямо в cefclient, собрать его и поиграться с результатами. )))
Re[40]: Словарь
От: vdimas Россия  
Дата: 16.01.17 13:47
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>В стандартной библиотеке .NET конкретно для этих распространённых интерфейсов (`IComparer<T>`, `IEqualityComparer<T>`) принято передавать их как есть, а не как констрейнты дженерика. То есть просто обычный динамический полиморфизм.


Именно на это я и обращал внимание.
Re[40]: «Собаку съел»
От: vdimas Россия  
Дата: 18.01.17 10:51
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Я к тому же, что этот пример приводит постоянно один человек, и считает это доказательством дефекта .Net.

V>>А ну ясно, аргументы оппонента тебе не нравятся.
V>>Бывает.
S> При этом я тебе постоянно привожу пример где это уже реализовано без лишних приседаний и кодогенерации.

Я тебе дважды на твой пример ответил, но тебе мой ответ не понравился.
Типа: "Этот аргумент мне не подходит, приведи-ка какой-нить другой". ))
Мы что, в "очко" тут играем, что ты на голубом глазу требуешь: "еще... еще... себе..."


S>Это не дефект .Net, а дефект Мойши.


Ты неконструктивен, извини.
И это поломало подающий надежды на предметность спор.
Re[41]: «Собаку съел»
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.01.17 15:01
Оценка: :)
Здравствуйте, vdimas, Вы писали:

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


S>>>> Я к тому же, что этот пример приводит постоянно один человек, и считает это доказательством дефекта .Net.

V>>>А ну ясно, аргументы оппонента тебе не нравятся.
V>>>Бывает.
S>> При этом я тебе постоянно привожу пример где это уже реализовано без лишних приседаний и кодогенерации.

V>Я тебе дважды на твой пример ответил, но тебе мой ответ не понравился.

V>Типа: "Этот аргумент мне не подходит, приведи-ка какой-нить другой". ))
V>Мы что, в "очко" тут играем, что ты на голубом глазу требуешь: "еще... еще... себе..."

Понимаешь, когда 1000 раз приводят пример, который в реальных случаях обходится примерами приведенными мной.
Там смысл в том, что Linq SQL ориентирован, и нет C++ max min

Но суть в том, что

Item itemMax = (from i in items
     let maxId = items.Max(m => m.ID)
     where i.ID == maxId
     select i).FirstOrDefault();


Для SQL будет выдан запрос, а для коллекций может быть сделан неоптимальный проход.
Поэтому ребята оптимизировали. Но дело то в том, Roslyn сейчас может оптимизировать такие запросы, и их оптимизация в итоге окажется наоборот тормозом
так как под оптимизацию подпадают стандартные операторы Linq

Так что не суди о Карузо по Мойше

S>>Это не дефект .Net, а дефект Мойши.


V>Ты неконструктивен, извини.

V>И это поломало подающий надежды на предметность спор.
Ну изини, что не оправдал твоих надежд.
и солнце б утром не вставало, когда бы не было меня
Re[42]: «Собаку съел»
От: vdimas Россия  
Дата: 18.01.17 16:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


Да я-то понимаю всё понимаю, просто прими как факт ))

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

Возвращаясь к началу начал, любая современная сложная программа представляет из себя иерархическую комбинацию сущностей. В этом плане параметрический полиморфизм — это удобный инструмент для построения таких комбинаторов, ведь "за один раз" можно описать комбинатор, который работает с множеством типов, а не одним. Ты же в ответ апеллируешь частностями.
Re[43]: «Собаку съел»
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.01.17 15:15
Оценка:
Здравствуйте, vdimas, Вы писали:

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


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


V>Да я-то понимаю всё понимаю, просто прими как факт ))


V>Просто тебя малость уносит в сторону от обсуждаемого. В этой подветке обсуждался параметрический полиморфизм.


V>Возвращаясь к началу начал, любая современная сложная программа представляет из себя иерархическую комбинацию сущностей. В этом плане параметрический полиморфизм — это удобный инструмент для построения таких комбинаторов, ведь "за один раз" можно описать комбинатор, который работает с множеством типов, а не одним. Ты же в ответ апеллируешь частностями.

Так параметрический полиморфизм хорошь в том, что он инлайнится.
Я привожу тебе примеры где Дженерики прекрасно инлайнятся. Но при этом получаем проверку типа и интеллисенсе.
Только типы у тебя должны перегружать все операторы. А вот когда например куча вариантов сортировок нет единого комбинатора итд.
На Linq те же условия селекторы они не единообразны. Так, что и куча проблем у С++ с теми же базами, в отличие от Linq
и солнце б утром не вставало, когда бы не было меня
Re[44]: «Собаку съел»
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.01.17 16:07
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S> Так параметрический полиморфизм хорошь в том, что он инлайнится.

S> Я привожу тебе примеры где Дженерики прекрасно инлайнятся. Но при этом получаем проверку типа и интеллисенсе.

Вы все еще об этом примере?

return arr.Where(x => x > q).Select(x => x + 3).Sum();


Если да, то в нем предикат и проекция записаны изначально в виде, не относящемся к параметрическому полиморфизму. "x > q" и "x + 3" здесь используют ad-hoc полиморфизм. Это один момент. Второй — инлайнятся Func-и, но не операторы. Вот если бы изначально было записано
x => SomeGenericComparer.Compare(x, q) > 0

подозреваая что метод Compare<T> дженериковый; компилятор выводит T, и после оптимизации мы увидели бы "x > q", то да!
Re[45]: «Собаку съел»
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.01.17 16:45
Оценка:
Здравствуйте, samius, Вы писали:

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


S>> Так параметрический полиморфизм хорошь в том, что он инлайнится.

S>> Я привожу тебе примеры где Дженерики прекрасно инлайнятся. Но при этом получаем проверку типа и интеллисенсе.

S>Вы все еще об этом примере?


S>
S>return arr.Where(x => x > q).Select(x => x + 3).Sum();
S>


S>Если да, то в нем предикат и проекция записаны изначально в виде, не относящемся к параметрическому полиморфизму. "x > q" и "x + 3" здесь используют ad-hoc полиморфизм. Это один момент. Второй — инлайнятся Func-и, но не операторы. Вот если бы изначально было записано

S>
S>x => SomeGenericComparer.Compare(x, q) > 0
S>

S>подозреваая что метод Compare<T> дженериковый; компилятор выводит T, и после оптимизации мы увидели бы "x > q", то да!

В свое время VladD2 на висби еже дела тест при компараторе на структуре и тогда они инлайнили компаратор. Но затем решили, что это не нужно.
То есть если компаратор заранее известен, то и проинлайнить как это делается в C++ с шаблонами.
Но нужно это только для валуе типов.
В большинстве же случаев ты будешь использовать линк

arr.Where(x => x > q).Select(x => x + 3).Sum();


Который и сейчас прекрасно инлайнится.
и солнце б утром не вставало, когда бы не было меня
Re[46]: «Собаку съел»
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.01.17 18:26
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

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


S> В свое время VladD2 на висби еже дела тест при компараторе на структуре и тогда они инлайнили компаратор. Но затем решили, что это не нужно.

S> То есть если компаратор заранее известен, то и проинлайнить как это делается в C++ с шаблонами.
Т.е. если компаратор заранее известен, то никакого отношения к инлайну дженерикового компаратора это не имеет.
S>Но нужно это только для валуе типов.
S> В большинстве же случаев ты будешь использовать линк

S>
S>arr.Where(x => x > q).Select(x => x + 3).Sum();
S>


S> Который и сейчас прекрасно инлайнится.

Инлайнится Where, Select и Sum, функция, принимающая целый x и сравнивающая с q, функция, добавляющая целому 3. Но никак не компаратор и оператор сложения. Параметрически полиморфны здесь Where и Select, но не компаратор, сложение и Sum.
Re[7]: Visual C# vs C++. Надо сравнить перспективы.
От: Ops Россия  
Дата: 20.01.17 02:13
Оценка:
Здравствуйте, novitk, Вы писали:

N>Почитал здесь.Я правильно понимаю, что в .NET возможно лишь словить сам факт исключения? Понять что именно произошло в нативе возможности нет?


Вот тут вроде бы можно. Как конкретно из шарпа
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[47]: «Собаку съел»
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.01.17 07:08
Оценка:
Здравствуйте, samius, Вы писали:

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


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


S>> В свое время VladD2 на висби еже дела тест при компараторе на структуре и тогда они инлайнили компаратор. Но затем решили, что это не нужно.

S>> То есть если компаратор заранее известен, то и проинлайнить как это делается в C++ с шаблонами.
S>Т.е. если компаратор заранее известен, то никакого отношения к инлайну дженерикового компаратора это не имеет.

Угу, а как же шаблоны то инлайнят функции при специализации, если компаратор не известен

Еще раз

public static IEnumerable<TSource> Where<TSource>(
    this IEnumerable<TSource> source,
    Func<TSource, bool> predicate
)


Здесь как ты видишь дженерик метод Func<TSource, bool> predicate
При этом автоматически выводится тип.

S>>Но нужно это только для валуе типов.

S>> В большинстве же случаев ты будешь использовать линк

S>>
S>>arr.Where(x => x > q).Select(x => x + 3).Sum();
S>>


S>> Который и сейчас прекрасно инлайнится.

S>Инлайнится Where, Select и Sum, функция, принимающая целый x и сравнивающая с q, функция, добавляющая целому 3. Но никак не компаратор и оператор сложения. Параметрически полиморфны здесь Where и Select, но не компаратор, сложение и Sum.

Еще раз, нет никаких особых препятствий для инлайнинга сомпараторов при специализации как это делается в C++.
При этом в том же Net Native как раз это и происходит.
и солнце б утром не вставало, когда бы не было меня
Re[37]: Стандартная библиотека .NET
От: alex_public  
Дата: 20.01.17 09:20
Оценка:
Здравствуйте, Serginio1, Вы писали:

K>>https://developer.xamarin.com/guides/mac/

S> Спасибо. Не знал. Правда в разрезе импортозамещения MAC не столь интересен
S> А для Linux, нет?

Кстати, забыл отметить тут важный нюанс. Xamarin (который не Forms) не является настоящей кроссплатформенной библиотекой, а по сути является набором отдельных решений под каждую из платформ и соответственно заставляет писать код под каждую из них отдельно.
Re[38]: Стандартная библиотека .NET
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.01.17 12:14
Оценка:
Здравствуйте, alex_public, Вы писали:

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


K>>>https://developer.xamarin.com/guides/mac/

S>> Спасибо. Не знал. Правда в разрезе импортозамещения MAC не столь интересен
S>> А для Linux, нет?

_>Кстати, забыл отметить тут важный нюанс. Xamarin (который не Forms) не является настоящей кроссплатформенной библиотекой, а по сути является набором отдельных решений под каждую из платформ и соответственно заставляет писать код под каждую из них отдельно.

Ну я это знаю. Да это и MS то особо не нужно. Им интересен UWP
и солнце б утром не вставало, когда бы не было меня
Re[48]: «Собаку съел»
От: samius Япония http://sams-tricks.blogspot.com
Дата: 20.01.17 14:52
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

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


S>>Т.е. если компаратор заранее известен, то никакого отношения к инлайну дженерикового компаратора это не имеет.


S> Угу, а как же шаблоны то инлайнят функции при специализации, если компаратор не известен

В момент специализации шаблона он известен.

S>Еще раз


S>
S>public static IEnumerable<TSource> Where<TSource>(
S>    this IEnumerable<TSource> source,
S>    Func<TSource, bool> predicate
S>)
S>


S> Здесь как ты видишь дженерик метод Func<TSource, bool> predicate

S>При этом автоматически выводится тип.
Дженерик метод, точнее делегат и выводящийся тип я вижу. Я не вижу здесь дженерикового компаратора. Его в этом примере нет, изначально есть лишь оператор сравнения для Int32. И в процессе инлайна Where и т.п., вызов оператора сравнения Int32 остается самим же собой. Т.е. с ним абсолютно ничего не происходит.

S>>Инлайнится Where, Select и Sum, функция, принимающая целый x и сравнивающая с q, функция, добавляющая целому 3. Но никак не компаратор и оператор сложения. Параметрически полиморфны здесь Where и Select, но не компаратор, сложение и Sum.


S> Еще раз, нет никаких особых препятствий для инлайнинга сомпараторов при специализации как это делается в C++.

Препятствий-то нет, но и инлайнинга тоже нет.
S>При этом в том же Net Native как раз это и происходит.
Можно ссылку? Еще раз уточню, я ожидаю увидеть автоматический разворот обобщенного компаратора Compare<T>(T, T) в специальный для типа T. Именно это я подразумеваю под инлайном дженерикового компаратора.
Re[49]: «Собаку съел»
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.01.17 16:14
Оценка:
Здравствуйте, samius, Вы писали:

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


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


S>>>Т.е. если компаратор заранее известен, то никакого отношения к инлайну дженерикового компаратора это не имеет.


S>> Угу, а как же шаблоны то инлайнят функции при специализации, если компаратор не известен

S>В момент специализации шаблона он известен.

S>>Еще раз


S>>
S>>public static IEnumerable<TSource> Where<TSource>(
S>>    this IEnumerable<TSource> source,
S>>    Func<TSource, bool> predicate
S>>)
S>>


S>> Здесь как ты видишь дженерик метод Func<TSource, bool> predicate

S>>При этом автоматически выводится тип.
S>Дженерик метод, точнее делегат и выводящийся тип я вижу. Я не вижу здесь дженерикового компаратора. Его в этом примере нет, изначально есть лишь оператор сравнения для Int32. И в процессе инлайна Where и т.п., вызов оператора сравнения Int32 остается самим же собой. Т.е. с ним абсолютно ничего не происходит.
Изначально происходит специализация как и в шаблонах C++
а Func<TSource, bool> predicate учавствует в дженерик коде .

S>>>Инлайнится Where, Select и Sum, функция, принимающая целый x и сравнивающая с q, функция, добавляющая целому 3. Но никак не компаратор и оператор сложения. Параметрически полиморфны здесь Where и Select, но не компаратор, сложение и Sum.


S>> Еще раз, нет никаких особых препятствий для инлайнинга сомпараторов при специализации как это делается в C++.

S>Препятствий-то нет, но и инлайнинга тоже нет.

А откуда ты з-наешь?
S>>При этом в том же Net Native как раз это и происходит.
S>Можно ссылку? Еще раз уточню, я ожидаю увидеть автоматический разворот обобщенного компаратора Compare<T>(T, T) в специальный для типа T. Именно это я подразумеваю под инлайном дженерикового компаратора.
Вот смотри исходники

https://github.com/Microsoft/referencesource/blob/master/System.Core/System/Linq/Enumerable.cs

А вот как это разворачивается

Optimising LINQ

roslyn-linq-rewrite



Так Func<TSource, bool> predicate
это и есть компаратор. Он и разворачивается.

То есть

 while (enumerator.MoveNext()) {
                            TSource item = enumerator.Current;
                            if (predicate(item)) {
                                current = item;
                                return true;
                            }
                        }


Прекрасно разворачивается

Example input code


public int Method1()
{
    var arr = new[] { 1, 2, 3, 4 };
    var q = 2;
    return arr.Where(x => x > q).Select(x => x + 3).Sum();
}

Allocations: input array, array enumerator, closure for q , Where delegate, Select delegate, Where enumerator, Select enumerator.

Decompiled output code


public int Method1()
{
    int[] arr = new[] { 1, 2, 3, 4 };
    int q = 2;
    return this.Method1_ProceduralLinq1(arr, q);
}
private int Method1_ProceduralLinq1(int[] _linqitems, int q)
{
    if (_linqitems == null) throw new ArgumentNullException();

    int num = 0;
    for (int i = 0; i < _linqitems.Length; i++)
    {
        int num2 = _linqitems[i]; 
        if (num2 > q)
            num += num2 + 3;
    }
    return num;
}
и солнце б утром не вставало, когда бы не было меня
Отредактировано 20.01.2017 16:23 Serginio1 . Предыдущая версия .
Re[36]: Visual C# vs C++. Надо сравнить перспективы.
От: Evgeny.Panasyuk Россия  
Дата: 20.01.17 16:22
Оценка:
Здравствуйте, itslave, Вы писали:

I>>>чувак явно форумом ошибся.

EP>>Ага, и в предыдущих более чем 400-а сообщений из ~750 тоже заблудился
I>И я полагаю, все они про недостатки перфоманса в дотнете?

Я показываю что он форумом не ошибся — он использует .NET и спрашивает про производительность, которая типа "бесплатно не нужна"

EP>>

EP>>In this post I’m going to visualize what exactly happens during Garbage Collection (GC) and how different GC modes can significantly affect application performance.

I>Все правильно — различные режимы GC могут влиять на перфоманс .NET. Какие из этого надо сделать далекоидущие выводы? У .NET проблемы с перфомансом? Дефолтный режим не всегда оптимален? Еще что нить?

Я показываю что люди этим интересуются, задают вопросы, видимо пытаясь решить реальные проблемы, вопреки мантрам "бесплатно не нужна".
Re[37]: Visual C# vs C++. Надо сравнить перспективы.
От: Evgeny.Panasyuk Россия  
Дата: 20.01.17 16:24
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

EP>>>Кстати, вот это тоже "красоглазики"?

S>> Да уж. Ты хоть, кроме этой самодеятельности хоть, что то читаешь? Ты эту ссылку уже 1000 раз даешь
K>Человека, видимо, в детстве трогал за всякое дотнетчик, с тех пор у него пунктик.

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