Re[22]: Матчасть 2
От: Qbit86 Кипр
Дата: 15.01.09 17:23
Оценка: 3 (1)
Здравствуйте, 8bit, Вы писали:

8>Дык ваш пост скорее наоборот это подтверждает :xz:


Простите меня, пожалуйста, у меня закрались сомнения в вашей вменяемости. Ещё раз простите.

8>Потому что в С/С++ я могу выделять и освобождать память так как мне захочется.


Ага. После того как затратите уйму времени на написание своего глючного аллокатора/менеджера памяти. Но в чуть менее чем всех проектах на Си/C++ этого не делают.

8>А отквоченные слова из книжки Рихтера вообще бред.


Рихтер — гуру не только .NET, но и платформы Windows, его книжка по WinAPI считается классикой. Он знает, о чём пишет. Не верите Рихтеру — спросим у Александреску:

По неизвестным мне причинам стандартный механизм распределения динамической памяти в языке C++ работает крайне медленно... Неэффективно работает с небольшими участками памяти... Стандартный распределитель управляет кучей, что часто вынуждает его занимать дополнительную память... Если возникает необходимость разместить в памяти объекты размером 8 байт, дополнительные затраты памяти составят от 50% до 400%.
(Красная Книжка Александреску, глава 4)


Должен признаться, меня немного задело ваше необоснованное сомнение в компетентности gandjustas'а («Прочитайте про устройство GC. Или разработчики на .Net в такие подробности не лезут?», «Плохо вы его знаете, плохо»). Также не делают вам чести фразы типа «все-таки силверлайт убивает ваш мозг», «и все таки .Net убивает ваш мозг». Вынужден выразить вам свой дизреспект :(
Глаза у меня добрые, но рубашка — смирительная!
Re[21]: что Qt может предложить по этому поводу
От: Сергей  
Дата: 15.01.09 17:47
Оценка: 1 (1) +4
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Сергей, Вы писали:


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


DV>>>>Возможно в далеком будущем (теоретически) — но не сейчас.

G>>>Ну да, года через 2-3.

С>>Про .NET это говорят уже лет пять.


G>Что говорят?


"года через два-три".

Например:
1. Года через два-три большинство шароварных программ будет написано на дотнете.
2. Года через два-три JIT-компилятор будет оптимизировать лучше, чем оптимизируют современные С/C++ компиляторы.
3. Года через два-три на дотнете критические к производительности вещи можно будет писать на дотнете.
Re[26]: что Qt может предложить по этому поводу
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 17:54
Оценка:
Здравствуйте, Sergey, Вы писали:


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>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо.

Это вы сами придумали?
Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов.
Но можно этих ошибок и не совершать.
Re[22]: Матчасть
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 17:57
Оценка:
Здравствуйте, Denys V., Вы писали:

DV>Предлагаю прекратить спор, ибо возможности Qt сравнивать с чисто MS продуктом смешно хотя бы потому что первое — кроссплатформа, второе — нет.

Первое работает только на десктопе, а второе и в вебе.

DV>Предлагаю на этом сойтись и все.

Ну как хотите.
Re[26]: QT под LGPL. УРА!!!!!!!!!!!!!!!!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 18:02
Оценка: :)
Здравствуйте, 8bit, Вы писали:

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


G>>Короче не пишите больше в этой теме, все равно ни одного здравого аргумента привести не можете.


8>


Как раз перед прочтением увидел новость http://lenta.ru/news/2009/01/15/laugh/
Re[22]: что Qt может предложить по этому поводу
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 18:03
Оценка:
Здравствуйте, Сергей, Вы писали:

С>>>Про .NET это говорят уже лет пять.


G>>Что говорят?


С>"года через два-три".


С>Например:

С>1. Года через два-три большинство шароварных программ будет написано на дотнете.
С>2. Года через два-три JIT-компилятор будет оптимизировать лучше, чем оптимизируют современные С/C++ компиляторы.
С>3. Года через два-три на дотнете критические к производительности вещи можно будет писать на дотнете.

Ссылки?
Re[18]: QT под LGPL. УРА!!!!!!!!!!!!!!!!
От: Сергей  
Дата: 15.01.09 18:09
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


Q>>Я мог бы попросить ещё пример кода, реализующего аппаратное ускорение для гуёвых контролов, но боюсь его увидеть


DM>А кто-нибудь может показать пример, где использование OpenGL/Direct3d ускорило какой-нибудь обычный гуевый контрол? [...]


Вот пример: здесь.
Правда, не совсем про "гуёвый контрол", там про SVG.
Re[23]: Матчасть 2
От: 8bit  
Дата: 15.01.09 18:23
Оценка: +2
Здравствуйте, Qbit86, Вы писали:

8>>Дык ваш пост скорее наоборот это подтверждает

Q>Простите меня, пожалуйста, у меня закрались сомнения в вашей вменяемости. Ещё раз простите.

Я на адептов ".Net" не обижаюсь .

Вы если не понимаете что сами написали, то какие ко мне притензии? Но я могу пояснить:

Вполне возможен случай, когда .NET-приложение будет требовать меньше памяти, чем Си-приложение, за счёт более плотной упаковки объектов.

Перевод: Иногда .Net приложение требует меньше памяти чем Cи-приложение. Но в целом это не так.

Вы поймите, какие-то особые возможные случаи никому не интересны.
В общем случае приложение на управляемом языке требует больше памяти.
И бОльшие требования к памяти вседа шли в жертву тому что бы разработчик перестал думать о ней.
БОльшие требования к памяти заложены в природе GC.
Re[24]: Матчасть 2
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 18:37
Оценка:
Здравствуйте, 8bit, Вы писали:

8>Вы поймите, какие-то особые возможные случаи никому не интересны.

8>В общем случае приложение на управляемом языке требует больше памяти.
8>И бОльшие требования к памяти вседа шли в жертву тому что бы разработчик перестал думать о ней.
8>БОльшие требования к памяти заложены в природе GC.
И какие-то подтверждения своим словам вы приводить будете?

Или в третий раз слив засчитаем?
Re[23]: что Qt может предложить по этому поводу
От: Сергей  
Дата: 15.01.09 18:43
Оценка: 13 (3) :))
Здравствуйте, gandjustas, Вы писали:

G>Ссылки?


Ну вот примерно такое:

то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется

здесь
Автор: DarkGray
Дата: 10.12.02
, 2002 г.

Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.

здесь
Автор: IT
Дата: 03.07.03
, 2003 г.

Ведь через пару-тройку лет (а точнее в 2006 когда выйдет Longhorn) Win32 не станет.

здесь
Автор: Pavel_Lechenko
Дата: 15.12.03
, 2003 г.
Re[24]: что Qt может предложить по этому поводу
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 18:57
Оценка: :)
Здравствуйте, Сергей, Вы писали:

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


G>>Ссылки?


С>Ну вот примерно такое:

С>

то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется

С>здесь
Автор: DarkGray
Дата: 10.12.02
, 2002 г.

И что, не развернулась?

С>

Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.

С>здесь
Автор: IT
Дата: 03.07.03
, 2003 г.

А вы сравните рынки C++ и C# за 2003 год и сейчаq. Почти правда.

С>

Ведь через пару-тройку лет (а точнее в 2006 когда выйдет Longhorn) Win32 не станет.

С>здесь
Автор: Pavel_Lechenko
Дата: 15.12.03
, 2003 г.

Этот оратор не учел что MS сохраняет обратную совместимость.
Re[17]: QT под LGPL. УРА!!!!!!!!!!!!!!!!
От: bkat  
Дата: 15.01.09 19:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Вообще-то юзеры не ищут чего-бы закрыть.


А я кто, не юзер что ли?
Я тут бурчу именно как юзер.
А язык и платформа — это дело десятое.
Если о ресурсах при программировании не думать,
то юзерам обычно все равно, почему система тормозит.
Re[27]: что Qt может предложить по этому поводу
От: Sergey Россия  
Дата: 15.01.09 19:48
Оценка:
Здравствуйте, 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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
три
Re[25]: что Qt может предложить по этому поводу
От: Сергей  
Дата: 15.01.09 19:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Сергей, Вы писали:


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


G>>>Ссылки?


С>>Ну вот примерно такое:

С>>

то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется

С>>здесь
Автор: DarkGray
Дата: 10.12.02
, 2002 г.

G>И что, не развернулась?

Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го".

С>>

Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.

С>>здесь
Автор: IT
Дата: 03.07.03
, 2003 г.

G>А вы сравните рынки C++ и C# за 2003 год и сейчаq. Почти правда.

Ну, у меня рынкомера нет, чтобы сравнивать. А вот про популярность языков программирования можно посмотреть здесь.
Там, кстати, есть сравнение с 2004-го года с 2008-м. Как был С++ популярнее, чем C#, так и остался.

С>>

Ведь через пару-тройку лет (а точнее в 2006 когда выйдет Longhorn) Win32 не станет.

С>>здесь
Автор: Pavel_Lechenko
Дата: 15.12.03
, 2003 г.

G>Этот оратор не учел что MS сохраняет обратную совместимость.

Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно.
Re[25]: что Qt может предложить по этому поводу
От: Кодёнок  
Дата: 15.01.09 20:14
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

G>И что, не развернулась?


Да как бы, почему-то, я не знаю почему, нет. Я сам с 2001-го года, как только увидел спецификацию C#, питаю большие надежды на .Net. Но Microsoft пока лишь доказывает, что она Microsoft.

С одной стороны, забавно наблюдать, как восемь лет назад C++серы усмехались, мол «вот майкрософт сделала неудачную попытку клонировать яву, через полгода умрет». Да впрочем, и до сих пор такие одаренные попадаются

С другой стороны, .Net даже близко не подошел к тому, чтобы стать платформой нового времени. Что я пока вижу, это как M$ включает в самый первый же гайд по WPF раздел "Optimizing WPF Application Performance", в котором говорится, что делать, если ваше приложение работает медленно или жрет слишком много. Интересно, не так ли?

Максимум, что сумел .Net — занял ниши, в которых C++ был плох. Рано еще говорить «будем писать на C#/WPF вместо C++/Qt, ибо разницы нет». Ибо разница есть. И я не предвижу ничего со стороны MS, чтобы эту разницу устранить.
Re[26]: что Qt может предложить по этому поводу
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 20:14
Оценка:
Здравствуйте, Сергей, Вы писали:

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


G>>Здравствуйте, Сергей, Вы писали:


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


G>>>>Ссылки?


С>>>Ну вот примерно такое:

С>>>

то же самое из .Net-ом, технология пока молодая, есть детские болезни, но завтра эти глюки поправят, и технология развернется

С>>>здесь
Автор: DarkGray
Дата: 10.12.02
, 2002 г.

G>>И что, не развернулась?

С>Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го".

Ну так технология развивается. "через пару лет будет ого-го" каждый раз говорят о разных вещах.

С>>>

Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.

С>>>здесь
Автор: IT
Дата: 03.07.03
, 2003 г.

G>>А вы сравните рынки C++ и C# за 2003 год и сейчаq. Почти правда.

С>Ну, у меня рынкомера нет, чтобы сравнивать. А вот про популярность языков программирования можно посмотреть здесь.

Этот индекс ужасен. Вы зайдите и посмотрите его определение.
Лучше смотрите в объявлениях о работе чем компании щанимаются.


С>>>

Ведь через пару-тройку лет (а точнее в 2006 когда выйдет Longhorn) Win32 не станет.

С>>>здесь
Автор: Pavel_Lechenko
Дата: 15.12.03
, 2003 г.

G>>Этот оратор не учел что MS сохраняет обратную совместимость.

С>Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно.

Вы считаете что любую бредятину, которую пишут на форуме пожно приводить в подтверждение своих слов?
Re[24]: что Qt может предложить по этому поводу
От: Anonim12  
Дата: 15.01.09 20:18
Оценка: 18 (5) +3 -1 :))) :))) :)
G>>Ссылки?
С>

в любом случае дни C++ сочтены.

С>здесь
Автор: IT
Дата: 03.07.03
, 2003 г.


Правда состоит в том, что лучшей альтернативы С++ в ближайшее время не предвидится. 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 лет. А гадать в какой следующий дурдом побежит команда Билли мне не интересно.

В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим.
Re[28]: что Qt может предложить по этому поводу
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.01.09 20:35
Оценка:
Здравствуйте, 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. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код.
Re[15]: QT под LGPL. УРА!!!!!!!!!!!!!!!!
От: bkat  
Дата: 15.01.09 20:41
Оценка:
Здравствуйте, Anonim12, Вы писали:

A>Qt представляется оптимальным решением:


Уже больше чем год пользуем
Пока довольны
Re[25]: что Qt может предложить по этому поводу
От: Denys V. Украина http://ua.linkedin.com/in/dvalchuk
Дата: 15.01.09 21:26
Оценка:
Здравствуйте, Anonim12, Вы писали:

G>>>Ссылки?

С>>

в любом случае дни C++ сочтены.

С>>здесь
Автор: IT
Дата: 03.07.03
, 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 чем больше мнений тем оптимальней выбор варианта... :)
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.