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

C>d Bratik пишет:

>> G>чего они от тебя НЕ ждут (ведь ты же не имеешь привычки кидать
>> исключения из деструктора?)
>> G>И вообще, многопоточность — это отдельная песня. С каждой
>> библиотекой можно работать в многопоточной среде, просто надо соблюдать
>> G>ряд правил для этого. STL вон тоже не многопоточная если на то пошло...
>> Речь идет о моногопоточном, exception-safe GUI. Мне это позарез нужно.
>> Таких библиотек (промышленных) только две: .NET framework и VCL (там
>> все хуже, но все равно есть).

C>ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
C>можно использовать в многотредовом окружении, точно так же как и: MFC,
C>WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
C>нужный поток или используя только их потокобезопасное подмножество.

Вы хоть раз Qt на Солярке пускали? Там Qt (по собственнной вине и по вине X11) по определению с многопоточностью не дружит (впрочем, разработчики Солярки вообще с головой не дружат, так что создателям Qt есть на кого пальцем тыкать).

C>Ну а в качестве exception-safe — чем MFC или WTL не нравится?

В моем инструментальном ящике этому отстою нету места. Если мне нужно будет сделать программу для Windows, я не раздумывая возьму Delphi и VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать программу для Solaris и Linux (и в последнюю очередь Windows), то я возьму Qt.

>> Я ставлю проблемы.

C>Какие? Которых нет?

Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие, нужно принять определенную систему ценностей. После многих лет программирования я принял систему ценностей Вирта и проповедую ее.

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

C>>Ну а в качестве exception-safe — чем MFC или WTL не нравится?

DB>В моем инструментальном ящике этому отстою нету места. Если мне нужно будет сделать программу для Windows, я не раздумывая возьму Delphi и VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать программу для Solaris и Linux (и в последнюю очередь Windows), то я возьму Qt.

Народ, дэ братику программ для виндовоза не давать, ему хватит!

DB>Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие, нужно принять определенную систему ценностей. После многих лет программирования я принял систему ценностей Вирта и проповедую ее.

И тебя вылечат...

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

A>Здравствуйте, d Bratik, Вы писали:

C>>>Ну а в качестве exception-safe — чем MFC или WTL не нравится?

DB>>В моем инструментальном ящике этому отстою нету места. Если мне нужно будет сделать программу для Windows, я не раздумывая возьму Delphi и VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать программу для Solaris и Linux (и в последнюю очередь Windows), то я возьму Qt.

A>Народ, дэ братику программ для виндовоза не давать, ему хватит!

DB>>Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие, нужно принять определенную систему ценностей. После многих лет программирования я принял систему ценностей Вирта и проповедую ее.

A>И тебя вылечат...

Я сам доктор, между делом студентов лечу. Бесплатно избавляю от синдрома страуструпа, комплекса "best industry practice", а также GUI- и DBMS-фобий. Так что обращайтесь

d Bratik пишет:

> A>И тебя вылечат...
> Я сам доктор, между делом студентов лечу. Бесплатно избавляю от
> синдрома страуструпа, комплекса "best industry practice", а также GUI-
> и DBMS-фобий. Так что обращайтесь

Нда... А потом еще люди жалуются на качество IT-образования в Росиии....

--
С уважением,
Alex Besogonov (alexy@izh.com)

d Bratik пишет:

> C>ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
> C>можно использовать в многотредовом окружении, точно так же как и: MFC,
> C>WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
> C>нужный поток или используя только их потокобезопасное подмножество.
> Вы хоть раз Qt на Солярке пускали? Там Qt (по собственнной вине и по
> вине X11) по определению с многопоточностью не дружит (впрочем,
> разработчики Солярки вообще с головой не дружат, так что создателям Qt
> есть на кого пальцем тыкать).

Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
многопоточностью по очень простой причине — ВСЕ они построены на
концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
современную GUI-систему можно использовать в многопоточной среде, приняв
соответствующие меры.

> C>Ну а в качестве exception-safe — чем MFC или WTL не нравится?
> В моем инструментальном ящике этому отстою нету места. Если мне нужно
> будет сделать программу для Windows, я не раздумывая возьму Delphi и
> VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать
> программу для Solaris и Linux (и в последнюю очередь Windows), то я
> возьму Qt.

Да я и не сомневался...

Ксати, VCL построена на стандартном WinAPI, почти вся ее
функциональность — это лишь достаточно тонкая обертка над виндовыми
вызовами. Только вот VCL пытается (плохо) скрыть свое родство с WinAPI,
а WTL использует это родство себе на выгоду.

>>> Я ставлю проблемы.
> C>Какие? Которых нет?
> Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие,
> нужно принять определенную систему ценностей. После многих лет
> программирования я принял систему ценностей Вирта и проповедую ее.

А, все понятно. Теоретик, оторванный от практики.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

DB>Я сам доктор, между делом студентов лечу. Бесплатно избавляю от синдрома страуструпа, комплекса "best industry practice", а также GUI- и DBMS-фобий. Так что обращайтесь

Бесплатная медицина — хреновая медицина. Как минимум на территории бывшего СССР .

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

DB>>Я сам доктор, между делом студентов лечу. Бесплатно избавляю от синдрома страуструпа, комплекса "best industry practice", а также GUI- и DBMS-фобий. Так что обращайтесь
AR>Бесплатная медицина — хреновая медицина. Как минимум на территории бывшего СССР .

Да уж... От GUI-фобии избавишься, так чего доброго GUIфилию подцепишь...

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

C>>Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.

A>пихать 10^5 записей в гуйный контрол это уже кривой дизайн. за такое по рукам надо
A>данные дерева должны быть в невизуальном контейнере, и только малая часть визуализируется по мере
A>необходимости

Умница! Вот только VirtualTreeView делает это за меня. И визуализирует "по мере необходимости",
избавляя от многих забот.

Kh_Oleg пишет:

> C>>Да. Само приложение, хотя 10^5 записей и дерево сможет отсортировать.
> A>пихать 10^5 записей в гуйный контрол это уже кривой дизайн. за такое
> по рукам надо
> A>данные дерева должны быть в невизуальном контейнере, и только малая
> часть визуализируется по мере
> A>необходимости
> Умница! Вот только VirtualTreeView делает это за меня. И визуализирует
> "по мере необходимости",
> избавляя от многих забот.

Даже SysTreeView32 это умеет

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

AE>>13. За дикий размер EXE, если конечно же не юзать пакаджи.
D_T>Дался тебе этот размер. Ты что програмки на дискетках распространяешь?
Нет, через интернет.

D_T>Единственный случай кода тебе нужны две IDE — это когда отлаживаешь расширения среды. В остальных случаях используем ProjectManager
D_T>для работы. Открываем там N проектов...


AE>> Для того чтобы определить где находится описание сетевой
AE>> функции нужно выполнять поиск по каталогу сырцов. К примеру NetWkstaGetInfo которая вообще отсутствиет в
AE>> стандартных сырцах
D_T>Можно подумать в VC 6 есть все-все API фунции?
В platform SDK есть все документированные функции и даже не документированные

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

DB>Я сам доктор, между делом студентов лечу.
Не жалко студентов то?

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

C>d Bratik пишет:

>> C>ТАКИХ нет. VCL — НЕпотокобезопасна, пора бы уже знать. Естественно, ее
>> C>можно использовать в многотредовом окружении, точно так же как и: MFC,
>> C>WTL, WinAPI, QT, GTK и прочие. То есть маршалируя графические вызовы в
>> C>нужный поток или используя только их потокобезопасное подмножество.
>> Вы хоть раз Qt на Солярке пускали? Там Qt (по собственнной вине и по
>> вине X11) по определению с многопоточностью не дружит (впрочем,
>> разработчики Солярки вообще с головой не дружат, так что создателям Qt
>> есть на кого пальцем тыкать).

C>Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
C>многопоточностью по очень простой причине — ВСЕ они построены на
C>концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
C>современную GUI-систему можно использовать в многопоточной среде, приняв
C>соответствующие меры.

Тогда Вы может быть мне расскажите, какие меры нужно принять, чтобы организовать многопоточное рисование (требуется просто фоновое рисование двух картинок) в Qt-программе, работающей на Солярисе? Или под "соответствующими мерами" понимается также смена оконного менеджера, библиотеки графического вывода и операционной системы?

>> C>Ну а в качестве exception-safe — чем MFC или WTL не нравится?
>> В моем инструментальном ящике этому отстою нету места. Если мне нужно
>> будет сделать программу для Windows, я не раздумывая возьму Delphi и
>> VCL (или нынче уже VS.NET с WinForms). Если передо мной цель — сделать
>> программу для Solaris и Linux (и в последнюю очередь Windows), то я
>> возьму Qt.

C>Да я и не сомневался...

C>Ксати, VCL построена на стандартном WinAPI, почти вся ее
C>функциональность — это лишь достаточно тонкая обертка над виндовыми
C>вызовами. Только вот VCL пытается (плохо) скрыть свое родство с WinAPI,
C>а WTL использует это родство себе на выгоду.

>>>> Я ставлю проблемы.
>> C>Какие? Которых нет?
>> Для того, чтобы понять, что проблемы есть и проблемы серьезнейшие,
>> нужно принять определенную систему ценностей. После многих лет
>> программирования я принял систему ценностей Вирта и проповедую ее.

C>А, все понятно. Теоретик, оторванный от практики.

Это кто, Вирт, что ли? С его практикой может сравниться только практика Хайльсберга (и то с натяжкой). Стыдно этого не знать.

d Bratik пишет:

> C>Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
> C>многопоточностью по очень простой причине — ВСЕ они построены на
> C>концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
> C>современную GUI-систему можно использовать в многопоточной среде,
> приняв
> C>соответствующие меры.
> Тогда Вы может быть мне расскажите, какие меры нужно принять, чтобы
> организовать многопоточное рисование (требуется просто фоновое
> рисование двух картинок) в Qt-программе, работающей на Солярисе?

Рисовать картинки в разных потоках, передавать обновленные картинки в
GUI-тред, а в GUI-треде их показывать.

Кстати, рисование средствами какой библиотеки производится?

> Или под "соответствующими мерами" понимается также смена оконного
> менеджера, библиотеки графического вывода и операционной системы?

Нет, понимается синхронизация и маршаллирование вызовов.

> C>А, все понятно. Теоретик, оторванный от практики.
> Это кто, Вирт, что ли? С его практикой может сравниться только
> практика Хайльсберга (и то с натяжкой). Стыдно этого не знать.

Чего? Как практиков я уважаю: Кернигана и Ритчи (создателей языка С), Б.
Страуструпа, Алана Кея (с натяжкой) и многих других.

Вот Вирта в этом списке нет, так как я не помню хороших его практических
творений: Pascal годен только для обучения, Oberon не входит даже в
сотню самых распространенных языков, а Дельфи делалась и вовсе без Вирта
(наверное поэтому и получилось сравнительно удачной). Я не спорю, что
Вирт сделал много для развития теории (как и Дональд Кнут), но вот для
практики....

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

Q Почему настоящие программисты избегают C++
A Потому что реальные перцы ваяют кульный софт исключительно в универсальной среде WinHex

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

C>A Потому что реальные перцы ваяют кульный софт исключительно в универсальной среде WinHex

Да ну... скажешь еще! WinHex... Фу!.. Вот Far с DOS интерфейсом — это руль (и диагноз)

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

К>Монстр макропрограммирования!
От монстра слышу!

К>

К>class PatchFont : public LOGFONT
К>{
К>    ...
К>public:
К>  PatchFont(HWND hWnd=0) {HWND m_hwnd= hWnd;}

К>  bool take(UINT id, HWND hwnd=-1)
К>  {
К>    if(hwnd != -1) m_hwnd = hwnd; 
К>    m_id = id;
К>    ...
К>  }

К>......

К>PatchFont pf(hDlg);

К>pf.take(ID_ONE);
К>  pf.lfWeight = FW_BOLD;
К>pf.give();

К>pf.take(ID_TWO);
К>  pf.lfUnderline = TRUE;
К>pf.give();

К>

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

K>Нет, т.к. ты не ответил на мой вопрос. Я так и не понял в чём ты со мной не согласен. Спрошу по-другому:
K>Функция вычисления среднего арифметического не должна бросать исключений. Влад, ты согласен с этим утверждением? Да или нет?

Как по твоему a + b может вызвать переполнение?

Решения могут быть какие угодно. Но если фонкция содержит код способный привести к переполнению и переполнение не учитывается, то см. пре. отв.

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

C>d Bratik пишет:

>> C>Ррррррррр..... Да _НИ_ _ОДНА_ распространенная GUI не дружит с
>> C>многопоточностью по очень простой причине — ВСЕ они построены на
>> C>концепции очереди сообщений (событий, сигналов). Но при этом _ЛЮБУЮ_
>> C>современную GUI-систему можно использовать в многопоточной среде,
>> приняв
>> C>соответствующие меры.
>> Тогда Вы может быть мне расскажите, какие меры нужно принять, чтобы
>> организовать многопоточное рисование (требуется просто фоновое
>> рисование двух картинок) в Qt-программе, работающей на Солярисе?

C>Рисовать картинки в разных потоках, передавать обновленные картинки в
C>GUI-тред, а в GUI-треде их показывать.

В Qt рисование (любое, даже картинки) в потоке небезопасно, если в это время выполняется цикл обработки сообщений

C>Кстати, рисование средствами какой библиотеки производится?

X11. Она не многопоточна

>> Или под "соответствующими мерами" понимается также смена оконного
>> менеджера, библиотеки графического вывода и операционной системы?

C>Нет, понимается синхронизация и маршаллирование вызовов.

>> C>А, все понятно. Теоретик, оторванный от практики.
>> Это кто, Вирт, что ли? С его практикой может сравниться только
>> практика Хайльсберга (и то с натяжкой). Стыдно этого не знать.

C>Чего? Как практиков я уважаю: Кернигана и Ритчи (создателей языка С), Б.
C>Страуструпа, Алана Кея (с натяжкой) и многих других.

C>Вот Вирта в этом списке нет, так как я не помню хороших его практических
C>творений: Pascal годен только для обучения, Oberon не входит даже в
C>сотню самых распространенных языков, а Дельфи делалась и вовсе без Вирта
C>(наверное поэтому и получилось сравнительно удачной). Я не спорю, что
C>Вирт сделал много для развития теории (как и Дональд Кнут), но вот для
C>практики....

Это невежество простительно лишь для студента первого курса. Вирт системы делал, а языки Pascal, Modula, Oberon — лишь побочный продукт его деятельности. Именно Виртом и его командой были придуманы и реализованы (в операционной системе Oberon) все самые лучшие технические идеи, которые спустя несколько десятилетий были внедрены в .NET: высокоуровневый байт-код, динамическая компиляция, автоматическая сборка мусора, контроль типов во время выполнения программы, полная информация о типах в исполняемых модулях, расширяемость программ без их перекомпиляции и многое другое. Вирт собственноручно проектировал язык, программировал компилятор, операционную систему, графическую библиотеку визуальных компонентов и др. Проблема Вирта лишь в том, что он слишком сильно (на 20-30 лет) опередил свое время.

Кернигана и Ритчи — неплохие ребята, но до Вирта им как до луны. Да, они тоже делали язык, компилятор и операционную систему, поэтому их есть за что уважать (хотя все их творения уже давно морально устарели).

Страуструп вообще ничего практического не сделал.

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

DB>Страуструп вообще ничего практического не сделал.

Распечатаю и повешу себе на стенку над рабочим местом.

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

DB>Именно Виртом и его командой были придуманы и реализованы (в операционной системе Oberon) все самые лучшие технические идеи, которые спустя несколько десятилетий были внедрены в .NET:

Знающие люди поправят, но ИМХО...

DB>высокоуровневый байт-код,

...был в smalltalk...

DB>динамическая компиляция,

...была в smalltalk...

DB>автоматическая сборка мусора,

...вроде тоже была.

DB>Вирт собственноручно проектировал язык, программировал компилятор, операционную систему, графическую библиотеку визуальных компонентов и др. Проблема Вирта лишь в том, что он слишком сильно (на 20-30 лет) опередил свое время.
DB>Кернигана и Ритчи — неплохие ребята, но до Вирта им как до луны. Да, они тоже делали язык, компилятор и операционную систему, поэтому их есть за что уважать (хотя все их творения уже давно морально устарели).
DB>Страуструп вообще ничего практического не сделал.

Угу, вот только "морально устаревшие творения K&R+S" продолжают успешно применяться, а Виртовские "опредившие время" системы так и остались по большому счету на уровне "интересных для изучения". А разговор-то идет о практике. Ты вот, например, сейчас под какой осью эту мессагу читаешь? Под Oberon-based или все-таки под написанными на С[++] виндами/линухом?