Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ага, и в предыдущих более чем 400-а сообщений из ~750 тоже заблудился
И я полагаю, все они про недостатки перфоманса в дотнете?
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.
Все правильно — различные режимы GC могут влиять на перфоманс .NET. Какие из этого надо сделать далекоидущие выводы? У .NET проблемы с перфомансом? Дефолтный режим не всегда оптимален? Еще что нить?
EP>Конечно, если факты не вписываются в твою теорию, то это всё "красноглазики" (кстати, почитай о значении этого мема — ты его применяешь совершенно не тему).
Да, прикинь, то что написано в этих статьях не нужно 99% девов в их ежедневной работы.
Здравствуйте, itslave, Вы писали:
_>>Тот пример я при желание легко (пара строк, причём исключительно средствами самого языка) подправлю так, что он будет работать на всех нужных ОС. А что будешь делать ты со своим WPF приложением? Переписывать с нуля? ))) I>Это ты в примерчике на 20 строк одним махом возьмешь и поправишь. В реальной же проекте портируемость С++ кода выльется в тысячи человекочасов.
Если бы я написал, что у кроссплатформенности на C++ всё идеально, то это конечно же было бы лукавством. Однако и ты похоже даже приблизительно не знаком с темой, о которой ты пишешь. Могу описать как это происходит в реальности.
У меня вот прямо сейчас на руках приложение, которое отлично работает на Android/iOS/Windows/OSX/Linux (теоретически можно ещё и другие платформы, но они уже совсем бессмысленны). Создавалось оно под виндой (т.к. машины разработчиков на ней и получается максимально эффективная работа) с периодической проверкой на реальном Андроид устройстве (чтобы скорректировать особенности мобильных устройств: маленького экрана, сенсорного ввода, дохлого процессора). Далее, когда приложение уже по сути готово, происходила его сборка и тестирование на всех целевых платформах (и разных устройствах, но это уже не по нашей теме). Так вот при этом безусловно вылезает целая куча багов. Причём скорее даже не классических багов (типа вылетов или чего-то подобного), а скорее именно каких-то некорректностей в поведение (ну типа например по разному работающей прозрачности в интерфейсе). И да, это можно назвать недоработкой кроссплатформенности библиотек C++. Однако все эти мелкие косяки правятся где-то за наделю. Да, обычно это делается не красиво (банальными платформенными define'ми, а не багрепортами авторам соответствующих библиотек с ожиданием пару лет исправления), но зато крайне быстро и эффективно. В итоге мы очень быстро получаем работающее кроссплатформенное приложение с единой кодовой базой.
И я не знаю другого инструмента, который смог бы представить хотя бы сравнимый уровень кроссплатформенности (при этом с полным доступом ко всем возможностям платформы). Или быть может ты хочешь сказать, что C# претендует на это? )))
Здравствуйте, itslave, Вы писали:
_>>Ааа, ты про клиентские скрипты на JS? Ну там сейчас творится такой ад (https://habrahabr.ru/post/312022/), что никакого желания даже близко приближаться нет. ))) Для наших внутренних целей хватает нескольких вызовов jquery на страничку, а все эти ужасы живут где-то в параллельной реальности. ))) I>Да, там творится ад и с этим надо как то жить. Питон — не вариант, остается всея надежда что ts выстрелит.
Ну лично мне с этим жить не надо, так что я посматриваю на это всё со стороны, как на шоу. )
Что касается надежд, то мне кажется, что в первую очередь они должны быть обращены к WebAssembly, который позволит покончить с монополией JS на разработку под браузеры. Тогда современные мощные языки и фреймворки быстро разгонят это уютный пикничок js маньяков. ))) Ну естественно если говорить про какие-то сложные проекты — для написания простой странички с одной кнопкой вряд ли можно придумать что-то проще чистого (ну максимум с jquery) JS.
Здравствуйте, itslave, Вы писали:
_>>Ну если не согласен, то тогда назови другую область, в которой по твоему находится большинство разработки на C#. ) I>B2B и прочий ентерпрайз.
Ну так я же именно это и написал. )
I>Только ты наверное пропустил тот момент, когда ентерпрайз попер в веб и "ИТ отдел" из внутренней службы, уменьшающей количество бумажек, и стал основной бизнеса.
Интересно, а в каком-нибудь Газпроме в курсе, что теперь основной их бизнеса является IT отдел? )))
_>Если бы я написал, что у кроссплатформенности на C++ всё идеально, то это конечно же было бы лукавством.
Настолько неидеально, что даже примитивные консольки не портироюстя без специальных приседаний.
_>У меня вот прямо сейчас на руках приложение, которое отлично работает на Android/iOS/Windows/OSX/Linux (теоретически можно ещё и другие платформы, но они уже совсем бессмысленны).
Отличное передергивание. Со стороны C#, ты предлагаешь взять уже готовое виндовое приложение и портировать его. Со стороны С++ ты же говоришь о приложении, которое изначально было портировано. Правильней было бы говорить про виндовом приложение на С++, достаточно немолодом, которое надо внезапно надо портировать на никсы. И в этом случае, я считаю что затраты на портирование будут колоссальными. Сравнимыми с переписыванием с нуля. Тоесть портируемость С++ околонулевая.
_>И я не знаю другого инструмента, который смог бы представить хотя бы сравнимый уровень кроссплатформенности (при этом с полным доступом ко всем возможностям платформы). Или быть может ты хочешь сказать, что C# претендует на это? )))
Java. C# подтянется года через 3, если будет двигаться нынешними темпами. Для low level — чистый С в связке с java. И да, в гугле это отлично понимали, когда делали android.
Здравствуйте, alex_public, Вы писали:
_>Ну лично мне с этим жить не надо, так что я посматриваю на это всё со стороны, как на шоу. )
я рад за тебя.
_>Что касается надежд, то мне кажется, что в первую очередь они должны быть обращены к WebAssembly, который позволит покончить с монополией JS на разработку под браузеры. Тогда современные мощные языки и фреймворки быстро разгонят это уютный пикничок js маньяков. ))) Ну естественно если говорить про какие-то сложные проекты — для написания простой странички с одной кнопкой вряд ли можно придумать что-то проще чистого (ну максимум с jquery) JS.
WebAssembly в массы выйдут лет через 5 имха. Иех, был же Silverlight еще черт знает когда...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Предлагаю тебе всё же начать работать с CEF. Он уже собранный под винду и при этом все нужные внутренности полностью доступны через удобное C++ API. В том числе и вызовы между нативным и JS кодом. S>> А можно поподробнее. Я в этом лузер. Буду премного благодарен.
_>Скачиваешь здесь http://opensource.spotify.com/cefbuilds/index.html нужный тебе вариант. Там главное набор dll (там внутри как раз тот самый уже собранный ужас, который ты пытался собрать сам — их надо положить в дистрибутив твоего приложения), плюс lib и h файлы, которые подключаешь к своему проекту. И дальше используешь довольно удобное API (там есть два варианта: C и C++; если использовать более удобный C++, то надо ещё отдельно подключить в проект его) для работы с теперь встроенным в твоём приложение полноценным браузером. Подробности использования надо конечно смотреть в документации http://magpcss.org/ceforum/apidocs3/, а введение можно глянуть тут https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage. Но в самом начале проще всего открыть их "Sample Application" — это по сути полноценный браузер, написанный в несколько строк с помощью этой библиотеки. )
Я так понял, что Sample Application это скомпилированный tests\cefclient\ ?
Здравствуйте, itslave, Вы писали:
_>>У меня вот прямо сейчас на руках приложение, которое отлично работает на Android/iOS/Windows/OSX/Linux (теоретически можно ещё и другие платформы, но они уже совсем бессмысленны). I>Отличное передергивание. Со стороны C#, ты предлагаешь взять уже готовое виндовое приложение и портировать его. Со стороны С++ ты же говоришь о приложении, которое изначально было портировано.
Ты видимо невнимательно прочитал моё сообщение. Как раз для Линуха (и ещё нескольких платформ) "портировалось" по сути готовое приложение. Так что не вижу разницы в подходах.
I>Правильней было бы говорить про виндовом приложение на С++, достаточно немолодом, которое надо внезапно надо портировать на никсы. И в этом случае, я считаю что затраты на портирование будут колоссальными. Сравнимыми с переписыванием с нуля. Тоесть портируемость С++ околонулевая.
Если это виндовое приложение на C++ изначально было написано с помощью нормальных инструментов (а не какой-нибудь убогой MFC и т.п.), то без проблем заработает после перекомпиляции. А после тестирования и устранение пары мелких шероховатостей (которые наверняка всплывут) можно и в релиз.
_>>И я не знаю другого инструмента, который смог бы представить хотя бы сравнимый уровень кроссплатформенности (при этом с полным доступом ко всем возможностям платформы). Или быть может ты хочешь сказать, что C# претендует на это? ))) I>Java.
Ну и какую же GUI библиотеку ты посоветуешь для такого случая? )
I>C# подтянется года через 3, если будет двигаться нынешними темпами.
Аааа, ну тогда и посмотрим. )))
I>Для low level — чистый С в связке с java. И да, в гугле это отлично понимали, когда делали android.
В Гугле изначально сделали разработку только на Java (Android SDK), но потом (после осознания ошибки) спешно добавили Android NDK. Аналогичный путь (только с заменой Java на C#) был и с WindowsPhone. Все эти истории тебе ни о чём не намекают? )))
Здравствуйте, itslave, Вы писали:
_>>Интересно, а в каком-нибудь Газпроме в курсе, что теперь основной их бизнеса является IT отдел? ))) I>У тебя очень узкое понимание того, что такое enterprise.
Так IT отдел Газпрома не имеет отношения к enterprise? Или что ты хотел сказать?
Здравствуйте, alex_public, Вы писали:
_>Если это виндовое приложение на C++ изначально было написано с помощью нормальных инструментов (а не какой-нибудь убогой MFC и т.п.), то без проблем заработает после перекомпиляции. А после тестирования и устранение пары мелких шероховатостей (которые наверняка всплывут) можно и в релиз.
Отдел фантастики на другом этаже. Доказано твоим же примером. У тебя один косяк на 20 строк кода, экстраполируем это на 100000 строк(что в общем то и немного) — получаем 5000 косяков. Которые надо найти, пофиксать, протестить и так далее. О чем я и говорил — тысячи человекочасов дял портирования.
_>В Гугле изначально сделали разработку только на Java (Android SDK), но потом (после осознания ошибки) спешно добавили Android NDK. Аналогичный путь (только с заменой Java на C#) был и с WindowsPhone. Все эти истории тебе ни о чём не намекают? )))
ДА не то чтобы намекают — прямым текстом пишут:
C library
The C library headers for Android 1.5 are available through their standard names, such as stdlib.h and stdio.h. If a header is missing at build time, it's because the header is not available on the 1.5 system image.
C++ library An extremely minimal C++ support API is available. For more information on C++ library support, see C++ Library Support.
_>Так IT отдел Газпрома не имеет отношения к enterprise? Или что ты хотел сказать?
Я хотел сказать именно то что сказал, а именно, т очто у тебя слишком узкое понимание ентерпрайза. Безусловно IT отдел госпрома — ето ентерпрайз. Но и dropbox.com — это тоже ентерпрайз.
Здравствуйте, Serginio1, Вы писали:
S> Я так понял, что Sample Application это скомпилированный tests\cefclient\ ?
Ага, в виде подготовленного дистрибутива со всеми dll. Т.е. именно в таком виде и должно будет распространяться твоё приложение.
S> Прошу прощения я с C++ кроме VS не работал. Мне надо создать прложение а библиотеки скопировать? S>Просто навравь на путь, а то самому куча времени уходит на поиски.
Пишешь своё приложение на C++. К нему подключаешь (это ты обязан уметь для хотя бы самого начала работы на C/C++): h файлы (из папки include), lib файл (из release), h и cc файлы (из папки libcef_dll, если хочешь использовать C++ API, для использование C API этого не требуется). Собираешь приложение в exe файл и кладёшь в его папку нужные dll из поставки CEF (по примеру того как в Sample Application).
S> А так конечно круть. Мне бы только теперь простенький пример сделать https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md#markdown-header-executing-functions
Ну собственно весь необходимый (для вызовов туда и обратно) код есть прямо по этой ссылке. Так что тебе достаточно просто научиться показывать окно бразуера в своём C++ приложение, а дальше добавить туда эти самые строчки из ссылки и всё заработает. А вот демонстрация окна браузера уже не так проста — тебе же нужен какой-то свои GUI (ну как минимум для создания главного окна, в которое будет рисовать CEF). Можно конечно использовать системный (как сделано в их примере cefclient), но если ты хочешь кроссплатформенности и удобства, то лучше взять какую-то популярную GUI библиотеку для C++.
S>и как отлаживать. Или все в логи?
Здравствуйте, itslave, Вы писали:
I>ДА не то чтобы намекают — прямым текстом пишут: I>
I>C library
I>The C library headers for Android 1.5 are available through their standard names, such as stdlib.h and stdio.h. If a header is missing at build time, it's because the header is not available on the 1.5 system image.
I>C++ library
I>An extremely minimal C++ support API is available. For more information on C++ library support, see C++ Library Support.
Да, у меня тоже как-то был bad experience от сборки чего-то на C++ под Android; но за давностью уже не помню деталей. То ли нельзя было современный C++ использовать, то ли Boost или ещё какие-то библиотеки подключать/линковать. Помню был какой-то кастомный NDK (CrystaX NDK); в целом жуть. Ещё помню, что в документации Google явно рекомендовал не использовать C++/NDK просто потому, что его знаешь — а только в крайнем случае.
Здравствуйте, itslave, Вы писали:
_>>Если это виндовое приложение на C++ изначально было написано с помощью нормальных инструментов (а не какой-нибудь убогой MFC и т.п.), то без проблем заработает после перекомпиляции. А после тестирования и устранение пары мелких шероховатостей (которые наверняка всплывут) можно и в релиз. I>Отдел фантастики на другом этаже. Доказано твоим же примером. У тебя один косяк на 20 строк кода, экстраполируем это на 100000 строк(что в общем то и немного) — получаем 5000 косяков. Которые надо найти, пофиксать, протестить и так далее. О чем я и говорил — тысячи человекочасов дял портирования.
Сразу видно очень опытного в данном вопросе человека. ))) Кстати, сколько Qt или wxWidgets виндовых приложений ты портировал под Линух? )
_>>В Гугле изначально сделали разработку только на Java (Android SDK), но потом (после осознания ошибки) спешно добавили Android NDK. Аналогичный путь (только с заменой Java на C#) был и с WindowsPhone. Все эти истории тебе ни о чём не намекают? ))) I>ДА не то чтобы намекают — прямым текстом пишут: I>
I>C library
I>The C library headers for Android 1.5 are available through their standard names, such as stdlib.h and stdio.h. If a header is missing at build time, it's because the header is not available on the 1.5 system image.
I>C++ library
I>An extremely minimal C++ support API is available. For more information on C++ library support, see C++ Library Support.
I>О чем я и говорю: С++ не нужен.
Ох, ты бы хоть немного разбирался в вопросе. В NDK входит штук 5 разных реализаций стандартной библиотеки C++, большинство из которых обеспечивают не только поддержку самого современного стандарта языка, но и даже экспериментальные функции. Просто выбор данной библиотек остаётся за приложением и соответственно оно таскает эту библиотеку в своём дистрибутиве. Кстати, в точности так же как это происходит и на винде. А то, что ты процитировал — это описание одно из этих 5 библиотек, специализированной минимимизированной библиотеки под названием system.
Здравствуйте, itslave, Вы писали:
_>>Так IT отдел Газпрома не имеет отношения к enterprise? Или что ты хотел сказать? I>Я хотел сказать именно то что сказал, а именно, т очто у тебя слишком узкое понимание ентерпрайза. Безусловно IT отдел госпрома — ето ентерпрайз. Но и dropbox.com — это тоже ентерпрайз.
). Для IT компаний расклады очевидно другие, т.к. у них это основа бизнеса. И как раз такие компании могут себе позволить охоту за высококвалифицированными кадрами.
2. Даже если говорить про dropbox, то непонятно что ты хотел сказать. Насколько я помню у них клиентская часть была написана на Питоне/C++, а серверная часть на Питоне. Потом вроде краем уха слышал, что они переписывали свою серверную часть с Питона на Go ради увеличения быстродействия. И какое это всё имеет отношение к энтерпрайзным Java/C#? )
Эта инструкция тебе вообще не нужна. Это о том как собрать отладочный дистрибутив CEF. А у тебя он уже собран и лежит в папке Debug.
S>Чтобы из VS отлаживать.
Отлаживать что? Свой C++ код? Свой JS код? Или внутренности CEF? )
S> ES6 кстати работает. Проверил. S>Спасибо буду разбираться. Просто иногда проще взять шаблон (для VS их много) и переделывать под себя. S>Поищу может для CEF есть шаблоны.
Я же говорю, тебе надо определиться со способом работы с GUI. Вот например https://github.com/joinAero/qtcefclient простейший вариант на Qt. А в поставку CEF входит пример с использованием нативных функций ОС (но на мой взгляд он ужасен, если говорить именно об этой части).
Здравствуйте, Слава, Вы писали:
V>>Т.е., те фишки ФП, которые не руинят ООП — они в практику дотнета таскаются с удовольствием, смотрю. Остальные практики игнорятся, хотя именно такая реализация параметрического полиморфизма требует именно таких практик. )) С>Я вот не понимаю, о какой технике речь. Поясните, пожалуйста. На примере.
"Словарь операций" умеет работать с некими типами или классом типов. Для статического ресолвинга в дотнете словарь может быть только value-типом.
Возьмем тот же компаратор и метод Sort(IComparer<T> comparer) какого-нить List<T>, изменим сигнатуру метода:
public class List<T> {
public void Sort<Comparer>(Comparer comparer) where Comparer : IComparer<T> {
...
}
...
}
В этом случае можно реализовать Comparer для произвольного типа T, причем сам тип T можно не нагружать реализацией интерфейса IComparable<T>. Если Comparer будет выполнен как value-type, то JIT будет вынужден сгенерировать уникальную реализацию метода Sort, в итоге мы избавляемся от вызовов методов интерфейса IComparer<T>, т.е. от лишней динамики, начинает работать статика и прочий инлайнинг.
Т.е., суть техники в том, что можно разработать некий тип и рядом с ним "словарь" операций над ним.
Схематично:
interface IMath<T>
{
T Add(T a, T b);
T Sub(T a, T b);
T Mul(T a, T b);
T Div(T a, T b);
}
struct VulgarFraction {
public int Numerator, Denominator;
public struct Operations : IMath<VulgarFraction>
, IEqualityComparer<VulgarFraction>
, IComparer<VulgarFraction>
, ...
{
public VulgarFraction Mul(VulgarFraction a, VulgarFraction b) {
return new VulgarFraction { Numerator = a.Numerator*b.Numerator, Denominator = a.Denominator*b.Denominator };
}
...
}
}
Далее. Самих таких "словарей операций" для некоего типа может быть более одного. Например, для простой дроби — с упрощением после каждой операции или без упрощения. С проверкой на переполнение int или без и т.д.
Далее один из таких словарей можно подавать на методы, организованные по принципу доработанной сигнатуры Sort выше.
Например, для встроенных числовых типов дотнета нет никаких ограничений, выраженных в виде интерфейса, позволяющих использовать математические операции, но можно нарисовать для каждого интересующего типа тот самый "словарь операций", реализующий IMath<> и, таким образом, разрабатывать эффективные математические generic-алгоритмы. Разве что потребуется каждый раз подавать этот словарь как аргумент — либо как обычный аргумент, либо как генерик параметр примерно так:
public class OurExtentions {
public T Average<Operations, T>(IEnumerable<T> collection) where Operations : IMath<T>, new() {
Operations ops = new Operations();
...
sum = ops.Add(sum, item);
...
}
}
Ну или можно представить некий сложный алгоритм как объект (структуру) и параметризировать этот объект словарём лишь однажды.
так что я посматриваю на это всё со стороны, как на шоу. )
