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

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

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

P>>>Вдогонку: не мог бы ты объяснить, где в моём примере страдает качество?
P>>>Предполагаем, что писатель обёрток на C++ знает своё дело хорошо и кривых обёрток не пишет.

V>>Основные затраты(и отсюда конечное качество) в системном программировании — не кодирование, а отладка и исследовательская работа. Всегда нужно знать, что внутри.

V>>Речь в первую очередь об этом.

P>Программист №1 знает, что внутри, и пишет обёртки для тех, кто не знает.
P>Обёртки ограничивают свободу программиста, но позволяют корректно писать приложения без глубоких знаний потрохов.

P>Или ты предлагаешь знать "что внутри" всем? Тогда получаем вариант с 15000 USD за проект.

Сравнение двух команд было некорректно. Требуется не 5 специалистов, а меньше, чем в команде номер 2. Именно специалистов. Отдельно рассматриваются прикладные программисты и QA инженеры.

Дело не в категориях программистов, а в областях специализации.

В том то все и дело. Подчеркиваю, речь идет о системном программировании.

----------------------------------

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

И критерии качества разные (в том числе экономически и технически обоснованные).


У меня была возможность сравнить и прикладное программирование и системное (начинал в 1988 на ассемблере DEC PDP-11).
В середине 90-х например был автором идеи и руководителем проекта, где одними из первых в России использовалась JAVA коммерчески успешно (но серверная часть была С/C++ TCP/IP сервер и поддерживающая С++ DCOM инфраструктура) для ИА Финмаркет (трансляция биржевых торгов в реальном времени). То, что в моем профайле — результат возвращения к корням в 1998 (хотя это было всегда со мной хотя бы в качестве халтурок).


Так что дело вовсе не в ретроградстве и "распальцовке" . И всякая хорошо сделанная работа (на любом языке программирования) достойна уважения.

У меня все

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

V>Сравнение двух команд было некорректно. Требуется не 5 специалистов, а меньше, чем в команде номер 2. Именно специалистов. Отдельно рассматриваются прикладные программисты и QA инженеры.

V>Дело не в категориях программистов, а в областях специализации.
V>В том то все и дело. Подчеркиваю, речь идет о системном программировании.

V>----------------------------------

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

V>И критерии качества разные (в том числе экономически и технически обоснованные).

Мой пойнт: km программист — это не обязательно системщик. [тухлые помидоры летят в сторону докладчика]
Отсюда и желание использовать C++ для прикладников, волей обстоятельств вынужденных писать в km.

У меня тоже всё.

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

Д>посмотрим, что они реально в Лонгхорне сделают. хотя избавляться от теперешнего WinAPI давно уже пора

Современная рекламма ЛХ, как ни странно, самя адекватная из слышанных мной от МС.

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

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

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

Т.е. дело в традициях и малость (а может и не малость) неадекватного к ним отношению? Ну, что же это объяснение очень похоже на правду.

AF> А если серьёзно — то C++ прекрасно можно использовать для драйверов. Главное при написании драйверов это смотреть — какие средства языка используются и каковы будут затраты ресурсов при их использовании.

Согласен на все 100.

AF>Например exceptions в драйверах явно не стоит использовать.

Ну, а почему бы и нет если они используются для выведения блюскринов?

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

A>Я про это и говорю. Никто не будет в Америке делать макдональдсы в каждом городе на том же уровне, что и в Москве. Большинство американцев живут в провинциальных городках и жиреют в провинциальных макдональдсах. Посмотри, например, сюда. Полу-деревня, а макдональдса там целых два!

Сдается еда одинакова во всех маках. Так что тут пробдемы в менталитете аперикосов. Ну, а это савсем уж их пробемы.

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

_>

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, Вы писали:

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

Потому-что — это порождает целый ворох граблей. Одним словом — это нарушение типобезопасности.

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

Дык потому и пользуются, что а) они с С++ убоги, б) нет полноценных специализированных средств. В Дельфи для этого есть set-ы, в Шарпе энумы помеченные атрибутом Flags.

Например, на шарпе можно писать так:
[Flags]

enum E { A = 0x1, B = 0x2 }

static void Main()
{
    E ab = E.B | E.A;
}

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

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

A>А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно.
Есть, только не талмуд, которому никто следовать не будет, а небольшой внутрифирменный документ, стандартизирующий написание кода. Над проектом работает 10 человек, каждому из которых доступен весь общий код. Каждый разработчик — представитель своей школы программирования, и если он будет применять сугубо свой стиль, особенно не в своих модулях, то это будет полнейший бардак, а код будет выглядеть как перелатанное одеяло.
Поэтому существует внутрифирменное соглашение-стандарт на написание кода. И каждый может представить своё обоснованное предложение на его усовершенствование или изменению. Да и опыт команды растёт, что отражаеться на эволюции "Coding guidelines".

A>Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку.
Тоже самое с модификатором const, сделав одну из функций неконстантной, вам прийдёться модифицировать все функции исполюзующие её. Но вы ведь не будете отрицать необходимость этого модификатора.

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

>> или для автоматической генерации кода обработки исключения.
A>Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна?
Кому не нужна, тот и не использует. Кому понадобиться, тот будет рад что такое возможно.

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

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

MSS>Во! Я именно против такого бреда выступаю.

Ты перегибаеш палку. Бред конечно плохо. Но татальная борьба с ним доводит до неменьшего бреда.

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

Незнаю. Нужно смотреть код. Может быть нафиг не упал. А может очень даже удобен.

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

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

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

V>Ваша миссия как более опытного специалиста объяснить коллеге нюансы IMHO. Ничего личного.

А что по-твоему проще объяснить "коллеге" или самому написать? И что будет когда объясняльщик уйдет и компании?

Абстракции тем и хороши, что они понятны сами собой. И их не нужно трактовать.

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

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

Кстати, хороший пример. Он демонстрирует, то что проблема не в ООП, а в абстракциях как таковых. Все тоже самое можно и на голых С-ях:

Buffer buffer;
InitBuffer(buffer, BufferPoolHandle, lpBuffer, nBufferSize);

Packet packet(PacketPoolHandle);
InitPacket(packet, PacketPoolHandle);

if (AddBufferToPacket(packet, buffer))
    miniport.send(packet);

Несколько длиннее, но по сути тоже саме. В сравнении с голым АПИ-шным прмером просто легко читаемый код.

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

_>microsoft в 2000, 2001 гг рассылал диски с Visual Studio.NET RC1, RC2...
_>я даже помню, что они были белого цвета
_>и при чем тут закрытое тестирование вообще

RC1 были или в самом конце 2001 или (что скорее) в 2002. В 2000 их быть немогло.

_>COM+ — это то, что было еше под Windows NT — только устанавливалось отдельно — называлось MTS
_>может внутрене .NET и реализован с использованием COM+ технологии, но так это совсем разные вещи

Блин, ткни по ссылки и почти чем языком молоть. Весь прикол в том, что КОМ+ — это альфное название прокта который выродился в сегодняшний дотнет. И работать ты на нем не мог.

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

AVK>Речь видимо не о СОМ+, а о СОМ+ 2.0

Нет, проект назывался именно СОМ+. СОМ+ 2.0 не сушествует по сей день. Версия того что вышло под маркой СОМ+ в W2k на сегодня дошла до 1.5.

В 1997 о том, что будет современный СОМ+ еще никто не знал. Тогда MTS то токлько-только вышел.

Просто дотнет планировался как развите идей КОМ-а. Типа СОМ 2.

Мужики, так вы вообще противники исключений!

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

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

V>>Ваша миссия как более опытного специалиста объяснить коллеге нюансы IMHO. Ничего личного.

VD>А что по-твоему проще объяснить "коллеге" или самому написать? И что будет когда объясняльщик уйдет и компании?

VD>Абстракции тем и хороши, что они понятны сами собой. И их не нужно трактовать.

Поддержка и развитие _сложного_ драйвера (по крайней мере для NT базированной OS) невозможна без поддержки
с помощью либо штатного специалиста, либо по договору поддержки и обслуживания с организацией или специалистом.

Есть еще вариант, когда развивать не требуется и все работает без проблем. Но контракт поддержки все равно
рекомендуется иметь.

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

_>> [Obsolete("use AddWithValue(string, object)", false)]
_>> public SqlParameter Add(string parameterName, object value) {
VD>Скорее всего там есть параметр типа энум. А разные орлы пытаясь сувать туда целочеисленное его значение налетали на боксинг и иную интепретацию. Ну, или еще что-нить в этом роде.

Почти угадал. Осталось только объяснить, почему два вызова Add порождают разный код:

SqlCommand cmd = new SqlCommand();
    object obj = 0;
    cmd.Parameters.Add("", obj);
    cmd.Parameters.Add("", 0);

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

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

_>>> [Obsolete("use AddWithValue(string, object)", false)]
_>>> public SqlParameter Add(string parameterName, object value) {
VD>>Скорее всего там есть параметр типа энум. А разные орлы пытаясь сувать туда целочеисленное его значение налетали на боксинг и иную интепретацию. Ну, или еще что-нить в этом роде.

_>Почти угадал. Осталось только объяснить, почему два вызова Add порождают разный код:
_>

SqlCommand cmd = new SqlCommand();
_>    object obj = 0;
_>    cmd.Parameters.Add("", obj);
_>    cmd.Parameters.Add("", 0);

Хочеш сказать, что 0 таки приводится к этуму автоматом? Нда, это грабли. Зачем они разрешили это совершенно не ясно. Видимо из-за инициализации нулем. Козлы, могли бы запретить хотя бы присваение литералов.

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

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

Но одного они добились. В NC отваживаются вмешиваться только очень смелые индейцы. Это позволяет МС менять NC в каждой версии ОС.

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

DG>>Это фича Windows-а — стандартные контролы Windows обрабатывает сама.

S>Чего? А CButton, CScrollBar (вот что фиг перепишешь, всмысле отрисовки) — это не часть MFC?

Это обертки над АПИ-шными контролами. CButton и CScrollBar отрисовкой не занимаются.

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

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

Ну, так уж и всегда. Знать конечно полезно. Но не обязательно. Просто уж если не знаешь, то понты лучше не кидать.