V>>Потому что кривая либа. Потому что "изкаробки" работает плохо. Не умеет, не предусмотрено, не учли и т.д. V>>На самом деле для WPF достаточно лишь представлять себе внутренний поток событий, в первую очередь событий лейаута, сериализацию его для проигрывания на нейтивной стороне, чтобы заведомо знать, что стоит на WPF делать, а чему лучше поискать альтернативу. Там же можно захостить обычное WinForms-окошко а на нем DirectX. А рисовать графики в DirectX всяко не сложнее, чем в WPF, скорее наоборот. Т.е. это уже какая-то косность мышления, похоже... MM>В последнем нашем споре о WPF оказалось, что, хотя ты и весь из себя такой инженер, но легко забиваешь на факты, делая выводы, основанные на незнании
Давай конкретно, что там не так? Если ты про то, что по памяти перепутал public/protected в той ветке, то это что в том споре не принципиально, что в этом (тем более, что даже если бы это было так, то это легко обыгрывается, в отличие от остального).
MM>Также и сейчас ты пытаешься сыграть аналогично, сказав "бла-бла-бла, всё проще делать на DirectX". При этом тебя, вроде бы инженера, почему-то не волнуют ни требования, которые я привел выше, ни проблемы интеграции WinForms и DirectX с WPF, ни поддержка этих решений, как с точки зрения наличия программистов со знанием DirectX, так и наличия соответствующего DirectX на ОС заказчика.
Ну тогда и я предположу, что всё что ты тут разводишь сейчас — это бла-бла от незнания. Вернее, от банальной лени и нежелания посмотреть по сторонам, даже в рамках самого дотнета... бо WPF требует вполне конкретную версию DirectX. И ровно эта же версия DirectX обернута через DirectX managed и вы можете включать этот модуль в инсталляцию. И ровно эта же версия DirectX стоит у заказчика обязательно, просто потому что идет вместе с осью, начиная с WinXP и ее современными сервис-паками. Ну и должно было хватить начальной эрудиции чтобы вспомнить, что COM тоже через интерфейсы умеет отвязываться от конкретной реализации и конкретного положения либ на машине заказчика, т.е. даже имея тонну различных минорных версий 9-го DirectX у различных заказчиков, вас это беспокоить было ничуть не должно.
И да, если DirectX идет как дотнетная либа со всей документацией в MSDN (MSDN — лучшая дока в мире де-факто), то какое именно знание DirectX еще требуется? Вы вообще разработчики или погулять вышли?
MM>Так что, я думаю, поставь-ка ты мне снова минус-рожицу, и разговор можно считать закрытым.
Эээ... да у тебя каждый разговор так. Даже по ссылке по предмету обсуждения (обсуждалась сложность расширения инфраструктуры) тебе не удалось возразить по приведенным фактам. Ну и мой ответ там тебе вполне в тему, ознакомься.
Просто ты непроизвольно в каждом обсуждении пытаешься скатываться на одну и ту же мантру, что мол в WPF "изкаробки всё есть". А это невозможно принципиально ни для какой библиотеки/фреймфорка, вот и приходится одергивать. ИМХО, важнее для либ-фреймворков возможность/трудоемкость самостоятельного расширения функциональности... И если спустя столько лет нечего возразить по этому вопросу, то зачем же снова и снова с завидной регулярностью пишешь свои заклинания: "просто его надо хорошо знать". Конечно надо знать, с чем работаешь, что за банальности? Но верно и другое: надо знать, какие либы/технологии для чего нужны, тем более, что это уже не раз обсуждалось т.е. инфы полно. Форум "Мультимедиа" читаешь? Нет? (судя по реакции на "DirectX") А стоило бы разработчику WPF, бо WPF именно что претендует на мультимедиа-задачи...
В общем, это я и имел ввиду насчет косности мышления: выучили одну либу из донета и пихаем ее куда надо и куда не надо, мужественно преодолевая трудности. Зачем?
Здравствуйте, мыщъх, Вы писали:
М>лис, хром -- у всех них довольно жесткие требования к компиляторам. сборка новых версий это как бы не проблема (раз смогли собрать они -- смогу и я). а вот если хочешь собрать какую-то древность -- то нужной версии компилятора не найти, особенно если это не gcc, а коммерческий компилятор.
Эээ.. пролема обычно ровно наоборот, более новую версию невозможно собрать на более старом компиляторе. Но это, ИХМО, нормально: новые версии разрабатываются на новых инструментах, т.е. хочешь всё новое — переходи на новое.
А насчет давности: все старые ходовые версии gcc вроде как доступны.
Здравствуйте, MxMsk, Вы писали:
MM>с точки зрения наличия программистов со знанием DirectX
Пардон, освоить сабсет функций DX, нужный для рисования графиков, можно за день.
MM> так и наличия соответствующего DirectX на ОС заказчика.
На винде начиная с WXP стоит DX 9.0
Все старшие версии включают поддержку младших.
В DX 10,11 для рисования графиков нет ничего революционно нового.
В чём проблема то?
Здравствуйте, vdimas, Вы писали:
V>Да че ты так к UI привязался? Платформенно-независимого UI хоть попой ешь. Проблемы только у конкретно дотнета с их непереносимыми WinForms и WPF
Т.е. в случае плюсов платформонезависимую либу взять можно, а дотнета уже нельзя?
V>Брехня опять. Моно сильно отличается от версии MS.
Чем конкретно?
V> Для примера, QT для разных платформ имеет одно и то же АПИ. А у меня сходу ни одно приложение для дотнета на Моно не идет.
А у меня кое что идет.
V> Т.е. это надо забыть про дотнет и разрабатывать под Моно даже на виндах, чтобы получилось кроссплатформенно.
Не обязательно. Можно просто периодически проверять на Моно, различия там не такие уж и большие.
Здравствуйте, Трололоша, Вы писали:
НС>>А смешанные сборки — это ж Win32 бинарник, никакой кроссплатформенности без всяких вайнов. Т>Моно смешанные сборки даже на Windows не поддерживает.
Здравствуйте, alex_public, Вы писали:
_>Это действительно так. Но всё дело в том, что если писать ТАКОЙ код, то возникает вопрос: "а зачем нам тут вообще .Net тогда?".
Затем, что там, где нам unsafe не нужен, можно все делать в safe. Ваш КО.
_> Т.е. у нас тут по сути возникает бледная копия нативного C++
Логическую ошибку в своих рассуждениях сам найдешь?
Здравствуйте, Трололоша, Вы писали:
MM>>с точки зрения наличия программистов со знанием DirectX Т>Пардон, освоить сабсет функций DX, нужный для рисования графиков, можно за день.
Прикинул, в принципе я тоже могу выучить наизусть 10 функций из любого API за один день. Жаль, что этого недостаточно для качественный разработки.
MM>> так и наличия соответствующего DirectX на ОС заказчика. Т>На винде начиная с WXP стоит DX 9.0 Т>Все старшие версии включают поддержку младших. Т>В DX 10,11 для рисования графиков нет ничего революционно нового. Т>В чём проблема то?
Если эта оценка, как и предыдущая, сделана "за 1 день", то наверняка по факту траблов хватит. Но можешь вычеркнуть.
Обожаю WPF — ненавистников. Просто-таки квинтэссенция чистой ненависти. По поводу кроссплатформенного UI — все это сказки.
Кроссплатформенный сервис — еще могу поверить. Кроссплатформенные библиотеки(в основном реализации алгоритмов, не привязанные к конкретной задаче) — верю безоговорочно.
У многих плюсовиков наблюдается какая-то непонятная фобия на managed среды вообще и на дотнет в частности. Да, не труъ кроссплатформенная среда.
Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все).
Мне такие проекты как-то не попадались. И вообще, я не понимаю, почему любители Юникс плачут о том, что дотнет не поддерживается в *nix среде? Дотнетчики же об этом не плачут. Странно это все, короче.
Впрочем, если MS вдруг решит выпустить версию CLR под *nix, то будет очень интересно посмотреть, сколько проживет Qt и прочие Gtk.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Затем, что там, где нам unsafe не нужен, можно все делать в safe. Ваш КО.
Так RAII то нужен везде, а не в одном узком месте. В том смысле что должна формироваться (автоматических, без работы программиста) цепочка деструкторов сквозь всё приложение, а не один маленький unsafe класс. Да и другие вещи типа работы с памятью и вызова системных функций тоже обычно не в одном месте требуются.
Конечно если заниматься только рисованием формочек (хотя как выяснилось в этой теме, тут тоже не всё так просто — 20х20 чекбоксов уже не тянем ), то совсем другое дело — тут можно обойтись только safe кодом.
Т.е. всё как я и говорил с самого начала: для написания всякого внутрикорпоративного софта Java и .Net подходят отлично. А вот для более качественного и требовательного софта берём уже другие инструменты.
Но фанатикам не понять — они будут везде совать своё любимое. )))
_>> Т.е. у нас тут по сути возникает бледная копия нативного C++ НС>Логическую ошибку в своих рассуждениях сам найдешь?
Бледная копия потому, что проблемы быстродействия и работы на низком уровне не решает даже unsafe код.
Здравствуйте, Codechanger, Вы писали:
C>Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все). C>Мне такие проекты как-то не попадались.
Эээ, вы это серьёзно? Тут же ссылки можно даже не десятками, а сотнями кидать.
Здравствуйте, alex_public, Вы писали:
_>Так RAII то нужен везде, а не в одном узком месте. В том смысле что должна формироваться (автоматических, без работы программиста) цепочка деструкторов сквозь всё приложение, а не один маленький unsafe класс.
Серъёзно что ли? А мне вот как раз кажется, что детерминистическая финализация мало где нужна. _>Да и другие вещи типа работы с памятью и вызова системных функций тоже обычно не в одном месте требуются.
Ну, вот как раз работа с памятью в управляемой среде сделана хорошо. RAII нужен там, где в дотнете применяют IDisposable. А его по факту очень немного. И как раз для его упрощения в MC++ сделано вполне всё по уму.
_>Конечно если заниматься только рисованием формочек (хотя как выяснилось в этой теме, тут тоже не всё так просто — 20х20 чекбоксов уже не тянем ), то совсем другое дело — тут можно обойтись только safe кодом.
Впрочем, как сразу же выяснилось в этой же теме, 20x20 чекбоксов вполне себе тянем — тормоза воспроизвести в студии не удалось.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
V>Да и вообще, упоминание системных вещей смешнее всего. Например, ACE/boost/libevent/ptlib и еще куче других либ пофиг тонкости отличий АПИ операционнок, а вот "кроссплатформенному" дотнету (С) — не пофиг. Цирк как он есть.
И это ACE, которая еще вполне себе простая штука. В тот же буст я даже не полезу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sinclair, Вы писали:
S>Серъёзно что ли? А мне вот как раз кажется, что детерминистическая финализация мало где нужна.
Не в том дело. Допустим нам надо контролировать всего один ресурс. Но что бы всё сработало правильно нам мало просто добавить соответствующий деструктор в класс работающий с ресурсом. Нам надо что бы ещё и все владельцы убивали экземпляры нашего класса в нужное время — получается иерархическая цепочка на всю программу. Ну естественно это если мы хотим что бы всё автоматом работало. Можно и без этого — ручными вызовами и тогда действительно можно локализовать в одном месте с соответствующим ручным кодом там.
S>И как раз для его упрощения в MC++ сделано вполне всё по уму.
Кстати, а MC++ вообще кто-то использует? ) Я именно честно спрашиваю, потому что просто не знаю. Сам таких не видел. ))) Ну и как бы на мой взгляд странно использовать C++ в .Net. Т.е. как бы если уж мы принимаем все недостатки clr, то тогда уж не бесплатно — как минимум синтаксического сахара можно и добавить. Это я в смысле C# или ещё чего поприятнее. )))
S>Впрочем, как сразу же выяснилось в этой же теме, 20x20 чекбоксов вполне себе тянем — тормоза воспроизвести в студии не удалось.
Хы, ну в принципе так и должно быть. А то я уже прямо шокирован был. )))
Здравствуйте, Codechanger, Вы писали:
C>По поводу кроссплатформенного UI — все это сказки.
Ну почему. Если тебе не нужно что то красочное и цветастое, при этом быстро работающее, кросплатформенный UI вполне реален.
C>У многих плюсовиков наблюдается какая-то непонятная фобия на managed среды вообще и на дотнет в частности.
Нет в ней ничего непонятного. Обычный консерватизм (который, в свою очередь, вызван нежеланием ломать моск). В штыки будет восприниматься все альтернативное, имеющее ненулевую популярность.
И не у многих, кстати, а только у небольшого количества. Просто их очень заметно.
C>Знаете, я бы с удовольствием посмотрел бы на реальные кроссплатформенные проекты с человеческим интерфейсом(на десктопе, естественно, а не в вебе, там как раз понятно все).
Здравствуйте, alex_public, Вы писали:
_>Так RAII то нужен везде, а не в одном узком месте.
А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте. А в шарпе есть using, который не полностью автоматичен (но у него есть свои достоинства), а так же всякие intrinsic вещи типа SafeHandle.
_>Конечно если заниматься только рисованием формочек (
"Рисование формочек", а точнее качественный UI — одна из самых сложных задач в программировании.
_>хотя как выяснилось в этой теме, тут тоже не всё так просто — 20х20 чекбоксов уже не тянем )
Тут даже ехе'шник выложили, демонстрирующий что ничего не тормозит и косяки в чем то другом. И ты явно это видел. Но решил занятся откровенными и грубыми подтасовками.
_>, то совсем другое дело — тут можно обойтись только safe кодом.
А еще safe кодом можно обойтись в 99.99% серверного кода, к примеру. Это, по твоей внутренней шкале, круче формочек? Или нужно непременно драйвера писать, чтобы круто?
_>Но фанатикам не понять — они будут везде совать своё любимое. )))
Пока что на фанатика больше похож ты, когда предмет не знаешь, но огульно обвиняешь.
_>>> Т.е. у нас тут по сути возникает бледная копия нативного C++ НС>>Логическую ошибку в своих рассуждениях сам найдешь? _>Бледная копия потому, что проблемы быстродействия
Расскажи, что за проблемы быстродействия на работе ты решаешь?
_> и работы на низком уровне не решает даже unsafe код.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Так RAII то нужен везде, а не в одном узком месте.
НС>А для RAII unsafe и не нужен. C++/CLI вполне его обеспечивает в чисто managed контексте. А в шарпе есть using, который не полностью автоматичен (но у него есть свои достоинства), а так же всякие intrinsic вещи типа SafeHandle.
Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
_>>, то совсем другое дело — тут можно обойтись только safe кодом.
НС>А еще safe кодом можно обойтись в 99.99% серверного кода, к примеру. Это, по твоей внутренней шкале, круче формочек? Или нужно непременно драйвера писать, чтобы круто?
Мухаха, я на прошлой работе писал драйвера на яве .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
В жабу много чего надо добавить. Да и в шарп тоже. Но если у последнего компилятор на плюсах и необходимость сорелизов со студией палки в колеса вставляют, то в случае жабы просто неповоротливость и консервативность сам ого процесса изменения языка мешает.
E__>Мухаха, я на прошлой работе писал драйвера на яве .
Внутри МС был проект в том числе с написанием kernel-mode драйверов на шарпе, с учетом некоторой доработки unsafe конструкций и специального ядерного рантайма (codename Redhawk, если тебе это о чем то говорит, часть Раддеровского Midori). Но потом пришел Синовский и проект задвинули в маргинальную нишу.
Впрочем, если верить Mary-Jo Foley (а ей стоит верить) — кое что в Win8 оттуда просочилось.
Здравствуйте, alex_public, Вы писали:
_>Но фанатикам не понять — они будут везде совать своё любимое. )))
Тут еще как посмотреть, кто фанатик, а кто нет.
E__>>Вот чего я не понимаю, так это то, какого хрена в жабу никак не добавят using. Простая же штука, по сути — это банальный синтаксический сахар над try-finally.
НС>В жабу много чего надо добавить. Да и в шарп тоже. Но если у последнего компилятор на плюсах и необходимость сорелизов со студией палки в колеса вставляют, то в случае жабы просто неповоротливость и консервативность сам ого процесса изменения языка мешает.
Ну, отчасти эта консервативность — плюс(джава до сих пор бинарно совместима с древними махровыми версиями). Отчасти — минус. Но вот некоторые вещи именно на уровень языка(а не байткода) я бы добавил.
E__>>Мухаха, я на прошлой работе писал драйвера на яве .
НС>Внутри МС был проект в том числе с написанием kernel-mode драйверов на шарпе, с учетом некоторой доработки unsafe конструкций и специального ядерного рантайма (codename Redhawk, если тебе это о чем то говорит, часть Раддеровского Midori). Но потом пришел Синовский и проект задвинули в маргинальную нишу. НС>Впрочем, если верить Mary-Jo Foley (а ей стоит верить) — кое что в Win8 оттуда просочилось.
Ну, у меня были в client-mode, и кто-то скажет, что это и не драйвера вовсе. Но как тогда назвать код, который общается с устройством по его специфическому протоколу, а наверх дает высокоуровневое API для управления устройством(точнее, классом устройств, а там уже для каждого свой драйвер)?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, отчасти эта консервативность — плюс(джава до сих пор бинарно совместима с древними махровыми версиями).
Шарп тоже, до сих пор бинарно совместим с 2.0 (а небинарно с 1.0). Только бинарная совместимость никак развитию языка мешать не должна. В частности, для using точно рантайм менять не нужно.
E__>Ну, у меня были в client-mode, и кто-то скажет, что это и не драйвера вовсе
), то совсем другое дело — тут можно обойтись только safe кодом.
Тут же ссылки можно даже не десятками, а сотнями кидать.
