>Посмотри на Outlook — там как раз он много бегает в Exchange из UI потока и умудряется дико тупить не загружая процессор и не расходуя память.
Outlook странная софтина, мне кажется если ее нормально переписать с нуля, то можно получить продукт работающий заметно быстрее и отзывчевее, причем тут даже не так важно на чем его переписывать, главное перетрясти архитектуру.
Да и вообще, если говорить о производительности офиса,
Могу сказать что например ворд из Офис 2007 работает на десктопном core i7 c 16 Гб не быстрее(по мноим ощущениям даже медленнее) чем ворд из Офис 97 на ноутбучном PIII 700 с 380Мб памяти.
Это касается и отклика на ввод пользователя и запуска приложения, причем я бы не сказал, что отличиями функционала этих двух продуктов можно объяснить такую разницу во времяни отклика.
В enterprise отзывчивость интерфейса стоит на одном из последних мест в списке приоритетов.
Ведь тот кто за него платит, и тот кто им пользуется — как правило абсолютно разные люди.
(я возможно немного драматизировал ситуацию, но думаю не сильно)
> Почему Java вдруг оказался в другой категории нежели C#?
На это много причин, хотя на Java я писал мало, но по своему небольшому опыту(недавно Android, и лет 15 назад — портирование кое каких расчетов с Java на С++) могу сказать, что и
— она сильно проигрывает в производительности как С++ так и С#
— ее библиотеки просят рефакторинга. Субъективно, даже boost на С++ выглядит более целостным и логичным
У Java есть некоторые плюсы, но по областям применения С# и С++ пересекаются заметно сильнее чем Java и С++, по крайней мере в разработке под Windows.
Но над развитием Java тоже идет работа, возможно даже она станет значительно лучше…
>А где гарантия, что все критичные глюки будут найдены к релизу? К следующему релизу? К бесконечно отдаленному от вас релизу?
Вероятность значительно меньше. Эта вероятность снижается с ростом статистики использования продукта. А до того как продукт будет отрелижен статистики по его использованию будет недостаточно, из-за низкой массовости использования.
Через месяц-другой после релиза она наберется, но набирать ее будете не вы, а сотни и тысячи других людей. А это огромное количество человеко-часов, которое вы врядли способны потратить для быстрой оценки RC своими силами.
>Ну и вы же так ратовали за кроссплатформенность и переносимость C++ — почему вы так зависите от версии конкретной IDE?
Кроссплатформенность и переносимость корее всего будет достижима только на условно «предыдущем» релизе, потому что ваш код должен компилироваться компиляторами на других платформах, где самые новые фичи могут быть еще не реализованы.
>Кстати большинство эмбеда ранее (до 2010 года) было на C без плюсов.
Да, это правда, и наверное кстати так С без плюсов и останется в ряде эмбеда.
Я бы правда не стал говорить что большинство, но действительно много эмбеда используют C причем зачастую вкупе со статической работой с памятью. С++ добавляет некоторый оверхед относительно С, и на дохлом эмбеде это проявляется.
>Ты удивишься, но десктопная программа 95% времени ждет действия пользователя, а серверы более 80% активного времени занимаются склейкой строк для генерации ответов на HTTP.
Да не, не удивлюсь — тут все вполне логично. Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.
>Сначала неплохо бы выяснить, а есть ли критичные глюки.
Смотря сколько ресурсов надо потратить на это выяснение. И где гарантия что вы найдете все глюки критичные глюки входе этого выяснения?
Есть немалая вероятность что до критичного вы дойдете только к релизу, а там будет уже поздно менять платформу.… Мало радости быть первооткрывателем глюка, пока не набралось достаточно статистики по борьбе с ними…
Хотя это вопрос стратегии конечно, более рискованные стратегии могут быть более «прибыльными».
>Ок, а для каких НЕ пойдет?
Не скажу точно. Вообще, если он написан на С, то вполне возможно пойдет почти везде, только если на очень дохлом железе в ресурсы упрется.
>К C++17 язык догонит сегодняшние современные языки.
Да, скорее всего. И дальше будет вопрос как разовьются современные языки к моменту выхода C++17.
Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет? Особенно если производительность железа не сильно вырастет…
Если вы точно уверены, что вам не надо будет выпускаться до того как будут устранены критичные глюки то можно работать и на RC.
Но вот если вам надо будет выпуститься до этого, то вполне возможно придется задерживать релиз, и это является серьезным риском, на мой взгляд.
Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?
>Остальное и так все было.
и datagridtemplatecolumn-ы были и биндинг на контролы в них?
>В общем, я думаю что где-то у вас в коде зарылась ошибка. С виртуализацией такой DataGrid вообще не тормозит — визуальное дерево обновляется только для того, чтобы покрыть видимую область.
Видимо нужно найти время и тот проект, и выцепить грид оттуда
C++11 и C++0x это же вроде синонимы? Да и 5 лет не такой большой срок по меркам истории развития С++.
И самое главное, например в Visual Studio поддерживается только С++11, и то не полностью
blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
msdn.microsoft.com/en-us/library/hh567368.aspx
Какой смысл ссылаться на C++14 и C++17, если основное средство разработки под Windows их пока не держит?
> Я видел AutoCad на WPF, который вполне прилично работал
Я такого AutoCad-а ни разу не видел :) во всех все что я видел от 2009 до 2016-го ядро чтения файла было написано на С++, рендеринг тоже, а на WPF была написана только некоторая часть UI. (В UI там вообще зоопарк)
> Проснись. На intel edison пишут вообще на NodeJS.
Справедливости ради да, NodeJS используется как средство разработки встраимого ПО, правда не уверен что это подойдет для любых платформ.
> Ты банально повторяешь штампы 2005 года. А на дворе 2015…
Некоторые вещи изменились с 2005, некоторые нет… конечно что-то я не знаю.
Но раз все так хорошо, зачем развивают С++, откуда вообще эти планы на С++17?
Вот скриншот
i61.tinypic.com/f00uwo.png
Снапшута профайлера во время скроллинга вертикальным скроллером вверх и вниз. Лаги при этом страшные(без профайлера разумеется)
(почемуто у меня нормально картинка в пост не вставилась :( )
Outlook странная софтина, мне кажется если ее нормально переписать с нуля, то можно получить продукт работающий заметно быстрее и отзывчевее, причем тут даже не так важно на чем его переписывать, главное перетрясти архитектуру.
Да и вообще, если говорить о производительности офиса,
Могу сказать что например ворд из Офис 2007 работает на десктопном core i7 c 16 Гб не быстрее(по мноим ощущениям даже медленнее) чем ворд из Офис 97 на ноутбучном PIII 700 с 380Мб памяти.
Это касается и отклика на ввод пользователя и запуска приложения, причем я бы не сказал, что отличиями функционала этих двух продуктов можно объяснить такую разницу во времяни отклика.
Ведь тот кто за него платит, и тот кто им пользуется — как правило абсолютно разные люди.
(я возможно немного драматизировал ситуацию, но думаю не сильно)
В данном случае да, — Visual Studio от остальных платформ.
И в целом соглашусь, что С++11 можно считать новым только судя по Visual Studio.
На это много причин, хотя на Java я писал мало, но по своему небольшому опыту(недавно Android, и лет 15 назад — портирование кое каких расчетов с Java на С++) могу сказать, что и
— она сильно проигрывает в производительности как С++ так и С#
— ее библиотеки просят рефакторинга. Субъективно, даже boost на С++ выглядит более целостным и логичным
У Java есть некоторые плюсы, но по областям применения С# и С++ пересекаются заметно сильнее чем Java и С++, по крайней мере в разработке под Windows.
Но над развитием Java тоже идет работа, возможно даже она станет значительно лучше…
Кстати, а что можно почитать по правильной конфигурации кэша дла Sharepoint 2013?
>Битрикс Корп Портал
Спасибо, интересная информация.
Вероятность значительно меньше. Эта вероятность снижается с ростом статистики использования продукта. А до того как продукт будет отрелижен статистики по его использованию будет недостаточно, из-за низкой массовости использования.
Через месяц-другой после релиза она наберется, но набирать ее будете не вы, а сотни и тысячи других людей. А это огромное количество человеко-часов, которое вы врядли способны потратить для быстрой оценки RC своими силами.
>Ну и вы же так ратовали за кроссплатформенность и переносимость C++ — почему вы так зависите от версии конкретной IDE?
Кроссплатформенность и переносимость корее всего будет достижима только на условно «предыдущем» релизе, потому что ваш код должен компилироваться компиляторами на других платформах, где самые новые фичи могут быть еще не реализованы.
Да, это правда, и наверное кстати так С без плюсов и останется в ряде эмбеда.
Я бы правда не стал говорить что большинство, но действительно много эмбеда используют C причем зачастую вкупе со статической работой с памятью. С++ добавляет некоторый оверхед относительно С, и на дохлом эмбеде это проявляется.
>Ты удивишься, но десктопная программа 95% времени ждет действия пользователя, а серверы более 80% активного времени занимаются склейкой строк для генерации ответов на HTTP.
Да не, не удивлюсь — тут все вполне логично. Продолжил бы, что для десктопной программы, как правило, быстрый отклик важнее чем для серверной.
Смотря сколько ресурсов надо потратить на это выяснение. И где гарантия что вы найдете все глюки критичные глюки входе этого выяснения?
Есть немалая вероятность что до критичного вы дойдете только к релизу, а там будет уже поздно менять платформу.… Мало радости быть первооткрывателем глюка, пока не набралось достаточно статистики по борьбе с ними…
Хотя это вопрос стратегии конечно, более рискованные стратегии могут быть более «прибыльными».
Не скажу точно. Вообще, если он написан на С, то вполне возможно пойдет почти везде, только если на очень дохлом железе в ресурсы упрется.
>К C++17 язык догонит сегодняшние современные языки.
Да, скорее всего. И дальше будет вопрос как разовьются современные языки к моменту выхода C++17.
Я как-бы пытаюсь разобрать именно долгосрочные перспективы, не станет ли С++ более актуальным через 3-5 лет? Особенно если производительность железа не сильно вырастет…
Но вот если вам надо будет выпуститься до этого, то вполне возможно придется задерживать релиз, и это является серьезным риском, на мой взгляд.
Кстати интересно, а почему в 2010м активизировалась разработка фич С++, как вы думаете?
Это кросплатформенная С++ библиотека, кстати разработка по ней вполне жива
www.fltk.org/index.php
Там конечно нельзя по-простому делать всякие WPF-овские красивости и нет биндингов, но UI написанный на ней крайне отзывчивый.
Вообще говоря, с рядом релизов студии работать нельзя до первого сервис пака.
Конечно риск дело благородное, но использовать сырые продукты для работы я бы крайне не рекомендовал.
и datagridtemplatecolumn-ы были и биндинг на контролы в них?
>В общем, я думаю что где-то у вас в коде зарылась ошибка. С виртуализацией такой DataGrid вообще не тормозит — визуальное дерево обновляется только для того, чтобы покрыть видимую область.
Видимо нужно найти время и тот проект, и выцепить грид оттуда
И самое главное, например в Visual Studio поддерживается только С++11, и то не полностью
blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx
msdn.microsoft.com/en-us/library/hh567368.aspx
Какой смысл ссылаться на C++14 и C++17, если основное средство разработки под Windows их пока не держит?
Нужно либо передавать размер буфера и проверять его на стороне того кто его заполняет, либо аллоцировать буфер на стороне того кто его заполняет.
Я такого AutoCad-а ни разу не видел :) во всех все что я видел от 2009 до 2016-го ядро чтения файла было написано на С++, рендеринг тоже, а на WPF была написана только некоторая часть UI. (В UI там вообще зоопарк)
> Проснись. На intel edison пишут вообще на NodeJS.
Справедливости ради да, NodeJS используется как средство разработки встраимого ПО, правда не уверен что это подойдет для любых платформ.
> Ты банально повторяешь штампы 2005 года. А на дворе 2015…
Некоторые вещи изменились с 2005, некоторые нет… конечно что-то я не знаю.
Но раз все так хорошо, зачем развивают С++, откуда вообще эти планы на С++17?