Здравствуйте, Andrbig, Вы писали:
МЮ>>Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться.. A>Наверняка пригодится для чего? Для общего образования. Никакой практической пользы в большинстве случаев нет, т.к. эти случаи реализованы в fw. Как именно они реализованы, через winapi, через ядро или через задницу — ни на что не влияет. A>Насколько я слышал, winapi не будет развиваться. Его развитие закончилось и время его кончается. Не исключено, что мы доживем до времени, когда все будет сплошь managed и win32 будет эмулироваться, как сейчас это происходит с DOS. A>Так что изучать winapi можно так же как DOS, с исторической или медотологической точки зрения. Практически — бесполезно (я не рассматриваю редкие специфичные случаи).
Как вы всё красиво расписали, прям утопическое (от слова утопить) будущее какое-то... Вот только почему-то M$ до сих пор не отказалось от поддержки 16-ти разрядных приложений и WinAPI до сих пор тянет груз старых функций ещё из Win 3.11. А вы говорите о смерти Win32 и unmaneged приложениях, а меж тем готово уже Win64 и оно во всю используется. Кстати .NET Framework не содержит и половины того, что доступно под Windows средствами того же WinAPI, а половина из того, что он всё таки содержит — такое убожество, что и говорить не хочется (вспомнить хотя бы Remoting — это называется механизмом коммуникации в распределённых системах?! Не смешите меня — DCOM и то лучше). Просто банальное добавление всех возможностей ОС во Framework поверх WinAPI может растянуться на годы, а уж тем более полная замена WinAPI Framework`ом. Чтобы не быть голословным приведу пример, не далее чем вчера я убил полдня для того, чтобы реализовать банальную вещь — удаление сертификата X509 из хранилища, перелопатив документацию по .NET`у и WSE 2.0, я понял, что штатными средствами это сделать невозможно и полез импортить нужные функции.
Кроме того, а как быть с теми языками, которые не поддерживают .NET и имеют жёсткие стандарты: C (не плюсы, а именно pure C), Fortran какой-нибудь. Перевод этих языков на рельсы .NET`а означает слом их стандартов. Не думаю, что у M$ получиться протащить кардинальные изменения стандартов в ISO, и не думаю, что они решаться похерить тоны кода написанные на этих языках. В конце-концов несмотря на то, что приложения с использованием WinAPI в последние годы писались и пишутся в основном на C++, сам WinAPI был заточен под pure C, потому что он был раньше и на нём писались приложения для Win 3.11!
Зачем же тогда вообще нужен .NET мелкософту? У меня на этот счёт есть пара своих соображений:
1) Полный и окончательный провал COM`а как технологии — ну не удобно его сипользовать, хоть ты тресни, а механизмы объектно-ориентированного доступа к сервисами ОС иметь хочется.
2) Неопределённость разработчиков процессоров x86-ой архитектуры (традиционной для Windows) относительного того, как будет поддерживаться 32-ух разрядный код на их 64-ёх разрядных процах — .NET начал разрабатываться именно тогда, когда Intel объявила о том, что их процы не будут поддерживать старые приложения. И .NET как раз наоборот является тем самым средством, которое позволило бы спасти существующие наработки и осуществить безболезненный переход с 32-ух разрядной на 64-ёх разрядную архитектуру, а не способом похорогить всё что было до него. Но с тех пор AMD заявила о полной обратной совместимости своих процов и Intel был вынужден пойти по этоу же пути...
Всё сказанное чистый IMHO. Выводы делайте сами.
И вот ещё на закуску:
Есть и другое объяснения того, почему Microsoft так решительно отвергла все свои наработки и взялась за новую лучшую концепцию. Лучше всего эту версию изложил Ron Burk из WDJ. Вот его версия:
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, VladD2, Вы писали:
VD>>Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
K>Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Чистое IMHO:
"Windows для профессионалов" + Страуструп надо прочитать обязательно, потому что это основы;
"Программирование платформы .NET" + книга по C#-у имеет смысл пролистать, хотя бы для того чтобы значть что это такое и с чем его едят, всё равно все достоинства и недостатки вы сможете оценить только на реальном проекте.
И вообще читайте всё, что вам хоть чуть-чуть интересно и что попадается под руку, всё равно не угадаете, что от вас потребует заказчик
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Kisloid, Вы писали:
K>Вот думаю, стоит ли щас начать изучать Си шарп.
Не. Не стоит. Уже поздно.
K> Ведь насколько мне известно, окончательной версии этого языка еще не вышло. Я стою перед выбором, изучить Си шарп или писать на MC++.
Если чего-то и не вышло, так это как раз окончательной версии МС++. В новой студии его перелопатили на 100% и в текущих бэтах он до ума так и не доведен.
K> А может вообще стоит не торопиться и писать unmanaged приложения, хочу кстати купить книжку Джеффри Рихтера "Windows для профессионалов, создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows".
Вот и я отм. Пусть прогресс идет соей дорогой. Кстати, покупать "Windows для профессионалов" тоже довольно поздно. Ты где до сих пор был то?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, .smoke, Вы писали:
S>Здравствуйте, Kisloid, Вы писали:
K>>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло.
S>имхо уже позно года три назад надо было начинать изучать C#.
Следуя твоей логике, C++ надо было изучать лет эдак 15 назад, а щас ой как поздно!
... << RSDN@Home 1.1.3 stable >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, Kisloid, Вы писали:
K>По моему никто не хоронит С++, хоронят MC++.
Мне пришлось немного повозиться с этим MC++. Готов лично заколотить свой гвоздик в крышку гроба.
K>На C++ обычно разрабатывают unmanaged приложения и думаю будут разрабатывать =) Т.к. как я понял сама платформа .NET строится на Вин АПИ и значит Вин АПИ не умрет, надеюсь =)
А вот это не факт. Это сейчас .NET строиттся на winapi, а что будет дальше — неизвестно. Многие winapi функции переправляют вызовы в ядро. Может в следующей версии .NET будет обращаться в ядро напрямик?
winapi — такая гнусь, что пора уж от него избавиться. Кто захочет возразить, пусть вспомнит различное поведение одних и тех же функций под NT и 95. Этого "счастья" в winapi навалом. .NET похоронит winapi. Это вопрос времени.
Разумеется, я говорю исключительно о прикладниках. Драйвера — дело системное. Там C++ — и вперед!
K>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло.
Остается только ломать голову, на какой же версии народ пишет уже второй год.
Возможно имеется в виду не C#, а CLI/C++?
K>Я стою перед выбором, изучить Си шарп или писать на MC++.
Писать под .NET на MC++ стоит лишь в очень специфических случаях вроде портирования legacy-кода и хитрого интеропа. Тем более, что этот язык официально мертв и развиваться не будет.
K>А может вообще стоит не торопиться и писать unmanaged приложения,
Зависит от того, какие. Вообще противопоставление "писать vs изучать" немного не ясно. Что мешает совмещать эти занятия?
Mab>Писать под .NET на MC++ стоит лишь в очень специфических случаях вроде портирования legacy-кода и хитрого интеропа. Тем более, что этот язык официально мертв и развиваться не будет.
1. Целая куча случаев, когда нужен С++, поддержка и развитие уже существующих разработак — один из многих и естественных примеров.
2. То что MC++ официально мёртв, совсем не значит что мёртв С++. Я знаю несколько контор, где до сих пор пользуются MSVC 6 и совершенно не собираются пока лезть на dotNet.
3. Я совершенно не против dotNet, я за dotNet. НО! Пытатся противопостовлять его С++, а тем более С++ хоронить — совершенно нелепо. Меня, например, в некоторых случаях dotNet не устраивают ограничения по производительности и качеству оптимизации.
Здравствуйте, Малич Юрий, Вы писали:
A>> Мне больше нравится другое — что fw одинаково работает на различных ОС от MS. win32 этим похвастать не мог.
МЮ>Really? Одинаково ограниченно вы хотели сказать . Внимание вопрос: Как вызвать из dotNet новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы? Или может прикладным программистам они не нужны?
Боюсь в случае с ОС от МС проблемы будут в том, как использовать "новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы" из не-дотнет приложений.
Это все чистая теория. Когда-нибудь все полезное, что есть в WinAPI, наверняка переползет под FW. Но писать-то приходится сегодня и сейчас. И пока еще очень много вещей, в которых без импорта WinAPI не обойтись.
Здравствуйте, Kisloid, Вы писали:
K>Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
Собсвтенно тот же рихтер для человека уже знакомого с программированием для виндовс — это оптимальный выбор. Только не "Windows для профессионалов", а ... честно говоря точно не понмню название. Но по дотнету у него только одна книжка, так что не промажешь. Еще очень полезно поглядеть стандарт языка. Там все довольно толково написано. Если пропустить скучьные разделы, то читается почти как книга.
Так же на нашем сатйте есть статьи по основным вопросам (коллекции, вэлью-типы и т.п.). Просто заходи в раздел по дотнету и читай то что больше интересно. Но это уже после того как освоишь рихтера и напушишь три десятка тестовых приложений.
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =)
Мнение твое с одной стороны верное. Но тем не менее знание дотнета это совсем не то же что знание ВыньАпи. Для программирования на С++ с использованием МФЦ оно нужно намного больше. А для дотнета больше нужно понимание того как работает рантайм. Умение эффективно использовать библиотеки. Библиотеки в дотнете на порядок более большие чем Апи-шные.
K> Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Я бы склонялся ко второму. А еще лучше просто купить и прочесть обе книжки. То же ВыньАпи можно с успехом осваивать и на шарпе. Даже больше знать будешь, так как каждую функцию вручную нужно будет описать для импорта.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>дравствуйте, Mab, Вы писали:
МЮ>1. Целая куча случаев, когда нужен С++, поддержка и развитие уже существующих разработак — один из многих и естественных примеров. МЮ>2. То что MC++ официально мёртв, совсем не значит что мёртв С++. Я знаю несколько контор, где до сих пор пользуются MSVC 6 и совершенно не собираются пока лезть на dotNet. МЮ>3. Я совершенно не против dotNet, я за dotNet. НО! Пытатся противопостовлять его С++, а тем более С++ хоронить — совершенно нелепо. Меня, например, в некоторых случаях dotNet не устраивают ограничения по производительности и качеству оптимизации.
По моему никто не хоронит С++, хоронят MC++. На C++ обычно разрабатывают unmanaged приложения и думаю будут разрабатывать =) Т.к. как я понял сама платформа .NET строится на Вин АПИ и значит Вин АПИ не умрет, надеюсь =)
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
K>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло. Я стою перед выбором, изучить Си шарп или писать на MC++. А может вообще стоит не торопиться и писать unmanaged приложения, хочу кстати купить книжку Джеффри Рихтера "Windows для профессионалов, создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows".
Изучать в любом случае надо — по-крайней мере, познакомитесь с современными понятиями, и не будете белой вороной, когда зайдет разговор об атрибутном программировании или рефлексии...
А писать — на ваш выбор. Если время не торопит, то ИМХО лучше unmanaged, т.к. вы поймете всю специфику работы приложений, внутреннее устройство windows, и когда наконец MS выпустит безглючную и нормальную версию .NET сможете перейти на нее (если захочете) со спокойной душой и со знанием дела.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Чем гадать, лучше знать WinAPI.
Зачем?
МЮ>Даже если .NET будет обращаться в ядро напрямик, всё равно там не будет всех нужных функций и придётся экспортировать.
Кому придется импортировать? Уж не программисту, точно. Авторам fw. Да какая разница, что там импортируется? Главное — работает!
МЮ>Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться..
Наверняка пригодится для чего? Для общего образования. Никакой практической пользы в большинстве случаев нет, т.к. эти случаи реализованы в fw. Как именно они реализованы, через winapi, через ядро или через задницу — ни на что не влияет.
Насколько я слышал, winapi не будет развиваться. Его развитие закончилось и время его кончается. Не исключено, что мы доживем до времени, когда все будет сплошь managed и win32 будет эмулироваться, как сейчас это происходит с DOS.
Так что изучать winapi можно так же как DOS, с исторической или медотологической точки зрения. Практически — бесполезно (я не рассматриваю редкие специфичные случаи).
A>Кому придется импортировать? Уж не программисту, точно. Авторам fw. Да какая разница, что там импортируется? Главное — работает!
Точно? Вы уверены? За свои слова отвечаете. Приходится программисту импортировать довольно часто. И увчерен придётся в будущем.
Гладко в жизни не бывает. Напрмер слабо найти во фрейворке обёрнутую функцию QueryPerformanceCounter? И таких фукций сотни!
МЮ>>Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться.. A>Наверняка пригодится для чего? Для общего образования. Никакой практической пользы в большинстве случаев нет, т.к. эти случаи реализованы в fw.
Да ну?ещё раз спрашиваю, вы уверены? Всегда что-ли?
>Как именно они реализованы, через winapi, через ядро или через задницу — ни на что не влияет.
Если бы всё было реализовано!
A>Насколько я слышал, winapi не будет развиваться. Его развитие закончилось и время его кончается.
1. Это пока слухи
2. Среди уже развитого много такого, чего нет в FW
A>Не исключено, что мы доживем до времени, когда все будет сплошь managed и win32 будет эмулироваться, как сейчас это происходит с DOS.
Не скоро. Пока API актуальней.
A>Так что изучать winapi можно так же как DOS, с исторической или медотологической точки зрения. Практически — бесполезно (я не рассматриваю редкие специфичные случаи).
Редкость говорите?
Вы мне с ходу сможете привести хоть одну популярную и требующую производительности программу, написанную на dotNet?
Здравствуйте, Andrbig, Вы писали:
A>А вот это не факт. Это сейчас .NET строиттся на winapi, а что будет дальше — неизвестно. Многие winapi функции переправляют вызовы в ядро. Может в следующей версии .NET будет обращаться в ядро напрямик?
A>winapi — такая гнусь, что пора уж от него избавиться. Кто захочет возразить, пусть вспомнит различное поведение одних и тех же функций под NT и 95. Этого "счастья" в winapi навалом. .NET похоронит winapi. Это вопрос времени.
Неужели будут переписывать весь Win API? Я думаю, что дот нет будет основываться на Вин АПИ еще долгое время =)
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, alexkro, Вы писали:
A>Нужно: игра, полностью портированная под .NET, с исходными кодами только на C#. Что-то вроде порта Quake на Java.
Зачем нужно? В чем проблема использовать несколько языков? Там где нужны оптимизации применять МС++/С++. А основной код (особенно прикладнаую логику игры) писать на том же шарпе.
A>Я не о том, что мне Quake нравится или нет. А о том, что на основании производительности Quake2 .NET нельзя делать выводы о применимости .NET для написания игр.
Это ж почему нельзя? Код полностью менеджед. Куча менеджед-мнменеджед переходов. И все прекрасно работает. Вбил себе в голову что ЖЦ это самый главный тормоз... вот только откуда ты это взял?
Еще рез говорю. Посмотри другие примеры. Там и ЖЦ испльзуется. И никаких проблем нет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А ты думешь, что вся ОС тоже менеджед? Код приложения то менеджед, а вот ввод-вывод пока что весь состоит из вызовов анменеджед-АПИ. Так что менеджед-анменеджед переходов там хватает. И как раз Ку2.нэт доказывает, что они делаются в МС++ очень эффективно. Разница с нэйтив вариантом несколько процентов. И на глаз вообще не видна.
Понятно. Просто обычно "менеджед-анменеджед" говорят о смешанном коде. А это называют интеропом.
Здравствуйте, Lloyd, Вы писали:
L>Понятно. Просто обычно "менеджед-анменеджед" говорят о смешанном коде. А это называют интеропом.
Менеджед-анменеджед переход так и называется. И осуществляться он может с помощью интеропа, а может, как в случае с МС++, с помощью IJW 0 встроенного в МС++ аналога интеропа. Отличается тем что не требует описания нэтив-методов и значительно более эффективен. Правда так еж и более опасен, потому как управление памятью и маршалинг (если он требуется) перекладывается на плечи программиста. IJW работает как для анменеджед-кода находящегося внутри проекта, так и для внешнего кода.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WM>>Если бы GUI был написан на MFC, или WTL, он тоже был бы приветливее. VD>Само собой. Вот только трудозатрат на его создание потребовалось бы куда больше и скорее всего опять был бы компромис.
Спорное утверждение. Написание нетривиального UI на дотнете — занятие не для слабонервных. Или для богатых
Здравствуйте, VladD2, Вы писали:
O>>Вы меня простите, что я священную корову трогаю, но в хоуме весьма простенький GUI VD>Ну, ты предъяви свой сложнений и тогда простим.
Я смогу предложить его купить через пару месяцев
Здравствуйте, VladD2, Вы писали:
VD>Там несколько десятков окон. Мнокие из которых довольно сложны. Там же динамически загружаемый интерфейс и преобразование ОО-модели в ГУИ. Если тебе влом разбираться, то хотя бы воздержись от заявлений по поводу продукта о котором мало чего знашь.
Так там все-таки окна сложные или они сложно сделаны? Это все-таки разные вещи, не находишь?
Здравствуйте, VladD2, Вы писали:
VD>Ну, то есть вместо аргуметов пошла софистика? Прекрасно понимашь, что речь об объеме работы и сложности кода.
Нет, просто видимо у нас разное понимание слова навороченный. Если для простого интерфейса пишется сложный код, то я считаю это глупость, а не наворот.
Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло. Я стою перед выбором, изучить Си шарп или писать на MC++. А может вообще стоит не торопиться и писать unmanaged приложения, хочу кстати купить книжку Джеффри Рихтера "Windows для профессионалов, создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows".
02.09.04 15:59: Перенесено из '.NET'
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Mab, Вы писали:
K>>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло. Mab> Mab>Остается только ломать голову, на какой же версии народ пишет уже второй год.
Mab>Возможно имеется в виду не C#, а CLI/C++?
Нет, имеется в виду именно Си шарп, а насколько мне известно, должен выйти C# 2.0 с добавленной поддержкой шаблонов и еще чего то =).
K>>Я стою перед выбором, изучить Си шарп или писать на MC++. Mab>Писать под .NET на MC++ стоит лишь в очень специфических случаях вроде портирования legacy-кода и хитрого интеропа. Тем более, что этот язык официально мертв и развиваться не будет.
Пасибо за совет =)
K>>А может вообще стоит не торопиться и писать unmanaged приложения, Mab>Зависит от того, какие. Вообще противопоставление "писать vs изучать" немного не ясно. Что мешает совмещать эти занятия?
Писал, пишу и буду писать ! Просто, до этого я писал используя MFС, а в книге Рихтера вроде про Win API. Буду писать и одновременно изучать =)
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
K>Нет, имеется в виду именно Си шарп, а насколько мне известно, должен выйти C# 2.0 с добавленной поддержкой шаблонов и еще чего то =).
Должен. Но беты VS2005 и второго фреймворка доступны уже достаточно давно.
Насчет "принятости" стандарта -- это вопрос риторический. Ясно, что к релизу язык либо совсем не изменится, либо изменения будут просто микроскопическими. Так что проблем писать на нем уже сейчас нет. Другое дело, что могут изменить API, но здесь уж риски нужно оценивать в зависимости от задачи.
K>Писал, пишу и буду писать ! Просто, до этого я писал используя MFС, а в книге Рихтера вроде про Win API. Буду писать и одновременно изучать =)
Одно другому не противоречит. Квалификация тех, кто пришел с MFC/WinAPI/C++ в .NET обычно выше, чем у "чистых дотнетчиков". По крайней мере у первых нет странных иллюзий о том, как это все работает.
Здравствуйте, Kisloid, Вы писали:
K>Нет, имеется в виду именно Си шарп, а насколько мне известно, должен выйти C# 2.0 с добавленной поддержкой шаблонов и еще чего то =).
В отличии от CLI/C++ шарп полностью совместим с предыдущей версией и переучиваться не прийдется. К тому же C# 2.0 уже давно доступен и можн сразу изучать его.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kisloid, Вы писали:
K>>Вот думаю, стоит ли щас начать изучать Си шарп.
VD>Не. Не стоит. Уже поздно.
А почему поздно ? Ведь все только начинает развиваться, С шарп то вышел всего года два назад =)
K>> А может вообще стоит не торопиться и писать unmanaged приложения, хочу кстати купить книжку Джеффри Рихтера "Windows для профессионалов, создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows".
VD>Вот и я отм. Пусть прогресс идет соей дорогой. Кстати, покупать "Windows для профессионалов" тоже довольно поздно. Ты где до сих пор был то?
И почему поздно покупать "Windows для профессионалов" ? Вин АПИ скоро изменится ? А с чего вообще тогда начать ? До сих пор я использовал MFC =)
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
K>А почему поздно ? Ведь все только начинает развиваться, С шарп то вышел всего года два назад =)
Ничего не поздно . Скоро выйдут "шаблоны"-дженереки, и в путь .
K>И почему поздно покупать "Windows для профессионалов" ? Вин АПИ скоро изменится ? А с чего вообще тогда начать ? До сих пор я использовал MFC =)
"Windows для профессионалов" — весьма полезная книга. Вообще токого рода знания только в плюс, лишними не будут точо. Хорошому программисту очень важно знать внутренности виндовс, тем более, что многие API функции в dotNet отсутствуют и часто приходится их туда экспортировать.
МЮ>2. То что MC++ официально мёртв, совсем не значит что мёртв С++. Я знаю несколько контор, где до сих пор пользуются MSVC 6 и совершенно не собираются пока лезть на dotNet.
Вопрос изначально был про .NET, поэтому "живость" нативного С++ к делу не относится
Здравствуйте, Andrbig, Вы писали:
A>А вот это не факт. Это сейчас .NET строиттся на winapi, а что будет дальше — неизвестно. Многие winapi функции переправляют вызовы в ядро. Может в следующей версии .NET будет обращаться в ядро напрямик?
Чем гадать, лучше знать WinAPI. Даже если .NET будет обращаться в ядро напрямик, всё равно там не будет всех нужных функций и придётся экспортировать. Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться..
В догонку раз пошла такая пьянка.
Ух! чувствую эта тема скоро уйдёт в священные войны!
A>Разумеется, я говорю исключительно о прикладниках. Драйвера — дело системное. Там C++ — и вперед!).
Вот сходу? Rar, 7z — это драйвера или прикладные программы? Почему они на MSVC до сих пор пишутся?
А VirtualDub, Canopus ProCoder ? А 3d игры? А Антивирус Касперского может тоже на dotNet написан?
Или это всё тоже драйвера?
A>Кому придется импортировать? Уж не программисту, точно. Авторам fw. Да какая разница, что там импортируется? Главное — работает!
Точно? Вы уверены? За свои слова отвечаете?
Приходится программисту импортировать довольно часто! И, уверен, придёться в будущем.
Гладко в жизни не бывает. Напрмер слабо найти во фрейворке обёрнутую функцию QueryPerformanceCounter? И таких нереализованных фукций сотни!
МЮ>>Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться.. A>Наверняка пригодится для чего? Для общего образования. Никакой практической пользы в большинстве случаев нет, т.к. эти случаи реализованы в fw.
Да ну? Ещё раз спрашиваю, вы уверены? Всегда что-ли?
>Как именно они реализованы, через winapi, через ядро или через задницу — ни на что не влияет.
Если бы всё было реализовано!
A>Насколько я слышал, winapi не будет развиваться. Его развитие закончилось и время его кончается.
1. Это пока слухи
2. Среди уже развитого много такого, чего нет в FW
A>Не исключено, что мы доживем до времени, когда все будет сплошь managed и win32 будет эмулироваться, как сейчас это происходит с DOS.
Не скоро. Пока API актуальней.
A>Так что изучать winapi можно так же как DOS, с исторической или медотологической точки зрения. Практически — бесполезно (я не рассматриваю редкие специфичные случаи).
Редкость говорите?
Вы мне с ходу сможете привести хоть одну популярную и требующую производительности программу, написанную на dotNet?
.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Гладко в жизни не бывает. Напрмер слабо найти во фрейворке обёрнутую функцию QueryPerformanceCounter? И таких фукций сотни!
Сотни, не сомневаюсь.
МЮ>Да ну?ещё раз спрашиваю, вы уверены? Всегда что-ли?
Уверен. Все в специфике задачи. Если надо работать с базой, UI и файлами — .NETа хватит. И я в этом уверен. Если же охота увешаться PerformanceCounter-ами — не хватит. NET расчитан на прикладников, а не для того, чтобы лезть в кишки ОС.
МЮ>Если бы всё было реализовано!
Реализовано не все, это не новость. Вопрос в другом — а нужно ли чтобы было реализовано все? В MS немного поучились на своих ошибках и пошли курсом МАКа: система отдельно, приклад — отдельно. .NET — механизм такого разделения. Прога под .NET сможет работать и под *nix, и под МАК — был бы fw. А если реализовать все, включая не-прикладные вещи типа Performance Counter-ов, то никакой тебе совместимости и переносимости. Логично?
МЮ>Не скоро. Пока API актуальней.
Смотря для каких задач. Я пишу Windows Service, работу с БД? с файлами и UI. Ни разу не возникла необходимость использования winapi.
МЮ>Вы мне с ходу сможете привести хоть одну популярную и требующую производительности программу, написанную на dotNet?
Страшно извиняюсь, но при чем тут популярность? Это нынче основной критерий?
Здравствуйте, Mab, Вы писали:
Mab>Это все чистая теория. Когда-нибудь все полезное, что есть в WinAPI, наверняка переползет под FW. Но писать-то приходится сегодня и сейчас. И пока еще очень много вещей, в которых без импорта WinAPI не обойтись.
Вот, более спокойный ответ. Можно задать более спокойный вопрос: нельзя ли огласить список, в каких случаях "не обойтись"? Перечислять функции не стоит конечно , хватит группировки по функционалу (например Perfomance Counter).
Здравствуйте, Andrbig, Вы писали:
A>Уверен. Все в специфике задачи. Если надо работать с базой, UI и файлами — .NETа хватит. A>Смотря для каких задач. Я пишу Windows Service, работу с БД? с файлами и UI. Ни разу не возникла необходимость использования winapi.
Вот! Это всё что входит в круг прикладных задач? Всё остальное, это драйвера что-ли? Что все прикладные программы вписываются работу в Windows Service, работу с БД, с файлами и UI? У меня, например, свой круг прикладных задач, в котором БД, с файлами и UI — процентов 10, но драйверов я тоже не пишу.
A>Прога под .NET сможет работать и под *nix, и под МАК — был бы fw.
В теории да, в реальном мире — увы нет. И в ближайшее время ситуация не изменится к лучшему.
A>А если реализовать все, включая не-прикладные вещи типа Performance Counter-ов, то никакой тебе совместимости и переносимости. Логично?
1. Её (переносимости) и так нет. Пока это только маркетинговый миф.
2. Поэтому и надо знать API, что совместимости всё равно нет, а всё необходимое в dotNet не реализовано.
A>Страшно извиняюсь, но при чем тут популярность? Это нынче основной критерий?
Я извиниюсь в свою очередь, а что критерием является круг ваших собственных задач? Нет!
Под популярностью я имел ввиду общедоступный продукт, а не программу по заказу организации X
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Ух! чувствую эта тема скоро уйдёт в священные войны!
Да нечего тут воевать. Надо просто понять, для чего .NET годится, а для чего — нет.
МЮ>Вот сходу? Rar, 7z — это драйвера или прикладные программы? Почему они на MSVC до сих пор пишутся? МЮ>А VirtualDub, Canopus ProCoder ? А 3d игры? А Антивирус Касперского может тоже на dotNet написан? МЮ>Или это всё тоже драйвера?
Паковщики — уже давно выжали все возможности. Различия между ними по степени есть, но не критичны. На первый план выходят другие параметры. Например, скорость. Не удивлюсь, если узнаю, что кто-нибудь и ассемблером балуется.
VirtualDub, Canopus ProCoder — не знаю что это
3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
Антивирусы — интегрируются в систему, чтобы отлавливать обращения к файлам. Хм, даже и не знаю... вроде бы каждое второе приложение так делает... Нет, все же это ближе к драйверам. Точнее, к системному программному обеспечению.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Вот! Это всё что входит в круг прикладных задач?
У меня — да.
МЮ>Всё остальное, это драйвера что-ли?
Есть еще системное программирование, т.е. написание прог, плотно интегрированных с системой.
МЮ>Что все прикладные программы вписываются работу в Windows Service, работу с БД, с файлами и UI? У меня, например, свой круг прикладных задач, в котором БД, с файлами и UI — процентов 10, но драйверов я тоже не пишу.
А у меня — практически все. Каждому свое... Кстати, если не секрет, из чего состоят оставшиеся 90%?
МЮ>В теории да, в реальном мире — увы нет. И в ближайшее время ситуация не изменится к лучшему.
Вы видите будущее? А как же .NET for Linux?
МЮ>1. Её (переносимости) и так нет. Пока это только маркетинговый миф. МЮ>2. Поэтому и надо знать API, что совместимости всё равно нет, а всё необходимое в dotNet не реализовано.
1,2 — спорно. Это не миф, более того, делаются реальные шаги в этом направлении. Как далеко зайдут эти шаги — вопрос совсем другой.
МЮ>Я извиниюсь в свою очередь, а что критерием является круг ваших собственных задач? Нет!
Очень решительно! Вах! Для меня критерием является заказчик и его желания.
МЮ>Под популярностью я имел ввиду общедоступный продукт, а не программу по заказу организации X
Пока fw не распространится так же широко, как и Windows (вместе с новыми его версиями), говорить о популярности для .NET программ бессмысленно.
Здравствуйте, Andrbig, Вы писали:
A>Паковщики — уже давно выжали все возможности. Различия между ними по степени есть, но не критичны. На первый план выходят другие параметры. Например, скорость. Не удивлюсь, если узнаю, что кто-нибудь и ассемблером балуется.
Тем не менее, это не драйвера.
A>VirtualDub, Canopus ProCoder — не знаю что это
Работа с видео
A>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
Тем не менее игры — вполне прикланые программы.
A>Антивирусы — интегрируются в систему, чтобы отлавливать обращения к файлам. Хм, даже и не знаю... вроде бы каждое второе приложение так делает... Нет, все же это ближе к драйверам. Точнее, к системному программному обеспечению.
1. У касперского есть конечно служба — монитор, но всё остальное там всё равно не dotNet.
2. Тем не менее это лишь мизерная часть программ, которые не являются БД и т.п.
A>Вот, более спокойный ответ. Можно задать более спокойный вопрос: нельзя ли огласить список, в каких случаях "не обойтись"?
Боюсь, я не компетентен составлять такой "список" . Могу лишь сказать, где самому пришлось развлекаться с pinvoke/MC++:
1) Нестандартные контролы. То, что предлагает WinForms, мягко говоря недостаточно. Тот же самый virtual list view пришлось руками делать.
1') Доступ к GDI, которое практически в FW не представлено (разве что ControlPaint-ом). GDI+ не подходил из-за соображений скорости.
2) Управление процессами (запуск с флагом DEBUG_PROCESS, отслеживание расходуемых ресурсов итп). Класс Process здесь малополезен.
3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke.
Каждый может дополнить этот список в соответствии с собственным опытом
В общем, все очень сильно от задачи зависит, спорить с этим бессмысленно. Пишут же люди на Java без JNI.
Здравствуйте, Andrbig, Вы писали:
A>У меня — да. A>Очень решительно! Вах! Для меня критерием является заказчик и его желания.
И вы поэтому не рекомендуете другим изучать API?
А если я буду другим рекомендовать например не устанавливать linux,потому как я ей не пользуюсь.
A>Есть еще системное программирование, т.е. написание прог, плотно интегрированных с системой. A>Пока fw не распространится так же широко, как и Windows (вместе с новыми его версиями), говорить о популярности для .NET программ бессмысленно. :
Это всё причины знать API.
A>А у меня — практически все. Каждому свое... Кстати, если не секрет, из чего состоят оставшиеся 90%?
Алгоритмы обработки данных. Ещё поддержка существющих программ на С++ написанных давно, ещё без поддержки COM.
Кроме это частенько я занимаюсь низкоуровневым тестированием процессоров, пишу ассемблерные вставки.
A>Вы видите будущее? А как же .NET for Linux?
Я трезво со здоровым консерватизмом смотрю на это. Linux сообщество всё равно будет отставать, всегда. dotNet FW вышел уже довольно давно, а lin до сих пор не может похвостатся полной совместимостью даже с WinForms версии 1.0
A>1,2 — спорно. Это не миф, более того, делаются реальные шаги в этом направлении. Как далеко зайдут эти шаги — вопрос совсем другой.
Не-а, это вопрос тот-же. Стоит ли не знать API ради .Net? Всё равно API знать нужно.
Кстати вы глубоко заблужадетесь, если вдруг думаете, что я ярый противник dotNet. Он мне на самом деле в чём-то нравится и я иногда пишу в нём простенькие утилитки. Я сам в своё время хотел на него перейти, но когда убедился что у меня частенько связаны руки, я отложил это дело в долгий ящик. Я уверен, что API ещё довольно долго будет нужен.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>И вы поэтому не рекомендуете другим изучать API?
Да. Я рекомендую изучать то, за что платят деньги заказчики. Ну а будут деньги, можно и поразвлекаться популярными и распространенными, но не факт что приносящими деньги программами. Вы лично заплатили за rar?
МЮ>А если я буду другим рекомендовать например не устанавливать linux,потому как я ей не пользуюсь.
Я буду рекомендовать не ставить linux потому как под ней меньше приложений и круг их ограничен. У каждого свои аргументы.
МЮ>Это всё причины знать API.
Знания ради знаний?
МЮ>Алгоритмы обработки данных. Ещё поддержка существющих программ на С++ написанных давно, ещё без поддержки COM. МЮ>Кроме это частенько я занимаюсь низкоуровневым тестированием процессоров, пишу ассемблерные вставки.
Серьезно. Я последний раз писал на ассемблере стековую оконную библиотеку в 80-х годах — 3 кб получилось. Эх, ностальгия... А кстати, где в работе с данными, вызове старого кода и тестировании процессора вызовы winapi?
МЮ>Я трезво со здоровым консерватизмом смотрю на это. Linux сообщество всё равно будет отставать, всегда. dotNet FW вышел уже довольно давно, а lin до сих пор не может похвостатся полной совместимостью даже с WinForms версии 1.0
Ну это проблемы lin сообщества. Мне больше нравится другое — что fw одинаково работает на различных ОС от MS. win32 этим похвастать не мог.
МЮ>Не-а, это вопрос тот-же. Стоит ли не знать API ради .Net? Всё равно API знать нужно.
Стоит ли знать API ради API?
A>Здравствуйте, Малич Юрий, Вы писали:
A>Да. Я рекомендую изучать то, за что платят деньги заказчики. Ну а будут деньги, можно и поразвлекаться популярными и распространенными, но не факт что приносящими деньги программами. Вы лично заплатили за rar?
Я много за что заплатил. В этом списке кстати ни одной dotNet программы.
Я вообще не рекомендую замыкать свои знания только на том, что нужно заказчику. Заказчики приходят и уходят, а знания остаются.
A>Я буду рекомендовать не ставить linux потому как под ней меньше приложений и круг их ограничен. У каждого свои аргументы.
У приложений dotNet круг тоже ограничен. Весьма. Ваш тому пример.
Звук, видео, САПР, игры — там dotNet не нужен, а разработчики, владеющие API — нужны.
A>Знания ради знаний?
Знания ради умений и опыта. Чтобы написать хорошую программу, которая не ограничевается Button, DBGrid и StoredProg знаний dotNet не дотсточно.
Вообще зачем нужно учится в университете? Выучил дома dotNet по книге и вперёд устраиватся на работу
A>Серьезно. Я последний раз писал на ассемблере стековую оконную библиотеку в 80-х годах — 3 кб получилось. Эх, ностальгия... А кстати, где в работе с данными, вызове старого кода и тестировании процессора вызовы winapi?
Вы очень поверхностно смотрите в корень проблемы, видимо специфика работы такая. Какой смысл мне вам рассказывать, если вам это не пригодится? Знанияния ради знаний?
А почему я например не могу попытатся что-то портировать или написать новое? Если я с этим сталкивался, значит мне это было нужно, а в FW этого не было.
A>Ну это проблемы lin сообщества.
Ага , уже напопятную.
A> Мне больше нравится другое — что fw одинаково работает на различных ОС от MS. win32 этим похвастать не мог.
Really? Одинаково ограниченно вы хотели сказать . Внимание вопрос: Как вызвать из dotNet новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы? Или может прикладным программистам они не нужны?
A>Стоит ли знать API ради API?
API надо знать ради расширения возможностей.
А стоит ли замыкатся на ограниченные возможности dotNet?
Здравствуйте, Kisloid, Вы писали:
K>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло. Я стою перед выбором, изучить Си шарп или писать на MC++. А может вообще стоит не торопиться и писать unmanaged приложения, хочу кстати купить книжку Джеффри Рихтера "Windows для профессионалов, создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows".
Окончательной версии C++ тоже ещё не вышло. И никак не выходит каменный цветок уже двадцать лет.
Здравствуйте, Andrbig, Вы писали:
A>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
Ха, с железом там работают драйвера да прослойки типа OpenGL или директа. Работает же Quake2 .NET, притом почти со скоростью оригинала (где-то 80% от нее по утверждению "переводчиков").
А что до API — это и нормальный Overlapped I/O и scatter/gather, MMF, SSPI, и просто — unmanaged код с оптимизациями под конкретные процессоры и структуры данных.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Я много за что заплатил. В этом списке кстати ни одной dotNet программы.
Мне многое за что платили и в последнее время это только .NET программы.
МЮ>Я вообще не рекомендую замыкать свои знания только на том, что нужно заказчику. Заказчики приходят и уходят, а знания остаются.
Есть у меня стойкое ощущение, что у нас разные заказчики. И это многое объясняет, не правда ли?
МЮ>У приложений dotNet круг тоже ограничен. Весьма. Ваш тому пример.
Не уверен, что имею право представлять написанными мной программами круг приложений .NET.
МЮ>Звук, видео, САПР, игры — там dotNet не нужен, а разработчики, владеющие API — нужны.
Да, не нужен. А кто говорит, что .NET заменит собой все и везде? Системное программирование, драйвера, программы критичные к скорости — туда путь .NETу заказан. Он ориентирован на программы уровня предприятия, а не на ширпотреб. Собственно, ничего другого от MS ждать и не приходится. Они жуть как людят масштаб предприятия" во всем. Собственно они (и NET) ориентированы на крупных заказчиков, а не на массовку.
МЮ>Знания ради умений и опыта. Чтобы написать хорошую программу, которая не ограничевается Button, DBGrid и StoredProg знаний dotNet не дотсточно. МЮ>Вообще зачем нужно учится в университете? Выучил дома dotNet по книге и вперёд устраиватся на работу
Абсолютно согласен. Методологию программирования и опыт ничто не заменит. Конкретные знания по winapi, .NET, ассемблеру или чему угодно этого не заменят и не помогут. Освоение книжки по NET или api опыта не даст.
МЮ>Вы очень поверхностно смотрите в корень проблемы, видимо специфика работы такая. Какой смысл мне вам рассказывать, если вам это не пригодится? Знанияния ради знаний?
Вы на попятную? Пожалуйста, уж снизойдите, расскажите. Я попробую отойти от своей поверхностной специфики и посмотреть на вопрос по-другому. Может я пойму всю свою убогость и брошусь в winapi? Мне все же непонятно насчет этих 90%. Как используется winapi в тестировании процессоров, обработке данных и вызове старого кода?
МЮ>А почему я например не могу попытатся что-то портировать или написать новое? Если я с этим сталкивался, значит мне это было нужно, а в FW этого не было.
Да ради бога, пишите сколько влезет и портируйте что требуется! Кто сказал нельзя? Просто вы работаете не в той сфере, для которой этот NET предназначен.
МЮ>Ага , уже напопятную.
Почему? В настоящий момент fw под lin уже чем под win. Это означает, что программу, написанную под lin, можно запускать по win, а обратное неверно. Это я и называю "проблемы lin сообщества". И почему в реальном мире прога не сможет работать и под win, и под lin при наличии fw — непонятно. Или для работы обязательно нужно абсолютно полное соответствие fw?
МЮ>Really? Одинаково ограниченно вы хотели сказать .
Нет, дорогой, ваша версия ошибочна, я сказал то, что хотел сказать — работает одинаково. А насчет ограниченности вопрос: лучше, если под одной ОС функция работала одним образом, а под другой — другим (или вообще не работала)?
МЮ>Внимание вопрос: Как вызвать из dotNet новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы? Или может прикладным программистам они не нужны?
Если вопрос абстрактен, то собственно если прикладнику приспичило что-то из win32, то pinvoke — и вперед.
Если вопрос конкретный, то его надо уточнить. О каких функциях, интерфейсах и контролах идет речь?
МЮ>API надо знать ради расширения возможностей. МЮ>А стоит ли замыкатся на ограниченные возможности dotNet?
Знания — это здорово, расширение возможностей — замечательно, но кроме них есть еще опыт, умения и навыки. Можно знать до черта всего, но не обладать опытом по его использованию. А можно знать мало, но довести это до совершенства, а скорость и качество написанных программ — до максимума. Что лучше? Истина как обычно, где-то посередине...
Здравствуйте, Kisloid, Вы писали:
K>А почему поздно ? Ведь все только начинает развиваться, С шарп то вышел всего года два назад =)
Вообще-то я думал ты поймешь, что я прикалываюсь. Просто уж больно смешно твои вопрсы выглядят.
K>И почему поздно покупать "Windows для профессионалов" ? Вин АПИ скоро изменится ? А с чего вообще тогда начать ? До сих пор я использовал MFC =)
Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вообще-то я думал ты поймешь, что я прикалываюсь. Просто уж больно смешно твои вопрсы выглядят.
Я понял =)
VD>Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
>Мне многое за что платили и в последнее время это только .NET программы.
Это вовсе не значит, что WinAPI мёртв и другим его знать не надо.
>Есть у меня стойкое ощущение, что у нас разные заказчики. И это многое объясняет, не правда ли?
May be
>Да, не нужен. А кто говорит, что .NET заменит собой все и везде? .. Системное программирование, драйвера, программы критичные к скорости -...
И ещё много-много чего.
> Как используется winapi в тестировании процессоров, обработке данных и вызове старого кода?
А как вы сами думаете?
1. Не ужели я пишу ассемблерные вставки в программы на С++, чтобы затем интерфейс писать на фреймворке. Естественно, что с виндами я взаимодействую через API.
>Если вопрос абстрактен, то собственно если прикладнику приспичило что-то из win32, то pinvoke — и вперед.
Вот. Чистый пример необходимости использования WinAPI.
>Нет, дорогой, ваша версия ошибочна, я сказал то, что хотел сказать — работает одинаково. А насчет ограниченности вопрос: лучше, если под одной ОС функция работала одним образом, а под другой — другим (или вообще не работала)?
Да не фига они не одинаково работают, потому что FW обёртка над тем же вин API.
Хотите пример? Попробуйте в программе под Win98 задать координаты больше 2^16. (это мне нужно для отображения рулонных листов в специализированном САПР).
Ещё пример сходу, о котором точно знаю.
Form.TransparencyKey Property ,
...
Remarks
Windows 2000 Platform Note: Transparent windows and regions are only supported under the Windows 2000 operating system.
Ещё примеры искать будем, или вы признаете, что с одинаковостью погорячились .
> Знания — это здорово, расширение возможностей — замечательно, но кроме них есть еще опыт, умения и навыки.
Ну разумеется. Знания и опыт — две стороны одной медали. Но имея знания, по крайней мере , если понадобится, не растеряешься и будешь знать где что искать.
>А можно знать мало, но довести это до совершенства, а скорость и качество написанных программ — до максимума.
Ну это вопрос очень-очень спорный, так как возникают вопросы , а " мало можно знать", чтобы и скорость и качество программ до максимума. Но мне если честно лень спорить по этому вопросу.
> Истина как обычно, где-то посередине...
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, VladD2, Вы писали:
VD>>Вообще-то я думал ты поймешь, что я прикалываюсь. Просто уж больно смешно твои вопрсы выглядят.
K>Я понял =)
VD>>Вообще-то MFC-программиста без знаний того что написано в "Windows для профессионалов" программистом то назвать тяжело. Так любитель.
K>Это я тоже понимаю, ну все же, посоветуй VladD2, "Windows для профессионалов" + Страуструп или "Программирование платформы .NET" + книга по C#-у ?
не бывает "или". Не те времена, когда можно позволить себе "или". И то, и другое, однозначно.
K>А мое мнение такое, что те, кто грит что Win API мертва и что в будущем .NET ,будет напрямую с ядром взаимодействовать неправда =) Поэтому я больше склоняюсь к первому варианту. Хотя конечно надо знать .NET, но в первую очередь думаю стоит изучить win api.
Изучать winapi надо, если уровень задачи того требует. Ведь ты же не собираешься изучать или знать PDP11 (хоть знаешь вообще, что это? ) из-за того, что он положил основу чему-то?)
А если вам не нужна легкость программирования на C#, удобная работа с Web, ASP.NET и ADO.NET, опять же, зачем вам C#?
А еще лучше следовать следующему правилу:
знать надо все, а для задачи применять наиболее удобный/подходящий/адекватный вариант.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Это вовсе не значит, что WinAPI мёртв и другим его знать не надо.
Я уж устал говорить, что NET не охватывает все на свете. Но в той части, что он охватывает, api мертв. Вы сами как считаете, с файлами и базами удобнее работать через классы или через хэндлы?
МЮ>И ещё много-много чего.
Можно список? Что не заменит в прикладном программировании NET, кроме задач требовательных к скорости/памяти (паковщики, 3d buhs), плотно интегрированных с системой (антивирусы, расширители shell) и специализированных задач (САПРы)?
МЮ>1. Не ужели я пишу ассемблерные вставки в программы на С++, чтобы затем интерфейс писать на фреймворке. Естественно, что с виндами я взаимодействую через API.
А я-то думал... Понятно. Это следствие.
МЮ>Ещё примеры искать будем, или вы признаете, что с одинаковостью погорячились .
Погорячился. Но все равно хотелось бы увидеть еще примеров.
A>Я уж устал говорить, что NET не охватывает все на свете. Но в той части, что он охватывает, api мертв. Вы сами как считаете, с файлами и базами удобнее работать через классы или через хэндлы?
Через классы работать само собой удобней, но, тем не менее, полезно иногда знать, что такое хенда, как передать хендл из одного процесса в другой и т.д. и т.п. Это, вообще говоря, фундамент, на котором построен dotNet.
A>Можно список? Что не заменит в прикладном программировании NET, кроме задач требовательных к скорости/памяти (паковщики, 3d buhs), плотно интегрированных с системой (антивирусы, расширители shell) и специализированных задач (САПРы)?
Ну а чего со списком баловаться? Обработка видео, звука. Дотнету туба пока далеко. А что всё, что вы перечислили, это мало и хорошие программисты там не нужны?
МЮ>>1. Не ужели я пишу ассемблерные вставки в программы на С++, чтобы затем интерфейс писать на фреймворке. Естественно, что с виндами я взаимодействую через API. A>А я-то думал... Понятно. Это следствие.
Хм. Тем не менее нельзя сказать, что dotNet может здесь мне заменить API.
A>Погорячился. Но все равно хотелось бы увидеть еще примеров.
А чего за ними далёко бегать? Все ограничения Win98 против NT действуют на dotNet. Кстати программы, написанные на Делфи тоже во всех версиях Win работают "одинаково". Однако практически все, кого я знал, пользовались не только VCL но и API.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Через классы работать само собой удобней, но, тем не менее, полезно иногда знать, что такое хенда, как передать хендл из одного процесса в другой и т.д. и т.п. Это, вообще говоря, фундамент, на котором построен dotNet.
Это вообще говоря вопрос. ДА — в той части, где NET — обертка над api. НЕТ — где в NET наколбасили своего. Больше всего изменений в распределенных приложениях. То RPC, потом DCOM, сейчас Remoting, в будущем Web-Service. Для чего например знать эту возню с хендлами в Remoting? Там свои приколы, специфичные и знания api в этой части не момогут. Так что не все там фундамент.
МЮ>Ну а чего со списком баловаться? Обработка видео, звука. Дотнету туба пока далеко. А что всё, что вы перечислили, это мало и хорошие программисты там не нужны?
Хорошие программисты везде нужны.
МЮ>Хм. Тем не менее нельзя сказать, что dotNet может здесь мне заменить API.
NET заменяет там, где начинает играть вопрос удобства. Под NET удобней, там все в классах и namespace-ах.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Звук, видео,
Ну, тут МС и без нас справится. А АПИ для звука и видео пофигу будет откуда вызвать.
МЮ>САПР,
А что сапр? Такая же прикладнуха как и все остальное. На дотнете так же будет надежнее и проще чем на С++.
МЮ> игры — там dotNet не нужен,
От как раз там то они и нужен. Как минимум какой-нибудь Шарп или ВБ.Нет намного лучше доморощенных скриптов используемых в игрушках. ИЛ2 уже забросил пробный шар — использовал для этого Яву. Рано или поздно кто-то воспользуется дотнето для тех же целей. А потом подумает, а почему бы не писать на дотнете почти всю игру? Ну, вынести там самые низкоуровневые участки в анменеджед-код и все. И скажу по сикрету МС очень даже хочет пропихнуть дотнет в игры.
МЮ> а разработчики, владеющие API — нужны.
Да конечно нужны. Но уже меньше чем 5 лет назад. И с каждым годом будут нужны все меньше и меньше. А когда нибудь глядишь фрэймворк будет восприниматься как основное АПИ и тогда времена Вынь32 пройдут как страшный сон.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Хотите пример? Попробуйте в программе под Win98 задать координаты больше 2^16. (это мне нужно для отображения рулонных листов в специализированном САПР).
Дык в Лонгхорне как раз ГДИ то и станет не нужным. Там будет Авалон который перекроет возможности GDI/User32 и ВинФормс с большим запасам. А все координаты будут с плавающей точкой. Так что прачные прогнозы твоих аппонентов уже сбываются.
Правда можно будет использовать и GDI с User32. Но выгоды ты уже от этого не получишь. Только если с точки зрения совместимости со старыми ОС.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mab, Вы писали:
Mab>1) Нестандартные контролы. То, что предлагает WinForms, мягко говоря недостаточно. Тот же самый virtual list view пришлось руками делать.
Во втором фрэймворке обернут и виртуальный режим. К тому же нет проблем написать свой виртуальный грид. Тут АПИ только проиграет.
Mab>1') Доступ к GDI, которое практически в FW не представлено (разве что ControlPaint-ом). GDI+ не подходил из-за соображений скорости.
Опять же во втором фрэймворке обернуты основные функции и не можно легко обойтись без использования ГДИ напрмямую.
А если вспомнить о Лонгхорне, то становится понятным, что рано или поздно ГДИ и Юзер32 вымрут как динозавры.
Mab>2) Управление процессами (запуск с флагом DEBUG_PROCESS, отслеживание расходуемых ресурсов итп). Класс Process здесь малополезен.
Есть менеджед-дебаг-апи. Его более чем достаточно для этих целей. Просто это настолько экзотично, что моло кто о нем знает.
Mab>3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke.
Это зачем же нужны MMF если есть МС++?
Ну, и где ты видел обертки над MMF? Можно ссылочку?
Mab>Каждый может дополнить этот список в соответствии с собственным опытом
Да может конечно. Только тенденция то однозначаная. Все меньше и меньше мест где Вынь32АПИ нужно. Так что рано или поздно 99% приложений будут писаться на дотнете без ВыньАПИ.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrbig, Вы писали:
A>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
А ты тест того же Квака2 видел перекомпилированного под дотнет? Так вот он очень так хорошо показал, что для 3D-игр дотнет очень даже подходит.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrbig, Вы писали:
A>>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
VD>А ты тест того же Квака2 видел перекомпилированного под дотнет? Так вот он очень так хорошо показал, что для 3D-игр дотнет очень даже подходит.
Не совсем верное следствие. В том-то и дело, что он был перекомпилирован в managed code, а не портирован под .NET. Quake 2 .NET не использует .NET библиотеки (BCL, winforms, etc), не использует managed классы, не использует GC. Это скорее тест возможностей VC++ по компилированию C-кода в IL и тест для голого CLR.
Здравствуйте, alexkro, Вы писали:
A>Не совсем верное следствие. В том-то и дело, что он был перекомпилирован в managed code, а не портирован под .NET. Quake 2 .NET не использует .NET библиотеки (BCL, winforms, etc), не использует managed классы,
И что плохого могут сделать библиотеки фрэймворка?
A> не использует GC.
Слухи о тормозах ЖЦ сильно приувеличены. Не трудно провести эксперемент и убедиться, что система поколений и инкрементальная сборка мусора основанная на ней приводит к тому что процесс сборки мусора проходит очень быстро.
A> Это скорее тест возможностей VC++ по компилированию C-кода в IL и тест для голого CLR.
Весь код был полностью переведен во МСИЛ. Приложение исполнялось под управлением дотнета и компилировалось джитом. В приложениии было винформсовое окно и несколько дотнетных объектов. Что еще нужно?
Не нравится квака покляди примеры написанные на шарпе. Хочень из дайрект-икса, а хочишь найти поиском обсуждение на нашем сайте там была ссылка на движек игры специаьно адаптированный на работу с шарпом. Гдето даже были ссылки на отзывы разработчиков. Они примерно говорили следующее: "Проигрыш в скорости получаемый при использовании Шарпа и дотнета минимален и почти незаметен, при этом простота разработки резко повышается и компенсирует проблемы скорости".
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Во втором фрэймворке обернут и виртуальный режим. К тому же нет проблем написать свой виртуальный грид. Тут АПИ только проиграет.
Ну когда выйдет, тогда и посмотрим Писать-то сейчас приходится.
VD>Опять же во втором фрэймворке обернуты основные функции и не можно легко обойтись без использования ГДИ напрмямую.
Очень рад за них.
VD>Есть менеджед-дебаг-апи. Его более чем достаточно для этих целей. Просто это настолько экзотично, что моло кто о нем знает.
А вот об этом не знал. Можно ссылку?
Mab>>3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke. VD>Это зачем же нужны MMF если есть МС++?
Э... не понял противопоставления. MMF нужны потому, что исходных данных порядка гигабайта и нужен быстрый доступ и отрисовка.
VD>Ну, и где ты видел обертки над MMF? Можно ссылочку?
Они есть в Caching Application Block.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>Не совсем верное следствие. В том-то и дело, что он был перекомпилирован в managed code, а не портирован под .NET. Quake 2 .NET не использует .NET библиотеки (BCL, winforms, etc), не использует managed классы,
VD>И что плохого могут сделать библиотеки фрэймворка?
В том и дело, что этот тест ничего о них сказать не может.
A>> не использует GC.
VD>Слухи о тормозах ЖЦ сильно приувеличены. Не трудно провести эксперемент и убедиться, что система поколений и инкрементальная сборка мусора основанная на ней приводит к тому что процесс сборки мусора проходит очень быстро.
Я и не говорю, что GC медленный. Просто Quake2.NET его не использует.
A>> Это скорее тест возможностей VC++ по компилированию C-кода в IL и тест для голого CLR.
VD>Весь код был полностью переведен во МСИЛ. Приложение исполнялось под управлением дотнета и компилировалось джитом. В приложениии было винформсовое окно и несколько дотнетных объектов. Что еще нужно?
Несколько окошек и объектов — ничто по сравнению с исходным кодом Quake. Нужно: игра, полностью портированная под .NET, с исходными кодами только на C#. Что-то вроде порта Quake на Java.
VD>Не нравится квака покляди примеры написанные на шарпе.
Я не о том, что мне Quake нравится или нет. А о том, что на основании производительности Quake2 .NET нельзя делать выводы о применимости .NET для написания игр.
>Хочень из дайрект-икса, а хочишь найти поиском обсуждение на нашем сайте там была ссылка на движек игры специаьно адаптированный на работу с шарпом. Гдето даже были ссылки на отзывы разработчиков. Они примерно говорили следующее: "Проигрыш в скорости получаемый при использовании Шарпа и дотнета минимален и почти незаметен, при этом простота разработки резко повышается и компенсирует проблемы скорости".
Здравствуйте, VladD2, Вы писали:
VD>... А когда нибудь глядишь фрэймворк будет восприниматься как основное АПИ и тогда времена Вынь32 пройдут как страшный сон.
2006 год — когда это .NET хозяйство полностью укомплектуется, плюс еще 2 года на откладывание сроков и сервиспаки, обкатку, психологическую ломку итд. С 2008 по 2010 активное промышленное использование и забывание страшного сна Вынь32. Только после 2010 можно полностью забыть про Вынь32, сдать в музей.
Здравствуйте, warhast, Вы писали:
W>Здравствуйте, Andrbig, Вы писали:
A>>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест. W>Ха, с железом там работают драйвера да прослойки типа OpenGL или директа. Работает же Quake2 .NET, притом почти со скоростью оригинала (где-то 80% от нее по утверждению "переводчиков").
Так этот перевод сделала совершенно левая контора какая то Vertigo, только чтобы продемонстрировать длину своего девайса. По их словам они просто показали что могут отпортировать С код в С++ без багов и без большой потери производительности. (На MC++ в данном случае).
А если бы все изначально проектировалось в .NET стиле и писалось на С#, то скорее всего Quake , был бы пошустрее и покачественнее чем оригинал на С. (Имеется ввиду разработка за те же бюджет). Откуда бы взялось увеличение производительности?
За счет более правильной архитектуры, упрощения разработки можно было бы более сложные оптимизации провернуть. Сама по себе Quake довольно примитивная программа, не требующая высокой производительности, все 3D движок рисует, остальное довольно примитивные алгоритмы.
Здравствуйте, Kisloid, Вы писали:
K>Неужели будут переписывать весь Win API? Я думаю, что дот нет будет основываться на Вин АПИ еще долгое время =)
Ну максимум до 2010 года. А что вобще такое Win API?
— user32.dll (400килобайт),
— comctl32.dll (500K)
— gdi32.dll (200K)
— еще пару тройку.
Из-за этих козявок столько шума? Дык элементарно их переписать, сложнее программстов отучить их использовать. Сделают альтернативное API вместо них.
А если под Win API доразумеваются все файлы .dll из инсталяшки винды, тогда более тяжелый случай. Полностью винду может и не скоро перепишут.
Здравствуйте, Mab, Вы писали:
Mab>Ну когда выйдет, тогда и посмотрим Писать-то сейчас приходится.
Он уже доступен. Смотри сколько влезет.
Mab>А вот об этом не знал. Можно ссылку?
Сейчас нет доступа а Интернету (пишу в офлайне) попробуй поискать на МСДН и в гугле. Если неполучится, дерни меня еще раз.
VD>>Ну, и где ты видел обертки над MMF? Можно ссылочку? Mab>Они есть в Caching Application Block.
Т.е. левая внешняя реализация? Ну, а что мешает свою сделать?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Куда переходит менеджед код, если он полностью менеджед?
А ты думешь, что вся ОС тоже менеджед? Код приложения то менеджед, а вот ввод-вывод пока что весь состоит из вызовов анменеджед-АПИ. Так что менеджед-анменеджед переходов там хватает. И как раз Ку2.нэт доказывает, что они делаются в МС++ очень эффективно. Разница с нэйтив вариантом несколько процентов. И на глаз вообще не видна.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WinterMute, Вы писали:
WM>А вы код VirtualDub видели?
Нет.
WM> Там С++, и то редко встречается, портировать это на Dot.NET бессмысленно.
Возможно... если там один ассемблер. Однако уж больно убог гуи у VD. Думаю, что если бы его делали на дотнете, то он оказался бы по приветливее. Даже в самой оптимизированой программе объем кода требующего ручной оптимизации относительно не велик и его проще выделить в отдельный модуль, а остальное написать просто, быстро и удобно, т.е. на чем-то вроде дотнета.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Он уже доступен. Смотри сколько влезет.
Смотреть -- дело одно, использоваться -- другое. Хорошо, что все это хозяйство будет во FW меньше чем через год, но куда я его воткну _сейчас_, пока релиза нет?
VD>Сейчас нет доступа а Интернету (пишу в офлайне) попробуй поискать на МСДН и в гугле. Если неполучится, дерни меня еще раз.
ОК
VD>Т.е. левая внешняя реализация?
Про сей блок ничего сказать вообще не могу -- не использовал и пока не собираюсь. В целом MS App Blocks -- неплохие примеры для изучения, если концепция устраивает, то при необходимости доводятся до кондиции руками (ну или переписываются вообще с нуля).
Есть, впрочем, и совершенно бессмысленные монстры вроде UI Process.
VD>Ну, а что мешает свою сделать?
Да мне она нафиг не нужна -- у нас MMF-ом нативная часть проекта занимается. А в managed-коде торчат уже заведомо более высокоуровневые фукнции, чем ReadByte. И нет другого выхода, потому что иначе от расходов на маршаллинг все ляжет.
Я лишь ответил на вопрос о том, бывает такое в природе или нет (кстати, откуда такой вопрос вообще возник, я не понял ): VD>Ну, и где ты видел обертки над MMF? Можно ссылочку?
VD>Возможно... если там один ассемблер. Однако уж больно убог гуи у VD. Думаю, что если бы его делали на дотнете, то он оказался бы по приветливее. Даже в самой оптимизированой программе объем кода требующего ручной оптимизации относительно не велик и его проще выделить в отдельный модуль, а остальное написать просто, быстро и удобно, т.е. на чем-то вроде дотнета.
Если бы GUI был написан на MFC, или WTL, он тоже был бы приветливее.
Mab>>Да мне она нафиг не нужна... VD>То есть интерес чисто спортивный?
Да разговор про managed-оболочки для MMF вообще непонятно откуда взялся... вроде как я его не начинал
VD>А что, совсем от нэйтив-кода отказаться не получается?
Увы, оно и на нейтив не слишком торопится, так что на очередной итерации придется, видимо, часть переписать. В общих чертах задача -- визуализация топогеодезической информации. Объемы данных слишком велики, чтобы их через маршаллер гонять. Поэтому приходится API, торчащее из нативной части, делать достаточно высокоуровневым и органичивать поток информации через границу.
Здравствуйте, Mab, Вы писали:
Mab>Увы, оно и на нейтив не слишком торопится, так что на очередной итерации придется, видимо, часть переписать. В общих чертах задача -- визуализация топогеодезической информации. Объемы данных слишком велики, чтобы их через маршаллер гонять. Поэтому приходится API, торчащее из нативной части, делать достаточно высокоуровневым и органичивать поток информации через границу.
По-моему, пролема именно в переходах туда-сюда. Мой опыт показывает, что дотнет неплохо справляется с пермалываением бльших объемов данных. Ведь хотя он и не 100%-но оптимален, но позволяет резко поднять уровень абстракции, а это позволяет писать более чисто. В конце концов все равное все данные в память положить ельзя, так что нужно сосредоточиться на их олее эффективном отсечении и подгрузки по месту (как в 3D-играх). MMF далеко не так эффктивны как кажется. Может оказаться, что отсечение на более высоком уровен даст больший выигрыш.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло.
имхо уже позно года три назад надо было начинать изучать C#.
Здравствуйте, orangy, Вы писали:
O>Спорное утверждение. Написание нетривиального UI на дотнете — занятие не для слабонервных. Или для богатых
Вот это уж точно более чем спорное утверждение. По простоте, удобству и скорости с дотенетом может сорвевноваться, в этой области, только Дельфи. А МФЦ и темболее ВТЛ точно отдыхают.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Mab>>3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke.
Для справки: в принципе обернуть memory maped files и асинхронный ввод/вывод не представляет никаких проблем, в Java это сделано и, кстати, как обычно грамотно, переносимо, удобно.
Здравствуйте, VladD2, Вы писали:
O>>Спорное утверждение. Написание нетривиального UI на дотнете — занятие не для слабонервных. Или для богатых VD>Вот это уж точно более чем спорное утверждение. По простоте, удобству и скорости с дотенетом может сорвевноваться, в этой области, только Дельфи. А МФЦ и темболее ВТЛ точно отдыхают.
Простой гуй — да. А если надо нетривиальный, то начинаются такие припрыгивания и интероп, что проще было бы на WinAPI написать.
Здравствуйте, orangy, Вы писали:
O>Простой гуй — да. А если надо нетривиальный, то начинаются такие припрыгивания и интероп, что проще было бы на WinAPI написать.
Не проще. Хоум тому хороший пример.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
O>>Простой гуй — да. А если надо нетривиальный, то начинаются такие припрыгивания и интероп, что проще было бы на WinAPI написать. VD>Не проще. Хоум тому хороший пример.
Вы меня простите, что я священную корову трогаю, но в хоуме весьма простенький GUI
Здравствуйте, orangy, Вы писали:
O>Я смогу предложить его купить через пару месяцев
У вас там триал будет? Или все должны влюбиться заочно? Если будет, то и погляядим на эту круть. За ожно посмотрим на чем она сделана... может там и правда МФЦ или ВТЛ будут.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, orangy, Вы писали:
O>>Простой гуй — да. А если надо нетривиальный, то начинаются такие припрыгивания и интероп, что проще было бы на WinAPI написать.
VD>Не проще. Хоум тому хороший пример.
Здравствуйте, Lloyd, Вы писали:
VD>>Ну, простым его назвать тже нельзя. Окошек не море, но все они навороченны.
L>Если можно, ткни пожалуйста пальцем. А то чего-то никак не найти.
В ссвлку проекта что ли? В Хоуме к гуи относится все что не относится к БД, т.е. 90%.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>И видимо к особенно навороченным можно отнести окно выбрать дату.
Там несколько десятков окон. Мнокие из которых довольно сложны. Там же динамически загружаемый интерфейс и преобразование ОО-модели в ГУИ. Если тебе влом разбираться, то хотя бы воздержись от заявлений по поводу продукта о котором мало чего знашь.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
VD>>Там несколько десятков окон. Мнокие из которых довольно сложны. Там же динамически загружаемый интерфейс и преобразование ОО-модели в ГУИ. Если тебе влом разбираться, то хотя бы воздержись от заявлений по поводу продукта о котором мало чего знашь.
L>Так там все-таки окна сложные или они сложно сделаны? Это все-таки разные вещи, не находишь?
Ну, то есть вместо аргуметов пошла софистика? Прекрасно понимашь, что речь об объеме работы и сложности кода.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Какой смысл мне вам рассказывать, если вам это не пригодится? 
