Nokia is pleased to announce that with the release of Qt 4.5 you will
be able to use Qt under the Lesser General Public License (LGPL)
version 2.1 terms. When released in March 2009, Qt will be made
available under three licensing options: Commercial, LGPL and GPL.
Prior versions of Qt are not impacted by this announcement.
Nokia is committed to Qt and its continued development. By offering Qt
under LGPL version 2.1 license terms alongside today’s licensing
options Nokia hopes to:
— facilitate wider adoption of Qt across industries, desktop, web and
embedded platforms.
— establish Qt as a de facto standard for application development.
— receive more valuable feedback and increased user contributions to
ensure that Qt remains the best-in-class, cross-platform framework.
— extend Nokia’s existing platform commitment to the open source
community.
By offering a cost-free LGPL license as well as commercial and GPL
licenses to Qt, you can choose the license model that best fits your
development requirements.
15.01.09 04:48: Перенесено модератором из 'C/C++' — Кодт
Здравствуйте, Cyberax, Вы писали:
C>Ура, товарищи!
Молодцы ребята с Нокии.
Вспоминаю, сколько было криков, когда нокия троллей выкупила, что все будущие версии qt будут только коммерческими и т.п.
А тут вот какое счастье!
Ждем гном на Qt
Здравствуйте, Mr.Cat, Вы писали:
MC>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы? Why would I want to buy a commercial license? What is the difference?
The commercial Qt license includes email support, access to upgrades and allows you to develop fully closed source software. The LGPL carries some restrictions regarding the ability for users to relink libraries and other restrictions that may impose architectural requirements that some organizations might not be comfortable with. http://www.qtsoftware.com/about/licensing/frequently-asked-questions#why-would-i-want
Ну и да, это новый этап в развитии. На самом кутэ много нокия не заработает, андроиды и айфоны вытеснят её из рынка софта под встроенные системы.
А так у нее появился шанс.
Здравствуйте, Mr.Cat, Вы писали:
MC>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы?
Комерческая — это страховка. Они смогут сделать чисто комерческий форк Qt. Плюс полагаю останется комерческая поставка, в которой будет QtScript и QtDesigner.
А GPL\LGPL потому что хочет многа-многа приложений для своих смартов.
Существенно поменялось здесь только то, что они открывают GPL\LGPL версии Qt для развития сообществом и то, что теперь можно использовать Qt для комерческого софта.
Здравствуйте, Mazay, Вы писали:
MC>>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы? M>Комерческая — это страховка. Они смогут сделать чисто комерческий форк Qt.
Не смогут. Есть такая замечательная вещь — договор между Trolltech и KDE. По нему предусматривается, что QT будет перелицензирована под BSD, если Trolltech (или компания, которая её купит) перестанет её развивать.
Здравствуйте, dont.avt, Вы писали: C>>Ура, товарищи!
DA>Молодцы ребята с Нокии. DA>Вспоминаю, сколько было криков, когда нокия троллей выкупила, что все будущие версии qt будут только коммерческими и т.п. DA>А тут вот какое счастье! DA>Ждем гном на Qt
Еще будет... Сначала QT будет бесплатной, пока не просочится в многие долгосрочные проекты, а потом станет платной и канторам прийдется раскошеливатся что бы получать фиксы и апргрейды..
Здравствуйте, DIMEDROLL, Вы писали:
DIM>Здравствуйте, dont.avt, Вы писали: C>>>Ура, товарищи!
DA>>Молодцы ребята с Нокии. DA>>Вспоминаю, сколько было криков, когда нокия троллей выкупила, что все будущие версии qt будут только коммерческими и т.п. DA>>А тут вот какое счастье! DA>>Ждем гном на Qt
DIM>Еще будет... Сначала QT будет бесплатной, пока не просочится в многие долгосрочные проекты, а потом станет платной и канторам прийдется раскошеливатся что бы получать фиксы и апргрейды..
Это врядли. Во-первых железячным конторам (коей безусловно является Нокиа) опен-сорс — выгоден. Во-вторых это не так-то просто закрыть открытое )
Здравствуйте, Константин Б., Вы писали:
КБ>Это врядли. Во-первых железячным конторам (коей безусловно является Нокиа) опен-сорс — выгоден. Во-вторых это не так-то просто закрыть открытое )
Это чем же опенсор им выгоден? Платить ЗП разработчикам и раздавать библиотеки нашару?
Здравствуйте, DIMEDROLL, Вы писали:
DIM>Это чем же опенсор им выгоден? Платить ЗП разработчикам и раздавать библиотеки нашару?
Зато боьлше ПО будет под платформу. Они же не на ПО деньги делают, а на устройствах. ПО они чисто в нагрузку создают...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, DIMEDROLL, Вы писали:
DIM>Еще будет... Сначала QT будет бесплатной, пока не просочится в многие долгосрочные проекты, а потом станет платной и канторам прийдется раскошеливатся что бы получать фиксы и апргрейды..
Некоторые компании такое пробовали сделать. В итоге получали форк последней открытой ветки. А в то, что для QT найдётся достаточно OpenSource-разработчиков, я уверен на 100%.
Здравствуйте, DIMEDROLL, Вы писали:
DIM>Здравствуйте, Константин Б., Вы писали:
КБ>>Это врядли. Во-первых железячным конторам (коей безусловно является Нокиа) опен-сорс — выгоден. Во-вторых это не так-то просто закрыть открытое ) DIM>Это чем же опенсор им выгоден? Платить ЗП разработчикам и раздавать библиотеки нашару?
Простая экономика. Софт+Железо — товары-комплементы. Рост спроса на одно увеличвает спрос на другое.
Здравствуйте, MasterZiv, Вы писали:
>> Ура, товарищи! MZ>А так ли он хорош, чтобы так радоваться ?
Для С++ — это лучший фреймворк. У него только один недостаток — он сам виджеты рисует. Хотя и делает это очень качественно.
Здравствуйте, Cyberax, Вы писали:
C>Для С++ — это лучший фреймворк. У него только один недостаток — он сам виджеты рисует. Хотя и делает это очень качественно.
А почему это недостаток? Для переносимого GUI, возможно, это вообще самый разумный путь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Mr.Cat, Вы писали:
MC>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы?
Для Нокии продажа Qt за бапки — не ее бизнес. Самой Нокии Qt явно нужна в качестве платформы, а не в качестве товара.
А смысл коммерческой лицензии в том, чтобы компании, не доверяющие опенсорсу, могли пользоваться Qt на привычных им условиях, т.е. за бапки. Ну и плюс, за бапки вы получаете не только лиценсию на софтварий, а еще и поддержку.
Здравствуйте, Cyberax, Вы писали:
>>> Ура, товарищи! MZ>>А так ли он хорош, чтобы так радоваться ? C>Для С++ — это лучший фреймворк. У него только один недостаток — он сам виджеты рисует. Хотя и делает это очень качественно.
т.е. вообще не нарисовать свой убер-контрол?.
толи я чего то не понял, толи набор контролов становится ограничен тем, что предлагает Qt..
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Cyberax, Вы писали:
>>>> Ура, товарищи! MZ>>>А так ли он хорош, чтобы так радоваться ? C>>Для С++ — это лучший фреймворк. У него только один недостаток — он сам виджеты рисует. Хотя и делает это очень качественно.
F>т.е. вообще не нарисовать свой убер-контрол?. F>толи я чего то не понял, толи набор контролов становится ограничен тем, что предлагает Qt..
Нет. Набор контролов неограничен, но те что есть могут отличаться от стандартных контролов.
Здравствуйте, Константин Б., Вы писали:
F>>т.е. вообще не нарисовать свой убер-контрол?. F>>толи я чего то не понял, толи набор контролов становится ограничен тем, что предлагает Qt.. КБ>Нет. Набор контролов неограничен, но те что есть могут отличаться от стандартных контролов.
нет ли здесь опечатки?.
я не понял, объясни, пожалуйста, на пальцах..
хочу вот я контрол, который выглядит как белый квадратик, а когда я нажимаю на него в разных местах, то там внутри контрола рисуются черные кружочки.. такое возможно?.
есть там аналог OnPaint(PaintDC*) ?.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
F>>>т.е. вообще не нарисовать свой убер-контрол?. F>>>толи я чего то не понял, толи набор контролов становится ограничен тем, что предлагает Qt.. КБ>>Нет. Набор контролов неограничен, но те что есть могут отличаться от стандартных контролов.
F>нет ли здесь опечатки?.
F>я не понял, объясни, пожалуйста, на пальцах..
Ну например Qt-шный едит-бокс может оличаться по внешнему виду и поведению от стандартного виндового.
Здравствуйте, Cyberax, Вы писали:
C>>>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы? M>>Комерческая — это страховка. Они смогут сделать чисто комерческий форк Qt. C>Не смогут. Есть такая замечательная вещь — договор между Trolltech и KDE. По нему предусматривается, что QT будет перелицензирована под BSD, если Trolltech (или компания, которая её купит) перестанет её развивать.
neFormal пишет:
> т.е. вообще не нарисовать свой убер-контрол?. > толи я чего то не понял, толи набор контролов становится ограничен тем, > что предлагает Qt..
Имелось в виду видимо, что даже на винде, где есть свои контролы в
OS он тем не менее будет рисовать свои собственные, а не использовать
стандартные.
Финляндия, маленькая страна с 5-миллионным населением — второй раз спасает весь мир от давления майкрософта.
Первый раз — когда финн Линус Торвальдс осмелился написать бесплатную и открытую операционную систему, выйти против монстроидально устрашающего конкурента Microsoft Windows.
Второй раз — сейчас, финская компания Nokia купила целую фирму, чтобы сделать бесплатной для коммерческого использования самую лучшую кросс-платформенную библиотеку GUI для C++.
Таким образом, на MFC писать уже становится менее выгодно. А на .NET тем более.
Хорошо сказано древними: по плодам узнаете их. Финны — очень честный народ. Поэтому не удивительно. По индексу стран с самым низким уровнем коррупции Финляндия всегда занимала одно из первых мест. Всякое дерево доброе приносит и плоды добрые.
Здравствуйте, Anonim12, Вы писали:
A>От себя могу добавить:
A>Финляндия, маленькая страна с 5-миллионным населением — второй раз спасает весь мир от давления майкрософта.
A>Первый раз — когда финн Линус Торвальдс осмелился написать бесплатную и открытую операционную систему, выйти против монстроидально устрашающего конкурента Microsoft Windows.
A>Второй раз — сейчас, финская компания Nokia купила целую фирму, чтобы сделать бесплатной для коммерческого использования самую лучшую кросс-платформенную библиотеку GUI для C++.
A>Таким образом, на MFC писать уже становится менее выгодно. А на .NET тем более.
A>Хорошо сказано древними: по плодам узнаете их. Финны — очень честный народ. Поэтому не удивительно. По индексу стран с самым низким уровнем коррупции Финляндия всегда занимала одно из первых мест. Всякое дерево доброе приносит и плоды добрые.
Ну вот. И сюда добрались любители реконструировать историю
"Mr.Cat" <64543@users.rsdn.ru> wrote in message news:3247919@news.rsdn.ru...
>А в чем тогда будет смысл коммерческой лицензии? Или нокия поняла, что на qt много не заработаешь и решила начать двигать его в массы?
Я думаю им просто западло инсталляторы переделывать забесплатно Вот второй Карбид Нокия тоже теперь нахаляву раздает, а едишенов так три штуки и осталось — хотя в младшем, который раньше служил в качестве первой бесплатной дозы, теперь смысла точно нет никакого
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
"Qbit86" <70337@users.rsdn.ru> wrote in message news:3249605@news.rsdn.ru...
> S>Вот второй Карбид Нокия... > > «Карбид нокия» — это что-то из химии? Соль какая-то?
Да, смешно получилось IDE это такая, на базе Eclipse, для разработки под симбиан.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Qbit86, Вы писали:
A>>Таким образом, на MFC писать уже становится менее выгодно. А на .NET тем более.
Q>М? В смысле «тем более»? На WPF писать проще, чем на Qt.
WPF не то же самое, что и Qt. Помимо того, что Qt реально кроссплатформенная, есть еще такой момент:
1. Найди электронную книжку на 3-4 Мб текста.
2. Открой демо-приложения с ричэдитом на Qt, WPF, ну и еще что-нибудь — Winword, Wordpad, Sciter, textarea в IE, Firefox.
3. Вставь туда этот текст, сделай Ctrl+A и Ctrl+B (все жирным).
4. Погляди на объемы использованной памяти, закрой зависшее WPF-приложение, сними футлобку с надписью «microsoft» и отложи в долгий ящик до лучших времен.
5. Пойди загляни в глаза тому, кто говорил, что 50 Мб используемой памяти вместо 5 на MFC, это копейки, когда на компе «аж целых 2 Гб»
Здравствуйте, Кодёнок, Вы писали:
Кё>1. Найди электронную книжку на 3-4 Мб текста. Кё>2. Открой демо-приложения с ричэдитом на Qt, WPF, ну и еще что-нибудь — Winword, Wordpad, Sciter, textarea в IE, Firefox. Кё>3. Вставь туда этот текст, сделай Ctrl+A и Ctrl+B (все жирным). Кё>4. Погляди на объемы использованной памяти, закрой зависшее WPF-приложение, сними футлобку с надписью «microsoft» и отложи в долгий ящик до лучших времен. Кё>5. Пойди загляни в глаза тому, кто говорил, что 50 Мб используемой памяти вместо 5 на MFC, это копейки, когда на компе «аж целых 2 Гб»
Вообще, дельная идея, сейчас в TODO запишу. Реальных и правдоподобных сравнений производительности пока не встречал.
По своему опыту могу сказать, что рисование в WPF вполне себе быстрое, оно использует напрямую Direct3D, и НЕ использует прямо или косвенно через интероп Win32 (User32), GDI, GDI+.
Кё>есть еще такой момент:
Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Кодёнок, Вы писали:
Кё>>1. Найди электронную книжку на 3-4 Мб текста. Кё>>2. Открой демо-приложения с ричэдитом на Qt, WPF, ну и еще что-нибудь — Winword, Wordpad, Sciter, textarea в IE, Firefox. Кё>>3. Вставь туда этот текст, сделай Ctrl+A и Ctrl+B (все жирным). Кё>>4. Погляди на объемы использованной памяти, закрой зависшее WPF-приложение, сними футлобку с надписью «microsoft» и отложи в долгий ящик до лучших времен. Кё>>5. Пойди загляни в глаза тому, кто говорил, что 50 Мб используемой памяти вместо 5 на MFC, это копейки, когда на компе «аж целых 2 Гб»
Q>Вообще, дельная идея, сейчас в TODO запишу. Реальных и правдоподобных сравнений производительности пока не встречал.
Q>По своему опыту могу сказать, что рисование в WPF вполне себе быстрое, оно использует напрямую Direct3D, и НЕ использует прямо или косвенно через интероп Win32 (User32), GDI, GDI+.
Кё>>есть еще такой момент:
Q>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие) — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов. То можешь сам посчитать производительность каждой компоненты, умножить на N и получить рузультат
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
Q>>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
DV>это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие)
«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы.
DV> — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов.
Что-то я с этим сложноподчинённым предложением запутался.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Denys V., Вы писали:
Q>>>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо.
DV>>это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие)
Q>«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы.
а я WPF туда же... в туже топку
DV>> — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов.
Q>Что-то я с этим сложноподчинённым предложением запутался.
Приложение = П
Компоненты = К
П = К1 + К2 + К3 + ... + КN
Возьмем к примеру такой параметр как отжирание памяти
упустим что не все компоненты могут быть активны одновременно. Будем считать что у нас все работают одновременно.
тогда Память отжираемая приложением — это сумма объемов памяти каждой из компонент.
Соответственно. если все компоненты написаны на wpf — получим один результат. если на wpf — другой.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
Q>>«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы.
DV>а я WPF туда же... в туже топку ;)
И Qt туда же? Или на Qt проще CD-ejector'ы писать? Или сложнее? Не запутался?
DV>Возьмем к примеру такой параметр как отжирание памяти... DV>Соответственно. если все компоненты написаны на wpf — получим один результат. если на c++ — другой.
«Другой» — какой? С памятью у C++ не всё просто, потому что стандартный аллокатор памяти (MSVC++ Runtime) работает в общем случае медленнее .NET'овского. Т. к. проходится по списку чанков, порой даже за линейное время. А в .NET выделение памяти — мгновенный инкремент (правда, для выделения очень больших кусков в CLR применяется другой алгоритм).
Здравствуйте, Denys V., Вы писали:
DV>Возьмем к примеру такой параметр как отжирание памяти
Я могу проще объяснить.
WTL-приложение кушает 6 Мб — копейки. WPF-приложение — 60 Мб, копейки (типичный аргумент про .Net — «сколько у вас памяти? 2 Гб? и, что, 60 Мб у вас вызывают проблемы?»)
Подвергаем приложение чуть большей нагрузке. Умножаем на 10. WTL-приложение — 60 Мб, копейки остались копейками. WPF — 600 Мб. Копейки превратились в околопредельную нагрузку. На практике — 600 Мб плюс долгие зависания на секунды, пока GC по этим 600 Мб прошаривается.
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, Qbit86, Вы писали: Q>>Здравствуйте, Denys V., Вы писали: Q>>>>Есть и другой момент помимо производительности программы — производительность программиста. На WPF она выше, имхо. DV>>>это преимущество имеет место быть востребованным в случае если твоя команда занимается штампованием прог аля CD-ejector (смотри простенькие) Q>>«Штампованием CD-ejector'ов» можно и на Дельфи заниматься, так что мимо кассы. DV>а я WPF туда же... в туже топку
Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
Кроме того WPF — не только desktop, есть еще и Silverlight.
DV>>> — ибо если ты таким образом налабаеш сложное приложение, состоящее из N компонентов. Q>>Что-то я с этим сложноподчинённым предложением запутался.
DV>Приложение = П DV>Компоненты = К
DV>П = К1 + К2 + К3 + ... + КN
DV>Возьмем к примеру такой параметр как отжирание памяти
Вот что меня всегда поражало в программиста на С++ — всегда меряются объемами пожираемой памяти. Причем не в масштабе всего приложения, а в маленьких примерах.
Сообщаю новость. Времена когда память была серьезны ограничением давно прошли.
DV>упустим что не все компоненты могут быть активны одновременно. Будем считать что у нас все работают одновременно. DV>тогда Память отжираемая приложением — это сумма объемов памяти каждой из компонент.
Так наверное в Adobe посчитали когда писали Photoshop (который на С++ и кроссплатформенный), который грузится секунд 30, хавает 200 метров памяти и показывает пустой воркспейс.
Paint.NET при этом запускается 3 секунды и отжирает порядка 20 метров.
Откуда цифры взяты? Эти 60 Мб — это данные программы, или это суммарный объём только гуёвых контролов? Или что?
Кё>(типичный аргумент про .Net — «сколько у вас памяти? 2 Гб? и, что, 60 Мб у вас вызывают проблемы?»)
Типичный аргумент против .NET — это что у него с памятью проблемы. Причём в большинстве случаев предъявы никак не обоснованы, на уровне урбан мифов. У .NET потенциальные проблемы — долгая «холодная» загрузка, притормаживание при первом вызове для JIT-компиляции, возможно, общий abstraction penalty (зачастую последний пренебрежимо мал). Но все почему-то цепляются к этой памяти.
Кё>На практике — 600 Мб плюс долгие зависания на секунды, пока GC по этим 600 Мб прошаривается.
Ты уверен в вине сборщика в этих долгих зависаниях? Подробности работы GC помню не очень хорошо, но Рихтер, емнип, говорит, что для сборщика есть верхняя граница времени работы (предопределённая константа). Если не успел собрать за отведённое время, то «долгие секунды шариться» не будет — отложит. В Java, возможно, иначе.
Кстати, формула некорректная. Если один компонент тратит X ресурсов, то два компонента вовсе не обязательно тратят 2X ресурсов, обычно гораздо меньше. Потому что какие-то вещи между ними шарятся, например, библиотеки дважды подгружаться не будут. Увеличение числа компонентов только удешевляет «удельную стоимость» каждого.
Здравствуйте, gandjustas, Вы писали:
G>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах.
G>Кроме того WPF — не только desktop, есть еще и Silverlight.
Qt — это не только desktop, но и embedded systems.
Будет ли работать аппаратное ускорение в WPF в Silverlight? А на Windows Mobile? А на платформах, отличных от Windows?
Здравствуйте, Сергей, Вы писали:
С>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах.
OpenGL имеет дело только с трехмерным рисованием и предоставляет очень слабую поддержку (или не предоставляет её вовсе) для решения проблем GUI-программирования.
Всё-таки, гуи в Qt может быть аппаратно ускорен? Насколько просто это сделать?
"Qbit86" <70337@users.rsdn.ru> wrote in message news:3249898@news.rsdn.ru... > Здравствуйте, Сергей, Вы писали: > > С>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. > > Полез за пруфлинком, первая ссылка в Гугле:
> OpenGL имеет дело только с трехмерным рисованием и предоставляет очень слабую поддержку (или не предоставляет её вовсе) для решения проблем GUI-программирования.
Это немного не про то ссылка.
> Всё-таки, гуи в Qt может быть аппаратно ускорен? Насколько просто это сделать?
Здравствуйте, gandjustas, Вы писали:
G>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
А всё очень просто. Эпоха инноваций заканчивается. И начинается эпоха ОПТИМИЗАЦИИ и РАЦИОНАЛИЗАЦИИ.
1) Cкорость написания программ на Qt достаточно высокая, чтобы охарактиризовать процесс как Rapid Application Development
2) И код генерируется рационально — как с точки зрения скорости исполнения, так и объёма бинарника.
И несоменно, главное преимущество — кроссплатформенность.
Здравствуйте, gandjustas, Вы писали:
G>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
Скажите пожалуйста, как эти все бантики и украшательства с шейдерами, аппаратным ускорением пригодятся для конкретной серьёзной работы, например рядовому бухгалтеру с медленной видеокартой? Вы ему в будущем что ли предложите бегать по трёхмерным комнатам с виртуальными столами, в поисках отчётов, и с трехмерными формами для заполнения? Так ведь в истории уже были попытки сделать что-то похожее — но почему-то подобные "инновации" оказались просто невостребованными.
Использовать 2D контролы QT для работы — очень практично и удобно. К тому же, есть и возможность нарисовать собственные — а потом опубликовать для коммьюнити и совместными усилиями их улучшать. Ведь в принципе ничего больше и не нужно.
А если говорить о трёхмерных игрушках или каких-то сложных средствах визуализации для Direct3D с помощью WPF, то в этой области уже есть готовые альтернативные решения для абстрагирования от Direct3D, позволяющие разрабатывать приложения одновременно и под DirectX в Windows и под OpenGL в Linux и MacOS X. Например, бесплатные для коммерческого использования, открытые кроссплатформенные библиотеки irrlicht, ogre3d — уже отлично позволяют это делать. В irrlicht (лицензия типа BSD) кроме поддержки аппаратных Direct3D и OpenGL, .NET language binding, даже есть ультрабыстрый software renderer — что вообще позволяет охватить максимальное количество десктопов (Platform independent. Runs on Windows95, 98, NT, 2000, XP, Linux, OSX, Solaris, and others).
G>Кроме того WPF — не только desktop, есть еще и Silverlight.
IMHO, а в этой области я вообще предпочитаю ещё дополнительно прислушиваться к мнению Google.
Здравствуйте, Sergey, Вы писали:
>> С>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах.
S>Пишут что да: http://doc.trolltech.com/4.4/qt-embedded-opengl.html
Про Windows, Linux и MacOS там не написано, только про embedded. Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть :)
Здравствуйте, Anonim12, Вы писали:
A>Казалось бы, при чём тут .NET ?
А ещё в этой ветке слишком мало Nemerle. Требую больше Nemerle!
A>А всё очень просто. Эпоха инноваций заканчивается. И начинается эпоха ОПТИМИЗАЦИИ и РАЦИОНАЛИЗАЦИИ.
Причём, не столько оптимизации бинарника, сколько рационализации труда разработчика.
A>1) Cкорость написания программ на Qt достаточно высокая, чтобы охарактиризовать процесс как Rapid Application Development
Кстати, как выглядит байндинг на Qt? Скажем, надо привязвть двусторонней привязкой View к ViewModel, например, текстбокс к полю типа «дата/время» (не знаю, как в Qt соотв. класс называется). В WPF привязки можно делать как декларативно, так и по старинке (в коде). Можно пример на Qt?
Здравствуйте, Anonim12, Вы писали:
A>Казалось бы, при чём тут .NET ?
A>А всё очень просто. Эпоха инноваций заканчивается. И начинается эпоха ОПТИМИЗАЦИИ и РАЦИОНАЛИЗАЦИИ.
Эпоха ОПТИМИЗАЦИИ закочилась 25-30 лет назад.
A>1) Cкорость написания программ на Qt достаточно высокая, чтобы охарактиризовать процесс как Rapid Application Development
Вау. С++ за черт знает сколько лет дорос до RAD. Это когда от RAD многие отказываются ибо "программирование мышкой" годится только для создания простых программ или прототипов.
A>2) И код генерируется рационально — как с точки зрения скорости исполнения, так и объёма бинарника.
Не совсем рационально. Не используется параллелизм и декларативно его задать не получится.
A>И несоменно, главное преимущество — кроссплатформенность.
Призрачно преимущество. Даже кроссплатформенные GUI фреймворки не делают приложения автоматически кроссплатформенными, в очень многих случаях окружение также надо учитывать.
A>Здравствуйте, gandjustas, Вы писали:
G>>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
A>Скажите пожалуйста, как эти все бантики и украшательства с шейдерами, аппаратным ускорением пригодятся для конкретной серьёзной работы, например рядовому бухгалтеру с медленной видеокартой?
Затем же зечем и Qt — абсолютно не зачем.
Я вообще имею стойкое убеждение что все приложения, не требующие красивой графики и обработки обработки больших объемов данных на клиентской стороне, должы быть Web-based.
A>Использовать 2D контролы QT для работы — очень практично и удобно. К тому же, есть и возможность нарисовать собственные — а потом опубликовать для коммьюнити и совместными усилиями их улучшать. Ведь в принципе ничего больше и не нужно.
Не нужно для чего?
Для бизнес-приложений вообще не нужен десктопный клиент. Там, где задействуется графика — лучше WPF.
A>А если говорить о трёхмерных игрушках или каких-то сложных средствах визуализации для Direct3D с помощью WPF, то в этой области уже есть готовые альтернативные решения для абстрагирования от Direct3D, позволяющие разрабатывать приложения одновременно и под DirectX в Windows и под OpenGL в Linux и MacOS X. Например, бесплатные для коммерческого использования, открытые кроссплатформенные библиотеки irrlicht, ogre3d — уже отлично позволяют это делать. В irrlicht (лицензия типа BSD) кроме поддержки аппаратных Direct3D и OpenGL, .NET language binding, даже есть ультрабыстрый software renderer — что вообще позволяет охватить максимальное количество десктопов (Platform independent. Runs on Windows95, 98, NT, 2000, XP, Linux, OSX, Solaris, and others).
Игрушки с 3D графикой на WPF делать не стоит. А вот редактор моделей для этой игрушке вполне можно изобразить на WPF.
А то что касается игрушек — на PDC был доклад про Mono, там показан был фреймворк для разработки игр (на C#), которые запускаются как под маком,виндовс, linux и даже на iPhone.
G>>Кроме того WPF — не только desktop, есть еще и Silverlight. A>IMHO, а в этой области я вообще предпочитаю ещё дополнительно прислушиваться к мнению Google.
А что гугл говорит по этому поводу? Правильно — ничего. Нету у гугла Rich Internet Application платформы.
Здравствуйте, Qbit86, Вы писали:
Q>Кстати, как выглядит байндинг на Qt? Скажем, надо привязвть двусторонней привязкой View к ViewModel, например, текстбокс к полю типа «дата/время» (не знаю, как в Qt соотв. класс называется). В WPF привязки можно делать как декларативно, так и по старинке (в коде). Можно пример на Qt?
"Qbit86" <70337@users.rsdn.ru> wrote in message news:3249945@news.rsdn.ru... > Здравствуйте, Sergey, Вы писали: > >>> С>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. > > S>Пишут что да: http://doc.trolltech.com/4.4/qt-embedded-opengl.html > > Про Windows, Linux и MacOS там не написано, только про embedded.
Никто не обещает, что ускорение будет под все платформы, под которые есть qt — по вполне очевидным причинам. Но нетрудно догадацца, что под платформы, под которые QT умеет OpenGL, будет работать и QOpenGLPaintEngine.
А вообще там пишут что и Direct3D под винду имеется:
Constant Value Description
QPaintEngine::X11 0
QPaintEngine::Windows 1
QPaintEngine::MacPrinter 4
QPaintEngine::CoreGraphics 3 Mac OS X's Quartz2D (CoreGraphics)
QPaintEngine::QuickDraw 2 Mac OS X's QuickDraw
QPaintEngine::QWindowSystem 5 Qt for Embedded Linux
QPaintEngine::PostScript 6
QPaintEngine::OpenGL 7
QPaintEngine::Picture 8 QPicture format
QPaintEngine::SVG 9 Scalable Vector Graphics XML format
QPaintEngine::Raster 10
QPaintEngine::Direct3D 11 Windows only, Direct3D based engine
QPaintEngine::Pdf 12 Portable Document Format
QPaintEngine::User 50 First user type ID
QPaintEngine::MaxUser 100 Last user type ID
> Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть
Да-да, использовать QOpenGLPaintEngine в качестве QPaintEngine — это так страшно
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3249976@news.rsdn.ru...
> A>А всё очень просто. Эпоха инноваций заканчивается. И начинается эпоха ОПТИМИЗАЦИИ и РАЦИОНАЛИЗАЦИИ. > Эпоха ОПТИМИЗАЦИИ закочилась 25-30 лет назад.
Насмешил. Ага, еще скажи што памяти всегда любому приложению хватает, дали 3 гига и больше не понадобится
> G>>Кроме того WPF — не только desktop, есть еще и Silverlight. > A>IMHO, а в этой области я вообще предпочитаю ещё дополнительно прислушиваться к мнению Google. > А что гугл говорит по этому поводу? Правильно — ничего. Нету у гугла Rich Internet Application платформы.
А GWT не считается?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Здравствуйте, gandjustas, Вы писали:
G>>>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
RO>>Ну, может предложить такое, например: RO>> RO>>http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/
G>Мда.. они наконец изобрели wolfenstein 3d
G>Лучше смотрите это
вы сравнили божий дар с яичницей...
Там есть видео в 3D сцене??? Или вэб-браузер??? Или Rich Text control? или...
Где все???
Молодцы. Наконецто создали игру вчерашнего дня и на Сильверлайт. На чем только не переписывали бедную кваку Посмотрите остальные игры — они все на С++ (практически)
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, gandjustas, Вы писали:
G>Сообщаю новость. Времена когда память была серьезны ограничением давно прошли.
Да, память это не очень сереьзное ограничение, но поскольку большинство так думает,
то в итоге на моем компе с 2 гигами памяти, нормально работать можно максимум с 2-мя приложениями (VisualStudio и UML tool).
Я конечно могу еще гиг докупить и тогда можно будет еще Word запустить...
В общем вермена, когда надо было биться за каждый байт, давно прошли,
но то, что твориться сейчас — это тоже ненормально.
Здравствуйте, gandjustas, Вы писали:
A>>А всё очень просто. Эпоха инноваций заканчивается. И начинается эпоха ОПТИМИЗАЦИИ и РАЦИОНАЛИЗАЦИИ. G>Эпоха ОПТИМИЗАЦИИ закочилась 25-30 лет назад.
Здравствуйте, Denys V., Вы писали:
G>>Мда.. они наконец изобрели wolfenstein 3d
G>>Лучше смотрите это
DV>вы сравнили божий дар с яичницей...
Да, всего-то квака в браузере... на каждом углу валяется.
DV>Там есть видео в 3D сцене??? Или вэб-браузер??? Или Rich Text control? или... DV>Где все???
Веб браузер есть в самом веб-браузере, в silverlight он не нужен.
Rich Text в стандартной поставке нет, но на просторах инета пару раз такой контрол видел.
DV>Молодцы. Наконецто создали игру вчерашнего дня и на Сильверлайт. На чем только не переписывали бедную кваку
И на чем?
DV>Посмотрите остальные игры — они все на С++ (практически)
Я вас сильно расстрою, но на C++ только графический движок, который достаточно долго разрабатывается, и то не всегда, физика (реже) и логика(почти всегда) делается на более высокоуровневых языках.
И со временем управляемые языки все больше вытесняют неупавляемые даже из этих областей.
Например Mono векторные операции делает быстрее, чем аналогичная реализация на C++.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Сообщаю новость. Времена когда память была серьезны ограничением давно прошли.
B>Да, память это не очень сереьзное ограничение, но поскольку большинство так думает, B>то в итоге на моем компе с 2 гигами памяти, нормально работать можно максимум с 2-мя приложениями (VisualStudio и UML tool). B>Я конечно могу еще гиг докупить и тогда можно будет еще Word запустить...
У меня открыто 2 студии, браузер, Word и Remote Desktop, а в фоне SQL Server шуршит и это на машине с 2 гигами памяти, занято 80% и нормально.
B>В общем вермена, когда надо было биться за каждый байт, давно прошли, B>но то, что твориться сейчас — это тоже ненормально.
А вас волнует цифирка в TaskManager или быстродействие? Обычно в компромисе время-память выбирают время.
Здравствуйте, catBasilio, Вы писали:
B>Здравствуйте, Qbit86, Вы писали:
Q>>М? В смысле «тем более»? На WPF писать проще, чем на Qt.
B>Ссылкой где качнуть WPF для C++ не поделишься?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Denys V., Вы писали:
G>>>Мда.. они наконец изобрели wolfenstein 3d
G>>>Лучше смотрите это
DV>>вы сравнили божий дар с яичницей... G>Да, всего-то квака в браузере... на каждом углу валяется.
Ага. Даже на ява-скрипте где-то есть.
DV>>Там есть видео в 3D сцене??? Или вэб-браузер??? Или Rich Text control? или... DV>>Где все??? G>Веб браузер есть в самом веб-браузере, в silverlight он не нужен. G>Rich Text в стандартной поставке нет, но на просторах инета пару раз такой контрол видел.
Ты просил hardware-accelerated UI. Тебе его показали. Что не так-то?
Или тебя то, что пример похож на wolfenstein 3d смущает? Так это тока по геймплейной части, по графике вульфенштейн был куда хуже
Здравствуйте, bkat, Вы писали:
B>Да, память это не очень сереьзное ограничение, но поскольку большинство так думает, B>то в итоге на моем компе с 2 гигами памяти, нормально работать можно максимум с 2-мя приложениями (VisualStudio и UML tool). B>Я конечно могу еще гиг докупить и тогда можно будет еще Word запустить...
B>В общем вермена, когда надо было биться за каждый байт, давно прошли, B>но то, что твориться сейчас — это тоже ненормально.
Qt представляется оптимальным решением:
— высокая скорость разработки,
— высокая скорость выполнения программ,
— рациональное использование ресурсов (оперативной памяти и дискового пространства),
— кроссплатформенность (Windows, Linux, MacOSX),
— открытый исходный код библиотеки,
— библиотека за много лет хорошо оттестирована и стабильно работает,
— большая база пользователей,
— библиотека удачно запроектирована, и поэтому замечена хорошая динамика её развития (от версии к версии поддерживает всё новые особенности операционных систем, а также хорошо зарекоммендованные сторонние библиотеки, к примеру в мартовской версии 4.5 будет добавлена поддержка Qt WebKit — то на чём написан Google Chrome, поддержка нового Cocoa API на 64-битных маках).
И ещё, за спиной у Qt теперь стоит корпорация Nokia, а это уже намного более серьёзный маркетинг.
Anonim12 пишет:
> Второй раз — сейчас, *финская* компания Nokia купила целую фирму, чтобы > сделать бесплатной для коммерческого использования самую лучшую > кросс-платформенную библиотеку GUI для C++.
Ну, что-то я восторгов-то по поводу QT не разделяю. Такое же MFC, только
кроссплатформенное.
DV>>>вы сравнили божий дар с яичницей... G>>Да, всего-то квака в браузере... на каждом углу валяется. КБ>Ага. Даже на ява-скрипте где-то есть.
Ссылку в студию.
DV>>>Там есть видео в 3D сцене??? Или вэб-браузер??? Или Rich Text control? или... DV>>>Где все??? G>>Веб браузер есть в самом веб-браузере, в silverlight он не нужен. G>>Rich Text в стандартной поставке нет, но на просторах инета пару раз такой контрол видел.
КБ>Ты просил hardware-accelerated UI. Тебе его показали. Что не так-то?
И шейдеры поддерживает?
КБ>Или тебя то, что пример похож на wolfenstein 3d смущает? Так это тока по геймплейной части, по графике вульфенштейн был куда хуже
И не сомневаюсь что более чем через 20 лет графику можно было продкрутить.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Denys V., Вы писали:
G>>>Мда.. они наконец изобрели wolfenstein 3d
G>>>Лучше смотрите это
DV>>вы сравнили божий дар с яичницей... G>Да, всего-то квака в браузере... на каждом углу валяется.
DV>>Там есть видео в 3D сцене??? Или вэб-браузер??? Или Rich Text control? или... DV>>Где все??? G>Веб браузер есть в самом веб-браузере, в silverlight он не нужен.
Это разные подходы. Я вам не об идеологии а возможностях движка. Есть возможность у Silverlite отрендерить окно браузера в 3Д сцене?
G>Rich Text в стандартной поставке нет, но на просторах инета пару раз такой контрол видел.
в 3Д сцене??? не верю — покажите.
DV>>Молодцы. Наконецто создали игру вчерашнего дня и на Сильверлайт. На чем только не переписывали бедную кваку G>И на чем?
Да хоть бы и на Java. поищите в интернете — там их много уже.
DV>>Посмотрите остальные игры — они все на С++ (практически) G>Я вас сильно расстрою, но на C++ только графический движок, который достаточно долго разрабатывается, и то не всегда, физика (реже) и логика(почти всегда) делается на более высокоуровневых языках. G>И со временем управляемые языки все больше вытесняют неупавляемые даже из этих областей.
G>Например Mono векторные операции делает быстрее, чем аналогичная реализация на C++.
Ссылку на тест плиз. я хочу посмотреть на "аналогичную" реализацию на С++.
И меня не нужно расстраивать ибо что на чем и для чего пишется в геймдеве я знаю .
Физика на управляемом языке? Это какой же физический движок на нем??? Ссылку плиз.
О логике не спорю — быстрее менять, быстрее эксперементировать... Интерфейс также часто делается к примеру на Flash. Я ж не говорю что у управляемых языков нету своей ниши (правда python либо lua я б даже и не звал управляемыми). Она есть, будет и будет шире чем сейчас. Но вы меня не убедили и не убедите, что нужно писать performance зависимые вещи на управляемых языках. Возможно в далеком будущем (теоретически) — но не сейчас.
Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно.
но это уже большой HW получается и не в той ветке...
Выйдет Qt под LGPL — лучше об этом. А не о .Net и иже с ними
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Qbit86 пишет:
> Ты уверен в вине сборщика в этих долгих зависаниях? Подробности работы > GC помню не очень хорошо, но Рихтер, емнип, говорит, что для сборщика > есть верхняя граница времени работы (предопределённая константа). Если > не успел собрать за отведённое время, то «долгие секунды шариться» не > будет — отложит. В Java, возможно, иначе.
Гы, отложить-то он отложит, а вот где память-то взять, если нужна ?
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, gandjustas, Вы писали:
G>>У меня открыто 2 студии, браузер, Word и Remote Desktop, а в фоне SQL Server шуршит и это на машине с 2 гигами памяти, занято 80% и нормально. 8>Замете (ну и слово), ни одно из этих приложений не напсинано на .Net
Еще раз пример с фотошопом и Paint.NET привести?
8>p/s 8>спор-то у вас бестолковый и очень боянистый.
Угу
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, gandjustas, Вы писали:
G>>А вас волнует цифирка в TaskManager или быстродействие? Обычно в компромисе время-память выбирают время.
DV>Когда приложение начинает свопить от недостатка памяти — оно тормозит — тогда меня очень интерессует злосчастное число в таск менеджере
И как число в TaskManager связано со свопингом?
Здравствуйте, gandjustas, Вы писали:
КБ>>Ты просил hardware-accelerated UI. Тебе его показали. Что не так-то? G>И шейдеры поддерживает?
ДА
мы их используем.
Я в QtOpenGL могу сделать все что в OGL.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Denys V., Вы писали:
DV>>Здравствуйте, gandjustas, Вы писали:
G>>>А вас волнует цифирка в TaskManager или быстродействие? Обычно в компромисе время-память выбирают время.
DV>>Когда приложение начинает свопить от недостатка памяти — оно тормозит — тогда меня очень интерессует злосчастное число в таск менеджере G>И как число в TaskManager связано со свопингом?
Очень просто.
[offtop]
Ну почему я должен объяснять такие элементарные вещи!
Или я какой то не тот термин употребил?
Тада заранее сорри.
[/offtop]
Допустим у меня Windows на тачке с 500Мб ОЗУ и 500Мб своп файл.
Допустим у меня запущено 3 приложения по 200 Мб каждое.
в cумме 600Мб.
Соответственно одно неактивное приложение (а то и 2 — ещё ж системные сервисы всякие) ляжет в своп.
Когда я захочу переключиться на это приложение — оно начнется оттуда подниматься и тормозить.
Так вот если б каждое из этих 3 приложений занимало по 20Мб в памяти — все было б БЫСТРО и красиво.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Чукча не читатель? «A Wolfenstein like maze theme was chosen because of ease of implementation, you could of course embed a widget onto any 3d surface».
Вопрос был в том, поддерживает ли Qt аппаратное ускорение. Еще и как поддерживает, включая даже третье измерение. Позволяет делать штуки наподобие Cover Flow в Mac OS.
Посмотри видео по ссылке, там, где в конце рекурсия. Вряд ли такое возможно реализовать с помощью WPF.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, 8bit, Вы писали:
8>>Здравствуйте, gandjustas, Вы писали:
G>>>У меня открыто 2 студии, браузер, Word и Remote Desktop, а в фоне SQL Server шуршит и это на машине с 2 гигами памяти, занято 80% и нормально. 8>>Замете (ну и слово), ни одно из этих приложений не напсинано на .Net G>Еще раз пример с фотошопом и Paint.NET привести?
кстати
Photoshop стал использовать мега языки впоследнее время... Наблюдается тенденция
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Denys V., Вы писали:
G>>>>Мда.. они наконец изобрели wolfenstein 3d
G>>>>Лучше смотрите это
DV>>>вы сравнили божий дар с яичницей... G>>Да, всего-то квака в браузере... на каждом углу валяется.
DV>>>Там есть видео в 3D сцене??? Или вэб-браузер??? Или Rich Text control? или... DV>>>Где все??? G>>Веб браузер есть в самом веб-браузере, в silverlight он не нужен. DV>Это разные подходы. Я вам не об идеологии а возможностях движка. Есть возможность у Silverlite отрендерить окно браузера в 3Д сцене?
G>>Rich Text в стандартной поставке нет, но на просторах инета пару раз такой контрол видел. DV>в 3Д сцене??? не верю — покажите.
Вам окно браузера или редактор в 3d сцене нужен?
В Silverlight 2 вообще поддержки 3d нету, там на процессоре все работает. 3D только в третьем сильверлайте будет.
DV>>>Молодцы. Наконецто создали игру вчерашнего дня и на Сильверлайт. На чем только не переписывали бедную кваку G>>И на чем? DV>Да хоть бы и на Java. поищите в интернете — там их много уже.
И все в браузере работают?
DV>>>Посмотрите остальные игры — они все на С++ (практически) G>>Я вас сильно расстрою, но на C++ только графический движок, который достаточно долго разрабатывается, и то не всегда, физика (реже) и логика(почти всегда) делается на более высокоуровневых языках. G>>И со временем управляемые языки все больше вытесняют неупавляемые даже из этих областей. G>>Например Mono векторные операции делает быстрее, чем аналогичная реализация на C++. DV>Ссылку на тест плиз. я хочу посмотреть на "аналогичную" реализацию на С++.
DV>И меня не нужно расстраивать ибо что на чем и для чего пишется в геймдеве я знаю . DV>Физика на управляемом языке? Это какой же физический движок на нем??? Ссылку плиз.
Это надо на XNA смотреть, что там с физикой у них, я не сильно в курсе.
DV>О логике не спорю — быстрее менять, быстрее эксперементировать... Интерфейс также часто делается к примеру на Flash. Я ж не говорю что у управляемых языков нету своей ниши (правда python либо lua я б даже и не звал управляемыми).
То что ипользует свою виртуальную машину или интерпетатор — управляемый.
DV>Она есть, будет и будет шире чем сейчас. Но вы меня не убедили и не убедите, что нужно писать performance зависимые вещи на управляемых языках.
Более высокий уровень абстракции позволяет делать такие оптимизации, которые неуправляемым языкам и не снились. Например исполнение части кода (написанного на самом языке) на видеокарте, декларативное распараллеливание и прочие радости.
DV>Возможно в далеком будущем (теоретически) — но не сейчас.
Ну да, года через 2-3. (Хинт: если вы хотите года через 2-3 выпустить свой продукт, то стоит заниматься новыми технологиями уже сейчас).
DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно.
Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти. Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Посмотри видео по ссылке, там, где в конце рекурсия. Вряд ли такое возможно реализовать с помощью WPF.
Возможно. WPF тоже позволяет делать 3D-преобразования над виджетами. У него похожая идеология.
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, gandjustas, Вы писали:
G>>Еще раз пример с фотошопом и Paint.NET привести?
8>Это про то кто дольше грузиться и сколько при старте памяти сжирает? Совершенно глупый пример.
Чем глупый? Окна-то одинаковые показываются.
8>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти.
Вообще странно что вы это утверждаете. Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, 8bit, Вы писали:
8>>>Здравствуйте, gandjustas, Вы писали:
G>>>>У меня открыто 2 студии, браузер, Word и Remote Desktop, а в фоне SQL Server шуршит и это на машине с 2 гигами памяти, занято 80% и нормально. 8>>>Замете (ну и слово), ни одно из этих приложений не напсинано на .Net G>>Еще раз пример с фотошопом и Paint.NET привести?
DV>кстати DV>Photoshop стал использовать мега языки впоследнее время... Наблюдается тенденция
на C++ он написан. javascript у него только для скриптинга.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250476@news.rsdn.ru...
> DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно. > Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти.
Или чем 20 гигов памяти, да? А ниче, что железо, которое 20 гигов умеет, уже стоит на порядок дороже обычного?
> Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов.
да-да, пара гигов * 10000 персоналок — скока стоит? Все еще дешевле месяца работы?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Erop, Вы писали:
C>>Для С++ — это лучший фреймворк. У него только один недостаток — он сам виджеты рисует. Хотя и делает это очень качественно. E>А почему это недостаток? Для переносимого GUI, возможно, это вообще самый разумный путь...
На Mac'е, например, QT-шные приложения выглядят не совсем нативно. На Windows это тоже очень чувствуется. Впрочем, они становятся лучше от версии к версии.
PS: интересно, кто напишет первый "ribbon" для QT?
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Denys V., Вы писали:
DV>>>Здравствуйте, gandjustas, Вы писали:
G>>>>А вас волнует цифирка в TaskManager или быстродействие? Обычно в компромисе время-память выбирают время.
DV>>>Когда приложение начинает свопить от недостатка памяти — оно тормозит — тогда меня очень интерессует злосчастное число в таск менеджере G>>И как число в TaskManager связано со свопингом?
DV>Очень просто.
Да вот не совсем просто. См ниже.
DV>Допустим у меня Windows на тачке с 500Мб ОЗУ и 500Мб своп файл. DV>Допустим у меня запущено 3 приложения по 200 Мб каждое.
200 мб COMMITED памяти или RESERVED, или это WorkSet ? Кстати какое чило в TaskManager отображается?
DV>в cумме 600Мб.
DV>Соответственно одно неактивное приложение (а то и 2 — ещё ж системные сервисы всякие) ляжет в своп.
В своп лягут все 3, такова стратегия работы свопа.
DV>Когда я захочу переключиться на это приложение — оно начнется оттуда подниматься и тормозить.
Ну это если понадобится поднимать все страницы из свопа.
DV>Так вот если б каждое из этих 3 приложений занимало по 20Мб в памяти — все было б БЫСТРО и красиво.
Опять зависит от термина "занимало".
Кстати, вы много приложений знаете, которые с ходу 200 метров хавают? Из них на .NET сколько?
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250476@news.rsdn.ru...
>> DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно. >> Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти.
S>Или чем 20 гигов памяти, да? А ниче, что железо, которое 20 гигов умеет, уже стоит на порядок дороже обычного?
>> Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов.
S>да-да, пара гигов * 10000 персоналок — скока стоит? Все еще дешевле месяца работы?
Обычно не один программист и не один месяц работает.
Здравствуйте, gandjustas, Вы писали:
B>>Да, память это не очень сереьзное ограничение, но поскольку большинство так думает, B>>то в итоге на моем компе с 2 гигами памяти, нормально работать можно максимум с 2-мя приложениями (VisualStudio и UML tool). B>>Я конечно могу еще гиг докупить и тогда можно будет еще Word запустить... G>У меня открыто 2 студии, браузер, Word и Remote Desktop, а в фоне SQL Server шуршит и это на машине с 2 гигами памяти, занято 80% и нормально.
Ужас.
У меня запущено: текстовый редактор (с десяток файлов), растровый графический редактор (5 файлов), Inkscape (векторный редактор), Scribus (издательская система). Плеер, почтовик, клиент Jabber, отслеживатель времени. Серверы SSH, СУБД, SMTP, HTTP, memcached. 449 МБ. ЧЯДНТ?
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
DV>>>Возможно в далеком будущем (теоретически) — но не сейчас. G>>Ну да, года через 2-3.
С>Про .NET это говорят уже лет пять.
Здравствуйте, gandjustas, Вы писали:
8>>Это про то кто дольше грузиться и сколько при старте памяти сжирает? Совершенно глупый пример. G>Чем глупый? Окна-то одинаковые показываются.
все-таки силверлайт убивает ваш мозг
8>>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти. G>Вообще странно что вы это утверждаете. Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, gandjustas, Вы писали:
B>>>Да, память это не очень сереьзное ограничение, но поскольку большинство так думает, B>>>то в итоге на моем компе с 2 гигами памяти, нормально работать можно максимум с 2-мя приложениями (VisualStudio и UML tool). B>>>Я конечно могу еще гиг докупить и тогда можно будет еще Word запустить... G>>У меня открыто 2 студии, браузер, Word и Remote Desktop, а в фоне SQL Server шуршит и это на машине с 2 гигами памяти, занято 80% и нормально.
RO>Ужас.
RO>У меня запущено: текстовый редактор (с десяток файлов), растровый графический редактор (5 файлов), Inkscape (векторный редактор), Scribus (издательская система). Плеер, почтовик, клиент Jabber, отслеживатель времени. Серверы SSH, СУБД, SMTP, HTTP, memcached. 449 МБ. ЧЯДНТ?
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250523@news.rsdn.ru...
>>> DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно. >>> Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти. > > S>Или чем 20 гигов памяти, да? А ниче, что железо, которое 20 гигов умеет, уже стоит на порядок дороже обычного? > >>> Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов. > > S>да-да, пара гигов * 10000 персоналок — скока стоит? Все еще дешевле месяца работы? > > > Обычно не один программист и не один месяц работает.
"Месяц работы программиста, который будет сэкономлен" — ты ж сам сказал, что разница месяц, нет?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, gandjustas, Вы писали:
8>>>Это про то кто дольше грузиться и сколько при старте памяти сжирает? Совершенно глупый пример. G>>Чем глупый? Окна-то одинаковые показываются.
8>все-таки силверлайт убивает ваш мозг
8>>>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти. G>>Вообще странно что вы это утверждаете. Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
8>
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250523@news.rsdn.ru...
>>>> DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно. >>>> Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти. >> >> S>Или чем 20 гигов памяти, да? А ниче, что железо, которое 20 гигов умеет, уже стоит на порядок дороже обычного? >> >>>> Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов. >> >> S>да-да, пара гигов * 10000 персоналок — скока стоит? Все еще дешевле месяца работы? >> >> >> Обычно не один программист и не один месяц работает.
S>"Месяц работы программиста, который будет сэкономлен" — ты ж сам сказал, что разница месяц, нет?
Это же от масштабов проекта зависит. Месяц это минимум.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250557@news.rsdn.ru...
> S>"Месяц работы программиста, который будет сэкономлен" — ты ж сам сказал, что разница месяц, нет? > Это же от масштабов проекта зависит. Месяц это минимум.
Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250557@news.rsdn.ru...
>> S>"Месяц работы программиста, который будет сэкономлен" — ты ж сам сказал, что разница месяц, нет? >> Это же от масштабов проекта зависит. Месяц это минимум.
S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать.
Поспорить тут можно только если на C# никогда не писал.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250557@news.rsdn.ru...
>> S>"Месяц работы программиста, который будет сэкономлен" — ты ж сам сказал, что разница месяц, нет? >> Это же от масштабов проекта зависит. Месяц это минимум.
S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах.
Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше. А .NET вам в случае ошибки четко покажет где она произошла, и выдаст адекватный stack trace.
Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти, динамически генерировать код и тому подобное. Это позволяет использовать архитектурные приемы недоступные неуправляемым языкам.
В совокупности может огромный прирост производительности программиста дать.
Кстати, вы на .NET работали?
S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать.
А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
Здравствуйте, gandjustas, Вы писали:
G>Слив засчитан.
Ой, вот только давайте без этого.
8>>>>Это про то кто дольше грузиться и сколько при старте памяти сжирает? Совершенно глупый пример. G>>>Чем глупый? Окна-то одинаковые показываются.
Гупый потому что сравниваете не сравниваемое.
Надо было сразу написать вот так:
Если приложение на .Net НЕ запускать, то запуск займет 0 времени и приложение займет 0 памяти,
а приложение на C++ если запустить, займет Х памяти и Y времени. Понимаете абсурдность?
А чушь типа "Окна-то одинаковые показываются", ну ни в какие ворота.
Хотите я на .Net напишу приложение которое будет открываться три дня и сожрет памяти по максимуму возможного,
но при этом окна-то одинаковые будут.
8>>>>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти. G>>>Вообще странно что вы это утверждаете. Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
Прочитайте про устройство GC. Или разработчики на .Net в такие подробности не лезут?
У вас вот уже пошли условия какие-то:
Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
А 3 мелких приложения на .Net сожрут памяти как одно крупное на C++ ? Или как?
Здравствуйте, 8bit, Вы писали:
G>>Еще раз пример с фотошопом и Paint.NET привести?
8>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти.
Вполне возможен случай, когда .NET-приложение будет требовать меньше памяти, чем Си-приложение, за счёт более плотной упаковки объектов. При этом выделение объектов на куче осуществляется быстрее, показатели временной и пространственной локальности лучше (⇒ меньше кэш-миссов).
Для сравнения посмотрим, как выделяется память в куче исполняющей среды С. Чтобы выделить в куче память для объекта, исполняющая среда С должна пройти по связному списку структур данных. Обнаружив свободный блок достаточного размера, среда разбивает его, модифицируя указатели в узлах связного списка, чтобы сохранить его целостность. Для сравнения: в случае управляемой кучи выделение памяти для объекта означает просто прибавление некоторого значения к указателю, что намного быстрее. По сути, объект в управляемой куче выделяется почти так же быстро, как память в стеке потока! Кроме того, в большинстве куч (таких как куча исполняющей среды С) память для объектов выделяется в любой свободной области. Поэтому вполне вероятно, что несколько последовательно созданных объектов окажутся разделенными мегабайтами адресного пространства. Но в управляемой куче последовательно созданные объекты гарантирован но будут расположены друг за другом.
(Зелёная Книжка Рихтера)
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, gandjustas, Вы писали:
G>>Слив засчитан. 8>Ой, вот только давайте без этого.
Ну зачем тогда вместо ответов на вопросы смайлики рисовать?
8>>>>>Это про то кто дольше грузиться и сколько при старте памяти сжирает? Совершенно глупый пример. G>>>>Чем глупый? Окна-то одинаковые показываются.
8>Гупый потому что сравниваете не сравниваемое. 8>Надо было сразу написать вот так: 8>Если приложение на .Net НЕ запускать, то запуск займет 0 времени и приложение займет 0 памяти, 8>а приложение на C++ если запустить, займет Х памяти и Y времени. Понимаете абсурдность?
Абсурдность ваших слов понимаю.
8>А чушь типа "Окна-то одинаковые показываются", ну ни в какие ворота. 8>Хотите я на .Net напишу приложение которое будет открываться три дня и сожрет памяти по максимуму возможного, 8>но при этом окна-то одинаковые будут.
Я не уверен что авторы фотошопа делали его тормозящим специально.
8>>>>>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти. G>>>>Вообще странно что вы это утверждаете. Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
8>Прочитайте про устройство GC. Или разработчики на .Net в такие подробности не лезут?
Да я хорошо устройство GC знаю, но где написано что не очищает память?
8>У вас вот уже пошли условия какие-то: 8>
8>Крупные программы на .NET кушают не больше памяти, чем аналогичные на C++.
8>А 3 мелких приложения на .Net сожрут памяти как одно крупное на C++ ? Или как?
Может так, может наоборот, это смотря как писать.
Здравствуйте, gandjustas, Вы писали: G>>>Слив засчитан. 8>>Ой, вот только давайте без этого. G>Ну зачем тогда вместо ответов на вопросы смайлики рисовать?
Дык, смешно потому что.
8>>>>>>Это про то кто дольше грузиться и сколько при старте памяти сжирает? Совершенно глупый пример. G>>>>>Чем глупый? Окна-то одинаковые показываются. 8>>Гупый потому что сравниваете не сравниваемое. 8>>Надо было сразу написать вот так: 8>>Если приложение на .Net НЕ запускать, то запуск займет 0 времени и приложение займет 0 памяти, 8>>а приложение на C++ если запустить, займет Х памяти и Y времени. Понимаете абсурдность? G>Абсурдность ваших слов понимаю. 8>>А чушь типа "Окна-то одинаковые показываются", ну ни в какие ворота. 8>>Хотите я на .Net напишу приложение которое будет открываться три дня и сожрет памяти по максимуму возможного, 8>>но при этом окна-то одинаковые будут. G>Я не уверен что авторы фотошопа делали его тормозящим специально.
и все таки .Net убивает ваш мозг.
8>>Прочитайте про устройство GC. Или разработчики на .Net в такие подробности не лезут? G>Да я хорошо устройство GC знаю
Плохо вы его знаете, плохо.
Здравствуйте, gandjustas, Вы писали:
B>>В общем вермена, когда надо было биться за каждый байт, давно прошли, B>>но то, что твориться сейчас — это тоже ненормально. G>А вас волнует цифирка в TaskManager или быстродействие? Обычно в компромисе время-память выбирают время.
Вообще-то именно быстродействие и волнует.
Я вообщем как юзер на ситуацию смотрю.
Цифиркb в TaskManager'е меня интерсуют только тогда, когда я пытаюсь понять,
что мне лучше закрыть, чтобы можно было нормально работать.
Ну а как программист, я просто вижу, что если о ресурсах вообще не думать,
и каждый будет так поступать, то в итоге юзеры тоже замечают, что 2 гига что-то маловато стало.
Здравствуйте, 8bit, Вы писали:
8>и все таки .Net убивает ваш мозг.
В первой версии был Silverlight.
8>>>Прочитайте про устройство GC. Или разработчики на .Net в такие подробности не лезут? G>>Да я хорошо устройство GC знаю 8>Плохо вы его знаете, плохо.
А вы прям специалист?
Короче не пишите больше в этой теме, все равно ни одного здравого аргумента привести не можете.
Здравствуйте, Qbit86, Вы писали:
Q>Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть
А кто-нибудь может показать пример, где использование OpenGL/Direct3d ускорило какой-нибудь обычный гуевый контрол? Неужели рисование какого-нибудь radio button'a путем формирования серии треугольников и пересылки их видеокарте быстрее обычного растрового рисования? Контролы же обычно небольшие, чего там ускорять-то? И вообще, так ли часто отрисовка гуя занимает хоть сколь-нибудь заметное время на современных компах? Не припомню такого у обычных win32 приложений. В WinForms, помнится, были жалобы на медленный расчет layout'a, но его видеокарта быстрее не сделает..
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250615@news.rsdn.ru...
> S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. > Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше.
Да-да, даже наследования реализации нету — а кода меньше писать, ага.
> А .NET вам в случае ошибки четко покажет где она произошла, и выдаст адекватный stack trace.
Адекватный стек трейс у меня на плюсах выдается уже лет десять.
> Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти,
Не парится по поводу выделяемой памяти в моем случае возможно только при переходе на x64 — чего в силу некоторых особенностей лицензионной политики MS пока не случилось. Трех гигов в вин32 хватает с трудом.
> динамически генерировать код и тому подобное.
И часто вам приходится динамически генерировать код?
> Это позволяет использовать архитектурные приемы недоступные неуправляемым языкам.
Какие конкретно архитектурные приемы?
> В совокупности может огромный прирост производительности программиста дать.
Или не дать
> Кстати, вы на .NET работали?
Не особо много — не понравилось.
> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. > А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, 8bit, Вы писали:
8>>Это вы к чему?
Q>Ещё раз засчитан.
И мне плиз засчитайте, ибо надоело уже.
Уже и на пальцах объясняли и к RTFM аппелировали...
Предлагаю прекратить спор, ибо возможности Qt сравнивать с чисто MS продуктом смешно хотя бы потому что первое — кроссплатформа, второе — нет.
Предлагаю на этом сойтись и все.
Зачтите мне слив пожалуйста.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>В общем вермена, когда надо было биться за каждый байт, давно прошли, B>>>но то, что твориться сейчас — это тоже ненормально. G>>А вас волнует цифирка в TaskManager или быстродействие? Обычно в компромисе время-память выбирают время.
B>Вообще-то именно быстродействие и волнует. B>Я вообщем как юзер на ситуацию смотрю. B>Цифиркb в TaskManager'е меня интерсуют только тогда, когда я пытаюсь понять, B>что мне лучше закрыть, чтобы можно было нормально работать.
У меня больше всех занимает браузер и студия, теперь их попеременно закрывать?
Вообще-то юзеры не ищут чего-бы закрыть.
B>Ну а как программист, я просто вижу, что если о ресурсах вообще не думать, B>и каждый будет так поступать, то в итоге юзеры тоже замечают, что 2 гига что-то маловато стало.
Лет 5 назад я мог себе позволить держать открытым браузер и делфи, если надо было открыть word, то приходилось что-нить закрывать. А антивирусник вообще предпочитал не ставить из-за тормозов.
Сейчас у меня на даже на ноуте дофига всего крутится.
Здравствуйте, 8bit, Вы писали:
8>Вообще странно что вы пытаетесь оспорить что приложение на управляемом языке требует больше памяти.
Это не так уж очевидно. Ведь когда выделяешь каким-нибудь malloc'ом, создаются служебные структуры менеджера памяти, они тоже свое место съедают. Если, допустим, у меня есть структура из 10 интов на 32-битной машине, и я создаю ее в куче, то в .net я потрачу кажися 12+10*4 байт, а в каком-нибудь окамле (язык со сборкой мусора) 4+10*4 байт. А сколько в случае С/С++?
"D. Mon" <58130@users.rsdn.ru> wrote in message news:3250668@news.rsdn.ru...
> Q>Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть > > А кто-нибудь может показать пример, где использование OpenGL/Direct3d ускорило какой-нибудь обычный гуевый контрол? Неужели рисование какого-нибудь radio button'a путем формирования серии треугольников и пересылки их видеокарте быстрее обычного растрового рисования? Контролы же обычно небольшие, чего там ускорять-то? И вообще, так ли часто отрисовка гуя занимает хоть сколь-нибудь заметное время на современных компах? Не припомню такого у обычных win32 приложений. В WinForms, помнится, были жалобы на медленный расчет layout'a, но его видеокарта быстрее не сделает..
Тормоза при прорисовке видно вполне отчетливо, если в виндах не установить драйвер видеокарты — поскольку самый обычный GDI уже лет 15 как аппаратно-ускоренный.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Qbit86, Вы писали:
Q>Ещё раз засчитан.
О, еще один, со сливами
Вы к чему свой пост с "матчастью" привели?
Как опровержение слов "что приложение на управляемом языке требует больше памяти."
Дык ваш пост скорее наоборот это подтверждает
А отквоченные слова из книжки Рихтера вообще бред.
Потому что в С/С++ я могу выделять и освобождать память так как мне захочется.
Здравствуйте, Denys V., Вы писали:
DV>И мне плиз засчитайте, ибо надоело уже.
Тебе пока рано засчитывать, ты ещё не перешёл на беспомощные фразы «лишь бы сказать». Но уже близко :)
DV>Уже и на пальцах объясняли и к RTFM аппелировали...
. Мне же на пальцах втирали про какие-то мифические .NET'овские 600 Мб супротив Сишных 60-ти — неубедительно и неправдоподобно.
DV>Предлагаю прекратить спор, ибо возможности Qt сравнивать с чисто MS продуктом смешно хотя бы потому что первое — кроссплатформа, второе — нет.
В том-то и дело, что начиналось всё с GUI-фреймворков, а потом зачем-то перешли на платформы разработки.
Здравствуйте, D. Mon, Вы писали:
Q>>Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть DM>А кто-нибудь может показать пример, где использование OpenGL/Direct3d ускорило какой-нибудь обычный гуевый контрол? Неужели рисование какого-нибудь radio button'a путем формирования серии треугольников и пересылки их видеокарте быстрее обычного растрового рисования? http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/
Здравствуйте, 8bit, Вы писали:
8>Дык ваш пост скорее наоборот это подтверждает :xz:
Простите меня, пожалуйста, у меня закрались сомнения в вашей вменяемости. Ещё раз простите.
8>Потому что в С/С++ я могу выделять и освобождать память так как мне захочется.
Ага. После того как затратите уйму времени на написание своего глючного аллокатора/менеджера памяти. Но в чуть менее чем всех проектах на Си/C++ этого не делают.
8>А отквоченные слова из книжки Рихтера вообще бред.
Рихтер — гуру не только .NET, но и платформы Windows, его книжка по WinAPI считается классикой. Он знает, о чём пишет. Не верите Рихтеру — спросим у Александреску:
По неизвестным мне причинам стандартный механизм распределения динамической памяти в языке C++ работает крайне медленно... Неэффективно работает с небольшими участками памяти... Стандартный распределитель управляет кучей, что часто вынуждает его занимать дополнительную память... Если возникает необходимость разместить в памяти объекты размером 8 байт, дополнительные затраты памяти составят от 50% до 400%. (Красная Книжка Александреску, глава 4)
Должен признаться, меня немного задело ваше необоснованное сомнение в компетентности gandjustas'а («Прочитайте про устройство GC. Или разработчики на .Net в такие подробности не лезут?», «Плохо вы его знаете, плохо»). Также не делают вам чести фразы типа «все-таки силверлайт убивает ваш мозг», «и все таки .Net убивает ваш мозг». Вынужден выразить вам свой дизреспект :(
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Сергей, Вы писали:
С>>Здравствуйте, gandjustas, Вы писали:
DV>>>>Возможно в далеком будущем (теоретически) — но не сейчас. G>>>Ну да, года через 2-3.
С>>Про .NET это говорят уже лет пять.
G>Что говорят?
"года через два-три".
Например:
1. Года через два-три большинство шароварных программ будет написано на дотнете.
2. Года через два-три JIT-компилятор будет оптимизировать лучше, чем оптимизируют современные С/C++ компиляторы.
3. Года через два-три на дотнете критические к производительности вещи можно будет писать на дотнете.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250615@news.rsdn.ru...
>> S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. >> Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше.
S>Да-да, даже наследования реализации нету — а кода меньше писать, ага.
Чего чего нету?
>> А .NET вам в случае ошибки четко покажет где она произошла, и выдаст адекватный stack trace. S>Адекватный стек трейс у меня на плюсах выдается уже лет десять.
И прям с именами функций? Даже при AV ?
>> Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти,
S>Не парится по поводу выделяемой памяти в моем случае возможно только при переходе на x64 — чего в силу некоторых особенностей лицензионной политики MS пока не случилось. Трех гигов в вин32 хватает с трудом.
Ну не знаю, всем приложениям хватает, почему вам не хватает?
>> динамически генерировать код и тому подобное. S>И часто вам приходится динамически генерировать код?
Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день.
>> Это позволяет использовать архитектурные приемы недоступные неуправляемым языкам. S>Какие конкретно архитектурные приемы?
IoC-контейнеры, метапрограммирование на атрибутах, AOP в рантайме, ORMы, кодогенерацию
>> В совокупности может огромный прирост производительности программиста дать. S>Или не дать
Обычно дает. Но можете думать по-другому.
>> Кстати, вы на .NET работали? S>Не особо много — не понравилось.
Ну если думаете что нет наследования реализации можно считать что не работали вообще.
>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее.
как раз равномерно все работает быстрее, из-за быстрого выделения памяти, а тех местах где надо много считать получается чуть медленее (даже не в 2 раза).
S>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо.
Это вы сами придумали?
Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов.
Но можно этих ошибок и не совершать.
Здравствуйте, Denys V., Вы писали:
DV>Предлагаю прекратить спор, ибо возможности Qt сравнивать с чисто MS продуктом смешно хотя бы потому что первое — кроссплатформа, второе — нет.
Первое работает только на десктопе, а второе и в вебе.
DV>Предлагаю на этом сойтись и все.
Ну как хотите.
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, gandjustas, Вы писали:
G>>Короче не пишите больше в этой теме, все равно ни одного здравого аргумента привести не можете.
8>
Здравствуйте, Сергей, Вы писали:
С>>>Про .NET это говорят уже лет пять.
G>>Что говорят?
С>"года через два-три".
С>Например: С>1. Года через два-три большинство шароварных программ будет написано на дотнете. С>2. Года через два-три JIT-компилятор будет оптимизировать лучше, чем оптимизируют современные С/C++ компиляторы. С>3. Года через два-три на дотнете критические к производительности вещи можно будет писать на дотнете.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Qbit86, Вы писали:
Q>>Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть
DM>А кто-нибудь может показать пример, где использование OpenGL/Direct3d ускорило какой-нибудь обычный гуевый контрол? [...]
Вот пример: здесь.
Правда, не совсем про "гуёвый контрол", там про SVG.
Здравствуйте, Qbit86, Вы писали:
8>>Дык ваш пост скорее наоборот это подтверждает Q>Простите меня, пожалуйста, у меня закрались сомнения в вашей вменяемости. Ещё раз простите.
Я на адептов ".Net" не обижаюсь .
Вы если не понимаете что сами написали, то какие ко мне притензии? Но я могу пояснить:
Вполне возможен случай, когда .NET-приложение будет требовать меньше памяти, чем Си-приложение, за счёт более плотной упаковки объектов.
Перевод: Иногда .Net приложение требует меньше памяти чем Cи-приложение. Но в целом это не так.
Вы поймите, какие-то особые возможные случаи никому не интересны.
В общем случае приложение на управляемом языке требует больше памяти.
И бОльшие требования к памяти вседа шли в жертву тому что бы разработчик перестал думать о ней.
БОльшие требования к памяти заложены в природе GC.
Здравствуйте, 8bit, Вы писали:
8>Вы поймите, какие-то особые возможные случаи никому не интересны. 8>В общем случае приложение на управляемом языке требует больше памяти. 8>И бОльшие требования к памяти вседа шли в жертву тому что бы разработчик перестал думать о ней. 8>БОльшие требования к памяти заложены в природе GC.
И какие-то подтверждения своим словам вы приводить будете?
Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.
Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.
Здравствуйте, gandjustas, Вы писали:
G>Вообще-то юзеры не ищут чего-бы закрыть.
А я кто, не юзер что ли?
Я тут бурчу именно как юзер.
А язык и платформа — это дело десятое.
Если о ресурсах при программировании не думать,
то юзерам обычно все равно, почему система тормозит.
Здравствуйте, gandjustas, Вы писали:
>>> S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. >>> Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше.
S>>Да-да, даже наследования реализации нету — а кода меньше писать, ага. G>Чего чего нету?
Множественного наследования реализации.
>>> А .NET вам в случае ошибки четко покажет где она произошла, и выдаст адекватный stack trace. S>>Адекватный стек трейс у меня на плюсах выдается уже лет десять. G>И прям с именами функций?
Имена функций извлекаются потом, из pdb. Клиенту мы pdb не поставляем. Есть конечно некоторая трудность с FPO и инлайнами, но тут уж приходится терпеть.
G>Даже при AV ?
Почему даже? Проблемы только при stack overflow — крэшдамп очень большой получается, может в почту не пролезть
>>> Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти,
S>>Не парится по поводу выделяемой памяти в моем случае возможно только при переходе на x64 — чего в силу некоторых особенностей лицензионной политики MS пока не случилось. Трех гигов в вин32 хватает с трудом. G>Ну не знаю, всем приложениям хватает, почему вам не хватает?
Так и нам хватает, для текущих задач, но не сказать чтобы с избытком. Юзеры по крайней мере хотели бы обрабатывать в сто раз большие данные — и желательно в сто раз быстрее
>>> динамически генерировать код и тому подобное. S>>И часто вам приходится динамически генерировать код? G>Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день.
В смысле, Emit раз в месяц? Жостко
>>> Это позволяет использовать архитектурные приемы недоступные неуправляемым языкам. S>>Какие конкретно архитектурные приемы? G>IoC-контейнеры,
Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам?
G>метапрограммирование на атрибутах, AOP в рантайме, ORMы, кодогенерацию
Атрибутов в плюсах действительно не хватает, хотя и без них метапрограммирование вполне на высоте. Ну то есть я могу без всяких атрибутов оформить например
список членов класса, над которыми требуется выполнять какую-то операцию или там проверить, что какой-то класс унаследован от другого. Чего на практике пока оказывалась
достаточно — хотя делается это, к сожалению, через зад.
АОП — ну тоже компилтаймового пока хватало, и, видимо, и дальше хватать будет.
ORM — да, это не область C++. Ну и к счастью совсем не из моей области.
Кодогенерация на лету у нас в программе когда-то была, на ассемблере
Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое.
>>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >>> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. G>как раз равномерно все работает быстрее, из-за быстрого выделения памяти, а тех местах где надо много считать получается чуть медленее (даже не в 2 раза).
У наших конкурентов есть очень похожий на наш (вернее, мы на них) продукт, написан на джаве. Работает раза в три медленнее и жрет в два раза больше памяти.
Так что не надо мне рассказывать сказки.
S>>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо. G>Это вы сами придумали? G>Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов. G>Но можно этих ошибок и не совершать.
Да да да. Но на управляемых языках совершать эти ошибки проще.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Сергей, Вы писали:
С>>Здравствуйте, gandjustas, Вы писали:
G>>>Ссылки?
С>>Ну вот примерно такое: С>>
то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется
Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го".
С>>
Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.
, 2003 г. G>А вы сравните рынки C++ и C# за 2003 год и сейчаq. Почти правда.
Ну, у меня рынкомера нет, чтобы сравнивать. А вот про популярность языков программирования можно посмотреть здесь.
Там, кстати, есть сравнение с 2004-го года с 2008-м. Как был С++ популярнее, чем C#, так и остался.
С>>
Ведь через пару-тройку лет (а точнее в 2006 когда выйдет Longhorn) Win32 не станет.
Здравствуйте, gandjustas, Вы писали:
G>И что, не развернулась?
Да как бы, почему-то, я не знаю почему, нет. Я сам с 2001-го года, как только увидел спецификацию C#, питаю большие надежды на .Net. Но Microsoft пока лишь доказывает, что она Microsoft.
С одной стороны, забавно наблюдать, как восемь лет назад C++серы усмехались, мол «вот майкрософт сделала неудачную попытку клонировать яву, через полгода умрет». Да впрочем, и до сих пор такие одаренные попадаются
С другой стороны, .Net даже близко не подошел к тому, чтобы стать платформой нового времени. Что я пока вижу, это как M$ включает в самый первый же гайд по WPF раздел "Optimizing WPF Application Performance", в котором говорится, что делать, если ваше приложение работает медленно или жрет слишком много. Интересно, не так ли?
Максимум, что сумел .Net — занял ниши, в которых C++ был плох. Рано еще говорить «будем писать на C#/WPF вместо C++/Qt, ибо разницы нет». Ибо разница есть. И я не предвижу ничего со стороны MS, чтобы эту разницу устранить.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Сергей, Вы писали:
С>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Ссылки?
С>>>Ну вот примерно такое: С>>>
то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется
, 2002 г. G>>И что, не развернулась?
С>Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го".
Ну так технология развивается. "через пару лет будет ого-го" каждый раз говорят о разных вещах.
С>>>
Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.
, 2003 г. G>>А вы сравните рынки C++ и C# за 2003 год и сейчаq. Почти правда.
С>Ну, у меня рынкомера нет, чтобы сравнивать. А вот про популярность языков программирования можно посмотреть здесь.
Этот индекс ужасен. Вы зайдите и посмотрите его определение.
Лучше смотрите в объявлениях о работе чем компании щанимаются.
С>>>
Ведь через пару-тройку лет (а точнее в 2006 когда выйдет Longhorn) Win32 не станет.
, 2003 г. G>>Этот оратор не учел что MS сохраняет обратную совместимость.
С>Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно.
Вы считаете что любую бредятину, которую пишут на форуме пожно приводить в подтверждение своих слов?
Правда состоит в том, что лучшей альтернативы С++ в ближайшее время не предвидится. C++ будет жить ещё очень долго. C++ будет жить до тех пор, пока на платформах будут поддерживаться компиляторы этого языка. А Microsoft далеко не единственный производитель компиляторов. Например, Intel традиционно выпускает два компилятора — C++ и Фортран.
С++ это СВОБОДА. Программиста С++ не сажают в "тюрьму" какого-то одного фрэймворка или одной операционной системы. С++ программисту невозможно что-то навязать снаружи, потому что это универсальный язык, который позволяет полностью абстрагироваться от конкретной реализации. Более того, невероятная гибкость позволяет повторно использовать один и тот же код в разных независимых проектах на разных операционных системах (а некоторое время спустя написанные раньше библиотеки могут снова пригодиться — ведь ничего не пропадает, всё сохраняется!), и это позволяет существенно экономить время. По простоте изучения C++ почти такой же как Java или С#. Кроме этого, С++ применим для любой ниши.
C++ это кость в горле Microsoft.
Программист, который пишет на C++ полностью неуправляем с точки зрения монополии. Такой программист может делать всё что захочет. У него есть все степени свободы. Он вещь сама в себе. Он может спокойно перейти на Линукс, на Макинтош, на FreeBSD/Unix/Solaris или ... на любую новую операционную систему, к примеру от Google. Да... Язык С++ это тот самый кошмарный сон Майкрософта, от которого монополия уже который год пытается незаметно избавиться с помощью агрессивной рекламы .NET технологий и последующей "привязкой" разработчиков к C#.
С коммерческой точки зрения язык С++ — это реальная угроза для монополии. Особенно в условиях чрезвычайно острой конкуренции со свободными юниксами, и тем более сейчас, с выходом бесплатного Qt.
Задача монополиста — жестко посадить девелопера "на иглу". Поэтому политика свелась даже к тому, чтобы в бесплатную версию VS.NET Express не включать традиционные средства разработки приложений на C++ для Windows — MFC.
Зато маркетинговый пиар С# и VB.NET продолжается полным ходом. Здесь всё понятно. В Microsoft выбрали традиционный подход для оболванивания разработчиков, и пока он работает. Но только есть одна проблема — кризис доверия. Люди не могут простить то, что произошло с VB Classic, Win32 API, COM+. Я когда-то тоже писал на VB6, внимательно изучал COM технологии. Но потом случилось то, что всех лояльных программистов неожиданно "кинули" — сказали что языку VB6 пришёл конец. Писали даже петицию, с просьбой включить VB Classic в состав новой студии — не помогло. Многие расценили этот шаг от Microsoft как издевательство. Программисты с девяностых годов учили Visual Basic около 15 лет, потратили кучу времени на изучение особенностей, а потом их просто ставят перед фактом — что весь ваш труд можете выбросить, или попробовать всё переписать. Почему? Потому что кому-то в Microsoft так захотелось.
Так вот, вместо выбора очередного маразма под называнием VB.NET, я полностью перешёл на надёжный C++. Кстати, знаю и про то, что новоиспечённые сторонники C# часто тоже переходят на C++ и говорят об удобстве проектирования ПО с помощью кроссплатформенных обёрток и библиотек таких как Qt, о долговечности, проверенной надежности языка C++. В конечном итоге они приходят к выводу, что важнее больше думать, вместо того чтобы громко кричать.
Хотя вас никто не заставляет использовать С++ и быть свободными. Пожалуйста, пользуйтесь очередными "технологиями" от Microsoft. А я, например, очень уважаю свой труд, и поэтому не могу позволить чтобы работоспособность моего кода зависела от очередного выпендрёжа или замены очередного фреймворка Microsoft на что-нибудь ещё, более "модное". Я просто хочу чтобы мои наработки можно было использовать и через 5 лет, и через 10 лет. А гадать в какой следующий дурдом побежит команда Билли мне не интересно.
В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
>>>> S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. >>>> Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше.
S>>>Да-да, даже наследования реализации нету — а кода меньше писать, ага. G>>Чего чего нету?
S>Множественного наследования реализации.
А вы его используете? Тогда вам в форум по философии, там быстро все объяснят.
>>>> Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти,
S>>>Не парится по поводу выделяемой памяти в моем случае возможно только при переходе на x64 — чего в силу некоторых особенностей лицензионной политики MS пока не случилось. Трех гигов в вин32 хватает с трудом. G>>Ну не знаю, всем приложениям хватает, почему вам не хватает?
S>Так и нам хватает, для текущих задач, но не сказать чтобы с избытком. Юзеры по крайней мере хотели бы обрабатывать в сто раз большие данные — и желательно в сто раз быстрее
Пусть платят в 100*100, те в 10000 раз больше и все им будет
А чем вы таким занимаетесь?
При ОЧЕНЬ больших объемах уже проблемы не перформанса на одной машине возникают.
>>>> динамически генерировать код и тому подобное. S>>>И часто вам приходится динамически генерировать код? G>>Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день.
S>В смысле, Emit раз в месяц? Жостко
Да ниче страшного нет. В основном простые функции эмитятся, чтобы рефлекшеном не пользоваться.
>>>> Это позволяет использовать архитектурные приемы недоступные неуправляемым языкам. S>>>Какие конкретно архитектурные приемы? G>>IoC-контейнеры,
S>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам?
Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов.
S>Кодогенерация на лету у нас в программе когда-то была, на ассемблере
.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится.
S>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое.
Метапрограммирование должно быть везде.
>>>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >>>> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>>>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. G>>как раз равномерно все работает быстрее, из-за быстрого выделения памяти, а тех местах где надо много считать получается чуть медленее (даже не в 2 раза).
S>У наших конкурентов есть очень похожий на наш (вернее, мы на них) продукт, написан на джаве. Работает раза в три медленнее и жрет в два раза больше памяти. S>Так что не надо мне рассказывать сказки.
Это ж джава. Она и скоростью никогда не отличалась. да еще и непонятно какой уровень разработчиков.
S>>>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо. G>>Это вы сами придумали? G>>Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов. G>>Но можно этих ошибок и не совершать.
S>Да да да. Но на управляемых языках совершать эти ошибки проще.
Ошибки совершаются одинаково независимо от языка. Только в управляемых потенциальных ошибок меньше.
На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код.
, 2003 г.
A>Правда состоит в том, что лучшей альтернативы С++ в ближайшее время не предвидится. C++ будет жить ещё очень долго. C++ будет жить до тех пор, пока на платформах будут поддерживаться компиляторы этого языка. А Microsoft далеко не единственный производитель компиляторов. Например, Intel традиционно выпускает два компилятора — C++ и Фортран.
A>С++ это СВОБОДА. Программиста С++ не сажают в "тюрьму" какого-то одного фрэймворка или одной операционной системы. С++ программисту невозможно что-то навязать снаружи, потому что это универсальный язык, который позволяет полностью абстрагироваться от конкретной реализации. Более того, невероятная гибкость позволяет повторно использовать один и тот же код в разных независимых проектах на разных операционных системах (а некоторое время спустя написанные раньше библиотеки могут снова пригодиться — ведь ничего не пропадает, всё сохраняется!), и это позволяет существенно экономить время. По простоте изучения C++ почти такой же как Java или С#. Кроме этого, С++ применим для любой ниши.
A>C++ это кость в горле Microsoft.
A>Программист, который пишет на C++ полностью неуправляем с точки зрения монополии. Такой программист может делать всё что захочет. У него есть все степени свободы. Он вещь сама в себе. Он может спокойно перейти на Линукс, на Макинтош, на FreeBSD/Unix/Solaris или ... на любую новую операционную систему, к примеру от Google. Да... Язык С++ это тот самый кошмарный сон Майкрософта, от которого монополия уже который год пытается незаметно избавиться с помощью агрессивной рекламы .NET технологий и последующей "привязкой" разработчиков к C#.
A>С коммерческой точки зрения язык С++ — это реальная угроза для монополии. Особенно в условиях чрезвычайно острой конкуренции со свободными юниксами, и тем более сейчас, с выходом бесплатного Qt.
A>Задача монополиста — жестко посадить девелопера "на иглу". Поэтому политика свелась даже к тому, чтобы в бесплатную версию VS.NET Express не включать традиционные средства разработки приложений на C++ для Windows — MFC.
A>Зато маркетинговый пиар С# и VB.NET продолжается полным ходом. Здесь всё понятно. В Microsoft выбрали традиционный подход для оболванивания разработчиков, и пока он работает. Но только есть одна проблема — кризис доверия. Люди не могут простить то, что произошло с VB Classic, Win32 API, COM+. Я когда-то тоже писал на VB6, внимательно изучал COM технологии. Но потом случилось то, что всех лояльных программистов неожиданно "кинули" — сказали что языку VB6 пришёл конец. Писали даже петицию, с просьбой включить VB Classic в состав новой студии — не помогло. Многие расценили этот шаг от Microsoft как издевательство. Программисты с девяностых годов учили Visual Basic около 15 лет, потратили кучу времени на изучение особенностей, а потом их просто ставят перед фактом — что весь ваш труд можете выбросить, или попробовать всё переписать. Почему? Потому что кому-то в Microsoft так захотелось.
A>Так вот, вместо выбора очередного маразма под называнием VB.NET, я полностью перешёл на надёжный C++. Кстати, знаю и про то, что новоиспечённые сторонники C# часто тоже переходят на C++ и говорят об удобстве проектирования ПО с помощью кроссплатформенных обёрток и библиотек таких как Qt, о долговечности, проверенной надежности языка C++. В конечном итоге они приходят к выводу, что важнее больше думать, вместо того чтобы громко кричать.
A>Хотя вас никто не заставляет использовать С++ и быть свободными. Пожалуйста, пользуйтесь очередными "технологиями" от Microsoft. А я, например, очень уважаю свой труд, и поэтому не могу позволить чтобы работоспособность моего кода зависела от очередного выпендрёжа или замены очередного фреймворка Microsoft на что-нибудь ещё, более "модное". Я просто хочу чтобы мои наработки можно было использовать и через 5 лет, и через 10 лет. А гадать в какой следующий дурдом побежит команда Билли мне не интересно.
A>В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим.
В статьи!!!
В "Философия программирования" однозначно!
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
A>>В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим. DV>В статьи!!! DV>В "Философия программирования" однозначно!
Будем честными. Сразу уж в КСВ.
, 2003 г.
A>Правда состоит в том, что лучшей альтернативы С++ в ближайшее время не предвидится. C++ будет жить ещё очень долго. C++ будет жить до тех пор, пока на платформах будут поддерживаться компиляторы этого языка. А Microsoft далеко не единственный производитель компиляторов. Например, Intel традиционно выпускает два компилятора — C++ и Фортран.
Налачие кучи компиляторов фортрана в его время не спасло от устаревания, также история с коболом, несмотря на то что на коболе и по сей день написано больше всего строк кода. C++ тоже устарел. Процесс его вытеснения идет.
A>С++ это СВОБОДА. Программиста С++ не сажают в "тюрьму" какого-то одного фрэймворка или одной операционной системы. С++ программисту невозможно что-то навязать снаружи, потому что это универсальный язык, который позволяет полностью абстрагироваться от конкретной реализации. Более того, невероятная гибкость позволяет повторно использовать один и тот же код в разных независимых проектах на разных операционных системах (а некоторое время спустя написанные раньше библиотеки могут снова пригодиться — ведь ничего не пропадает, всё сохраняется!), и это позволяет существенно экономить время. По простоте изучения C++ почти такой же как Java или С#.
Невернятная гибкость C# позволяет запускать один и тотже код (в бинарном виде) на Windows, Linux, MacOS (iPhone в том числе), WindowsMobile. Иходники также могут быть скомилированы для запуска в браузере (Silverlight), также по C# можно создать JS код (Script#) или SQL запрос (Linq2SQL, EF).
Так что речь о "тюрьмах" и повторном использовании — мимо кассы.
По простоте изучения C++ гораздо сложнее Java и C#. А обилие способов "выстрелить себе в ногу" на C++ требует большой строгости при разработке (почитайте coding styles гугла).
A>Кроме этого, С++ применим для любой ниши.
Ага, особенно для веб-разработки. Да и в enterprise он не сильно прижился.
A>C++ это кость в горле Microsoft.
Счего бы?
A>Программист, который пишет на C++ полностью неуправляем с точки зрения монополии. Такой программист может делать всё что захочет. У него есть все степени свободы. Он вещь сама в себе. Он может спокойно перейти на Линукс, на Макинтош, на FreeBSD/Unix/Solaris или ... на любую новую операционную систему, к примеру от Google. Да... Язык С++ это тот самый кошмарный сон Майкрософта, от которого монополия уже который год пытается незаметно избавиться с помощью агрессивной рекламы .NET технологий и последующей "привязкой" разработчиков к C#.
C C# тоже самое. С помощью Mono можно разрабатывать на любой ОС.
A>С коммерческой точки зрения язык С++ — это реальная угроза для монополии. Особенно в условиях чрезвычайно острой конкуренции со свободными юниксами, и тем более сейчас, с выходом бесплатного Qt.
Прямо вендекапец какой-то.
A>Задача монополиста — жестко посадить девелопера "на иглу". Поэтому политика свелась даже к тому, чтобы в бесплатную версию VS.NET Express не включать традиционные средства разработки приложений на C++ для Windows — MFC.
Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего. Будь MS действительно такой плохой компанией вообще бы отказались от поддержки C++ библиотек года 3 назад.
A>Зато маркетинговый пиар С# и VB.NET продолжается полным ходом. Здесь всё понятно. В Microsoft выбрали традиционный подход для оболванивания разработчиков, и пока он работает. Но только есть одна проблема — кризис доверия. Люди не могут простить то, что произошло с VB Classic, Win32 API, COM+.
И что с ними произошло? Правильный ответ — ничего. Просто эти технологии достигли предела развития. А MS чтобы держаться на плаву надо придумывать что-то новое.
A>Я когда-то тоже писал на VB6, внимательно изучал COM технологии. Но потом случилось то, что всех лояльных программистов неожиданно "кинули" — сказали что языку VB6 пришёл конец. Писали даже петицию, с просьбой включить VB Classic в состав новой студии — не помогло. Многие расценили этот шаг от Microsoft как издевательство. Программисты с девяностых годов учили Visual Basic около 15 лет, потратили кучу времени на изучение особенностей, а потом их просто ставят перед фактом — что весь ваш труд можете выбросить, или попробовать всё переписать. Почему? Потому что кому-то в Microsoft так захотелось.
И большенство из тех, кто писал на VB пересели на VB.NET. Недовольных я что-то не видел.
Вообще любые перемены вызывают такие кризисы, но если предлагается достойная замена, то кризис быстро проходит.
.NET более чем достойная замена.
A>Так вот, вместо выбора очередного маразма под называнием VB.NET, я полностью перешёл на надёжный C++.
А что же сразу не стали на C++ кодить? Ждали пока MS вас кинет? VB и был-то не самым лучшим языком, больше для скриптинга подходил.
A>Кстати, знаю и про то, что новоиспечённые сторонники C# часто тоже переходят на C++ и говорят об удобстве проектирования ПО с помощью кроссплатформенных обёрток и библиотек таких как Qt, о долговечности, проверенной надежности языка C++. В конечном итоге они приходят к выводу, что важнее больше думать, вместо того чтобы громко кричать.
"Часто" — это очень громко сказано. Из порядка сотни программистов на .NET я знаю только одного, который на C++ перешел. В основном наоборот.
A>Хотя вас никто не заставляет использовать С++ и быть свободными. Пожалуйста, пользуйтесь очередными "технологиями" от Microsoft. А я, например, очень уважаю свой труд, и поэтому не могу позволить чтобы работоспособность моего кода зависела от очередного выпендрёжа или замены очередного фреймворка Microsoft на что-нибудь ещё, более "модное". Я просто хочу чтобы мои наработки можно было использовать и через 5 лет, и через 10 лет. А гадать в какой следующий дурдом побежит команда Билли мне не интересно.
Никто вам не мешает знать несколько языков и технологий. Новые технологии не появляются неожижанно, у вас всегда будет время изучить новое, прежде чем оно пойдет в массы.
A>В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим.
Аминь
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, gandjustas, Вы писали:
G>>И что, не развернулась?
Кё>Да как бы, почему-то, я не знаю почему, нет. Я сам с 2001-го года, как только увидел спецификацию C#, питаю большие надежды на .Net. Но Microsoft пока лишь доказывает, что она Microsoft.
Кё>С одной стороны, забавно наблюдать, как восемь лет назад C++серы усмехались, мол «вот майкрософт сделала неудачную попытку клонировать яву, через полгода умрет». Да впрочем, и до сих пор такие одаренные попадаются
В 2001 я тоже так усмехался.
Кё>С другой стороны, .Net даже близко не подошел к тому, чтобы стать платформой нового времени. Что я пока вижу, это как M$ включает в самый первый же гайд по WPF раздел "Optimizing WPF Application Performance", в котором говорится, что делать, если ваше приложение работает медленно или жрет слишком много. Интересно, не так ли?
А что такого удивительного. Напишите графический движок, которым будут тысячи людей пользоваться и заставьте его всегда работать быстро и экономично.
Кё>Максимум, что сумел .Net — занял ниши, в которых C++ был плох. Рано еще говорить «будем писать на C#/WPF вместо C++/Qt, ибо разницы нет». Ибо разница есть. И я не предвижу ничего со стороны MS, чтобы эту разницу устранить.
И в чем разница?
Почему-то на этот вопрос ответ находится только "кроссплатформенность", но а)кроссплатформенность гуя не означает кроссплатформенность всего приложения, б)при 90% виндовсов на персональных компьютерах эта кросплатформенность не сильно нужна, в)с появлением Mono 2.0 на .NET также можно писать кроссплатформенный код.
Здравствуйте, gandjustas, Вы писали:
S>>Множественного наследования реализации. G>А вы его используете? Тогда вам в форум по философии, там быстро все объяснят.
Разумеется, используем — невиртуальное. Что на эту тему думают философы, меня абсолютно не волнует.
S>>Так и нам хватает, для текущих задач, но не сказать чтобы с избытком. Юзеры по крайней мере хотели бы обрабатывать в сто раз большие данные — и желательно в сто раз быстрее G>Пусть платят в 100*100, те в 10000 раз больше и все им будет
Они не хотят платить больше, смысл в использовании софта пропадет. Но их деньги нам все равно нужны.
G>А чем вы таким занимаетесь? G>При ОЧЕНЬ больших объемах уже проблемы не перформанса на одной машине возникают.
Data Mining/Text Mining. Не на одной машине — это кстати гораздо сложнее, чем на одной на плюсах. И куда дороже.
>>>>> динамически генерировать код и тому подобное. S>>>>И часто вам приходится динамически генерировать код? G>>>Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день.
S>>В смысле, Emit раз в месяц? Жостко G>Да ниче страшного нет. В основном простые функции эмитятся, чтобы рефлекшеном не пользоваться.
Это видимо из-за отсутствия более правильных средств
S>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? G>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов.
Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение.
S>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере G>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится.
Да в общем то и не надо
S>>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое. G>Метапрограммирование должно быть везде.
В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
>>>>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >>>>> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>>>>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. G>>>как раз равномерно все работает быстрее, из-за быстрого выделения памяти, а тех местах где надо много считать получается чуть медленее (даже не в 2 раза).
S>>У наших конкурентов есть очень похожий на наш (вернее, мы на них) продукт, написан на джаве. Работает раза в три медленнее и жрет в два раза больше памяти. S>>Так что не надо мне рассказывать сказки. G>Это ж джава. Она и скоростью никогда не отличалась.
На дотнете такое писать пока желающих не нашлось. Напишут — сравним.
G>да еще и непонятно какой уровень разработчиков.
Типа лидер рынка.
S>>>>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо. G>>>Это вы сами придумали? G>>>Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов. G>>>Но можно этих ошибок и не совершать.
S>>Да да да. Но на управляемых языках совершать эти ошибки проще. G>Ошибки совершаются одинаково независимо от языка. Только в управляемых потенциальных ошибок меньше.
Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. А ошибки в логике что там что сям действительно одинаково легко навесить. В голом С кстати ошибки с производительность еще труднее делать, но там и код писать сильно труднее
G>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код.
Хочешь еще про необходимость профотбора пофлеймить что ли?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Множественного наследования реализации. G>>А вы его используете? Тогда вам в форум по философии, там быстро все объяснят. S>Разумеется, используем — невиртуальное. Что на эту тему думают философы, меня абсолютно не волнует.
>>>>>> динамически генерировать код и тому подобное. S>>>>>И часто вам приходится динамически генерировать код? G>>>>Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день. S>>>В смысле, Emit раз в месяц? Жостко G>>Да ниче страшного нет. В основном простые функции эмитятся, чтобы рефлекшеном не пользоваться. S>Это видимо из-за отсутствия более правильных средств
Ну да. Отсутствие "compiler as service" иногда напрягает. Но вроде как с DLR в .NET 4 станет чуть легче жить.
S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение.
Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму.
S>>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере G>>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится. S>Да в общем то и не надо
Вам может и не надо, а возможность очень хорошая.
S>>>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое. G>>Метапрограммирование должно быть везде. S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
G>>да еще и непонятно какой уровень разработчиков. S>Типа лидер рынка.
Ну это ни о чем не говорит. Я работал к компании — лидере своего рынка, но код там воистину ужасен.
S>>>>>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо. G>>>>Это вы сами придумали? G>>>>Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов. G>>>>Но можно этих ошибок и не совершать.
S>>>Да да да. Но на управляемых языках совершать эти ошибки проще. G>>Ошибки совершаются одинаково независимо от языка. Только в управляемых потенциальных ошибок меньше.
S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее.
И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна.
G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. S>Хочешь еще про необходимость профотбора пофлеймить что ли?
Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251166@news.rsdn.ru...
> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? > G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. > S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. > Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму.
Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую
> S>>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере > G>>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится. > S>Да в общем то и не надо > Вам может и не надо, а возможность очень хорошая.
Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off.
> S>>>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое. > G>>Метапрограммирование должно быть везде. > S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. > Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
Ну я только рад за разработчиков FPGA, только мне-то что с того?
> G>>да еще и непонятно какой уровень разработчиков. > S>Типа лидер рынка. > Ну это ни о чем не говорит. Я работал к компании — лидере своего рынка, но код там воистину ужасен.
У меня нет оснований полагать, что мы напишем лучше. А на плюсах — написали.
> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. > И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна.
Сложнее — потому что слой "шоколада" толще.
> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. > S>Хочешь еще про необходимость профотбора пофлеймить что ли? > Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании.
Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании Совсем уж бред то не пиши, ладно?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании.
S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании Совсем уж бред то не пиши, ладно?
Ну разве не видно, что у человека C# повинен во всех радостях жизни. Завтра окажется, что мы тоже должны читать мантры, и какого мы неблагодарные этого не понимаем то? Счастье то вот оно.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, gandjustas, Вы писали:
С>>Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го". G>Ну так технология развивается. "через пару лет будет ого-го" каждый раз говорят о разных вещах.
Каждый раз говорят о том, что C/C++ вот-вот станет никому не нужен, и C# будет годен для всего.
G>Этот индекс ужасен. Вы зайдите и посмотрите его определение. G>Лучше смотрите в объявлениях о работе чем компании щанимаются.[...]
А по-моему — прекрасный индекс.
Не нравится этот — найдите другой индекс, посмотрим и на него. Я ещё один нашёл.
По поводу, чем компании занимаются — вот с job.ru, Москва, первая страница выдачи. Мной убраны вакансии администраторов и всяких "менеджеров по ведению бизнеса".
Программист 1С: УПП 8.0
Программист 1С
Консультант по программе Парус
Консультант SAP
Программист Visual C++
Ведущий программист С++
Разработчик С++
Программист С++
Aрхитектор С++
Старший разработчик Java
Java программист
Старший разработчик С++/3D
Разработчик драйверов
Консультант SAP HR
Программист С#
Разработчик C#
Разработчик J 2EE
Разработчик .NET
Разработчик SAP Netweaver
Программист С++
С>>Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно. G>Вы считаете что любую бредятину, которую пишут на форуме пожно приводить в подтверждение своих слов?
Мои слова подтверждает не смысл этого сообщения (который, совершенно согласен, по сути бредовое), а наличие такого сообщения.
A>Первый раз — когда финн Линус Торвальдс осмелился написать бесплатную и открытую операционную систему, выйти против монстроидально устрашающего конкурента...
Дабы подлить огня в затухающее пламя .
Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса.
Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
Здравствуйте, gandjustas, Вы писали:
G>Налачие кучи компиляторов фортрана в его время не спасло от устаревания.
Фортран занимает лидирующее положение среди языков программирования, ориентированных на решение научно-технических задач, требующих большого объема вычислений. Особенно актуальным является применение Фортрана при решении крупномасштабных вычислительных задач с использованием современных параллельных вычислительных систем. Решение таких задач требуется в различных сферах фундаментальных научных исследований. Одно из преимуществ современного Фортрана — большое количество написанных на нём программ и библиотек подпрограмм. Среди учёных, например, ходит такая присказка, что любая математическая задача уже имеет решение на Фортране, и, действительно, можно найти среди тысяч фортрановских пакетов и пакет для перемножения матриц, и пакет для решения сложных интегральных уравнений и многие, многие другие. Ряд таких пакетов создавались на протяжении десятилетий и популярны в научной среде по сей день. Большинство таких библиотек является фактически достоянием человечества: они доступны в исходных кодах, хорошо документированы, отлажены и весьма эффективны. Поэтому изменять, а тем более переписывать их на других языках программирования накладно, несмотря на то, что регулярно производятся попытки автоматического конвертирования FORTRAN-кода на языки C/C++. Самый новый стандарт этого языка — Fortran 2008.
G>C++ тоже устарел. Процесс его вытеснения идет.
Чем? Шарпом и джавой? Так ведь это тюремные языки привязанные к своим фреймворкам и капризам корпораций.
G>С помощью Mono можно разрабатывать на любой ОС.
Mono — это провокация, очередная попытка освобождения программистов от тюрьмы майкрософта (Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#.) Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono. Но так или иначе, Mono закономерно приспосабливается под требования очередных реализаций дот-нет-фреймворков. И здесь очевидная цель — не создание альтернативной платформы для разработчиков C#, а простое освобождение людей от Windows-зависимости, путём копирования под юниксы. Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете:
G>А MS чтобы держаться на плаву надо придумывать что-то новое.
Тратить драгоценное время на изучение очередных одноразовых "технологий" Microsoft, только чтобы удержать эту корпорацию на плаву — не интересно.
A>>Кроме этого, С++ применим для любой ниши. G>Ага, особенно для веб-разработки.
Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов. И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++.
Есть даже такой веб сервер — лайти (lighttpd с нативной поддержкой FastCGI), который кстати довольно успешно используется на Youtube именно для этих целей.
G>Да и в enterprise он не сильно прижился.
Enterprise очень сильно зависит от психологического воздействия пиара, маркетинга, давления корпораций. Там сложная политика больших денег, а не технологий.
G>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего.
Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков.
G>Будь MS действительно такой плохой компанией вообще бы отказались от поддержки C++ библиотек года 3 назад.
Они прекрасно понимают что явным образом такой шаг будет сделать очень сложно. И пока даже сами пишут Windows на C/C++.
G>А что же сразу не стали на C++ кодить? Ждали пока MS вас кинет? VB и был-то не самым лучшим языком, больше для скриптинга подходил.
Я могу вам сейчас задать точно такой же вопрос: А чего вы на C# кодите? Ждёте пока MS вас кинет?
С# по скорости выполнения, пока тоже больше для скриптинга подходит.
G>Никто вам не мешает знать несколько языков и технологий. Новые технологии не появляются неожижанно, у вас всегда будет время изучить новое, прежде чем оно пойдет в массы.
Ещё раз повторю. Терять время на изучение новых одноразовых "технологий", только чтобы удержать Microsoft на плаву — не интересно.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251166@news.rsdn.ru...
>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму.
S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую
всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC.
>> S>>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере >> G>>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится. >> S>Да в общем то и не надо >> Вам может и не надо, а возможность очень хорошая.
S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off.
Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти.
>> G>>Метапрограммирование должно быть везде. >> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. S>Ну я только рад за разработчиков FPGA, только мне-то что с того?
С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. S>Сложнее — потому что слой "шоколада" толще.
Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много.
>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании. S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании Особенно шаблоны и кастомные алокаторы
S>Совсем уж бред то не пиши, ладно?
Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код.
Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
С>>>Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го". G>>Ну так технология развивается. "через пару лет будет ого-го" каждый раз говорят о разных вещах.
С>Каждый раз говорят о том, что C/C++ вот-вот станет никому не нужен, и C# будет годен для всего.
Дык .NET с каждым мажорным апдейтом начинает покрывать все большие области. C\C++ никогда не станет совсем не нужным, но его доля на рынке постоянно уменьшается.
Или вы думаете что в один приекрасный день все бросят писат на C++ и разом перейдут на шарп?
G>>Этот индекс ужасен. Вы зайдите и посмотрите его определение. G>>Лучше смотрите в объявлениях о работе чем компании щанимаются.[...]
С>А по-моему — прекрасный индекс. С>Не нравится этот — найдите другой индекс, посмотрим и на него. Я ещё один нашёл.
Мда..
С>По поводу, чем компании занимаются — вот с job.ru, Москва, первая страница выдачи. Мной убраны вакансии администраторов и всяких "менеджеров по ведению бизнеса".
не сами вакансии интересуют, а количество различных конмпаний, работающих на C#. Косвенно этот праметр оценть можно по вакансиям.
С>>>Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно. G>>Вы считаете что любую бредятину, которую пишут на форуме пожно приводить в подтверждение своих слов?
С>Мои слова подтверждает не смысл этого сообщения (который, совершенно согласен, по сути бредовое), а наличие такого сообщения.
Ну на просторах интернета можно много чего найти. На этом форуме можно найти сотни цитат про то что .NET загнется.
Здравствуйте, Germes, Вы писали:
G>Дабы подлить огня в затухающее пламя . G>Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса. G>Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
наверное потому что в аутсорсе намного больше Java и .NET чем C++
Аутсорс первым пострадал от кризиса.
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>C++ тоже устарел. Процесс его вытеснения идет. A>Чем? Шарпом и джавой? Так ведь это тюремные языки привязанные к своим фреймворкам и капризам корпораций.
А вы на ГОЛОМ С++ пишете?
G>>С помощью Mono можно разрабатывать на любой ОС.
A>Mono — это провокация, очередная попытка освобождения программистов от тюрьмы майкрософта (Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#.)
Источник откровения?
Наверное они такие заклятые враги, что даже пригласили выедущего разработчика Mono на PDC в качестве докладчика.
A>Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono.
С# стандартизован ECMA и никому не пренадлежит. Также ECMA стандартизировала спецификацию CLR.
Так что ваши слова — откровенный бред.
A>Но так или иначе, Mono закономерно приспосабливается под требования очередных реализаций дот-нет-фреймворков.
Mono во второй версии имеет некоторые фичи, которые даже в .NET 4 недоступны будут.
A>И здесь очевидная цель — не создание альтернативной платформы для разработчиков C#, а простое освобождение людей от Windows-зависимости, путём копирования под юниксы. Вы бы вопрос изучили перед тем как такое писать.
A>Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете: G>>А MS чтобы держаться на плаву надо придумывать что-то новое.
Выход любого нового продукта анонсируют за год-два. Причем вместе с тупой рекламой предоставляют возможности будущим пиользователям бесплатно пользоваться продуктом во время тестирования?
Так где непредсказуемость и кидалово?
A>Тратить драгоценное время на изучение очередных одноразовых "технологий" Microsoft, только чтобы удержать эту корпорацию на плаву — не интересно.
Ну .NET не одноразовая технология. Скоро 10 лет ей стукнет и пока никто не собирается её выбрасывать.
Те кто с свое время перешаело на VB.NET не прогадали.
A>>>Кроме этого, С++ применим для любой ниши. G>>Ага, особенно для веб-разработки.
A>Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов.
И потратить миллиарды на стоимости разработки
A>И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++.
Это в теории, а примеры "ультрабыстрых веб сервисов" есть?
A>Есть даже такой веб сервер — лайти (lighttpd с нативной поддержкой FastCGI), который кстати довольно успешно используется на Youtube именно для этих целей. Только Youtube на питоне написан.
А lighttpd нужен для максимально быстрой отдачи контента.
G>>Да и в enterprise он не сильно прижился. A>Enterprise очень сильно зависит от психологического воздействия пиара, маркетинга, давления корпораций. Там сложная политика больших денег, а не технологий.
Ага, все гондоны, один я в белом халате.
G>>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего. A>Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков. Нету зоопарка. Разные версии FW не зависят друг от друга и могут спокойно сосуществовать на одной машине.
G>>А что же сразу не стали на C++ кодить? Ждали пока MS вас кинет? VB и был-то не самым лучшим языком, больше для скриптинга подходил. A>Я могу вам сейчас задать точно такой же вопрос: А чего вы на C# кодите? Ждёте пока MS вас кинет?
Ну я много на чем писал, на C# проще всего.
A>С# по скорости выполнения, пока тоже больше для скриптинга подходит.
Повторяйте это чаще — сами поверите. А пока из того что я видел на .NET работает быстрее C++. особенно это касается серверных приложений.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251920@news.rsdn.ru...
>>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >>> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >>> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >>> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму. > > S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую > всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC.
Сколько тех слоев-то?
> S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off. > Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти.
Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения.
>>> G>>Метапрограммирование должно быть везде. >>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. > S>Ну я только рад за разработчиков FPGA, только мне-то что с того? > С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
CUDA SDK никак не устроит? Или ты утверждаешь, что F# сам сумеет криво написанный (т.е., без учета особенностей вычисления на видеокарте) алгоритм переделать?
>>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >>> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. > S>Сложнее — потому что слой "шоколада" толще. > Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много.
Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
>>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >>> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >>> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании. > S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании > Особенно шаблоны и кастомные алокаторы
А что сложного в шаблонах и аллокаторах?
> S>Совсем уж бред то не пиши, ладно? > Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код. > Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией.
Действительно тормозящий — это в сто раз что ли ?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251920@news.rsdn.ru...
>>>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >>>> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >>>> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >>>> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму. >> >> S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую >> всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC. S>Сколько тех слоев-то?
Ну как обычно. 3-4 слоя + cross-cutting.
>> S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off. >> Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти.
S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения.
Ну так приведите бенчмарки здесь.
>>>> G>>Метапрограммирование должно быть везде. >>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. >> S>Ну я только рад за разработчиков FPGA, только мне-то что с того? >> С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
S>CUDA SDK никак не устроит? Или ты утверждаешь, что F# сам сумеет криво написанный (т.е., без учета особенностей вычисления на видеокарте) алгоритм переделать?
Ну не любой код на фшарпе, а какое-то его подмножество. Но тем не менее это будет статически типизированынй код.
>>>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >>>> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. >> S>Сложнее — потому что слой "шоколада" толще. >> Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много.
S>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
>>>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >>>> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >>>> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании. >> S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании >> Особенно шаблоны и кастомные алокаторы S>А что сложного в шаблонах и аллокаторах?
Действительно, совсем ничего
>> S>Совсем уж бред то не пиши, ладно? >> Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код. >> Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией.
S>Действительно тормозящий — это в сто раз что ли ?
Действительно тормозящий — это быстродействия которого было недостаточно для выполнения задачи.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3252058@news.rsdn.ru...
>>>>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >>>>> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >>>>> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >>>>> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму. >>> >>> S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую >>> всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC. > S>Сколько тех слоев-то? > Ну как обычно. 3-4 слоя + cross-cutting.
Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста?
>>> S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off. >>> Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти. > > S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения. > Ну так приведите бенчмарки здесь.
Ну те естественно уже не найду, канули так сказать в лету. Вот первое что попалось: http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html http://www.osnews.com/story/5602 http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/
>>>>> G>>Метапрограммирование должно быть везде. >>>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. >>> S>Ну я только рад за разработчиков FPGA, только мне-то что с того? >>> С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни. > > S>CUDA SDK никак не устроит? Или ты утверждаешь, что F# сам сумеет криво написанный (т.е., без учета особенностей вычисления на видеокарте) алгоритм переделать? > Ну не любой код на фшарпе, а какое-то его подмножество.
Дело даже не в подмножестве, не заточенный под карту код либо вообще не пойдет, либо будет работать медленне чем на CPU.
> Но тем не менее это будет статически типизированынй код.
А с CUDA это по твоему какой код будет?
>>>>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >>>>> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. >>> S>Сложнее — потому что слой "шоколада" толще. >>> Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много. > > S>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. > CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп?
>>> S>Совсем уж бред то не пиши, ладно? >>> Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код. >>> Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией. > > S>Действительно тормозящий — это в сто раз что ли ? > Действительно тормозящий — это быстродействия которого было недостаточно для выполнения задачи.
Ну это значит задачи такие, что им быстродействие не нужно.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, gandjustas, Вы писали:
S>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. G>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
Даже сложность интерфейса несравнима, не говоря уже об функционале.
так... маленькая ремарка, открыл одну и ту же картинку в обеих... сделал пару мазков брашем и там и там...
Paint.Net занял в памяти 60 Мб
Photoshop 120 Мб
Но ведь даже интерфейса открытого и сложности в нем меньше в намного больше раз чем в 2 раза.
Так что не нужно сравнивать несравнимое. Ненужно. Я с радостью посмотрю на примеры — но этот — несостоятелен!!!
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, gandjustas, Вы писали:
>>> G>>Метапрограммирование должно быть везде. >>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. S>>Ну я только рад за разработчиков FPGA, только мне-то что с того? G>С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
вы определитесь в чем вы разбираетесь в F# или в FPGA или в видеокартах, а то смеяться столько вредно для здоровья читателей.
Здравствуйте, Sergey, Вы писали:
S>Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста? если бы все в разработке делалось один разщ и навсегда, то вообще не возникало бы потребности в IoC.
Правка многотонных конфигов жутко утомляет. В коде же есть Intellisence, проверка типов и другие радости.
Причем нигде нету тестов на скорость выделения и освобожения памяти.
S>Дело даже не в подмножестве, не заточенный под карту код либо вообще не пойдет, либо будет работать медленне чем на CPU.
Это вы так думаете. F# — функциональный язык. Если использовать чисто функциональный код, то он может быт распараллелен автоматически. На CPU это не всегда целесообразно ибо большие накладные расходы. А на GPU или любых системах, спроектированных для параллельной обработки информации — вполне. >> Но тем не менее это будет статически типизированынй код.
S>А с CUDA это по твоему какой код будет?
Не такой. Можно будет код для CUDA выполнить без CUDA?
S>И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп?
paint.NET умеет 80% т того что умеет фотошоп.
Фотошоп тормозит везде по сравнению с Paint.NET. Только фильтры в фотошопе работыют быстрее, наверное потому что не через GDI+.
>> S>Действительно тормозящий — это в сто раз что ли ? >> Действительно тормозящий — это быстродействия которого было недостаточно для выполнения задачи. S>Ну это значит задачи такие, что им быстродействие не нужно.
Да, и задач таких большенство.
Сколько вы в своей работе используете программ, которым требуется много считать?
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, gandjustas, Вы писали:
>>>> G>>Метапрограммирование должно быть везде. >>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. S>>>Ну я только рад за разработчиков FPGA, только мне-то что с того? G>>С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
SD>вы определитесь в чем вы разбираетесь в F# или в FPGA или в видеокартах, а то смеяться столько вредно для здоровья читателей.
Он читает пресс релизы Майкрософт — а это уже о чем то да говорит
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, gandjustas, Вы писали:
S>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. G>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
DV>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
А вы Paint.NET видели? Photoshop — реально слон, очень тормозной.
DV>Даже сложность интерфейса несравнима, не говоря уже об функционале.
Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования.
Интерфейс у них очень похожий.
DV>так... маленькая ремарка, открыл одну и ту же картинку в обеих... сделал пару мазков брашем и там и там... DV>Paint.Net занял в памяти 60 Мб DV>Photoshop 120 Мб
DV>Но ведь даже интерфейса открытого и сложности в нем меньше в намного больше раз чем в 2 раза. DV>Так что не нужно сравнивать несравнимое. Ненужно. Я с радостью посмотрю на примеры — но этот — несостоятелен!!!
А какая разница, если на одинаковых операциях (кроме фильтров) фотошошоп тормозит сильнее Paint.NET.
Можете вечно кричать о несостоятельности примеров, но я фотошопом уже не пользуюсь именно из соображений быстродействия и удобства.
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, gandjustas, Вы писали:
>>>> G>>Метапрограммирование должно быть везде. >>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. S>>>Ну я только рад за разработчиков FPGA, только мне-то что с того? G>>С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
SD>вы определитесь в чем вы разбираетесь в F# или в FPGA или в видеокартах, а то смеяться столько вредно для здоровья читателей.
F# знаю, код для исполнения в видеокарте писал.
Если можно компилить F# в FPGA, то и аналогичная процедура для видеокарты или другого устройства параллельной обработки вполне возможна.
Здравствуйте, gandjustas, Вы писали:
G>А вы на ГОЛОМ С++ пишете?
На С++ имеется НАМНОГО больше разных бесплатных кроссплатформенных библиотек и фреймворков, чем на C#. Например для GUI кроме Qt ещё есть FL Toolkit, Ultimate, wxWidgets, FOX, VCF, ... вот вам огромный список: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
Это событие — результат соглашения с Novell. Так что скажите спасибо представителям Новелла за это.
On November 2, 2006, Microsoft and Novell announced a joint agreement whereby Microsoft agreed to not sue Novell’s customers for patent infringement. According to Mono project leader Miguel de Icaza, this agreement extends to Mono but only for Novell developers and customers. It was criticized by some members of the free software community because it violates the principles of giving equal rights to all users of a particular program.
A>>Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono. G>С# стандартизован ECMA и никому не пренадлежит. Также ECMA стандартизировала спецификацию CLR. G>Так что ваши слова — откровенный бред.
Пожалуйста, вот вам источники: http://ru.wikipedia.org/wiki/Mono
и http://www.gnome.org/~seth/blog/mono (Why Mono is Currently An Unacceptable Risk)
A>>Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете: G>>>А MS чтобы держаться на плаву надо придумывать что-то новое. G>Выход любого нового продукта анонсируют за год-два. Причем вместе с тупой рекламой предоставляют возможности будущим пиользователям бесплатно пользоваться продуктом во время тестирования
То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом.
Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы.
G>Те кто с свое время перешаело на VB.NET не прогадали.
А те кто в свое время перешли на С++ сейчас продолжают спокойно работать. Потому что им гадать вообще не надо. У них уже всё угадано.
A>>Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов. G>И потратить миллиарды на стоимости разработки
А что программировать под веб это что ли — какая-то ужасно нетривиальная задача?
Принцип работы с FastCGI можно выучить за 2 дня.
A>>И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++. G>Это в теории, а примеры "ультрабыстрых веб сервисов" есть?
Wt is a freely available library and application server that lets C++ programmers write modern web applications using a familiar C++ GUI programming style. Wt then renders the C++ applications to the web browser. Figure 1, for instance, is a running Wt application—a functional look-alike of the GMail composer, fully AJAX enabled, and written entirely in C++ using CSS for the markup.
Figure1:
From a programmer's perspective, the Wt API is similar to those offered by libraries such as Qt, Gtk, wxWindows, and the like. However, instead of rendering widgets to Windows/X11/ windows, Wt incrementally renders the widgets in web browsers. Wt completely hides the underlying web technologies (HTML, AJAX, XML, FastCGI, JavaScript, and DHTML), chooses a rendering and session-management strategy depending on browser capabilities, and deals with browser dialects. Being a native C++ library, web applications developed with Wt typically enjoy greater efficiency and a smaller footprint than Java or Ruby solutions.
Figure2:
G>>>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего. A>>Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков. G> Нету зоопарка. Разные версии FW не зависят друг от друга и могут спокойно сосуществовать на одной машине.
Разные версии MFC тоже не зависят друг от друга и могут сосуществовать на одной машине. Так вот, точно такой же зоопарк наблюдается и с версиями фреймворков. Только если раньше версии MFC были достаточно хорошо обратно совместимы, то сейчас вопросов по этому же поводу относительно фреймворков — задают намного больше.
G>Ну я много на чем писал, на C# проще всего.
Я рад за вас.
A>>С# по скорости выполнения, пока тоже больше для скриптинга подходит. G>Повторяйте это чаще — сами поверите. А пока из того что я видел на .NET работает быстрее C++. особенно это касается серверных приложений.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3252188@news.rsdn.ru...
> S>Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста? > если бы все в разработке делалось один разщ и навсегда, то вообще не возникало бы потребности в IoC. > Правка многотонных конфигов жутко утомляет. В коде же есть Intellisence, проверка типов и другие радости.
Не убедил, в общем. IoC в плюсах, при желании, есть.
>>> S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения. >>> Ну так приведите бенчмарки здесь. > > S>Ну те естественно уже не найду, канули так сказать в лету. Вот первое что попалось: > S>http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html > там еще вервый фреймворк, и то по некоторым тестам быстрее С# оказывается быстрее C++. > > S>http://www.osnews.com/story/5602 > Вот по этим тестам видно что математика медленее работает, а IO даже быстрее. > Получается для математики можно написать либу на C++, а для всего остального .NET юзать > > S>http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/ > Смотрел на код на C# и плакал. Там в как раз испольуется способ грантированно просадить производительность.
Тем не менее, в целом C# по бенчмаркам получается медленнее. И, что мне еще критичней — памяти жрет больше.
> Причем нигде нету тестов на скорость выделения и освобожения памяти.
А смысл? На плюсах критичные по быстродействию места пишут так, что большого количества выделений-освобождений памяти нет.
> S>Дело даже не в подмножестве, не заточенный под карту код либо вообще не пойдет, либо будет работать медленне чем на CPU. > Это вы так думаете. F# — функциональный язык. Если использовать чисто функциональный код, то он может быт распараллелен автоматически. На CPU это не всегда целесообразно ибо большие накладные расходы. А на GPU или любых системах, спроектированных для параллельной обработки информации — вполне.
А ищё можно написать искуственный интеллект, и он сам за нас программы сочинять будет Без рабочего распаралеливальщика это все фантазии.
>>> Но тем не менее это будет статически типизированынй код. > > S>А с CUDA это по твоему какой код будет? > Не такой. Можно будет код для CUDA выполнить без CUDA?
Конечно можно, только не без CUDA а без видеокарты. А какое это имеет отношение к статической типизации?
> S>И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп? > paint.NET умеет 80% т того что умеет фотошоп. > Фотошоп тормозит везде по сравнению с Paint.NET. Только фильтры в фотошопе работыют быстрее, наверное потому что не через GDI+.
Ссылки на бенчмарки, показывающие что фотошоп тормозит везде по сравнению с Paint.NET, привести не затруднит?
>>> S>Действительно тормозящий — это в сто раз что ли ? >>> Действительно тормозящий — это быстродействия которого было недостаточно для выполнения задачи. > S>Ну это значит задачи такие, что им быстродействие не нужно. > Да, и задач таких большенство.
И что с того? Я то про себя говорю, а не про большинство.
> Сколько вы в своей работе используете программ, которым требуется много считать?
Я не понял, ты проценты тормозного софта считать кинулся или продолжаешь доказывать, что памяти мало не бывает и оптимизировать ничего не надо?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>А вы на ГОЛОМ С++ пишете?
A>На С++ имеется НАМНОГО больше разных бесплатных кроссплатформенных библиотек и фреймворков, чем на C#. Например для GUI кроме Qt ещё есть FL Toolkit, Ultimate, wxWidgets, FOX, VCF, ... вот вам огромный список: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
Не думаю что огромный список библиоткек — это хорошо. тот кто использует библиотек это хорошо.
A>>>Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono. G>>С# стандартизован ECMA и никому не пренадлежит. Также ECMA стандартизировала спецификацию CLR. G>>Так что ваши слова — откровенный бред.
A>Пожалуйста, вот вам источники: http://ru.wikipedia.org/wiki/Mono A>и http://www.gnome.org/~seth/blog/mono (Why Mono is Currently An Unacceptable Risk)
Статья 2004 года. ИМХО отстала от текущей ситуации.
A>>>Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете: G>>>>А MS чтобы держаться на плаву надо придумывать что-то новое. G>>Выход любого нового продукта анонсируют за год-два. Причем вместе с тупой рекламой предоставляют возможности будущим пиользователям бесплатно пользоваться продуктом во время тестирования
A>То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом. A>Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы.
естественно, или вы планируете всю жизнь на одном и томже C++ писать?
G>>Те кто с свое время перешаело на VB.NET не прогадали. A>А те кто в свое время перешли на С++ сейчас продолжают спокойно работать. Потому что им гадать вообще не надо. У них уже всё угадано.
Ну не все, выйдет новая серсия стандарта C++ и посыпятся новые библиотеки, теже сложности с изучением и такаяже зависимость от вендоров на первых порах.
A>>>Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов. G>>И потратить миллиарды на стоимости разработки
A>А что программировать под веб это что ли — какая-то ужасно нетривиальная задача? A>Принцип работы с FastCGI можно выучить за 2 дня.
А написать сервис, который держит высокую нагрузку за 2 дня не получится.
A>>>И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++. G>>Это в теории, а примеры "ультрабыстрых веб сервисов" есть? A>Читать здесь: http://fastcgi.com A>Вот ещё: http://sourceforge.net/projects/witty/
Теория мало интересует. А гугл может (вернее мог до кризиса) себе позволить писать хоть на ассемблере.
G>>>>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего. A>>>Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков. G>> Нету зоопарка. Разные версии FW не зависят друг от друга и могут спокойно сосуществовать на одной машине.
A>Разные версии MFC тоже не зависят друг от друга и могут сосуществовать на одной машине. Так вот, точно такой же зоопарк наблюдается и с версиями фреймворков. Только если раньше версии MFC были достаточно хорошо обратно совместимы, то сейчас вопросов по этому же поводу относительно фреймворков — задают намного больше.
Я вот каждый день читаю форумы по .NET вопрос о совместимости задается раз в месяц.
Здравствуйте, Sergey, Вы писали:
>> S>Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста? >> если бы все в разработке делалось один разщ и навсегда, то вообще не возникало бы потребности в IoC. >> Правка многотонных конфигов жутко утомляет. В коде же есть Intellisence, проверка типов и другие радости.
S>Не убедил, в общем. IoC в плюсах, при желании, есть.
Конечно есть ибо IoC-принцип, но пользоваться им не очень удобно без соотвествующих средств автоматизации и настройки.
S>Тем не менее, в целом C# по бенчмаркам получается медленнее. И, что мне еще критичней — памяти жрет больше.
А где тесты памяти был?
>> Причем нигде нету тестов на скорость выделения и освобожения памяти. S>А смысл? На плюсах критичные по быстродействию места пишут так, что большого количества выделений-освобождений памяти нет.
Ну хорошо если так.
S>Ссылки на бенчмарки, показывающие что фотошоп тормозит везде по сравнению с Paint.NET, привести не затруднит?
А вы поставьте и запустите. Миркотесты в таком деле не нужны.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Denys V., Вы писали:
DV>>Здравствуйте, gandjustas, Вы писали:
S>>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. G>>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
DV>>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон. G>А вы Paint.NET видели? Photoshop — реально слон, очень тормозной.
DV>>Даже сложность интерфейса несравнима, не говоря уже об функционале. G>Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования.
Так 80% чем лично я пользуюсь покрывает MS Paint — означает ли это что я могу ставить на одну полку эти 2 продукта???
У меня жена — проффесиональный дизайнер — и paint.NET для неё поделка — не более. Не смешите людей лучше — а то уже честно — живот болит смеяться. Вы даже с очевидными вещами согласиться не можете. Я подозреваю что если б MS Paint был бы на .Net вы б и его без особого зазрения совести сравнили б с Photoshop.
G>Интерфейс у них очень похожий.
Очень похожий — не означает такой же.
Скажем так — он никакой по сравнинию с интерфейсом Photoshop. Я могу долго объяснять вам разницу, но основываясь на вашем поведении в этой теме — это вас нисколько не заденет.
DV>>так... маленькая ремарка, открыл одну и ту же картинку в обеих... сделал пару мазков брашем и там и там... DV>>Paint.Net занял в памяти 60 Мб DV>>Photoshop 120 Мб
DV>>Но ведь даже интерфейса открытого и сложности в нем меньше в намного больше раз чем в 2 раза. DV>>Так что не нужно сравнивать несравнимое. Ненужно. Я с радостью посмотрю на примеры — но этот — несостоятелен!!! G>А какая разница, если на одинаковых операциях (кроме фильтров) фотошошоп тормозит сильнее Paint.NET.
G>Можете вечно кричать о несостоятельности примеров, но я фотошопом уже не пользуюсь именно из соображений быстродействия и удобства.
Да я тоже не пользуюсь почти — у меня есть жена.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, gandjustas, Вы писали:
G>Или вы думаете что в один приекрасный день все бросят писат на C++ и разом перейдут на шарп?
Нет, не думаю. А вот некоторые — уже давно пишут, что "через два-три года" так и будет.
G>не сами вакансии интересуют, а количество различных конмпаний, работающих на C#. Косвенно этот праметр оценть можно по вакансиям.
Цифры в студию, обсуждать пока нечего — мои тебе (предлагаю перейти на ты) не нравятся, а свои ты не показываешь.
С>>Мои слова подтверждает не смысл этого сообщения (который, совершенно согласен, по сути бредовое), а наличие такого сообщения. G>Ну на просторах интернета можно много чего найти. На этом форуме можно найти сотни цитат про то что .NET загнется.
Если интересно мое мнение, то я не считаю, что .NET загнется.
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Denys V., Вы писали:
DV>>>Здравствуйте, gandjustas, Вы писали: S>>>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. G>>>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET. DV>>>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон. G>>А вы Paint.NET видели? Photoshop — реально слон, очень тормозной. DV>>>Даже сложность интерфейса несравнима, не говоря уже об функционале. G>>Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования. DV>Так 80% чем лично я пользуюсь покрывает MS Paint — означает ли это что я могу ставить на одну полку эти 2 продукта??? DV>У меня жена — проффесиональный дизайнер — и paint.NET для неё поделка — не более. Не смешите людей лучше — а то уже честно — живот болит смеяться. Вы даже с очевидными вещами согласиться не можете. Я подозреваю что если б MS Paint был бы на .Net вы б и его без особого зазрения совести сравнили б с Photoshop.
Ну учитывая что фотошоп еще и денег стоит, то только проф. дизайнерам и меет смысл им пользоваться.
G>>Интерфейс у них очень похожий. DV>Очень похожий — не означает такой же. DV>
Интерфейс на 99% совпадает с точностью до расположения интсрументальных окошечек.
DV>Скажем так — он никакой по сравнинию с интерфейсом Photoshop. Я могу долго объяснять вам разницу, но основываясь на вашем поведении в этой теме — это вас нисколько не заденет.
Ну объясните. Интсрументы рисования такие же, слои также работают, список undo-redo тоже не сльно отличается.
В чем отличие? В наборе фильтров разве что?
Вы еще не забывайте что над фотошопом немаленькая фирма работает достаточно долго, а Paint.NET сделан в основном энтузиастами и использует далеко неоптимальные низлежащие средства (GDI+).
Вот вам ещё информация: Mono’s implementation of those components of the .NET stack not submitted to the ECMA for standardization has been the source of patent violation concerns for much of the life of the project. In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits. The base technologies submitted to the ECMA, and therefore also the Unix/GNOME-specific parts, may be non-problematic. The concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms, i.e. parts composing Mono’s Windows compatibility stack. These technologies are today not fully implemented in Mono http://en.wikipedia.org/wiki/Mono_(software)
A>>То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом. A>>Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы. G>естественно, или вы планируете всю жизнь на одном и томже C++ писать?
А вы планируете всю жизнь переучивать одноразовые "технологии" Microsoft ?
G>Ну не все, выйдет новая серсия стандарта C++ и посыпятся новые библиотеки, теже сложности с изучением и такаяже зависимость от вендоров на первых порах.
Не поверите, но код написанный на C как компилировался 20 лет назад, так и сейчас отлично компилируется и работает, при чём в связке с новым стандартом.
И такого жесткого кидалова как у Microsoft никогда не было, и не будет.
G>>>И потратить миллиарды на стоимости разработки
Не понимаю откуда у многих такой необъяснимый страх перед веб сервисами.
Кстати, не флейма ради — вы с этой штукой работали? Я правильно понял — оно в рантайме генерирует HTML с жабаскриптом, соответствующие написанному на C++ коду? Т.е., если одновременно 10 юзеров разными данными одинаковую форму заполняют — HTML для юзеринтерфейса 10 раз генерироваться будет? Или, как с GWT, можно сделать чтобы статика шла отдельно, а вся динамика — единожды сгенерированный жабаскрипт на клиенте?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, gandjustas, Вы писали:
S>>И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп? G>paint.NET умеет 80% т того что умеет фотошоп. G>Фотошоп тормозит везде по сравнению с Paint.NET. Только фильтры в фотошопе работыют быстрее, наверное потому что не через GDI+.
фотошоп практически на всех операциях шустрее, только грузится медленей.
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Не думаю что огромный список библиоткек — это хорошо. A>Когда есть выбор — это очень хорошо. А у шарперов нет выбора.
И что, кому-то от этого плохо?
A>Вот вам ещё информация: Mono’s implementation of those components of the .NET stack not submitted to the ECMA for standardization has been the source of patent violation concerns for much of the life of the project. In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits. The base technologies submitted to the ECMA, and therefore also the Unix/GNOME-specific parts, may be non-problematic. The concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms, i.e. parts composing Mono’s Windows compatibility stack. These technologies are today not fully implemented in Mono A>http://en.wikipedia.org/wiki/Mono_(software)
Ну и что? Вы часто видели чтобы MS подавала в суды по таким прцедентам? Обычно МС использует патенты как раз для защиты от умников которые запатентуют ASP.NET или ADO.NET.
A>>>То есть, вы хотите сказать, что не всё так уж и плохо. Потому что у Майкрософт — кидалово с анонсом. A>>>Наверное если сейчас хорошо потренироваться, то потом можно будет даже научиться прогнозировать очередные циклы. G>>естественно, или вы планируете всю жизнь на одном и томже C++ писать?
A>А вы планируете всю жизнь переучивать одноразовые "технологии" Microsoft ?
И какие из технологий за последние 5 лет стали "одноразовыми" ?
A>И такого жесткого кидалова как у Microsoft никогда не было, и не будет.
Вас это так сильно обидело?
Не стоит личные обиды на технологии переность, глупо смотрится.
G>>>>И потратить миллиарды на стоимости разработки A>Не понимаю откуда у многих такой необъяснимый страх перед веб сервисами.
Какой страх, я как раз вебом занимаюсь и не по наслышке знаю чего стоит выдерживание огромной нагрузки.
A>Скажите, неужели это всё аж так "сложно" ?
Не смешите.
Напишите какой-нить блог на этом.
A>А вот вам ещё пример: A simple multi-threaded FastCGI application
О круто.
A>Писать на C++ веб сервисы так же легко как и на PHP (тем более, что там в основном используются библиотеки написанные на C). A>А популярность PHP обусловлена тем, что на shared хостингах запрещено запускать бинарники.
Думаете только этим? Напишите простенькое приложение, типа доски обявлений на PHP и на C++ и сравните трудозатраты.
Вы не в теме.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
FR>А ты немерли еще не изучил?
Еще нет. Сначала питон.
FR>А то читаю и кажется мне что год 2004, а ты не gandjustas а Влад
Через 5 лет буду про Nemerle холивары вести
Здравствуйте, gandjustas, Вы писали:
G>Сообщаю новость. Времена когда память была серьезны ограничением давно прошли.
Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает.
Конечно, управляемые среды могут противопоставить compacting GC фрагментации памяти в C++. Но в любом случае, сейчас вопросам потребления и работы с памятью придется уделять гораздо больше внимания, чем несколько лет назад.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandjustas, Вы писали:
DV>>>>Здравствуйте, gandjustas, Вы писали: S>>>>>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. G>>>>>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET. DV>>>>Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон. G>>>А вы Paint.NET видели? Photoshop — реально слон, очень тормозной. DV>>>>Даже сложность интерфейса несравнима, не говоря уже об функционале. G>>>Функционал paint.NET покрывает более 80% необходимостей непрофессионального рисования. DV>>Так 80% чем лично я пользуюсь покрывает MS Paint — означает ли это что я могу ставить на одну полку эти 2 продукта??? DV>>У меня жена — проффесиональный дизайнер — и paint.NET для неё поделка — не более. Не смешите людей лучше — а то уже честно — живот болит смеяться. Вы даже с очевидными вещами согласиться не можете. Я подозреваю что если б MS Paint был бы на .Net вы б и его без особого зазрения совести сравнили б с Photoshop. G>Ну учитывая что фотошоп еще и денег стоит, то только проф. дизайнерам и меет смысл им пользоваться.
G>>>Интерфейс у них очень похожий. DV>>Очень похожий — не означает такой же. DV>> G>Интерфейс на 99% совпадает с точностью до расположения интсрументальных окошечек.
вам видео ролик снять и показать отличия???
у меня 2 продукта запущено на разных мониторах
где ж они одинаковые на 99% то??????????? ГДЕ???????? Неужели не видно что у Photoshop все кастомно а в Paint стандартные виндовые контролы в основном???
Вы не овен по гороскопу случаем, а?
DV>>Скажем так — он никакой по сравнинию с интерфейсом Photoshop. Я могу долго объяснять вам разницу, но основываясь на вашем поведении в этой теме — это вас нисколько не заденет. G>Ну объясните. Интсрументы рисования такие же, слои также работают, список undo-redo тоже не сльно отличается. G>В чем отличие? В наборе фильтров разве что?
G>Вы еще не забывайте что над фотошопом немаленькая фирма работает достаточно долго, а Paint.NET сделан в основном энтузиастами и использует далеко неоптимальные низлежащие средства (GDI+).
Ну так и нечего сравнивать несравнимое. Чего ж вы эти продукты в пример тогда ставите? Похоливарить лишний раз???
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Germes, Вы писали:
G>Дабы подлить огня в затухающее пламя . G>Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса. G>Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
Ну понятно, что масс-маркет будет схопываться быстрее, чем всякого рода нишевые рынки.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Сообщаю новость. Времена когда память была серьезны ограничением давно прошли.
E>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает.
Выделенное еще надо доказать.
Часто бывает так что выгоднее создать дополнительную копию данных, расположенных в другом проядке, чтобы увеличить быстродействие.
E>Конечно, управляемые среды могут противопоставить compacting GC фрагментации памяти в C++. Но в любом случае, сейчас вопросам потребления и работы с памятью придется уделять гораздо больше внимания, чем несколько лет назад.
Но это не значит что память стоит экономить.
Здравствуйте, Germes, Вы писали:
G>Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса.
Нужно чтобы выпустили новый .NET абсолютно не совместимый с предыдущим, что бы дать новый толчек в IT. Так как 50% работы в IT это переезды: DOS -> WIN; WIN -> .NET; .NET -> ? Страшно подумать если некуда будет дальше переезжать при таком огромном количестве программистов в мире
G>Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
Наверное потому что порог входа ниже на .NET, поэтому набрать снова будет не проблема. Правда, если кризис затянется могут и не вернутся назад.
Здравствуйте, Denys V., Вы писали:
G>>Можете вечно кричать о несостоятельности примеров, но я фотошопом уже не пользуюсь именно из соображений быстродействия и удобства.
DV>Да я тоже не пользуюсь почти — у меня есть жена.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
gandjustas однажды (15 января 2009 21:37) писал в rsdn.cpp.applied:
> 8>Вы поймите, какие-то особые возможные случаи никому не интересны. > 8>В общем случае приложение на управляемом языке требует больше памяти. > 8>И бОльшие требования к памяти вседа шли в жертву тому что бы разработчик перестал думать о ней. > 8>БОльшие требования к памяти заложены в природе GC. > И какие-то подтверждения своим словам вы приводить будете?
На пальцах же объяснили, что таки да, дотнет может иногда потреблять меньше памяти, но в целом это не так.
Хотя... Тебя ничто не убедит уже. Ты зомбирован. Иди программируй лучше, пока есть возможность применять свои знания дотнета.
> Или в третий раз слив засчитаем?
Да хоть в восемнаццатый.
MasterZiv однажды (15 января 2009 17:57) писал в rsdn.cpp.applied:
> Ну, что-то я восторгов-то по поводу QT не разделяю. Такое же MFC, только > кроссплатформенное.
Я чтото восторга по поводу иномарок не разделяю. Такиеже машины как и жигули, только иностранные.
Germes однажды (16 января 2009 13:59) писал в rsdn.cpp.applied:
> Дабы подлить огня в затухающее пламя . > Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса. > Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
Да потомучто их как собак нерезанных. жаба и дотнет — простые языки\фреймворки, на них просто писать.
Здравствуйте, Sheridan, Вы писали:
S>На пальцах же объяснили...
Оппоненты как раз ничего не объясняли, они твердили, как зомби, «.NET жрёт память!» (Да и как они могут объяснить, если о .NET'е знают понаслышке?) На пальцах же приводили пример с десятью запущенными .NET-приложениями, не осознавая, что в действительности, увеличение числа запущенных приложений только уменьшает удельный перерасход ресурсов.
S>Ты зомбирован.
Как раз наоборот. Открою секрет, natural-born программистов на C# почти не бывает. Они происходят, например, из C++-программистов. Поэтому они, как и в случае gandjustas'а, вполне представляют себе картину по обе стороны баррикад и могут сравнивать. В отличие от оголтелых противников .NET, для которых уже и Рихтер — бред
Здравствуйте, Sheridan, Вы писали:
S>gandjustas однажды (15 января 2009 21:37) писал в rsdn.cpp.applied:
>> 8>Вы поймите, какие-то особые возможные случаи никому не интересны. >> 8>В общем случае приложение на управляемом языке требует больше памяти. >> 8>И бОльшие требования к памяти вседа шли в жертву тому что бы разработчик перестал думать о ней. >> 8>БОльшие требования к памяти заложены в природе GC. >> И какие-то подтверждения своим словам вы приводить будете? S>На пальцах же объяснили, что таки да, дотнет может иногда потреблять меньше памяти, но в целом это не так.
Будет в этой теме хоть одно доказательство выделенному утверждению?
... G>Так наверное в Adobe посчитали когда писали Photoshop (который на С++ и кроссплатформенный), который грузится секунд 30, хавает 200 метров памяти и показывает пустой воркспейс. G>Paint.NET при этом запускается 3 секунды и отжирает порядка 20 метров.
А-а-а!!! Офтоп, да, но не надо конкретно про Paint.NET, пожалуйста! Тем более сравнивать с Фотошопом (все равно что Wordpad c Word). Paint.net — бездарный софт, с которым я иногда вынужден иметь дело исключительно из-за того, что он беплатен и прост для объяснений другим людям. Он нулевой по юзабилити, супертормозной (за гранью приличия) на самых простейших операциях. Вот сейчас он запущен у меня в фоновом режиме, ничего не делает, но в течение полминуты съедал 50-100% CPU (только что утих наконец, зараза).
Re[14]: QT под LGPL. УРА!!!!!!!!!!!!!!!!
От:
Аноним
Дата:
17.01.09 12:38
Оценка:
Здравствуйте, goto, Вы писали:
G>А-а-а!!! Офтоп, да, но не надо конкретно про Paint.NET, пожалуйста! Тем более сравнивать с Фотошопом (все равно что Wordpad c Word). Paint.net — бездарный софт, с которым я иногда вынужден иметь дело исключительно из-за того, что он беплатен и прост для объяснений другим людям. Он нулевой по юзабилити, супертормозной (за гранью приличия) на самых простейших операциях. Вот сейчас он запущен у меня в фоновом режиме, ничего не делает, но в течение полминуты съедал 50-100% CPU (только что утих наконец, зараза).
... А>Загружаю большую bmp-ху в таск менеджере:
А>Paint.NET — 155 Mb А>MS Paint — 145 Mb А>SnagIT — 55 Mb
А>Итого, если тупо в память сгружать всю картинку то ее нигде не хватит. Алгоритмы рулят не зависимо от платформы
Я загрузил ту же картинку, что у меня была. Paint.net занимает 37мб (картинка < 1000 пикс., слоев штук 6-7). Paint.net спроектирована и написана не очень талантливыми специалистами, я в этом ни минуты не сомневаюсь. Изобретением алгоритмов и элементарными думами о юзабилити они себя скорее всего не истязали. Даже если картинка небольшая, то при наличии слоев пэйнт.нет начинает безбожно тормозить, практически невозможно работать. Бесплатность — ее единственная положительная черта. Пардон за офтоп еще раз (нервишки не выдержали ).
Здравствуйте, goto, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
G>... А>>Загружаю большую bmp-ху в таск менеджере:
А>>Paint.NET — 155 Mb А>>MS Paint — 145 Mb А>>SnagIT — 55 Mb
А>>Итого, если тупо в память сгружать всю картинку то ее нигде не хватит. Алгоритмы рулят не зависмо от платформы
G>Я загрузил ту же картинку, что у меня была. Paint.net занимает 37мб (картинка < 1000 пикс., слоев штук 6-7). Paint.net спроектирована и написана не очень талантливыми специалистами, я в этом ни минуты не сомневаюсь. Изобретением алгоритмов и элементарными думами о юзабилити они себя скорее всего не истязали. Даже если картинка небольшая, то при наличии слоев пэйнт.нет начинает безбожно тормозить, практически невозможно работать. Бесплатность — ее единственная положительная черта. Пардон за офтоп еще раз (нервишки не выдержали ).
Специалисты пограмотнее, чем у адобы видимо.
на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!).
работает на работает на остновных функциях на 10% медленнее фотошопа за счет использования GDI+.
Из недостатков — paint.net грузит проц при выделении картинок, а также непонятные тормоза при попытке нарисовать круг. Другого не нашел.
Здравствуйте, gandjustas, Вы писали:
G>Специалисты пограмотнее, чем у адобы видимо. G>на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!). G>работает на работает на остновных функциях на 10% медленнее фотошопа за счет использования GDI+. G>Из недостатков — paint.net грузит проц при выделении картинок, а также непонятные тормоза при попытке нарисовать круг. Другого не нашел.
Похоже что с оптимизацией не напрягались ни первые ни вторые
Здравствуйте, gandjustas, Вы писали:
G>Специалисты пограмотнее, чем у адобы видимо. G>на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!). G>работает на работает на остновных функциях на 10% медленнее фотошопа за счет использования GDI+. G>Из недостатков — paint.net грузит проц при выделении картинок, а также непонятные тормоза при попытке нарисовать круг. Другого не нашел.
Насчет спецов Адоба не знаю, знаком с относительно старой версией CS2 (уже там среди авторов попадались индийские имена ). Просто сравнивать ФШ и paint.net некорректно, весовые категории абсолютно разные. Сравнивать с большой натяжкой можно было бы ФШ с Gimp'ом (из бесплатных). Paint.net — откровенно малофункциональная и слабая программа во всех смыслах. Мне приходится переписываться с людьми и расказывать им о том, как проделать те или иные простые графические манипуляции, и я вынужден ссылаться на paint.net только из-за того, что она беплатная и простецкая. На таких, например, простейших операциях, как несложный коллаж из 6-МПикс фоток она просто сдохнет даже при наличии кучи свободной памяти. ФШ же отлично, летая, справится и с намного более монструозными проектами.
Общее у ФШ и P.N — это, пожалуй, только незаменимость каждого в своем классе.
Почему "пустой" ФШ столько жрёть, не знаю. Это конечно диковато. Совсем распустились некоторые программеры .
A>Писать на C++ веб сервисы так же легко как и на PHP (тем более, что там в основном используются библиотеки написанные на C).
A>А популярность PHP обусловлена тем, что на shared хостингах запрещено запускать бинарники.
Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
A>1) Cкорость написания программ на Qt достаточно высокая, чтобы охарактиризовать процесс как Rapid Application Development
Потому что они переизобрели Java/C# но для С++. За это им, правда, надо ставить памятник при жизни — это я без шуток говорю.
A>2) И код генерируется рационально — как с точки зрения скорости исполнения, так и объёма бинарника.
Угу. moc-preprocessor все так же создает диспатчи слотов таким способом:
if(slot == "slot1"){
}else if (slot == "slot2"){
}
F>я не понял, объясни, пожалуйста, на пальцах.. F>хочу вот я контрол, который выглядит как белый квадратик, а когда я нажимаю на него в разных местах, то там внутри контрола рисуются черные кружочки.. такое возможно?.
Можно. Можно сделать все, что угодно. Сабклассинг виджетов в Qt — это основной сопосб разработки. Имеется в виду, что станартные контролы (кнопки, поля ввода и т.п.) могут отличаться от стандартных контролов системы (хоть и редко)
M>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
Я вчера как раз кейген написанл на с++, правда кейген верхнего уровня все равно на пхп
Здравствуйте, Mamut, Вы писали:
M>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Mamut, Вы писали:
M>>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
DM>Ну, некоторые (гугл, яндекс) таки пишут на С++.
у них небось недостаточно нагруженные системы для .net
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
M>>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
DM>Ну, некоторые (гугл, яндекс) таки пишут на С++.
Ну, эти монстры — всем монстрам монстры, и использование С++ там оправдано, имхо
Прошу прощение за запоздалый ответ, не было времени написать benchmark раньше.
E>>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает. G>Выделенное еще надо доказать.
Вот простой тест. Создается std::map, в котором случайным образом обновляются элементы. В случае маленьких std::map, помещающихся в кэши процессора, обновления должны проходить быстрее, чем в случае больших std::map. У меня на машине с 4Mb L2 получаются следующие разультаты:
Видно, что по мере разростания дерева поиска скорость работы с одним элементом падает.
G>Часто бывает так что выгоднее создать дополнительную копию данных, расположенных в другом проядке, чтобы увеличить быстродействие.
Я полагал, что мы сейчас говорим не о случаях, когда за оптимизацию расхода памяти отвечает программист, а о случаях, когда на программу накладываются дополнительные накладные расходы помимо того, что сделал программист. В языках со сборкой мусора такими накладными расходами является не убранный GC мусор -- пока GC не пройдется этот объем может вызывать промахи мимо кэша. А может и не вызывать.
E>>Конечно, управляемые среды могут противопоставить compacting GC фрагментации памяти в C++. Но в любом случае, сейчас вопросам потребления и работы с памятью придется уделять гораздо больше внимания, чем несколько лет назад. G>Но это не значит что память стоит экономить.
Я очень удивлен тем, что из сказанный мной слов вы все-таки сделали вывод о том, что сейчас память не стоит экономить.
Ну и еще о том, что C++ гордятся низким потреблением памяти...
We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks using the oracular memory manager, and present real (non-simulated) runs that lend further validity to our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational collector with a noncopying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.
Мне кажется, что причины для этого таки есть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas
E>Прошу прощение за запоздалый ответ, не было времени написать benchmark раньше.
E>>>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает. G>>Выделенное еще надо доказать.
E>Вот простой тест. Создается std::map, в котором случайным образом обновляются элементы. В случае маленьких std::map, помещающихся в кэши процессора, обновления должны проходить быстрее, чем в случае больших std::map. У меня на машине с 4Mb L2 получаются следующие разультаты: E>
E>Видно, что по мере разростания дерева поиска скорость работы с одним элементом падает.
Так это касается только конкретной реализации std::mapю
G>>Часто бывает так что выгоднее создать дополнительную копию данных, расположенных в другом проядке, чтобы увеличить быстродействие.
E>Я полагал, что мы сейчас говорим не о случаях, когда за оптимизацию расхода памяти отвечает программист, а о случаях, когда на программу накладываются дополнительные накладные расходы помимо того, что сделал программист. В языках со сборкой мусора такими накладными расходами является не убранный GC мусор -- пока GC не пройдется этот объем может вызывать промахи мимо кэша. А может и не вызывать.
Мусор тут вообще ни при чем, гораздо больше зависит от самого алгоритма.
E>Ну и еще о том, что C++ гордятся низким потреблением памяти...
E>Cуществует исследование Quantifying the Performance of Garbage Collection vs. Explicit Memory Management, в котором, в частности, говорится: E>
E>We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks using the oracular memory manager, and present real (non-simulated) runs that lend further validity to our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational collector with a noncopying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.
E>Мне кажется, что причины для этого таки есть.
Конечно есть. Во многих случаях ручное распределение памяти может оказаться быстрее, чем сборщик мусора. Но для этого придется писать кастомный аллокатор для каждого конкретного куска кода, что очень затратно. GC рассчитан на то чтобы в среднем случае работать не хуже стандартных аллокаторов.
Здравствуйте, eao197, Вы писали:
E>Вот простой тест. Создается std::map, в котором случайным образом обновляются элементы. В случае маленьких std::map, помещающихся в кэши процессора, обновления должны проходить быстрее, чем в случае больших std::map. У меня на машине с 4Mb L2 получаются следующие разультаты: E>
Здравствуйте, gandjustas, Вы писали:
E>>>>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает. G>>>Выделенное еще надо доказать.
E>>Видно, что по мере разростания дерева поиска скорость работы с одним элементом падает.
G>Так это касается только конкретной реализации std::mapю
Вы усомнились в том, что при работе с большими объемами данных скорость может серьезно падать только из-за промахов мимо кэша процессора. Я привел пример, который это наглядно демонстрирует. Можете списать его на детали реализации std::map, если вам так проще.
Ситуация, однако, такова, что при современной организации доступа к памяти программистам придется даже пересматривать свое отношение к традиционно-используемым структурам данных. Например, к таким, как двоичные деревья поиска или даже одномерные массивы.
G>Во многих случаях ручное распределение памяти может оказаться быстрее, чем сборщик мусора. Но для этого придется писать кастомный аллокатор для каждого конкретного куска кода, что очень затратно.
Пожалуйста, продолжайте придерживаться этого мнения и дальше. У меня складывается впечатление, что чем больше Java/.Net-разработчиков будут так думать, тем дольше будет сохраняться спрос на C++ников.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вы усомнились в том, что при работе с большими объемами данных скорость может серьезно падать только из-за промахов мимо кэша процессора. Я привел пример, который это наглядно демонстрирует. Можете списать его на детали реализации std::map, если вам так проще.
Я знаю что промахи кеша снижают производительность, но увеличение размеров используемой памяти далеко не всегда приводит к увеличению количества промахов. Есть даже обратные примеры.
G>>Во многих случаях ручное распределение памяти может оказаться быстрее, чем сборщик мусора. Но для этого придется писать кастомный аллокатор для каждого конкретного куска кода, что очень затратно. E>Пожалуйста, продолжайте придерживаться этого мнения и дальше. У меня складывается впечатление, что чем больше Java/.Net-разработчиков будут так думать, тем дольше будет сохраняться спрос на C++ников.
Всегда будут люди, которые думают что на C++\С\ассемблере можно написать код быстрее.
Здравствуйте, gandjustas, Вы писали:
G>Я знаю что промахи кеша снижают производительность, но увеличение размеров используемой памяти далеко не всегда приводит к увеличению количества промахов. Есть даже обратные примеры.
Еще раз. Речь не идет об ухищрениях, на которые идет программист для повышения производительности. Если человек решил продублировать данные в памяти для повышения производительности конкретной операции, то здесь не суть важно, использует ли он C++ или Java -- это решение человека. Речь идет о том, какие накладные расходы может наложить GC на приложение в современных условиях. Например, захочет GC построить граф достижимости объектов, прошерстит 100Mb данных в памяти и выкинет из кэша процессора все нужные в данный момент страницы. Может такое быть или нет?
G>Всегда будут люди, которые думают что на C++\С\ассемблере можно написать код быстрее.
Я категорически требую включения в этот список еще и Фортрана, т.к. он до сих пор рулит в области HPC и конкурентов, по сути, не имеет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Я знаю что промахи кеша снижают производительность, но увеличение размеров используемой памяти далеко не всегда приводит к увеличению количества промахов. Есть даже обратные примеры.
E>Еще раз. Речь не идет об ухищрениях, на которые идет программист для повышения производительности. Если человек решил продублировать данные в памяти для повышения производительности конкретной операции, то здесь не суть важно, использует ли он C++ или Java -- это решение человека. Речь идет о том, какие накладные расходы может наложить GC на приложение в современных условиях. Например, захочет GC построить граф достижимости объектов, прошерстит 100Mb данных в памяти и выкинет из кэша процессора все нужные в данный момент страницы. Может такое быть или нет?
Когда у вас 100мб данных, то вам надо не о кеше процессора беспокоиться, а о страницах памяти. Кеш процессора играет роль на значительно меньших объемах.
А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет.
Здравствуйте, gandjustas, Вы писали:
G>Когда у вас 100мб данных, то вам надо не о кеше процессора беспокоиться, а о страницах памяти. Кеш процессора играет роль на значительно меньших объемах. G>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет.
При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Когда у вас 100мб данных, то вам надо не о кеше процессора беспокоиться, а о страницах памяти. Кеш процессора играет роль на значительно меньших объемах. G>>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет. C>При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом.
Что такое полный цикл GC? Как вызвать полный цикл?
Здравствуйте, gandjustas, Вы писали:
А>>>Paint.NET — 155 Mb А>>>MS Paint — 145 Mb А>>>SnagIT — 55 Mb
G>Специалисты пограмотнее, чем у адобы видимо. G>на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!).
А почему это хорошо?
Фотошоп хитро очень с памятью и дисками работает. И любит хавать "про запас". Но это только если памяти реально много...
Честно такой тест провести: Заводить RAM диски разных размеров, чтобы память отъесть и смотреть на СКОРОСТЬ РАБОТЫ того и другого в условиях разной степени жёсткости дефицита памяти...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
А>>>>Paint.NET — 155 Mb А>>>>MS Paint — 145 Mb А>>>>SnagIT — 55 Mb
G>>Специалисты пограмотнее, чем у адобы видимо. G>>на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!).
E>А почему это хорошо? E>Фотошоп хитро очень с памятью и дисками работает. И любит хавать "про запас". Но это только если памяти реально много...
чем больше памяти отжирает программа, чем чаще промахи мимо кэша(не я сказал).
Кстати фотошоп абсолютно одинаково хавает память независимо от объема установленной.
E>Честно такой тест провести: Заводить RAM диски разных размеров, чтобы память отъесть и смотреть на СКОРОСТЬ РАБОТЫ того и другого в условиях разной степени жёсткости дефицита памяти...
Где вы сейчас дефицит памяти нашли, она стоит как грязь. 2 гига поставить вообще ничего не стоит. А на машинах, которые не могут себе позволить много памяти, как нетбуки например, приложения типа фотошопа не запускают.
Здравствуйте, gandjustas, Вы писали:
G>Где вы сейчас дефицит памяти нашли, она стоит как грязь. 2 гига поставить вообще ничего не стоит. А на машинах, которые не могут себе позволить много памяти, как нетбуки например, приложения типа фотошопа не запускают.
Странно, мы с женой запускаем. Просто в поездки с собой проще ноут брать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Где вы сейчас дефицит памяти нашли, она стоит как грязь. 2 гига поставить вообще ничего не стоит. А на машинах, которые не могут себе позволить много памяти, как нетбуки например, приложения типа фотошопа не запускают.
E>Странно, мы с женой запускаем. Просто в поездки с собой проще ноут брать...
Читайте внимательнее. Я говорил про нетбуки.
Здравствуйте, gandjustas, Вы писали:
G>Читайте внимательнее. Я говорил про нетбуки.
Я думал ошибка.
Ну да у нас и на ноуте мало памяти
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gandjustas, Вы писали:
G>>>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет. C>>При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом. G>Что такое полный цикл GC?
Полный сбор всего мусора, включая обычно и упаковку за-tenure-еных объектов.
Да и периодический mark&sweep в tenured куче тоже удовольствия не доставит.
G>Как вызвать полный цикл?
Обычно он сам вызывается через некоторое время.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет. C>>>При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом. G>>Что такое полный цикл GC? C>Полный сбор всего мусора, включая обычно и упаковку за-tenure-еных объектов.
C>Да и периодический mark&sweep в tenured куче тоже удовольствия не доставит.
G>>Как вызвать полный цикл? C>Обычно он сам вызывается через некоторое время.
Есть же поколения. Сборщик мусора не постоянно всю память шерстит. Плюс есть дифференциация по размеру объектов.
Схема в меру эффективна. Всё неплохо оптимизировано.
У Вас такие специфичные задачи, что сборка мусора доставляет проблемы?
Здравствуйте, WizardBox, Вы писали:
C>>Обычно он сам вызывается через некоторое время. WB>Есть же поколения.
Есть. И что, в них собирать мусор не надо?
WB>Сборщик мусора не постоянно всю память шерстит.
Старшие (tenured) поколения обычно как раз постоянно в фоне проверяет конкурентный mark&sweep.
WB>Плюс есть дифференциация по размеру объектов. Схема в меру эффективна. Всё неплохо оптимизировано.
Оно ничем не поможет.
По факту — никакие эффективные GC не живут со swapping'ом. А GC, совместимые со swap'ом, не живут на обычных задачах.
WB>У Вас такие специфичные задачи, что сборка мусора доставляет проблемы?
Скажем так. Как работает мусоросборщик в Java я знаю на уровне ассемблерного кода, использующегося для установки барьеров.
Здравствуйте, gandjustas, Вы писали:
G>ИМХО одинаковые, из заметных на глаз отличий — пара дополнительных инструментальных окошет в фотошопе, другое раположение кнопок инструментов и другой выбор цвета.
Да что же вы такое все курите-то, а?! Paint.Net сравнивать с Photoshop-ом — это примерно как ВАЗ 7-й с БМВ 7-м — типа четыре колеса и руль и ехать может...
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
G>>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
С>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах.
ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
Здравствуйте, March_rabbit, Вы писали:
M_>Здравствуйте, Сергей, Вы писали:
С>>Здравствуйте, gandjustas, Вы писали:
G>>>Улыбнуло. WPF умеет работать с шейдерами и рисовать с помощью аппаратного ускорения, что Qt может предложить по этому поводу?
С>>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. M_>ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
Ну это больше проблемы линукса. Почему-то мне кажется что с остальными гуишными фреймворками ситуация не чуть не лучше.
Здравствуйте, March_rabbit, Вы писали:
С>>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. M_>ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
Во-первых, про видео я ровно ничего не говорил. Во вторых, вряд ли ты на этом qt разрабатывал.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, March_rabbit, Вы писали:
С>>>Qt может предложить использование аппаратного ускорения посредством OpenGL на Windows, Linux, MacOS и портативных/встраиваемых устройствах. M_>>ой не надо! разрабатывал я на этом qt терминал видеотелефонной связи... там даже видео прилично под линуксом не выведешь — надо оторвать себе все что болтается.... И то ушли на чисто X-овые функции.
С>Во-первых, про видео я ровно ничего не говорил. Во вторых, вряд ли ты на этом qt разрабатывал.
гыгы. это-то я понимаю, что БУДУЩАЯ версия всегда лучше текущей
но вот когда они ее выпустят — станет ли она лучше текущих?
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250476@news.rsdn.ru...
>> DV>Если вернуться к памяти, то вы опять же не правы. У меня к примеру есть приложение в котором свободная память — это очень важный ресурс — чем больше доступной памяти — тем большую сцену можно загрузить. Тем быстрее можно делать вычисления. С большим количеством данных можно работать. И терять этот показатель только из за недостатков выбранной платформы — это смешно. >> Совсем не смешно. Месяц работы программиста, который будет сэкономлен при использовании при использовании современных средств, стоит гораздо дороже, чем пара гигов памяти.
S>Или чем 20 гигов памяти, да? А ниче, что железо, которое 20 гигов умеет, уже стоит на порядок дороже обычного?
А давайте прикинем, что надо места на винте 100Тб? Это ж сколько бабла потребуется на такую железяку?
И сделаем вывод — прекращаем выпуск HD видео.
>> Об аппетитах программы по памяти стоит беспокоиться только если вы хотите своим продуктом охватить очень широкий рынок, например от нетбуков до серверов.
S>да-да, пара гигов * 10000 персоналок — скока стоит? Все еще дешевле месяца работы?
гм. что за арифметика?
А ничего, что в каждой персоналке стоит процессор ценой от 2 тыщ и винчестер с такой же ценой? По сравнению с 1200 за 2Г средненькой ДДр2 совсем другие деньги получаются, не так ли? А если вспомнить, что мониторы начинаются с 5 тыщ....
Ну и к чему эти подсчеты были?
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3250615@news.rsdn.ru...
>> S>Тут на самом деле можно поспорить. Я вот например не вижу, с чего бы это в масштабном проекте на дотнете писалось быстрее чем на плюсах. >> Плотность ошибок в коде мало зависит от языка. С# более высокоуровневый, чем C++, поэтому для реализации той же функциональности требуется написать меньше, а следственно ошибок в программе будет меньше.
S>Да-да, даже наследования реализации нету — а кода меньше писать, ага.
на самом деле, в плюс .Net говорит хотя бы то, что там нет НЕСКОЛЬКИХ КЛАССОВ СТРОК. В плюсах каждый более-менее крупный проект заводит свои классы. И развлекаешься каждый раз, конвертя из одного в другой формат.... А когда начинается юникод, тогда все становится еще веселее.
Чтобы не быть голословным укажу на мозиллу: там 5 классов строк или около того! Добавим сюда std::string, std::wstring, char *, QString. Уже 8 форматов. Бред.
>> А .NET вам в случае ошибки четко покажет где она произошла, и выдаст адекватный stack trace. S>Адекватный стек трейс у меня на плюсах выдается уже лет десять.
особенно здорово копаться в стеке после того, как кто-нибудь пройдется по памяти и свалит какой-нибудь внутренний указатель std::string...
вот тут начинаешь понимать, что доступ к памяти — это лишнее
или, когда система свалится в каком-нибудь траверзе boost-а. Вот тогда стек оказывается очень полезен: трасса начинается с цикла обработки событий или какого-нибудь левого процесса. И ищи по всей программе: кто же сгенерил-то это событие или вызвал траверс?
>> Кроме того управляемая среда позволяет вам не париться по поводу выделяемой памяти,
S>Не парится по поводу выделяемой памяти в моем случае возможно только при переходе на x64 — чего в силу некоторых особенностей лицензионной политики MS пока не случилось. Трех гигов в вин32 хватает с трудом.
Не знаю, у нас все разработчики на винде сидят на 32х битных платформах. Я под линуксом себе 8Г вставил, чтобы работать с несколькими виртуалками одновременно.
>> Кстати, вы на .NET работали? S>Не особо много — не понравилось.
эту поговорку мы уже знаем (про устриц)
>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо.
ээээ. напомню: быстродействие ПО зависит на 95% от алгоритмов.
У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
Здравствуйте, Cyberax, Вы писали:
E>>А почему это недостаток? Для переносимого GUI, возможно, это вообще самый разумный путь... C>На Mac'е, например, QT-шные приложения выглядят не совсем нативно. На Windows это тоже очень чувствуется.
Это не проблема собственной отрисовки. Вон, WPF вполне неплохо под винду мимикрирует при необходимости.
Здравствуйте, March_rabbit, Вы писали:
M_>У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
Здравствуйте, hattab, Вы писали:
M_>>У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
H>Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
Здравствуйте, criosray, Вы писали:
M_>>>У нас линуксовый проект написан процентов на 90 на С++, но благодаря мозилле и тому, что много логики написано на JS, тормозит основательно. Беру виндозный вариант этого же софта — не заметил замедления по сравнению с линуксовым, хотя виндозный на половину почти на .Net писан.
H>>Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
C>Показалось. Он сказал совсем другое.
Здравствуйте, criosray, Вы писали:
H>>Это мне показалось, или ты сейчас сказал, что .Net по сравнению с JS не тормозит?
C>Показалось. Он сказал совсем другое.
