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

Вот там как раз окно в окне внешнее окно фрейма создает действительно window manager, а view создает приложение.

Кстати, Windows делали одновременно с X11, и она во многом лучше — если на GDI посмотреть, а не на USER.

Так что ой вряд ли микрософт что-то стянул у X11. Скорее уж у Эппла

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

По заворачиванию DeviceIoControl в класс претензий, я смотрю, нет?
Вот и хорошо.

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

1). Почему бы и нет?
2). Если так не любишь исключения — исправь код следующим образом:

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

Это по прежнему лучше пирамиды из вложенных if'ов.

Предупреждая твой следующих ход: обработка NDIS_STATUS_PENDING в результате NdisSend тоже легко решается.
И здесь, и в ProtocolSendComplete.

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

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

MSS>Вот там как раз окно в окне внешнее окно фрейма создает действительно window manager, а view создает приложение.

Не обязательно
Теоретически родительское окно может быть невидимым, а каждый элемент декорации быть отдельным окном.

MSS>Кстати, Windows делали одновременно с X11, и она во многом лучше — если на GDI посмотреть, а не на USER.

MSS>Так что ой вряд ли микрософт что-то стянул у X11. Скорее уж у Эппла

Похоже, что как минимум некоторые идеи пытались стянуть.
Зачем в Win32 API атомы?
Зачем они нужны в X Window очевидно. А вот зачем этот рудимент тут...

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

VD>В шарпе, например, привести неявно энум к целому или наоборот невозможно.

public sealed class SqlParameterCollection : DbParameterCollectionBase, ISqlParameterCollection {
    [Obsolete("use AddWithValue(string, object)", false)]
    [EditorBrowsable(EditorBrowsableState.Never)]
    public SqlParameter Add(string parameterName, object value) {
        return Add(new SqlParameter(parameterName, value));
    }
}

Угадай, почему Obsolete?

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

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

MSS>Классы таким людям давать писать нельзя им можно только давать юзать чужие
Так так и поступают — дают им чужие классы, да ещё с примерами использования...

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

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

Увы, часто приходится...

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

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

Согласен. Но это у профи, такого как Вы например... То есть у человека который прекрасно представляет для чего, что и как он делает. У него другие ошибки вообще редко бывают...

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

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

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

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

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

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

Если про системные — то да, согласен. В большинстве случаев там эффективнее всего C. Причём чем ближе к железу — тем эффективнее. C++ в системном программировании хорош при проектировании вещей высокоуровневых, которых в системном программировании не так и много...

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

B> А лишних фич не бывает. Не надо — не используй. В моём прошлом и настоящем проектах использовали throw, хотя были споры. И до сих пор некоторые члены команды его игнорируют. Но есть небольшая закономерность — throw используют как правило те, у кого зарплата больше, хотя это и локальная закономерность замеченная мной
Можно узнать зачем ты использовал спецификацию исключений?

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

WH>Можно узнать зачем ты использовал спецификацию исключений?
Извините, начну с самого дна.
Надеюсь никто не отрицает пользу исключений, поддерживаемых аппаратно. Это нормальный способ передачи сообщений на верх. Хотя некоторых пугает слово "исключение".
Сейчас С++ поддерживает гибкую систему работы с исключениями — передача объекта класса исключения на верх и вызов деструкторов автоматических объектов.
Большей частью мы использовали throw() для повышения самодокоментируемости кода. Если функция может вызвать штатное исключение, то это должно быть описано. В купе с модификатором const и другими подобными вещами, информация в заголовке функции несёт пользу для человека, использующего эту функцию в своём коде. А спецификация С++ следит за корректность использования throw().
К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций, или для автоматической генерации кода обработки исключения. А также всякими профайлерами и CASE средствами.

P>Предупреждая твой следующих ход: обработка NDIS_STATUS_PENDING в результате NdisSend
>тоже легко решается.
P>И здесь, и в ProtocolSendComplete.

Да это как раз тривиально в любом языке:

NdisSend(&Status, Binding->LowerAdapter, Packet);
if( Status != NDIS_STATUS_PENDING )
ProtocolSendComplete(Binding, Packet, Status);

Флаг вот только в руки реализовывать __CxxFrameHandler в ядре. На DISPATCH_LEVEL же это вообще невозможно, потому как exceptions основаны на thread local storage (сегмент FS), а на DISPATCH_LEVEL это понятие размыто. Запачкаешь FS:[0] какой-то нити, спасибо за это никто не скажет

Еще нюанс. После NdisSend пакет нам не принадлежит. Надо не забыть занулить поле в классе, чтобы деструктор по выходу из блока не решил уничтожить не-принадлежащий нам пакет. В итоге сложности вырастают, они всего лишь заталкиваются внутрь враппера.

Еще нюанс. Написание враппера вокруг обоих структур, а потом еще и "кода по делу" — дольше будет.

Еще нюанс. В отладчике страшно будет

B> Большей частью мы использовали throw() для повышения самодокоментируемости кода. Если
>функция может вызвать штатное исключение, то это должно быть описано. В купе с

По опыту Джавы могу рассказать, что будет.

Будет ограничение на то, что можно звать из данного метода. Для его обхода придется оборачивать вызов в try/catch, и _преобразовывать exception одного класса в exception другого_. А вот больший маразм и представить себе сложно. Совершенно лишний код, и некрасивый, и не подходит ни под одну нормальную концепцию, и дела не делает.

Честно говоря, хорошие exceptions в OLE Automation. Код ошибки и строка. И все. Хватит. На кой черт нужны _классы_ exceptions?

VD>>В шарпе, например, привести неявно энум к целому или наоборот невозможно.

Кстати, чем плохо неявное приведение энума к целому? Наоборот — конечно плохо, но я не уверен, что даже Си это позволяет.

Например, энумами пользуются для объявления побитовых флагов. Такой запрет разрушит это использование.

MSS>>Классы таким людям давать писать нельзя им можно только давать юзать чужие
AF> Так так и поступают — дают им чужие классы, да ещё с примерами использования...

Кстати, да.

На Си++ вполне возможен стиль кодирования, не сильно удаленный от Бейсика. Сочетание _com_ptr_t вместо Object, _bstr_t вместо String, и std::vector для массива.

Бизнес-логику на таком писать — одно удовольствие. У меня был на таком написан вебмейл, помнится.

При этом сохраняются преимущества языка низкого уровня — весь API доступен без проблем.

Вот на таком, с позволения сказать, "диалекте" Си++ — можно и лохам давать писать.

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

При плохом проектировании другой гимор. Обычно в виде сложности с развитием кода. А баги все исправить можно и в плохо спроектированном коде (USER тому пример).

P>Не обязательно
P>Теоретически родительское окно может быть невидимым, а каждый элемент декорации быть
отдельным окном.

Но чего-чего, а nonclient area и дублирующего набора событий для нее в X11 точно нет.

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

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

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

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

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

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

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

const char *Src=...;
char *Dst=...;

memcpy(Dst,Src,...);

Ну ка, перепутай. Компилятор матом не заругается? Надо ли напоминать, что в C++ грамотное использование модификатора const избавляет от очень многих ошибок подобного сорта.

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

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

В лохокоде? Сплошь и рядом.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

MSS>Например, энумами пользуются для объявления побитовых флагов. Такой запрет разрушит это использование.

В C++ (не помню, как в C) битовые флаги через enums делаются ущербно, именно с использованием явного приведения целого к enum:

enum test {one = 1, two = 2};
test t = one | two; // так нельзя, надо (test)(one | two)

В C# для каждого enum-типа автоматически определяются битовые операции и прибавление/вычитание константы, выдающие значение этого же типа, так что такие кривости там не нужны. Но мой пример несколько про другое, пусть Влад подумает.

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

MSS>Честно говоря, хорошие exceptions в OLE Automation. Код ошибки и строка. И все. Хватит. На кой черт нужны _классы_ exceptions?

Да уж, гемор ещё тот. Забыл один раз где-нибудь обработать и никто не узнает было ли исключение вообще.

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

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

MSS>>Так маразм-то — спецификация throw().
WH>А я спорю? Я же назвал это проблемой... Но это фигня по сравнению с граблями которые достались от С.
MSS>>Кому она нужна-то? излишество, загромождающее код,
WH>Ни кому.
MSS>>и одна из самых бесящих вещей в Джаве, где она обязательна, в отличие от Си++.
WH>.NET и исключения

Автор: Gasy
Дата: 24.05.04

MSS>>Кто-нить реально пользуется этой фичей Си++?
WH>Сомневаюсь

Кроме "throw()", который достаточно важен, так как указывает на то, что функция не порождает исключений.

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

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

WH>>Можно узнать зачем ты использовал спецификацию исключений?

B> Большей частью мы использовали throw() для повышения самодокоментируемости кода.

А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно. Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку.

>Если функция может вызвать штатное исключение, то это должно быть описано. В купе с модификатором const и другими подобными вещами, информация в заголовке функции несёт пользу для человека, использующего эту функцию в своём коде. А спецификация С++ следит за корректность использования throw().

Я так не думаю. Редок тот компилятор, который поддерживает, что-либо кроме пустого "throw()" (versus throw(some_exception)).

B> К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций,

Как раз таки, компилятор должен кучу кода награмаздить, чтобы проверить соответствие спецификации исключения. Тут уж ни о какой оптимизиции речи не идёт, за исключением опять-же пустого throw().

> или для автоматической генерации кода обработки исключения.

Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна?

>А также всякими профайлерами и CASE средствами.

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

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

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

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

Ну это как раз — "исторические причины" в чистом виде. и "якобы более надежны" — это аргумент совсем не в пользу Си

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


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