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

IT>Больше всего в этой статье поражает непонимание автором одной простой вещи — для решения каждой конкретной задачи нужно выбирать наиболее подходящий инструмент. OS нужно писать на C++, а ещё лучше на C.
Зачем на С? При грамотном знании С++ можно писать не менее производительный код, чем на С с меньшими трудозатратами.

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

TK>Знания WinForms в SL/WPF особо не помогут

Тот кто пишет на WinForms уже как минимум должен знать часть фреймворка необходимую для написания логики приложения.

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

nme>А что там ещё нового если уже WinForms знаешь?
Не столько новое, сколько другой подход, начиная от свойств и лэйаута и заканчивая композицией контролов.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС> H>Статистики нет, есть реальность. За все время существования 64-битных ОС, количество 64-битного софта не позволяет говорить о какой либо значимости этих самых 64 бит

НС> Вынужден был при недавнем апгрейде поставить х64. И, что характерно, абсолютно весь софт, который мне нужен есть в х64 версии. Кроме студии, увы.

У меня апгрейд на 64-битную ОС случился летом 2009 года. До сих пор практически весь софт, что у меня установлен, 32-битный. То есть обычно есть выбор какой инсталлятор качать, но некоторое время повозившись и с 32 и с 64 битными версиями одного и то же софта можно легко прийти к выводу, что никаких бенефитов от 64 бит эндюзер не получает. Ну а если разработчик дает возможность использовать 32-битные версии при наличии 64-битных, значит не так уж и важны для него эти 64 бита, раз не дали отказаться от 32-битных версий. А вот чего мне не встречалось, так это 64-бит-only софта. То есть, сегодня, 64 бита ближе к маркетингу, чем к реальным потребностям

НС> H> То есть, есть конечно софт, но реально нуждающегося в 64-битах очень и очень мало.

НС> Реально, нереально, а доля установленных х64 ОС постоянно растет. Особенно на серверах, там 32 бита уже редкость.

Рост доли 64-битных ОС объясним, при нынешних то объемах памяти. Но это совсем не означает, что софту, в массе своей, нужны 64 бита. Наверняка и среди 32-битного софта, лишь малая часть собирается с указанием на использование 4Gb адресного пространства под 64-битными ОС.

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

S>Не столько новое, сколько другой подход, начиная от свойств и лэйаута и заканчивая композицией контролов.

Тут вопрос в том какая часть WPF будет использована в Jupiter. Я думаю общий подход, лэйауты и возможно основные контролы останутся теми же.

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

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

FR>>>Да ладно в C++ нормальных фреймфорках (например QT) оно примерно так же и выглядит.

J>>там есть GC?? Или на подсчете ссылок??

FR>Там нет GC и не обязательно подсчет ссылок, но все вменяемые C++ GUI библиотеки полностью
FR>автоматически управляют памятью.

J>>если второе — то не катит. Совсем.

FR>Почему?

потому что циклические ссылки придется руками разруливать.

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

H>А вот чего мне не встречалось, так это 64-бит-only софта.

Последний SQL Server и SharePoint

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

FR>>Почему?

J>потому что циклические ссылки придется руками разруливать.

Не обязательно, например в питоне GC основано на подсчете ссылок + модуль автоматически разруливающий
циклические ссылки.

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

nme>Тут вопрос в том какая часть WPF будет использована в Jupiter. Я думаю общий подход, лэйауты и возможно основные контролы останутся теми же.
Не останется. В unmanaged очень тяжело реализовать большую часть концепций wpf. Как минимум с ресурсами и биндингами будет очень много интересных вопросов.

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

S>Как минимум с ресурсами и биндингами будет очень много интересных вопросов.

Есть конкретные примеры когда возникают проблемы?

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

FR>>>Почему?
J>>потому что циклические ссылки придется руками разруливать.
FR>Не обязательно, например в питоне GC основано на подсчете ссылок + модуль автоматически разруливающий
FR>циклические ссылки.
Так мы про GC или про подсчет ссылок? Про Python или про C++?

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

nme>Есть конкретные примеры когда возникают проблемы?
Для начала — как мы будем их освобождать? Особенно если ресурс помечен x:Shared="false", или на source биндинга никто больше не ссылается, или у нас несколько биндингов по сложному пути (object[0].SomeProp/Prop2).

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

FR>>Не обязательно, например в питоне GC основано на подсчете ссылок + модуль автоматически разруливающий
FR>>циклические ссылки.
MM>Так мы про GC или про подсчет ссылок? Про Python или про C++?

Эта техника не явлется питон специфичной и вполне реализуема и на C++.
Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++.

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

FR>Эта техника не явлется питон специфичной и вполне реализуема и на C++.
FR>Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++.
Ну, вот когда реализуешь, тогда и поговорим

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

FR>>Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++.
MM>Ну, вот когда реализуешь, тогда и поговорим

Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.

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

FR>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?

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

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

FR>>>Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++.
MM>>Ну, вот когда реализуешь, тогда и поговорим

FR>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.

Например в Qt да?

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

FR>>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
MM>Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?

Новый родитель.

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

L> H>А вот чего мне не встречалось, так это 64-бит-only софта.

L> Последний SQL Server и SharePoint

А что нибудь из недевелоперского?

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

FR>>>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
MM>>Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
FR>Новый родитель.
Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется? Или упомянутый уже Data Binding. Допустим у меня есть объект, который я задал как источник данных в неизвестном числе контролов. Теперь все эти контролы удаляются из дерева. Должен ли их источник данных быть уничтожен? А если на него сослался какой-то другой объект вне дерева? Как GUI об этом узнает?