Re: Применим ли Си++ в серьезном коде? - Философия программирования

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

S>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar?

Нигде эта функция не зарыта. Ее вообще нет

. MFC не рисует скролбары — их рисует винда.

S> Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?

Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары которые есть у каждого окна — то тут немного нужно поплясять с бубном. Но к MFC это никакого отношения не имеет

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

S>>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar?

AJD>Нигде эта функция не зарыта. Ее вообще нет

. MFC не рисует скролбары — их рисует винда.
нее... Вы меня не понимаете вообще, ладно, пойдем по другому: как переписать отрисовку скроллбара?

S>> Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?

AJD>Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары которые есть у каждого окна — то тут немного нужно поплясять с бубном. Но к MFC это никакого отношения не имеет.

Про стандартные я вообще молчу, это действительно жопа. Ну-ну, попробуйте в производном классе от CScrollBar поперехватывать сообщение wm_paint, ехидство тут же поубавиться, гарантирую.
Хорошо, если считать mfc обертку воокруг winapi, тогда все мои претензии относиться к winapi, но сути это не меняет.

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

A>Что нужно было сделать? Проверить, можно ли в файл записать?

A>

A>bool try(char* path)
A>{
A>    FILE* f;
A>    if((f = fopen(path, "w")) == NULL)
A>        return 0;
A>    if(!fprintf(f, "Hello...\n"))
A>    {
A>        fclose(f);
A>        return 0;
A>    }
A>    return 1;
A>}
A>

А закрывать кто будет? Перед 'return 1'?

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

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

E>>P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.

VD>Можно узнать чем ООП может помешать драйверам?

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

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

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

NA>>При грамотном проектировании на C++ кода будет меньше, чем на C.
NA>>Одна из хороших черт ООП: инкапсуляция. Если классы правильно
NA>>реализованы и документированы, то разобраться что делает код можно
NA>>быстрее, чем на C.

MSS>Угу. На Си делается то же самое, путем использования слова static перед именем функции.

И действует только в пределах модуля.

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

Такие взгляды довольно распространены среди системных программистов.

S>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar? Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?

Еще раз:

1. Есть фича WIndows-а, именно Windows-а, как операционной системы, что стандартные контролы обрабатываются напрямую.
2. MFC предоставляет тонкие обертки над WinApi, т.е. получается, что MFC не перекрывает это поведение.
3. Вы не разобравшись, как устроены стандартные контролы, наступили на эти грабли
4. Вы в этих граблях обвинили MFC, и перестали использовать MFC.

Внимание, вопрос:
Можно ли в данном случае говорить о каком-либо профессионализме, или мы имеем дело с человеком, который плохо разбирается в той области, в которой работает?

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

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

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

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

VD>>>>Сдается мне, что сей труд написан на днях.

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

A>>Ссылочку пожалуйте.

V>Можно найти в архивах www.osronline.com

http://www.osronline.com/lists_archive/ntdev/thread4355.html

S>Про стандартные я вообще молчу, это действительно жопа. Ну-ну, попробуйте в производном классе от CScrollBar поперехватывать сообщение wm_paint, ехидство тут же поубавиться, гарантирую.

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

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

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

A>>В Америке и в Москве МакДональдс — это небо и земля.

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

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

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

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

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

_>>>я не понял что ты имеешь в виду — человек писал, что в 2001 C# не было, а я писал, что был.

VD>>Человек — это был я. Так вот официально С# вышел в 2002 году. Его бетатестирование было закртытым и сотрудник МС распространяться про него да еще так вольготно словно о нем все давно знают в 2001 попросту не мог. Его а) никто бы не понял, б) выгнали бы с работы.

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

_>и при чем тут закрытое тестирование вообще

Как щас помню. Осень 2000, PDC, VS.NET alpha...

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

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

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

... << RSDN@Home 1.1.4 beta 2 >>

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

G>>Да, только у человека с высокой квалификацией этот объем повыше чем к примеру у
>>алканафта-слесаря.

MSS>Незнание азов эргономики.

MSS>Объем внимания у всех примерно одинаков (при алкоголизме, может, и меньше, но я про здоровых людей).

MSS>Объем внимания такой же.

Это так.

MSS>>>Это вопросы азов эргономики.
G>>А че там эргономика говорит нам про оператор сдвига?

MSS>Есть понятие "визуальный шум". Излишняя визуальная информация, не нужная для решения задачи, а то и отвлекающая от нее.

MSS>Пример — static_cast<type>(x) — static_cast<> — визуальный шум, а (type)(x) — уменьшение визуального шума.

MSS>Пример — Kernel::SetEvent по сравнению с KeSetEvent. Лексема :: — визуальный шум.

А не является ли визуальным шумом strcat? А таблицы виртуальных функций, если их реализовывать на C вручную? Вопрос не о наличии визуального шума — он есть в любом языке — а в его количестве. Так вот — в любом сложном проекте (сложность котого на проявляется на архитекутрном, а не на алгоритмическом уровне) — C++ даёт существенно меньше визуального шума.
Кроме того — на лицо подмена понятий:
static_cast<type>(x) != (type)(x)
static_cast выдаст ошибку на этапе компиляции, если преобразование не возможно, а вот (type)(x) прекрасно пройдёт компиляцию — даже если выражение абсолютно бессмысенно. Потому добавленые в C++ static_cast, dynamic_cast, reinterpret_cast — гораздо нагляднее и безопаснее, так как проводят проверки как на этапе компиляции, так и в Runtime, кроме того — позволяют явно выразить свои намерения — что имелось в виду при написании кода. Да и потом — лукавите батенька!

В C++ вы по прежнему можете писать (type)(x) — так что аргумент насчёт визуального шума тут не проходит.
Кроме того, для опытного программиста CloseHandle( hThread ) или if( hFile == INVALID_FILE_HANDLE ) — гораздо больший визуальный шум, чем static_cast — хотя бы потому, что первые на C будут встречаться гораздо чаще, чем преобразования типов, кроме того, CloseHandle — как правило вообще полезной информации не несёт. Обычная рутинная операция освобождения ресурсов, только загрязняет алогритм, не внося какой либо ясности — наоборот только усложняя алгоритм.
C++ позволяет легко скрыть или упростить подобные казусы — как раз уменьшив визуальное загрязнение:
Очевидно, что:

 CFile obFile;
 if( !obFile.Open( "Somefile" ) ) return FALSE;

 CObj  obObj;
 if( !obFile.Read( obObj ) ) return FALSE;

 obObj.Execute();

 return TRUE;

Содержит гораздо меньше визуального шума, чем:

HANDLE    hFile;
 DWORD     dwBytesRead;
 TObjType  Obj;

 hFile = CreateFile( "Somefile", 0, 0, NULL, 0, 0, NULL );
 if( hFile == INVALID_FILE_HANDLE ) return FALSE;

 TObjTypeInit( &Obj );
 if( ( !ReadFile( hFile, &Obj, sizeof( TObjType ), &dwBytesRead, NULL ) ) || ( dwBytesRead != sizeof( TObjType ) ) )
 {
    TObjTypeExit( &Obj );
    CloseHandle( hFile );
    return FALSE;
 }
 
 TObjTypeExecute( &Obj );

 TObjTypeExit( &Obj );
 CloseHandle( hFile );

 return TRUE;

И это при примитивной логике. Добавим сюда композитный Obj — и мне жалко того, кто будет не то что писать — читать такой код...

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

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

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

MSS>>Гы! У MSа давно есть свои собственные коды. %p, например. Печатает пойнтер. 64бита на Win64, 32 бита на Win32.

A>Почему у MS?
A>Не далее чем вчера под пингвином так указатли распечатывал.

Скорее — новые крос-платформенные коды для поддержки 64 битных платформ...

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

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

A>>Что нужно было сделать? Проверить, можно ли в файл записать?

A>>

A>>bool try(char* path)
A>>{
A>>    FILE* f;
A>>    if((f = fopen(path, "w")) == NULL)
A>>        return 0;
A>>    if(!fprintf(f, "Hello...\n"))
A>>    {
A>>        fclose(f);
A>>        return 0;
A>>    }
A>>    return 1;
A>>}
A>>

WF>А закрывать кто будет? Перед 'return 1'?

Неважно. Зато на C!

А баг любой может исправить неглядя, поставив fclose(f) перед fprintf для верности

.

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

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

S>>>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar?

AJD>>Нигде эта функция не зарыта. Ее вообще нет

. MFC не рисует скролбары — их рисует винда.
S>нее... Вы меня не понимаете вообще, ладно, пойдем по другому: как переписать отрисовку скроллбара?

S>>> Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?

AJD>>Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары которые есть у каждого окна — то тут немного нужно поплясять с бубном. Но к MFC это никакого отношения не имеет.

S>Про стандартные я вообще молчу, это действительно жопа. Ну-ну, попробуйте в производном классе от CScrollBar поперехватывать сообщение wm_paint, ехидство тут же поубавиться, гарантирую.
S>Хорошо, если считать mfc обертку воокруг winapi, тогда все мои претензии относиться к winapi, но сути это не меняет.

А ты попробуй заставь ComboBox обновлять элементы списка при раскрытом списке...

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

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

MSS>>>> Творческое пользование темплейтами также сможет доставить потомкам
MSS>>>> немало приятных минут.
S>>>Бывает. Но если нет шаблонов, то вместо них на помощь приходят макросы... А
S>>>это вообще жопа.

MSS>>Темплейты как раз хорошая фича. Одна из лучших в Си++.

MSS>>>> Вышли из блока -- значит, вышли, и нечего кроме.
S>>>И забыли закрыть половину хэндлов....

MSS>>Сразу видно. Локально видно. Легко править.

Ш>Сказок, пожалуйста, не надо рассказывать.

Почему же сказок? Человеку надо видеть что ему править. Мысль о том, что код может не содрежать примитивных ошибок — вроде незакрытого вовремя дескриптора, а содержать ошибки концептуальные, семантические — в голову видимо не приходит...

VD>Кстати, году в 1994 я наблюдал изумительный пример маразма в этой области. Одному орлу поручили написать функцию преобразоватия числа в строку прописью (русское написание числа). Так вот он вместо того, чтобы написать одну простую функцию состряпал класс. Это надо было видить. Я плякаль... После этого мы переписали его код выбросив процентов 40. Но это же не проблема ООП. Это проблема умения выделять абстракции.

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

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

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

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

S>>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar? Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?

DG>Еще раз:

DG>1. Есть фича WIndows-а, именно Windows-а, как операционной системы, что стандартные контролы обрабатываются напрямую.
DG>2. MFC предоставляет тонкие обертки над WinApi, т.е. получается, что MFC не перекрывает это поведение.
DG>3. Вы не разобравшись, как устроены стандартные контролы, наступили на эти грабли
DG>4. Вы в этих граблях обвинили MFC, и перестали использовать MFC.

DG>Внимание, вопрос:
DG>Можно ли в данном случае говорить о каком-либо профессионализме, или мы имеем дело с человеком, который плохо разбирается в той области, в которой работает?

Но, перед тем как катить бочки, надо вообще-то читать всё до конца.

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

Про 2)
Надо читать мои посты, прежде, чем професионнализм свои крутой показывать.

Про 3)
Ну-ну...

4)
Логика железная, я не сказал что перестал, я его использую по минимуму.

DG> Это стандартная задача, этому посвящено очень много статей и литературы.
В данном случае, не стоило изобретать велосипед, а стоило хоть один раз прочитать хорошую статью, которая рассказывает, как это делается.

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

WH>Дополнять существующий очень сложно. Да и проблем в нем хватает... Взять хотябы A Little Detail in Overload 60
WH>Про Сишные маразмы я вобще молчу.

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

Кто-нить реально пользуется этой фичей Си++?

И каким боком из деструктора делается то, что может возбудить ситуацию? Там что, делается то, что может обломиться? Сразу откровенный маразм.

AVK>Ты что то путаешь. IDE под винды появилось только в 4.0.

Неправильно. В 3.0.

3.1 — это 3.0, слегонца переделанный (в основном по библиотекам) для совместимостью с Windows 3.1.

BC++ 3.0 был старше, чем Windows 3.1, и ее плохо поддерживал.

AVK>И OWL в те времена был только для BP.

Неправильно. Она в BC++ 3.0 появилась еще.

Борланда 4.0 я уже не видел, потому как перешел на Вижуал Си — тогда 1.51. Сплетни, правда, ходили, что OWL чуть ли не с нуля переписали между 3.1 и 4.0.

	От:	AndrewJD
	Дата:	13.06.04 21:43
	Оценка:	+1

	От:	Shhady
	Дата:	13.06.04 22:06
	Оценка:

	От:	WFrag
	Дата:	14.06.04 04:21
	Оценка:

	От:	AndreyFedotov
	Дата:	14.06.04 06:15
	Оценка:	+1

	От:	AndreyFedotov
	Дата:	14.06.04 06:40
	Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	14.06.04 06:55
Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	14.06.04 07:45
Оценка:

	От:	Maxim S. Shatskih
	Дата:	14.06.04 08:25
	Оценка: