В примере для WPF были включены EnableRowVirtualization=«True» EnableColumnVirtualization=«True»
Можете попробовать запустить примеры и счетчик, если отпишетесь тут с результатами и названием вашего процессора — будет полезно. Если сможете заставить их работать быстрее — будет еще полезнее.
>Ну скажите пожалуйста где вы видели нормальный кроссплатформенный UI который поддерживает все фишки любой платформы?
А мне не нужны ВСЕ фишки ЛЮБОЙ платформы. Мне нужно чтобы у UI было низкое время отклика и достаточное количество контролов в базе. Поддержка биндингов была бы плюсом, но жить можно и без нее (биндинги всеравно тянут MVVM, который хотя и приносит свои плюсы, но сильно раздувает код)
Для десктопа же очень много вариантов кросплатформенного UI.
Мобильный UI (и только UI) не вижу смысла делать кросплатформенным
Понимаете, моя цель не в притензиях, а в более четком понимании того, где лучше использовать С++, а где С# и какие будут перспективы у этого.
Естественно есть не мало вопросов по которым к С++ можно предъявлять притензии симитричные притензиям к С# и наоборот, и видимо оценка кода на глаз — один из них.
>Или ты подумал, что если com вызывается из C#, то он должен работать по другим правилам?
Я такого поведения и ожидал, но вот C#-писатель написавший оригинальный код — явно ожидал что GC ему поможет. Он положил ссылку на объект в мембер класа и подумал что GC за него сам все почистит когда надо будет. И GC вообщем-то почистил на выходе из приложения, (только кажется с крашем, потому что после Close, Release у взятого объекта уже както плохо отработал в полудохлом excel-е)
>Кстати описанного тобой поведения легко добиться и в C++.
Можно, но не по причине веры в GC
>А вызов Application.close гарантировано закрывает excel даже если есть ссылки.
Ага — и сделает ссылки на этот объект битыми — это конечно очень полезно.
Но на сколько помню — нет. excel.exe будет висть до тех пор, пока его объекты не освободят, даже после Application.close
С точки зрения COM тут все правильно. Если кто-то взял объект, то пока его не отпустят удалять его нельзя, а соотвественно нельзя и закрывать приложение в котором живет этот взятый объект.
>Кто же пишет тяжелые клиенты для мобильников?
Если в вашем клиенте всроена рендерилка какихнибудь документов, то уже есть что делать кроссплатформенным. Или же например поддержан каконибудь особый протокол работы с сервером, или у вас там расчеты какие-то выполняются…
Да в любом относительно толстом клиенте, который делает что-то «свое» (а не только вызов функциональности ОС) появляется смысл в кроссплатформенности.
А тривиальные приложения делать кросплатформенными смысла нет.
>Конструктор объектов вызывает конструкторы вложенных объектов каскадно. Если объекты не указаны в списке инициализации, то тебе надо будет явно пройтись по всем вложенным объектами чтобы понять что они делают. Как «на глаз» такое оценить?
Конструкторы копирования принято писать достаточно быстрыми, поэтому данная запись сведется либо к копированию объекта либо к передаче ссылки, но никак не к мрачному перебору огроммного масива и поиску в нем чегонибудь.
Во вторых часто свойства простых типов тоже можно отличить на глаз.
Например вряд-ли какойнибудь XXXId, XXXCount, XXXNumber будет объектом, а не простым типом.
Понятно что все это эвристика, но для конкретного примере — более-менее рабочая эвристика.
>В C++ есть неявный вызов деструкторов
Надо просто знать что он вызыватеся на удалении объекта или выходе его из области видимоти, это не сложное правило.
>неявные вызовы конструкторов копирования
Тут отчасти соглашусь, вызовы бывают не очевидные. Лечится использованием ссылок где допустимо (то есть при анализе кода скорее смотришь на то передается ли объект по ссылке)
> неявное применение перегруженных операторов
Глупый вопрос: а как этого достичь? (кроме случая оператора приведения типа)
> неявные преобразования типов при подстановке шаблонов.
Да, может быть неочевидным…
Вообще верно что и С++ бывает сложным в оценке производительности «на глаз»
Более менее точно на глаз наверное только ассемблер оценивать можно :)
>И что? Какую проблему тут ты увидел?
Тут проблемы нет, тут есть различие — производительность C# в этом вызове «на глаз» оценить сложнее, потомучто синтаксис не дает ответа на вопрос будет тут вызов метода или нет, и чтобы понять это нужно перейти к определению класса.
(мелочь конечно, но различие такое есть)
Вот не сказал бы, както ловил случайный краш на использовании неправильно отмаршаленной выходной строки — достаточно долго провозился (я же не знал что он из-за этого), причем вероятность его вылезания по debug была очень малой (не вылезал) и без page heap его вообще было не воспроизвести табильно.
Как то раз попадал на «случайное» кэширование ссылки на COM объект в .net классе при использовании Excel через Automation. В результате Excel не закрывался должны образом (не момню, может даже валился), и для того чтобы этого избежать надо было найт эту закэшированную ссылку на COM объект и явно освободить ДО закрытия application объекта.
И там и там причиной ошибки было то, что с вызовами native кода работали так, как будто это обычные .net объекты\методы, что являлось в корне не верным.
(еще раз говорю, что это относится только к случаям общения с native кодом)
>Это заведомо неправильный подход. Нужно сначала задуматься о таком сервисе, который позволит затратить минимум усилий на поддержку произвольных клиентов.
Я не спорю с тем, что сначала нужно думать о сервисе. Я говорю о том, что клиентов всеравно придется писать. Если клиент будет простой, то можно и не заботиться о кросплатформенности, а написать везде свои.
А если клиент тяжелый, то писать под каждую платформу будет уже трудоемко.
>Это все следствие криво написанного нативного кода (внезапно на С++), а вовсе не проблема .NET.
Вообще-то нет. В документации к нативным методам и COM объектам написано как правильно с ними работать, что и как освобождать, просто .net разработчики ее не особо читают, полагая что раз они пишут на .net то он сам все какниюудь разрулит.
>Это не проблема C#.
Да. Это проблема культуры разработки под C#, сам C# тут не причем.
Я лишь привел примеры где отладка C# может представлять заметные проблемы.
>С ними все однозначно — есть игры и для мобильных устройств, и для десктопов. Иногда разные, иногда одни и те же, иногда companions.
Имено так.
>Опять-таки, зависит от области деятельности.
Да.
Иными словами имеет место быть сегментация, а не уход с десктопа. То что подходит больше для десктопа остается на нем, а то что больше для мобильных платформ — идет на них.
>Особенно почтового, учитывая наличие стандартных протоколов?
Согласен, этот пример плохой. Стандарное приложение для почты вполне подойдет. Однако если бы это был какойнибудь менее стандартный сервис на котором вы не так плотно сидите, типа планировщика, листа покупок или еще чегонибудь то вполне возможно это былобы аргументом. Скажем так, для меня было бы аргументом.
>если вы предоставляете сервис, а не приложение, то вы вполне переживете все смены клиентских парадигм
Если вашим сервисом будут пользоваться — то да. Обычно к сервису нужно предоставить и каких-то клиентов чтобы им пользовались, и тут появляется вопрос о таких средствах разработки этих клиентов, которые бы позволили затратить минимум усилий на поддержку новых платформ.
> Это неправда: игры.
С ними все не однозначно. Часть игр удобных под тач, и не требующих продвинутого ввода действительно идет на мобильные платформы, но для немалой части отсутствие мышки и клавиатуры или хотябы джойстика, а также маленький экран сильно портит геймплей.
>если мы про приложения, не требующие какой-то специальной графики
Мы не только про них) Если говорить о приложениях без особой графики и особо продвинутого UI, то да — веб в них имеет свою долю. Но и не все так просто. Если приложение должно что-то делать с данными на вашей файловой системе (а таких приложений не так и мало) то веб приложения начинают сильно проигрывать.
>Почему вы считаете, что отзывчивость интерфейса у нативного приложения выше?
Она потенциально может быть выше, т.к. больше шансов ответить без задержки на ввод из-за меньшего количество прослоек и задержек.
Хотя например некоторые WFP контролы работают медленнее подобных написанных на HTLM + JS. Поэтому в сравнении веб это может быть не так и плохо по отзывчивости, но врядли на wpf в этом вопросе стоит равняться.
>Во-первых, не отобрали
Это только потому что у gamail есть и мобильный и веб клиенты. А вот если бы не было, то может вы бы и перешли на другую почту, ради удобства мобильного пользования.
>Предположим, раз в год. А сколько у вас период тестирования «перед релизом»?
Месяца 3-4.
>Для GUI работает? Например, high-DPI в Windows и MacOS одинаково себя ведет?
Например для Qt должно бы работать…
doc-snapshots.qt.io/qt5-5.4/highdpi.html
>Тогда ваша формулировка «Декстопные приложение уходят на Workstation, где им и место» лишена смысла.
Наверное я плохо сформулировал, имел ввиду что среди Декстопных приложений остаются только нужные на Workstation, а приложения более уместные на планшетах и телефонах — отмирают на десктопе. Но при этом и Workstation приложения не появляются на мобильных устройствах, то есть рынок просто делится.
>Потому что у него более удобный интерфейс и интеграция с телефонными сервисами.
И именно поэтому веб приложения проигрывают многим десктопным приложениям. Еще можно добавить отзывчивость интерфейса. Я кстати думаю что именно приложения для смартфонов и планшетов отобрали часть рынка у веб приложений.
>Вообще распределенная, удаленная и совместная работа.
Dms и PLM системы появились очень давно, и не в вебе… они очень стары…
>Big Data в ее нынешнем понимании.
А какое у нее сейчас понимание? (видел немного разные трактовки...)
Я попробовал грид из Xceed. Он показал в моем тесте в 3 раза больший FPS чем стандартный грид WPF.
Правда с ним есть проблема: во время скроллинга он не отрисовывает свое содержимое, и получается что скролируется пустой грид.
Как можно заставить этот грид отображать содержимое во время скроллинга? (иначе сложно адекватно сравнить его с остальными)
Можете попробовать запустить примеры и счетчик, если отпишетесь тут с результатами и названием вашего процессора — будет полезно. Если сможете заставить их работать быстрее — будет еще полезнее.
А мне не нужны ВСЕ фишки ЛЮБОЙ платформы. Мне нужно чтобы у UI было низкое время отклика и достаточное количество контролов в базе. Поддержка биндингов была бы плюсом, но жить можно и без нее (биндинги всеравно тянут MVVM, который хотя и приносит свои плюсы, но сильно раздувает код)
Для десктопа же очень много вариантов кросплатформенного UI.
Мобильный UI (и только UI) не вижу смысла делать кросплатформенным
Естественно есть не мало вопросов по которым к С++ можно предъявлять притензии симитричные притензиям к С# и наоборот, и видимо оценка кода на глаз — один из них.
Я такого поведения и ожидал, но вот C#-писатель написавший оригинальный код — явно ожидал что GC ему поможет. Он положил ссылку на объект в мембер класа и подумал что GC за него сам все почистит когда надо будет. И GC вообщем-то почистил на выходе из приложения, (только кажется с крашем, потому что после Close, Release у взятого объекта уже както плохо отработал в полудохлом excel-е)
>Кстати описанного тобой поведения легко добиться и в C++.
Можно, но не по причине веры в GC
Мир был бы лучше, если бы все C#-писатели об этом знали :)
Ага — и сделает ссылки на этот объект битыми — это конечно очень полезно.
Но на сколько помню — нет. excel.exe будет висть до тех пор, пока его объекты не освободят, даже после Application.close
С точки зрения COM тут все правильно. Если кто-то взял объект, то пока его не отпустят удалять его нельзя, а соотвественно нельзя и закрывать приложение в котором живет этот взятый объект.
Если в вашем клиенте всроена рендерилка какихнибудь документов, то уже есть что делать кроссплатформенным. Или же например поддержан каконибудь особый протокол работы с сервером, или у вас там расчеты какие-то выполняются…
Да в любом относительно толстом клиенте, который делает что-то «свое» (а не только вызов функциональности ОС) появляется смысл в кроссплатформенности.
А тривиальные приложения делать кросплатформенными смысла нет.
Конструкторы копирования принято писать достаточно быстрыми, поэтому данная запись сведется либо к копированию объекта либо к передаче ссылки, но никак не к мрачному перебору огроммного масива и поиску в нем чегонибудь.
Во вторых часто свойства простых типов тоже можно отличить на глаз.
Например вряд-ли какойнибудь XXXId, XXXCount, XXXNumber будет объектом, а не простым типом.
Понятно что все это эвристика, но для конкретного примере — более-менее рабочая эвристика.
>В C++ есть неявный вызов деструкторов
Надо просто знать что он вызыватеся на удалении объекта или выходе его из области видимоти, это не сложное правило.
>неявные вызовы конструкторов копирования
Тут отчасти соглашусь, вызовы бывают не очевидные. Лечится использованием ссылок где допустимо (то есть при анализе кода скорее смотришь на то передается ли объект по ссылке)
> неявное применение перегруженных операторов
Глупый вопрос: а как этого достичь? (кроме случая оператора приведения типа)
> неявные преобразования типов при подстановке шаблонов.
Да, может быть неочевидным…
Вообще верно что и С++ бывает сложным в оценке производительности «на глаз»
Более менее точно на глаз наверное только ассемблер оценивать можно :)
Тут проблемы нет, тут есть различие — производительность C# в этом вызове «на глаз» оценить сложнее, потомучто синтаксис не дает ответа на вопрос будет тут вызов метода или нет, и чтобы понять это нужно перейти к определению класса.
(мелочь конечно, но различие такое есть)
Как то раз попадал на «случайное» кэширование ссылки на COM объект в .net классе при использовании Excel через Automation. В результате Excel не закрывался должны образом (не момню, может даже валился), и для того чтобы этого избежать надо было найт эту закэшированную ссылку на COM объект и явно освободить ДО закрытия application объекта.
И там и там причиной ошибки было то, что с вызовами native кода работали так, как будто это обычные .net объекты\методы, что являлось в корне не верным.
(еще раз говорю, что это относится только к случаям общения с native кодом)
Я не спорю с тем, что сначала нужно думать о сервисе. Я говорю о том, что клиентов всеравно придется писать. Если клиент будет простой, то можно и не заботиться о кросплатформенности, а написать везде свои.
А если клиент тяжелый, то писать под каждую платформу будет уже трудоемко.
Вообще-то нет. В документации к нативным методам и COM объектам написано как правильно с ними работать, что и как освобождать, просто .net разработчики ее не особо читают, полагая что раз они пишут на .net то он сам все какниюудь разрулит.
>Это не проблема C#.
Да. Это проблема культуры разработки под C#, сам C# тут не причем.
Я лишь привел примеры где отладка C# может представлять заметные проблемы.
Имено так.
>Опять-таки, зависит от области деятельности.
Да.
Иными словами имеет место быть сегментация, а не уход с десктопа. То что подходит больше для десктопа остается на нем, а то что больше для мобильных платформ — идет на них.
>Особенно почтового, учитывая наличие стандартных протоколов?
Согласен, этот пример плохой. Стандарное приложение для почты вполне подойдет. Однако если бы это был какойнибудь менее стандартный сервис на котором вы не так плотно сидите, типа планировщика, листа покупок или еще чегонибудь то вполне возможно это былобы аргументом. Скажем так, для меня было бы аргументом.
>если вы предоставляете сервис, а не приложение, то вы вполне переживете все смены клиентских парадигм
Если вашим сервисом будут пользоваться — то да. Обычно к сервису нужно предоставить и каких-то клиентов чтобы им пользовались, и тут появляется вопрос о таких средствах разработки этих клиентов, которые бы позволили затратить минимум усилий на поддержку новых платформ.
С ними все не однозначно. Часть игр удобных под тач, и не требующих продвинутого ввода действительно идет на мобильные платформы, но для немалой части отсутствие мышки и клавиатуры или хотябы джойстика, а также маленький экран сильно портит геймплей.
>если мы про приложения, не требующие какой-то специальной графики
Мы не только про них) Если говорить о приложениях без особой графики и особо продвинутого UI, то да — веб в них имеет свою долю. Но и не все так просто. Если приложение должно что-то делать с данными на вашей файловой системе (а таких приложений не так и мало) то веб приложения начинают сильно проигрывать.
>Почему вы считаете, что отзывчивость интерфейса у нативного приложения выше?
Она потенциально может быть выше, т.к. больше шансов ответить без задержки на ввод из-за меньшего количество прослоек и задержек.
Хотя например некоторые WFP контролы работают медленнее подобных написанных на HTLM + JS. Поэтому в сравнении веб это может быть не так и плохо по отзывчивости, но врядли на wpf в этом вопросе стоит равняться.
>Во-первых, не отобрали
Это только потому что у gamail есть и мобильный и веб клиенты. А вот если бы не было, то может вы бы и перешли на другую почту, ради удобства мобильного пользования.
Месяца 3-4.
>Для GUI работает? Например, high-DPI в Windows и MacOS одинаково себя ведет?
Например для Qt должно бы работать…
doc-snapshots.qt.io/qt5-5.4/highdpi.html
Наверное я плохо сформулировал, имел ввиду что среди Декстопных приложений остаются только нужные на Workstation, а приложения более уместные на планшетах и телефонах — отмирают на десктопе. Но при этом и Workstation приложения не появляются на мобильных устройствах, то есть рынок просто делится.
>Потому что у него более удобный интерфейс и интеграция с телефонными сервисами.
И именно поэтому веб приложения проигрывают многим десктопным приложениям. Еще можно добавить отзывчивость интерфейса. Я кстати думаю что именно приложения для смартфонов и планшетов отобрали часть рынка у веб приложений.
>Вообще распределенная, удаленная и совместная работа.
Dms и PLM системы появились очень давно, и не в вебе… они очень стары…
>Big Data в ее нынешнем понимании.
А какое у нее сейчас понимание? (видел немного разные трактовки...)