MSS>>То-то ядра Windows и юниксов работают хорошо, то-то компиляторы работают хорошо...
>все на Си
Д>то-то мне сразу вспоминаются MS-Blast и компиляторы, которые при любом шаге в сторону
>сыплют internal compiler error

Да прям при любом шаге пятерка была неудачная версия, в шестерке я не чаще раза в год такое вижу. В том компиляторе, что с XP DDK дают — тоже.

Насчет MSBlaster — ну ОК, перейди на юниксы, которые якобы более надежны — там тоже большая часть софта на Си написана.

>новые интелектуальные 3D интерфейсы сладящие за нашими глазами, дыханием, биотоками, понимающими нашу речь

Все, дальше не надо пошла научная фантастика.

AF> Я видел кучу кода а-ля:
AF>

AF> EnterCriticakSection( &cs );
AF> fp = fopen( "file", "rb" );
AF> if( fp == NULL ) return -1;
AF> ....
AF> LeaveCriticalSection( &cs );
AF>

Я бы это назвал "лохописный код". при таком лоховстве Си++ лучше в руки не давать — они там понаворотят...

Уже сам факт вызова fopen из-под лока — смахивает на лоховство, я про не-отдачу лока даже не говорю.

AF> Ну да, править тут ошибку — очень легко, но зачем?

Затем, что если этот файл не найдется, или если с него права на чтение убрать — то система дедлокнется. Классический DOS attack.

>вас раздражает. У большинства же интересы диаметрально противоположны. Гораздо
>интереснее не детали того, как открыватся файл — а сам факт его открытия и дальнейшие
>действия — причём опять таки их суть, а не детали...

Ну, если что-то надо на коленке сляпать, да побыстрее — то, наверное, да. Для таких вещей Перл хорош, например

MSS>>Кстати, их наличие — равно как и вообще концепция nonclient area — одна из
>мерзейших фич USERа.

Потому что намного более удачный подход — два окна, одно внутри другого.

Самое главное — Си++ ная обертка над USER под названием MFC именно так и делает, и плевать она хотела на nonclient area.

Внутреннее окно называется view. То же самое было и в TurboVision, где window — это окно с рамкой, а в него еще отдельно вставлялся interior. Кажется, и в AWT то же самое.

В большинстве случаев это так. Ну и зачем тогда понятие nonclient area, а заодно второй комплект сообщений WM_NCxxx? Есть окно фрейма, ему принадлежит рамка и кнопочки по углам. А в него вставлено окно view, ему принадлежит изображаемый документ. Очень все разумно.

Скроллбары же ИМХО нужно отдельными дочерними окнами делать. Причем окнами совершенно стандартного класса Scrollbar.

S>Если это такая уж фича Windows, как вы это представляете (типа святая), то откуда например у CListCtrl функция DrawItem, позволяющая самому инжектить отрисовку?

Потому что USERовский класс LISTBOX поддерживает owner draw в MFC же этой поддержкой воспользовались.

Вывод: нефиг трогать MFC, не зная USERа. Всегда надо знать детали того, с чем работаешь, иначе будешь в глупые положения попадать.

S>Стандартная? Ну дай мне ссылку на "стандартную" статью, где изменяется отрисовка у скролбара.

Надо унаследовать свой класс от CButton, в нем завести обработчик OnPaint, и просубклассить кнопку этим своим классом. Иначе же WM_PAINT пропускается в родную WndProc класса BUTTON, которая сидит в USER32.DLL, и ее не откастомайзишь.

P.S. Последний раз писал UI на MFC лет 8 назад

MSS>Для прикладного уровня — конечно. Можно даже проще. Вот так

MSS>for $name(`ls`)
MSS>{
MSS> ...
MSS>}

Вот так делать не стоит.
Потому что как раз в этом случае появляется очень много неявных зависимостей
0. В какой системе запущена программа
1. Как в данной системе настроен вывод ls
2. Что выводит ls, если файлы не найдены
3. что выводит ls в случае ошибки
4. Что выводит ls в случае файлов, содержащих нечитабельные символы
5. Какие файлы выводит ls (выводятся ли hidden, выводятся ли system)
6. Какая кодировка в системе, у команды ls, у нашей программы
7. как for парсит вывод ls (по пробельным символам, по 0x0D, по 0x0A, по 0x0d0x0a, и так, и так)
и т.д. и т.п.

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

DG>Потому что как раз в этом случае появляется очень много неявных зависимостей
DG>0. В какой системе запущена программа

Краткий ответ на все претензии.

Приведенное решение непортабельно между юниксами, а то и между разными дистрами Линукса. Это делают только в решениях конкретному клиенту, где есть договоренность о том, что за юникс у него будет стоять, какой версии, и вдобавок как настроен. Большинство таких решения рассыпаются, если что-то подкрутить в настройках ОС.

Здравствуйте, Maxim S. Shatskih, Вы писали:

>>новые интелектуальные 3D интерфейсы сладящие за нашими глазами, дыханием, биотоками, понимающими нашу речь
MSS>Все, дальше не надо пошла научная фантастика.
Ладно не буду. Вернее буду чуть-чуть , специально для тех кто застрял в прошлом.
Это не фантастика, а реально работающие прототипы, демострируемые на выстаках. Некоторые системы — слежение за хрусталиком глаза, и другой биометрией в т.ч. биотоками, давно используются военными и эту фантастику уже продают, правда за большие деньги.
С 3D интерфейсами эксперементируют давно. Но скорее всего официальной вехой развития будет Windows Longhorn, для которого 3D будет родным интерфейсом. Эта фантастика уже есть, и надо просто иногда смотреть новости, чтобы увидеть, нет не рождение, которое уже было, а становление.

Хотя я понимаю — для некоторых С++ и в половинном объёме спецификаций тоже недостижимая фантастика

Хотя вы правы, больше не надо — бесполезно

Здравствуйте, Maxim S. Shatskih, Вы писали:

AF>> Я видел кучу кода а-ля:
AF>>

AF>> EnterCriticakSection( &cs );
AF>> fp = fopen( "file", "rb" );
AF>> if( fp == NULL ) return -1;
AF>> ....
AF>> LeaveCriticalSection( &cs );
AF>>

MSS>Я бы это назвал "лохописный код". при таком лоховстве Си++ лучше в руки не давать — они там понаворотят...

MSS>Уже сам факт вызова fopen из-под лока — смахивает на лоховство, я про не-отдачу лока даже не говорю.
С лохописностью кода — абсолютно согласен. Я его как раз из-за этого и привел. Однако замечу, что для народа, который пишет такой код классы — обёртки решают половину проблем — вроде банального лока. Вторую половину — для которой нужна голова тут конечно уже не решить...
А С++ выдавать народу можно — они не то что оператор или шаблон, класс толком не напишут. Так что это не страшнее, чем C.

AF>> Ну да, править тут ошибку — очень легко, но зачем?

MSS>Затем, что если этот файл не найдется, или если с него права на чтение убрать — то система дедлокнется. Классический DOS attack.

Ты не понял суть. Почему нужно освобождать лок — я догадываюсь, но вот зачем давать возможность вообще совершить ТАКУЮ ошибку — и тратить время на её исправление, когда подобные ошибки лечатся элементарными обёртками? Думаешь народ не наделает ошибок и без забытых локов? Наделают — причём ошибки будут глубже. Потому лучше иметь среду — в которой можно будет тратить время на правку действительно существенных — смысловых ошибок. В противном случае есть риск, что после того, как ты подправишь закрытие всех хендлов и отпускание всех локов (а заодно и их установку) в "лохописном коде", частенько выясняется, что ошибка глубже — и этот код надо вообще было переписать...

Здравствуйте, Maxim S. Shatskih, Вы писали:

>>вас раздражает. У большинства же интересы диаметрально противоположны. Гораздо
>>интереснее не детали того, как открыватся файл — а сам факт его открытия и дальнейшие
>>действия — причём опять таки их суть, а не детали...

MSS>Ну, если что-то надо на коленке сляпать, да побыстрее — то, наверное, да. Для таких вещей Перл хорош, например

Согласен, впрочем для таких целей есть много разных языков... Правда жизнь богаче и между "сляпать на коленке" и "серьёзный проект с огромным бюджетом", есть маленькая такая прослойка — проекты с относительно (решаемых задач) маленьким бюджетом, но при этом широко используемыми резульататами И что удивительно — почему то абсолютное большинство проектов — именно в этой прослойке. Вот там то и рулит C++, а с недавнего времени — C#.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>Кстати, их наличие — равно как и вообще концепция nonclient area — одна из
>>мерзейших фич USERа.

MSS>Потому что намного более удачный подход — два окна, одно внутри другого.

MSS>Самое главное — Си++ ная обертка над USER под названием MFC именно так и делает, и плевать она хотела на nonclient area.

MSS>Внутреннее окно называется view. То же самое было и в TurboVision, где window — это окно с рамкой, а в него еще отдельно вставлялся interior. Кажется, и в AWT то же самое.

MSS>В большинстве случаев это так. Ну и зачем тогда понятие nonclient area, а заодно второй комплект сообщений WM_NCxxx? Есть окно фрейма, ему принадлежит рамка и кнопочки по углам. А в него вставлено окно view, ему принадлежит изображаемый документ. Очень все разумно.

MSS>Скроллбары же ИМХО нужно отдельными дочерними окнами делать. Причем окнами совершенно стандартного класса Scrollbar.

Полностью согласен. Если сделать окна с Non-client area как отдельные — контейнеры для окон представлений, то логика работы с окнами упростилась бы на порядок и код писать стало бы гораздо легче. Но об этом в своё время не думали...

B> Это не фантастика, а реально работающие прототипы, демострируемые на выстаках.

Они уже десять лет там демонстрируются. Равно как и шлемы виртуальной реальности. А вот такие вещи на mass market — фантастика.

>Некоторые системы — слежение за хрусталиком глаза, и другой биометрией в т.ч.
>биотоками, давно используются военными

Это не mass market. Специализированные вещи, мелкие тиражом (да и тиражом ли?) делаемые, отсюда и дорогие.

B> С 3D интерфейсами эксперементируют давно. Но скорее всего официальной вехой развития
>будет Windows Longhorn, для которого 3D будет родным интерфейсом.

То, что там везде будут скины, как в ВинАмпе — слышал. Но чтоб все трехмерное?

Чем двумерное-то плохо? Вот рядом совсем нитка про UI. И что-то не вижу я там утверждений, что трехмерный UI лучше двумерного.

>рождение, которое уже было, а становление.

Рождение было давно, становления — нет и не предвидится.

Это как с авиацией. Боингу-747 уже 30 лет. F-16 — тоже 30 лет. И ничего, летают, первый с незначительными изменениями, второй — почти как есть.

А теперь представим себе 70ые годы. Что такое был в 70ые годы — самолет 40х годов? Скажем, Ла-7 или Мустанг в 70ые годы. Смешное старье.

Просто отрасль как целое начинает тормозиться в развитии.

B> Хотя я понимаю — для некоторых С++ и в половинном объёме спецификаций тоже
>недостижимая фантастика

Да нет.

Просто есть места, где ни к чему эти навороты совсем. Русские мастера средних веков строили великолепные церкви одним топором. Такие, что сейчас с трудом повторимы даже с нынешней техникой.

А то, что в Си++ есть конкретно лишние фичи в виде throw() — со мной и сторонники этого языка согласились

AF> А С++ выдавать народу можно — они не то что оператор или шаблон, класс толком не
>напишут. Так что это не страшнее, чем C.

Классы таким людям давать писать нельзя им можно только давать юзать чужие

AF>Ты не понял суть. Почему нужно освобождать лок — я догадываюсь, но вот зачем давать
>возможность вообще совершить ТАКУЮ ошибку

Если таких людей в команде иметь — то да, возможно.

>ошибки будут глубже. Потому лучше иметь среду — в которой можно будет тратить время на
>правку действительно существенных — смысловых ошибок.

Да нет. Как показывает практика — самый мощный источник багов — опечатки. Типа перепутать Src и Dst. Или ++ забыть где-нить. От такого никакие обертки не спасут.

>выясняется, что ошибка глубже — и этот код надо вообще было переписать...

Редко такое бывает. Ну что такое "смысловая ошибка"? Финансовая система неправильно деньги считает? ОК. Решается как правило переписыванием одного SQLного запроса.

>этом широко используемыми резульататами И что удивительно — почему то абсолютное
>большинство проектов — именно в этой прослойке. Вот там то и рулит C++, а с
>недавнего времени — C#.

Я ж про системные вещи говорю.

AF> Полностью согласен. Если сделать окна с Non-client area как отдельные — контейнеры для окон представлений, то логика работы с окнами упростилась бы на порядок и код писать стало бы гораздо легче. Но об этом в своё время не думали...

ИМХО на USER нужно архитекторов учить — как на примере плохо спроектированной системы. Типичный случай. И как раз пример того, к чему ведут архитектурные огрехи:

а) затрудняется труд тех, кому писать код поверх этого
б) затрудняется развитие системы
в) появляется необходимость во врапперах типа MFC, чтобы упрятать безобразие, и причем даже врапперы не справляются
г) рефакторинг почти невозможен, почти любая правка приводит к слому того, что написано уровнем выше
д) так же невозможна реимплементация с нуля

Ну и так далее.

А уж те, что исходники USER видели, с патчами "А вот тут затычка, потому что в PowerPoint квадратик рисуется неправильно", "а вот тут придется развести немножко грязюки, чтобы ПаэурБилдер и написанные на нем программы правильно работали", с именами функций типа zzzDesktopThread() и доведенной до маразма венгерской нотацией — эти и вовсе чудеса рассказывают.

Известно, что GDI в НТ переписали с нуля. Потому как правильно спроектированная система (одна из лучших подсистем у Майкрософта ИМХО), и тут дело не в Си или Си++, а в голове . А вот USER туда перетащили из Вин 3.1, перетащили за уши — и, по слухам, потому, что сам Майкрософт в этом коде запутался напрочь, и боится в нем хоть что-то тронуть.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Они уже десять лет там демонстрируются. Равно как и шлемы виртуальной реальности. А вот такие вещи на mass market — фантастика.
Виртуальный шлем — это вчерашний день. Современные кибер костюмы захватывают гораздно больше человеческих чуств, даже эротических

>>Некоторые системы — слежение за хрусталиком глаза, и другой биометрией в т.ч.
>>биотоками, давно используются военными
MSS>Это не mass market. Специализированные вещи, мелкие тиражом (да и тиражом ли?) делаемые, отсюда и дорогие.
Да, какая разница в цене, сегодня дорого, через пару лет — доступно студенту. Например прогресс мобильной связи за 10 лет.

B>> С 3D интерфейсами эксперементируют давно. Но скорее всего официальной вехой развития
>>будет Windows Longhorn, для которого 3D будет родным интерфейсом.
MSS>То, что там везде будут скины, как в ВинАмпе — слышал. Но чтоб все трехмерное?
MSS>Чем двумерное-то плохо? Вот рядом совсем нитка про UI. И что-то не вижу я там утверждений, что трехмерный UI лучше двумерного.
Появиться Longhorn, появяться и утверждения. MS уже всё решил

MSS>Рождение было давно, становления — нет и не предвидится.
MSS>Это как с авиацией. Боингу-747 уже 30 лет. F-16 — тоже 30 лет. И ничего, летают, первый с незначительными изменениями, второй — почти как есть.
MSS>А теперь представим себе 70ые годы. Что такое был в 70ые годы — самолет 40х годов? Скажем, Ла-7 или Мустанг в 70ые годы. Смешное старье.
MSS>Просто отрасль как целое начинает тормозиться в развитии.
Ну вот, все согласны, что закон Мура работает в IT уже лет 30, а вы нет.
Не правильно сравнивать IT и граждансую авиацию, где цена ошибки может быть гибельна для авиакомпании и порождает консервативный подход. Посмотрите на военную авиацию — Россия модернезирует старое железо, ставя там современную электронику. Так что какой нибудь МиГ29 сегодня и 10 лет назад — это две разных машины.

MSS>Просто есть места, где ни к чему эти навороты совсем. Русские мастера средних веков строили великолепные церкви одним топором. Такие, что сейчас с трудом повторимы даже с нынешней техникой.
MSS>А то, что в Си++ есть конкретно лишние фичи в виде throw() — со мной и сторонники этого языка согласились
Современные мастера построят такую же церковь за пару месяцев а не лет, да и добавят такого что в старину и не снилось. А современные технологи создадут такой меч, что и легенды позавидуют. Надеюсь не будете отрицать, что архитектура и технология шагнула далеко вперёд, а предкам место в сказках и патриотических историях.
А лишних фич не бывает. Не надо — не используй. В моём прошлом и настоящем проектах использовали throw, хотя были споры. И до сих пор некоторые члены команды его игнорируют. Но есть небольшая закономерность — throw используют как правило те, у кого зарплата больше, хотя это и локальная закономерность замеченная мной

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Вернемся к SMART (протокол съема с ИДЕ винчестера инфы о том, как скоро он посыпется). Человек написал ради этого класс. Зачем? Три вызова — CreateFile, DeviceIoControl, CloseHandle. Вот зачем там — класс?

Сравни:

HANDLE hDevice = CreateFile("\\\\.\\SMARTDevice", ...);
if (hFile != INVALID_HANDLE_VALUE) {
        BOOl res = DeviceIoControl(hDevice, IOCTL_SOMEACTION, ... );
        if (!res) {
                // И что тут делать? SetLastError устанавливать?
                // Оно не доедет до того места, где может быть обработано.
        }
        CloseHandle(hFile);
} else {
    // А тут что делать?
}

и

try {
    CSMARTDevice device();
    device.some_action();
} catch (Exception &e) {
    std::cerr << e << sdt::endl;
}

В первом случае обработка ошибок застилаем всю логику. Во втором мы можем вынести её туда, где она действительно имеет смысл.
А пропустить какой-нибудь CloseHandle в первом случае — как два пальца.

MSS>Про драйвера. Задумался вчера всерьез над темой "Си++ в драйверах", и получилось вот что. Там некое количество внешних структур, с которыми приходится работать, и которые приходят извне. Ну и толку будет оборачивать NDIS_PACKET в класс? Что это даст-то? Взаимодействие с окружающей ОС все равно делается в терминах NDIS_PACKET, и зачем вокруг него врапперы плодить?

Сравни

PVOID VirtualAddress;
status = NdisAllocateMemoryWithTag(&VirtualAddress, nBufferSize, 'XXXX');

if (status == NDIS_STATUS_SUCCESS) {
    NdisMoveMemory(VirtualAddress, lpBuffer, nBufferSize);

    PNDIS_BUFFER Buffer;
    NdisAllocateBuffer(&status, &Buffer, BufferPoolHandle, VirtualAddress, nBufferSize);

    if (status == NDIS_STATUS_SUCCESS) {
        PNDIS_PACKET Packet;
        NdisAllocatePacket(&status, &Packet, PacketPoolHandle);

        if (status == NDIS_STATUS_SUCCESS) {
            NdisChainBufferAtBack(Packet, Buffer);

            NdisSend(&status, NdisBindingHandle, Packet);

            // ...

            NdisFreePacket(Packet);
        }
        NdisFreeBuffer(Buffer);

    }

    NdisFreeMemory(VirtualAddress, nBufferSize, 0);
}

и

CBuffer buffer(BufferPoolHandle, lpBuffer, nBufferSize);
CPacket packet(PacketPoolHandle);
packet.add_buffer(buffer);
miniport.send(packet);

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>Кстати, их наличие — равно как и вообще концепция nonclient area — одна из
>>мерзейших фич USERа.

MSS>Потому что намного более удачный подход — два окна, одно внутри другого.

MSS>Внутреннее окно называется view. То же самое было и в TurboVision, где window — это окно с рамкой, а в него еще отдельно вставлялся interior. Кажется, и в AWT то же самое.

MSS>В большинстве случаев это так. Ну и зачем тогда понятие nonclient area, а заодно второй комплект сообщений WM_NCxxx?

Посмотри на X Window.
Там рамка и заголовок окна — это именно nonclient area. Т.е. собственность не приложения, а window manager'а.

Похоже, что разработчики GUI для Windows хотели применить тот же подход.
Но что-то не срослось...

P>

P>CBuffer buffer(BufferPoolHandle, lpBuffer, nBufferSize);
P>CPacket packet(PacketPoolHandle);
P>packet.add_buffer(buffer);
P>miniport.send(packet);
P>

А обломится аллокация — что делать бум? Только не надо мне рассказывать про Си++ exceptions в ядре, да еще и на DISPATCH_LEVEL.