Засел я тут на выходных попробовать в кутэ попрограммить...
Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
[RSDN@Home][1.2.0][alpha][634]
[Дайте мне хорошую политику, и я вам дам хорошие финансы. [А. Тюрго]]
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
отличная библиотека, мне тоже нравится. есть еще биндинг Qt# для .Net. Правда, сейчас этот проект заморозили
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Мне на выходных из деревни прислали свежую ливерную колбасу. Сварил. Попробовал. Ммм.. объеденье!
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Здравствуйте, Sheridan, Вы писали:
S>Qt это не только формы. Но конечно в дотнете функционала больше
главное в .Net — это не только (и не столько) библиотеки классов. Главное — это инфраструктура для интеграции языков.
Так что обсуждение получается из разряда "кит vs слон"
Здравствуйте, Дарней, Вы писали:
Д>главное в .Net — это не только (и не столько) библиотеки классов. Главное — это инфраструктура для интеграции языков. Д>Так что обсуждение получается из разряда "кит vs слон"
Зачем столько языков? Достаточно 2... бэйсик(онже C#) для офисных поделок и с++ для чегото более трудоемкого.
Qt вообще обходится одним с++... Причем можно сказать расширяет его...
[RSDN@Home][1.2.0][alpha][634]
[Верный тон не может быть слабым. [Б. Шоу]]
1. Дорогая (в смысле дорого стоит).
2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю).
3. Использования Qt-расширений С++ накладывает ограничение на исходный код, например, нельзя использовать шаблоны <sic!> (верно для 3.x, для 4-ой, кажется, тоже), проблемы с библиотекой boost::signals.
4. Мне не очень понравился предлагаемый Qt механизм создания пользовательского интерфейса.
ИМХО, Qt неплохой выбор при разработки приложения (с богатым GUI), целевыми платформами для которого будут Win & Linux. А вот над целесообразностью разработки единого пользовательского интерфейса под Mac и под Win нужно десять раз подумать. (Всё таки маковский гуй существенно отличается от виндового.)
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Здравствуйте, Kubera, Вы писали:
K>ИМХО, Qt неплохой выбор при разработки приложения (с богатым GUI), целевыми платформами для которого будут Win & Linux. А вот над целесообразностью разработки единого пользовательского интерфейса под Mac и под Win нужно десять раз подумать. (Всё таки маковский гуй существенно отличается от виндового.)
интересно, а какие есть еще альтернативы? Gtk мне не очень понравился — под виндой злостно тормозит.
Здравствуйте, Sheridan, Вы писали:
S>Зачем столько языков? Достаточно 2... бэйсик(онже C#) для офисных поделок и с++ для чегото более трудоемкого.
если для тебя С++ — это верх технологической мысли, так пиши себе на нем и радуйся жизни. Зачем обливать грязью всех, кто не разделяет твоей точки зрения?
Кстати, как там RSDN@Linux поживает?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Sheridan, Вы писали:
S>>Зачем столько языков? Достаточно 2... бэйсик(онже C#) для офисных поделок и с++ для чегото более трудоемкого.
Д>если для тебя С++ — это верх технологической мысли, так пиши себе на нем и радуйся жизни. Зачем обливать грязью всех, кто не разделяет твоей точки зрения?
Кто обливал? Если кого обидел или задел — звиняйте, но от своего мнения не откажусь и буду его всячески развивать...
Д>Кстати, как там RSDN@Linux поживает?
Дык вот начал кутэ учить, останавливает только отсутствие инета дома... Хотя вот проапгредюсь, старый комп сервачком поставлю чтоб реальная сеть была и начну пробовать. Вот только синхронизация...
[RSDN@Home][1.2.0][alpha][634]
[Hе всякому человеку даже гусарский мундир к лицу. [К. Прутков]]
Здравствуйте, Kubera, Вы писали:
K>Здравствуйте, Sheridan, Вы писали:
K>Минусы Qt:
K>1. Дорогая (в смысле дорого стоит).
Opensource.
K>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю).
Это какой стиль выберите...
K>3. Использования Qt-расширений С++ накладывает ограничение на исходный код, например, нельзя использовать шаблоны <sic!> (верно для 3.x, для 4-ой, кажется, тоже), проблемы с библиотекой boost::signals.
Я покачто обхожусь возможностями самой Qt. Если незабуду — потестю шаблоны в 4ке, хотя могу сказать что там присутствуют шаблонные классы...
K>4. Мне не очень понравился предлагаемый Qt механизм создания пользовательского интерфейса.
А мне оооочень понравилось! Руками интерфейс в кутэ оказалось очень удобно собирать. Layouts рулят.
K>ИМХО, Qt неплохой выбор при разработки приложения (с богатым GUI), целевыми платформами для которого будут Win & Linux. А вот над целесообразностью разработки единого пользовательского интерфейса под Mac и под Win нужно десять раз подумать. (Всё таки маковский гуй существенно отличается от виндового.)
Маки я даже невидел ниразу
[RSDN@Home][1.2.0][alpha][634]
[Глупец ищет счастья вдали; мудрый растит его рядом с собой. [Д. Оппенхейм]]
Здравствуйте, anton_t, Вы писали:
_>Здравствуйте, Sheridan, Вы писали:
S>>Дык сразуже видно! Вы не заметили? S>>Следить за памятью ненадо, нормальные бинарники не собирает...
_>Всё ясно, Java — это бейсик .
Может быть. Не видел. С другой стороны всем бы такую кроссплатформенность как у явы, а дотнет увы и ах тока на пальмах и на ПЦ (хотя и там и там винда)
_>А кстати, что такое "нормальный бинарник"?
Это тот который не компилируется при/перед выполнением.
[RSDN@Home][1.2.0][alpha][634]
[Hе будь у меня чувства юмора, я давно бы покончил с собой. [М. Ганди]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, anton_t, Вы писали:
_>>Здравствуйте, Sheridan, Вы писали:
S>>>Дык сразуже видно! Вы не заметили? S>>>Следить за памятью ненадо, нормальные бинарники не собирает...
_>>Всё ясно, Java — это бейсик . S>Может быть. Не видел. С другой стороны всем бы такую кроссплатформенность как у явы, а дотнет увы и ах тока на пальмах и на ПЦ (хотя и там и там винда)
_>>А кстати, что такое "нормальный бинарник"? S>Это тот который не компилируется при/перед выполнением.
Ну то есть получаем, что Java — это бейсик который "написано один раз, работает везде"
Здравствуйте, Sheridan, Вы писали:
S>Кто обливал? Если кого обидел или задел — звиняйте, но от своего мнения не откажусь и буду его всячески развивать...
а в чем вообще заключается твое мнение? все идиоты, один ты д'Артаньян?
S>Дык вот начал кутэ учить, останавливает только отсутствие инета дома... Хотя вот проапгредюсь, старый комп сервачком поставлю чтоб реальная сеть была и начну пробовать. Вот только синхронизация...
а чего там "учить"? библиотеку классов на память заучивать, что ли?
достаточно разобраться с основными концепциями наподобие signal-slot, moc и так далее — и в бой. Для толкового программиста дня два-три максимум.
Здравствуйте, anton_t, Вы писали:
_>Ну то есть получаем, что Java — это бейсик который "написано один раз, работает везде"
Я считаю что это былобы хорошо, хотя понимаю что так не всегда...
[RSDN@Home][1.2.0][alpha][634]
[В мыслях своих замесив попреками льстивые речи... [Тимон об Аркесилае]]
Здравствуйте, Дарней, Вы писали:
S>>Кто обливал? Если кого обидел или задел — звиняйте, но от своего мнения не откажусь и буду его всячески развивать... Д>а в чем вообще заключается твое мнение? все идиоты, один ты д'Артаньян?
стопстоп стоп. Остановимся.
Д>а чего там "учить"? библиотеку классов на память заучивать, что ли? Д>достаточно разобраться с основными концепциями наподобие signal-slot, moc и так далее — и в бой. Для толкового программиста дня два-три максимум.
Руку набить... Концепцию понять.... Я для набивания руки завел проект катологизатора CD...
[RSDN@Home][1.2.0][alpha][634]
[Кто способен все претерпеть, тому дано на все дерзнуть. [Л. Вовенарг]]
Здравствуйте, Cyberax, Вы писали:
C>Sheridan wrote: >> K>1. Дорогая (в смысле дорого стоит). >> Opensource. C>Лицензия слишком жесткая для библиотеки.
Зато бери и используй. А если нравится то покупай. При чем заметь — купить можно уже перед самым запуском готового софта в продажу
[RSDN@Home][1.2.0][alpha][634]
[Мысль должна быть направлена на необъятное. [М. Фичино]]
Здравствуйте, Sheridan, Вы писали:
K>>1. Дорогая (в смысле дорого стоит). S>Opensource.
В OpenSource нет поддержки MSVC и интеграции со студией.
K>>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю). S>Это какой стиль выберите...
Может и не аляповато, но тормознуто точно. Эти умельцы все контролы сами перерисовывают. Даже для родного для данной операционки стиля.
K>>4. Мне не очень понравился предлагаемый Qt механизм создания пользовательского интерфейса. S>А мне оооочень понравилось! Руками интерфейс в кутэ оказалось очень удобно собирать. Layouts рулят.
О! А как вам понравились эти "пружинки" (Spacers)? Только за это кютишникам надо руки поотрывать. Давно существует нормальное решение проблемы ресайза окна — Anchors. Нет, им понадобилось свое, самобытное.
Sheridan wrote: >> > K>1. Дорогая (в смысле дорого стоит). >> > Opensource. > C>Лицензия слишком жесткая для библиотеки. > Зато бери и используй. А если нравится то покупай. При чем заметь — > купить можно уже перед самым запуском готового софта в продажу
Дорого, очень дорого. Причем по их лицензии QT надо покупать еще ДО
начала разработки. Это никто проверять не будет, но для заказчиков часто
важна полная лицензионная чистота. А уговорить заказчиков купить такую
дорогую либу заранее достаточно сложно.
Здравствуйте, Sheridan, Вы писали:
_>>А кстати, что такое "нормальный бинарник"? S>Это тот который не компилируется при/перед выполнением.
А как же настройка адресов (relocation) ? Таковая может иметь место в "нормальном" бинарнике. И я могу её считать компиляцией перед выполнением
Т.е. самые нормальные бинарники это COM файлы.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, Sheridan, Вы писали:
K>>>1. Дорогая (в смысле дорого стоит). S>>Opensource. K_O>В OpenSource нет поддержки MSVC и интеграции со студией.
K>>>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю). S>>Это какой стиль выберите... K_O>Может и не аляповато, но тормознуто точно. Эти умельцы все контролы сами перерисовывают. Даже для родного для данной операционки стиля.
Откуда такая инфа, кстати часто такое слышу в форумах, кто то один сказал , а все остальные сразу же поумнели, читай стали профессионалами по QT. Это не трудно опровергнуть, например сделай прогу на QT в стиле Mac OS и запусти ее на винде, нарисуется она в стиле MAC OS? Идем дальше, могу точно сказать что для рисования конторол в стиле WinXP данная библиотека использует uxtheme.dll, а это стандартный рендерер в винде, получается что он тормозной?
Здравствуйте, Denwer, Вы писали:
K>>>>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю). S>>>Это какой стиль выберите... K_O>>Может и не аляповато, но тормознуто точно. Эти умельцы все контролы сами перерисовывают. Даже для родного для данной операционки стиля.
D>Откуда такая инфа, кстати часто такое слышу в форумах, кто то один сказал , а все остальные сразу же поумнели, читай стали профессионалами по QT. Это не трудно опровергнуть, например сделай прогу на QT в стиле Mac OS и запусти ее на винде, нарисуется она в стиле MAC OS? Идем дальше, могу точно сказать что для рисования конторол в стиле WinXP данная библиотека использует uxtheme.dll, а это стандартный рендерер в винде, получается что он тормозной?
Из опыта. А еще из изучения исходников. До выхода версии 4.1.0 была у них забавная ошибка: tab control в том случае, когда его закладки должны быть ниже основного документа, а стиль — WinXP, отображались неверно. При наведении мыши желтая полоска появлялась по верхней границе закладки, а не по нижней. Теперь это уже исправлено. То есть они сами рисуют свои контролы так, чтобы они выглядели как в WinXP. И, кстати, понять их можно: при самостоятельной перерисовке на всех платформах контролы будут отображаться одинаково. Одинаково медленно.
Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна.
Теперь. Я точно не знаю, для чего в винде используется uxtheme.dll (судя по таблице экспортируемых функций это все-таки менеджер тем, но ни в коем случае не рендерер контролов — контролы рисуются при помощи Gdi32.dll и User32.dll), но вот QtGui.dll точно не имеет явной зависимости от этой библиотеки. Есть неявная зависимость через ComDlg32.dll. То есть, у ребят все-таки хватило ума стандартные диалоги самим не переделывать.
Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна.
Жаль на шоте не видно что окошко дергают...
K_O>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет.
Гм... Мне всегда было на самом деле интересно — чем отличается "уровень ядра" от остальных в плане производительности?
[RSDN@Home][1.2.0][alpha][634]
[Всякий слышит лишь то, что понимает. [Плавт]]
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, Denwer, Вы писали:
K>>>>>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю). S>>>>Это какой стиль выберите... K_O>>>Может и не аляповато, но тормознуто точно. Эти умельцы все контролы сами перерисовывают. Даже для родного для данной операционки стиля.
D>>Откуда такая инфа, кстати часто такое слышу в форумах, кто то один сказал , а все остальные сразу же поумнели, читай стали профессионалами по QT. Это не трудно опровергнуть, например сделай прогу на QT в стиле Mac OS и запусти ее на винде, нарисуется она в стиле MAC OS? Идем дальше, могу точно сказать что для рисования конторол в стиле WinXP данная библиотека использует uxtheme.dll, а это стандартный рендерер в винде, получается что он тормозной?
K_O>Из опыта. А еще из изучения исходников. До выхода версии 4.1.0 была у них забавная ошибка: tab control в том случае, когда его закладки должны быть ниже основного документа, а стиль — WinXP, отображались неверно. При наведении мыши желтая полоска появлялась по верхней границе закладки, а не по нижней. Теперь это уже исправлено. То есть они сами рисуют свои контролы так, чтобы они выглядели как в WinXP. И, кстати, понять их можно: при самостоятельной перерисовке на всех платформах контролы будут отображаться одинаково. Одинаково медленно.
Ну я же предложил тебе сделать программу на QT которая будет рисоваться на Mac OS в стиле Win XP. Или наоборот на винде но в стиле MAC OS.
У них есть два типа стилей, это платфомро зависемый и независеймы. ВОт независеймый стиль они действительно рисую сами. Но ты можешь его не использовать. Вот цитата их их доки
The QWindowsXPStyle class provides a Microsoft WindowsXP-like look and feel.
Warning: This style is only available on the Windows XP platform because it makes use of Windows XP's style engine.
Вот та DLL о которой я говорил как раз и есть style engine.
K_O>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна.
Это ничего не доказывает. Просто более медленная работа. Напрмер если я в MFC программе при отрисовке сделаю цикл с 1000000 итерациями она тоже будет тормозозить, выходит MFC сама рисует контролы.
K_O>Теперь. Я точно не знаю, для чего в винде используется uxtheme.dll (судя по таблице экспортируемых функций это все-таки менеджер тем, но ни в коем случае не рендерер контролов — контролы рисуются при помощи Gdi32.dll и User32.dll), но вот QtGui.dll точно не имеет явной зависимости от этой библиотеки. Есть неявная зависимость через ComDlg32.dll. То есть, у ребят все-таки хватило ума стандартные диалоги самим не переделывать.
ComCtrl32 тоже использует кстати.
K_O>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет.
Винда все рисует на уровне ядра!!! Даже если ты сделаешь MoveTo(...) LineTo(...) — это рисуется в режиме ядра.
Denwer wrote: > Откуда такая инфа, кстати часто такое слышу в форумах, кто то один > сказал , а все остальные сразу же поумнели, читай стали профессионалами > по QT. Это не трудно опровергнуть, например сделай прогу на QT в стиле > Mac OS и запусти ее на винде, нарисуется она в стиле MAC OS? Идем > дальше, могу точно сказать что для рисования конторол в стиле WinXP > данная библиотека использует uxtheme.dll, а это стандартный рендерер в > винде, получается что он *тормозной*?
Библиотека uxtheme используется для получения информации об элементах
тем (битмапы, цвета и т.п.). Виджеты они рисуют сами (хотя достаточно
качественно), можете посмотреть в сырцы.
Здравствуйте, Cyberax, Вы писали:
C>Denwer wrote: >> Откуда такая инфа, кстати часто такое слышу в форумах, кто то один >> сказал , а все остальные сразу же поумнели, читай стали профессионалами >> по QT. Это не трудно опровергнуть, например сделай прогу на QT в стиле >> Mac OS и запусти ее на винде, нарисуется она в стиле MAC OS? Идем >> дальше, могу точно сказать что для рисования конторол в стиле WinXP >> данная библиотека использует uxtheme.dll, а это стандартный рендерер в >> винде, получается что он *тормозной*? C>Библиотека uxtheme используется для получения информации об элементах C>тем (битмапы, цвета и т.п.). Виджеты они рисуют сами (хотя достаточно C>качественно), можете посмотреть в сырцы.
Я и не говорил что они используют для рисования виджетов только возможности виндовса. Но часть их используется.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна. S> S> <Здесь был Screenshot> S> Жаль на шоте не видно что окошко дергают...
100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.
K_O>>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет. S>Гм... Мне всегда было на самом деле интересно — чем отличается "уровень ядра" от остальных в плане производительности?
Само по себе, где именно рисовать не так уж и важно, алгоритм рисования должен быть примерно одинаков по производительности. Но, видишь ли, графические примитимы в конце концов рисует драйвер видеокарты, а драйвер работает в винде всегда в режиме ядра. А вот что уже играет огромную роль — так это количество переключений из Kernel Mode в User Mode и обратно. На Интеловской архитектуре такое переключение — очень затратная операция. Поэтому чем меньше таких переключений, тем лучше. Если графика реализована в User Mode, значит переключаться придется для рисования каждого примитива. А если графика реализована в Kernel Mode — это значит, что переключаться придется намного реже, в начале отрисовки сложного контрола и при возврате из функции рисования.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, Sheridan, Вы писали:
S>>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна. S>> S>> <Здесь был Screenshot> S>> Жаль на шоте не видно что окошко дергают...
K_O>100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.
K_O>>>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет. S>>Гм... Мне всегда было на самом деле интересно — чем отличается "уровень ядра" от остальных в плане производительности?
K_O>Само по себе, где именно рисовать не так уж и важно, алгоритм рисования должен быть примерно одинаков по производительности. Но, видишь ли, графические примитимы в конце концов рисует драйвер видеокарты, а драйвер работает в винде всегда в режиме ядра. А вот что уже играет огромную роль — так это количество переключений из Kernel Mode в User Mode и обратно. На Интеловской архитектуре такое переключение — очень затратная операция. Поэтому чем меньше таких переключений, тем лучше. Если графика реализована в User Mode, значит переключаться придется для рисования каждого примитива. А если графика реализована в Kernel Mode — это значит, что переключаться придется намного реже, в начале отрисовки сложного контрола и при возврате из функции рисования.
Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.
Здравствуйте, Denwer, Вы писали:
D>Ну я же предложил тебе сделать программу на QT которая будет рисоваться на Mac OS в стиле Win XP. Или наоборот на винде но в стиле MAC OS. D>У них есть два типа стилей, это платфомро зависемый и независеймы. ВОт независеймый стиль они действительно рисую сами. Но ты можешь его не использовать. Вот цитата их их доки
D>
D>The QWindowsXPStyle class provides a Microsoft WindowsXP-like look and feel.
D>Warning: This style is only available on the Windows XP platform because it makes use of Windows XP's style engine.
D>Вот та DLL о которой я говорил как раз и есть style engine.
То, что на винде нет стиля Mac OS еще не говорит об использовании родных библиотек для рисования виджетов. Это говорит о том, что ребята сделать качественную поддержку стиля на другой платформе не смогли. Или это, в принципе, невозможно. Еще раз, посмотри исходники.
K_O>>Идем дальше. Создаем простую форму, запускаем и пробуем, взявшись за правый нижний угол, ее часто-часто ресайзить. Загрузка процессора — 100%, задержки при перерисовке видны невооруженным взглядом. Для сравнения можно тоже самое проделать с главным окном навороченного Visual Studio. Разница очень заметна. D>Это ничего не доказывает. Просто более медленная работа. Напрмер если я в MFC программе при отрисовке сделаю цикл с 1000000 итерациями она тоже будет тормозозить, выходит MFC сама рисует контролы.
Разница лишь в том, что Qt-шная форма будет тормозить и в том случае, если я специально ничего затормаживать не буду.
K_O>>Последнее. Тормознутость Qt-шных гуев обусловлена тем, что в винде отрисовка контролов происходит все-таки на уровне ядра. А у Qt — нет. D>Винда все рисует на уровне ядра!!! Даже если ты сделаешь MoveTo(...) LineTo(...) — это рисуется в режиме ядра.
Не надо так нервничать, тебя все прекрасно слышат. Важен не факт нахождения в режиме ядра, а количество переключений. См. мой соседний ответ.
Здравствуйте, Denwer, Вы писали:
D>Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.
В моем эксперименте были получены другие данные — 70% времени кушал процесс с неподвижной формой, 30% — перетаскиваемый калькулятор.
Но дело не в этом. Когда я хочу создать качественное приложение с ГУИ мне не особо важно, какая именно часть Qt виновна в тормозах. Ясное дело, что тут и рисование и рассылка событий и много прочей ерунды. Речь ведь изначально шла о Qt в целом. Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, Denwer, Вы писали:
D>>Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.
K_O>В моем эксперименте были получены другие данные — 70% времени кушал процесс с неподвижной формой, 30% — перетаскиваемый калькулятор. K_O>Но дело не в этом. Когда я хочу создать качественное приложение с ГУИ мне не особо важно, какая именно часть Qt виновна в тормозах. Ясное дело, что тут и рисование и рассылка событий и много прочей ерунды. Речь ведь изначально шла о Qt в целом. Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.
А никто и не спорит что QT замедляет работу, но тогда уж выбирай либо ты рисуешь каждую форму на АПИ по 10 дней, либо рисуешь за 1 час но скорость работы гуя медленнее. Кстати я вот не слышал что бы кто то жаловался на скорость работы оперы(хотя я им не пользуюсь).
D>Кстати я вот не слышал что бы кто то жаловался на скорость работы оперы(хотя я им не пользуюсь).
А ты уверен, что Опера/Win использет Qt ?
Тогда скажи, легко ли из qt/Win вызовы drag-n-drop как-то вынести наружу ?
За всю долгую жизнь не хватает мне в Opera/win переноса. Прям думается не попробовтаь ли написать переходник между X DnD и MS COM DnD
PS: Есть какие-то притормознутые места в ресайзах, на вскидку не помню. Что-то было.
Здравствуйте, Arioch2, Вы писали:
A>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах A>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites
Верно понимаеш... Есть Qt — зачем дотнет?
[RSDN@Home][1.2.0][alpha][634]
[Вдвойне дает тот, кто дает быстро. [Сенека Старший]]
A>>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах A>>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites
S>Верно понимаеш... Есть Qt — зачем дотнет?
Дааа... а мне говорили, что OpenSource — это Bazaar. А тут такой Catherdral с инквизиторскими кострами....
А Beagle-то не знает
Здравствуйте, Arioch2, Вы писали:
A>>>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах A>>>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites
S>>Верно понимаеш... Есть Qt — зачем дотнет?
A>Дааа... а мне говорили, что OpenSource — это Bazaar. А тут такой Catherdral с инквизиторскими кострами.... A>А Beagle-то не знает
Лучшее оно всегда враг хорошего...
Честно скажу — под виндами на шарпЕ программлю ибо нет инпрайзовской тормознутости билдера. В линухах жеж Qt самое то — и надеюсь со временем перейду в Qt и под виндами...
И вот что я вам скажу... Простота и функционал кутэ находится между mfc и winforms, но кутэ обходит их вместе взятых по кроссплатформенности
[RSDN@Home][1.2.0][alpha][634]
[В России надо жить долго, тогда что-нибудь получится. [К. И. Чуковский]]
Здравствуйте, Kh_Oleg, Вы писали:
K_O>100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.
Спокойно себе ресайзил, не мельтешил... Прорисовка страдает...
[RSDN@Home][1.2.0][alpha][634]
[Беда тому, кто умен, но не наделен при этом сильным характером. [H. Шамфор]]
Здравствуйте, Kh_Oleg, Вы писали:
> Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms.
Тормознее, чем .NET WinForms ???
Сравнение RSDN@Home и Opera 8.5 явно не в пользу RSDN@Home. Все еще усугубляется тем, что Опера и HTML перерисовывает — и тормозов все равно намного меньше.
Здравствуйте, Сергей, Вы писали:
>> Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms. С>Тормознее, чем .NET WinForms ??? С>Сравнение RSDN@Home и Opera 8.5 явно не в пользу RSDN@Home. Все еще усугубляется тем, что Опера и HTML перерисовывает — и тормозов все равно намного меньше.
Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, Kh_Oleg, Вы писали:
>> Ну так вот, в целом ГУИ, сделанный на Qt, намного более тормозной, чем родной Win32 или .net WinForms. С>Тормознее, чем .NET WinForms ??? С>Сравнение RSDN@Home и Opera 8.5 явно не в пользу RSDN@Home. Все еще усугубляется тем, что Опера и HTML перерисовывает — и тормозов все равно намного меньше.
Не надо сравнивать слона с носорогом. Сравнивайте равноценные приложения. Взять хотя бы стандартный Блокнот, его аналог на Qt и его аналог на WinForms. А уже потом RSDN@Home и его же, на Qt...
[..]
SJA>Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....
[...]
K_O>Не надо сравнивать слона с носорогом. Сравнивайте равноценные приложения. Взять хотя бы стандартный Блокнот, его аналог на Qt и его аналог на WinForms. А уже потом RSDN@Home и его же, на Qt...
Сдается мне, Опера будет покруче и понавороченней, чем RSDN@Home в плане интерфейса. И переформатирование HTML страницы (RSDN.RU) при ресайзе — это тоже непростая операция. И при этом не шибко навроченное WinForms окошко тормозит сильнее.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....
Чтото я не видел в коде чтобы он по ресайзу в базу лез...
[RSDN@Home][1.2.0][alpha][634]
[Мое время и я — не соответствуют друг другу; это ясно. [А. Шопенгауэр]]
С>Сдается мне, Опера будет покруче и понавороченней,
Спошу еще раз, здесь все уверены, что Opera/Win32 использует Qt ?
Учитывая, что opera/Win была всегда, а проект Opera/Magic появился в районе Opera 5.
И что, они сменили весь к тому времени наработанный GUI ?
Здравствуйте, Сергей, Вы писали:
SJA>>Не забываем, что RSDN@Home ворочает нехилый mdb файлик. Лично у меня RSDN@Home + Access тормозил ужасно. А сменил базу на MS SQL Server — летает....
С>А на тормоза при ресайзе это как влияет?
А..., я думал, что речь вообще об интерфейсе, а не о ресайзе. На ресайз не обращал внимание...
Здравствуйте, Arioch2, Вы писали:
С>>Сдается мне, Опера будет покруче и понавороченней,
A>Спошу еще раз, здесь все уверены, что Opera/Win32 использует Qt ? A>Учитывая, что opera/Win была всегда, а проект Opera/Magic появился в районе Opera 5. A>И что, они сменили весь к тому времени наработанный GUI ?
Ну например при закачки оперы на Unix, т.е.
Opera 8.51 for FreeBSD i386 там можно даже выбрать
Static QT 5.9 MB
Shared QT 4.0 MB
Я не уверен что у них под разную платформу используется разный фреймворк.
ЗЫ: Насколько я помню они не с самого начала использовали QT, но могу и ошибаться
A>>Спpошу еще раз, здесь все уверены, что Opera/Win32 использует Qt ? A>>Учитывая, что opera/Win была всегда, а проект Opera/Magic появился в районе Opera 5. A>>И что, они сменили весь к тому времени наработанный GUI ?
D>Ну например при закачки оперы на Unix, т.е.
Да знаю я. Я же не просто так пишу про винды! Именно про Opera/Win32
D>ЗЫ: Насколько я помню они не с самого начала использовали QT, но могу и ошибаться
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Дарней, Вы писали:
Д>>ты хотя бы "Искусство программирования для Unix" читал?
S>Еще не купил в бумаге а с монитора читать длинное не перевариваю
ну тогда поищи. там Рэймонд как раз на тему языков много интересного пишет
Denwer wrote: > Вот как можно доказать что причина тормознутости это не прорисовка > графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен > не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем > его двигать поверх QT проги, в это время она же перерисовывается, так? > Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что > прихоодит в голову, это то что в QT много разных эвентов и тамо подобной > мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее.
Скорее они просто кэшируют рисунки. Попробуйте тоже самое с wxWidgets —
он на порядок быстрее работает.
Denwer wrote: > А никто и не спорит что QT замедляет работу, но тогда уж выбирай либо ты > рисуешь каждую форму на АПИ по 10 дней, либо рисуешь за 1 час но > скорость работы гуя медленнее. Кстати я вот не слышал что бы кто то > жаловался на скорость работы оперы(хотя я им не пользуюсь).
На API можно рисовать очень быстро — если знать как его готовить.
Д>>главное в .Net — это не только (и не столько) библиотеки классов. Главное — это инфраструктура для интеграции языков. Д>>Так что обсуждение получается из разряда "кит vs слон"
S>Зачем столько языков? Достаточно 2... бэйсик(онже C#) для офисных поделок и с++ для чегото более трудоемкого.
Есть еще функциональные языки. Вон, например, Влад в Философии пишет, что некий Nemerle рвет C# на мелкие запчасти
S>Qt вообще обходится одним с++... Причем можно сказать расширяет его...
А почему расширяет? Правильно, потому что недостаточно просто С++ для решения многих задач
Это я так, провоцирую А Qt мне и самому очень нравится
Здравствуйте, Arioch2, Вы писали:
С>>Сдается мне, Опера будет покруче и понавороченней,
A>Спошу еще раз, здесь все уверены, что Opera/Win32 использует Qt ? A>Учитывая, что opera/Win была всегда, а проект Opera/Magic появился в районе Opera 5. A>И что, они сменили весь к тому времени наработанный GUI ?
Opera/Win и Opera/nix выглядят практически идентично. Кроме того, заметно, что MessageBox'ы — это не стандартные виндозные MessageBox'ы, это что-то другое. Главное меню тоже явно не стандартное. Скроллбары тоже ведут себя по-другому.
К тому же, им так и так приходится делать Oper'у для *nix на QT. Эта самая QT — кроссплатформенна, и я думаю, грех не воспользоваться этой кроссплатформенностью.
D>>Вот та DLL о которой я говорил как раз и есть style engine.
K_O>То, что на винде нет стиля Mac OS еще не говорит об использовании родных библиотек для рисования виджетов. Это говорит о том, что ребята сделать качественную поддержку стиля на другой платформе не смогли. Или это, в принципе, невозможно. Еще раз, посмотри исходники.
Курить Qstyle
Все виджеты в Qt рисуются Qt. uxtheme.dll используется для определения текущих цветовых настроек в винде
Здравствуйте, Mamut, Вы писали:
D>>Я и не говорил что они используют для рисования виджетов только возможности виндовса. Но часть их используется.
M>Ну естественно. Например, используется GDI
D>>>Я и не говорил что они используют для рисования виджетов только возможности виндовса. Но часть их используется.
M>>Ну естественно. Например, используется GDI
D>Например рисование бекграунда элементов XP стиля.
Ну дык, GDI Ну и uxtheme.dll, естственно, но Qt на него не завязано — Win2k и Win98 ведь тоже поддерживать надо
Здравствуйте, dead_ricky, Вы писали:
>>>... сменил базу на MS SQL Server — летает....
_>А можно подробней, ну как вы это сделали?
Я скачал исходники 1.2 (через SVN, но вроде можно и архив скачать). Скомпилил.
Среди исходников лежит файлик DbMigration.txt в котором описано как мигрировать.
Там ничего сложного вроде нету.
Здравствуйте, anton_t, Вы писали:
_>Здравствуйте, Sheridan, Вы писали:
S>>Дык сразуже видно! Вы не заметили? S>>Следить за памятью ненадо, нормальные бинарники не собирает...
_>Всё ясно, Java — это бейсик . А кстати, что такое "нормальный бинарник"?
когда говорят Java подразумевают платформу в первую очередь, хотя и на счет языка я тоже не согласен...
M>>забыли.
SJA>Гм... Я уже подзабыл, но мне кажется, ORG 100 как раз и указывает точную привязку к адресам. После чего эти адреса настраивать не нужно.
А по-моему, оно резервировало место под служебную инфу ДОС, которая хранилась как-раз в первых 256 байт. И это не релокация, ИМХО...
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Здравствуйте, Rebus83, Вы писали:
R>Здравствуйте, Sergey J. A., Вы писали:
M>>>Про M>>>
M>>>ORG 100H
M>>>
M>>>забыли.
SJA>>Гм... Я уже подзабыл, но мне кажется, ORG 100 как раз и указывает точную привязку к адресам. После чего эти адреса настраивать не нужно.
R>А по-моему, оно резервировало место под служебную инфу ДОС, которая хранилась как-раз в первых 256 байт. И это не релокация, ИМХО...
Это сдвигало счетчик в ассемблере и потом он уже все адреса считал соответственно.
Но вообещ не скажу, были ли в exe в начале 256 байтов мусора или нет, всегда линковал сразу с ключом -t
Здравствуйте, Rebus83, Вы писали:
R>А по-моему, оно резервировало место под служебную инфу ДОС, которая хранилась как-раз в первых 256 байт. И это не релокация, ИМХО...
Именно, резервировало. При этом компилятор компилил код с расчётом, что начало файла попадёт на 100h. Т.е. жёстко прописывал все переходы, адреса и др.
exe файл можно загрузить с любого адреса, поэтому компилятор не может всё жёстко прошить сразу и строит таблицу релокаций.
Таким образом, можно сказать, что релокацию COM-а выполняет компилятор, а EXE — загрузчик.
З.Ы. Виндовые EXE можно так-же заранее релоцировать(или как там это называется ?) на определённый адрес. DLL тоже можно, но тогда есть шанс, что DLL не загрузится, если на её месте уже кто-то прописался.
С>Opera/Win и Opera/nix выглядят практически идентично. Кроме того, заметно, что MessageBox'ы — это не стандартные виндозные MessageBox'ы, это что-то другое. Главное меню тоже явно не стандартное. Скроллбары тоже ведут себя по-другому.
...поскольку у них шкурки, то явно они не могли использовать 100%-нативные контролы. Но ведь их шкурки и QTшными не являются!
Впрочем, я српосил TrollTech есть ли в Qt/Win32 drag-n-drop, ибо не хваает его в Опере.
Opera for Windows has not been created with Qt, so you need to contact
Opera to get an answer to your question.
[..]
A>...поскольку у них шкурки, то явно они не могли использовать 100%-нативные контролы. Но ведь их шкурки и QTшными не являются! A>Впрочем, я српосил TrollTech есть ли в Qt/Win32 drag-n-drop, ибо не хваает его в Опере.
A>
Opera for Windows has not been created with Qt, so you need to contact
A>Opera to get an answer to your question.
Благодарю, наконец-то меня перестал мучить вопрос о том, используется ли QT в Opera/Win.
Здравствуйте, Kubera, Вы писали:
K>Здравствуйте, Sheridan, Вы писали:
K>Минусы Qt:
K>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю).
Аляповато? Винда выглядит аляповато по сравнению с Plastique стилем. Причем при желании каждому приложению можно свой стиль прилепить, свои цвета...
[RSDN@Home][1.2.0][alpha][634]
[Hе бойся совершенства, тебе его не достичь никогда. [С. Дали]]
Здравствуйте, Sergey J. A., Вы писали:
SJA>З.Ы. Виндовые EXE можно так-же заранее релоцировать(или как там это называется ?) на определённый адрес. DLL тоже можно, но тогда есть шанс, что DLL не загрузится, если на её месте уже кто-то прописался.
Загрузится, только чуть дольше. Потому что как раз тогда придется выполнять relocation.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>100% можно сделать и просто быстро дергая мышкой, дело не в процентах. Просто за то время (очень приблизительно и на глаз, естественно), когда у меня Qt-шная форма отрисуется при ресайзе 1 раз, Блокнот успевает отрисоваться раз 10. Говоря языком геймеров, у Qt страдает FPS.
Поставил кутэ 4
По скорости прорисовывания сопоставимо с winforms...
[RSDN@Home][1.2.0][alpha][639]
[Из всех руин тяжелее всего созерцать человеческую руину. [Т. Готье]]
Здравствуйте, Arioch2, Вы писали:
A>Но умолчальный ты Керамик. Сладенькая гадость для девочек с розовыми бантами. Не знаю, может это я такой ненормальный, но от Керамика меня тошнит.
эээ вы путаете.... керамик это умолчание kde! Он мне самому не нравится.
С кутэ что с 3м что с 4м идут только 5 стилей: windows, windowsxp, plastique, motif и cde (и то точно непомню но вроде windowsxp токо в 4й qt появилось) — помотрите на шот — там все стили что с кутэ идут.
A>А что касается стилей в Виндах — когда игрался, мне нравился Elegant2000 от WindowsBlinds
Имхо в отличии от стилей кутэ WindowsBlinds это просто нашлепка сверху...
[RSDN@Home][1.2.0][alpha][639]
[В природе многих людей — рассуждать умно, но поступать нелепо. [А. Франс]]
Здравствуйте, Arioch2, Вы писали:
A>Там вроде Arthur сделали, который должен уметь напрямую задействовать разные DirectDraw или друкгие ускоренные нативные интерфейсы ?
Не вникал...
Может это про это?
[RSDN@Home][1.2.0][alpha][639]
[Легче хулить, чем сделать так же. [Аполлодор]]
Где-то была статья, где один из разработчиков X.org критиковал настоящее и смотрел в будущее (несколько пессимистично). Там он про ускорения говорил тоже.
S>Может это про это? S>
Красиво. Похоже на акву, но не обычные приглушённые цвета. Что за тема ?
Здравствуйте, Arioch2, Вы писали:
S>>По скорости прорисовывания сопоставимо с winforms...
A>Там вроде Arthur сделали, который должен уметь напрямую задействовать разные DirectDraw или друкгие ускоренные нативные интерфейсы ?
Qt Painting System теперь действительно называется Arthur. Но где сказано, что она реализована на основе DirectDraw?!
Qt currently provides paint engines for the following platforms and APIs:
A pixel-based engine for the Windows platform that is also used to draw onto QImages on all platforms
OpenGL on all platforms
PostScript on Linux, Unix, and Mac OS X
QuickDraw and CoreGraphics on Mac OS X
X11 and the X Render Extension on Linux and Unix systems
То есть, Артур — это скорее единый интерфейс рисования, который можно реализовать через что угодно. Но... через DirectDraw пока не реализован. И не факт, что будет когда-либо реализован.
K_O>Qt Painting System теперь действительно называется Arthur. Но где сказано, что она реализована на основе DirectDraw?!
Нигде, это к примеру. Суть в том, что на ускоренные интерфейсы. А на какие — не интересовался.
K_O>OpenGL on all platforms
Уже неплохо, наверное.
K_O> Но... через DirectDraw пока не реализован. И не факт, что будет когда-либо реализован.
Скорее всего не нужно. Какой-никакой OpenGL сейчас у любой карточки есть, а войны OpenGL vs DirectX в случае обычных програм неактуальны, тут никто за fps не гонится
Здравствуйте, Sinclair, Вы писали:
SJA>>З.Ы. Виндовые EXE можно так-же заранее релоцировать(или как там это называется ?) на определённый адрес. DLL тоже можно, но тогда есть шанс, что DLL не загрузится, если на её месте уже кто-то прописался. S>Загрузится, только чуть дольше. Потому что как раз тогда придется выполнять relocation.
Я говорю про ситуацию, когда данные для релокации будут сознательно удалены. Опция линкера /FIXED.
Для DLL они по умолчанию остаются, для других типов — удаляются.
Здравствуйте, Arioch2, Вы писали:
K_O>>Qt Painting System теперь действительно называется Arthur. Но где сказано, что она реализована на основе DirectDraw?! A>Нигде, это к примеру. Суть в том, что на ускоренные интерфейсы. А на какие — не интересовался.
Так ведь не на ускоренные интерфйесы, в том-то и дело. Сейчас Qt позволяет при желании и определенной доли настойчивости рисовать через OpenGL. Но... "гладко было на бумаге, да забыли про овраги".
K_O>>OpenGL on all platforms A>Уже неплохо, наверное.
Но и далеко не так хорошо, как кажется на первый взгляд. Есть проблемы с многопоточным рисованием, есть проблемы с рисованием в память.
K_O>> Но... через DirectDraw пока не реализован. И не факт, что будет когда-либо реализован. A>Скорее всего не нужно. Какой-никакой OpenGL сейчас у любой карточки есть, а войны OpenGL vs DirectX в случае обычных програм неактуальны, тут никто за fps не гонится
Иногда бывает, что и гонятся. Например, в CAD системах. Да и в обычных программах, сейчас все чаще применяются контролы со сложными спецэффектами (полупрозрачность, градиентные заливки, анимации), а в следующей версии Windows без этого вообще никуда. А в Windows Vista OpenGL, похоже, не будет среди фаворитов.
K_O>>> Но... через DirectDraw пока не реализован. И не факт, что будет когда-либо реализован. A>>Скорее всего не нужно. Какой-никакой OpenGL сейчас у любой карточки есть, а войны OpenGL vs DirectX в случае обычных програм неактуальны, тут никто за fps не гонится K_O>Иногда бывает, что и гонятся. Например, в CAD системах. Да и в обычных программах, сейчас все чаще применяются контролы со сложными спецэффектами (полупрозрачность, градиентные заливки, анимации),
В тех местах CAD-а где это нужно, все равно рисовать едва ли через Qt будут
Спецэффекты при всех их сложности будут уступать таковой в разных 3d-шутерах. Так что, пусть даже несколько медленнее...
Здравствуйте, Arioch2, Вы писали:
A>В тех местах CAD-а где это нужно, все равно рисовать едва ли через Qt будут A>Спецэффекты при всех их сложности будут уступать таковой в разных 3d-шутерах. Так что, пусть даже несколько медленнее...
Почему вы так думаете? В играх и в Qt разный OGL?
[RSDN@Home][1.2.0][alpha][639]
[Hеподражаемое как раз и вызывает большинство подражателей. [Мария Эшенбах]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Arioch2, Вы писали:
A>>В тех местах CAD-а где это нужно, все равно рисовать едва ли через Qt будут A>>Спецэффекты при всех их сложности будут уступать таковой в разных 3d-шутерах. Так что, пусть даже несколько медленнее...
S>Почему вы так думаете? В играх и в Qt разный OGL?
Одинаковый, требования к нему разные.
Если OGL рисует 1000 треугольников в секунду, то для игры этого не хватить, а тnx,s yнарисоват кнопку из даже 20 треугольников — хватит.
Здравствуйте, Sheridan, Вы писали:
S>slavdon, интересно знать чемже ты так до смешного несогласен?
Trolltech offers a free 30-day evaluation of Qt — if you are a commercial software developer, you may also qualify for free support during your evaluation
S>>slavdon, интересно знать чемже ты так до смешного несогласен? S>Trolltech offers a free 30-day evaluation of Qt — if you are a commercial software developer, you may also qualify for free support during your evaluation
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Kubera, Вы писали:
K>>Здравствуйте, Sheridan, Вы писали:
K>>Минусы Qt:
K>>1. Дорогая (в смысле дорого стоит). S>Opensource.
A>...поскольку у них шкурки, то явно они не могли использовать 100%-нативные контролы. Но ведь их шкурки и QTшными не являются! A>Впрочем, я српосил TrollTech есть ли в Qt/Win32 drag-n-drop, ибо не хваает его в Опере.
A>
Opera for Windows has not been created with Qt, so you need to contact
A>Opera to get an answer to your question.
Вах! Уважаю ребят из Оперы. Эххх, выпустили бы они свой тулкит.....
Sheridan wrote: > A>А что касается стилей в Виндах — когда игрался, мне нравился > Elegant2000 от WindowsBlinds > Имхо в отличии от стилей кутэ WindowsBlinds это просто нашлепка сверху...
А какая разница? Windows Blinds просто заменяет дефолтную систему
рисования виджетов.
Здравствуйте, Denwer, Вы писали:
D>Вот как можно доказать что причина тормознутости это не прорисовка графики. Берем прогу на QT, и ресайзим ее, проц действительно загружен не мало. Далее берем октрываем поверх нее скажем калькулятор, и начинаем его двигать поверх QT проги, в это время она же перерисовывается, так? Но загрузка проца 1-3 процента, в чем же тут дело то? Самое простое что прихоодит в голову, это то что в QT много разных эвентов и тамо подобной мишуры. Которая увеличивает возможности этой либы, но и замедляеет ее. Но никак не отрисовка виджетов.
afaik когда таскается калькулятор поверх формы, идёт только работа с битмапами
тоже самое бывает когда таскаешь форму без ресайза — перерисовывается битмап скопированный из предыдущего места
не скажу что правило, но сам замечал не раз что именно так и есть
Здравствуйте, Cyberax, Вы писали:
C>А какая разница? Windows Blinds просто заменяет дефолтную систему C>рисования виджетов.
Может быть, но тормозит это днло посильнее кутэ...
C>Кстати, QT произносится "кьюти" (как "cutie"). Знаю, только вот кутэ быстрее набрать
Здравствуйте, Sheridan, Вы писали:
K>>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю). S>Аляповато? Винда выглядит аляповато по сравнению с Plastique стилем. Причем при желании каждому приложению можно свой стиль прилепить, свои цвета...
Картинка вполне подойдет чтобы распечатать и подереть одно место.
Кроме картинки(она на 188м месте) в первую очередь важены функционалы контролов с точки зрения пользователя и разработчика.
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Да, все круто. А что на счет рантайма, рефлекшта, кодедома, автоматической сборки мусора, отсутствия указателей. Ну хорошая библиотека для С++. Что с того ?
[..]
PE>Картинка вполне подойдет чтобы распечатать и подереть одно место. PE>Кроме картинки(она на 188м месте) в первую очередь важены функционалы контролов с точки зрения пользователя и разработчика.
Вы хотите сказать, что в QT непорядок с функционалом контролов? ИМХО, это самая качественная библиотека для разработки кроссплатформенных десктопных приложений. Да и просто как средство разработки десктопных приложений не имеет достойных соперников и под Windows.
Здравствуйте, Kubera, Вы писали:
K>Здравствуйте, Sheridan, Вы писали:
K>Минусы Qt:
K>1. Дорогая (в смысле дорого стоит).
Тут я с вами согласен... Что есть то есть.... Дорого.... K>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю).
Аляповато????
Это при поддержке даже XP стиля???
Это Делфишные гуи аляповато.
Я не спорю не всегда нативно выглядит... Но порой даже лучше нативного...
K>3. Использования Qt-расширений С++ накладывает ограничение на исходный код, например, нельзя использовать шаблоны <sic!> (верно для 3.x, для 4-ой, кажется, тоже), проблемы с библиотекой boost::signals.
Насчёт boost::signals не знаю... не пробовал... Не вижу смысла использовать signals в библиотеке постоенной на колбэках...
K>4. Мне не очень понравился предлагаемый Qt механизм создания пользовательского интерфейса.
Ну тут дело вкуса...
Я в генерации вообще вижу 2 варианта:
1. Генератор кода (QT, FLTK, C#...)
2. Генератор ресурсов (Сocoa, MFC частично...)
K>ИМХО, Qt неплохой выбор при разработки приложения (с богатым GUI), целевыми платформами для которого будут Win & Linux. А вот над целесообразностью разработки единого пользовательского интерфейса под Mac и под Win нужно десять раз подумать. (Всё таки маковский гуй существенно отличается от виндового.)
А вы пробовали????
Я про Mac.
Думаю нет, раз ИМХО большими буквами упомянули вначале
А я пробовал.
Из всех возможных кроссплатформенных либ — это единственная поддерживающая НАТИВНЫЙ Mac интерфейс..... (+ кучу других нативных интерфейсов)
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
[..]
PE>Да, все круто.
Согласен. PE>А что на счет рантайма,
C/C++ runtime library PE>рефлекшта, кодедома,
Это что, надо? PE> автоматической сборки мусора,
насчет этого можно долго спорить. Лично я придерживаюсь другой точки зрения — мусорить не надо, и сборщик не нужен будет. PE> отсутствия указателей.
Это есть хорошо? PE>Ну хорошая библиотека для С++.
Согласен. PE>Что с того ?
Ну как. Все что вы там выше перечислили — может и круто, но (ИМХО) реально револиционная вещь — это то, что в средствах разработки от Microsoft GUI теперь можно рисовать мышкой, даже если ты не VB-шник. И кнопочки удобно рисовать, и язык — не VB6. А пройдет некоторое время, и Microsoft опять призадумается, почему же до сих пор существую другие, не Windows-платформы. И тогда появится новая технология, в которой тоже будет много умных слов. И будет толпа последователей этой технологии, предвещая вслед за рекламщиками Microsoft'а грядущее тотальное доминирование новомодной технологии. А за предыдущим революционной технологией Microsoft, как обычно, останется та ниша, в которой от нее действительно будет какая-то польза.
А вот если посмотреть с другой стороны, жизнь на Марсе тоже есть. Linux — ОС, выросшая из курсовой работы лет на десять позже (может, я и ошибаюсь), чем появилась Windows 1.0, сейчас является самым значимым конкурентом ОС Windows. Обратите внимание — никаких революционных мега-технологий, а спектр возможного применения GNU/Linux несравнимо шире. А та самая оболочка, которая и является, собственно, конкурентом Windows на десктопах — это KDE, основанная на просто хорошей библиотеке для C++ — QT.
Так что я думаю, все эти COM'ы, .NET'ы — 90% маркетинг. Как и раньше, гигантом софтостроения движет желание заработать больше бабла и задавить конкурентов (им даже не жалко DVD-ки по всему миру рассылать с VS2k5beta ради того, чтоб программеров на него подсадить).
В общем, я к чему. QT для программиста предоставляет широкие возможности для программирования широкого класса кроссплатформенных приложений, включает удобные средства построения GUI, хорошо спроектирована. Область применения неплохо так пересекается с новой революционной технологией microsoft, в которой, как обычно, много новых терминов и т. п. А если конечный результат один и тот же, зачем платить больше (20mb — или сколько там — фреймворк, прожорливость по отношению к памяти и общая тормознутость)? Как обычно, OpenSource решения (в данном случае — QT) позволяют достичь того же, но не плодят сущности без необходимости.
Disclamer
Вот такое моё мнение. Прошу сильно не пинать. Если кому надо, могут считать, что я заранее согласился с тем что я не прав и фреймворк, разумеется, будет скоро даже на калькуляторах, да и работает мегабыстро. С памятью два варианта — либо она очень дешевая либо нифига .net овские проги ее не хавают без меры. Разумеется, я никогда не работал с этой технологией и поэтому ничего в ней не понимаю.
В общем, если вы не согласны с этим постом, сотрите его с носителей информации своего компьютера и забудьте его.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Картинка вполне подойдет чтобы распечатать и подереть одно место. PE>Кроме картинки(она на 188м месте) в первую очередь важены функционалы контролов с точки зрения пользователя и разработчика.
Выбы сначала любезнейший попрограммили под Qt а потом можете и слово молвить.
[RSDN@Home][1.2.0][alpha][642]
[Если только знать, но не действовать, то это равносильно неучению. [Чжу Си]]
Здравствуйте, Plutonia Experiment, Вы писали:
PE>А что на счет рантайма, рефлекшта, кодедома, автоматической сборки мусора, отсутствия указателей.
Любитель бэйсика? Не нравятся указатели? Не нравится возможность управления памятью?
[RSDN@Home][1.2.0][alpha][642]
[Боится презрения лишь тот, кто его заслуживает [Ф. Ларошфуко]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>А что на счет рантайма, рефлекшта, кодедома, автоматической сборки мусора, отсутствия указателей. S>Любитель бэйсика? Не нравятся указатели? Не нравится возможность управления памятью?
Не, возможность управления нравится. Не нравится не возможность не управления. А на счёт бейсика... Вот скажи — перл и питон — это бейсик?
Здравствуйте, anton_t, Вы писали:
_>Не, возможность управления нравится. Не нравится не возможность не управления.
Эээ... Невъехал...
_>А на счёт бейсика... Вот скажи — перл и питон — это бейсик?
Да, интерпритаторы. (во всяком случае перл, питона не видел)
Хотя и помощнее бэйсика. (как впрочем и шарп тоже просто новая более мощная версия бэйсика)
Я признаю только нормальные языки, компилиркемые в нормальный бинарный код.
Остальное так, скрипты пописать на 20-30 строчек...
[RSDN@Home][1.2.0][alpha][642]
[В молодости учатся, а в старости понимают. [Мария Эшенбах]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, anton_t, Вы писали:
_>>Не, возможность управления нравится. Не нравится не возможность не управления. S>Эээ... Невъехал...
Какой слово тебе не понятно?
_>>А на счёт бейсика... Вот скажи — перл и питон — это бейсик? S>Да, интерпритаторы. (во всяком случае перл, питона не видел) S>Хотя и помощнее бэйсика. (как впрочем и шарп тоже просто новая более мощная версия бэйсика)
S>Я признаю только нормальные языки, компилиркемые в нормальный бинарный код. S>Остальное так, скрипты пописать на 20-30 строчек...
Здравствуйте, anton_t, Вы писали:
_>Не, возможность управления нравится. Не нравится не возможность не управления. А на счёт бейсика... Вот скажи — перл и питон — это бейсик?
Нет не бейсик. Языки созданы для совершенно разного класса задач. Бейсик(visual) — для легкого и быстрого создания "полноценных" программ программистами с низкой квалификацией (по этой причине его не хорошо сравнивать с Билдером/Делфи — средой для быстрого создания интерфейсов + быстрого доступа к основным функциям ОС), perl — язык для администраторов для максимально простого создания программ для анализа текстовых файлов. С возможностью быстрого внесения изменений даже если нет компилятора под рукой (а зачем на сервере компилятор?), поэтому не компилируется. Python — не знаю для чего он задумывался. Видимо для простого создания портируемых программ в тех случаях, когда скорость работы не сильно критична, а на первый план выходит простота написания (например скрипты для того же администратора). Про С# думаю, что он ближе к Делфи/Билдеру с уклоном в сторону Бейсика.
Здравствуйте, anton_t, Вы писали:
_>>>Не, возможность управления нравится. Не нравится не возможность не управления. S>>Эээ... Невъехал...
_>Какой слово тебе не понятно?
Я фразу непонял, особенно вторую...
[RSDN@Home][1.2.0][alpha][642]
[Кто умеет льстить, умеет и клеветать. [Hаполеон I]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Kubera, Вы писали:
K>>Здравствуйте, Sheridan, Вы писали:
K>>Минусы Qt:
K>>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю). S>Аляповато? Винда выглядит аляповато по сравнению с Plastique стилем. Причем при желании каждому приложению можно свой стиль прилепить, свои цвета...
У приложений стиль должен быть умолчательный в системе. Бесит когда приложения пытаються "красоваться" своими аляповатыми интерфейсами.
Здравствуйте, slavdon, Вы писали:
S>У приложений стиль должен быть умолчательный в системе. Бесит когда приложения пытаються "красоваться" своими аляповатыми интерфейсами.
Это извини как программер решит спрограммировать.
[RSDN@Home][1.2.0][alpha][642]
[Hе всякому человеку даже гусарский мундир к лицу. [К. Прутков]]
Здравствуйте, Sheridan, Вы писали:
S>Я признаю только нормальные языки, компилиркемые в нормальный бинарный код. S>Остальное так, скрипты пописать на 20-30 строчек...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, anton_t, Вы писали:
_>>>>Не, возможность управления нравится. Не нравится не возможность не управления. S>>>Эээ... Невъехал...
_>>Какой слово тебе не понятно? S>Я фразу непонял, особенно вторую...
Ну в некоторых языках есть возможность не управлять памятью. Так вот, в С++ этой возможности нет.
Здравствуйте, WFrag, Вы писали:
WF>А как определить нормальность бинарного кода?
Который не компилируется/интерпритируется непосредственно при/перед исполнением.
[RSDN@Home][1.2.0][alpha][642]
[Hовые взгляды сквозь старые щели. [Г. Лихтенберг]]
Здравствуйте, Sheridan, Вы писали:
WF>>А как определить нормальность бинарного кода? S>Который не компилируется/интерпритируется непосредственно при/перед исполнением.
Здравствуйте, anton_t, Вы писали:
S>>Я фразу непонял, особенно вторую... _>Ну в некоторых языках есть возможность не управлять памятью. Так вот, в С++ этой возможности нет.
гм... Не создавать указатели?
[RSDN@Home][1.2.0][alpha][642]
[Забудь часы нужды, но не забывай того, чему они тебя научили. [С. Геснер]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, anton_t, Вы писали:
S>>>Я фразу непонял, особенно вторую... _>>Ну в некоторых языках есть возможность не управлять памятью. Так вот, в С++ этой возможности нет. S>гм... Не создавать указатели?
Не заботиться о том, что нужно делать указателю delete.
Здравствуйте, Sheridan, Вы писали:
WF>>Ahead Of Time компиляция. Когда байт-код компилируется в нативный заранее.
S>Перед выполнением?
Да. Только раньше, чем JIT. Например, gcj (вроде бы) такое умеет — компилирует .class-файлы Java в библиотеки .so. Соответственно, может компилировать заранее.
Здравствуйте, WFrag, Вы писали:
S>>Перед выполнением?
WF>Да. Только раньше, чем JIT. Например, gcj (вроде бы) такое умеет — компилирует .class-файлы Java в библиотеки .so. Соответственно, может компилировать заранее.
С большой натяжкой это бинарники. С огромной! Нет компилятора — абздец.
Единственный + -> возможная(может быть) оптимизация под камень и прочее...
А теперь представьте такая вот полуинтерпритированная софтина из скрипта будет запускатся раз 50 в секунду.
[RSDN@Home][1.2.0][alpha][642]
[Кто хорошо служит своей родине, тот не нуждается в предках. [Ф. Вольтер]]
Здравствуйте, Sheridan, Вы писали:
S>С большой натяжкой это бинарники. С огромной! Нет компилятора — абздец. S>Единственный + -> возможная(может быть) оптимизация под камень и прочее...
S>А теперь представьте такая вот полуинтерпритированная софтина из скрипта будет запускатся раз 50 в секунду.
Какие-то странные я б сказал у тебя требования к софту Ну, будет медленно запускаться. И что? Никто же не перезапускает enterprise (к примеру) порталы 50 раз в секунду — там такого требования просто не стоит.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Sheridan, Вы писали:
S>>С большой натяжкой это бинарники. С огромной! Нет компилятора — абздец. S>>Единственный + -> возможная(может быть) оптимизация под камень и прочее...
S>>А теперь представьте такая вот полуинтерпритированная софтина из скрипта будет запускатся раз 50 в секунду.
WF>Какие-то странные я б сказал у тебя требования к софту Ну, будет медленно запускаться. Да ну? Обычное требование — чтобы не тормозило.
WF> И что? Никто же не перезапускает enterprise (к примеру) порталы 50 раз в секунду — там такого требования просто не стоит.
Вот так все и начинается. Ждем драйверов реального времени на байсике.
[RSDN@Home][1.2.0][alpha][642]
[Hичто так не вредит, как возлагаемые надежды. [Цицерон]]
Здравствуйте, Sheridan, Вы писали:
WF>>Какие-то странные я б сказал у тебя требования к софту Ну, будет медленно запускаться.
S> Да ну? Обычное требование — чтобы не тормозило.
Извини, но ты бредишь. Начиная с того, что "тормозит" понятие крайне неопределенное и заканчивая тем, что вообще говоря, приоритеы при разработки систем бывают самые различные.
Я вполне могу представить ситуацию, когда двоекратная скорость разработки (например) окупает 10-кратное замедление в скорости работы (при заданном объеме данных).
WF>> И что? Никто же не перезапускает enterprise (к примеру) порталы 50 раз в секунду — там такого требования просто не стоит.
S>Вот так все и начинается. Ждем драйверов реального времени на байсике.
К слову сказать, на Erlang-е уже пишут системы мягкого реального времени. И ничего, ребята вроде счастливы.
Вообще у тебя какая-то странная аргументация. Причем тут вообще драйвера реального времени? Я тебе привел пример — некий корпоративный портал. Скажем, что-то типа http://ibm.com/. Скажи мне, нафиг там нужно 50 перезапусков в секунду?
Здравствуйте, WFrag, Вы писали:
S>> Да ну? Обычное требование — чтобы не тормозило.
WF>Извини, но ты бредишь.
Отнюдь.
WF>Начиная с того, что "тормозит" понятие крайне неопределенное
Согласен. dir тормозит это когда задумывается на пару секунд. msvs тормозит это когда задумывается на пару минут.
WF>и заканчивая тем, что вообще говоря, приоритеы при разработки систем бывают самые различные.
К сожалению основной приоритет сейчас — рюшечки.
WF>Я вполне могу представить ситуацию, когда двоекратная скорость разработки (например) окупает 10-кратное замедление в скорости работы (при заданном объеме данных).
Я тоже ее представить могу и что, значит надо чтобы тормозило?
S>>Вот так все и начинается. Ждем драйверов реального времени на байсике. WF>К слову сказать, на Erlang-е уже пишут системы мягкого реального времени. И ничего, ребята вроде счастливы.
Мама... Посмотрим насколько будут счастливы конечные пользователи.
WF>Вообще у тебя какая-то странная аргументация. Причем тут вообще драйвера реального времени? Я тебе привел пример — некий корпоративный портал. Скажем, что-то типа http://ibm.com/. Скажи мне, нафиг там нужно 50 перезапусков в секунду?
ааа... Гм... Тут извините и побольше надо. Сколько пользователей в секунду может туда зайти?
[RSDN@Home][1.2.0][alpha][642]
[Люди легко верят тому, чего страстно желают. [Ф. Вольтер]]
Здравствуйте, Sheridan, Вы писали:
WF>>Начиная с того, что "тормозит" понятие крайне неопределенное S>Согласен. dir тормозит это когда задумывается на пару секунд. msvs тормозит это когда задумывается на пару минут.
Не забывай еще о зависимости от объема данных, например.
WF>>и заканчивая тем, что вообще говоря, приоритеы при разработки систем бывают самые различные.
S>К сожалению основной приоритет сейчас — рюшечки.
Сам придумал?
WF>>Я вполне могу представить ситуацию, когда двоекратная скорость разработки (например) окупает 10-кратное замедление в скорости работы (при заданном объеме данных).
S>Я тоже ее представить могу и что, значит надо чтобы тормозило?
Нет. Это значит, что бывают задачи, где производительность не так важна.
WF>>К слову сказать, на Erlang-е уже пишут системы мягкого реального времени. И ничего, ребята вроде счастливы.
S>Мама... Посмотрим насколько будут счастливы конечные пользователи.
В том-то и дело, что довольны. Можешь смеху ради FAQ почитать, там про C++ и производительность пара слов есть. В общем, если интересно, можешь поискать различные отчеты, например, о AXD301.
WF>>Вообще у тебя какая-то странная аргументация. Причем тут вообще драйвера реального времени? Я тебе привел пример — некий корпоративный портал. Скажем, что-то типа http://ibm.com/. Скажи мне, нафиг там нужно 50 перезапусков в секунду?
S>ааа... Гм... Тут извините и побольше надо. Сколько пользователей в секунду может туда зайти?
Дык приложение-то не перезапускается. Оно как стартануло, так и работает.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, anton_t, Вы писали:
_>>Не заботиться о том, что нужно делать указателю delete.
S>... и улетаем в memory leak. Причем в одном случае по своей вине а в другом, более сложном — по вине разработчика языка.
Здравствуйте, Sheridan, Вы писали:
WF>>Вообще у тебя какая-то странная аргументация. Причем тут вообще драйвера реального времени? Я тебе привел пример — некий корпоративный портал. Скажем, что-то типа http://ibm.com/. Скажи мне, нафиг там нужно 50 перезапусков в секунду? S>ааа... Гм... Тут извините и побольше надо. Сколько пользователей в секунду может туда зайти?
Причём тут пользователи портала и перезапуски? Компиляция происходит при первом запуске кода. Далее обращение происходит уже к откомпилированному коду.
Здравствуйте, anton_t, Вы писали:
S>>... и улетаем в memory leak. Причем в одном случае по своей вине а в другом, более сложном — по вине разработчика языка.
_>Не знаю, я на C# ни куда не улетаю.
... что имхо довольно странно, особенно для микрософта.
[RSDN@Home][1.2.0][alpha][642]
[Истинное воображение требует гениального знания. [А. С. Пушкин]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, slavdon, Вы писали:
S>>У приложений стиль должен быть умолчательный в системе. Бесит когда приложения пытаються "красоваться" своими аляповатыми интерфейсами.
S>Это извини как программер решит спрограммировать.
Вот потом такие и говорят "что их не понимают".
Программу надо писать какую хочет пользователь, а не как программист.
Здравствуйте, WFrag, Вы писали:
S>>Согласен. dir тормозит это когда задумывается на пару секунд. msvs тормозит это когда задумывается на пару минут. WF>Не забывай еще о зависимости от объема данных, например.
не забыл.
S>>К сожалению основной приоритет сейчас — рюшечки. WF>Сам придумал?
Да нет, по сторонам смотрю...
WF>Нет. Это значит, что бывают задачи, где производительность не так важна.
Я честно пытался представить подобное но так и не смог...
WF>>>К слову сказать, на Erlang-е уже пишут системы мягкого реального времени. И ничего, ребята вроде счастливы. S>>Мама... Посмотрим насколько будут счастливы конечные пользователи.
WF>В том-то и дело, что довольны. Можешь смеху ради FAQ почитать, там про C++ и производительность пара слов есть. В общем, если интересно, можешь поискать различные отчеты, например, о AXD301.
Про это?
Code which involves mainly number crunching and data processing will run about 10 times slower
than an equivalent C program. This includes almost all "micro benchmarks"
Large systems which spent most of their time communicating with other systems, recovering from
faults and making complex decisions run at least as fast as equivalent C programs.
Тоесть не обращать внимание что обработка данных в 10 раз медленнее, зато чучуть быстрее работают системы которые большую часть времени простаивают...
S>>ааа... Гм... Тут извините и побольше надо. Сколько пользователей в секунду может туда зайти? WF>Дык приложение-то не перезапускается. Оно как стартануло, так и работает.
IBM_HTTP_Server?
[RSDN@Home][1.2.0][alpha][642]
[Hе слово, а несчастье есть учитель глупцов. [Демокрит]]
Здравствуйте, slavdon, Вы писали:
S>Вот потом такие и говорят "что их не понимают". S>Программу надо писать какую хочет пользователь, а не как программист.
Значит программер должен поумолчанию пользовать стиль системы, и дать возможность выбора стиля пользователю.
[RSDN@Home][1.2.0][alpha][642]
[Все для всего всегда. [Будда]]
Здравствуйте, Sheridan, Вы писали:
S>Я честно пытался представить подобное но так и не смог...
Да запросто. Самый тупой пример — Proof Of Concept или прототип
Ну и вообще за выигрыш во времени/деньгах на разаботку и выигрыш в надежности надежности можно еще серверов прикупить.
S>Про это? S>
S>Code which involves mainly number crunching and data processing will run about 10 times slower
S>than an equivalent C program. This includes almost all "micro benchmarks"
S>Large systems which spent most of their time communicating with other systems, recovering from
S>faults and making complex decisions run at least as fast as equivalent C programs.
S>Тоесть не обращать внимание что обработка данных в 10 раз медленнее, зато чучуть быстрее работают системы которые большую часть времени простаивают...
Не думаю, что софт для AXD301 основное время проводит в number crunching и data processing. По-моему, он больше под второе подпадает. В любом случае, лучше таки погляди различные отчеты. Люди счастливы. Недалее как сегодня пришло письмо с success story в erlang-questions Реальный пример, в отличие от форумного трепа
Вот, кстати, любопытная ссылочка: http://www.sics.se/~joe/apachevsyaws.html. Тест разумеется не является полноценным тестом на производителоьность, однако что-то да означает
S>IBM_HTTP_Server?
Нет, J2EE приложение. Хотя возможно, что их портал и без него сделан В таком случае можно на microsoft.com поглядеть, у них вроде таки на .NET портал.
Здравствуйте, slavdon, Вы писали:
S>У приложений стиль должен быть умолчательный в системе. Бесит когда приложения пытаються "красоваться" своими аляповатыми интерфейсами.
Согласен.
А вот у разработчиков Microsoft Office видимо другие представления. А недавно вообще встретил программу для админов (от Microsoft), которая обеспечивает НАТ, прокси и еще всякую гадость с сетью. Так у той интерфейс мне ICQ напомнил по аляповатости. При этом QT совсем не причем и может создавать такой же по виду интерфейс. А то что программист может другой задать так покажите, где этого нельзя. Только в одних местах это проще, в других — сложнее.
Здравствуйте, Sheridan, Вы писали:
S>А теперь представьте такая вот полуинтерпритированная софтина из скрипта будет запускатся раз 50 в секунду.
Нормально. В Линуксе при загрузке такая кипа скриптов стартует и выполняется. Только под Линуксом запуск процесса операция очень быстрая, а вот под Виндой тяжеловата... все из-за разной идеологии. В Unix'е жизненно необходимо стартовать большое количество мелких программ (например интерпритаторов), а в винде проги большие, стартанули и работают неспеша. Но это уже другая история.
Здравствуйте, __MasteR__, Вы писали:
__M>Здравствуйте, slavdon, Вы писали:
S>>У приложений стиль должен быть умолчательный в системе. Бесит когда приложения пытаються "красоваться" своими аляповатыми интерфейсами.
__M>Согласен. __M>А вот у разработчиков Microsoft Office видимо другие представления. А недавно вообще встретил программу для админов (от Microsoft), которая обеспечивает НАТ, прокси и еще всякую гадость с сетью. Так у той интерфейс мне ICQ напомнил по аляповатости. При этом QT совсем не причем и может создавать такой же по виду интерфейс. А то что программист может другой задать так покажите, где этого нельзя. Только в одних местах это проще, в других — сложнее.
Что интерфейс у Офисов начиная с ХП дурной согласен. Мне больше всего Офис2к нравился
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Сам после небольшого дрейфа по библиотекам (wxWidgets,FLTK и U++ попробовал) остановился на Qt 4.1 OO. Супер. Сигнал-слот после MFC/wxWidgets'ких макросов это что-то
Здравствуйте, Arioch2, Вы писали:
Д>>>Кстати, как там RSDN@Linux поживает? S>>Дык вот начал кутэ учить,
A>А Mono/dotGNU изучить не реальней? статью бы написал, как живет .NET на не-виндах
A>Т.е. я понимаю, что вообще не живёт Но... http://beaglewiki.org/Installing_prerequisites
А он уже 2.0 поддерживает? ИМХО, под Линукс уж лучше C++
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, anton_t, Вы писали:
С>[...] _>>Не заботиться о том, что нужно делать указателю delete.
С>В C++ для этого есть auto_ptr <>. С>Зачем нужен gc, если есть смарт-пойнтеры?
Да что-то по слухам они то с одной фичей не совместимы, то с другой.
Здравствуйте, anton_t, Вы писали:
С>>В C++ для этого есть auto_ptr <>. С>>Зачем нужен gc, если есть смарт-пойнтеры?
_>Да что-то по слухам они то с одной фичей не совместимы, то с другой.
Д>а чего там "учить"? библиотеку классов на память заучивать, что ли? Д>достаточно разобраться с основными концепциями наподобие signal-slot, moc и так далее — и в бой. Для толкового программиста дня два-три максимум.
Вы неправы Кроме заучивания функций существует такая вещь как подводные камни и их желательно выявлять на кощках
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Qt, конечно, круть. Но сравнение его с .Net — это вообще просто пальцем в небо! Следовало бы переформулировать: Qt vs WinForms.
Мне .Net приглянулся из-за того, что:
1. Оптимизирован под платформу ОС самого разработчика этой ОС.
2. Намного меньше головных болей при решении классических задач, которые необходимо решать в любом (или почти любом) приложении.
3. Это действительно технология и стиль разработки приложений уровня корпорации. Чего только стоит .Net Remoting или Reflection (который хоть и тормознутый, но при правильном дозированном употреблении лечит много головных болей).
..и т.д. и т.п.
Причем, понравилась именно за счет того, что можно создавать сложные многоуровневые приложения "лёгким движением руки". Именно за это, а не за пользовательский интерфейс. Работаю пока с дот Нет 1.1. Во второй версии, говорят, вообще еще круче. И вообще, постоянно сталкиваюсь с двумя-тремя заблуждениями: "дот Нет — это среда для разработки приложений на разных языках", "дот Нет — это платформа для Интернет-приложений", "дот Нет — это интерпретация кода". Всё это верно только в одномерных проекциях, причем большинство проецируют весь спектр только в одну проекцию, я бы сказал, даже в точку. Причем только в одну, в зависимости от своих чисто субъективных предпочтений/бывшего личного опыта...
Вы, уважаемый сударь, вообще-то о дот Нете в каком объёме представление имеете?.. А?.. Спрашиваю, т.к. непонимание ключевой сути просто бъёт по глазам... Или это просто провокация? Если базар на тему .Net vs J2EE еще уместен, то сабж, на который отвечаю, ИМХО, вообще-то некорректен. Это почти тоже самое, что сравнивать "зелёное" и "мокрое", или "вкусное" и "злобное".
Да, в Qt есть выход за границы чисто графической библиотеки в область других системных функций, но как была она ориентирована на пользовательский интерфейс, так и останется. Это в ней главное. Ещё один плюс многоплатформенность. Ну и красивое решение некоторых внутренних задач. Но это и всё....
А я проблему скудности стандартных Виндозовских Виджетов решил другим способом: убедил руководство купить Developer Express (http://www.devexpress.com), наделал своих сложных компонентных контролов на базе имеющихся, и не жу-ж-жжу! Колеги, кстати, тоже не жужжат, а активно пользуются.
Достаточно, пожалуй. Если в чем то ошибаюсь, прошу прощения, т.к. с последними версиями КуТэ не работал... Мож там действительно что-то принципиально новое появилось, в чем я почему-то сомневаюсь...
З.Ы. Мнение автора может не совпадать с мнением редакции.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, WFrag, Вы писали:
WF>>Ahead Of Time компиляция. Когда байт-код компилируется в нативный заранее. S>Перед выполнением?
Здравствуйте, slavdon, Вы писали:
S>Что интерфейс у Офисов начиная с ХП дурной согласен. Мне больше всего Офис2к нравился
Кстати насчет аляповатого интерфейса офиса 11: как ни странно, во всех этих пухлых градиентах и прочей попсе используются именно цвета выбранной пользователем темы. Попереключайте темки, попробуйте свои цвета настроить. Офис будет смотреться вполне гармонично. Так что MS Office User Experience Team не зря свой хлеб с форелью кушает.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, slavdon, Вы писали:
S>>Что интерфейс у Офисов начиная с ХП дурной согласен. Мне больше всего Офис2к нравился S>Кстати насчет аляповатого интерфейса офиса 11: как ни странно, во всех этих пухлых градиентах и прочей попсе используются именно цвета выбранной пользователем темы. Попереключайте темки, попробуйте свои цвета настроить. Офис будет смотреться вполне гармонично. Так что MS Office User Experience Team не зря свой хлеб с форелью кушает.
проблема в том что я не люблю пухлость. Мне нравиться "ровный" интерфейс
K>1. Дорогая (в смысле дорого стоит).
С чем сравниваем?
K>2. Приложение на Qt выглядит аляповато, внешний вид отличается от родного GUI (верно для Win, как на Мак'ах не знаю).
Эээ... Вон там тебе один скриншот прислали, я могу наших пару подкинуть. Выглядит, как... Блин, просто виндовое приложение! МЕняешь стиль в виндах — меняется и там.
K>3. Использования Qt-расширений С++ накладывает ограничение на исходный код, например, нельзя использовать шаблоны <sic!> (верно для 3.x, для 4-ой, кажется, тоже), проблемы с библиотекой boost::signals.
Эээ... Это как это "нельзя использовать шаблоны"??? Я использую, и ничего... То, что в самой Qt много шаблонов (QValueList, QMap...) — это как?
Единственное ограничение, которое рекомендуют тролльтеховцы — не использовать exception'ы. И то, при умелом подходе вполне обходится. Но это уже пилотаж второго курса обучения Но и не высший, имхо.
Про boost — не знаю, не пользовал никогда.
K>4. Мне не очень понравился предлагаемый Qt механизм создания пользовательского интерфейса.
тут пас. Работаю с Qt2 и Qt3, designer'ом доволен. Многое делается вручную достаточно просто.
Здравствуйте, Dair, Вы писали:
K>>4. Мне не очень понравился предлагаемый Qt механизм создания пользовательского интерфейса. D>тут пас. Работаю с Qt2 и Qt3, designer'ом доволен. Многое делается вручную достаточно просто.
Я дизайнера использую только чтобы слоты — события посмотреть у контролов. Остальное вручную.
[RSDN@Home][1.2.0][alpha][643]
[Или ничто не истинно, или истинное нам неизвестно. [Демокрит]]
Здравствуйте, Vladimir V Kochetkov, Вы писали:
VVK>Здравствуйте, Sheridan, Вы писали:
S>>бэйсик(онже C#)
VVK>На чем основывается данное утверждение?
На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Arioch2, Вы писали:
A>>Все что не написано на Oberon++ — в биореактор!!!!!!
S>Что такое оберон?
Это тот, у которого был волшебный рог.
Здравствуйте, Hasmik, Вы писали:
H>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций.
Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
[RSDN@Home][1.2.0][alpha][648]
[Если афоризм нуждается в пояснениях, значит он неудачен. [Л. Вовенарг]]
Здравствуйте, Kubera, Вы писали:
А вот над целесообразностью разработки единого пользовательского интерфейса под Mac и под Win нужно десять раз подумать. (Всё таки маковский гуй существенно отличается от виндового.)
Даже и думать нечего. Фтопку! "Non-Mac look and feel" — это приговор для программы под Мак.
Здравствуйте, Kh_Oleg, Вы писали:
K>>>1. Дорогая (в смысле дорого стоит). S>>Opensource. K_O>В OpenSource нет поддержки MSVC и интеграции со студией.
Кстати, есть. Только нужно ее правильно собрать Я поставил сперва evalution версию, затем переписал ее открытой, открытую студией же и собрал (небольшой геморр с конфигурированием, но очень небольшой), после чего получил открытую версию qt с интеграцией со студией. Конечно, после окончания срока действия интегратора, перестают работать некоторые кутешные пункты меню в студии, но только некотрые! И как раз те, которыми я никогда не пользовался. А в списке шаблонов проектов (при создании нового проекта) кутешные визарды успешно работают, а это как раз то, что нужно.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Hasmik, Вы писали:
H>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций. S>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Hasmik, Вы писали:
H>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций. S>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
Для меня тормоза наступают тогда, когда для того, чтобы получить из строки число, пользуешься допотопными функциями, где еще надо буфер создавать.
Или for(int i=1;i<times;i++) вместо foreach.
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, Kh_Oleg, Вы писали:
K>>>>1. Дорогая (в смысле дорого стоит). S>>>Opensource. K_O>>В OpenSource нет поддержки MSVC и интеграции со студией.
D> Кстати, есть. Только нужно ее правильно собрать Я поставил сперва evalution версию, затем переписал ее открытой, открытую студией же и собрал (небольшой геморр с конфигурированием, но очень небольшой), после чего получил открытую версию qt с интеграцией со студией. Конечно, после окончания срока действия интегратора, перестают работать некоторые кутешные пункты меню в студии, но только некотрые! И как раз те, которыми я никогда не пользовался. А в списке шаблонов проектов (при создании нового проекта) кутешные визарды успешно работают, а это как раз то, что нужно.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>>>В OpenSource нет поддержки MSVC и интеграции со студией.
D>> Кстати, есть. Только нужно ее правильно собрать Я поставил сперва evalution версию, затем переписал ее открытой, открытую студией же и собрал (небольшой геморр с конфигурированием, но очень небольшой), после чего получил открытую версию qt с интеграцией со студией. Конечно, после окончания срока действия интегратора, перестают работать некоторые кутешные пункты меню в студии, но только некотрые! И как раз те, которыми я никогда не пользовался. А в списке шаблонов проектов (при создании нового проекта) кутешные визарды успешно работают, а это как раз то, что нужно.
K_O>А дизайнер форм после истечения срока работает?
Нет А он нужен что-ли? Я формы в дельфи нарисовался по самое не могу (и терпеть не могу это дело). В qt очень просто и приятно все делать ручками. Но уж если захотелось все же что-то наваять в дизайнере, то запускай-не-хочу его как внешнюю прогу.
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>>>В OpenSource нет поддержки MSVC и интеграции со студией.
D>>> Кстати, есть. Только нужно ее правильно собрать Я поставил сперва evalution версию, затем переписал ее открытой, открытую студией же и собрал (небольшой геморр с конфигурированием, но очень небольшой), после чего получил открытую версию qt с интеграцией со студией. Конечно, после окончания срока действия интегратора, перестают работать некоторые кутешные пункты меню в студии, но только некотрые! И как раз те, которыми я никогда не пользовался. А в списке шаблонов проектов (при создании нового проекта) кутешные визарды успешно работают, а это как раз то, что нужно.
K_O>>А дизайнер форм после истечения срока работает?
D> Нет А он нужен что-ли? Я формы в дельфи нарисовался по самое не могу (и терпеть не могу это дело). В qt очень просто и приятно все делать ручками. Но уж если захотелось все же что-то наваять в дизайнере, то запускай-не-хочу его как внешнюю прогу.
Здравствуйте, Demiurg, Вы писали:
K_O>>А дизайнер форм после истечения срока работает?
D> Нет А он нужен что-ли? Я формы в дельфи нарисовался по самое не могу (и терпеть не могу это дело). В qt очень просто и приятно все делать ручками. Но уж если захотелось все же что-то наваять в дизайнере, то запускай-не-хочу его как внешнюю прогу.
Наверное, я не так выразился. Дизайнер форм и остальные тулы работают, они ведь и собираются из исходников (то есть не имеют ничего общего с коммерческой версией). Интеграция со студией дизайнера перестает работать. Что не так уж и важно.
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, Kh_Oleg, Вы писали:
K>>>>1. Дорогая (в смысле дорого стоит). S>>>Opensource. K_O>>В OpenSource нет поддержки MSVC и интеграции со студией.
D> Кстати, есть. Только нужно ее правильно собрать Я поставил сперва evalution версию, затем переписал ее открытой, открытую студией же и собрал (небольшой геморр с конфигурированием, но очень небольшой), после чего получил открытую версию qt с интеграцией со студией.
V>Здравствуйте, Kubera, Вы писали: V>А вот над целесообразностью разработки единого пользовательского интерфейса под Mac и под Win нужно десять раз подумать. (Всё таки маковский гуй существенно отличается от виндового.)
V>Даже и думать нечего. Фтопку! "Non-Mac look and feel" — это приговор для программы под Мак.
Здравствуйте, Mamut, Вы писали:
D>> Кстати, есть. Только нужно ее правильно собрать Я поставил сперва evalution версию, затем переписал ее открытой, открытую студией же и собрал (небольшой геморр с конфигурированием, но очень небольшой), после чего получил открытую версию qt с интеграцией со студией.
M>Извращенец здесь
Читал Но я сделал почти все так же, за исключением того, может быть, что не скачивал скрипт, а сам отконфигурил (20 секунд ). Да, и qmake я взял от eval версии, он без ограничений. Ну а потом nmake — и все. Студия у меня, кстати, 2003.
H>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций. S>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых. Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
H>>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций. S>>Я не про то что он легкий/сложный. Я про то что такиеже тормоза. S>Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых.
Смешно.
S>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.
[RSDN@Home][1.2.0][alpha][648]
[Для того, чтобы жить как следует, надо иметь или разум или петлю. [Диоген]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
H>>>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций. S>>>Я не про то что он легкий/сложный. Я про то что такиеже тормоза. S>>Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых. S>Смешно.
S>>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века. S>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.
Здравствуйте, Sheridan, Вы писали:
S>>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века. S>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.
Так он компилируется один раз при первом вызове нескомпилированного метода.
Здравствуйте, Sheridan, Вы писали: S>>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века. S>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.
Смешно.
Непонятно, что значит "в обертке": почему ты не сравниваешь просто управляемый код с неуправляемым?
Непонятно, почему ты делаешь смешные заявления на основе какой-то веры. Есть объективная реальность, есть аргументы в пользу того, чтобы неуправляемый код исполнялся быстрее, есть аргументы в пользу обратного. Я так понимаю, ты себе не дал труда изучить ни те ни другие, зато потешить народ заявлениями типа "жирафов быть просто не может".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка. S>Смешно. S>Непонятно, что значит "в обертке": почему ты не сравниваешь просто управляемый код с неуправляемым? S>Непонятно, почему ты делаешь смешные заявления на основе какой-то веры. Есть объективная реальность, есть аргументы в пользу того, чтобы неуправляемый код исполнялся быстрее, есть аргументы в пользу обратного. Я так понимаю, ты себе не дал труда изучить ни те ни другие, зато потешить народ заявлениями типа "жирафов быть просто не может".
Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно.
Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при:
1. Запуске.
2. Вызове ф-ии из управляемой секции.
3. Вызове ф-ии из неуправляемой секции.
4.1 Закрытии приложения.
4.2 Снятии приложения.
6. Может быть чтото еще.
[RSDN@Home][1.2.0][alpha][648]
[Hе слово, а несчастье есть учитель глупцов. [Демокрит]]
Здравствуйте, Sheridan, Вы писали:
S>Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно. S>Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при: S>1. Запуске. S>2. Вызове ф-ии из управляемой секции. S>3. Вызове ф-ии из неуправляемой секции. S>4.1 Закрытии приложения. S>4.2 Снятии приложения. S>6. Может быть чтото еще.
Вообще-то, Рихтер обо всем этом очень интересно написал. Лучше его почитать, а не пересказ, это правда интересно, рекомендую
Здравствуйте, Demiurg, Вы писали:
D> Вообще-то, Рихтер обо всем этом очень интересно написал. Лучше его почитать, а не пересказ, это правда интересно, рекомендую
За неименеем рихтера... Да и опятьже мне хочется факты. Что. Как. Ибо сколько книг не читал — везде воды дофига. Тотже страуструп и тот тудаже...
[RSDN@Home][1.2.0][alpha][648]
[Брак — и не рай и не ад, это просто чистилище. [А. Линкольн]]
Sheridan wrote: > Что происходит при: > 1. Запуске.
JITинг кода или взятие готового кода из кэша.
> 2. Вызове ф-ии из управляемой секции.
Все что угодно: от отсутствия вызова из-за inlineing'а до запуска JITа,
компиляции функции и выполнения вызова.
> 3. Вызове ф-ии из неуправляемой секции.
Вот тут плохо все. Оверхед на кросс-вызовы получается больше, чем в
случае вызова неуправляемой фнуции.
> 4.1 Закрытии приложения.
Закрытие приложения. А что обязано происходить?
> 4.2 Снятии приложения.
Снятие приложения.
Как показывает практика, хорошие управляемые среды способны создавать
код, в среднем работающий ненамного медленнее компилированного (20-30%).
В некоторых крайних случаях может быть перевес в разы в любую сторону.
Так же практика показывает, что управляемый код в среднем жрет в разы
больше памяти (оверхед на GC, ориентированность на куча и т.п.)
Здравствуйте, Cyberax, Вы писали:
>> 1. Запуске. C>JITинг кода или взятие готового кода из кэша.
Ясно.
>> 2. Вызове ф-ии из управляемой секции. C>Все что угодно: от отсутствия вызова из-за inlineing'а до запуска JITа, C>компиляции функции и выполнения вызова.
Тоже ясно.
>> 3. Вызове ф-ии из неуправляемой секции. C>Вот тут плохо все. Оверхед на кросс-вызовы получается больше, чем в C>случае вызова неуправляемой фнуции.
Это как я понял издержки управляемой среды.
>> 4.1 Закрытии приложения. C>Закрытие приложения. А что обязано происходить?
Ну не знаю... Какие нибудь телодвижения... Типа чтоть скомпилять опять, куданибудь чтото сохранить...
>> 4.2 Снятии приложения. C>Снятие приложения.
Ясно.
C>Как показывает практика, хорошие управляемые среды способны создавать C>код, в среднем работающий ненамного медленнее компилированного (20-30%). C>В некоторых крайних случаях может быть перевес в разы в любую сторону.
C>Так же практика показывает, что управляемый код в среднем жрет в разы C>больше памяти (оверхед на GC, ориентированность на куча и т.п.)
Вот это я и имел ввиду.
Какбы повела себя управляемая среда в этом случае
Здравствуйте, Sheridan, Вы писали:
S>Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно. S>Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при: S>1. Запуске.
Запускается точка входа. Приложение импортирует соответствующий набор DLL из дотнет фреймворк, и передает ему управление. Фреймворк анализирует метаданные основной сборки, определяет адрес управляемой точки входа и передает ей управление. Если управляемый код не был обработан при помощи NGEN, в этот момент активизируется JIT-компилятор. Он компилирует код точки входа в целевую архитектуру, подправляет указатель в соответствующей таблице и передает управление в свежескомпилированный код. S>2. Вызове ф-ии из управляемой секции.
Я не очень понимаю, что ты имеешь в виду под "неуправляемой секцией". Если ты имеешь в виду вызов неуправляемого кода, то система формирует специальный переходник — фрагмент кода, занимающийся согласованием конвенций вызова и прочим маршаллингом. S>3. Вызове ф-ии из неуправляемой секции.
Когда ты отдаешь в неуправляемый код указатель на callbcack, система формирует специальный переходник — фрагмент кода, занимающийся согласованием конвенций вызова и прочим маршаллингом. Фактически в неуправляемый код передается адрес этого переходника, а не управляемой функции. S>4.1 Закрытии приложения.
Ничего интересного. То же самое, что и в нативном приложении. S>4.2 Снятии приложения.
Это довольно сложно, в основном из-за всяких спецэффектов при наличии в стеках потоков как управляемого, так и неуправляемого кода. В идеале: во всех потоках бросается соответствующее исключение, выполняются секции catch и finally, после чего см. п. 4.1. S>6. Может быть чтото еще.
Что-то еще: маршаллинг между управляемым и неуправляемым кодом относительно дорог (относительно вызовов внутри той или иной модели). Это очевидно: сборщик мусора должен быть единственным, кто контролирует управляемые ресурсы. На практике, переходы относительно редки — как правило в стеке вызовов присутствует не более двух переходов, а подавляющее большинство вызовов делается без маршаллинга. Вопросы, связанные со снятием/завершением приложений, можно рассматривать в контексте производительности только в шутку.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
H>>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций. S>>Я не про то что он легкий/сложный. Я про то что такиеже тормоза. S>Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых. S>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
Слишком общее сообщение что бы быть правильным. У C# своя ниша, в которой не только перформанс определяет победителя. Там, где победитель определяется исключительно перформансом алгоритма, у С++ неоспоримое преимущество. Это как раз ниша С++. Так что вывод напрашивается простой.
Здравствуйте, Sheridan, Вы писали:
S>Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно. S>Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при: S>1. Запуске. S>2. Вызове ф-ии из управляемой секции. S>3. Вызове ф-ии из неуправляемой секции. S>4.1 Закрытии приложения. S>4.2 Снятии приложения.
Знамо дело работает интероп и GC. Эти штуки являются в разных условиях как преимуществами так и недостатками.
Люди которые считают интероп и GC исключительно преимуществом в равной степени идиоты как и те, что считают интероп и GC исключительно недостатком.
Интероп, GC + куча etc и разделяют экономические ниши для нативного С++ и C# .Net например.
Спасибо.
Давай теперь посмотрим трезво.
1. Сразу оверхед — анализ метаданных, запуск при небходимости JIT'а.
2. Зачемто какието переходники и согласования вместо прямого выполнения кода. Нет, я понимаю — соблюдаются условия защиты системы от кривизны кода, но мы то сравниваем производительность дотнета и нативного кода.
3. И тут согласования...
4.2 Вот это неплохо, неплохо... Я бы даже сказал очень хорошо.
В общем имеет место быть постоянный контроль кода и ресурсов. Господа но на это же дело ресурсы тоже тратятся?
Или я опять неправ, и весь контроль выполняется "бесплатно"?
Я нив коем случае никого не хочю обидеть. Я хочю понять, отчего все ломанулись в дотнет и C# в частности. Если оттого что программировать легче и проще то согласен, там проще, легче. Но конечным пользователям то не легче. Юзерам приходится покупать железо и софт.
[RSDN@Home][1.2.0][alpha][648]
[Зная, на чем стоишь, хорошо еще понять, куда идешь. [Авессалом Подводный]]
Здравствуйте, Sheridan, Вы писали:
S>1. Сразу оверхед — анализ метаданных, запуск при небходимости JIT'а.
Это даже не милли это микросекунды. Причем только один раз. Так что это не оверхед. S>2. Зачемто какието переходники и согласования вместо прямого выполнения кода. Нет, я понимаю — соблюдаются условия защиты системы от кривизны кода, но мы то сравниваем производительность дотнета и нативного кода.
Переходники нужны для работы с неуправляемым кодом. Внутри управляемого кода никаких переходников нет. Все компилируется в банальные call'ы. S>3. И тут согласования...
Ну а как ты хотел... этоже возьня с неупиравляемым кодом...
S>В общем имеет место быть постоянный контроль кода и ресурсов. Господа но на это же дело ресурсы тоже тратятся? S>Или я опять неправ, и весь контроль выполняется "бесплатно"?
Практически бесплатно.
S>Я нив коем случае никого не хочю обидеть. Я хочю понять, отчего все ломанулись в дотнет и C# в частности. Если оттого что программировать легче и проще то согласен, там проще, легче. Но конечным пользователям то не легче. Юзерам приходится покупать железо и софт.
Как правило купить железо дешевле чем отлавливать тараканы в С++ном коде.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Так же практика показывает, что управляемый код в среднем жрет в разы больше памяти (оверхед на GC, ориентированность на куча и т.п.)
В разы?! Ну да в разы он жрет если памяти много, а вот если памяти мало то управляемое приложение очень быстро ужимается в размерах.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Plutonia Experiment, Вы писали:
PE> Слишком общее сообщение что бы быть правильным. У C# своя ниша, в которой не только перформанс определяет победителя. Там, где победитель определяется исключительно перформансом алгоритма, у С++ неоспоримое преимущество. Это как раз ниша С++. Так что вывод напрашивается простой.
Нет это ниша асма...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Так же практика показывает, что управляемый код в среднем жрет в разы > больше памяти (оверхед на GC, ориентированность на куча и т.п.) > В разы?! Ну да в разы он жрет если памяти много, а вот если памяти мало > то управляемое приложение очень быстро ужимается в размерах.
В разы, в разы. Имел возможность сравнивать.
Во-первых, GC для эффективной работы требует определенный overhead по
объему памяти (процентов 20%-50%). Во-вторых, объекты имеют заголовок,
который занимает размер. В-третьих, ориентированость на кучу —
value-типы используются редко.
Здравствуйте, Cyberax, Вы писали:
C>В разы, в разы. Имел возможность сравнивать.
Что за задача?
C>Во-первых, GC для эффективной работы требует определенный overhead по объему памяти (процентов 20%-50%).
Во во проценты, а не разы.
C>Во-вторых, объекты имеют заголовок, который занимает размер.
+8 байт на объект. Не много.
C>В-третьих, ориентированость на кучу — value-типы используются редко.
И правильно. Если оптимизировать не надо то с reference типами проще, а если надо то можно и value типы использовать. Мне они понадобились лишь один раз.(в смысле написать свой value тип, а не использовать всякие там int'ы)
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Сергей, Вы писали:
С>В C++ для этого есть auto_ptr <>. С>Зачем нужен gc, если есть смарт-пойнтеры?
А они уже научились разруливать циклические ссылки?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
давича решил посмотреть поближе на Paint.NET.
Открылся шустренько, в Таск Менеджер глядел, но не будем об этом
Открыл одну из своих фоток (3,64 Мб). Открывалась хоть и с прогрессом — но быстро.
Потом решил воспользоваться эффектами и добавить Gaussian Blur. Увидел всю мощь программы — этот эффект добавлялся построчно.
WolfHound wrote: > C>В разы, в разы. Имел возможность сравнивать. > Что за задача?
Одно приложение для обработки и представления данных в двух версиях — на
C# и С++.
> C>Во-первых, GC для эффективной работы требует определенный overhead по > объему памяти (процентов 20%-50%). > Во во проценты, а не разы.
Ну так проценты имеют свойство накапливаться.
> C>Во-вторых, объекты имеют заголовок, который занимает размер. > +8 байт на объект. Не много.
В С++ от 0 до 4.
> C>В-третьих, ориентированость на кучу — value-типы используются редко. > И правильно. Если оптимизировать не надо то с reference типами проще, а > если надо то можно и value типы использовать. Мне они понадобились лишь > один раз.(в смысле написать свой value тип, а не использовать всякие там > int'ы)
Ну вот в этом и проблема — в результате общего неэффективного расхода
памяти проценты и набегают.
Вас послушать — так там совсем всё хорошо. Программировать под .net мне пока не доводилось, так что могу судить об этом только из разного рода литературы, мнений на форумах и опыта работы с такими приложениями.
Видел я их всего пока 3 (три) штуки: это RSDN@Home, интерфейс к драйверам под ATI-видюхи и конфигурилка для GeoShell'a. Больше всего впечатлений у меня осталось от последнего пункта. Замечено, что:
1) запускается примерно как OpenOffice, 5 секунд.
2) памяти лопает примерно как Opera (14(!)Мб)
3) перерисовка интерфейса тормозит примерно как Winamp5 с modern-скином.
4) частенько падает...
Аналогичная программа Win32 хавала бы примерно 400 кб памяти и запускалась бы мгновенно.
Напомню, что одно из преимущетв технологии .net — упрощение разработки программ и повышение ее надежности. Где же это упрощение разработки и повышение надежности, если программа а) тормозит и жрет память как слон б) падает ? Вывод: чтобы писать качественные программы с использованием .net, нужно это дело плотно изучать. Человек с низкой квалификацией вряд ли сделает качественную и надежную программу даже на .net'e. Похоже на Delphi — начать программировать проще, чем на С++, но для того, чтобы разработать качественную программу, знать нужно не меньше. По моему, только станет больше дилетантских программ (а-ля кривые поделки на Delphi).
RSDN@Home падал меньше, лучше всего работала АТИ-шная приблуда.
Мне, как пользователю, все равно, на чем написана программа, лишь бы работала хорошо. Таких .НЕТ-программ я пока не видел, хотя с момента начала раскрутки дотнета прошел не один год.
WolfHound wrote: > С>В C++ для этого есть auto_ptr <>. > С>Зачем нужен gc, если есть смарт-пойнтеры? > А они уже научились разруливать циклические ссылки?
Да, причем очень просто. Просто достаточно не делать циклические ссылки
Здравствуйте, Cyberax, Вы писали:
C>Одно приложение для обработки и представления данных в двух версиях — на C# и С++.
Информации 0.
Кстати а свободной памяти на машине сколько было?
Просто если памяти было много то ГЦ ее всю и утилизировал чтобы лишний раз мусор не собирать.
C>Ну так проценты имеют свойство накапливаться.
Куда накапливатся?
C>В С++ от 0 до 4.
Для value типов тоже 0.
C>Ну вот в этом и проблема — в результате общего неэффективного расхода памяти проценты и набегают.
Куда набегают?
Короче кудабы они не бежали в разы всеравно не получается. За исключением того случая когда на машине много свободной памяти...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Вертер, Вы писали:
В>давича решил посмотреть поближе на Paint.NET. В>Открылся шустренько, в Таск Менеджер глядел, но не будем об этом
А памяти на машине было гиг или может два?... Кстати фотошоп у меня сожрал больше памяти...
В>Открыл одну из своих фоток (3,64 Мб). Открывалась хоть и с прогрессом — но быстро. В>Потом решил воспользоваться эффектами и добавить Gaussian Blur. Увидел всю мощь программы — этот эффект добавлялся построчно.
В>XnView всё это делает «немного» быстрее
А причем тут .NET?
Тут некоторое время назад великий и ужасный McSeem2 пытался наезжать на .NET что он тормозной но даже у него не получилось сделать код
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Вертер, Вы писали:
В>>давича решил посмотреть поближе на Paint.NET. В>>Открылся шустренько, в Таск Менеджер глядел, но не будем об этом WH>А памяти на машине было гиг или может два?... Кстати фотошоп у меня сожрал больше памяти...
да фиг с этой памятью, если поверить, что GC отдаст память сразу, как системе понадобиться.
В>>Открыл одну из своих фоток (3,64 Мб). Открывалась хоть и с прогрессом — но быстро. В>>Потом решил воспользоваться эффектами и добавить Gaussian Blur. Увидел всю мощь программы — этот эффект добавлялся построчно.
В>>XnView всё это делает «немного» быстрее WH>А причем тут .NET?
так эффекты то Paint.NET сам рисовал, сдаётся мне, использую алгоритм, реализованный на дотНЕТ. То есть получается, что выполнение сложного алгоритма на дотНЕТ не выгодно (в конкретном примере)...
WH>Тут некоторое время назад великий и ужасный McSeem2 пытался наезжать на .NET что он тормозной но даже у него не получилось сделать код
Здравствуйте, Cyberax, Вы писали:
C>Да, причем очень просто. Просто достаточно не делать циклические ссылки
Иногда для этого приходится думать очень очень много и городить такие огороды что уж лучше был бы ГЦ. Уж точно проще и надежней и наверняка оверхед меньше.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Сергей, Вы писали:
С>Вас послушать — так там совсем всё хорошо. Программировать под .net мне пока не доводилось, так что могу судить об этом только из разного рода литературы, мнений на форумах и опыта работы с такими приложениями.
Вот когда доведется... причем что ни будь серьезное и лучше в комманде с опытными .NET'чиками...
С>Видел я их всего пока 3 (три) штуки: это RSDN@Home,
Все томоза RSDN@Home растут из базы данных написанной на C++... Вывод?... С>интерфейс к драйверам под ATI-видюхи и конфигурилка для GeoShell'a. Больше всего впечатлений у меня осталось от последнего пункта. Замечено, что: С>1) запускается примерно как OpenOffice, 5 секунд.
Например Paint.NET запускается примерно с тойже скоростью что Paint. Ну может четь медленней. С>2) памяти лопает примерно как Opera (14(!)Мб)
Особенности работы ГЦ. В форуме .NET на эту тему есть пара флеймов Память и .Net
Короче не так страшен черт как его пытается малевать Pavel Dvorkin
С>3) перерисовка интерфейса тормозит примерно как Winamp5 с modern-скином.
Не знаю что они там наворотили у меня на скорость ГУИ приложений .NET нареканий нет. С>4) частенько падает...
Радиус кривизну рук "программистов" ATI помойму уже давно лешенда. С>Аналогичная программа Win32 хавала бы примерно 400 кб памяти и запускалась бы мгновенно.
Они бы ее вобще недописали. С>Напомню, что одно из преимущетв технологии .net — упрощение разработки программ и повышение ее надежности.
Именно. С>Где же это упрощение разработки и повышение надежности, если программа С>а) тормозит и жрет память как слон
Это как написать... Могут быть варианты когда программа на .NET работает быстрее чем программа на С++. См например System.Reflection.Emit и то как он использован в BLToolkit
Как сделать что-то подобное на С++ я даже представить боюсь объем и сложность работы. С>б) падает ?
Руки... С>Вывод: чтобы писать качественные программы с использованием .net, нужно это дело плотно изучать. Человек с низкой квалификацией вряд ли сделает качественную и надежную программу даже на .net'e. Похоже на Delphi — начать программировать проще, чем на С++, но для того, чтобы разработать качественную программу, знать нужно не меньше. По моему, только станет больше дилетантских программ (а-ля кривые поделки на Delphi).
А кто спорит? С>RSDN@Home падал меньше, лучше всего работала АТИ-шная приблуда.
Кстати RSDN@Home лучшее доказательство того что .NET таки рулит ибо
1)До сих пор нет аналога на С++
2)Его писали люди очень разной квалификации... С>Мне, как пользователю, все равно, на чем написана программа, лишь бы работала хорошо. Таких .НЕТ-программ я пока не видел, хотя с момента начала раскрутки дотнета прошел не один год.
Ну так на нем пишут в основном корпаративный софт и серверы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Вертер, Вы писали:
В>так эффекты то Paint.NET сам рисовал, сдаётся мне, использую алгоритм, реализованный на дотНЕТ. То есть получается, что выполнение сложного алгоритма на дотНЕТ не выгодно (в конкретном примере)...
В данном конкретном случае авторам нужно выправить руки.
В>так кто бы спорил, просто утверждается, что на дотНЕТ так всё просто, что ни о чём и думать то не надо — только полёт свободной мысли
Кто утверждает? Говорят о том что там проще чем на С++.
В>Как пример: В>
WH>В данном конкретном случае авторам нужно выправить руки.
заметь, они писали прогу под патронажем МС
В>>так кто бы спорил, просто утверждается, что на дотНЕТ так всё просто, что ни о чём и думать то не надо — только полёт свободной мысли WH>Кто утверждает? Говорят о том что там проще чем на С++.
когда пишешь на С++ — априори надо сначала думать, а потом писать.
В>>Как пример: В>>
Здравствуйте, Вертер, Вы писали:
В>так кто бы спорил, просто утверждается, что на дотНЕТ так всё просто, что ни о чём и думать то не надо — только полёт свободной мысли В>Как пример: В>
Здравствуйте, WolfHound, Вы писали:
WH>Вот когда доведется... причем что ни будь серьезное и лучше в комманде с опытными .NET'чиками...
Посмотрим, может и придется. WH>Все томоза RSDN@Home растут из базы данных написанной на C++... Вывод?...
Что-ж не на .NET'e, если там все так хорошо?
С>>1) запускается примерно как OpenOffice, 5 секунд. С>>2) памяти лопает примерно как Opera (14(!)Мб) С>>3) перерисовка интерфейса тормозит примерно как Winamp5 с modern-скином. С>>4) частенько падает...
Эти 4 пункта — про конфигурилку к GeoShell'у.
WH>Радиус кривизну рук "программистов" ATI помойму уже давно легенда.
Да вот из попадавших ко мне экземпляров их поделие работало лучше всего.
С>>Аналогичная программа Win32 хавала бы примерно 400 кб памяти и запускалась бы мгновенно. WH>Они бы ее вобще недописали.
Если это вы про конфигурилку, то показываю скриншот (8кб):
Еще столько же контролов на второй вкладке. Это, собственно, и все. Да: не дописана сия утилита еще пока у них Кстати, у того же GeoShella есть утилитка для смены скина и тому подобных параметров внешнего вида. Превьюшки всякие показывает, на ходу применяет все изменения в ГеоШелле. Не глючит, не падает, все дописано, памяти хавает 1.3 метра и не дотнет.
WH>Это как написать... Могут быть варианты когда программа на .NET работает быстрее чем программа на С++. См например System.Reflection.Emit и то как он использован в BLToolkit WH>Как сделать что-то подобное на С++ я даже представить боюсь объем и сложность работы.
Боюсь, не могу оценить масштаб затеи.
WH>Ну так на нем пишут в основном корпоративный софт и серверы.
А я вот к чему клоню: чтобы правильно применять дотнет использовать его преимущества нужно хорошо его изучить и иметь хорошую квалификацию. Ничего революционного, просто еще одна платформа для разработки приложений, чем-то хуже и чем-то лучше других. Имхо, заявления (которых я видел немало на просторах инета), что скоро будет только дотнет и посему будет всем щастье, весьма опрометчивы.
Здравствуйте, Сергей, Вы писали:
WH>>Все томоза RSDN@Home растут из базы данных написанной на C++... Вывод?... С>Что-ж не на .NET'e, если там все так хорошо?
Те ручками написать СУБД? Для читалки форумов которую пишут в свободное от работы, семьи и интересной книжки время? А не слишком круто?
С>А я вот к чему клоню: чтобы правильно применять дотнет использовать его преимущества нужно хорошо его изучить и иметь хорошую квалификацию. С>Ничего революционного, просто еще одна платформа для разработки приложений, чем-то хуже и чем-то лучше других.
А кто с этим спорит?
С>Имхо, заявления (которых я видел немало на просторах инета), что скоро будет только дотнет и посему будет всем щастье, весьма опрометчивы.
Ну тоже самое говорили про Жабу...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Все томоза RSDN@Home растут из базы данных написанной на C++... Вывод?... С>>интерфейс к драйверам под ATI-видюхи и конфигурилка для GeoShell'a. Больше всего впечатлений у меня осталось от последнего пункта. Замечено, что: С>>1) запускается примерно как OpenOffice, 5 секунд. WH>Например Paint.NET запускается примерно с тойже скоростью что Paint. Ну может четь медленней.
И примерно в 10 раз быстрее, чем Photoshop с аналогичным набором фильтров. С>>4) частенько падает... WH>Радиус кривизну рук "программистов" ATI помойму уже давно лешенда.
Это, кстати, вообще проблема. Железячные компании постоянно отдают на рынок такой софт, что хоть стой хоть падай. С>>Аналогичная программа Win32 хавала бы примерно 400 кб памяти и запускалась бы мгновенно. WH>Они бы ее вобще недописали.
Совершенно верно. "Аналогичная" программа на win32 просто бы не запустилась.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sheridan, Вы писали:
S>>1. Сразу оверхед — анализ метаданных, запуск при небходимости JIT'а. WH>Это даже не милли это микросекунды. Причем только один раз. Так что это не оверхед.
ок
S>>2. Зачемто какието переходники и согласования вместо прямого выполнения кода. WH>Переходники нужны для работы с неуправляемым кодом. Внутри управляемого кода никаких переходников нет. Все компилируется в банальные call'ы. S>>3. И тут согласования... WH>Ну а как ты хотел... этоже возьня с неупиравляемым кодом...
ok
S>>В общем имеет место быть постоянный контроль кода и ресурсов. Господа но на это же дело ресурсы тоже тратятся? S>>Или я опять неправ, и весь контроль выполняется "бесплатно"? WH>Практически бесплатно.
гм...
S>> Но конечным пользователям то не легче. Юзерам приходится покупать железо и софт. WH>Как правило купить железо дешевле чем отлавливать тараканы в С++ном коде.
Позволь, но тут я не соглашусь. Это программистам дешевле, а не пользователям.
[RSDN@Home][1.2.0][alpha][648]
[Hарод, который поет и пляшет, зла не думает. [Екатерина II]]
Здравствуйте, Sheridan, Вы писали:
WH>>Как правило купить железо дешевле чем отлавливать тараканы в С++ном коде. S>Позволь, но тут я не соглашусь. Это программистам дешевле, а не пользователям.
Здравствуйте, WolfHound, Вы писали:
С>>Видел я их всего пока 3 (три) штуки: это RSDN@Home, WH>Все томоза RSDN@Home растут из базы данных написанной на C++... Вывод?...
Надо менять движок. Что то двинулись в сторону firebird да так и не освоили...
С>>1) запускается примерно как OpenOffice, 5 секунд. WH>Например Paint.NET запускается примерно с тойже скоростью что Paint. Ну может четь медленней.
Угу, там четь, тут четь, здесь четь...
С>>Напомню, что одно из преимущетв технологии .net — упрощение разработки программ и повышение ее надежности. WH>Именно.
Это одно единственное преимущество дотнета. Но огромное!
С>>Где же это упрощение разработки и повышение надежности, если программа С>>а) тормозит и жрет память как слон WH>Это как написать... Могут быть варианты когда программа на .NET работает быстрее чем программа на С++. См например System.Reflection.Emit и то как он использован в BLToolkit
Вот именно что могут быть. Зависит от специфики задачи.
С>>б) падает ? WH>Руки...
...ноги, голова, но только не дотнет...
С>>Вывод: чтобы писать качественные программы с использованием .net, нужно это дело плотно изучать. Человек с низкой квалификацией вряд ли сделает качественную и надежную программу даже на .net'e. Похоже на Delphi — начать программировать проще, чем на С++, но для того, чтобы разработать качественную программу, знать нужно не меньше. По моему, только станет больше дилетантских программ (а-ля кривые поделки на Delphi). WH>А кто спорит?
Странно, обычно дотнетчики обижаются. Респект за понимание.
С>>RSDN@Home падал меньше, лучше всего работала АТИ-шная приблуда. WH>Кстати RSDN@Home лучшее доказательство того что .NET таки рулит ибо WH>1)До сих пор нет аналога на С++
Проект стартовал и неспеша крутится.
WH>2)Его писали люди очень разной квалификации...
Под чутким руководством ведущих специалистов.
С>>Мне, как пользователю, все равно, на чем написана программа, лишь бы работала хорошо. Таких .НЕТ-программ я пока не видел, хотя с момента начала раскрутки дотнета прошел не один год. WH>Ну так на нем пишут в основном корпаративный софт и серверы.
Бедные компании... Наверно с каждым релизом дотнета парк серверов обновляют...
[RSDN@Home][1.2.0][alpha][648]
[Люди не в состоянии изменить свою природу. [Д. Юм]]
WH>>Например Paint.NET запускается примерно с тойже скоростью что Paint. Ну может четь медленней. S>И примерно в 10 раз быстрее, чем Photoshop с аналогичным набором фильтров.
WolfHound wrote: > C>Одно приложение для обработки и представления данных в двух версиях — > на C# и С++. > Информации 0. > Кстати а свободной памяти на машине сколько было? > Просто если памяти было много то ГЦ ее всю и утилизировал чтобы лишний > раз мусор не собирать.
Проблема в том, что сначала версию написали на C# — при больших объемах
данных памяти не хватало. Потом версию на C# пооптимизировали
слегка (воткнув val-типы), но памяти все равно постоянно не хватало.
В итоге написали в доке, что версия на C# должна использоваться на WinXP64.
В версии на С++, которая делала то же самое (с точностью до
пунктов меню) памяти требовалось примерно в три раза меньше.
Работали обе версии, кстати, с примерно одинаковой скоростью. C# в паре
тестов вырывался вперед, в целом C++ обычно был процентов на 10-20% быстрее.
> C>Ну так проценты имеют свойство накапливаться. > Куда накапливатся?
В расходуемую память
> C>В С++ от 0 до 4. > Для value типов тоже 0.
Перечислите ограничения для неbox-нутых val-типов.
> Короче кудабы они не бежали в разы всеравно не получается. За > исключением того случая когда на машине много свободной памяти...
"Свободной памяти" не существует — существует место для кэша диска.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Вертер, Вы писали:
В>>так кто бы спорил, просто утверждается, что на дотНЕТ так всё просто, что ни о чём и думать то не надо — только полёт свободной мысли В>>Как пример: В>>
Варианты такие:
1. может быть дырка между адресами L_0000 и L_0005 так как команда ldstr не занимает 5 байт
2. может быть вместо stloc.0 должно быть stloc.1
WolfHound wrote: > C>Да, причем очень просто. Просто достаточно не делать циклические ссылки > Иногда для этого приходится думать очень очень много и городить такие > огороды что уж лучше был бы ГЦ. Уж точно проще и надежней и наверняка > оверхед меньше.
Я тоже так думал несколько лет назад Даже в ФИДО спорил по этому поводу.
Теперь я написал пару программ с нетривиальным сроком жизни объектов.
Время, потраченое на продумывание системы владения объектами,
многократно окупилось из-за улучшений архитекутуры, которые получились
из-за продумывания системы владения.
Программы, где без GC не обойтись, все же есть, но их не так уж и много.
Это разные компиляторы (где политики владения выделить сложно),
серверные системы (где надежнее использовать GC и плевать на несколько
процентов производительности).
Здравствуйте, Sheridan, Вы писали:
S>Угу, там четь, тут четь, здесь четь...
Фотошоп стартует раз в 10 медленней... выводы?
S>Это одно единственное преимущество дотнета. Но огромное!
Рад что ты это понимаешь. Теперь осталось понять что недостатки далеко не такие большие как ты их патаешься раздуть.
S>Вот именно что могут быть. Зависит от специфики задачи.
Вот только что-то очень часто мне такие задачи попадаются...
WH>>Руки... S>...ноги, голова, но только не дотнет...
Если написано на нете да еще и падает... то точно руки.
S>Странно, обычно дотнетчики обижаются. Респект за понимание.
А кто сказал что я дотнетчик?
Я в отличии от некоторых владею многими технологиями.
S>Проект стартовал и неспеша крутится.
Удачи.
WH>>Ну так на нем пишут в основном корпаративный софт и серверы. S>Бедные компании... Наверно с каждым релизом дотнета парк серверов обновляют...
Если так то очень глупые компании ибо каждый следующий релиз дотнета работает быстрее.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что сначала версию написали на C# — при больших объемах C>данных памяти не хватало. Потом версию на C# пооптимизировали C>слегка (воткнув val-типы), но памяти все равно постоянно не хватало.
А что за задача?
C>В итоге написали в доке, что версия на C# должна использоваться на WinXP64.
C>В версии на С++, которая делала то же самое (с точностью до C>пунктов меню) памяти требовалось примерно в три раза меньше.
Иначе чем алгоритмическими оптимизациями объяснить не могу. Или может у вас были миллиона мелких объектов и ручной менеджер памяти для С++?
C>Перечислите ограничения для неbox-нутых val-типов.
А какие именно тебе мешают?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
S>>Угу, там четь, тут четь, здесь четь... WH>Фотошоп стартует раз в 10 медленней... выводы?
Написать фотошоп на дотнете и затестить?
S>>Это одно единственное преимущество дотнета. Но огромное! WH>Рад что ты это понимаешь. Теперь осталось понять что недостатки далеко не такие большие как ты их патаешься раздуть.
Увы... Преимущество дотнета есть и остается в удобстве программирования. Даже поддержка уже прихрамывает... Тут fm1.1, там нужен 2.0...
S>>Вот именно что могут быть. Зависит от специфики задачи. WH>Вот только что-то очень часто мне такие задачи попадаются...
все может быть. Даже то что я неправ.
WH>>>Руки... S>>...ноги, голова, но только не дотнет... WH>Если написано на нете да еще и падает... то точно руки. если падает то да, а если тормозит?
S>>Странно, обычно дотнетчики обижаются. Респект за понимание. WH>А кто сказал что я дотнетчик? WH>Я в отличии от некоторых владею многими технологиями.
Это радует.
S>>Проект стартовал и неспеша крутится. WH>Удачи.
Спасибо...
WH>>>Ну так на нем пишут в основном корпаративный софт и серверы. S>>Бедные компании... Наверно с каждым релизом дотнета парк серверов обновляют... WH>Если так то очень глупые компании ибо каждый следующий релиз дотнета работает быстрее.
Ясное дело быстрее, железо то новое
[RSDN@Home][1.2.0][alpha][648]
[Hе всякому человеку даже гусарский мундир к лицу. [К. Прутков]]
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, WolfHound, Вы писали:
>>[...]
С>Вас послушать — так там совсем всё хорошо. Программировать под .net мне пока не доводилось, так что могу судить об этом только из разного рода литературы, мнений на форумах и опыта работы с такими приложениями.
Кстати задумался. Влад, какие ты мог бы предложить приложения на .Net для end-userа?
WolfHound wrote: > C>Проблема в том, что сначала версию написали на C# — при больших объемах > C>данных памяти *не хватало*. Потом версию на C# пооптимизировали > C>слегка (воткнув val-типы), но памяти все равно постоянно не хватало. > А что за задача?
Обработка данных профиля поверхности. Там сэмплы в 10000х10000 точек —
вполне нормальное явление.
> C>В версии на С++, которая делала *то же самое* (с точностью до > C>пунктов меню) памяти требовалось примерно в три раза меньше. > Иначе чем алгоритмическими оптимизациями объяснить не могу.
Оптимизаций там практически не было — я их код перелопачивал лично.
> Или может у вас были миллиона мелких объектов и ручной менеджер > памяти для С++?
Нет, были миллионы стековых объектов. Специальные менеджеры
использовались, но только для работы с несколькими большими (сотни
мегабайт) массивами.
> C>Перечислите ограничения для неbox-нутых val-типов. > А какие именно тебе мешают?
Нет эффективного способа передачи value-типов по ссылке. Ну и по мелочам
напрягала невозможность наследования и реализации интерфейсов (на
незабоксированых типах) — приходилось писать один и тот же код несколько
раз для разных типов.
Здравствуйте, WolfHound, Вы писали:
S>>Позволь, но тут я не соглашусь. Это программистам дешевле, а не пользователям. WH>А кто плавит программистам?
Директор и бухгалтерия .
На самом деле конечно все зависит от конторы.
Есть 4 типа контор...
1 — все шустренько ставится, работает, бесплатно но поддержки нет
2 — все ставится, работает, настраивается но поддержка слабая — софт в районе 0-100$
3 — с трудом ставится, настраивается припомощи техподдержки после 2х литров пива, потом работает — софт в районе 1000-5000$
4 — и софт с 7-8 тыщ нифига не ставится, не работает но за такие бабки техподдержка приедет, поставит, подключит и все будет работать.
Так вот, дотнет имхо это часто 3,4
[RSDN@Home][1.2.0][alpha][648]
[Быть добрым совсем нетрудно: трудно быть справедливым. [В. Гюго]]
Здравствуйте, Cyberax, Вы писали:
C>Обработка данных профиля поверхности. Там сэмплы в 10000х10000 точек — вполне нормальное явление.
А что мешало сделать это массивом value типов?
C>Нет эффективного способа передачи value-типов по ссылке.
void Foo(ref SomeValueType vt)
{
}
Ы? C>Ну и по мелочам напрягала невозможность наследования и реализации интерфейсов (на незабоксированых типах) — приходилось писать один и тот же код несколько раз для разных типов.
void Foo<T>(ref T vt)
where T : ISomeInterface
{
}
Ы?
Или был первый фреймворк?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sheridan, Вы писали:
WH>>Если так то очень глупые компании ибо каждый следующий релиз дотнета работает быстрее. S>Ясное дело быстрее, железо то новое
Все ясно. Я с тролями не разговариваю.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Обработка данных профиля поверхности. Там сэмплы в 10000х10000 точек — > вполне нормальное явление. > А что мешало сделать это массивом value типов?
С этим проблем нет (оно так и сделано было, собственно). Эти сэмплы же
еще и обрабатывать надо.
> C>Нет эффективного способа передачи value-типов по ссылке. > void Foo(ref SomeValueType vt) > { > }
См. выделенное.
> Ы?
Происходит боксирование типа -> аллокация на куче (нет, JIT его не
оптимизирует).
> C>Ну и по мелочам напрягала невозможность наследования и реализации > интерфейсов (на незабоксированых типах) — приходилось писать один и тот > же код несколько раз для разных типов. > void Foo<T>(ref T vt) > where T : ISomeInterface > { > } > Ы?
См. выделенное.
> Или был первый фреймворк?
Первый, потом стал второй. Разницы особой нет.
Здравствуйте, WolfHound, Вы писали:
WH>>>Если так то очень глупые компании ибо каждый следующий релиз дотнета работает быстрее. S>>Ясное дело быстрее, железо то новое WH>Все ясно. Я с тролями не разговариваю.
Да, qt мне довольно нравится.
[RSDN@Home][1.2.0][alpha][648]
[Кто в верности не клялся никогда, тот никогда ее и не нарушит. [А. Платен]]
Здравствуйте, WolfHound, Вы писали:
WH>Информации 0. WH>Кстати а свободной памяти на машине сколько было? WH>Просто если памяти было много то ГЦ ее всю и утилизировал чтобы лишний раз мусор не собирать.
Немного не в тему, но что мне оперативку некуда девать? Вот под линуксом вся свободная оперативка на кешь дисковых операций идет. На медленных носителях эффект поразительный (у меня ее 1 Гб, на кэш ок. 700 Мб идет). Так если каждое приложение начнет расти и себе ее хватать, то для других целей ее не останется. Плохо.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Sheridan, Вы писали:
S>>Так вот, дотнет имхо это часто 3,4
S>ironwit глядя на твой минус я понимаю что был всетаки прав и дотнет тянет только на 1,2 но никак на 3,4
не очень понял такую хитро закрученную фразу.. Я больше логичные строю, на паскале S>Спасибо.
та не за что За тобой очень увлекательно наблюдать
Здравствуйте, ironwit, Вы писали:
S>>>Так вот, дотнет имхо это часто 3,4
S>>ironwit глядя на твой минус я понимаю что был всетаки прав и дотнет тянет только на 1,2 но никак на 3,4 I>не очень понял такую хитро закрученную фразу.. Я больше логичные строю, на паскале
Ну первоначально я оценил дотнет как инструмент для крупных проектов. Ты со мной не согласился...
S>>Спасибо. I>та не за что За тобой очень увлекательно наблюдать
Надеюсь не для того чтобы повеселиться...
[RSDN@Home][1.2.0][alpha][648]
[Hастоящее горе стыдливо. [Ф. Геббель]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, ironwit, Вы писали:
I>>та не за что За тобой очень увлекательно наблюдать S>Надеюсь не для того чтобы повеселиться...
ну что ты, как можно
Я все еще жду кроссплатформенный янус в котором будет фич побольше чем в текущем и вносится они будут побыстрее
Здравствуйте, ironwit, Вы писали:
I>Я все еще жду кроссплатформенный янус в котором будет фич побольше чем в текущем и вносится они будут побыстрее
Ну а чтоже ты... http://sheridan.stavcom.ru/wiki/index.php?n=Main.HomePage
Вливайся может что подскажеж...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, ironwit, Вы писали:
I>>Я все еще жду кроссплатформенный янус в котором будет фич побольше чем в текущем и вносится они будут побыстрее S>Ну а чтоже ты... S>http://sheridan.stavcom.ru/wiki/index.php?n=Main.HomePage S>Вливайся может что подскажеж...
там слова rsdn нет прокси не пустит
Здравствуйте, Cyberax, Вы писали:
>> C>Нет эффективного способа передачи value-типов по ссылке. >> void Foo(ref SomeValueType vt) >> { >> } C>См. выделенное.
>> Ы? C>Происходит боксирование типа -> аллокация на куче (нет, JIT его не C>оптимизирует).
Смотри выделенное — не смотри, а никакого боксинга в данном случае не происходит — факт.
>> C>Ну и по мелочам напрягала невозможность наследования и реализации >> интерфейсов (на незабоксированых типах) — приходилось писать один и тот >> же код несколько раз для разных типов. >> void Foo<T>(ref T vt) >> where T : ISomeInterface >> { >> } >> Ы? C>См. выделенное.
Здесь — тем более. Я сам проводил замеры и неоднократно. Никакого боксинга и в этом случае не происходит. Причем JIT зачастую инлайнит вызываемый метод, так что по сравнению с вызовом интерфейсного метода выигрыш может быть десятикратным.
>> Или был первый фреймворк? C>Первый, потом стал второй. Разницы особой нет.
FW 1.1 и FW 2.0 — небо и земля. Лично у меня обратное утверждение автоматически вызывает сомнение в компетентности того, кто, собственно, обратное и утверждает. В данном вопросе, разумеется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
WolfHound wrote: > Где здесь боксинг?
Торможу, немного другое имел в виду.
Ладно, вот реальная ситуация:
Стандартный способ задания сеток в трехмерных программах — массив вершин
и массив треугольников. Для алгоритма обработки еще нужно иметь
информацию о соседях каждого треугольника.
Теперь, как нам это портировать на C#? vector3 и vertex, понятно,
становится val-типами. Но как представить треугольник, не делая его классом?
Мы сделали примерно так:
struct Triangle
{
public long point1,point2,point3;
public long tri1,tri2,tri3;
};
При этом point1,point2... становятся индексами, а не указателями. Но не
все точки и треугольники лежат в одном массиве, так что в старшем байте
индекса кодируется еще и индекс массива.
WolfHound wrote: > А почему long? Разве у вас есть массивы в которых больше int.MaxValue > элементов? Сомневаюсь.
Один байт нужен для индекса массива. И 3 остающихся байт уже совсем
недостаточно.
Размеры, кстати, на некоторых тестах уже подбираются к половине
миллиарда. Так что граница int'а уже не за горами.
> И какой смысл в нескольких массивах вертексов?
Есть изначальный массив вершин (сэмпл размером 10000х10000).
В процессе обработки создаются промежуточные вершины и треугольники. В
исходный массив их пихать нельзя, поэтому они кладутся во временные
массивы. Поэтому и невозможно обойтись единым индексом.
Здравствуйте, Cyberax, Вы писали:
C>Один байт нужен для индекса массива. И 3 остающихся байт уже совсем недостаточно.
А почему тогда не так:
struct Triangle
{
public int point1,point2,point3;
public int tri1,tri2,tri3;
public byte point1_arr,point2_arr,point3_arr;
public byte tri1_arr,tri2_arr,tri3_arr;
};
Ы?
Вот мы и сэкономили по 3 байта на индекс.
Итого: 3 * 6 — 2(на выравнивание) = 16 байт экономии на структуру
C>Размеры, кстати, на некоторых тестах уже подбираются к половине миллиарда. Так что граница int'а уже не за горами.
Если перейти границу int то тут уж точно без 64х битной архитектуры не обойтись.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Один байт нужен для индекса массива. И 3 остающихся байт уже совсем > недостаточно. > А почему тогда не так: > struct Triangle > { > public int point1,point2,point3; > public int tri1,tri2,tri3; > public byte point1_arr,point2_arr,point3_arr; > public byte tri1_arr,tri2_arr,tri3_arr; > }; > Ы?
Не подумали Хотя мне кажется, что сильно больших улучшений не даст.
> C>Размеры, кстати, на некоторых тестах уже подбираются к половине > миллиарда. Так что граница int'а уже не за горами. > Если перейти границу int то тут уж точно без 64х битной архитектуры не > обойтись.
В 4Гб оно уже не вмешается на C# при больших сэмплах — так что 64 бита
уже в requirements'ах. Версия на С++ намного более эффективна, кстати.
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Здравствуйте, Вертер, Вы писали:
В>1. может быть дырка между адресами L_0000 и L_0005 так как команда ldstr не занимает 5 байт
Ну да, конечно. однобайтовый опкод + 4-байтный токен строки ну никак не равен 5 В>2. может быть вместо stloc.0 должно быть stloc.1
Для статического метода не может
Здравствуйте, Mace Windu, Вы писали:
MW>Здравствуйте, Вертер, Вы писали:
В>>1. может быть дырка между адресами L_0000 и L_0005 так как команда ldstr не занимает 5 байт MW>Ну да, конечно. однобайтовый опкод + 4-байтный токен строки ну никак не равен 5 В>>2. может быть вместо stloc.0 должно быть stloc.1 MW>Для статического метода не может
хм, а почему же -1 то?
Сам же писал, что:
L>Найдешь проблему — поставлю 3 балла.
про остальное — ни слова
В ответ на реплику, я написал: «совсем не селён в IL асме, а тем более в дотНЕТе». Реакция на мою попытку непонятна, ну да ладно...
Здравствуйте, Sheridan, Вы писали:
S>Засел я тут на выходных попробовать в кутэ попрограммить... S>Довольно понравилось... Интерфейс руками накидать — как 2 пальца, отослать чтото из потока кудато еще — как 2 пальца... Технология сигнал-слот вообще супер! Практически все что надо охватывается функциями самой Qt, а это уже реальная кроссплатформенность. В общем мне понравился кутэ. Welcome...
Windows Forms для .NET
Qt для C++
Каждому свое. Иначе давайте обсуждать http vs ftp или что-нибудь в этом духе
Здравствуйте, Sheridan, Вы писали:
С>>>RSDN@Home падал меньше, лучше всего работала АТИ-шная приблуда. WH>>Кстати RSDN@Home лучшее доказательство того что .NET таки рулит ибо WH>>1)До сих пор нет аналога на С++ S>Проект стартовал и неспеша крутится.
Че-то не открывается.
1.1.4 stable rev. 510
"Всё что не убивает нас, делает нас сильнее..."
