S>Хорошая. Но в неумелых руках такая же опасная, как и объявление функции без S>аргументов в C. И виртуальные функции — тоже хорошая фича,
Тоже хорошая. У темплейтов, кстати, неудачный синтаксис — но я не стану вслед за Завалишиным заявлять, что это "редкий пример того, где все сделано плохо".
Насчет опасности — там хотя бы все явно написано, и глаза мозолит. Нет неявностей. И реально экономит кучу труда — взять тот же std::vector<T>.
operator T() по сравнению с этим — ой-ой фича. Почти не экономит никакого труда, и вносит скрытую семантику.
S>хотя и не такая опасная, как шаблоны. И что самое главное, обе этих фичи S>позволяют избежать дулирования кода, что радикально облегчает сопровождение S>программ.
Иногда наследование хуже, чем дублирование кода.
S>Править, может, и легко, а вот дописывать новую функциональность — трудно. S>Кроме того, налицо подмена понятий — цель не в том, чтобы ошибки исправлять S>легче было, а в том, чтобы ошибок меньше было, при тех же трудозатратах.
Для этого а) должно быть легче исправлять ошибки б) в языке должны быть средства, которые просто не дадут написать ошибку.
S>Смотря какой. Хотя даже для x86 — не сложнее С, примерно одна фигня. А вот S>писать на нем — сложнее чем на С. А на С++ писать проще, если квалификация S>позволяет.
Ага, а потом расползается все тоже весело. Даже у квалифицированных.
S>Чтоб за деревьями леса не увидеть...
Во! Баги как правило — в отдельных деревьях.
Сторонники "увидеть лес в целом" об этом забывают.
S>раз нерешливо написанную на С программу переписать на С++
Неряшливо написанная программа на Си++ — еще хуже
S>А насчет новичков — это сейчас их в С не осталось, а посмотреть на S>ширпотреб, написанный в конце 80х-начале 90х годов "среднестатистическим S>программистом". На С++ мне такой кошмар ни разу не попадался.
WH>Си вариант с деталями.(а все ли я учел? очень давно с WinAPI на прямую не >работал )
Все во врапперах, что ли? Верх маразма.
WH> if(file==INVALID_HANDLE_VALUE)//За этим мне тоже пришлось лезь в MSDN ибо иногда >не валидный хендел NULL и иногда INVALID_HANDLE_VALUE
Ну, тут микрософт лоханулся, конечно, то INVALID_HANDLE_VALUE только из CreateFile возвращается.
WH> bool res=WriteFile//И опять таки без MSDN не обошлось
Врапперы твои не требуют чтения документации? это только тебе так кажется
WH>Имея обертку которая просто делегирует вызовы в Qin32API
А! Вот оно! Сначала зовем конструктор, потом ::is_valid(). Супер просто.
И чем плохи магические константы? Лучше, чем врапперы.
WH> //избавились от необходимости создавать промежуточную переменную для запоминания >результата WriteFile
А она мешала?
WH>//Хотя за параметрами опять надо лезть в MSDN.
Теперь резюме. Ты написал код, понятный только тебе. Твой же сосед по офису его не поймет. Ему придется долго и занудно читать башку с врапперами, которые сочинены тобой и понятны только тебе.
Или эта башка — корпоративный стандарт? Тогда изучать все это пустобрешество (а такие врапперы — именно оно и есть, потому как они функционала не несут) — придется каждому вновь прибывшему новичку.
И за инфой по врапперам придется лезть не в хороший MSDN, а во внутреннюю документацию, которая наверняка хуже.
И человек, который за тобой будет код править, скорее всего выкинет врапперы на помойку и напишет "по MSDNу".
WH>Однажды пришлось править код одного "программера со стажем" который не знал что такое >смартпоинтеры и для чего надо писать обертки...
Это вопрос того, что Win32 у нас очень низкого уровня. Например, он async IO умеет, который для таких задач не нужен.
WH>А для работы ИМХО хорошей идеей является абстракция типа WH>[ccode] WH>struct binary_stream_reader WH>{ WH> virtual size_t read(void* buf, size_t size)=0; WH> virtual bool is_valid()=0; WH>};
Это да. Только я бы ISequentialStream использовал бы уже за меня объявлен микрософтом
Кстати — на кой черт is_valid виртуальный? Зачем это? ну не маразм ли — делать виртуальным тот метод, который зовется только сразу за конструктором?
Еще забыли про деструктор или release. Раз уж есть хоть один виртуальный метод — то виртуальный деструктор — это святое.
WH>Если пасать код под binary_reader то работа с файлом, блобом или еще какой структурой >с произвольным доступом будет совершенно одинакова. А если писать под >binary_stream_reader то вобще можно работать с любым потоком...
Вряд ли мне надо рассказывать, что полиморфизм — это хорошо.
WH>Ибо The devil is in the details. и чем деталей меньше тем лучше.
Сами по себе обертки уже есть детали. Те самые.
А если баг в обертке где? Ой млиииин...
E>А не надо файлы исходников листать. Надо диаграммы классов и состояний смотреть. Это >следующий уровень абстракции.
...и он скроет как раз те детали, от которых зависит производительность и надежность кода...
MSS>>Прекрасный пример! Многомиллиардная корпорация! E>Ну если ты считаешь, что делает McDonalds — хорошо
Это нормально. По крайней мере это не совковая столовка с блевотными подносами, вытертыми грязной тряпкой.
И не Ростикс какой-нить, где в зале кухней воняет.
E>Ты свою семью в McDonalds поведешь?
Иногда по пути заходим мороженое съесть.
И разговор-то не о том. А о том, что Макдональдс — успешный бизнес. Вот и все.
NA>При грамотном проектировании на C++ кода будет меньше, чем на C. NA>Одна из хороших черт ООП: инкапсуляция. Если классы правильно NA>реализованы и документированы, то разобраться что делает код можно NA>быстрее, чем на C.
Угу. На Си делается то же самое, путем использования слова static перед именем функции.
VD>Може, то выглядет смешно. Кстати, в 2001 это тоже вряд ли могло быть написано. Дотнет >официально вышел в 2002-ом и трепаться о Шарпе в таком стле разумный человек работающий >на МС не стал бы.
Не стал бы как представитель компании на публике. В узком кругу — пожалуйста.
V>Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где- >то назад на редмондовском V>форуме разработчиков драйверов (в частности в нем участвуют многие ключевые >разработчики NT).
Да. Еще и на английский его сам перевел.
И развел там flamewar, но — надо заметить — там народ поопытнее, и меньше людей, которые с барабаном на шее возглавляют колонну защитников ОО, при этом не зная, чем RTTI противоречит полиморфизму.
V>Высокая стоимость сопровождения кода C++ и вред скрытой семантики — факт.
Особенно врапперы всех мастей сюда вклад вносят. Поубивав бы вот это точно самый настоящий "код с душком".
V>Но главным критерием на мой взгляд является уместность употребления языка в конкретном >культурном контексте и традиции.
Совершенно верно.
V>Хорошо то, что принимается сообществом (или большей/авторитетной частью с возможными >исключениями) и соответствует большинству доступных материалов.
Угу. Пример — Numega DriverStudio. Допустил багу в коде на ней — и все, трында, помощь на форуме почти невозможна.
Потому как мало кто ей пользуется. А если человек ее не знает — первая мысль — "а, ну тут, наверное, эти самые классы использованы не так, как надо" — и все.
Реальная поддержка возможно только от Нумеги, а она у них — по сравнению с Майкрософт и просто сообществом — слабенькая совсем.
V>Для системного программирования (режим ядра) — С, в других областях — могут быть >другие языки.
Конечно. И есть критерии даже.
Цена баги в человеко-часах. Любой UI по этому параметру — сразу относится к простому программированию. Сразу. Потому как любой баг в UI находится мгновенно. Потому как у UI крайне редко бывают interop issues.
А высокая сложность — написание прибамбасов снизу и сбоку к любой системе. Особенно если система без исходников. Особенно если средства отладки подчас требуют ребута каждый раз. Заметим — я описал системное программирование под Windows.
Или же вообще нет толком средств отладки, как для Pocket PC.
Когда высока цена баги, то лучше уж сделать так, чтобы вся логика бесстыдно смотрела в глаза. Тогда баг проще найти вычиткой, не связываясь с отладкой — а в таких средах очень часто именно вычиткой баги и находят.
VD>2 возможно. Но в 2001 ти слова вряд ли могли прозвучать.
Почему? Человек, видимо, имел отношение к разработке микрософтного компилятора Джавы.
Кстати, я не знаю, что там за грабли в Джаве он нашел... ИМХО она как раз свободна от многих извратов Си++. Действительно ОО, а не пародия на него.
VD>Во-во. И если уж говорить о стоимости сопровождения и развития, то плевки в сторону >явы и плюсов выглядят просто смешно.
Ну Джавы — возможно. Там нет operator+ и прочих abstract datatypes наворотов, которые, кстати, к ОО отношения не имеют. Это из другой оперы.
VD>[b]На сегодня важна не простота в смысле приметивности. Важна простота в смысле >непротиворичивости, отсуствия множества способов выражения одного и тогоже,
Да. А вон почитай, как тут человек признавался в романтической любви к Си++ именно потому, что там одно и то же можно выразить по-разному
>концептуальной стройности
Си++ ее давно утерял, да и не факт, что имел (в отличие от Джавы и Шарпа).
VD>Сдается мне, что Шарп все же новый универсальный язык, а не замена жлабэйсику.
Да-да-да.
VD>Ну, NT далеко не на С написан. Ядро возможно. Но оно не составляет основную часть ОС.
Ядро.
Все подсистемы ядра кроме софтового РАЙДа (и его на помойку выбросили, заменив купленной у Веритаса урезанной версией VxVM) и PortCls
SMSS
LSA
Короче, почти все, где нет UI. А вот где UI — там сразу Си++.
Еще прикол. Графический движок в НТ написан на Си++, еще в 91-92 годы. У микрософта тогда не было компилятора, и пользовали cfront. А вот API для драйверов видеокарт — Сишный. Все эти CLIPOBJ_bEnum есть Сишный враппер вокруг CLIPOBJ::bEnum.
Вот такие вот дела. Интересно, на чем XFree86 написан — на Си или Си++?
>Да и переносимость NT на сегодня уже ушла в прошлое (все Мипсы и ППиСи давно забыты).
Зато не забыт IA64, который не имеет ничего общего с x86, и во многом дальше от него, чем MIPS.
VD>Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT >ведь в свое время была написана с чистого листа (только на основе опыта и знаний).
Ага, только опыт и знания были накоплены на VMS некоторые ключевые структуры имеют дословные аналоги в VMS — типа IRP и MDL.
>настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать >каую-нить Каиру.
Cairo — внутреннее имя для DCOM. Он-то тут причем?
VD>Быстрота? На IA64 виндовс портируется уже лет пять, и все есть проблемы.
Проблемы с продвижением процессора на рынок, а не с Windows, которая действительно уже пять лет как там на ура работает.
Доказательство: на Итаниуме есть еще и Линукс, и это не увеличивает продажи Итаниума. Проблемы таки с Итаниумом.
VD>Сдается мне что партирование даже на близкие платформы дается МС не дешего. Именно по >этому и забили на PPC и Mips. Денег приходилось вкладывать море, а окумпаемость фиговая.
По обмолвкам на форуме одного из ключевых людей, которые портировали NT на PPC, получается, что NT на PPC стала коммерчески нафиг никому не нужна тогда, когда Стив Джобс удушил юридически рынок клонов Макинтошей. В конце 90х.
Теперь общие соображения. Пентиум и Атлон — едва ли не быстрее всех этих Спарков и МИПСов. По целочисленной арифметике быстрее. Причина понятна — у Интела и АМД лучшая силиконовая технология, лучше, чем у Сана и Тексас Инструментс, которые Спарки делают на пару. Лучше, чем у MIPS. И так далее.
Дальше. Сам процессор типа Спарка может стоит дешевле, чем Пентиум. Но он у нас собственность конкретной компании, которая заодно собирает на нем машины и к ним дает ОС. На этот рынок воткнуть свою ОС очень сложно. Для этого та родная ОС должна быть совсем отстой.
Именно потому порт НТ просто принесет совсем немного денег Майкрософту. Вот и все. Итаниум — другой разговор. Все еще есть шансы, что это будущее массовых десктопов. Такую штуку Майкрософт не упустит.
Более того. Есть сплетня, что DEC потребовала от Майкрософта разработать порт Альфы, угрожая судом насчет того, что Катлер унес некоторые конфиденциальные сведения о VMS, на опыте которой была основана архитектура НТ. Якобы без этой угрозы и на Альфу НТ бы не портировал никто.
VD>Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых >(в том числе и раньше) платформ.
Да, уже давно. И на ARM есть, и на SH есть, и на MIPS есть.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Из каких соображений придумывали ОНИКС? Есть ли там какая-то идея, вокруг которой язык придумывали? Или он придуман ради удовлетворения тщеславия кого-то шибко умного?
Основная идея — чтобы любой испытатель космических аппаратов, не знавший до этого, что такое программирование, смог бы научится быстро писать испытательные программы. Этого они, скорее всего, достигли: я смог писать программы через 2 дня после знакомства с ним, а через месяц уже почти не заглядывал в документацию (120 стр. ядро + 80 стр. прикладная часть, из-за которой и придумывался ОНИКС, как часть системы исполнения испытательных программ). Хотя я бы предпочёл, чтобы всё это было оформлено в виде библиотеки на обычном С.
MSS>10-15 лет назад говорили то же самое. Воз и ныне там.
Ставлю на 2-ю половину этого столетия
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вот такие вот дела. Интересно, на чем XFree86 написан — на Си или Си++?
Чистый С.
MSS>Ага, только опыт и знания были накоплены на VMS некоторые ключевые структуры имеют дословные аналоги в VMS — типа IRP и MDL.
>>настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать >>каую-нить Каиру.
А самое инетресное, что посмотрев исходники Вин2К пришел к выводу, что ядро не правилось этак с 96-го года... (ну ессесено драйвера правилились, но основные системы похоже что нет )
)
