Вы знаете, я вообще-то достаточно долго занимался разработкой компиляторов. Как-то, разговаривая с Игорем Васильевичем Поттосиным (одним из крупнейших специалистов в области оптимизирующих компиляторов) лет 15 назад -- я тогда был еще молодой -- я поинтересовался, с какой целью мы тратим невероятные усилия на разработку новых методов оптимизации и проч., если процессоры, согласно закону г-на Мура, становятся вдвое быстрее каждые полтора года? -- обычно код, порожденный предельно тупым компилятором ("что вижу, то и пою"), медленнее оптимального ну в полтора, ну в два раза (для RISC и CISC архитектур); поскольку в скором времени "плохой" код на новой машине будет работать столь же быстро, как и хороший на старой, имеет ли смысл так упираться?
В ответ на это Игорь Васильевич заметил, что я далеко не первый, кто задает этот вопрос, -- он его регуляно слышит начиная года так с 60-го. Ответ заключается в том, что, как бы много вычислительных ресурсов не было, программисты найдут способ занять их все, посему выжимание из машины всего, чего она может, есть хорошо и будет хорошо еще долго.
И.В., безусловно, прав. Вы все помните, как здорово работал Ворд на 286. На 386 он бы просто взлетел, но эти редиски -- наши коллеги из Офиса -- перенесли его на Винды и сделали графическим (появилась новая вычислительная мощность -- чего бы ее не занять?). Появился 486 и, казалось, Ворд снова должен взлететь, так нет, вставили туда какую-то проверку орфографии текста, которая работает всегда, и снова вычислительных ресурсов стало остро не хватать. И т.д. и т.п. Если кто-то думает, что 1.5 ГГц Пентиума-4 хватит на все случаи жизни, то он глубоко ошибается. 1.5 GHz P-4 -- примерно половина того, что нужно для сжатия телевизионного сигнала в реальном времени, я уже не говорю о полноценном распознавании речи.
Таким образом, скорость работы программы важна. Практика показывает, что если программа (серьезная, а не демонструшка в 1000 строк) работает слишком быстро, в нее немедленно добавляется какая-нибудь забавная функциональность, которая увеличивает объем продаж на 10% и съедает все ресурсы.
Ни программы на Java, ни на C# -- по 100 разных причин -- не работают и никогда не будут работать столь быстро, как на Си. Ну язык левой ногой задизайнен, что тут сделаешь, -- разработчики компиляторов не винованы, что создатели Жабы были в языках программирования и компиляторах ни уха ни рыла, посему там грабли разложены очень ровным слоем просто везде. Жаба, господа, это просто атас, а реализация ВМ (виртуальной машины) Саном -- это песня. Смотришь, и сразу понятно, -- ребята делают первую в их жизни ВМ. Ляп тут, ляп здесь, засада за углом, обломс там... Скажем все дружное спасибо фирме Сан, которая вбахала в пропаганду и распространие этого убожества несколько миллиардов баксов и таки добилась своего.
Кроме того, есть еще один очень существенный момент. Собственно написание кода -- это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов и проч) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять в лес намыливается...
И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение.
Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как.
И вот тут начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, исключительными ситуациями и проч.
Ну скажите мне, часто ли в Си встречаются указатели на функции? -- исключительно редко, и только по делу. Поэтому, увидев вызов функции в Си, как правило сразу понятно, какая именно функция вызвалась, можно сходить и посмотреть, что она делает.
В ОО-же языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, хрен поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.
Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором.
В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на ОО языке, не разберется никто.
Посему, как показывает мой личный опыт, надежность программ, размашисто написанных на ОО языках, оставляет желать лучшего (конечно, если менеджер следит за тем, как пишут код и за творческое использование языка программирования немедленно дает по ушам, то дело, конечно, другое. К сожалению, грязного кода на ОО языках я видел на порядок больше).
Я уже не говорю про перекрытие операторов, конструкторов копирования и проч. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события?
Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же программа начинает напоминать сводку новостей времен СССР и приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на ОО языках наломать дров проще простого, что мы и наблюдаем изо дня в день.
Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен олигофрену, иначе человек, который заменит Вас через 2-4 года, не справится.
Хотите проинициализировать переменную? -- вызовите процедуру. Надо вызвать функцию? -- зовите ее напрямую. Не надо вот этого -- посылания сообщения в Жаба-скрипт, который исполнит XML (взяв его из Registry), который запустит ActiveX контрол, который и сделает, что надо, позвав вашу процедуру через COM-интерфейс (Вы смеетесь? -- зря. Я именно такой код чинил год назад. Очень надеюсь, что создатель этого маразма больше в МС не работает).
Связная тема -- сложность языка программирования. Стардарт языка Си -- 200 страниц. Си++ -- почти 1000 (и достаточно много отдано на волю разработчика компилятора). Та отписка, которая должна подразумевать собой описание семантики Жабы, -- это просто смех.
Ее авторы скромно обошли молчанием самые интересные и интригующие моменты (ну, все те, где грабли лежат) -- которые и вызывают самый искренний интерес у разработчика компилятора, -- видимо, справедливо полагая, что как ни сделаешь, хуже уже не будет.
Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает более 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?
Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен (а все ведь под него проточено, не так ли?). Наконец, необходимым требованием является 100% backward compatibility библиотек. Ну скажите мне, хоть одна библиотека для Жабы удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о том, что на изучение этих библиотек может уйти полжизни.
Опять же, смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Что касается Си, то всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью [программистов]. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, посему вероятность обнаружить ошибку в компиляторе с Си гораздо ниже, чем в компиляторе с Си++ (чтобы найти баги в компиляторе с Жабы, в особенности Сановском, напрягаться не нужно, -- баги Вас сами найдут).
Резюмирую. При создании операционных систем и большинства других серьезных проектов предъявляются очень жесткие требования к производительности и надежности.
Первое существенно зависит от языка программирования. Второе зависит от как от тестирования, так и от дисциплины программирования и читаемости/модифицируемости кода, которые также достаточно сильно связаны с языком.
Если внимательно посмотреть, то все хорошие серьезные программы на Си с примесью ассемблера. Ворд. Эксель. Ядро НТ. Ядро Линукса. Кодогенераторы (VC, GNU, etc. Гнусный кодогенератор, конечно, никуда не годится, но про удачном расположении звезд может и правильный код породить). Единственная хорошая программа, написанная на Си++, знакомая мне, -- это MS SQL сервер.
Посмотрим же теперь на софт, написанный на Си++. Exchange Server. Outlook. PowerPoint. WMP. Нужны комментарии?
Конечно, все вышесказанное относится к большим промышленным проектам, где объем кода измеряется миллионами и десятками миллионов строк и над которым работает хотя бы человек 50. К софту класса "t.c" длиной в 100 строк это не относится -- это можно писать на любом языке программирования.
пи-эс. Я тут много пинал Жабу и мало -- C#. Однако, учитывая вышесказанное и тонкую связь, имеющую место быть между этими двумя языками, полагаю, что есть основания считать, что и проблемы у них будут достаточно общими. Хрен, он ведь редьки не слаще.
Hello, Maxim!
You wrote on Fri, 11 Jun 2004 07:13:38 GMT:
MSS> Ко мне этот текст попал в конце 91го года. Он довольно старый, и
А разве Жаба тогда уже была?
MSS> В ответ на это Игорь Васильевич заметил, что я далеко не первый, кто MSS> задает этот вопрос, -- он его регуляно слышит начиная года так с MSS> 60-го. Ответ заключается в том, что, как бы много вычислительных MSS> ресурсов не было, программисты найдут способ занять их все, посему MSS> выжимание из машины всего, чего она может, есть хорошо и будет хорошо MSS> еще долго.
Вот тут он явно прав — быстродействия много не бывает.
MSS> Ну скажите мне, часто ли в Си встречаются указатели на функции? -- MSS> исключительно редко, и только по делу.
Ага, щаз.
MSS> Поэтому, увидев вызов функции в Си, как правило сразу понятно, какая MSS> именно функция вызвалась, можно сходить и посмотреть, что она делает.
Особенно если она использует 25-30 глобальных переменных. Чиста на 5 минут
дело
MSS> В ОО-же языках, где народ (в особенности вчерашние студенты) любят, ой MSS> как любят переоперделять функции, хрен поймешь, какой из 15 MSS> виртуальных методов будет вызван в данном контексте, и читать текст их MSS> всех дело утомительное. В результате починка бага занимает в 3-5 раз MSS> больше времени.
Эмуляция полиморфизма на С — гораздо страшнее
MSS> Перейдем к деструкторам и конструкторам. Видит программист описание MSS> локальной переменной, которая нигде не используется, и, ничтоже MSS> сумняшеся, херит его.
Значит, или идиот, или новичок. Что способны такие люди написать на С, я
видел. Автор, похоже, нет.
MSS> В результате программист (по-хорошему) вынужден прочитать описания MSS> всех конструкторов и деструкторов по всей цепочке наследования всех MSS> локальных cтруктурных переменных процедуры. Кому хочется шариться по MSS> 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто MSS> этого и не делает, в результате через 3 года в программе, лихо MSS> написанной на ОО языке, не разберется никто.
Это если ламеры писали.
MSS> Посему, как показывает мой личный опыт, надежность программ, MSS> размашисто написанных на ОО языках, оставляет желать лучшего
Надежность программ, размашисто написанных на любых языках,
оставляет желать лучшего.
MSS> Я уже не говорю про перекрытие операторов, конструкторов копирования и MSS> проч.
При правильном использовании способно избавить от разбирательства с
деталями.
MSS> Творческое пользование темплейтами также сможет доставить потомкам MSS> немало приятных минут.
Бывает. Но если нет шаблонов, то вместо них на помощь приходят макросы... А
это вообще жопа.
MSS> А чего стоят исключительные события?
Сложный вопрос. Иногда значительно меньше, чем коды ошибок.
MSS> Почему-то получается, что код, написанный на языке программирования MSS> без скрытого поведения, поддерживать и сопровождать гораздо легче.
Щаз. Достаточно пару раз глянуть на MS'овский любимый "goto cleanup" чтоб
понять, что это не так.
MSS> Вышли из блока -- значит, вышли, и нечего кроме.
И забыли закрыть половину хэндлов....
MSS> Что написано, то и происходит.
А это и в C++ так — просто читать надо уметь
MSS> Когда же программа начинает напоминать MSS> сводку новостей времен СССР и приходится докапываться до третьего слоя MSS> истины -- это бардак. К сожалению, на ОО языках наломать дров проще MSS> простого, что мы и наблюдаем изо дня в день.
Честно говоря, я в этом вопросе больше доверяю Кернигану и Пайку, которых в
предубеждении к С трудно обвинить. Цитирую: "C is a razor-sharp tool, with
which one can create an elegant and efficient program or a bloody mess". Про
С++ они куда спокойней отзывались.
MSS> Очевидно, что чем проще язык программирования, тем трудней сделать на MSS> нем семантическую ошибку.
Если б это было правдой, все бы до сих пор писали на ассемблере.
MSS> Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного MSS> программирования, — чем проще, тем лучше.
И чем больше — тем лучше. Сишного рантайма категорически не хватает.
MSS> Опять же, смежная проблема. Возраст языка. Чем старше язык, тем лучше MSS> и глубже его знают программисты. Что касается Си, то всем известно, MSS> что можно делать, чего нельзя, а что можно, но лучше не нужно. С MSS> новомодными языками дело обстоит сложней, и опыт, равно как устав MSS> караульной службы, пишется кровью [программистов].
Да, в 91 году это было очень актуально. Достаточно посмотреть на
MFC... Сейчас сложнее найти грамотного программиста на С, чем на С++.
MSS> Наконец, не следует забывать, что разработчики компиляторов тоже не MSS> боги и могут ошибаться, посему вероятность обнаружить ошибку в MSS> компиляторе с Си гораздо ниже, чем в компиляторе с Си++
Да-да, давайте все в машинных кодах писать — в процессорах багов точно
меньше, чем в связке процессор-компилятор
MSS> Резюмирую. При создании операционных систем и большинства других MSS> серьезных проектов предъявляются очень жесткие требования к MSS> производительности и надежности.
Угу.
MSS> Первое существенно зависит от языка программирования.
С + asm здесь рулят.
MSS> Второе зависит от как от тестирования, так и от дисциплины MSS> программирования и читаемости/модифицируемости кода, которые также MSS> достаточно сильно связаны с языком.
Так точно. И С здесь совершенно не конкурентоспособен.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 alpha
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
MSS>Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором.
А я иногда создаю переменную типа CWaitCursor и нигде ее не использую. Похоже, меня тоже скоро уволят.
Здравствуйте, Maxim S. Shatskih, Вы писали:
S>>И забыли закрыть половину хэндлов.... MSS>Сразу видно. Локально видно. Легко править.
А в моих программах ошибок такого класса вобще нет и быть не может. Ибо взятся им не откуда... любимые тобой деструкторы все хендлы закрывают обожаемым тобой скрытным образом...
The devil is in the details.
Великая фраза... А иметь дело с дьяволом...
А вывод из этого: Не имей дело с деталями те детали должны быть спрятаны.
Взят хотябы бональную работу с файлами...
Си вариант с деталями.(а все ли я учел? очень давно с WinAPI на прямую не работал )
bool write_some_in_file1(char const* name)
{
HANDLE file=CreateFile//Когда я первый раз пытался с помощью Win32API пытался прочитать фаил я долго искал OpenFile...
(name//Для того чтобы заполнить параметры функции мне пришлось лезть в MSDN.
,GENERIC_WRITE
,0
,0
,CREATE_ALWAYS
,0
,0
);
if(file==INVALID_HANDLE_VALUE)//За этим мне тоже пришлось лезь в MSDN ибо иногда не валидный хендел NULL и иногда INVALID_HANDLE_VALUEreturn false;
DWORD bytes=0;
bool res=WriteFile//И опять таки без MSDN не обошлось
(file
,name
,strlen(name)
,&bytes
,0
);
CloseHandle(file);
return res;
}
Имея обертку которая просто делегирует вызовы в Qin32API мы уже можем писать так
bool write_some_in_file2(char const* name)
{
CWin32API_File file
(name
,GENERIC_WRITE
,0
,0
,CREATE_ALWAYS
,0
,0
);
if(!file.is_valid())//избавились от магической константы INVALID_HANDLE_VALUEreturn false;
DWORD bytes=0;
//избавились от необходимости создавать промежуточную переменную для запоминания результата WriteFilereturn file.write
(name
,strlen(name)
,&bytes
,0
);
//И на конец избавились от необходимости закрывать хендл руками
};
//Хотя за параметрами опять надо лезть в MSDN.
И это на таком простом примере с пимитивнишим врапером...
А что будет если логика будет сложнее? Несколько файлов? Несколько мест где надо проверить логику?... лирическое отступление...
Однажды пришлось править код одного "программера со стажем" который не знал что такое смартпоинтеры и для чего надо писать обертки... я потритил несолько часов для того чтобы изменить формат генерируемого файла с такого
Правки такого типа в своем коде исполюзующем "навороты С++ на всю катушку" я вношу за минуты причем как правило тестирование багов не находит.
И самое смешное что другой программист со стажем(на этот раз без кавычек)не имевший раньше дел с "наворотами С++ на всю катушку" сел и спокойно прочитал мой код...
Если пасать код под binary_reader то работа с файлом, блобом или еще какой структурой с произвольным доступом будет совершенно одинакова. А если писать под binary_stream_reader то вобще можно работать с любым потоком...
Думайте сами, решайте сами... какой вариант использовать для разработки приложений...
Я не спорю с тем что когда надо добратся до всех возможностей работы с файлами под виндой то от WinAPI ни куда не дется... но даже в этом случае я буду делать обертки аля второй вариант.
Ибо The devil is in the details. и чем деталей меньше тем лучше.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.
Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.
Namespaces и особенно оператор using.
Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.
Уже нужен BSCMAKE вместо grep, и вдобавок код лишается локальной понятности. Позвано просто — set() и все. И чтобы понять, что за set(), надо листать код на начало файла, где стоит using.
Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.
Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть венгерскую нотацию используй
RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования? Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы. Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?
Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC? Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.
Такое ощущение, что рефакторинг кода на Си++ должен состоять главным образом в выбрасывании из него этих маразмов, и приближении его к коду на Си .
E>Ну вот я пишу под ACAD. И кое-что нельзя использовать. Например dynamic_cast
dynamic_cast само собой. Но это не единственный бред в Си++.
E>Так, а что такое "завистливые функиии"?
Метод одного класса, который часто и помногу работает с содержимым другого класса. Кандидат на перенос в тот другой класс.
E>Читайте Буча, первое издание. Там примеры были на Smalltalk. Про энтропию — опять же >квалификация программистов.
Программисты (и часто даже очень толковые программисты) есть народ, очень склонный к сверхценным идеям и поиску "серебряных пуль" на все случаи жизни. Вбил он себе в башку, что ОО — это круто, и будет потом писать программу для чтения SMART данных с винчестера в ОО стиле, при этом делая идиотства типа открытия файла в конструкторе. И невдомек ему, что OO — это круто для inherently object oriented задач типа UI, а вовсе не панацея на все случаи жизни.
Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих маньяков. Даже такая шиза, как юниксные condvar.
И нет никакой гарантии, что программист, которого нанимаешь, не будет маньяком какой-то заумной бредятины, и не свернет весь проект на ее использование. Рынок труда и HR таких гарантий уж точно не дадут.
Заумь написать мы все можем, дурное дело нехитрое. А ты (абстрактный "ты", не Exhumer) попробуй простой код написать. Существенно сложнее.
А в силу сложности этого — лучше пользоваться инструментом, который не даст писать заумь. По крайней мере в ответственных проектах, где высока цена баги в человеко-часах, и превышает цену печати кода.
E>С C++ вообще в командной строке тяжело работать. Но в оболочке — не вызывает никаких > >атруднений. Особенно если VC + VisualAssist. Удобство работы на порядок улучшается.
О! Уже даже MSVC мало, нужен еще какой-то VisualAssist. Энтропия инструмента такова, что требует дополнительных тулов для ее обуздания
И вот только не надо мне говорить, что project workspace в MSVC лучше, чем файл SOURCES или Makefile. Потому как это не так аргументы могу привести. Project workspace — это иллюзия юзабилити для начинающих.
E>Ну это типичное мнение linux-оидов. Частично как следствие инертности мышления.
Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид
Я работал на Си++ годы. С 93 по эдак 99. И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.
Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью >>технических средств.
MSS>Совершенно верно! Только почему это плохо?
MSS>Фирма Макдоннел-Дуглас сильно гордилась тем, что уменьшила на F-15 число приборов на доске до 30, вместо 48 у "Фантома". Ну наверное, не зря гордилась, правда?
MSS>А ведь могли бы сказать — "настоящий летчик и 48 приборов осилит"...
Физичексие ограничения человеческого организма — 7 объектов наблюдения / внимания.
А пример реализации твоей идеи — McDonalds. Ничего не умеющие студенты, делающие низкого качества еду.
Все ухожу, уходу, ухожу :)
Re: наверное это последствия професионального заболевания :)
интересное чтиво, вот только опоздало лет на 10+, даже странно что вокруг него такой флейм развели, по-этому коментировать пост просто не хочется.
Поражает другое, у людей много писавших код с использованием глубокой специфики ОС или железа появляется своеобразное професиональное заболевание которое можно назвать попросту "жлобством", почему то они считают что только проекты из той области где они работают, можно считать "серьезными"
G>Да чушь полная. ООП — это такой же инструмент как и любой другой. Все зависит от того >кто как этим инструментом пользуется. Если руки из жопы растут, то хоть ооп, хоть >процедурное программирование — один хрен будет куча ошибок и проблем. Вопрос не в >инструменте а в квалификации товарищей, которые его пользуют.
Типичное возражение, и совершенно неверное.
У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.
Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.
Использование оператора сдвига для печати — в минус.
На 100% согласен с тем, что сказано про запутанность кодов и монструозность библиотек.
Когда читал про оптимизацию компиляторов, вспомнился один пример немножко из другой области, но весьма жизненный.
Есть две среды разработки специфических приложений — 1С и MBS Navision. Обе занимаются не компиляцией, а интерпретацией своих скриптовых языков. 1С написан, видимо, на С++ с широким использованием COM, в результате чего производительность встроенного языка при исполнении на P4 примерно равна производительности ROM-бэйсика на IBM XT. Navision пошустрее будет. Раз в 10. Тоже, конечно, безобразие, но но разница в 10 раз — это, согласитесь, аргумент.
Рассмотрим, операцию, реализованную на обеих этих продуктах: учёт отгрузки товара (в терминах 1С — "проведение расходной накладной", в терминах Navision — "учёт отгрузки"). Выполняется за одно и то же время. Функциональность примерно одна и та же. Законный вопрос: куда подевались эти 10 раз? Ввод/вывод? Поэкспериментировали с базовыми операциями работы с БД. Навижн шустрее пусть не на порядок, но в разы — это точно.
Идём смотреть скрипты, выполняющие операцию учёта. В 1С это несколько экранов текста, всё понятно и прозрачно. Ничего лишнего. Основная часть работы возложена на механизьму учётных регистров, которую надо только правильно вызвать.
Идём смотреть в навижн. Боже ж ты мой! Как в этой хреноте разобраться? Необозримой длины процедура без единого комментария (вру, один какой-то бессмысленный где-то в середине есть), IFы кустятся и ветвятся как мангровый лес. В конце концов управление передаётся в знаменитый программный модуль №12, безобразно мутный и запутанный.
Промежуточный вывод: те, кто сочинял модуль учёта в 1С думали в основном о логике предметной области (ну там проверить остатки, снять резервы, двинуть взаиморасчёты и т.д.), а навижионистам пришлось сделать всё вручную и, соответственно, до оптимальности алгоритмов дело вообще не дошло.
А если всё это реализовывать чисто на С, то результат мог бы получиться ещё более плачевным: программа, скомпилированная самым супероптимизирующим компилятором, вполне может оказаться тормознутее, чем то же самое, исполняемое интерпретатором 1С.
Вывод:важна не только и не столько оптимизация, заложенная в средство разработки, но и закладываемые в "философию" средства разработки средства обеспечения простоты и ясности реализации целевого функционала.
(что, в общем, совпадает с выводами, следующими из "текста написанного нашим соотечественником, работающим в микрософтовской команде компиляторов").
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Нижеследующий текст написан нашим соотечественником, работающим в микрософтовской команде компиляторов.
MSS>Ко мне этот текст попал в конце 91го года. Он довольно старый, и старше, чем релиз .NET.
MSS>Предлагаю обсудить.
MSS>----------------------------------------------------------------------------------------
......
Да чушь полная. ООП — это такой же инструмент как и любой другой. Все зависит от того кто как этим инструментом пользуется. Если руки из жопы растут, то хоть ооп, хоть процедурное программирование — один хрен будет куча ошибок и проблем. Вопрос не в инструменте а в квалификации товарищей, которые его пользуют.
VD>Указание ref обязательно. Оно прекрасно выражает смысл.
Вот это очень хорошая идея.
>Все тоже самое можно и в С с С++, но только на уровне соглашений кодирования.
Сначала придумали глупость под названием references, глупость потому, что это неполноценный дубликат указателей. А неполноценный потому, что [] не работают с ними.
А потом стали придумывать соглашения кодирования, чтобы не дать этой глупости портить код.
Единственное место, где реально нужна reference — это перекрытые операторы, дающие lvalue. operator[], например.
VD>Агащасблин. А про то, что указатель может быть NULL или черти чем ты не забыл? Ссылки >как раз это устраняют. Так что тут пролема не в наличии фичи, а в плохом синтаксисе.
А какая разница? Утверждение "ссылки из Си++ — это плохо" — верно и в том, и в другом случае.
VD>Тут даже коментировать нечего. Бред да и только. Простраства имен самое разумное >решение борьбы с перекрывающимися именами. С префиксами давно борятся все разумные >люди. При некотором объеме кода они превращаются в тихий ужас.
Аргументы есть какие-то для такого вывода? В ядре Windows — где только из самого ядра торчит 1100 функций, а еще есть куча подсистем вне ядра типа NDIS — как-то такой проблемы не возникает.
VD>string a = "мыла"; VD>string b = "Маша " + a + " раму." + "Вот " + "такие пироги.";
Единственный случай, где overloading разумен. А, да, комплексные числа еще.
MSS>>Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже >никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть >венгерскую нотацию используй VD>Мля. А если strcat() залудить вызов отправляющий мыло админу о том, что строка >сконкатинирована? Тоже ведь никто незаметит.
Разница ощущается? Одно дело — библиотечная функция, имя которой все знают. Другое дело, когда в выражении выполняется какая-то работа, и выполняется так, что по синтаксису этого не заметно.
VD>Если приведение семантически грамотно, то никаких проблем не возникает.
Исходная статья микрософтовца о чем была? О том, что Си++ _открывает намного больше возможностей сделать глупость_, и намного больше возможностей написать грязнющий код. Потому нужно меньше доверять людям, и пользоваться тем языком, у которого таких возможностей напаскудить — меньше.
Из тех же соображений, из каких уменьшают число приборов в кабине истребителя.
VD>Сам то понял что сказал? Причем тут полиморфизм и RTTI?
Люблю я таких людей. Приходится азы объяснять.
Стоит задача. Код, работающий единообразным образом с разными объектами. Обычно есть два паттерна решения этой задачи:
а) полиморфный — сказать "сделай", а инстанс сам разберется, как он это будет делать.
б) явно спросить "а какого типа вот этот инстанс?" (эта возможность и называется RTTI) и потом сделать или switch, или цепочку ifов, для каждого типа свой код.
То, что путь б) плох — очевидно. Хотя бы потому, что появление нового типа объектов его тут же ломает.
RTTI противоречит полиморфизму. Это второй путь решения тех же задач, и путь почти всегда плохой.
То, что в языке не было RTTI, заставляло пионеров (про пионеров отдельная тема — на этом же форуме видел — начинают изучение сокетов... с MFC, потому что это типа круто и объектно. В итоге сокеты у них не работают и шибко умных писать полиморфно. И это было правильно.
Крайне редко действительно нужна RTTI. Например, при вводе-выводе объектов. Скажем, в COM интерфейс IPersist (который и есть RTTI) — только за этим и задуман, как ясно из имени. Придуман как база для наследования IPersistFile, IPersistStream и прочих. В ТурбоВижне в 90ые годы — то же самое примерно было. RTTI, придуманный для ввода-вывода объектов.
И Страуструп совершенно прав был, когда писал вот практически то же самое, о чем я тут распинаюсь для шибко умных. Прав потому, что как фича языка — это отстой, и потому, что элементарно делается через виртуальный метод, завернутый в макрос. Пишутся три строчки один раз, потом реюзятся везде, где можно. Не подходит? Откастомайзить легко, исходник есть.
VD>Что значит "поощрять не-полиморфные стили программирования"?
См. выше.
>дотнете рефлекшон прекрасно вписывается в ОО-концепции,
RTTI вписывается в ОО концепции? Может, это пиарная фигня, которую несут ради маркетинговых соображения, а такие, как ты, верят, потому как не знают, что такое полиморфизм?
VD>Ключевые слова здесь "как часть языка". У него есть идея фикс по которой все что >можно нужно сделать независимой библиотекой.
Правильно совершенно. Чем меньше автосгенеренного компилятором кода — тем лучше. Он принципиально закрыт и не изменяем. С библиотечными фичами не так — не нравится, сделай свою, делов-то.
VD>Можно ссылки на то откуда ты взял "во-первых и во-вторых"?
Страуструп/Эллис Annotated C++ Reference Manual 90го года. Длииинный текст курсивом, почему в языке нет RTTI.
MSS>>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — >что бывает редко — чем плох DECLARE_DYNAMIC из MFC? VD>Самому то не смешно?
Нет. Макрос лучше, чем вшитый в компилятор код. Потому как это не черный ящик.
VD>Ну, "откастомайзи" ради хохмы чтобы получить информацию сравнимую с дотнетной.
А зачем она нужна?
При действительно ОО проектировании просто не нужна эта информация, разве что для debug traces Си++, помимо всего прочего, еще и не совсем ОО.
VD>Пока, что ты назвал одну фичу которую нужно дорабатывать.
Я назвал фичу, которая принципиально не нужна.
VD>Мля. dynamic_cast — единственное небезопасное приведение типов в С++. Я балдею с этой >агитации за каменный век.
А я балдею с людей, которых не тянет блевать просто от синтаксиса dynamic_cast<имя>(...).
Чем хуже C-style cast в виде (тип)имя? Тем, что меньше визуального шума?
Преимущества этих Си++ наворотов возникают только при использовании множественного наследования и RTTI. И то, и другое — маразм. Вон Джава прекрасно обходится без множественного наследования — в extends можно перечислить только один класс.
VD>Дурь — это конечно большая проблема. Только не программистов, а человечества в общем. >Адни из них как раз борба с ОО без всяких оснований.
Да борьба-то тут скорее с маразмами конкретного языка, чем с ОО. Чем полиморфизм-то плох?
VD>Низнаю что за задача "чтение SMART-данных".
Техническая безграмотность — это плохо.
>Но открывть файлы в конструкторе, а закрывать в деструкторе совершенно нормально.
Бред. Обработать ошибку нечем, кроме перегруженного до жути механизма exceptions.
Не зря Брокшмидт в книжке про COM писал — "не делайте в конструкторе ничего, что могло быть обломиться.". Ой не зря. У него очень разумный подход к Си++. Он не считает, что это революционно новая идеология и прочую такую муйню. У него подход — Си++ — не более чем способ записи того же, что можно сделать и на Си. Правильный подход.
MSS>>Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих >маньяков. Даже такая шиза, как юниксные condvar. VD>И какое это имеет отношение к ОО и языку? Или маньяков нет только у CRT?
Отношение очень простое. Меньше фич — меньше руки чешутся их поюзать, где надо и где не надо.
VD>Ага. Например маньяком С.
Си простой язык. Вред от сверхценных идей практически только в неоправданном усложнении того, что можно сделать проще.
Писать класс как обертку вокруг Win32 event... во это я понимаю! титаны мысли такое делают!
VD>С каких это пор простой код было сложно писать?
С тех пор, когда стали пропагандировать, что классика устарела, ее на помойку, и все надо делать только на новомодных вещах.
>Вот просто решать сложные задачи — это действительно талант нужен.
Да. Си++ приводит к тому, что в даже простейшие задачи пихают кучу ненужных там наворотов. Лишнего в языке много.
>ОО-языки способствуют упрощению.
Да правда что ли? Теперь, кроме того, чтобы думать, как код работает, еще приходится думать — а как поле объявить — protected или private?
Претензии к ОО в основном идут к наследованию, которое действительно делает из простых задач сложные. Уж лучше дублирование кода, чем отстойно спроектированное дерево наследования. А спроектировать его правильно — простите, но мало кто может. Тут нужен действительно талант, а не средне-рыночные навыки умника за 1200 долларей.
Традиционно мог Борланд, например. Мог Гослинг. СиШарп делал тот же архитектор, что и борландовские ОО тулы. Потому Микрософт его и зазвал на работу.
А умнику дай такую задачу — при объеме эдак в 10 классов на реальном проекте (когда поступают реальные требования рынка, и их надо выполнять) у него все поползет.
Как расползаются деревья наследования — надо рассказывать? Страуструп был совершенно прав — хаки и патчи, сделанные по требованиям рынка (заказчика или своего руководства и маркетинга) — все постепенно ползут к корню дерева, объем кода в корне увеличивается, а в потомках — уменьшается. До тех пор, пока наследование не начинает выглядеть маразмом.
Претензии же к конкретно Си++, в отличие от ОО вообще — как правило к overloading и к RTTI, которая потянула за собой эти бредовые typecasts. К тому, что, строго говоря, к ОО не имеет отношения.
>придуманное тобой слово. И придумано оно исключительно чтобы повоспевать С. На С писать >непонятный и плохочитаемый код ни чуть не сложнее чем на С++.
Сложнее. Меньше вещей, которыми можно до такой степени грязно злоупотребить.
> В совое время я был очень рад перепрыгнуть с С на С++, потому как для описания задачи >эмулировать ОО-подход на С.
Таблицы указателей на функции? Ничего ужасного уж особо в этом нет. В юниксе файловые системы на них основаны. И ничего. ОС пережила уже 30 лет, и до сих пор считается хорошей.
VD>Ага. И нопэд куда лучше чем разные там студии.
Конечно. Сколько нужно сделать дебильных тычков мышью, чтобы развернуть дерево в ClassView?
Или взять список пропертей из VB или Дельфи. Задача — посадить в форму 2 контрола, у которых одинаковые списки пропертей, и оба одинаково отличаются от дефолтного.
Сколько надо мышью пощелкать для этого? А на каждый щелчок надо еще прицелится, еще иногда надо список проскроллировать, да еще надо весь этот список (позиций 20) в кратковременной памяти удержать.
В VB спасает то, что можно взять FRM файл, открыть текстовым редактором и руками через copy/paste отредактировать. В Дельфи — не знаю.
Единственная ценность Студии — хороший текстовый редактор и визарды. Остальное все от лукавого.
"Программирование без написания кода" путем заполнения форм и проперти-шитов — отстой. Отстойность становится очевидной, как только нужно два или три похожих объекта сделать — придется два или три раза заполнять этот шит одинаковым образом. Задача обезьянья, и легко сделать просто глазную ошибку. А для начинающих да. Типа круто. Типа пологая learning curve.
VD>А можно узнать название компилятора который ты испльзовал в 93-ем?
Borland C++ 3.1 + OWL.
VD>Из С++ действительно можно было бы викинуть кучу бреда. Но пришлось бы добавить и >кучу всего очень нужного.
А что мешает библиотеки понаписать, которые нужны?
>Тогда бы он возможно и для ГУИ подошел. А в современном виде использовать его для ГУИ — >это мозахизм.
Что не мазохизм? ПаэурБилдер? VB?
>приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот >же Борланд 3.1. VD>Да уж зрелее не бывает.
Хороший инструмент был. Пригодный для разработки достаточно серьезного софта.
Хотя, Вижуал Си, конечно, всем был лучше практически но он позже появился.
VD>То-то Девпартнерс напрягается.
То-то они так широко известны то-то у них сайт http://www.devpartners.com такой хороший... видать, успешная компания
VD>Да и написанием драйверов и ОС занимаются еденицы.
Скажем точнее — занимаются лучшие.
А "мейнстрим" твой — тут вопросы про сокеты задает. Причем с сокетами у чувака плохо получается (хотя что может быть проще Berkeley API? даже printf сложнее) — а вот Си++ он уже "типа выучил" и завернул Win32 эвент в Си++ный класс типа объектно оно
А вот о том, что от эвента нечего наследовать, что примитивы синхронизации уже полиморфны и уже инкапсулированы — человек забыл.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>C:\WINNT\system32>dumpbin /exports ntoskrnl.exe | wc -l MSS> 1277
MSS>Порядка 1100 функций. Это маленькое подмножество???
Ну, давай сравним. В проекте R# их 764. В Janus 348. (я почему-то склонен называть это маленькими проектами).
Думаю, что в фрэймворке функций значительно больше.
А главное, что пофигу сколько функций. Главное, что найдись одна пересекающаяся и прийдется трахаться.
Одни дефайны чего стоят. Назви так свою функцию SetWindowText, а потом ломай глову почему линкер ее не видет.
MSS>Да правда что ли? То есть, что тут автор кода имел в виду под сложением (а прийти в безумную голову может все, что угодно, например, << для печати) — это неважно?
У тебя в конторе все из псих-больницы что ли? Найди хоть один класс (из широко известных) с перегрузкой операторов который бы вызывал проблемы у большого количества людей. << для печати тоже проблем не представляет, хотя и не очень логично. Использование семантики присвоения тут было бы более усестно. А можно и вообще функцию использовать. Вот только << в С++ появлися из-за убогости функций с переменными параметрами дставшейся С++ по наследству от С. Так что твои призывы к каменному веку это не обосновывает. Возми Шарп . Там вывод на консоль делатеся методом хотя перегрузка операторов есть. И кстати, перегрузить << не по назначению невозможно, так как оператор требует целочисленный параметр.
MSS>Чем плохи макросы? MSS> Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Короче, кончай пропаганду каменного века. Это уже не смешно.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>CMyClass& как параметр вызовов.
MSS>Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.
Указание ref обязательно. Оно прекрасно выражает смысл. Все тоже самое можно и в С с С++, но только на уровне соглашений кодирования.
MSS>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.
Агащасблин. А про то, что указатель может быть NULL или черти чем ты не забыл? Ссылки как раз это устраняют. Так что тут пролема не в наличии фичи, а в плохом синтаксисе.
MSS>Namespaces и особенно оператор using.
MSS>Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.
MSS>Уже нужен BSCMAKE вместо grep, и вдобавок код лишается локальной понятности. Позвано просто — set() и все. И чтобы понять, что за set(), надо листать код на начало файла, где стоит using.
Тут даже коментировать нечего. Бред да и только. Простраства имен самое разумное решение борьбы с перекрывающимися именами. С префиксами давно борятся все разумные люди. При некотором объеме кода они превращаются в тихий ужас.
MSS>Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.
А надо чтобы значил? Назави хоть один случай когда ты пострадал от использования операторов? А вот читать:
string a = "мыла";
string b = "Маша " + a + " раму." + "Вот " + "такие пироги.";
Куда проще чем:
char* a = "мыла";
char* b = strcat("Маша ", strcat(a, strcat(" раму.",
strcat("Вот ", strcat("такие пироги.")))));
Одни скобки считать запаришся.
MSS>Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть венгерскую нотацию используй
Мля. А если strcat() залудить вызов отправляющий мыло админу о том, что строка сконкатинирована? Тоже ведь никто незаметит.
Если приведение семантически грамотно, то никаких проблем не возникает.
MSS>RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования?
Сам то понял что сказал? Причем тут полиморфизм и RTTI?
Что значит "поощрять не-полиморфные стили программирования"?
Процедурный стиль программирования полиморфный? Ну, а что ты за С тогда агетируешь? RTTI в С++ ругать можно и нужно, так как он убог до безобразия. Но уж хоть что-то. В дотнете рефлекшон прекрасно вписывается в ОО-концепции, позволяя расширять возможности среды и языка. Что-то ни одной жалобы на его использование. Чем ты это объяснишь?
MSS> Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы.
Ключевые слова здесь "как часть языка". У него есть идея фикс по которой все что можно нужно сделать независимой библиотекой. От того RTTI в С++ так убог.
MSS> Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?
Можно ссылки на то откуда ты взял "во-первых и во-вторых"?
MSS>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC?
Самому то не смешно?
MSS> Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.
Ну, "откастомайзи" ради хохмы чтобы получить информацию сравнимую с дотнетной. А мы тут вмесете посмеемся.
MSS>Такое ощущение, что рефакторинг кода на Си++ должен состоять главным образом в выбрасывании из него этих маразмов, и приближении его к коду на Си .
Пока, что ты назвал одну фичу которую нужно дорабатывать и наговорил кучу глупости. Так что, думаю, рефакторинг в тоем стиле убил бы остатки разуменого в этом языке.
MSS>dynamic_cast само собой. Но это не единственный бред в Си++.
Мля. dynamic_cast — единственное небезопасное приведение типов в С++. Я балдею с этой агитации за каменный век.
MSS>Программисты (и часто даже очень толковые программисты) есть народ, очень склонный к сверхценным идеям и поиску "серебряных пуль" на все случаи жизни. Вбил он себе в башку, что ОО — это круто, и будет потом писать программу для чтения SMART данных с винчестера в ОО стиле, при этом делая идиотства типа открытия файла в конструкторе. И невдомек ему, что OO — это круто для inherently object oriented задач типа UI, а вовсе не панацея на все случаи жизни.
Дурь — это конечно большая проблема. Только не программистов, а человечества в общем. Адни из них как раз борба с ОО без всяких оснований. Она ничем от обратоной (создания всего во что бы то ни стало в ОО-стиле) не отличается.
Низнаю что за задача "чтение SMART-данных". Но открывть файлы в конструкторе, а закрывать в деструкторе совершенно нормально. Особенно если чтение не тривиально и нужно хранить кучу контекстной информации.
MSS>Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих маньяков. Даже такая шиза, как юниксные condvar.
И какое это имеет отношение к ОО и языку? Или маньяков нет только у CRT?
MSS>И нет никакой гарантии, что программист, которого нанимаешь, не будет маньяком какой-то заумной бредятины, и не свернет весь проект на ее использование. Рынок труда и HR таких гарантий уж точно не дадут.
Ага. Например маньяком С.
MSS>Заумь написать мы все можем, дурное дело нехитрое. А ты (абстрактный "ты", не Exhumer) попробуй простой код написать. Существенно сложнее.
С каких это пор простой код было сложно писать? Вот просто решать сложные задачи — это действительно талант нужен. ОО-языки способствуют упрощению. Возможно С++ не самый удачный из ООЯ, но уж С — точно намного хуже.
MSS>А в силу сложности этого — лучше пользоваться инструментом, который не даст писать заумь. По крайней мере в ответственных проектах, где высока цена баги в человеко-часах, и превышает цену печати кода.
Запрещать нужно писать опасный и действительно плохопонятный код. "Заумь" — это придуманное тобой слово. И придумано оно исключительно чтобы повоспевать С. На С писать непонятный и плохочитаемый код ни чуть не сложнее чем на С++. В совое время я был очень рад перепрыгнуть с С на С++, потому как для описания задачи эмулировать ОО-подход на С.
MSS>И вот только не надо мне говорить, что project workspace в MSVC лучше, чем файл SOURCES или Makefile. Потому как это не так аргументы могу привести. Project workspace — это иллюзия юзабилити для начинающих.
Ага. И нопэд куда лучше чем разные там студии.
MSS>Я работал на Си++ годы. С 93 по эдак 99.
А можно узнать название компилятора который ты испльзовал в 93-ем?
MSS> И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.
Из С++ действительно можно было бы викинуть кучу бреда. Но пришлось бы добавить и кучу всего очень нужного. Тогда бы он возможно и для ГУИ подошел. А в современном виде использовать его для ГУИ — это мозахизм.
MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1.
Да уж зрелее не бывает.
MSS> А в системном программировании не прижился.
То-то Девпартнерс напрягается.
Да и написанием драйверов и ОС занимаются еденицы. А ты предлагаешь мэйнстриму идти в каменный век только потому, что тебе больше нравится С.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
SWW>Конечно. Такие вещи позволяют разбираться в сути программы, не отвлекаясь на >(конкретную реализацию сложения).
"Суть программы" — фигня полная. Во-первых, это просто. Практически всегда.
Во-вторых, зачем читают код? Для саппорта, то бишь а) баги править б) фичи дописывать и в) рефакторинг.
Для всех трех вышеперечисленных вещей нужно знать досконально все детали того куска кода, с которым работаешь, а не одну лишь "суть". И тут упрятывание вредит.
>Читая текст программы и зная, какие объекты складываются, в первом приближении ты >можешь догадаться что для них означает сложение (например, для строк — слияние).
А если валится оно в этом месте — мне тоже не надо знать, что означает + там?
Почему не написать obj.Add(obj2)? Оно имеет преимущество всегда, кроме сложных арифметических выражений, которые с кастом-классами встречают очень редко.
SWW>Разумеется, если operator+ выполняет действия, не имеющие ничего общего со >сложением, то с таким программистом надо разбираться в другом месте.
Во! Золотые слова! А такое ведь почти всегда бывает. Например, оператор <<, означающий печать.
Здравствуйте, iZEN, Вы писали: ZEN>Да, ошибся в формулировке. Неправильно выразился. ZEN>Шаблоны — это костыли для первых псевдо-ООП-языков, таких как C++ с его STL. Чтобы было легче писать в "как-бы" ООП-стиле, экономя время себе и другим.
Ничего подобного. Еще раз: никакого отношения к ООП шаблоны не имеют. Ни "как-бы", ни "вместо" ООП. Просто не все виды взаимоотношений между типами можно выразить при помощи наследования (или генерализации). Шаблоны, как и ООП, позволяют увеличить выразительность языка программирования. Совместное применение метапрограммирования и ООП на сегодня, насколько мне известно, является наиболее выразительным средством императивного программирования.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Дарней, Вы писали:
Д>я бы сказал, очень маленькое. Если взять в качестве примера FCL, то мне даже подумать страшно, сколько там всего функций (точнее, методов). На порядок больше — это точно.
Здравствуйте, AndreyT, Вы писали:
AT>Тебе просто не удаётся понять, что речь как раз идёт о наличии такого понятия как "вешь, которую можно использовать не по назначению". Поскольку число идиотов примерно постоянно в любой системе координат и снижению не поддаётся, то надо говорить о снижении числа двусмысленностей.
Ненадо путать идиотов которых много, т.е. представителей интеллектуального большинства, и идиотов которых еще поискать нужно.
Если серьезно, то это попытка высасать проблему из поальца. Если сделать идеальный язык добившись полного отсуствия неявных вещей, то писать не нем никто не будет, так как это будет крайне неудобный и ограниченный язык. Скрытое поведение так же низбежно как само поведение. Ну, нельзя сказать какие побочные эффекты есть у вызва процедуры. В принципе нельзя. Для того, чтобы гарантировать, что его нет нужно изучить исходники этой функции и всех вызываемых из нее функций. А это в действительно больших системах незвоможно (да и библиотеки порой всретчаются у которых нет исходников). Так что приходится верить. Именно поэтому придумали такую вещь как инкапсуляция. Или давайте откажемся от подпрограмм. Не, ну, ведь они, заразы приводят к боязни побочных эффектов.
Я много раз слышал бред о вреде переопределения операторов или о неявном вызове деструкторов. Правда обычно слышал — это от довольно зацикленных дельфистов. Слова о вреде полиморфизма слышу впервые. Конечно неудбно когда из-за того, что метод виртуальный студия не дает перейти к нужному исходнику, но ведь, черт побери, если не будет этих виртуальных функций прийдется читать гору ужасного кода состоящего из гигантских свитчей и разных С-шных приколв. Уж лучше я найду метод другими путями.
AT>Когда Максим говорит про перегрузку, он совершенно прав. AT>Правило коммутативности обязано выполнятся, стало быть, те ситуации, которые по разному интерпретируют (a+b) и (b+a) должны идти в сад. Во избежание.
И причем тут это и перегрузка? Ну, где ты на практике видел проблемы от пергрузки операторов? Да не так часто их и переопределяет. Слава богу те идиоты просто не справятся с перегрузкой.
В общем, высасал из пальца проблему и на основании этого обосновывает ненужность очень полезной фичи.
ЗЫ
Не стоит воевать с ветренными мельницами. Есть куча куда более интересных проблем.
С++ действительно оброс проблеммами, но не теми о которых тут говорися. С — это намного хуже чем С++. Вот уж где кладесь неоднозначности и россыпи граблей.
МС сделала верный выбор спроектировав Шарп снуля. Очень многих проблем они избежали. И я совсем не понимаю почему не забыть об откровенно пережившем себя С, забить на С++ и пользоваться современным языком избавленным от большинства проблем.
Рано или поздно и Шарп устареет. Но на сегодня он ближе всего к идеало из императивных языков. Кстати, возможно лучшим развитием языков для сложных проектов будет интеграция в императивный язык декларативной и функциональной составляющих. Собственно кое что в Шарпе уже есть (атрибуты).
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MSS>>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось >бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть >изменен в результате вызова. E>Надо использовать модификатор const. И тогда все намного будет проще.
Ничего не будет проще. Останется f(obj), а за словом const лезть в заголовок. Намного лучше использовать CObject*, чем const CObject&
E>Все от программиста зависит. Если в одном фале ипользуются разные namespace, то и >пользоватся using надо аккуратнее.
Дело в том, что подавляющее большинство программистов злоупотребят этим. У многих менталитет на уровне "есть фича, надо пользоваться" . Дай такому в руки Си++ — получишь write-only language.
E>А реализация "+" может быть разная у разных объектов. Никак не звязанная с >арифметическим сложением. Ты об этом не задумывался?
Я именно об этом, и именно это и есть бред. Лучше уж тогда метод Add. Скажем:
container.Insert(obj);
лучше, чем
container += obj;
E>А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных >ситуациях.
Например?
E>Реализация RTII в MFC не самый удачный пример. Явно хуже чем RTTI в C++. Хотя бы тем >что обязывает наследовать от CObject.
А чем это плохо-то? RTTI нужна на крайне небольшом количестве классов (на CString она не нужна, например), и обязать все такие классы наследоваться от одного корня — что плохого?
>E>"Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения" >(C) — не помню кто.
Keep it simple and stupid. Принцип такой в инженерии. Почти в любой. Усложнения делаются только тогда, когда иначе НИКАК.
E>Переведи понятие "цена печати кода".
Количество нажатий на клавиши, нужное для набора кода. Фичи Си++ — тот же класс строки — полезны практически только в этом.
MSS>>Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид E>Так я о мышлении.
Ну тут, наверное, да. Я скорее буду заодно с линуксоидами, чем с маньяками "серьезного проектирования".
И самый прикол, что эти маньяки почему-то все больше выше бухгалтерий не поднимаются...
E>А так вот ты о чем! Ну так маленькие задачи и ОО там не нужен. И не спорю. Не понимаю >как это соотносится с темой: "C++ и большие проекты".
Тема была — Си++ и серьезный код. Очевидно, что кернел модуль в любой ОС — более серьезный код, чем, например, абсолютно любой UI.
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Например? Только фичи языка, а не STL, etc.
MSS>CMyClass& как параметр вызовов.
MSS>Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.
MSS>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.
Надо использовать модификатор const. И тогда все намного будет проще. А твой метод не спасает — это яркий пример not well design.
MSS>Namespaces и особенно оператор using.
MSS>Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.
Ну и в чем проблема? SetEvent, он что только у Kernel-а может быть? Как-то надо разделять.
MSS>Уже нужен BSCMAKE вместо grep, и вдобавок код лишается локальной понятности. Позвано просто — set() и все. И чтобы понять, что за set(), надо листать код на начало файла, где стоит using.
Все от программиста зависит. Если в одном фале ипользуются разные namespace, то и пользоватся using надо аккуратнее.
MSS>Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.
А реализация "+" может быть разная у разных объектов. Никак не звязанная с арифметическим сложением. Ты об этом не задумывался?
MSS>Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть венгерскую нотацию используй :)
А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных ситуациях.
MSS>RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования? Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы. Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?
MSS>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC? Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.
Реализация RTII в MFC не самый удачный пример. Явно хуже чем RTTI в C++. Хотя бы тем что обязывает наследовать от CObject.
MSS>Такое ощущение, что рефакторинг кода на Си++ должен состоять главным образом в выбрасывании из него этих маразмов, и приближении его к коду на Си :).
Ощущение неправильное.
E>>Читайте Буча, первое издание. Там примеры были на Smalltalk. Про энтропию — опять же >>квалификация программистов.
MSS>Программисты (и часто даже очень толковые программисты) есть народ, очень склонный к сверхценным идеям и поиску "серебряных пуль" на все случаи жизни. Вбил он себе в башку, что ОО — это круто, и будет потом писать программу для чтения SMART данных с винчестера в ОО стиле, при этом делая идиотства типа открытия файла в конструкторе. И невдомек ему, что OO — это круто для inherently object oriented задач типа UI, а вовсе не панацея на все случаи жизни.
А чего ты взял такую напрввленность ОО? Смотри конец поста.
MSS>Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих маньяков. Даже такая шиза, как юниксные condvar. :)
MSS>И нет никакой гарантии, что программист, которого нанимаешь, не будет маньяком какой-то заумной бредятины, и не свернет весь проект на ее использование. Рынок труда и HR таких гарантий уж точно не дадут. :)
MSS>Заумь написать мы все можем, дурное дело нехитрое. А ты (абстрактный "ты", не Exhumer) попробуй простой код написать. Существенно сложнее.
"Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения" (C) — не помню кто.
MSS>А в силу сложности этого — лучше пользоваться инструментом, который не даст писать заумь. По крайней мере в ответственных проектах, где высока цена баги в человеко-часах, и превышает цену печати кода.
Переведи понятие "цена печати кода".
E>>С C++ вообще в командной строке тяжело работать. Но в оболочке — не вызывает никаких > >>атруднений. Особенно если VC + VisualAssist. Удобство работы на порядок улучшается.
MSS>О! Уже даже MSVC мало, нужен еще какой-то VisualAssist. Энтропия инструмента такова, что требует дополнительных тулов для ее обуздания :)
Для облегчения работы. А уж почему VC сделали таким как он есть — вопрос к товарищу из MS. Например у borland-а это все есть. Хотя знаю зачем — что бы не было конкуренции VB.
MSS>И вот только не надо мне говорить, что project workspace в MSVC лучше, чем файл SOURCES или Makefile. Потому как это не так :) аргументы могу привести. Project workspace — это иллюзия юзабилити для начинающих.
E>>Ну это типичное мнение linux-оидов. Частично как следствие инертности мышления.
MSS>Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид :)
Так я о мышлении.
MSS>Я работал на Си++ годы. С 93 по эдак 99. И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.
MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.
А так вот ты о чем! Ну так маленькие задачи и ОО там не нужен. И не спорю. Не понимаю как это соотносится с темой: "C++ и большие проекты".
Еще раз. Очень много от программиста зависит и достаточно мало от языка
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. и чем деталей меньше тем лучше.
Сами по себе обертки уже есть детали. Те самые.
А если баг в обертке где? Ой млиииин...
Здравствуйте, VladD2, Вы писали:
VD>Пойми если рефлекшен есть, то он есть. Сделай превую компиляцию, получи мета-информацию, прочти ее и сгенери код сериализации.
Класс.
Интересно, сколько мне ещё учиться, чтобы понять эту фразу?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>CMyClass& как параметр вызовов.
MSS>Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.
const надо писать, вот что я могу сказать. посмотрел заголовок функции — и стало всё понятно
MSS>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.
а ты уверен, что CMyClass* это именно подсказка о том, что параметр изменяется внутри? Может быть, просто этот объект очень тяжеловесный и програмер написал передачу через указатель, чтобы убрать лишнее копирование данных. Потому что ссылки он ненавидит и нигде не использует
MSS>Namespaces и особенно оператор using.
MSS>Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.
мне даже страшно представить себе имена в стиле SystemRuntimeRemotingChannelsTcpTcpChannel
вот за такое точно надо руки рубить, по самые уши
такие имена можно использовать только в том случае, если у тебя очень мало модулей, на которые разделены функции. Вероятно, в случае написания драйверов, когда достаточно использовать крайне маленькое подмножество функций, это прокатит. В других случаях — нет.
MSS>Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.
Это значит "сложение"! (чтобы понять, совсем не нужно даже иметь высшее образование )
А уж как и где оно делается, это уже дело десятое.
MSS>RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования? Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы. Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?
да, RTTI плох. Но не тем, что он есть. А тем, что он недостаточно развит и применяется не для того, чего надо бы. Я надеюсь, полезность отражения никто оспаривать не будет?
MSS>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC? Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.
Здравствуйте, 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 {
// А тут что делать?
}
В первом случае обработка ошибок застилаем всю логику. Во втором мы можем вынести её туда, где она действительно имеет смысл.
А пропустить какой-нибудь CloseHandle в первом случае — как два пальца.
MSS>Про драйвера. Задумался вчера всерьез над темой "Си++ в драйверах", и получилось вот что. Там некое количество внешних структур, с которыми приходится работать, и которые приходят извне. Ну и толку будет оборачивать NDIS_PACKET в класс? Что это даст-то? Взаимодействие с окружающей ОС все равно делается в терминах NDIS_PACKET, и зачем вокруг него врапперы плодить?
Ну конечно...
MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.
Да, только у человека с высокой квалификацией этот объем повыше чем к примеру у алканафта-слесаря. Тем они и отличаются в первую очередь.
MSS>Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.
Ага А необходимость листать 500 функций — это огромный плюс?
MSS>Использование оператора сдвига для печати — в минус.
Добавляй "Я думаю"
MSS>Это вопросы азов эргономики.
А че там эргономика говорит нам про оператор сдвига?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, iZEN, Вы писали: ZEN>>К сожалению, в ООП слишком много парадигм, например, шаблоны (template), от чег весь вой: с одной стороны это экономит силы и время, с другой стороны ведёт к двусмысленности(n-смысленности) толкований сторонними кодерами. S>В ООП нет никаких шаблонов. Эта парадигма никакого отношения к ООП не имеет.
Да, ошибся в формулировке. Неправильно выразился.
Шаблоны — это костыли для первых псевдо-ООП-языков, таких как C++ с его STL. Чтобы было легче писать в "как-бы" ООП-стиле, экономя время себе и другим. В что это иногда (не всегда!) выливается — уже написал — требуется более продвинутый программист, чтобы понять что хотел сказать автор. Простота ООП исключает "левые" наносные сложности, там не место макроподстановкам (моё мнение, другое мнение возобладало в C++) — фактически метаязык "определений для определений" (на самом деле для препроцессора).
Обидно, что новая версия Java пошла по такому же пути.
SWW>>Конечно. Такие вещи позволяют разбираться в сути программы, не отвлекаясь на >>(конкретную реализацию сложения).
MSS>"Суть программы" — фигня полная. Во-первых, это просто. Практически всегда. MSS>Во-вторых, зачем читают код? Для саппорта, то бишь а) баги править б) фичи дописывать и в) рефакторинг.
Нормально! То есть, чтобы баг найти — не надо вникать в суть программы. Мне главное — баг найти!
MSS>Для всех трех вышеперечисленных вещей нужно знать досконально все детали того куска кода, с которым работаешь, а не одну лишь "суть". И тут упрятывание вредит.
Я же написал: в первом приближении. Если есть подозрение, что баг "где-то здесь" — исследуешь это место подробнее.
А ты считаешь, чтобы разобраться с программой, нужно прочитать ее всю и сразу, мешая в одну кучу реализацию основного алгоритма и функции-хелперы?
MSS>А если валится оно в этом месте — мне тоже не надо знать, что означает + там?
...нет слов... одни выражения...
MSS>Почему не написать obj.Add(obj2)? Оно имеет преимущество всегда, кроме сложных арифметических выражений, которые с кастом-классами встречают очень редко.
А почему надо вырезать из поего поста ту часть, где есть ответ на этот вопрос?
Но ведь и для функции можно выбрать имя, не имеющее ничего общего с ее работой!
SWW>>Разумеется, если operator+ выполняет действия, не имеющие ничего общего со >>сложением, то с таким программистом надо разбираться в другом месте. MSS>Во! Золотые слова! А такое ведь почти всегда бывает. Например, оператор <<, означающий печать.
Но ведь и для функции можно выбрать имя, не имеющее ничего общего с ее работой!
Так что, не перегрузка операторов виновата, а программист.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Ха-хах, и сразу (по аналогии с операторами) найдутся умельцы, которые напишут:
Дело тут не в слишком большой "продвинутости" языка, а в слишком большой "продвинутости" программеров. Я могу написать на Си нечитаемую хрень (да что я — см. многие исходники ID-а с хитрым закосом под ОО), а могу такую же на C++, в объектах, быстро и просто. Или наоборот.
Дело в уместности инструмента, а не в его мнимой вредоносности
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Я работал на Си++ годы. С 93 по эдак 99. И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.
MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.
Приживается.
Мы используем C++ и STL для разработки модулей ядра под Linux и Windows NT.
В результате проект, который местный защитник plain C писал год, был закончен за пол-года.
А по скорости даже выиграл у сишного прототипа.
Страшилки про использование C++ в ядре рассказывать не надо — мы их знаем.
Мне кажется, что история как всегда повторяется.
Nдцать лет назад тоже гремели баталии на тему "asm vc C".
Любители всё держать под контролем так же рассказывали про кривой язык C. Соглашались, что они программируют медленно, но зато генерируют намного более оптимальный и предсказуемый код, чем компилятор. Сравнения кода приводили. И так же боролись с попытками писать VXD на C.
Здравствуйте, Maxim S. Shatskih, Вы писали:
SWW>>Разумеется, если operator+ выполняет действия, не имеющие ничего общего со >>сложением, то с таким программистом надо разбираться в другом месте.
MSS>Во! Золотые слова! А такое ведь почти всегда бывает. Например, оператор <<, означающий печать.
Дык тебе и говорят, что нет проблем в операторах. Ты их сам придумал. А есть проблемы в идиотах использующих вещи не по назначению. Ведь с таким же успехом можно назвать функцию вывода в консоль Shift и начать рассуждать о неполноценности процедурного подхода и приемуществах ассемблера.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Единственное место, где реально нужна reference — это перекрытые операторы, дающие lvalue. operator[], например.
А еще конструкторы копирования, а еще для параметров перегруженных операторов...
MSS>Аргументы есть какие-то для такого вывода? В ядре Windows — где только из самого ядра торчит 1100 функций, а еще есть куча подсистем вне ядра типа NDIS — как-то такой проблемы не возникает. Re[8]: Применим ли Си++ в серьезном коде?
MSS>Единственный случай, где overloading разумен. А, да, комплексные числа еще.
Еще векторы и если подумать то наверняка еще задачи найдутся...
MSS>Разница ощущается? Одно дело — библиотечная функция, имя которой все знают. Другое дело, когда в выражении выполняется какая-то работа, и выполняется так, что по синтаксису этого не заметно.
Если эта работа делает то что обозначает этот оператор в данном контексте то все нормально. А если нет тот тут уж ни кто не застрахован то дебила который в функции CopyFile будет удалять фаил.
MSS>Исходная статья микрософтовца о чем была? О том, что Си++ _открывает намного больше возможностей сделать глупость_, и намного больше возможностей написать грязнющий код. Потому нужно меньше доверять людям, и пользоваться тем языком, у которого таких возможностей напаскудить — меньше.
Все реальные проблемы С++(2Влад: порутчик молчать! Про рефлекшен мы все давно выяснили и ни чего нового друг другу не скажем. На всякий случай напомню что я сомневаюсь в необходимости рантайм-рефлекшена и двумя руками за компаил-тайм рефлекшен), а не высосаные из пальца тапа проблемы с сылками, операторами, пространствами имен... имеют свои корни именно в С.
Меня например бесит неявное привидение массива к указателю, не явное привидение указателя к void*,
дебильный макро-процессор из-за которого возникают вопросы типа
"а почему после включения <windows.h> начались проблемы с методом GetSome"
И на него следует ответ типа "а по тому что есть две функции GetSomeA и GetSomeW и какойто умник определил дефайн который в зависимости от настроек проекта..."
И даже если забыть про это то остается кошмарное требование к разработчикам STL называть временные переменные так _<A..Z0..9><A..Za..z0..9_>
и код STL обязан выглядеть так
template<class _FwdIt1,
class _Diff2,
class _Ty,
class _Diff1> inline
_FwdIt1 _Search_n(_FwdIt1 _First1, _FwdIt1 _Last1,
_Diff2 _Count, const _Ty& _Val, _Diff1 *)
{ // find first _Count * _Val match
_Diff1 _Count1 = 0;
_Distance(_First1, _Last1, _Count1);
for (; _Count <= _Count1; ++_First1, --_Count1)
{ // room for match, try it
_FwdIt1 _Mid1 = _First1;
for (_Diff2 _Count2 = _Count; ; ++_Mid1, --_Count2)
if (_Count2 == 0)
return (_First1);
else if (!(*_Mid1 == _Val))
break;
}
return (_Last1);
}
В свою очередь разработчиким запрещено использовать такие имена.
Я могу еще много гадости вытащить...
MSS>Из тех же соображений, из каких уменьшают число приборов в кабине истребителя.
А с этим ни кто не спорит. Но не надо пытаться свести набор инструментов к одному молотку...
MSS>Стоит задача. Код, работающий единообразным образом с разными объектами. Обычно есть два паттерна решения этой задачи: MSS>а) полиморфный — сказать "сделай", а инстанс сам разберется, как он это будет делать. MSS>б) явно спросить "а какого типа вот этот инстанс?" (эта возможность и называется RTTI) и потом сделать или switch, или цепочку ifов, для каждого типа свой код.
С этим согласен на все 100. Но не забываем и про другие способы использовать RTTI например dynamic_cast тотже QueryInterface только в профиль.
MSS>RTTI противоречит полиморфизму. Это второй путь решения тех же задач, и путь почти всегда плохой.
Если им заменять полиформизм то да. А если использовать его паралельно с полиформизмом...
Не надо отверткой забивать гвозди. Не для того она придумана. А вот заворичивать шурупы...
MSS>И Страуструп совершенно прав был, когда писал вот практически то же самое, о чем я тут распинаюсь для шибко умных. Прав потому, что как фича языка — это отстой, и потому, что элементарно делается через виртуальный метод, завернутый в макрос. Пишутся три строчки один раз, потом реюзятся везде, где можно. Не подходит? Откастомайзить легко, исходник есть.
С этим в принципе согласен. НО! Делать это теми средствами которые есть в языке на сегодняшней день это мягко говоря мазохизм.
VD>>Ну, "откастомайзи" ради хохмы чтобы получить информацию сравнимую с дотнетной. MSS>А зачем она нужна?
Для сериализации. Я ее делал... Нет я ее конешно сделал и вобщем даже удобно получилось но блин сколько гемороя было с реализацией...
С рефлекшеном это делается легко и просто, а если бы был компаил-тайм рефлекшен... то вобще бы сразу сгенерил бы код для сериализации в нужном не формате.
MSS>А я балдею с людей, которых не тянет блевать просто от синтаксиса dynamic_cast<имя>(...).
Чесно говоря от MVP я не ожидал довода из серии begin/end vs {}
MSS>Чем хуже C-style cast в виде (тип)имя? Тем, что меньше визуального шума?
А ты вобще знаком со свойствами С++кастов?
MSS>Преимущества этих Си++ наворотов возникают только при использовании множественного наследования и RTTI. И то, и другое — маразм. Вон Джава прекрасно обходится без множественного наследования — в extends можно перечислить только один класс.
1)В жабе есть инетерфейсы, а в С++ нет.
2)Множественное наследование реализации тоже иногда очень полезно.
MSS>Бред. Обработать ошибку нечем, кроме перегруженного до жути механизма exceptions.
А что ты имеешь против исключений? Очень удобный механизм если уметь им пользоватся.
По мне так проще писать код безопасный к исключениям даже если исключения и не предвидятся чем писать код который плевать хотел на исключения.
MSS>Отношение очень простое. Меньше фич — меньше руки чешутся их поюзать, где надо и где не надо.
Проблема в том чтоесли не фичи то и где надо ее не поюзаешь...
MSS>Си простой язык. Вред от сверхценных идей практически только в неоправданном усложнении того, что можно сделать проще.
Аналогично для С++. НО!
Пусть это будет просто:
просто, как только можно, но не проще.
(C) А. Эйнштейн
MSS>Писать класс как обертку вокруг Win32 event... во это я понимаю! титаны мысли такое делают!
А почему бы и нет? Обертки гарантируют освобождение хндлов только из-за этого они достойны использования.
MSS>Да. Си++ приводит к тому, что в даже простейшие задачи пихают кучу ненужных там наворотов. Лишнего в языке много.
На пример?
MSS>Таблицы указателей на функции? Ничего ужасного уж особо в этом нет. В юниксе файловые системы на них основаны. И ничего. ОС пережила уже 30 лет, и до сих пор считается хорошей.
А на кой черт писать их руками? С этим компилятор справляется на ура.
MSS>Конечно. Сколько нужно сделать дебильных тычков мышью, чтобы развернуть дерево в ClassView?
Ну не знаю лично я класс вью вобще не пользую. А вот дерево файлов проекта очень даже использую. Возможность раскидать файлы по папкам очень удобна. И кликов для того чтобы добратся для нужного файла надо куда меньше чем в связке explorer+notepad.
MSS>Или взять список пропертей из VB или Дельфи. Задача — посадить в форму 2 контрола, у которых одинаковые списки пропертей, и оба одинаково отличаются от дефолтного.
Не знаю как в ВБ но в дельфе садишь на форму один контрол, настраиваешь его и копируешь... или всегда можно перейти в к текстовому виду формы.
И вобще спорить с тем что RAD это плохо при создании ГУИ как бы это по мягче выразится...
MSS>"Программирование без написания кода" путем заполнения форм и проперти-шитов — отстой. Отстойность становится очевидной, как только нужно два или три похожих объекта сделать — придется два или три раза заполнять этот шит одинаковым образом. Задача обезьянья, и легко сделать просто глазную ошибку.
Ты вобще хоть немного с RAD средствами работал? Или только из далека видел? MSS>А для начинающих да. Типа круто. Типа пологая learning curve.
В смысле крутая? В этом согласен. Опасна дельфя для новичков. Очень опасна.
MSS>А что мешает библиотеки понаписать, которые нужны?
Есть вещи которые на том что есть сейчас реализовать мягко говоря охренеешь. Таже сериализация.
VD>>Да и написанием драйверов и ОС занимаются еденицы. MSS>Скажем точнее — занимаются лучшие.
Ты толькочто оскорбил всех тех кто не пишет драйверы и ОС...
По легче на поворотах.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Претензии к ОО в основном идут к наследованию, которое действительно делает из простых задач сложные. Уж лучше дублирование кода, чем отстойно спроектированное дерево наследования. А спроектировать его правильно — простите, но мало кто может. Тут нужен действительно талант, а не средне-рыночные навыки умника за 1200 долларей.
Вот небольшой пример кода в чисто сишном стиле, хоть там и используются интерфейсы. Но это особой разницы не делает.
Всё в твоем любимом стиле — никаких ссылок, никаких исключений, никаких деструкторов.
#include <windows.h>
#include <winbase.h>
#include <initguid.h>
#include <ole2.h>
#include <mstask.h>
#include <msterr.h>
#include <wchar.h>
int main(int argc, char **argv)
{
HRESULT hr = S_OK;
ITaskScheduler *pITS;
///////////////////////////////////////////////////////////////////
// Call CoInitialize to initialize the COM library and then
// CoCreateInstance to get the Task Scheduler object.
///////////////////////////////////////////////////////////////////
hr = CoInitialize(NULL);
if (SUCCEEDED(hr))
{
hr = CoCreateInstance(CLSID_CTaskScheduler,
NULL,
CLSCTX_INPROC_SERVER,
IID_ITaskScheduler,
(void **) &pITS);
if (FAILED(hr))
{
CoUninitialize();
return 1;
}
}
else
{
return 1;
}
///////////////////////////////////////////////////////////////////
// Call ITaskScheduler::Activate to get the Task object.
///////////////////////////////////////////////////////////////////
ITask *pITask;
LPCWSTR lpcwszTaskName;
lpcwszTaskName = L"Test Task";
hr = pITS->Activate(lpcwszTaskName,
IID_ITask,
(IUnknown**) &pITask);
if (FAILED(hr))
{
wprintf(L"Failed calling ITaskScheduler::Activate: ");
wprintf(L"error = 0x%x\n",hr);
CoUninitialize();
return 1;
}
pITS->Release();
///////////////////////////////////////////////////////////////////
// Call ITask::CreateTrigger to create new trigger.
///////////////////////////////////////////////////////////////////
ITaskTrigger *pITaskTrigger;
WORD piNewTrigger;
hr = pITask->CreateTrigger(&piNewTrigger,
&pITaskTrigger);
if (FAILED(hr))
{
wprintf(L"Failed calling ITask::CreatTrigger: ");
wprintf(L"error = 0x%x\n",hr);
CoUninitialize();
return 1;
}
//////////////////////////////////////////////////////
// Define TASK_TRIGGER structure. Note that wBeginDay,
// wBeginMonth, and wBeginYear must be set to a valid
// day, month, and year respectively.
//////////////////////////////////////////////////////
TASK_TRIGGER pTrigger;
ZeroMemory(&pTrigger, sizeof (TASK_TRIGGER));
// Add code to set trigger structure?
pTrigger.wBeginDay =1; // Required
pTrigger.wBeginMonth =1; // Required
pTrigger.wBeginYear =1999; // Required
pTrigger.cbTriggerSize = sizeof (TASK_TRIGGER);
pTrigger.wStartHour = 13;
pTrigger.TriggerType = TASK_TIME_TRIGGER_DAILY;
pTrigger.Type.Daily.DaysInterval = 1;
///////////////////////////////////////////////////////////////////
// Call ITaskTrigger::SetTrigger to set trigger criteria.
///////////////////////////////////////////////////////////////////
hr = pITaskTrigger->SetTrigger (&pTrigger);
if (FAILED(hr))
{
wprintf(L"Failed calling ITaskTrigger::SetTrigger: ");
wprintf(L"error = 0x%x\n",hr);
CoUninitialize();
return 1;
}
///////////////////////////////////////////////////////////////////
// Call IPersistFile::Save to save trigger to disk.
///////////////////////////////////////////////////////////////////
IPersistFile *pIPersistFile;
hr = pITask->QueryInterface(IID_IPersistFile,
(void **)&pIPersistFile);
hr = pIPersistFile->Save(NULL,
TRUE);
wprintf(L"The trigger was created and IPersistFile::Save was \n");
wprintf(L"called to save the new trigger to disk.\n");
///////////////////////////////////////////////////////////////////
// Release resources.
///////////////////////////////////////////////////////////////////
pITask->Release();
pITaskTrigger->Release();
pIPersistFile->Release();
CoUninitialize();
return 0;
}
Ну как, хорошо? Пока работает — замечательно.
А потом кому-то понадобится этот код модифицировать, и он влепит посреди функции return и забудет позвать какой-нибудь из Release(), или CoUninitialize()
Или создаст новый объект на куче и забудет поставить delete в каждую из дестяка точек, где может происходить выход из функции.
Чудно будет, правда?
Я уж не говорю о том, что в этой функции полезного кода процентов 10 наверно будет, а всё остальное — это просто дублирование.
Хотя кажется мне, зря я это всё пишу. Автор темы — или фанатик, или провокатор. Любые аргументы он просто не поймет.
А теперь можно смело ставить мне минусы
Здравствуйте, VladD2, Вы писали:
_>> [Obsolete("use AddWithValue(string, object)", false)] _>> public SqlParameter Add(string parameterName, object value) { VD>Скорее всего там есть параметр типа энум. А разные орлы пытаясь сувать туда целочеисленное его значение налетали на боксинг и иную интепретацию. Ну, или еще что-нить в этом роде.
Почти угадал. Осталось только объяснить, почему два вызова Add порождают разный код:
Здравствуйте, 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++ позволяет легко скрыть или упростить подобные казусы — как раз уменьшив визуальное загрязнение:
Очевидно, что:
И это при примитивной логике. Добавим сюда композитный Obj — и мне жалко того, кто будет не то что писать — читать такой код...
Стоит помнить о том — что программа многоуровневая, и помимо синтаксического уровня (и шума на этом уровне) — есть так же алгоритмический, арихитектурный и куча других уровней — и соответсвенно разновидностей шума на этих уровнях. И читабельность программы будет зависеть от её лаконичности на всех уровнях, а не только от эконгомии на "(type) x".
MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.
--
С последней фразой можно поспорить.
Например, интересно проследить тенденцию в рекомендациях использования языка программирования для системного программирования от той же самой Microsoft.
Если раньше Microsoft не рекомендовала вообще использовать С++ в программировании драйверов, то в последних их докуметнах и презентациях уже встречаются слова типа "Microsoft neither endorses nor prohibits the use of C++ for kernel-mode drivers" (здесь) или "We moved the development language debate from Assembly versus C to C versus C++", а в DDK уже сравнительно давно встречаются примеры кода, написанного на С++ (см. src\wdm\audio\msvad\savedata.*).
Hi "Maxim S. Shatskih" <29705@news.rsdn.ru>!
Fri, 11 Jun 2004 11:34:18 GMT you wrote:
MSS> Необходимость много листать несколько файлов (заголовки этого MSS> класса и предков) для чтения кода — в минус.
При грамотном проектировании на C++ кода будет меньше, чем на C.
Одна из хороших черт ООП: инкапсуляция. Если классы правильно
реализованы и документированы, то разобраться что делает код можно
быстрее, чем на C.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.
Ага. А если лепить в столбик в стиле С, то внимание будет на месте?
Общая идея повышения качества ПО — это повышение уровня разрабтки/языка и упрощение изложения/восприятия кода. Если у тебя будет 100 мег плоского кода, то понять в нем ты ничего не сможешь даже если он будет написан в солбик и с минимумом уловных переходов.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Все во врапперах, что ли?
Да. Ни один ресурс не захватывается без врапера. MSS>Верх маразма.
Категорически не согласен. Практика показывает что это не так.
Когда я писал OPC сервер я нашол в сети несколько аналогичных серверов написаных в С стиле ну там были использованы классы чисто для того чтобы с СОМ работать было чуть проще.
Один из нах мне даже удалось собрать... у него было в 3 раза больше исходников, он не соответствовал стандарту, он сильнее грузил процессор и у него текла память и хендлы.
У моего таких проблем небыло. И это при том что я начинал его писать зная о COM лишь то что есть такая хреновина в винде...
MSS>Ну, тут микрософт лоханулся, конечно, то INVALID_HANDLE_VALUE только из CreateFile возвращается.
Поиск по MSDN показал что не только...
MSS>Врапперы твои не требуют чтения документации? это только тебе так кажется
Этот требует. Мои практически нет. Соседи по офису понимали все без доков.
MSS>Точнее — "имея нафиг не нужную обертку"...
В данном случае обертка слишком низкоуровневая.
Но в реальных проектах я на таком низком уровне практически не работаю.
MSS>А! Вот оно! Сначала зовем конструктор, потом ::is_valid(). Супер просто.
Или сначала CreateFile а потом лезем в MSDN и смотрем чемуже не валидный хендл у CreateFile равен.
MSS>А она мешала?
Она не было необходима. А значит мешала. В болие сложном случае таких переменных могло понадобится гораздо больше. И вот тогда бы они точно начали мешать.
MSS>Теперь резюме. Ты написал код, понятный только тебе. Твой же сосед по офису его не поймет.
Мои соседи все понимали. MSS>Ему придется долго и занудно читать башку с врапперами, которые сочинены тобой и понятны только тебе.
Уж лучше пусть ОДИН раз поймет как работают враперы, чем потом сотни раз ищет утечку хендла.
MSS>И за инфой по врапперам придется лезть не в хороший MSDN, а во внутреннюю документацию, которая наверняка хуже.
Все приличные редакторы кода выдают подсказки. Имена методов и их сигнатуры у нормальных программистов интуитивно понятны.
MSS>И человек, который за тобой будет код править, скорее всего выкинет врапперы на помойку и напишет "по MSDNу".
И будет его код в три раза больше и будут у него теч хендлы и будет он ловить эти утечки в несколько раз дольше чем переписывал мой кусок и...
Короче тех кто не понимает что такое врапер на работу дешевле не брать.
MSS>Смартпойнтеры — один разговор. Обертки — бредятина полная. Забивание мозгов лишней информацией.
В чем разница? И те и другие созданы для того чтобы скрывать детали.
MSS>С stdio примерно то же самое.
Вот только там надо не забыть закрыть фаил... А это геморой. Особенно если открыто несколько файлов.
MSS>Это да. Только я бы ISequentialStream использовал бы уже за меня объявлен микрософтом
1)На кой черт мне нужен этот интерфейс определенный черт знает где особенно если моя программа не работает с СОМ?
2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без произвольного доступа что есть маразм.
MSS>Еще забыли про деструктор или release. Раз уж есть хоть один виртуальный метод — то виртуальный деструктор — это святое.
Это догмы. В существовании таких объектов самих по себе без четко определенного хозяина я не вижу ни какого смысла.
MSS>Сами по себе обертки уже есть детали. Те самые.
Детали это то что прячет хорошая обертка. MSS>А если баг в обертке где? Ой млиииин...
В том то и дело если быг в обертке то все сто мест где эта обертка использована будут глючить и баг бысто найдут и исправят. И исправится он сразу везде.
А если этот баг будет в 2х-3х местах из сотни вот тогда... Ой млиииииииин...
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndreyFedotov, Вы писали:
AF> А то! Есть хорошая традиция разделяемая почти всеми программистами: услышав заклинание "Visual Basic" дружно орать: "Фу! Остой!", трясти бубном и совершать другие ритаульно-оскорбительные действия в отношении VB.
Есть такое. Но это от стадного чувства и неумения его готовить. Сейчас с появлением Шарпа ВБ 6 конечно не актуален. А ВБ 7 мало чем отличается от Шарпа. Но раньше связка VC+VB была очень продуктивной.
AF>Причём что меня удивило больше всего, эта традиция распространена и среди самих программистов на VB...
Ну, это уже побочный эффект стадного чувства.
AF>Не экономично. В драйвере гораздо проще этого добиться например так: AF> *( ( DWORD* ) 0x0000000C ) = 0;
Не, мы тут о эстетике, а ты со своей экономией
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MSS>Ни программы на Java, ни на C# -- по 100 разных причин -- не работают и никогда не будут работать столь быстро, как на Си. Ну язык левой ногой задизайнен, что тут сделаешь, -- разработчики компиляторов не винованы, что создатели Жабы были в языках программирования и компиляторах ни уха ни рыла, посему там грабли разложены очень ровным слоем просто везде. Жаба, господа, это просто атас, а реализация ВМ (виртуальной машины) Саном -- это песня. Смотришь, и сразу понятно, -- ребята делают первую в их жизни ВМ. Ляп тут, ляп здесь, засада за углом, обломс там... Скажем все дружное спасибо фирме Сан, которая вбахала в пропаганду и распространие этого убожества несколько миллиардов баксов и таки добилась своего.
Ню-ню.
Java — это философия, резко отличающаяся от остальных парадигм программных систем.
И она стала распространённой от серверов уровня предприятия до сотовых телефонов.
Везде. Абсолютно.
Если Вы лично её не используете — это Ваше личное дело, никто, кроме маркетинга, Вам ничего не навязывает.
Почему "Ляп тут, ляп здесь, засада за углом"? Да потому что Вы лично не привыкли к иному видению "мира" и остаётесь на том уровне, на котором Вам удобно воспринимать окружающее.
MSS>Кроме того, есть еще один очень существенный момент. Собственно написание кода -- это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов и проч) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять в лес намыливается...
Мир всегда был изменчивым, а Вы — нет.
MSS>И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение. Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как.
JavaDOC и комментарии в обычных языках ничего не дают?
MSS>И вот тут начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, исключительными ситуациями и проч.
Веселье начинается тогда, когда человек, приступающий к "разборкам" чужого кода, начинает чувствовать свою неспособность объять необъятное. Ему поможет лишь здравый смысл и диаграммы из разных уровней абстрагирования.
MSS>Ну скажите мне, часто ли в Си встречаются указатели на функции? -- исключительно редко, и только по делу. Поэтому, увидев вызов функции в Си, как правило сразу понятно, какая именно функция вызвалась, можно сходить и посмотреть, что она делает.
В ОО-же языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, хрен поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.
CodeExplorer Вам в помощь.
MSS>Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором. MSS>В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на ОО языке, не разберется никто.
Да нельзя делать иерархическую цепочку (ветвь наследования) слишком длинной! Это нецелесообразно в любых ООП-языках.
А так, лучше использовать UML-инструментарий — понятнее будет.
MSS>Посему, как показывает мой личный опыт, надежность программ, размашисто написанных на ОО языках, оставляет желать лучшего (конечно, если менеджер следит за тем, как пишут код и за творческое использование языка программирования немедленно дает по ушам, то дело, конечно, другое. К сожалению, грязного кода на ОО языках я видел на порядок больше).
Надёжность программ оставалась и всегда будет оставаться в головах разработчиков, а не в парадигме ООП.
MSS>Я уже не говорю про перекрытие операторов, конструкторов копирования и проч. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события?
К сожалению, в ООП слишком много парадигм, например, шаблоны (template), от чег весь вой: с одной стороны это экономит силы и время, с другой стороны ведёт к двусмысленности(n-смысленности) толкований сторонними кодерами.
MSS>Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же программа начинает напоминать сводку новостей времен СССР и приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на ОО языках наломать дров проще простого, что мы и наблюдаем изо дня в день.
Интерфейсы и семантика использования — основные факторы, которые нужно донести до сторонних кодеров. Всё!
MSS>Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен олигофрену, иначе человек, который заменит Вас через 2-4 года, не справится.
Пять баллов! (Полностью согласен)
MSS>Хотите проинициализировать переменную? -- вызовите процедуру. Надо вызвать функцию? -- зовите ее напрямую. Не надо вот этого -- посылания сообщения в Жаба-скрипт, который исполнит XML (взяв его из Registry), который запустит ActiveX контрол, который и сделает, что надо, позвав вашу процедуру через COM-интерфейс (Вы смеетесь? -- зря. Я именно такой код чинил год назад. Очень надеюсь, что создатель этого маразма больше в МС не работает).
По-хорошему сочувствую Вам.
MSS>Связная тема -- сложность языка программирования. Стардарт языка Си -- 200 страниц. Си++ -- почти 1000 (и достаточно много отдано на волю разработчика компилятора). Та отписка, которая должна подразумевать собой описание семантики Жабы, -- это просто смех.
Pascal — 50 страниц;
Modula-2 — 40 страниц;
Oberon — 16 страниц.
(c) Н. Вирт
Java — ~100 страниц (по-моему мнению, библиотеки не считаем)
MSS>Ее авторы скромно обошли молчанием самые интересные и интригующие моменты (ну, все те, где грабли лежат) -- которые и вызывают самый искренний интерес у разработчика компилятора, -- видимо, справедливо полагая, что как ни сделаешь, хуже уже не будет.
Грабли в Java? Где?
Лично я в 1998г. столкнулся с непониманием семантики организации кода (пакеты), а дальше — легко.
MSS>Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает более 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?
"Навороченные конструкции" — это шедевры из области C/C++.
MSS>Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен (а все ведь под него проточено, не так ли?). Наконец, необходимым требованием является 100% backward compatibility библиотек. Ну скажите мне, хоть одна библиотека для Жабы удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о том, что на изучение этих библиотек может уйти полжизни.
На изучение Win32 API может уйти вся жизнь. И только небольшая чать документирована в MSDN на нескольких CD.
Что Вы хотите от библиотек Java, которые занимают объём, равный Windows 95 OSR2 (если не Win98)? По-моему, тот кто занимается узкой областью, тот использует узкие аспекты библиотеки, знает, где что закопано и не фырчит, так как это отраслевой стандарт.
MSS>Опять же, смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Что касается Си, то всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью [программистов]. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, посему вероятность обнаружить ошибку в компиляторе с Си гораздо ниже, чем в компиляторе с Си++ (чтобы найти баги в компиляторе с Жабы, в особенности Сановском, напрягаться не нужно, -- баги Вас сами найдут).
Первый раз слышу о багах в компиляторе Java.
MSS>Резюмирую. При создании операционных систем и большинства других серьезных проектов предъявляются очень жесткие требования к производительности и надежности.
Требования-то предъявляются, а вот исполняются ли, по-хорошему?
MSS>Первое существенно зависит от языка программирования. Второе зависит от как от тестирования, так и от дисциплины программирования и читаемости/модифицируемости кода, которые также достаточно сильно связаны с языком. MSS>Если внимательно посмотреть, то все хорошие серьезные программы на Си с примесью ассемблера. Ворд. Эксель. Ядро НТ. Ядро Линукса. Кодогенераторы (VC, GNU, etc. Гнусный кодогенератор, конечно, никуда не годится, но про удачном расположении звезд может и правильный код породить). Единственная хорошая программа, написанная на Си++, знакомая мне, -- это MS SQL сервер.
)
Насмешили. Сколькл багов и дыр нашли в MSSQL сервер, знаете? Спец.вирусы уже пишут...
MSS>Посмотрим же теперь на софт, написанный на Си++. Exchange Server. Outlook. PowerPoint. WMP. Нужны комментарии?
...Windows.
Самая небезопасная ОС в мире.
MSS>Конечно, все вышесказанное относится к большим промышленным проектам, где объем кода измеряется миллионами и десятками миллионов строк и над которым работает хотя бы человек 50. К софту класса "t.c" длиной в 100 строк это не относится -- это можно писать на любом языке программирования.
???
MSS>пи-эс. Я тут много пинал Жабу и мало -- C#. Однако, учитывая вышесказанное и тонкую связь, имеющую место быть между этими двумя языками, полагаю, что есть основания считать, что и проблемы у них будут достаточно общими. Хрен, он ведь редьки не слаще.
Проблемы будут везде!
Независимо от того, на чём можно писать "Hello World!".
Люди — вот главные баги.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>----------------------------------------------------------------------------------------
[] MSS>Таким образом, скорость работы программы важна. Практика показывает, что если программа (серьезная, а не демонструшка в 1000 строк) работает слишком быстро, в нее немедленно добавляется какая-нибудь забавная функциональность, которая увеличивает объем продаж на 10% и съедает все ресурсы.
MSS>Ни программы на Java, ни на C# -- по 100 разных причин -- не работают и никогда не будут работать столь быстро, как на Си. Ну язык левой ногой задизайнен, что тут сделаешь, -- разработчики компиляторов не винованы, что создатели Жабы были в языках программирования и компиляторах ни уха ни рыла, посему там грабли разложены очень ровным слоем просто везде. Жаба, господа, это просто атас, а реализация ВМ (виртуальной машины) Саном -- это песня. Смотришь, и сразу понятно, -- ребята делают первую в их жизни ВМ. Ляп тут, ляп здесь, засада за углом, обломс там... Скажем все дружное спасибо фирме Сан, которая вбахала в пропаганду и распространие этого убожества несколько миллиардов баксов и таки добилась своего. MSS>Кроме того, есть еще один очень существенный момент. Собственно написание кода -- это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов и проч) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять в лес намыливается... MSS>И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение. MSS>Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как. MSS>Ну скажите мне, часто ли в Си встречаются указатели на функции? -- исключительно редко, и только по делу. Поэтому, увидев вызов функции в Си, как правило сразу понятно, какая именно функция вызвалась, можно сходить и посмотреть, что она делает. MSS>В ОО-же языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, хрен поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.
Ну, это просто недисциплинированное использование возможностей ОО. Не наигрался еще народ с фичами MSS>Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором.
Да, круто! Я б точно такого уволил! MSS>Посему, как показывает мой личный опыт, надежность программ, размашисто написанных на ОО языках, оставляет желать лучшего (конечно, если менеджер следит за тем, как пишут код и за творческое использование языка программирования немедленно дает по ушам, то дело, конечно, другое. К сожалению, грязного кода на ОО языках я видел на порядок больше). MSS>К сожалению, на ОО языках наломать дров проще простого, что мы и наблюдаем изо дня в день.
Да, возможностей нагадить — значительно больше!
MSS>Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен олигофрену, иначе человек, который заменит Вас через 2-4 года, не справится. MSS>Хотите проинициализировать переменную? -- вызовите процедуру. Надо вызвать функцию? -- зовите ее напрямую. Не надо вот этого -- посылания сообщения в Жаба-скрипт, который исполнит XML (взяв его из Registry), который запустит ActiveX контрол, который и сделает, что надо, позвав вашу процедуру через COM-интерфейс (Вы смеетесь? -- зря. Я именно такой код чинил год назад. Очень надеюсь, что создатель этого маразма больше в МС не работает). Смех сквозь слезы! MSS>Связная тема -- сложность языка программирования. Стардарт языка Си -- 200 страниц. Си++ -- почти 1000 (и достаточно много отдано на волю разработчика компилятора). Та отписка, которая должна подразумевать собой описание семантики Жабы, -- это просто смех. MSS>Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает более 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?
Ну, я ж говорю — не наигрались! ИМХО чем "дубовей" код, тем он правильней, и зачастую — быстрее. MSS>Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен (а все ведь под него проточено, не так ли?). Наконец, необходимым требованием является 100% backward compatibility библиотек. Ну скажите мне, хоть одна библиотека для Жабы удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о том, что на изучение этих библиотек может уйти полжизни.
О-о-о-о-!!!!! Кая вас понимаю!!!!! MSS>Опять же, смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Что касается Си, то всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью [программистов]. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, посему вероятность обнаружить ошибку в компиляторе с Си гораздо ниже, чем в компиляторе с Си++ (чтобы найти баги в компиляторе с Жабы, в особенности Сановском, напрягаться не нужно, -- баги Вас сами найдут).
В каком-то буржуйском жкрнале была даже такая ежемесячная колонка — ошибка месяца (в компиляторах С++). MSS>Резюмирую. При создании операционных систем и большинства других серьезных проектов предъявляются очень жесткие требования к производительности и надежности. MSS>Первое существенно зависит от языка программирования. Второе зависит от как от тестирования, так и от дисциплины программирования и читаемости/модифицируемости кода, которые также достаточно сильно связаны с языком. MSS>Если внимательно посмотреть, то все хорошие серьезные программы на Си с примесью ассемблера. Ворд. Эксель. Ядро НТ. Ядро Линукса. Кодогенераторы (VC, GNU, etc. Гнусный кодогенератор, конечно, никуда не годится, но про удачном расположении звезд может и правильный код породить). Единственная хорошая программа, написанная на Си++, знакомая мне, -- это MS SQL сервер. MSS>Посмотрим же теперь на софт, написанный на Си++. Exchange Server. Outlook. PowerPoint. WMP. Нужны комментарии? MSS>Конечно, все вышесказанное относится к большим промышленным проектам, где объем кода измеряется миллионами и десятками миллионов строк и над которым работает хотя бы человек 50.
Ну, не вырос еще ОО-подход из коротких штанишек! Подрастем, ходить научимся, перестанем падать на каждой кочке. MSS>пи-эс. Я тут много пинал Жабу и мало -- C#. Однако, учитывая вышесказанное и тонкую связь, имеющую место быть между этими двумя языками, полагаю, что есть основания считать, что и проблемы у них будут достаточно общими. Хрен, он ведь редьки не слаще.
Все так. Именно поэтому вирт как альтернативу С++ пропагандирует оберон, описание которого на 19 (кажется страницах), а возможности — те же. Я тут постил уже ссылки на доклад Вирта.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью >>технических средств.
MSS>Совершенно верно! Только почему это плохо?
MSS>Фирма Макдоннел-Дуглас сильно гордилась тем, что уменьшила на F-15 число приборов на доске до 30, вместо 48 у "Фантома". Ну наверное, не зря гордилась, правда?
MSS>А ведь могли бы сказать — "настоящий летчик и 48 приборов осилит"...
Тот случай когда аналогия хорошая но совершенно не верная. Лётчику требуется принимать жизнено важные решения часто за доли секунды... Причём скорость реакции тут куда важнее, чем глубина анализа или стратегическая продуманность решений. Ну во-первых, большинство пилотов не гении, а во вторых — талантливый пилот как раз стратегией то и занимается — для этого у него и есть мозги, и тут важно — что бы исбыток информации от приборов не занял его мозги на 110% Потому то фирма и гордилась тем, что смогла свести количество приборов к минимуму... Но! Вот пример из той же области: АВАКС Я не думаю, что фирма гордилась бы тем, что они выкинули бы половину нужных приборов из приборного отсека АВАКСА... Потому — что для него — как и для научного корабля или марсохода — важна функциональность и максимум возможностей. И приборов там сотни если не тысячи. Но тем не менее принцип минмализма действует и там. Никто не будет ставить на АВАКС 10 одинаковых приборов, если достаточно одного. Потому что дорого и энергоёмко, но никто не будет и экономить на ещё одном приборе — даже если он частично дублирует другие — но приносит реальную пользу.
По поводу C и С++. Одно из ключевых преимуществ языка — любого языка, это СОКРЫТИЕ информации — инкапсуляция поведения. Для того, что бы можно было видеть лес за деревьями. И с этой точки зрения — C++ гораздо эффективнее, чем C, так как язык позволяет управлять степенью инкапсуляции в гораздо более широких пределах: хочешь — пиши на встроеном ассемблере — хочешь — используй сложение комплексных чисел в виде близком естественному, ну а хочешь — оформяй бухгалтерские проводки в виде классов или операторов. Выбор за тобой. И, как показывает практика — на сегодня это вполне эффективный и практичный инструмент. Хотя появился C#... С другой стороны есть какие системы как Mathcad или Maple, где используется собственный язык, ориентированный на решение прикладных задач этих систем. Есть так же CAD или бухгалтерские системы — где есть свои встроеные языки, гораздо более подходящие для работы с этими системами, чем C или C++.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Пока что мне там ответили
Где там то?
MSS>Насчет драйверов. Проекты маленькие по объему (мегабайт густо комментированного исходника — это в этой области большой проект) — но как бы очень насыщенные по логике.
Логика она и в африке логика. Скорее уж ваша специфика это много низкоуровневой мешуры, жесткие требования к производительности (видимо) и надежность, так как от драйверов зависит вся система.
MSS> В этом области "терять сцепление колес с дорогой" и витать в облаках абстракций вряд ли оправдано.
С первым согласен. Да тебе и виднее. А вот со вторым нет. Абстракция нужна везде. И чем сложнее решаемая задача тем болше она наужна.
Давно замечено, что средний человек не может держать в поле зрения более 7 предметов одновременно. Если тебе нужно параллельно котролировать более семи параметров, то без введения асбтракций ты рано или поздно прийдеш к тому, что будеш смотреть на код с тихим ужасом.
MSS> И требования к надежности очень высоки. Потому ИМХО оправдано не прятать детали реализации, а выставлять наружу как есть.
Мне кажется, во всем нужно быть размным. Бесспорно неоправданные побочные эффекты и срытая логика вредны. И уж темболее в коде который должен быть быстрым и надежным. Но и примитивизация — это тоже не выход. Мне как пользователю совершенно пофигу почему будет глючить имеющийся у меня драйвер. Будь то неередсказуемое поведение в следствии неграмотной инкапсуляции и побочных эффектов, или в следствии того, что разработчики драйвера перестали отслеживть все повороты логики в следствии превышения порога понимаемости из-за того, что они забили на абстракцию.
MSS>Абстракции там получаются очень крупноблочные, скорее как в COMе, а не как в классических ОО языках типа Дельфей, Джавы и Шарпа.
Абстракция — понятие очень относительное. Всегда можно выделить мелкие и крупные абстракции. Твоя злость скорее свсего основывается на примерах нерадивого выделения абстракций.
Кстати, году в 1994 я наблюдал изумительный пример маразма в этой области. Одному орлу поручили написать функцию преобразоватия числа в строку прописью (русское написание числа). Так вот он вместо того, чтобы написать одну простую функцию состряпал класс. Это надо было видить. Я плякаль... После этого мы переписали его код выбросив процентов 40. Но это же не проблема ООП. Это проблема умения выделять абстракции.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Как можно жить без in-place определения переменных. Как это напрягало в паскал, когда одныжды пришлось что-то на нём писать! А отсутсвие декодирования имён! Этож как можно писать проект, если не выполняется проверка корректности типов и количества аргументов? А работа с памятью? Тривиальная работа со строками превращается в геморрой. Кто где память выделяет, и кто должен её удалять? Реализация функции split на голом си занимает едва ли не страницу текста. А сколько там соатнется дырок, связанных с переполнением буфера!
А контейнеры? Вы себе представляете работу на голом С со структурой вроде map<int,list<string> >? То ли я раньше не сталкивался с этим, но сейчас мне просто страшно представить, как это можно сделать без классов. Или вот работа с 3D графикой. Без перегрузки операторов, без конструкторов копирования. Как-то в юношеские годы была безумная идея написать трассировщик лучей на делфях (ещё второй версии). Посмотрел я на, то выглядят операции с векторами и ужаснулся.
Один из преподов по программированию как-то сказал, что программы по мере роста начинают жить своей собственной жизнью. Это правда!
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Физичексие ограничения человеческого организма — 7 объектов наблюдения / внимания.
MSS>Ага. И если забивать башку девелоперу нюансами типа — а protected это у нас поле или private? — то не останется объема внимания на понимание логики.
А не надо файлы исходников листать. Надо диаграммы классов и состояний смотреть. Это следующий уровень абстракции.
E>>А пример реализации твоей идеи — McDonalds. Ничего не умеющие студенты, делающие >>низкого качества еду.
Мне было противно там работать.
MSS>Прекрасный пример! Многомиллиардная корпорация!
Ну если ты считаешь, что делает McDonalds — хорошо, то у меня просто нет слов. А если это еще и применить к программированию, то вообще...
Ты свою семью в McDonalds поведешь?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ага. И если забивать башку девелоперу нюансами типа — а protected это у нас поле или private? — то не останется объема внимания на понимание логики.
Не понял аргуманта.
MSS>Прекрасный пример! Многомиллиардная корпорация!
А теперь посмотри на амереканцев... жрут в МакДональдсе и выглядят как... ну вы поняли... Короче я считаю что МакДональдс гораздо опаснее чем БенЛаден и компания... В отличии от террористов МакДональдс убивает милионами причем с особой жестокостью и цинизмом.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
>незвоможно (да и библиотеки порой всретчаются у которых нет исходников). Так что >приходится верить. Именно поэтому придумали такую вещь как инкапсуляция.
Инкапсуляция — это другое. Это отделение интерфейса от имплементации, и запрет лазить к деталям имплементации в обход оговоренного интерфейса.
Синтаксическое упрятывание скрытой семантики к инкапсуляции отношения не имеет. Полно ОО языков (да та же Джава, которая во многом сделана умнее Си++, в ней меньше создающих энтропию вещей) где не бывает "operator T", который вызывается неявно без каких бы то ни было напоминаний.
>Слова о вреде полиморфизма слышу впервые.
А где они?
>операторов? Да не так часто их и переопределяет. Слава богу те идиоты просто не >справятся с перегрузкой.
Нет. Справятся, и справятся так, что потом умный не разберется в их бреде.
Любой дурак может юзать любую фичу. А понимать, нужна ли она — ума требует.
Это как обезьянка, которая увидела рычажок и дернула за него.
VD>МС сделала верный выбор спроектировав Шарп снуля.
Точнее, скопировав с Джавы в значительной степени.
>Очень многих проблем они избежали. >И я совсем не понимаю почему не забыть об откровенно пережившем себя С, забить на С++ и >пользоваться современным языком избавленным от большинства проблем.
То-то практически все серьезное (т.е. системное) программирование делают на Си.
VD>2 возможно. Но в 2001 ти слова вряд ли могли прозвучать.
Почему? Человек, видимо, имел отношение к разработке микрософтного компилятора Джавы.
Кстати, я не знаю, что там за грабли в Джаве он нашел... ИМХО она как раз свободна от многих извратов Си++. Действительно ОО, а не пародия на него.
VD>Во-во. И если уж говорить о стоимости сопровождения и развития, то плевки в сторону >явы и плюсов выглядят просто смешно.
Ну Джавы — возможно. Там нет operator+ и прочих abstract datatypes наворотов, которые, кстати, к ОО отношения не имеют. Это из другой оперы.
VD>[b]На сегодня важна не простота в смысле приметивности. Важна простота в смысле >непротиворичивости, отсуствия множества способов выражения одного и тогоже,
Да. А вон почитай, как тут человек признавался в романтической любви к Си++ именно потому, что там одно и то же можно выразить по-разному
>концептуальной стройности
Си++ ее давно утерял, да и не факт, что имел (в отличие от Джавы и Шарпа).
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, Maxim S. Shatskih
V>На 100% согласен с тем, что сказано про запутанность кодов и монструозность библиотек.
V>Когда читал про оптимизацию компиляторов, вспомнился один пример немножко из другой области, но весьма жизненный.
V>Есть две среды разработки специфических приложений — 1С и MBS Navision. Обе занимаются не компиляцией, а интерпретацией своих скриптовых языков. 1С написан, видимо, на С++ с широким использованием COM, в результате чего производительность встроенного языка при исполнении на P4 примерно равна производительности ROM-бэйсика на IBM XT. Navision пошустрее будет. Раз в 10. Тоже, конечно, безобразие, но но разница в 10 раз — это, согласитесь, аргумент.
Скажем так: опыт программирования на 1С у меня не большой, а точнее сказать ваще не большой, вчера когда читал этот треп скачал и установил, и начал писать на нем ). Но..
Не знаю про Навизион, но:
1С, в чем то очень ограниченый язык, согласен что он расширяемый вроде бы, не в курсе, и не буду спорить по этому поводу... опять таки но:
чем больше и гибче возможности по программированию задачи тем на мой взгляд лучше.
Т.е. на том же Си++ описать можно все... а в 1С только в пределах того что она позволяет..
Хотя конечно хотелось бы взглянуть на реализацию расширения 1С кто ссылкой кинется буду очень признателен.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Похоже, что сначала придумали ОО и Си++ — то есть "как сделать то же самое, но через зад, с кучей лишнего и в шизанутом синтаксисе" — а тут же возникла нужда в рефакторинге. Энтропии в ОО языках больше, чем в Си.
Я так понял это наезды вобще на высокоуровневые технологии и ООП.
Хорошо. Может обсудим надежность во такой вот функции, которая торчала из одной библиотеки.
int MtGetLastMail( const int handle, char * path, int *lenofpath );
Получения имени файла, в который было записано пришедшее с сервера письмо.
handle – ....
path – строка символов для приёма имени файла;
lenofpath – адрес переменной типа int, в которой записана длина приёмной строки.
Если имя файла (включая завершающий ноль) больше, чем приёмная строка,
то в приёмную строку записывается строка нулевой длины, а в переменную
по адресу lenofpath записывается длина строки, необходимая для приёма имени файла.
Возвращает код возврата.
И ее высокоуровневый аналог [b]со скрытым поведением
string GetLastMal() — Все! больше ничего не надо. Ошибки через иключения плевать. А handle инкапсулирован в классе.[/b]
Так какая конструкция подходит для серьезных проектов?
По поводу документации: описание этой функции очень неполное, как минимум раз в 5 его побольше надо было сделать там где описан процесс возврата строки. Можно конечно сказать что у прграммистов руки были кривые ктороые это писали, но к чему эти разговоры если тогда у 90% разработчиков руки кривые.
В вызове этой фукции как минимум десяток потенциальных багов может случиться. С длинами буферов итд.
Хотя тут скрытого поведения нету. Вот поэтому крупный софт и глючный на основе низкоуровневых технологий (без скрытого поведения), и лезут через инет на комп всякие черви через всякие щели.
В подавляющем большинстве случаев безразлично, как именно обломалась функция. Это относится и к exceptions, и к кодам ошибки типа NTSTATUS и HRESULT.
Как правило, нужда в знании причины облома возникает уже в UI, чтобы оную причину показать юзеру. В ОО фреймворках все это лежит в объекте exception.
В остальных случаях — ну редко это нужно. Очень редко. Например, при придумывании нового цифирного имени файла — открываешь FILE0000.DAT — получил STATUS_OBJECT_NAME_COLLISION — открываешь FILE0001.DAT и дальше.
Потому на уровне языка энфорсировать, какие именно exceptions имеет право кидать функция — просто затрудняет работу и все.
Джаву я знал в 97ом году, и то как игрушку. Но эта спецификация там успела достать. На деле она ограничивает то, чем можно пользоваться в методе. Нельзя пользоваться теми вещами, которые имеют более широкую спецификацию throw. Вокруг них придется try/catch делать, в котором переделывать одни разновидности exceptions в другие. Изврат редкостный.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Честно говоря, хорошие exceptions в OLE Automation. Код ошибки и строка. И все. Хватит. На кой черт нужны _классы_ exceptions?
Да уж, гемор ещё тот. Забыл один раз где-нибудь обработать и никто не узнает было ли исключение вообще.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, iZEN, Вы писали: ZEN>К сожалению, в ООП слишком много парадигм, например, шаблоны (template), от чег весь вой: с одной стороны это экономит силы и время, с другой стороны ведёт к двусмысленности(n-смысленности) толкований сторонними кодерами.
В ООП нет никаких шаблонов. Эта парадигма никакого отношения к ООП не имеет.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ага, новичок. С 93го года на этом языке работаю. MSS>Более того. Для UI я им и по сей день пользуюсь, естественно.
Многие мои знакомые пользуються компьютером много лет, но дальше инсталляции игр, из развитие в IT области не пошло. Печально что вы используете гоночный автомобиль для перевозки картошки. И ещё более грустно, что вы и не подозреваете и даже отказыветесь увидеть то, о чём вам тут все говорят. Есть старая добрая поговорка — "если тебе 10 человек сказали, что ты пьян, то иди проспись ,)"
Да и программирование UI никогда не считалось уважаемым занятием.
B>> Э, какой горячий джигит ,). B>> Кроме x89 архитектуры процессоров есть ещё десятки других платформ, иногда очень >>экзотических. И для этих платформ нет С++ компилятора, а есть только С. MSS>Учите матчасть. gcc портирован на такую экзотику, что вряд ли бывала в России. И для экзотических платформ в наше время — портируют gcc, а не пишут свой компилятор.
Платформ гораздно больше . Я смотрю на свой рабочий стол — принтер, модем, мобилка, часы с записной книжкой, DECT телефон, монитор, UPS(под столом . И везде стоят микроконтроллеры и микропроцессоры. Портировать под каждый девайс gcc — дорого и можно столкнуться с лецензионными проблемами, да и зачем из пушки да по воробьям. Поэтому, как правило производитель всякой мелочи имеет свой компилятор С.
Как вы думаете — проприетарный BIOS вашей материнки скомпилирован gcc ,) ?
>>То есть это вопрос переносимости, который очень актуален для некоторых промышенных >>отраслей. MSS>Бред. См. выше.
Хотя это бред не основное направление мой проффесиональной деятельности, но и он мне денег приносит. БОЛЬШЕ БРЕДА!
B>> А лет через 10-20 и С++ тоже могут на свалку викинуть, как когда то перфокарты. MSS>То-то UNIX 30 лет живет без существенных изменений Есть такое понятие — классика.
Слышали про закон Мура, он относиться не только к числу транзисторов на квадратный метр. И 30 двадцатого века, это совсем не то что 30 лет двадцать первого. Да через 10 лет С++ будит жить поживать, но спрос на его специалистов значительно снизиться. Следите за прогрессом — появление новых языков программирования; новых методологий; поддержка виртуализации операционных систем на уровне железа; да и вообще огромные темпы развития вычислительных мощностей; новые интелектуальные 3D интерфейсы сладящие за нашими глазами, дыханием, биотоками, понимающими нашу речь; Всё это, по Карлу Марксу, просто не может не дать качественного скачка, после которого следующие поколение будет ужасаться при виде клавиатуры и мышки.
Здравствуйте, VladD2, Вы писали:
VD>Хочеш сказать, что 0 таки приводится к этуму автоматом?
C# Language Specification
6.1.3 Implicit enumeration conversions
An implicit enumeration conversion permits the decimal-integer-literal 0 to be converted to any enum-type.
VD>Нда, это грабли. Зачем они разрешили это совершенно не ясно. Видимо из-за инициализации нулем. Козлы, могли бы запретить хотя бы присваение литералов.
Из-за флаговых enums. Любой здравомыслящий человек при работе с флагами в случае, если ни один из флагов не установлен, захочет передавать литеральный 0, вместо того чтобы явно приводить его или заводить Default = 0, как, скажем, в CommandBehavior. А грабли из-за того, что создателям компилятора было лень проверять FlagsAttribute (он проверяется только в рантайме — Enum.ToString), и все эти 0, |, &, ^, ~ работают даже с нефлаговыми enums.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>А уж те, что исходники USER видели, с патчами "А вот тут затычка, потому что в PowerPoint квадратик рисуется неправильно", "а вот тут придется развести немножко грязюки, чтобы ПаэурБилдер и написанные на нем программы правильно работали", с именами функций типа zzzDesktopThread() и доведенной до маразма венгерской нотацией — эти и вовсе чудеса рассказывают.
Вот, кстати, свежая статья с несколькими примерами на эту тему. Особенно мне понравилось про SimCity
Неужели правда?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>В том-то и фишка, что надо ЗАГОЛОВОК смотреть. В случае f(&obj) — все видно в месте вызова, без заголовка.
Ничего не понятно. Большие обьекты всегда передаются по ссылке (указателю) модифицируется обьект или нет должно следовать из имени функции.
object_gradeUp(obj);
object_name_get(obj);
Четко и ясно. Все зависит от прямоты рук.
На самом деле С++ это тот же С только гораздо лучше. К примеру для GUI паттерн signal/slot крайне полезен. Попробуйте сделать это на голом С, так чтобы это было удобно использовать, а мы посмотрим.
AF> Полностью согласен. Если сделать окна с Non-client area как отдельные — контейнеры для окон представлений, то логика работы с окнами упростилась бы на порядок и код писать стало бы гораздо легче. Но об этом в своё время не думали...
ИМХО на USER нужно архитекторов учить — как на примере плохо спроектированной системы. Типичный случай. И как раз пример того, к чему ведут архитектурные огрехи:
а) затрудняется труд тех, кому писать код поверх этого
б) затрудняется развитие системы
в) появляется необходимость во врапперах типа MFC, чтобы упрятать безобразие, и причем даже врапперы не справляются
г) рефакторинг почти невозможен, почти любая правка приводит к слому того, что написано уровнем выше
д) так же невозможна реимплементация с нуля
Ну и так далее.
А уж те, что исходники USER видели, с патчами "А вот тут затычка, потому что в PowerPoint квадратик рисуется неправильно", "а вот тут придется развести немножко грязюки, чтобы ПаэурБилдер и написанные на нем программы правильно работали", с именами функций типа zzzDesktopThread() и доведенной до маразма венгерской нотацией — эти и вовсе чудеса рассказывают.
Известно, что GDI в НТ переписали с нуля. Потому как правильно спроектированная система (одна из лучших подсистем у Майкрософта ИМХО), и тут дело не в Си или Си++, а в голове . А вот USER туда перетащили из Вин 3.1, перетащили за уши — и, по слухам, потому, что сам Майкрософт в этом коде запутался напрочь, и боится в нем хоть что-то тронуть.
Здравствуйте, vstrogov, Вы писали:
V>Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где-то назад на редмондовском
форуме разработчиков драйверов (в частности в нем участвуют многие ключевые разработчики NT).
2 возможно. Но в 2001 ти слова вряд ли могли прозвучать.
V>Высокая стоимость сопровождения кода C++ и вред скрытой семантики — факт.
Собственно с этим я и не спорю. Но С в поддержке как минимум не дешев.
V>С тоже не лишен недостатков.
Во-во. И если уж говорить о стоимости сопровождения и развития, то плевки в сторону явы и плюсов выглядят просто смешно.
V>Но главным критерием на мой взгляд является уместность употребления языка в конкретном культурном контексте и традиции.
V>Хорошо то, что принимается сообществом (или большей/авторитетной частью с возможными исключениями) и соответствует большинству доступных материалов.
V>Для системного программирования (режим ядра) — С, в других областях — могут быть другие языки.
Я бы поспорил на счет уместности С++ в драйверах, ну, да не мне судить. Я ими почти не занимался. Но ты на название темы взгляди? Или у нас драйверы — это единственное серьезное место?
Нзвал бы "Уместность С++ в драйверах и ядре ОС" и вряд ли кто особо спорить стал. Да и вообще читать.
ЗЫ
Тут давно идут баталии C++ vs. C#, и на их фоне C++ sv. C выгдядит как неудавшаяся шутка.
Более безопастный, надежный, простой, читабельный и т.п. нужен. Но при этом не хочется отказываться от удобных и приятных вещей. Да и простота языка сегодня понимается не так примитивно как понимает ее Maxim S. Shatskih. Например, синтаксис шарпа намного сложнее чем С++, но писать на нем (и что важнее читать!) проще и быстрее.
На сегодня важна не простота в смысле приметивности. Важна простота в смысле непротиворичивости, отсуствия множества способов выражения одного и тогоже, концептуальной стройности, сбалансированности и т.п.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MSS>>Кстати, их наличие — равно как и вообще концепция nonclient area — одна из >мерзейших фич USERа.
Потому что намного более удачный подход — два окна, одно внутри другого.
Самое главное — Си++ ная обертка над USER под названием MFC именно так и делает, и плевать она хотела на nonclient area.
Внутреннее окно называется view. То же самое было и в TurboVision, где window — это окно с рамкой, а в него еще отдельно вставлялся interior. Кажется, и в AWT то же самое.
В большинстве случаев это так. Ну и зачем тогда понятие nonclient area, а заодно второй комплект сообщений WM_NCxxx? Есть окно фрейма, ему принадлежит рамка и кнопочки по углам. А в него вставлено окно view, ему принадлежит изображаемый документ. Очень все разумно.
Скроллбары же ИМХО нужно отдельными дочерними окнами делать. Причем окнами совершенно стандартного класса Scrollbar.
Здравствуйте, 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 используют как правило те, у кого зарплата больше, хотя это и локальная закономерность замеченная мной
Вывод можно сделать только один. Плохие программисты были и будут всегда и везде. И если MS (ну и не только) берет на работу студентов, то и качеству кода удивляться не приходится. Они же только учатся, а получают копейки. И научившись чему-то, сразу уходят на нормальную зарплату в другое место. Так что это проблемы фирмы.
Так что язык программирования здесь абсолютно не причем. Чем мощнее и гибче язык, тем большая квалификация нужна для работы с ним. И наоборот. Да здравствует VB! :)
E>Так что язык программирования здесь абсолютно не причем. Чем мощнее и гибче язык, тем >большая квалификация нужна для работы с ним. И наоборот. Да здравствует VB!
Речь не об этом. А о том, что есть фичи Си++, которые не приносят никакой пользы, и приносят при этом вред. Шизанутый язык это (особенно последние новшества, которые грубо противоречат тому, что подавалось как основы языка), и восторгов совершенно не заслуживает. Вот и все.
Практическое использование Си++ нередко требует разработки внутрифирменного документа о том, какие фичи _запрещено_ использовать. Просто чтоб код нечитаемый не вышел, и чтоб не было нужды в рефакторинге
Это как известный анекдот: внедрение безбумажных систем делопроизводства привело к росту продаж принтеров и увеличению количества напечатанных за год листов.
Про ОО и рефакторинг — честно говоря, то же самое. Вот я задал вопрос, что такое "завистливые функиии". Мне ответили. Из ответа понятно, что в Си такое явление невозможно в принципе.
Похоже, что сначала придумали ОО и Си++ — то есть "как сделать то же самое, но через зад, с кучей лишнего и в шизанутом синтаксисе" — а тут же возникла нужда в рефакторинге. Энтропии в ОО языках больше, чем в Си.
Еще пример. Программа на Си читается безо всякой browse info, с использованием одного лишь grep, чтобы найти, где объявлена функция. На Си++ с этим туго. Там BSCMAKE нужен. А зачем? Плюсы-то какие?
Здравствуйте, Voblin, Вы писали:
V>Промежуточный вывод: те, кто сочинял модуль учёта в 1С думали в основном о логике предметной области (ну там проверить остатки, снять резервы, двинуть взаиморасчёты и т.д.), а навижионистам пришлось сделать всё вручную и, соответственно, до оптимальности алгоритмов дело вообще не дошло.
V>А если всё это реализовывать чисто на С, то результат мог бы получиться ещё более плачевным: программа, скомпилированная самым супероптимизирующим компилятором, вполне может оказаться тормознутее, чем то же самое, исполняемое интерпретатором 1С.
V>Вывод:важна не только и не столько оптимизация, заложенная в средство разработки, но и закладываемые в "философию" средства разработки средства обеспечения простоты и ясности реализации целевого функционала. V>(что, в общем, совпадает с выводами, следующими из "текста написанного нашим соотечественником, работающим в микрософтовской команде компиляторов").
Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
С остальным полностью согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
E>Физичексие ограничения человеческого организма — 7 объектов наблюдения / внимания.
Ага. И если забивать башку девелоперу нюансами типа — а protected это у нас поле или private? — то не останется объема внимания на понимание логики.
E>А пример реализации твоей идеи — McDonalds. Ничего не умеющие студенты, делающие >низкого качества еду.
Hello, Maxim!
You wrote on Fri, 11 Jun 2004 11:39:42 GMT:
MSS>>> Творческое пользование темплейтами также сможет доставить потомкам MSS>>> немало приятных минут. S>> Бывает. Но если нет шаблонов, то вместо них на помощь приходят S>> макросы... А это вообще жопа.
MSS> Темплейты как раз хорошая фича. Одна из лучших в Си++.
Хорошая. Но в неумелых руках такая же опасная, как и объявление функции без
аргументов в C. И виртуальные функции — тоже хорошая фича, и тоже опасная,
хотя и не такая опасная, как шаблоны. И что самое главное, обе этих фичи
позволяют избежать дулирования кода, что радикально облегчает сопровождение
программ. Как, впрочем, и макросы с указателями на функции в С.
MSS>>> Вышли из блока -- значит, вышли, и нечего кроме. S>> И забыли закрыть половину хэндлов....
MSS> Сразу видно. Локально видно. Легко править.
Править, может, и легко, а вот дописывать новую функциональность — трудно.
Кроме того, налицо подмена понятий — цель не в том, чтобы ошибки исправлять
легче было, а в том, чтобы ошибок меньше было, при тех же трудозатратах.
MSS>>> Очевидно, что чем проще язык программирования, тем трудней сделать MSS>>> на нем семантическую ошибку. S>> Если б это было правдой, все бы до сих пор писали на ассемблере.
MSS> Ассемблер сложнее Си.
Смотря какой. Хотя даже для x86 — не сложнее С, примерно одна фигня. А вот
писать на нем — сложнее чем на С. А на С++ писать проще, если квалификация
позволяет. Хотя язык сложнее.
MSS> Си — оптимальный язык для близкого к машине программирования. MSS> Позволяет все, что и ассемблер (ай, ну да, кроме CPUID — и при MSS> этом не содержит скрытой семантики.
Скрытой семантики нет и в С++ — она только для закоренелых сишников скрытая.
MSS> Прятать мелочи — глупо.
Нет, прятать их — целесообразно. Что, например, делает функция memcpy, как
не прячет мелочи?
MSS> Баги будут именно в них.
Баги будут в них, если их выставлять на показ, т.е. каждый раз переписывать
заново.
MSS> The devil is in the details.
Во-во.
MSS> Потому имеет смысл выставить эти детали бесстыдно наружу, чтобы MSS> быстрее баг увидеть, если он там есть.
Чтоб за деревьями леса не увидеть... Попробуй найди баг в функции из 1000
строк, из которых 2/3 — обработка ошибок и очистка ресурсов. Достаточно 1
раз нерешливо написанную на С программу переписать на С++, чтобы в этом
убедиться.
А насчет новичков — это сейчас их в С не осталось, а посмотреть на
ширпотреб, написанный в конце 80х-начале 90х годов "среднестатистическим
программистом". На С++ мне такой кошмар ни разу не попадался.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 alpha
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Crab, Вы писали:
S>>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
V>>Ага, но при этом легко получить вариант a la Navision.
C>Хехе. А ведь РСДН-то Навизионцы читают )
Ну и что? Думаете, они сами редко делают вот так: [ ]?
Здравствуйте, Exhumer, Вы писали:
E>Вывод можно сделать только один. Плохие программисты были и будут всегда и везде. И если MS (ну и не только) берет на работу студентов, то и качеству кода удивляться не приходится. Они же только учатся, а получают копейки. И научившись чему-то, сразу уходят на нормальную зарплату в другое место. Так что это проблемы фирмы.
Здравствуйте, AndreyT, Вы писали:
AT>Здравствуйте, VladD2, Вы писали: VD>>Дык тебе и говорят, что нет проблем в операторах. Ты их сам придумал. А есть проблемы в идиотах использующих вещи не по назначению.
AT>Тебе просто не удаётся понять, что речь как раз идёт о наличии такого понятия как "вешь, которую можно использовать не по назначению". Поскольку число идиотов примерно постоянно в любой системе координат и снижению не поддаётся, то надо говорить о снижении числа двусмысленностей.
AT>Когда Максим говорит про перегрузку, он совершенно прав. AT>Правило коммутативности обязано выполнятся, стало быть, те ситуации, которые по разному интерпретируют (a+b) и (b+a) должны идти в сад. Во избежание.
Сложение строк не коммутативно.
AT>Maxim S. Shatskih, мой respect.
О>Ну да, это я погорячился, прочитав предыдущие сообщения. Компилятор С++ вообще сложная >вещь, не все ОС могут себе позволить.
Да-да-да. gcc не везде портирован
>проходит так: сначала текст программы на ОНИКСе преобразуется
Из каких соображений придумывали ОНИКС? Есть ли там какая-то идея, вокруг которой язык придумывали? Или он придуман ради удовлетворения тщеславия кого-то шибко умного?
О>Не, не будет такого лет через 10-20 Легче создать программу, которая делает >работу за программиста (хотя это ещё вопрос), и, я думаю, это время не за горами.
10-15 лет назад говорили то же самое. Воз и ныне там.
NA>При грамотном проектировании на C++ кода будет меньше, чем на C. NA>Одна из хороших черт ООП: инкапсуляция. Если классы правильно NA>реализованы и документированы, то разобраться что делает код можно NA>быстрее, чем на C.
Угу. На Си делается то же самое, путем использования слова static перед именем функции.
Здравствуйте, Maxim S. Shatskih, Вы писали:
A>>А самое инетресное, что посмотрев исходники Вин2К пришел к выводу, что ядро не >>правилось этак с 96-го года... (ну ессесено драйвера правилились, но основные >>системы похоже что нет )
MSS>Просто сразу хорошо написали, и все.
MSS>От того, что туда напихают врапперов по WolfHoundу , оно лучше не станет.
За этим дело не встанет... на С уже никто не пишет (ну кроме некоторых) ... а когда надо будет ядро править, придется это на С++ делать .
Здравствуйте, VladD2, Вы писали:
MSS>>Да. А вон почитай, как тут человек признавался в романтической любви к Си++ именно потому, что там одно и то же можно выразить по-разному
VD>Дык то не романтик, то фанат.
А вот этого — не надо!
Нам, зверькам, фанатизм не к лицу — рАмантики мы
И ваще — еще раз на меня таким словом заругаешься — за нос укушу.
VD>Он просто еще не видел как можно писать програмы быстрее и проще чем текст в конфе...
Дык! Я ж о том и писал — что мне важно не быстро/безглючно писать код, а с удовольствием.
Когда я перестану получать удовольствие от "тупого" кодирования — перестану считать себя программистом и найду другое дело по душе.
(Предвидя толпу любителей фразы "мальчик, с такими понятиями денег не заработать", предупреждаю — зарабатываю. на хлеб с икрой — хватает.)
Здравствуйте, Shhady, Вы писали:
S>Я конечно не использую dynamic_cast, темплейтов и эксепшенов, и очень доволен, и использовать не хочеться.
И очень зря. Чертовски полезные вещи. Хотя исключения сделаны (особенно в компиляторах МС) не очень толково. Но уж шаблоны не использовать работая с КОМ-ом — это верх мазохизма. Все же ATL непропьеш.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Сами по себе обертки уже есть детали. Те самые. MSS>А если баг в обертке где? Ой млиииин...
Если баг в обертке, то рано или поздно он будет обнаружен и устранен. А вот если баги (а они будут такими же что и в обертке) разбросаны по коду, то это уже называется "приплыли".
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ну если совсем практика показывает, что постоянно хэндлы текут у данной конкретной команды — сделай так:
MSS>class CHandle MSS>{ MSS> HANDLE m_Handle; MSS> CHandle(HANDLE h){ m_Handle = h; } MSS> ~CHandle(){ ::CloseHandle(m_Handle); } MSS> operator HANDLE(){ return m_Handle; } MSS>};
Т.е. ты не совсем против враперов? Или у тебя свои понития об этом деле? Понятно.
Вот только как это соотвествует утверждению, что на С программа надежнее и недолжно быть невидимых эффектов?
MSS>- и юзай как хочешь. Полная прозрачность, как у смартпойнтера. Единственная разница — в месте объявления handle и вызове CreateFile.
С Апи-шными функциями есть одна проблема. Им в параметры можно подсунуть все что угодно. Они ведь в столь любимом тобой С-стиле объявлюятся (для совместимости). А С язык совсем ничего не знающий о типобезопасности. Сделать простую обертку над CreateFile заменив безликие константы на энумы и скрыв незначимые для прекладного программиста параметры ты повысишь надежность кода.
Вот только С++ сдесь тоже фиговый помошник. Уж больно вольно он относится к приведению типов. В шарпе, например, привести неявно энум к целому или наоборот невозможно. И с обертками особых проблем нет. Например для чтения текстовой информации изумительно подхтдит врапер вроде StreamReader. Зачастую код ограничивается вот таким вариантом:
Напиши аналогичный код на Апи без враперов и предложим сравнить другим какой код более понятен и читабелен.
В следующем фрэймворке вообще будет отдельная функция позволяющая считать содержимое файла без явного его открытия.
MSS>Мерзость врапперов в том, что они из всем известного системного API делают что-то хрен знает какое.
Есть и дугая теория. Враперы инкапсулируют логику и предоставляют более высокоуровневую абстракцию. Это позволят упростить написание, чтрение и поддержку кода.
MSS>В известных мне командах в Москве при виде враппера вокруг ReadFile подумали бы — "маньяааааак" — и точно на работу бы не взяли.
Ну, я знаю не мало контор которые не взяли бы человека на работу в следствии высказывания им одного из высказанных тобой утверждения. Что с того?
Ты постоянно себе противоречишь. С одной стороны ты вроде ратуешь за инкапсуляцию, полиморфизм. С другой низводишь базовые концепции ОО. Причем ради чего? Ради упрощения. Но каое же упрощение если вместо простой, лаконичной и понятной строчки унжно написать 10 перенапичканные ненужными деталями?
MSS>>>Смартпойнтеры — один разговор. Обертки — бредятина полная. Забивание мозгов лишней >>информацией. WH>>В чем разница? И те и другие созданы для того чтобы скрывать детали.
MSS>Враппер ничего не скрывает. Как была CreateFile, так и осталась.
Это в CHandle то? Он же нарушает главное (по-твоему) правило — делает невидимые действия. Ты же вроде обвинял в этом приведение типов и пергрузку операторов.
WH>>Вот только там надо не забыть закрыть фаил... А это геморой.
MSS>Правда что ли?
Если бы было не правдой, то на свете небыло бы столько глючных и текущих программ.
WH>>2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без >>произвольного доступа что есть маразм.
MSS>Правда что ли? а если это качаемый с HTTP поток? Сериализация из такого потока возможна? да. Ну и на кой требовать произвольный доступ для сериализации?
Вот тут согласен. Потоки разные важны, потоки разные важны.
>>виртуальный деструктор — это святое. WH>>Это догмы.
MSS>И? Ты же сам тут огласил другую догму, а именно "врапперы обязательны".
Опять согласен. Вот только какая разница от чего будет глючить приложение, от неверно вызванного деструктора, или от незакрытого файла?
MSS>Невиртуальный деструктор приводит к отвратительным гиморам, которые очень сложно потом ловить. Есть рекомендация автора языка — везде, где есть вообще VMT, делать виртуальный деструктор. Разумная и обоснованная.
Этим авторам бы пошее дать. И объяснить, что если это так важно, то нужно было вводть не разрешительную, а запретильную политику. Ну, чтобы программист сам и явно говорил "не нужен мне ваш виртуальный деструктор". Тогда таких багов было бы минимум.
MSS>Какие детали прячет обертка вокруг WriteFile?
Ну, не тебе рассказывать сколько у нее параметров насколько неприятно их путать. Это тебе может ясно что такое разные OVERLAPPED и т.п. А прикладнику все это до лампочки ему нужно файл на диск сбросить. К тому же WriteFile довольно простой метод. А вон с CreateFile будет посложнее. К тому же не каждый знает что для открытия вайлва нужно вызывать именно ее, а не OpenFile. Ну, а если учесть, что человек не помешанный на битах читает из файла структурированные данные, то понятно, что обертка может очень сильно облегчить ему жизнь предоставив методы форматированного чтения и записи (а то и обеспечить контроль).
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
VD>>>Раз формат %u значит к unsigneg int.
Ш>>С возможной потерей значения?
VD>Ну, тут оно как. В большинстве случаев это невероятно. Если вероятность все же есть, то преобразуй к заведому большому типу и выводи его.
Какому? Это зависит от системы. Нет в С способа использовать printf системно-независимым способом. Сейчас Майкрософт вводит Win64. В этой системе size_t -- 64 разрядный. Он будет больше long.
Т.е. его вообще невозможно распечатать используя стандартные коды форматирования. Соответсвенно, весь C-шный код, написанный для Win32, надо тюнить под новую систему просто ручками переписывая все строки форматов. И при этом новый код будет Win64-only. Абзац. И кто-то после этого тут ещё заливает насчет сложностей с переносимостью и сопровождением C++ кода. С порождает куда большие проблемы.
VD>Ну, а то что в С/С++ функции с переменным количеством параметром полное дермо никто и не спорит.
Если ты имеешь ввиду ..., то да. Единственное полезное использование -- только в мета-программировании.
Здравствуйте, Shhady, Вы писали:
S>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar?
Нигде эта функция не зарыта. Ее вообще нет . MFC не рисует скролбары — их рисует винда.
S> Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?
Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары которые есть у каждого окна — то тут немного нужно поплясять с бубном. Но к MFC это никакого отношения не имеет
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Exhumer, Вы писали:
E>>P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.
VD>Можно узнать чем ООП может помешать драйверам?
Только тем, что половина драйверистов — едва услышав о такой идее закатывают глаза и начинают выть про "святотатство"... В подобных условиях не возможно работать...
А если серьёзно — то C++ прекрасно можно использовать для драйверов. Главное при написании драйверов это смотреть — какие средства языка используются и каковы будут затраты ресурсов при их использовании. Например exceptions в драйверах явно не стоит использовать.
S>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar? Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?
Еще раз:
1. Есть фича WIndows-а, именно Windows-а, как операционной системы, что стандартные контролы обрабатываются напрямую.
2. MFC предоставляет тонкие обертки над WinApi, т.е. получается, что MFC не перекрывает это поведение.
3. Вы не разобравшись, как устроены стандартные контролы, наступили на эти грабли
4. Вы в этих граблях обвинили MFC, и перестали использовать MFC.
Внимание, вопрос:
Можно ли в данном случае говорить о каком-либо профессионализме, или мы имеем дело с человеком, который плохо разбирается в той области, в которой работает?
Так маразм-то — спецификация throw(). Кому она нужна-то? излишество, загромождающее код, и одна из самых бесящих вещей в Джаве, где она обязательна, в отличие от Си++.
Кто-нить реально пользуется этой фичей Си++?
И каким боком из деструктора делается то, что может возбудить ситуацию? Там что, делается то, что может обломиться? Сразу откровенный маразм.
MSS>>То-то ядра Windows и юниксов работают хорошо, то-то компиляторы работают хорошо... >все на Си Д>то-то мне сразу вспоминаются MS-Blast и компиляторы, которые при любом шаге в сторону >сыплют internal compiler error
Да прям при любом шаге пятерка была неудачная версия, в шестерке я не чаще раза в год такое вижу. В том компиляторе, что с XP DDK дают — тоже.
Насчет MSBlaster — ну ОК, перейди на юниксы, которые якобы более надежны — там тоже большая часть софта на Си написана.
Я бы это назвал "лохописный код". при таком лоховстве Си++ лучше в руки не давать — они там понаворотят...
Уже сам факт вызова fopen из-под лока — смахивает на лоховство, я про не-отдачу лока даже не говорю.
AF> Ну да, править тут ошибку — очень легко, но зачем?
Затем, что если этот файл не найдется, или если с него права на чтение убрать — то система дедлокнется. Классический DOS attack.
DG>Потому что как раз в этом случае появляется очень много неявных зависимостей DG>0. В какой системе запущена программа
Краткий ответ на все претензии.
Приведенное решение непортабельно между юниксами, а то и между разными дистрами Линукса. Это делают только в решениях конкретному клиенту, где есть договоренность о том, что за юникс у него будет стоять, какой версии, и вдобавок как настроен. Большинство таких решения рассыпаются, если что-то подкрутить в настройках ОС.
MSS>Я бы это назвал "лохописный код". при таком лоховстве Си++ лучше в руки не давать — они там понаворотят...
MSS>Уже сам факт вызова fopen из-под лока — смахивает на лоховство, я про не-отдачу лока даже не говорю.
С лохописностью кода — абсолютно согласен. Я его как раз из-за этого и привел. Однако замечу, что для народа, который пишет такой код классы — обёртки решают половину проблем — вроде банального лока. Вторую половину — для которой нужна голова тут конечно уже не решить...
А С++ выдавать народу можно — они не то что оператор или шаблон, класс толком не напишут. Так что это не страшнее, чем C.
AF>> Ну да, править тут ошибку — очень легко, но зачем?
MSS>Затем, что если этот файл не найдется, или если с него права на чтение убрать — то система дедлокнется. Классический DOS attack.
Ты не понял суть. Почему нужно освобождать лок — я догадываюсь, но вот зачем давать возможность вообще совершить ТАКУЮ ошибку — и тратить время на её исправление, когда подобные ошибки лечатся элементарными обёртками? Думаешь народ не наделает ошибок и без забытых локов? Наделают — причём ошибки будут глубже. Потому лучше иметь среду — в которой можно будет тратить время на правку действительно существенных — смысловых ошибок. В противном случае есть риск, что после того, как ты подправишь закрытие всех хендлов и отпускание всех локов (а заодно и их установку) в "лохописном коде", частенько выясняется, что ошибка глубже — и этот код надо вообще было переписать...
AF> А С++ выдавать народу можно — они не то что оператор или шаблон, класс толком не >напишут. Так что это не страшнее, чем C.
Классы таким людям давать писать нельзя им можно только давать юзать чужие
AF>Ты не понял суть. Почему нужно освобождать лок — я догадываюсь, но вот зачем давать >возможность вообще совершить ТАКУЮ ошибку
Если таких людей в команде иметь — то да, возможно.
>ошибки будут глубже. Потому лучше иметь среду — в которой можно будет тратить время на >правку действительно существенных — смысловых ошибок.
Да нет. Как показывает практика — самый мощный источник багов — опечатки. Типа перепутать Src и Dst. Или ++ забыть где-нить. От такого никакие обертки не спасут.
>выясняется, что ошибка глубже — и этот код надо вообще было переписать...
Редко такое бывает. Ну что такое "смысловая ошибка"? Финансовая система неправильно деньги считает? ОК. Решается как правило переписыванием одного SQLного запроса.
По заворачиванию DeviceIoControl в класс претензий, я смотрю, нет?
Вот и хорошо.
MSS>А обломится аллокация — что делать бум? Только не надо мне рассказывать про Си++ exceptions в ядре, да еще и на DISPATCH_LEVEL.
1). Почему бы и нет?
2). Если так не любишь исключения — исправь код следующим образом:
Здравствуйте, Maxim S. Shatskih, Вы писали:
AF>> А С++ выдавать народу можно — они не то что оператор или шаблон, класс толком не >>напишут. Так что это не страшнее, чем C.
MSS>Классы таким людям давать писать нельзя им можно только давать юзать чужие
AF>>Ты не понял суть. Почему нужно освобождать лок — я догадываюсь, но вот зачем давать >>возможность вообще совершить ТАКУЮ ошибку
MSS>Если таких людей в команде иметь — то да, возможно.
>>ошибки будут глубже. Потому лучше иметь среду — в которой можно будет тратить время на >>правку действительно существенных — смысловых ошибок.
MSS>Да нет. Как показывает практика — самый мощный источник багов — опечатки. Типа перепутать Src и Dst. Или ++ забыть где-нить. От такого никакие обертки не спасут.
Ну ка, перепутай. Компилятор матом не заругается? Надо ли напоминать, что в C++ грамотное использование модификатора const избавляет от очень многих ошибок подобного сорта.
>>выясняется, что ошибка глубже — и этот код надо вообще было переписать...
MSS>Редко такое бывает. Ну что такое "смысловая ошибка"? Финансовая система неправильно деньги считает? ОК. Решается как правило переписыванием одного SQLного запроса.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Чем он лучше? FILE и fopen просто синтаксически красивее, чем эта бредятина с кучей ::. WH>Ты хотел сказать привычнее.
И лаконичнее. Что немаловажно. Кроме того нонешние компиляторы проверяют соответствие списка параметров форматной строке.
Здравствуйте, postmaster, Вы писали:
P>Результат: P>1). Тим из 5-ти человек, состоящий только из 1-ой категории программистов. Стоимость разработки продукта — 15000 USD. P>2). Тим из 5-ти человек, один из 1-ой категории, четверо из 2-ой категории. Стоимость разработки продукта при сопоставимом качестве — 7000 USD.
P>Теперь первый и второй продукт начинают конкурировать. P>Дальше рассказывать?
Это если продцкт за 15k будет написан. А то как бы не получилось в известной басне "Лебедь, Рак и Щука".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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 (хотя это было всегда со мной хотя бы в качестве халтурок).
Так что дело вовсе не в ретроградстве и "распальцовке" . И всякая хорошо сделанная работа (на любом языке программирования) достойна уважения.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Полностью согласен. Если сделать окна с Non-client area как отдельные — контейнеры для окон представлений, то логика работы с окнами упростилась бы на порядок и код писать стало бы гораздо легче. Но об этом в своё время не думали...
Но одного они добились. В NC отваживаются вмешиваться только очень смелые индейцы. Это позволяет МС менять NC в каждой версии ОС.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вывод: нефиг трогать MFC, не зная USERа. Всегда надо знать детали того, с чем работаешь, иначе будешь в глупые положения попадать.
Ну, так уж и всегда. Знать конечно полезно. Но не обязательно. Просто уж если не знаешь, то понты лучше не кидать.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
MSS>>Абстракции там получаются очень крупноблочные, скорее как в COMе, а не как в классических ОО языках типа Дельфей, Джавы и Шарпа.
AVK>Компонентная модель дотнета в разы более абстрактна нежели СОМ
А что такое компонентная модель КОМ?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, bwowa, Вы писали:
B>Мужики, так вы вообще противники исключений!
Мы сторонники правильных исключенией. А ISupportErrorInfo — это не исключения, это слёзы. Единственно, кто их умеет нормально эмулировать как C++ исключения — это #import.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Мы сторонники правильных исключенией. А ISupportErrorInfo — это не исключения, это слёзы. Единственно, кто их умеет нормально эмулировать как C++ исключения — это #import.
(сторонникам *NIX не читать!)
Зря вы так про ISupportErrorInfo, очень даже мощный подход. Хочешь бери GUID в качестве ошибки, хочешь — читай COM объект дла расширенной информации. Да к тому же это ещё и независимый от языка подход.
Правльное исключение выглядит так: (ну на фига нам всякие COM )
К стати это реальный код, одной из моих программ.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не полностью. Если вспомнить про индигу то ...
Ну, я как бы тут поглядел презенташки про ее. Мне кажется очень даже красивая штука получается. Как раз то что про нее бредит коробкин даже хуже того что будет на самом деле. Просто он слишком долго пролежал в мыльной ванне.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexkro, Вы писали:
A>Наверняка испытывал, только не задумывался над этим. Вот типичный код, в котором требуется невыбрасывающая операция: A>
A>void Update( ref SomeObject obj )
A>{
A> // create a copy
A> SomeObject copy = obj.Clone();
A> // update copy (connect to DB, etc), may throw
A> ...
A> // commit with non-throwing ops
A> obj = copy;
A>}
A>
Честно говоря по твоему коду этого не видно, а try .. finally в дотнете никто не отменял.
Здравствуйте, desperado_gmbh, Вы писали:
_>Вообще да, 0, наверное, сишная привычка — для указателей я уже привык использовать null. Кстати, default в Whidbey — это именно то,
Гы уже не default, а default(...). Они переделали его во встроенную функцию. Вроде sizeof() в С.
_>хотя и сделан для других целей.
Как раз именно для этих.
_> Жаль, уже поздно — есть много кода с нулем и ломать его, запрещая преобразование нуля в enum, не захотят.
Почему поздно? Именно под таким соусом и гробится С++. Мол поздно... совместимость...
_>Enums часто напрямую соответствуют параметрам API-функций, и нужна бинарная совместимость значений флагов.
Полная фигня. Энумы никак (семантически) не соотвествуют С-шным. В С энумы ни чем от констант не отличаются. Тут же это разумный тип.
Кстати, можно было бы и наследование для энумов ввести. Чтобы константы можно было выделять в подтипы...
_> Кроме того, бывают хитрые случаи, когда часть битов — флаговая, а часть — число, например, System.Drawing.Drawing2D.PathPointType.
Это все флаговое... просто есть маски. Не более того. К нулю это отношения не имеет. Ноль — это ошибка разработчиков языка. Разумно ее обяснить нельзя.
_> Естественно, это можно считать плохим дизайном, но при попытке сделать по-другому обертки над такими API-функциями усложняются и замедляются, почти не выигрывая в удобстве.
Ничего не усложняется. Разделять понятие флаков и обычных энумов. Ввести предопределенное значение None. И вск будет ОК. А еще лучше ввести set-ы как в Дельфи.
Для бинарной же совместимости есть интероп. Вот пусть он все несоотвествия и решает. А язык поганить по этому поводу смысла не было.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexkro, Вы писали:
A>Аппаратный сбой не является исключением C++.
Но ловится try-ем С++. Некоторая неувязочка.
A>Деление на ноль не является исключением C++. Я уж не говорю про то, что код можно гораздо более надёжно писать.
Куда уж надеженее? Надежность и С++ бизницы браться. Прям как Иванов, Петров и сидоров.
VD>>Скорее вредная. Я как-то ни разу на практике необходимости в этом не испытал.
A>Наверняка испытывал, только не задумывался над этим.
Не испытывал и задумывался... Глядя на извращения явы...
A> Вот типичный код, в котором требуется невыбрасывающая операция:
Нечиво тут не трубуется. И вообще описывать то что не требуется натуральный маразм. Эдак можн описать что для этого кода бензина не требуется.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, anidal, Вы писали:
A>Ошибочно мнение, что ООП можно заниматься только на языках, в которых есть поддержка ООП. Это не так. A>На Си тоже прекрасно получаются абстракции, наследование, полиморфизм и пр. НО! чтобы сделать A>это надо маленько подумать и написать несколько больше букв (размер кода не больше, чем генерит компилятор, поддерживающий ООП),
ИМХО, прекрасно как раз и не получится. Реализовать можно и на асме — для этого надо всего лишь подумать и написать несколько больше букв. Только кому это надо?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, anidal, Вы писали:
A>>Ошибочно мнение, что ООП можно заниматься только на языках, в которых есть поддержка ООП. Это не так. A>>На Си тоже прекрасно получаются абстракции, наследование, полиморфизм и пр. НО! чтобы сделать A>>это надо маленько подумать и написать несколько больше букв (размер кода не больше, чем генерит компилятор, поддерживающий ООП),
AJD>ИМХО, прекрасно как раз и не получится. Реализовать можно и на асме — для этого надо всего лишь подумать и написать несколько больше букв. Только кому это надо?
Я не призываю писать абстакции на С и тем более ассемблере, но когда для написания абстракции надо приложить усилия, пусть и небольшие,
сто раз подумаешь, а надо ли это и программ типа Hello world с десятком классов не будет.
MSS>>Ко мне этот текст попал в конце 91го года. Он довольно >старый, и старше, чем релиз .NET. BK>в 91-м году ни Жабы, ни тем более C# не было вроде...
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Так что язык программирования здесь абсолютно не причем. Чем мощнее и гибче язык, тем >>большая квалификация нужна для работы с ним. И наоборот. Да здравствует VB! :)
MSS>Речь не об этом. А о том, что есть фичи Си++, которые не приносят никакой пользы, и приносят при этом вред. Шизанутый язык это (особенно последние новшества, которые грубо противоречат тому, что подавалось как основы языка), и восторгов совершенно не заслуживает. Вот и все.
Например? Только фичи языка, а не STL, etc.
MSS>Практическое использование Си++ нередко требует разработки внутрифирменного документа о том, какие фичи _запрещено_ использовать. Просто чтоб код нечитаемый не вышел, и чтоб не было нужды в рефакторинге :)
Ну вот я пишу под ACAD. И кое-что нельзя использовать. Например dynamic_cast. И ничего.
MSS>Про ОО и рефакторинг — честно говоря, то же самое. Вот я задал вопрос, что такое "завистливые функиии". Мне ответили. Из ответа понятно, что в Си такое явление невозможно в принципе.
Так, а что такое "завистливые функиии"?
MSS>Похоже, что сначала придумали ОО и Си++ — то есть "как сделать то же самое, но через зад, с кучей лишнего и в шизанутом синтаксисе" — а тут же возникла нужда в рефакторинге. Энтропии в ОО языках больше, чем в Си.
Читайте Буча, первое издание. Там примеры были на Smalltalk. Про энтропию — опять же квалификация программистов.
MSS>Еще пример. Программа на Си читается безо всякой browse info, с использованием одного лишь grep, чтобы найти, где объявлена функция. На Си++ с этим туго. Там BSCMAKE нужен. А зачем? Плюсы-то какие?
С C++ вообще в командной строке тяжело работать. Но в оболочке — не вызывает никаких затруднений. Особенно если VC + VisualAssist. Удобство работы на порядок улучшается.
MSS>Очень мало мест, где ОО бесспорно есть хорошо.
Ну это типичное мнение linux-оидов. Частично как следствие инертности мышления.
Здравствуйте, Maxim S. Shatskih, Вы писали: MSS>Практическое использование Си++ нередко требует разработки внутрифирменного документа о том, какие фичи _запрещено_ использовать. Просто чтоб код нечитаемый не вышел, и чтоб не было нужды в рефакторинге
Всегда требуется , так как сколько людей столько и мнений . коллективная разработка каждый сам по себе ??? — дерзай . С++ тут не причем .
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Про ОО и рефакторинг — честно говоря, то же самое. Вот я задал вопрос, что такое "завистливые функиии". Мне ответили. Из ответа понятно, что в Си такое явление невозможно в принципе.
угу. потому что там классов вообще нет
отличчный аргумент, не поспоришь
Да, со студентами проблем много, чаще всего всё заканчиваеться переписыванием их кода.
Это как начинающий водитель и проффесиональный гонщик — если перед ними поставить 2 машины: болид формулы 1(18 скоростей) и чтто нибудь отечественное, то, думаю, не надо особой фантазии чтобы представить последсвия, а также переимущества и недостатки возможных комбинаций.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Нижеследующий текст написан нашим соотечественником, работающим в микрософтовской команде компиляторов.
MSS>Ко мне этот текст попал в конце 91го года. Он довольно старый, и старше, чем релиз .NET.
MSS>Предлагаю обсудить.
MSS>----------------------------------------------------------------------------------------
MSS>>Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой >видимой подсказки. Д>const надо писать, вот что я могу сказать. посмотрел заголовок функции — и стало всё >понятно
В том-то и фишка, что надо ЗАГОЛОВОК смотреть. В случае f(&obj) — все видно в месте вызова, без заголовка.
Д>а ты уверен, что CMyClass* это именно подсказка о том, что параметр изменяется внутри?
Как говорится, лучше перебдеть, чем недобдеть.
Д>мне даже страшно представить себе имена в стиле >SystemRuntimeRemotingChannelsTcpTcpChannel
RpcChannelIsTcp — пойдет? такой функции нет, но могла бы и быть.
>модулей, на которые разделены функции. Вероятно, в случае написания драйверов, когда >достаточно использовать крайне маленькое подмножество функций, это прокатит.
Порядка 1100 функций. Это маленькое подмножество???
Д>Это значит "сложение"! (чтобы понять, совсем не нужно даже иметь высшее >образование ) Д>А уж как и где оно делается, это уже дело десятое.
Да правда что ли? То есть, что тут автор кода имел в виду под сложением (а прийти в безумную голову может все, что угодно, например, << для печати) — это неважно?
Д>тем, что он нестандартный. И тем, что он макрос
Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
MSS>> Творческое пользование темплейтами также сможет доставить потомкам MSS>> немало приятных минут. S>Бывает. Но если нет шаблонов, то вместо них на помощь приходят макросы... А S>это вообще жопа.
Темплейты как раз хорошая фича. Одна из лучших в Си++.
MSS>> Вышли из блока -- значит, вышли, и нечего кроме. S>И забыли закрыть половину хэндлов....
Сразу видно. Локально видно. Легко править.
MSS>> Очевидно, что чем проще язык программирования, тем трудней сделать на MSS>> нем семантическую ошибку. S>Если б это было правдой, все бы до сих пор писали на ассемблере.
Ассемблер сложнее Си.
Си — оптимальный язык для близкого к машине программирования. Позволяет все, что и ассемблер (ай, ну да, кроме CPUID — и при этом не содержит скрытой семантики.
Прятать мелочи — глупо. Баги будут именно в них. The devil is in the details. Потому имеет смысл выставить эти детали бесстыдно наружу, чтобы быстрее баг увидеть, если он там есть.
Д>>Это значит "сложение"! (чтобы понять, совсем не нужно даже иметь высшее >>образование ) Д>>А уж как и где оно делается, это уже дело десятое.
MSS>Да правда что ли?
Конечно. Такие вещи позволяют разбираться в сути программы, не отвлекаясь на мелочи (конкретную реализацию сложения). Читая текст программы и зная, какие объекты складываются, в первом приближении ты можешь догадаться что для них означает сложение (например, для строк — слияние). Если же для этого будет использована функция, то нужно будет лезть в нее чтобы понять что она делает.
Разумеется, если operator+ выполняет действия, не имеющие ничего общего со сложением, то с таким программистом надо разбираться в другом месте. Но ведь и для функции можно выбрать имя, не имеющее ничего общего с ее работой!
Здравствуйте, Maxim S. Shatskih, Вы писали:
G>>Да чушь полная. ООП — это такой же инструмент как и любой другой. Все зависит от того >>кто как этим инструментом пользуется. Если руки из жопы растут, то хоть ооп, хоть >>процедурное программирование — один хрен будет куча ошибок и проблем. Вопрос не в >>инструменте а в квалификации товарищей, которые его пользуют.
MSS>Типичное возражение, и совершенно неверное.
Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью технических средств. А Globus совершенно прав.
MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.
MSS>Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.
Я никогда файлы не листаю. Для чего class view имеется?! Файлы листать — последнее дело.
P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.
E>Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью >технических средств.
Совершенно верно! Только почему это плохо?
Фирма Макдоннел-Дуглас сильно гордилась тем, что уменьшила на F-15 число приборов на доске до 30, вместо 48 у "Фантома". Ну наверное, не зря гордилась, правда?
А ведь могли бы сказать — "настоящий летчик и 48 приборов осилит"...
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось >>бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть >>изменен в результате вызова. E>>Надо использовать модификатор const. И тогда все намного будет проще.
MSS>Ничего не будет проще. Останется f(obj), а за словом const лезть в заголовок. Намного лучше использовать CObject*, чем const CObject&
ЧЕМ??? f( const CObject * ) — это лучше (нагляднее) чем f( const CObject & )???
E>>Все от программиста зависит. Если в одном фале ипользуются разные namespace, то и >>пользоватся using надо аккуратнее.
MSS>Дело в том, что подавляющее большинство программистов злоупотребят этим. У многих менталитет на уровне "есть фича, надо пользоваться" :). Дай такому в руки Си++ — получишь write-only language.
Опять же человеческий фактор.
E>>А реализация "+" может быть разная у разных объектов. Никак не звязанная с >>арифметическим сложением. Ты об этом не задумывался?
MSS>Я именно об этом, и именно это и есть бред. Лучше уж тогда метод Add. Скажем:
А кто мешает тогда сделать метод Add, который будет реализовывать арифметическое вычитание?
MSS> container.Insert(obj); MSS>лучше, чем MSS> container += obj;
ЧЕМ???
E>>А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных >>ситуациях.
MSS>Например?
Например когда у тебя нет class view (а-у, командная строка). И листая файл ты не занешь, что это за переменная. По префиксу можно понять, примерно, что это такое.
E>>Реализация RTII в MFC не самый удачный пример. Явно хуже чем RTTI в C++. Хотя бы тем >>что обязывает наследовать от CObject.
MSS>А чем это плохо-то? RTTI нужна на крайне небольшом количестве классов (на CString она не нужна, например), и обязать все такие классы наследоваться от одного корня — что плохого?
А если мне совершенно нельзя наследовать от CObject? В Acad-е для custom objects именно так.
>>E>"Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения" >>(C) — не помню кто.
MSS>Keep it simple and stupid. Принцип такой в инженерии. Почти в любой. Усложнения делаются только тогда, когда иначе НИКАК.
Именно.
E>>Переведи понятие "цена печати кода".
MSS>Количество нажатий на клавиши, нужное для набора кода. Фичи Си++ — тот же класс строки — полезны практически только в этом.
Хм. Какой-то странный подход к оценке труда программиста. Образца 60-х годов прошлого века.
А в C++ нет класа строки. Только в библиотеках (MFC и STL). Учите мат. часть.
MSS>>>Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид :) E>>Так я о мышлении.
MSS>Ну тут, наверное, да. Я скорее буду заодно с линуксоидами, чем с маньяками "серьезного проектирования".
MSS>И самый прикол, что эти маньяки почему-то все больше выше бухгалтерий не поднимаются...
Так все прикладные програмисты работают на конечного пользователя. И только системные непонятно на кого (вспомним как любимый принтер не печатал после установки новой версии драйверов видеокарты). Без обид, Ok?
E>>А так вот ты о чем! Ну так маленькие задачи и ОО там не нужен. И не спорю. Не понимаю >>как это соотносится с темой: "C++ и большие проекты".
MSS>Тема была — Си++ и серьезный код. Очевидно, что кернел модуль в любой ОС — более серьезный код, чем, например, абсолютно любой UI.
А пользователю все равно, будет ли рабочим ядро, если висит UI.
По причине серъезных и непреодолимых разногласий предлагаю закончить
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Я именно об этом, и именно это и есть бред. Лучше уж тогда метод Add. Скажем:
MSS> container.Insert(obj);
MSS>лучше, чем
MSS> container += obj;
Полностью согласен. Но сдругой стороны Point p = a + b; гораздо лучше чем point_add(&p,&a,&b).
Все должно быть на своих местах. Если человек ставит сапоги в холодильник, то кто в этом виноват? Сапоги или холодиоьник?
E>>А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных >>ситуациях.
MSS>А чем это плохо-то? RTTI нужна на крайне небольшом количестве классов (на CString она не нужна, например), и обязать все такие классы наследоваться от одного корня — что плохого?
Действително не полохо. Многие так и делают.
MSS>Тема была — Си++ и серьезный код. Очевидно, что кернел модуль в любой ОС — более серьезный код, чем, например, абсолютно любой UI.
Вот к примеру ядро ос на С++: http://l4ka.org/projects/pistachio/
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>В том-то и фишка, что надо ЗАГОЛОВОК смотреть. В случае f(&obj) — все видно в месте вызова, без заголовка.
ничего не понятно — см ниже
MSS>Как говорится, лучше перебдеть, чем недобдеть.
если отказаться от ссылок, то любому хорошему програмеру придется передавать указателем ВСЕ объекты. Чтобы избежать ненужных накладных расходов. И что, тебе от этого легче станет?
MSS>RpcChannelIsTcp — пойдет? такой функции нет, но могла бы и быть.
пойдет. Когда функций мало.
MSS>Порядка 1100 функций. Это маленькое подмножество???
я бы сказал, очень маленькое. Если взять в качестве примера FCL, то мне даже подумать страшно, сколько там всего функций (точнее, методов). На порядок больше — это точно.
MSS>Да правда что ли? То есть, что тут автор кода имел в виду под сложением (а прийти в безумную голову может все, что угодно, например, << для печати) — это неважно?
повежливее, пожалуйста.
В безумную голову может прийти мысль назвать функцию print_file, а на самом деле этот файл удалять. И что, есть какая-то разница?
MSS>Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Тем, что они ничего "не знают" о языке как таковом. Это — просто инструмент для обработки текстов, и последствия его применения могут быть непредсказуемыми даже для автора макроса. Ну а для кого-то постороннего это может стать засадой много хуже перегруженных методов и шаблонов, кстати говоря.
Здравствуйте, Дарней, Вы писали:
MSS>>Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Д>Тем, что они ничего "не знают" о языке как таковом. Это — просто инструмент для обработки текстов, и последствия его применения могут быть непредсказуемыми даже для автора макроса. Ну а для кого-то постороннего это может стать засадой много хуже перегруженных методов и шаблонов, кстати говоря.
Кстати, никто не знает тайную причину того, что в С/С++ так популярны макросы? Во многих других языках их вообще ведь нет. И даже как-то не хочется!
Здравствуйте, Serginio1, Вы писали:
V>>А если всё это реализовывать чисто на С, то результат мог бы получиться ещё более плачевным: программа, скомпилированная самым супероптимизирующим компилятором, вполне может оказаться тормознутее, чем то же самое, исполняемое интерпретатором 1С.
S> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
Ага, но при этом легко получить вариант a la Navision.
S>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
V>Ага, но при этом легко получить вариант a la Navision.
Хехе. А ведь РСДН-то Навизионцы читают )
I'm the hero I'm back
With weapons and with magic spells
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, Crab, Вы писали:
S>>>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
V>>>Ага, но при этом легко получить вариант a la Navision.
C>>Хехе. А ведь РСДН-то Навизионцы читают )
V>Ну и что? Думаете, они сами редко делают вот так: [ ]?
Я пишу доработки под Navision Axapta. Так никогда не делал.
Мне кажется, там все сделано очень хорошо. А что Вам не нравится?
Здается мне, что это "эссе" написано не сотрудником МС, а кем-то кому охота пофлэймить.
Грабли — это конечно не хорошо. Но голопом на С — это просто бред сивой кобыли.
И текст этот у тебя в 91 быть не мог. Тогда ни Шарпа, ни Явы еще в помине небыло. Да и С++ то был на С++ не похож. Шаблонов еще небыло, к примеру. А в тексте про это упоминается.
ЗЫ
Ты этот текст не сам часом написал?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Chris, Вы писали:
V>>Ну и что? Думаете, они сами редко делают вот так: [ ]?
C>Я пишу доработки под Navision Axapta. Так никогда не делал. C>Мне кажется, там все сделано очень хорошо. А что Вам не нравится?
Ахарта, конечно, покрасивше будет. Насчёт "очень хорошо" — спорить не буду. Скажу только, что мне она не очень понравилась по совокупности параметров, хотя некоторые заложенные в неё идеи просто восхитительны. Предлагается закруглить перемывание косточек MBS.
Тема-то была про другое. Navision просто под руку попался как иллюстрация неоднозначной зависимости скорости выполнения программ от скорострельности интерпретатора.
Здравствуйте, Voblin, Вы писали:
V>Кстати, никто не знает тайную причину того, что в С/С++ так популярны макросы? Во многих других языках их вообще ведь нет. И даже как-то не хочется!
Трудно сказать... я стараюсь без них но иногда особенно при написании какой либо библиотеки они бывают очень полезны.
На пример посмоти реализацию boost::function фаил function_template.hpp и попробуй представить его без макросов из библиотеки boost::preprocessor...
Если не можешь то посмотри на boost::signals.
А теперь попробуй представить их вобще без макросов...
Если не можешь то тебе прямая дорога в Loki фаил Functor.h и учти что по функциональности и качеству реализации Liki::Functor близко не валялся с boost::function...
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Voblin, Вы писали:
V>Ага, но при этом легко получить вариант a la Navision.
Дык, создай/купи/укради нормальную библиотеку предоставляющую примитивы предметной области и все будет ОК. Ну, и сам, как прикладник, не забывай про такие вещи как инкапсуляция.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Уважаемый автор!
Вы читали книгу Страуструпа "Дизайн и эволюция Си++"?
Если нет — рекомендую настоятельно ее почитать.
Там написано как, зачем и почему он сделан таким, какой есть.
Совершенно согласен с Globus.
Здравствуйте, WolfHound, Вы писали:
WH>Трудно сказать... я стараюсь без них но иногда особенно при написании какой либо библиотеки они бывают очень полезны. WH>На пример посмоти реализацию boost::function фаил function_template.hpp и попробуй представить его без макросов из библиотеки boost::preprocessor... WH>Если не можешь то посмотри на boost::signals. WH>А теперь попробуй представить их вобще без макросов... WH>Если не можешь то тебе прямая дорога в Loki фаил Functor.h и учти что по функциональности и качеству реализации Liki::Functor близко не валялся с boost::function...
И почему в Шарпе есть все тоже самое, но без макросов?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, achp, Вы писали:
A>Может, здесь просто ачипятка и имеется в виду 2001 год?
Може, то выглядет смешно. Кстати, в 2001 это тоже вряд ли могло быть написано. Дотнет официально вышел в 2002-ом и трепаться о Шарпе в таком стле разумный человек работающий на МС не стал бы.
Сдается мне, что сей труд написан на днях.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>А теперь посмотри на амереканцев... жрут в МакДональдсе и выглядят как... ну вы поняли... Короче я считаю что МакДональдс гораздо опаснее чем БенЛаден и компания... В отличии от террористов МакДональдс убивает милионами причем с особой жестокостью и цинизмом.
Не, а мне нравится макдонадльдс. Я им не злоупотребляю. А когда нужно в попыхах перекусить, то это лучше бем пирожок неизвестного качества или наши забегаловки.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Voblin, Вы писали:
V>Кстати, никто не знает тайную причину того, что в С/С++ так популярны макросы? Во многих других языках их вообще ведь нет. И даже как-то не хочется!
Тайного тут ничего нет. Многие проблемы в С++ решаются крайне криво. И макросы позволяют скрыть эту кривоту.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Ко мне этот текст попал в конце 91го года. Он довольно >>старый, и старше, чем релиз .NET. BK>>в 91-м году ни Жабы, ни тем более C# не было вроде...
MSS>Пардон, 2001, конечно. Запутался
Ты будешь смеяться, но в 2001 Шарпа тоже небыло. Он появился в 2002.
Но спор твой как раз из того самого 91-вого. Я бы это назвал синдромом Рыбинкина. Залезь на IXBT и поищи на эту фамилию. Думаю, неделя увлекательного чтива тебе обеспечена.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, bwowa, Вы писали:
B>Это как начинающий водитель и проффесиональный гонщик — если перед ними поставить 2 машины: болид формулы 1(18 скоростей) и чтто нибудь отечественное, то, думаю, не надо особой фантазии чтобы представить последсвия, а также переимущества и недостатки возможных комбинаций.
[offtopic]
На болиде Ф1 обычно 6-7 скоростей. На моём велосипеде 24!
[/offtopic]
А по-хорошему перед тем, как садиться в болид Ф1, надо потренироваться в картинге, с чего и начинал Шумахер (чтоб он наконец-то проиграл хоть этот чемпионат ). Вроде такого: Бейсик -> Паскаль -> С++. А мне сейчас, параллельно с проектом на С++, приходится лабать испытательные программы на языке ОНИКС (Орентированный на Наземные Испытания Космичесих Систем). В нём нет объектов, с этим я ещё согласен мириться. Но в нём ещё нельзя объявлять глобальные переменные, многомерные массивы, указатели, нет даже структур, и нет макросов, чтобы хоть как-то сымитировать некоторые из этих вещей (зато есть потоки). После С++ с STL очень тяжко. Размер программ получается раза в 2-10 больше, чем аналогичных на С++. Не обижайте С++!!! А С давно пора выкинуть в помойку как мелкое подмножество С++, по моему скромному мнению.
E>P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.
Эксхумер, вы не правы. Для драйверов С++ очень даже самое полезное средство. Тем более, что современный компилятор (MSVC или Intel) сделает из С++ такой же качественный код как из С. Чего только стоят С++ классы от Intel для простой и удобной работы с MMX, SIMD1 и SIMD2 без знания асемблера. Впрочем для С у Intel тоже есть аналогичные библиотеки.
Прошу прощения у поклонников *nix, их любимые компиляторы не тестировал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, achp, Вы писали:
A>>Может, здесь просто ачипятка и имеется в виду 2001 год?
VD>Може, то выглядет смешно. Кстати, в 2001 это тоже вряд ли могло быть написано. Дотнет официально вышел в 2002-ом и трепаться о Шарпе в таком стле разумный человек работающий на МС не стал бы.
VD>Сдается мне, что сей труд написан на днях.
Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где-то назад на редмондовском
форуме разработчиков драйверов (в частности в нем участвуют многие ключевые разработчики NT).
Высокая стоимость сопровождения кода C++ и вред скрытой семантики — факт. С тоже не лишен недостатков.
Но главным критерием на мой взгляд является уместность употребления языка в конкретном культурном контексте и традиции.
Хорошо то, что принимается сообществом (или большей/авторитетной частью с возможными исключениями) и соответствует большинству доступных материалов.
Для системного программирования (режим ядра) — С, в других областях — могут быть другие языки.
Здравствуйте, VladD2, Вы писали: VD>Дык тебе и говорят, что нет проблем в операторах. Ты их сам придумал. А есть проблемы в идиотах использующих вещи не по назначению.
Тебе просто не удаётся понять, что речь как раз идёт о наличии такого понятия как "вешь, которую можно использовать не по назначению". Поскольку число идиотов примерно постоянно в любой системе координат и снижению не поддаётся, то надо говорить о снижении числа двусмысленностей.
Когда Максим говорит про перегрузку, он совершенно прав.
Правило коммутативности обязано выполнятся, стало быть, те ситуации, которые по разному интерпретируют (a+b) и (b+a) должны идти в сад. Во избежание.
О>На болиде Ф1 обычно 6-7 скоростей. На моём велосипеде 24!
О>А по-хорошему перед тем, как садиться в болид Ф1, надо потренироваться в картинге, с чего и начинал Шумахер (чтоб он наконец-то проиграл хоть этот чемпионат ).
Вы неверно истолковали мой ответ. Ненавистник, он же новичок в С++, тут только один — это автор всего этого безобразия, Maxim. Я сам был таким лет 8 назад, когда работал с ассемблером, но был плох в С++, благо теперь я повзрослел
О>Вроде такого: Бейсик -> Паскаль -> С++. А мне сейчас, параллельно с проектом на С++, приходится лабать испытательные программы на языке ОНИКС (Орентированный на Наземные Испытания Космичесих Систем). В нём нет объектов, с этим я ещё согласен мириться. Но в нём ещё нельзя объявлять глобальные переменные, многомерные массивы, указатели, нет даже структур, и нет макросов, чтобы хоть как-то сымитировать некоторые из этих вещей (зато есть потоки). После С++ с STL очень тяжко. Размер программ получается раза в 2-10 больше, чем аналогичных на С++. Не обижайте С++!!! А С давно пора выкинуть в помойку как мелкое подмножество С++, по моему скромному мнению.
Сам прошел этот путь Basic -> Pascal -> C -> C++. Только межде Pascal и С я освоил Asm, на который до сих пор есть коммерческий спрос. Сейчас работаю одновременно с C, С++, Delphi, Asm. Естесвенно С++ самы гибкий и удобный, а с разросшимся проектом на Delphi я просто мучаюсь, и жалею что сразу не был заложен С++. Так что понимаю ваши чувства при работе с ОНИКС.
О>А С давно пора выкинуть в помойку как мелкое подмножество С++, по моему скромному мнению.
Э, какой горячий джигит ,).
Кроме x89 архитектуры процессоров есть ещё десятки других платформ, иногда очень экзотических. И для этих платформ нет С++ компилятора, а есть только С. То есть это вопрос переносимости, который очень актуален для некоторых промышенных отраслей.
А лет через 10-20 и С++ тоже могут на свалку викинуть, как когда то перфокарты. Будем сидеть на диване обвешанные электродами и мыслить программы на самых глубоких уровнях подсознания. Не вечно же клавиатуру терзать
Мне лично тенденция развития программирования бизнес-приложений на C# кажется положительной(есть такое субъективное ощущение).
Все хорошо, что легче писать и главное читать.
А С — в основном близкий к машине язык программирования, но не ассемблер. NT во многом закрепила такую роль C
своей идеологией переносимой системы (и является примером очень сложной операционной системы, реализованной простыми языковыми средствами).
Здравствуйте, vstrogov, Вы писали:
V>Мне лично тенденция развития программирования бизнес-приложений на C# кажется положительной(есть такое субъективное ощущение).
Сдается мне, что Шарп все же новый универсальный язык, а не замена жлабэйсику.
V>Все хорошо, что легче писать и главное читать.
Именно!
V>А С — в основном близкий к машине язык программирования, но не ассемблер. NT во многом закрепила такую роль C V>своей идеологией переносимой системы (и является примером очень сложной операционной системы, реализованной простыми языковыми средствами).
Ну, NT далеко не на С написан. Ядро возможно. Но оно не составляет основную часть ОС. Да и переносимость NT на сегодня уже ушла в прошлое (все Мипсы и ППиСи давно забыты).
Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT ведь в свое время была написана с чистого листа (только на основе опыта и знаний). Сейчас как раз такой же момент. Опыта и знаний накопилось много. Имеющиеся ОС уже настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать каую-нить Каиру.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, bwowa, Вы писали:
B>Вы неверно истолковали мой ответ. Ненавистник, он же новичок в С++, тут только один — это автор всего этого безобразия, Maxim. Я сам был таким лет 8 назад, когда работал с ассемблером, но был плох в С++, благо теперь я повзрослел
Вы неверно истолковали мой ответ. Я отвечал и на ваше и на предыдущие сообщения. И вас я не имел ввиду, конечно.
B> Сам прошел этот путь Basic -> Pascal -> C -> C++. Только межде Pascal и С я освоил Asm, на который до сих пор есть коммерческий спрос. Сейчас работаю одновременно с C, С++, Delphi, Asm. Естесвенно С++ самы гибкий и удобный, а с разросшимся проектом на Delphi я просто мучаюсь, и жалею что сразу не был заложен С++. Так что понимаю ваши чувства при работе с ОНИКС.
В этой цепочке С я пропустил, но попрограммировать на нём всё же немного удалось! Работал в одной компании разработчиков ГИС, в которой проект писался на С. Там был гениальный архитектор и программист Тим , таких людей я встречаю очень редко — человек-энциклопедия. Ему удалось грамотно спроектировать ГИС так, чтобы она легко портировалась в разные ОС (поэтому и был выбран С). Но всё в конце концов свелось к моделированию С++ средствами С. Помню некислые структуры с указателями на ф-ии, заменяющие таблицы виртуальных методов в С++; структуры, различающиеся только одним членом, которые можно было легко отнаследовать в С++. Когда мне оттуда пришлось уйти (а жаль), исходники проекта на С состояли из ~70000 строк... Вывода 2: и на С можно писать серьёзные вещи, и не факт, что на С++ проект не занимал бы ~50000 строк.
B> Э, какой горячий джигит ,). B> Кроме x89 архитектуры процессоров есть ещё десятки других платформ, иногда очень экзотических. И для этих платформ нет С++ компилятора, а есть только С. То есть это вопрос переносимости, который очень актуален для некоторых промышенных отраслей.
Ну да, это я погорячился, прочитав предыдущие сообщения. Компилятор С++ вообще сложная вещь, не все ОС могут себе позволить. Вот в том числе поэтому приходится писать на ОНИКСе , который сам написан на С (ОС QNX-2 /*вам смешно... а я иногда о DOSе мечтаю */). Кстати, сборка программ на ОНИКСе проходит так: сначала текст программы на ОНИКСе преобразуется в (нечитабельный) текст программы на С , потом запускается компилятор С, а потом полученные файлы *.obj собираются в исполняемые файлы... Вот такая история
B> А лет через 10-20 и С++ тоже могут на свалку викинуть, как когда то перфокарты. Будем сидеть на диване обвешанные электродами и мыслить программы на самых глубоких уровнях подсознания. Не вечно же клавиатуру терзать
Не, не будет такого лет через 10-20 Легче создать программу, которая делает работу за программиста (хотя это ещё вопрос), и, я думаю, это время не за горами. Потому что есть известный парадокс: цель программистов — сделать их профессию ненужной.
VD>Ну, NT далеко не на С написан. Ядро возможно. Но оно не составляет основную часть ОС. Да и переносимость NT на сегодня уже ушла в прошлое (все Мипсы и ППиСи давно забыты).
С этим не могу согласиться, сравнительная быстрота портирования на IA64 и AMD64 говорит о том, что ничего не ушло в прошлое.
Здравствуйте, vstrogov, Вы писали:
V>С этим не могу согласиться, сравнительная быстрота портирования на IA64 и AMD64 говорит о том, что ничего не ушло в прошлое.
Быстрота? На IA64 виндовс портируется уже лет пять, и все есть проблемы. AMD64 вообще считай та же архитектура. Да и IA64 имеет много общего в плане управления железом.
Сдается мне что партирование даже на близкие платформы дается МС не дешего. Именно по этому и забили на PPC и Mips. Денег приходилось вкладывать море, а окумпаемость фиговая.
Сдается мне, что во времена NT 3.11 она портировалась куда проще. Оптимизация производетельности бьет больно не только по надежности, но и портируемости.
ЗЫ
Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых (в том числе и раньше) платформ.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vstrogov, Вы писали:
V>>С этим не могу согласиться, сравнительная быстрота портирования на IA64 и AMD64 говорит о том, что ничего не ушло в прошлое.
VD>Быстрота? На IA64 виндовс портируется уже лет пять, и все есть проблемы. AMD64 вообще считай та же архитектура. Да и IA64 имеет много общего в плане управления железом.
VD>Сдается мне что партирование даже на близкие платформы дается МС не дешего. Именно по этому и забили на PPC и Mips. Денег приходилось вкладывать море, а окумпаемость фиговая.
VD>Сдается мне, что во времена NT 3.11 она портировалась куда проще. Оптимизация производетельности бьет больно не только по надежности, но и портируемости.
VD>ЗЫ
VD>Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых (в том числе и раньше) платформ.
Использование C как максимально распространенного и стандартизированного (на всех теоретически возможных платформах) было заложено в требования проекта NT.
Здравствуйте, Maxim S. Shatskih, Вы писали:
G>>Да чушь полная. ООП — это такой же инструмент как и любой другой. Все зависит от того >>кто как этим инструментом пользуется. Если руки из жопы растут, то хоть ооп, хоть >>процедурное программирование — один хрен будет куча ошибок и проблем. Вопрос не в >>инструменте а в квалификации товарищей, которые его пользуют.
MSS>Типичное возражение, и совершенно неверное.
MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.
MSS>Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.
MSS>Использование оператора сдвига для печати — в минус.
MSS>Это вопросы азов эргономики.
size_t s=...;
printf("%u\n",s);
Слабо найти и исправить баг в этом коде? Как там с азами эргономики поиска багов?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Exhumer, Вы писали:
E>>P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.
VD>Можно узнать чем ООП может помешать драйверам?
Имея соответстующий опыт, могу уверено сказать -- поможет. Наблюдая, как люди средствами C изображают полиморфизм, например, хочется плякать.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>> Творческое пользование темплейтами также сможет доставить потомкам MSS>>> немало приятных минут. S>>Бывает. Но если нет шаблонов, то вместо них на помощь приходят макросы... А S>>это вообще жопа.
MSS>Темплейты как раз хорошая фича. Одна из лучших в Си++.
MSS>>> Вышли из блока -- значит, вышли, и нечего кроме. S>>И забыли закрыть половину хэндлов....
MSS>Сразу видно. Локально видно. Легко править.
Здравствуйте, VladD2, Вы писали:
VD>Рано или поздно и Шарп устареет. Но на сегодня он ближе всего к идеало из императивных языков. Кстати, возможно лучшим развитием языков для сложных проектов будет интеграция в императивный язык декларативной и функциональной составляющих. Собственно кое что в Шарпе уже есть (атрибуты).
к примеру, "ленивые вычисления" были бы весьма полезны
Здравствуйте, VladD2, Вы писали:
VD>Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT ведь в свое время была написана с чистого листа (только на основе опыта и знаний). Сейчас как раз такой же момент. Опыта и знаний накопилось много. Имеющиеся ОС уже настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать каую-нить Каиру.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT ведь в свое время была написана с чистого листа (только на основе опыта и знаний). Сейчас как раз такой же момент. Опыта и знаний накопилось много. Имеющиеся ОС уже настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать каую-нить Каиру.
Д>Longhorn?
VD>>Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT ведь в свое время была написана с чистого листа (только на основе опыта и знаний). Сейчас как раз такой же момент. Опыта и знаний накопилось много. Имеющиеся ОС уже настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать каую-нить Каиру.
Не стоит рассматривать вещи отвлеченно от жизни и бизнеса.
Гейтс однажды сказал примерно следующее: "То, что сделали Дейв(Катлер) и другие, сравнимо с проектом полета на Луну".
Это колоссальное капиталовложение. Проект NT как переносимой OC был одним из главных средств захвата рынков,
на момент начала работ (1988, а до этого были VMS и исследовательский проект (Prism если не ошибаюсь) Катлера в Digital) было совсем не ясно, какая аппаратная платформа будет доминировать в 90-е.
>the development language debate from Assembly versus C to C versus C++", а в DDK уже >сравнительно давно встречаются примеры кода, написанного на С++ (см. >?src\wdm\audio\msvad\savedata.*).
Только PortCls и то, что с ним завязано. И — заметим — какое маленькое подмножество Си++ там использовано.
Кстати, можно вспомнить, что говорил Питер Вискарола насчет Си++ в ядре Кажется, OSR достаточно уважаемая команда.
B>Вы неверно истолковали мой ответ. Ненавистник, он же новичок в С++, тут только один — >это автор всего этого безобразия, Maxim.
Ага, новичок. С 93го года на этом языке работаю.
Более того. Для UI я им и по сей день пользуюсь, естественно.
B> Э, какой горячий джигит ,). B> Кроме x89 архитектуры процессоров есть ещё десятки других платформ, иногда очень >экзотических. И для этих платформ нет С++ компилятора, а есть только С.
Учите матчасть. gcc портирован на такую экзотику, что вряд ли бывала в России. И для экзотических платформ в наше время — портируют gcc, а не пишут свой компилятор.
>То есть это вопрос переносимости, который очень актуален для некоторых промышенных >отраслей.
Бред. См. выше.
B> А лет через 10-20 и С++ тоже могут на свалку викинуть, как когда то перфокарты.
То-то UNIX 30 лет живет без существенных изменений Есть такое понятие — классика.
Здравствуйте, vstrogov, Вы писали:
VD>>Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых (в том числе и раньше) платформ.
V>Использование C как максимально распространенного и стандартизированного (на всех теоретически возможных платформах) было заложено в требования проекта NT.
Не забывай, что это было почти 15 лет назад. Тогда у МС вообще небыло своего С++ компилятора, а С++ был еще в зародыше.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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>программистом". На С++ мне такой кошмар ни разу не попадался.
E>А не надо файлы исходников листать. Надо диаграммы классов и состояний смотреть. Это >следующий уровень абстракции.
...и он скроет как раз те детали, от которых зависит производительность и надежность кода...
MSS>>Прекрасный пример! Многомиллиардная корпорация! E>Ну если ты считаешь, что делает McDonalds — хорошо
Это нормально. По крайней мере это не совковая столовка с блевотными подносами, вытертыми грязной тряпкой.
И не Ростикс какой-нить, где в зале кухней воняет.
E>Ты свою семью в McDonalds поведешь?
Иногда по пути заходим мороженое съесть.
И разговор-то не о том. А о том, что Макдональдс — успешный бизнес. Вот и все.
VD>Може, то выглядет смешно. Кстати, в 2001 это тоже вряд ли могло быть написано. Дотнет >официально вышел в 2002-ом и трепаться о Шарпе в таком стле разумный человек работающий >на МС не стал бы.
Не стал бы как представитель компании на публике. В узком кругу — пожалуйста.
V>Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где- >то назад на редмондовском V>форуме разработчиков драйверов (в частности в нем участвуют многие ключевые >разработчики NT).
Да. Еще и на английский его сам перевел.
И развел там flamewar, но — надо заметить — там народ поопытнее, и меньше людей, которые с барабаном на шее возглавляют колонну защитников ОО, при этом не зная, чем RTTI противоречит полиморфизму.
V>Высокая стоимость сопровождения кода C++ и вред скрытой семантики — факт.
Особенно врапперы всех мастей сюда вклад вносят. Поубивав бы вот это точно самый настоящий "код с душком".
V>Но главным критерием на мой взгляд является уместность употребления языка в конкретном >культурном контексте и традиции.
Совершенно верно.
V>Хорошо то, что принимается сообществом (или большей/авторитетной частью с возможными >исключениями) и соответствует большинству доступных материалов.
Угу. Пример — Numega DriverStudio. Допустил багу в коде на ней — и все, трында, помощь на форуме почти невозможна.
Потому как мало кто ей пользуется. А если человек ее не знает — первая мысль — "а, ну тут, наверное, эти самые классы использованы не так, как надо" — и все.
Реальная поддержка возможно только от Нумеги, а она у них — по сравнению с Майкрософт и просто сообществом — слабенькая совсем.
V>Для системного программирования (режим ядра) — С, в других областях — могут быть >другие языки.
Конечно. И есть критерии даже.
Цена баги в человеко-часах. Любой UI по этому параметру — сразу относится к простому программированию. Сразу. Потому как любой баг в UI находится мгновенно. Потому как у UI крайне редко бывают interop issues.
А высокая сложность — написание прибамбасов снизу и сбоку к любой системе. Особенно если система без исходников. Особенно если средства отладки подчас требуют ребута каждый раз. Заметим — я описал системное программирование под Windows.
Или же вообще нет толком средств отладки, как для Pocket PC.
Когда высока цена баги, то лучше уж сделать так, чтобы вся логика бесстыдно смотрела в глаза. Тогда баг проще найти вычиткой, не связываясь с отладкой — а в таких средах очень часто именно вычиткой баги и находят.
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-го года... (ну ессесено драйвера правилились, но основные системы похоже что нет )
Я наверное уникальный случай, мой первый язык был c++, а уж потом паскаль и C ( и то, меня этому учили в институте и эгзамен по паскалю я сдавал преподу по теме C++ в виде исключения ). Эти чисто процедурные языки не впечатлили. Я разрабатываю систему наподобии navision axapta на С++ с применением технологии COM, так вот, если б я писал на C ( я на C я всё же ОЧЕНЬ много писал ), я бы повесился. Уже 30 000 строк каркаса, гуи 20 000. Я конечно не использую dynamic_cast, темплейтов и эксепшенов, и очень доволен, и использовать не хочеться.
вот
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
A>А самое инетресное, что посмотрев исходники Вин2К пришел к выводу, что ядро не >правилось этак с 96-го года... (ну ессесено драйвера правилились, но основные >системы похоже что нет )
Просто сразу хорошо написали, и все.
От того, что туда напихают врапперов по WolfHoundу , оно лучше не станет.
— и юзай как хочешь. Полная прозрачность, как у смартпойнтера. Единственная разница — в месте объявления handle и вызове CreateFile.
Мерзость врапперов в том, что они из всем известного системного API делают что-то хрен знает какое.
WH>Короче тех кто не понимает что такое врапер на работу дешевле не брать.
В известных мне командах в Москве при виде враппера вокруг ReadFile подумали бы — "маньяааааак" — и точно на работу бы не взяли.
MSS>>Смартпойнтеры — один разговор. Обертки — бредятина полная. Забивание мозгов лишней >информацией. WH>В чем разница? И те и другие созданы для того чтобы скрывать детали.
Враппер ничего не скрывает. Как была CreateFile, так и осталась.
WH>Вот только там надо не забыть закрыть фаил... А это геморой.
Правда что ли?
WH>2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без >произвольного доступа что есть маразм.
Правда что ли? а если это качаемый с HTTP поток? Сериализация из такого потока возможна? да. Ну и на кой требовать произвольный доступ для сериализации?
MSS>>Еще забыли про деструктор или release. Раз уж есть хоть один виртуальный метод — то >виртуальный деструктор — это святое. WH>Это догмы.
И? Ты же сам тут огласил другую догму, а именно "врапперы обязательны".
Невиртуальный деструктор приводит к отвратительным гиморам, которые очень сложно потом ловить. Есть рекомендация автора языка — везде, где есть вообще VMT, делать виртуальный деструктор. Разумная и обоснованная.
MSS>>Сами по себе обертки уже есть детали. Те самые. WH>Детали это то что прячет хорошая обертка.
Здравствуйте, WolfHound, Вы писали:
WH>2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без произвольного доступа что есть маразм.
Имхо,все очень даже логично для последовательного стрима. Для произвольного доступа есть IStream.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Maxim S. Shatskih, Вы писали:
A>>вроде работает как ожидалось... или я чего не понял?
MSS>Непортабельно. Тип size_t не факт, что лезет в %u.
MSS>С size_t это не сильно актуально, а вот с off_t — еще как! бывает и 32, и 64 бита.
аа... понятно...
но в данном случае это проблема данного вида функций...
всетречаются и вот такие вещи:
call_func("some_super_function_v1", "(%i%i%u)", a, b, c); (например в xml-rpc)
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вот это очень хорошая идея.
Дык на то они новый язык и проектировали, чтобы учесть и по возможности избежать проблем старого.
MSS>Сначала придумали глупость под названием references, глупость потому, что это неполноценный дубликат указателей. А неполноценный потому, что [] не работают с ними.
Это твое лично заблуждение. Ссылки — это очень удобное и полезное расширение. Оно уберигает о кучи проверок и ошибок. Другое дело что при передаче в метод синтаксически оно не выделяется. Ну, так язык надо дорабатывать.
MSS>А потом стали придумывать соглашения кодирования, чтобы не дать этой глупости портить код.
Подкручивать нужно язык и очень серьезно. Только не С, а скорее теперь уже к C#-у.
MSS>Единственное место, где реально нужна reference — это перекрытые операторы, дающие lvalue. operator[], например.
Мост таких море. Задай вопрос на форуме по С++ и их тебе насыпят тонну.
VD>>Агащасблин. А про то, что указатель может быть NULL или черти чем ты не забыл? Ссылки >>как раз это устраняют. Так что тут пролема не в наличии фичи, а в плохом синтаксисе.
MSS>А какая разница?
Огромная.
MSS> Утверждение "ссылки из Си++ — это плохо" — верно и в том, и в другом случае.
Оно вообще не верно.
MSS>Аргументы есть какие-то для такого вывода? В ядре Windows — где только из самого ядра торчит 1100 функций, а еще есть куча подсистем вне ядра типа NDIS — как-то такой проблемы не возникает.
Заметь компания сделавшая это ядро, создала новый язык в котором простраства имен не только не удалены, но и наоборот стали важнейшим компонентом.
1100 функций, как тебе уже тут сказали — это копейки. Размер среднего проекта. Имея полноценную систему пространств имен, мы можем давать полноценные, понятные и в тоже время короткие имена. Префиксы же легко могут пересечься, особенно если использовать код от назных производителей.
В общем, это утверждение даже не хочется обсуждать настолько оно бессмысленно.
VD>>string a = "мыла"; VD>>string b = "Маша " + a + " раму." + "Вот " + "такие пироги.";
MSS>Единственный случай, где overloading разумен. А, да, комплексные числа еще.
Случаев еще надыбать можно немало. И если ты обратишь внимание, то что-то не заметно толп ненормальных приделывающих операторы к чему попало. Полезная фича для некоторых применений. Побочных эффектов не больше чем от наличия методов.
MSS>Разница ощущается? Одно дело — библиотечная функция, имя которой все знают. Другое дело, когда в выражении выполняется какая-то работа, и выполняется так, что по синтаксису этого не заметно.
Нет не ощущаю. Мне пофигу от чего будет недокументированных побочный эффект. Аргументом против операторов он быть точно не может.
MSS>Исходная статья микрософтовца о чем была? О том, что Си++ _открывает намного больше возможностей сделать глупость_, и намного больше возможностей написать грязнющий код. Потому нужно меньше доверять людям, и пользоваться тем языком, у которого таких возможностей напаскудить — меньше.
Исходная статья была откровенным бредом.
MSS>Из тех же соображений, из каких уменьшают число приборов в кабине истребителя.
Ага. Заменяя их одинм компьютером.
MSS>Стоит задача. Код, работающий единообразным образом с разными объектами. Обычно есть два паттерна решения этой задачи: MSS>а) полиморфный — сказать "сделай", а инстанс сам разберется, как он это будет делать. MSS>б) явно спросить "а какого типа вот этот инстанс?" (эта возможность и называется RTTI) и потом сделать или switch, или цепочку ifов, для каждого типа свой код.
А. Ну, тогда нужно еще обвинить во вредности свитчи и переменные, так как на них тоже можно полиморфизм эмулировать.
Вот только информация о типах можно использовать для тысячи задачь. Например, за счет нее можно сериализацию автоматизировать или АОП-фичи реализовывать.
MSS>RTTI противоречит полиморфизму. Это второй путь решения тех же задач, и путь почти всегда плохой.
Свитчи противоречат полиморфизму! Не смешно?
То что ножом можно убить еще не значит, что его нельзя использовать в миных целях.
MSS>Крайне редко действительно нужна RTTI.
Такое действительно редко. А полноценное использовалось бы очень часто.
MSS> Например, при вводе-выводе объектов. Скажем, в COM интерфейс IPersist (который и есть RTTI) — только за этим и задуман, как ясно из имени. Придуман как база для наследования IPersistFile, IPersistStream и прочих. В ТурбоВижне в 90ые годы — то же самое примерно было. RTTI, придуманный для ввода-вывода объектов.
Сдается мне, что те кто пишут стандарт плюсов о сериализации в КОМ вообще не слышали.
MSS>RTTI вписывается в ОО концепции? Может, это пиарная фигня, которую несут ради маркетинговых соображения, а такие, как ты, верят, потому как не знают, что такое полиморфизм?
Полиморфизм тут непричем. RTTI в С++ сделан лажово. Но полезность самой концепции предоставления информации о типах это не уничижает. Полиморфизм тут тоже не причем. Там где достаточно полиморфизма рефлекшен не нужен. Но есть задачи ни коим боком не решающися полиморфизмом, а при наличии информации о типах решающиеся на ура.
MSS>Правильно совершенно. Чем меньше автосгенеренного компилятором кода — тем лучше. Он принципиально закрыт и не изменяем. С библиотечными фичами не так — не нравится, сделай свою, делов-то.
Совершенно, да не правильно. Во всем нужен разумный подход. То что проще сделать в компиляторе, то и нужно в нем делать. Ту же информацию о типах можно порождать только им. Читать уже можно будет и библиотекой...
VD>>Можно ссылки на то откуда ты взял "во-первых и во-вторых"?
MSS>Страуструп/Эллис Annotated C++ Reference Manual 90го года. Длииинный текст курсивом, почему в языке нет RTTI.
Что-то я ни разу таких его слов не читал.
MSS>Нет. Макрос лучше, чем вшитый в компилятор код. Потому как это не черный ящик.
А. Ну, ну. Попробуй сравни возможности этих макросов с рефлекшоном дотнета.
VD>>Ну, "откастомайзи" ради хохмы чтобы получить информацию сравнимую с дотнетной.
MSS>А зачем она нужна?
Почитай дотнетный форум, статей тоже по этому поводу хватает... Погляди на то как наш Хоум сделан. Там многое на решлекшоне базируется. В исходниках есть не мало примеров его использования...
MSS>При действительно ОО проектировании просто не нужна эта информация, разве что для debug traces Си++, помимо всего прочего, еще и не совсем ОО.
Я не фанат крайностей. Я предпочитаю просты, красивые и эффективные решения. Рефлекшон для них очень даже подходит. ОО-дизайном их не достич.
VD>>Пока, что ты назвал одну фичу которую нужно дорабатывать.
MSS>Я назвал фичу, которая принципиально не нужна.
По-твоему, а по моему очень даже нужна. И думаю, что со мной согласятся очень многие. Можно устроить голосование...
MSS>А я балдею с людей, которых не тянет блевать просто от синтаксиса dynamic_cast<имя>(...).
Синтаксис как синтаксис. Возможно Паскалевская конвенция мне бы понравилась больше, но и эта ничего. Главное, что четко выражает мысль и хорошо отличается от других конструкций. Сишное приведение (к сожалению испльзованное и в Шарпе) куда хуже. Оно и неоднозначно, и часто требует дополнительных скобок, и опасное ко всему прочему.
MSS>Чем хуже C-style cast в виде (тип)имя? Тем, что меньше визуального шума?
См. выше.
Могу так же добавить, что в Шарпе целая проблема в том, что народ вместо сишного приведения типов пытается использовать оператор "as" (невзирая на то, что он имеет другую семантику).
В общем, приемуществ сишного приведения я не вижу. А недостатков хватает.
MSS>Преимущества этих Си++ наворотов возникают только при использовании множественного наследования и RTTI. И то, и другое — маразм. Вон Джава прекрасно обходится без множественного наследования — в extends можно перечислить только один класс.
О! И сюда приплел нещасное RTTI. Перебор однако.
Множественное наследование тут тоже по сути непричем. Безопастное приведение типов требуется и при одиночном наследовании.
Кстити, в том же шарпе МН иногда очень нехватает (когда нужно подключить реализацию некой возможности к уже имеющемуся классу).
MSS>Да борьба-то тут скорее с маразмами конкретного языка, чем с ОО. Чем полиморфизм-то плох?
Я тебе уже говорил, что в этом языке действительно много маразма. Но ты почему-то докапываешся до довольно безобидных вещей. При этом про серьезные пролемы, те что выливаются, в реальные грабли, ты не говоришь. Вот мой список (без особого анализа):
1. Отсуствие возможности писать типобезопастные приложения.
2. Необходимость использования указателей.
3. Как следствие п. 2... Отстуствие полноценных встроенных массивов.
4. Отсуствие полноценной подержки информации о типах.
5. Оличие поведения виртуальных деструкторов от виртуальных функций.
6. Отсуствие предупреждений о невозможности вызова витуальных функций из конструкторов и деструкторов.
7. Неявный синтаксис передачи объектов по ссылке.
8. Отсуствие системы автоматического контроля памяти, или механизма позволяющего гладко интегрировать такой механизм на уровне библиотеки.
9. Бездарное исполнение препроцессора.
10. Как следствие п. 9. Опасность использования макросов.
11. Отсуствие модульности. Идея инглюдов протухла еще во времена С.
12. Как следствие п. 11. Необходимость предеклараций.
13. Как следствие п. 11. Необходимость разнесения интерфейсов и реализаций взаимно ссылающихся объектов.
14. Отсуствие фичи вроде делегатов в дотнете или клозюров в С++Билдере. В общем, отсуствие полноценного ОО-аналога сишного указателя на функцию.
15. Отсутствие компонентной модели и вообще описания динамичеки-загружаемых модулей.
16. Отсуствие средств метапрограммирования. Эмуляция метапрограммирования с помощью шаблонов вызывает отврощение своей сложностью и корявостью.
Думаю, если подумать, то список можно сильно расширить.
Однако многие проблемы С++ — это проблемы унаследованные от С. И говорить, что С — это тот идеал избавляющий от проблем С++ я бы не решился.
VD>>Низнаю что за задача "чтение SMART-данных".
MSS>Техническая безграмотность — это плохо.
Левый и некрасивый наезд. Все знать нельзя.
>>Но открывть файлы в конструкторе, а закрывать в деструкторе совершенно нормально.
MSS>Бред. Обработать ошибку нечем, кроме перегруженного до жути механизма exceptions.
А зачем кроме? Они как раз для этого и сделан. Вот только они в С++ тоже не идеальны. finally нет. Концепции передачи информации тоже. В дотнете исключения работают прекрасно. Правда там ЖЦ.
Ты бы лучше вместо повышения "технической" грамотности разобрался в исключениях. Это действительно полезная и удобная фича.
MSS>Не зря Брокшмидт в книжке про COM писал — "не делайте в конструкторе ничего, что могло быть обломиться.". Ой не зря.
А про try он не писал? Ну, да КОМ — это отдельная песня. В нем многое через задницу делать приходится.
MSS> У него очень разумный подход к Си++. Он не считает, что это революционно новая идеология и прочую такую муйню.
Было бы странно через 15 лет восхищяться революционностью.
MSS>У него подход — Си++ — не более чем способ записи того же, что можно сделать и на Си. Правильный подход.
Ага. А С — это способ записать тоже, что и на ассемблере. Вопрос в абстракции. На асме она одна, на С другая, на С++ третья, на Шарпе четвертая.
Твои слова в защиту С ничем не отличаются от слов в защиту асма лет 15 тому назад.
Недостатков у С в не меньше чем у С++. Он проще, но в основном с точки зрения разработчика компилятора. Ошибки же ловить на нем сложнее.
MSS>Отношение очень простое. Меньше фич — меньше руки чешутся их поюзать, где надо и где не надо.
И вот что забавно. В Шарпе фич больше чем в С++ и С вместе взятых, но писать, читать и отлаживать приложения написанные на нем в разы проще. Можещь объяснить этот феномен? Я вот могу. Шарп сбалансированный и продуманный язык в котором учтены и обойдены многие проблемы предшественников. Все его сложности направленны на решение сложностей решаемых задач.
Язык программирования — это инстумент. Примитивным инструментом можно решать только примитивные задачи. Это как копать яму лопатой и эксковатором.
MSS>Си простой язык.
С плохо спроектированный, опасный язык. Получить на нем плохой код очень просто. Многие недостатки С++ ростут от С.
MSS>Вред от сверхценных идей практически только в неоправданном усложнении того, что можно сделать проще.
Это если можно. Примитивные проблемы на чем угодно можно решить. С++ же разрабатывался для решения сложных проблем. Их он позволяет решает куда более просто чем С. Этому способствует большие возможности по абстрагированию. Причем и его время уходит. Появляются языки позволю абстрагировать задачи более эффективно.
MSS>Писать класс как обертку вокруг Win32 event... во это я понимаю! титаны мысли такое делают!
Блин, я болдею с этого примитивизма. Ты когда нибудь слышал о безопастности кода? О типобезопастности? О надежности?
Написав единыжды обертку ты застрахован от ошибок используя ее. А использование голого ВыньАпи приводит к ошибкам обязательно. Нужно только написать по больше кода.
VD>>С каких это пор простой код было сложно писать?
MSS>С тех пор, когда стали пропагандировать, что классика устарела, ее на помойку, и все надо делать только на новомодных вещах.
Ну, это называется реклама. Не слушай ее и все будет ОК. Я сам радуюсь когда в последнее время ХМЛ суют во все дыры. Вот только от этого сам ХМЛ хуже не становится. Это как Тайд. Он может и задолбал, но видимо стирать им можно довольно качественно.
MSS>Да. Си++ приводит к тому, что в даже простейшие задачи пихают кучу ненужных там наворотов. Лишнего в языке много.
На С++ можно писать и в стиле С. Так что это вообще голословное утверждение. Причем если писать на С++ в стиле С, то код только выигрывает. А вот если писать в ОО-стиле на С, то получается задница. Нагромождение кракозябр.
>>ОО-языки способствуют упрощению.
MSS>Да правда что ли?
Да. Правда.
MSS> Теперь, кроме того, чтобы думать, как код работает, еще приходится думать — а как поле объявить — protected или private?
Т.е. думать сложно. Ну, тогда ты не ту профессию выбрал.
Что касается модификаторов доступа, то это еще один примитивизм который ты пытаешся протолкнуть. Не нравятся тебе модификаторы не задумываяс пиши public или используй структуры. Если поймешь, что нужно все же поставить другой модификатор, значит они все же нужны.
Кстати, обясняется их необходимость практически твоими довадами. В программировании много лапоухих программистов от которых нужно спрятать кишки моего класса, чтобы они чё-нить не напортили. Еще, правда, есть обяснение основанное на упрощении жизни пользовтелей твоих классов, но это обяснение не для настоящих индейцев.
MSS>Претензии к ОО в основном идут к наследованию, которое действительно делает из простых задач сложные.
Я одного поянть не могу. Ты все гониш волну на С++, а ведь не нравится тебе именно ООП. Почему бы об этом открыто не сказать?
MSS> Уж лучше дублирование кода, чем отстойно спроектированное дерево наследования.
А может хорошо спроектированное и без дублирования? А?
MSS> А спроектировать его правильно — простите, но мало кто может. Тут нужен действительно талант, а не средне-рыночные навыки умника за 1200 долларей.
Видимо у меня этот талант есть, так как тут проблем не вижу.
Бездать использую любые средства, подходы и парадигмы сделает в итогде дерьмо. Ему не помешают ни отсуствие/наличие МН, ни какие другие фичи.
MSS>Претензии же к конкретно Си++, в отличие от ОО вообще — как правило к overloading и к RTTI, которая потянула за собой эти бредовые typecasts. К тому, что, строго говоря, к ОО не имеет отношения.
Здается мне, что у тебя натуральная каша в отношении предстовления о С++.
MSS>Сложнее. Меньше вещей, которыми можно до такой степени грязно злоупотребить.
Достаточно. Более чем достаточно. Причем примитивизм приводит к лавинообразному увеличению объемов кода и усложению проекта.
MSS>Таблицы указателей на функции?
Ну, почему таблицы. Структуры со списками псевдометодв в виде указателей, но роли это не играет.
MSS> Ничего ужасного уж особо в этом нет. В юниксе файловые системы на них основаны. И ничего. ОС пережила уже 30 лет, и до сих пор считается хорошей.
Да моло ли что по убогости где сделают. Это ужасно, убого и неудобно.
VD>>Ага. И нопэд куда лучше чем разные там студии.
MSS>Конечно. Сколько нужно сделать дебильных тычков мышью, чтобы развернуть дерево в ClassView?
Два. И можно без мыши. Клавиатуру еще никто не отменял. Я лично класс-вью пользуясь не часто. Но средствами навигации по коду постоянно. И фиг ты за мной угонишся в ноотпэде.
MSS>Или взять список пропертей из VB или Дельфи. Задача — посадить в форму 2 контрола, у которых одинаковые списки пропертей, и оба одинаково отличаются от дефолтного.
MSS>Сколько надо мышью пощелкать для этого? А на каждый щелчок надо еще прицелится, еще иногда надо список проскроллировать, да еще надо весь этот список (позиций 20) в кратковременной памяти удержать.
MSS>В VB спасает то, что можно взять FRM файл, открыть текстовым редактором и руками через copy/paste отредактировать. В Дельфи — не знаю.
MSS>Единственная ценность Студии — хороший текстовый редактор и визарды. Остальное все от лукавого.
Сразу видно, что достаточного количества ГУИ-ёв ты не понаклепал. Один два контрола может и можно вручную конопатить без особых проблем, но кодна форм много и объем наворотов в них значителен, то дизайнер резко облегчает жизнь. Залезь в Хоум погляди на объем некотороых форм. Долбить руками все это (а потом поддерживать) я бы точно не стал.
MSS>"Программирование без написания кода" путем заполнения форм и проперти-шитов — отстой.
А мне сдается, что любое упрощение и ускорение создания ПО является благом. А вот подобные вопли явно носят мало конструктива и не очень красивы.
MSS> Отстойность становится очевидной, как только нужно два или три похожих объекта сделать — придется два или три раза заполнять этот шит одинаковым образом.
Думаешь? Ах, да. Ты же выступаешь против наследования.
MSS>Задача обезьянья, и легко сделать просто глазную ошибку. А для начинающих да. Типа круто. Типа пологая learning curve.
Ну, я врядли могу считаться начинающим. Возможно даже больше тебя в этом деле колупаюсь. Но твоей позиции не разделяю. Здается мне, что ты просто плохо принимаешь новое.
MSS>Borland C++ 3.1 + OWL.
А разве Borland C++ 3.1 был связан с виндовс? Мне казалось он был под дос. Да компилятором С++ это назвать трудно. Хотя по тем временам...
MSS>А что мешает библиотеки понаписать, которые нужны?
Да их и так пишут. Только залатывание проблем языка библиотеками радостно только для Страуструпа. А на практике это маразм. Сотни кил кода на реализацию ОО-указателя на метод. Бред да и только.
>>Тогда бы он возможно и для ГУИ подошел. А в современном виде использовать его для ГУИ — >>это мозахизм.
MSS>Что не мазохизм? ПаэурБилдер? VB?
Ну, хуже С++ для создания ГУИ подхдит только С и пожалй асм.
Самыми удобными средствами я бы назвал дотнет и дельфи.
MSS>Хороший инструмент был. Пригодный для разработки достаточно серьезного софта.
Ну, по тем временам возможно. По факту полная фигня. Куча глюков и недоработок.
MSS>То-то они так широко известны то-то у них сайт http://www.devpartners.com такой хороший... видать, успешная компания
В общем неплохо известны. И думаю с бабками у них тоже все ОК.
VD>>Да и написанием драйверов и ОС занимаются еденицы.
MSS>Скажем точнее — занимаются лучшие.
Это у тебя самомнеие выпирает.
Сутя по твои словам занятие драйверами приводит к гипертрофированному консерватизму. Отрицание всех общепринятых норм разработки качественного ПО в качестве аргументацию за простоту и недоразвитых мостодонтов вроде С — это уже перебор. Причем полнейший.
MSS>А "мейнстрим" твой — тут вопросы про сокеты задает.
Я тебе скжу больше. Я вообще не разу в жизни с сокетами не работал. Не нужно было как-то. В прочем вопросы я тоже редко задаю.
MSS>А вот о том, что от эвента нечего наследовать, что примитивы синхронизации уже полиморфны и уже инкапсулированы — человек забыл.
Интересно причем тут это? Он что от оберток над эвентами наследников делел?
ЗЫ
В общем, похоже что разработка драйверо приводит к какому-то ужасному закапыванию в железо и нежелание видеть проблем других пробем. Может быть драйверы и принуждают к созданию софта в стиле С. Но есть еще куча других задач. И они примитивными средствами С решаются со слишком большими трудозатратами.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Инкапсуляция — это другое. Это отделение интерфейса от имплементации, и запрет лазить к деталям имплементации в обход оговоренного интерфейса.
Гы. Если тебя отделили от реализации , то о побочных эффектах ты принципиально знать не можешь.
Ты снова смотришь на мир со своей колоколни. Слишом низкоуровневой, что ли (?)... А ОО придумывалось не для решения частных задач, а для повышения абстракции. Нормальным положением дел в ООП является мышление на уровне абстракций вроде класса. Его внутреннее поведение — это его проблемы реализации. Тебе важны только предоставляемые возможности. Без доверия в таком случае просто нельзя.
MSS>Синтаксическое упрятывание скрытой семантики к инкапсуляции отношения не имеет. Полно ОО языков (да та же Джава, которая во многом сделана умнее Си++, в ней меньше создающих энтропию вещей) где не бывает "operator T", который вызывается неявно без каких бы то ни было напоминаний.
С++ не лучший язык. Но и не худший. Если выбирать, то я остановлю свой выбор на Шарпе. Он имеет множество того, что ты называешь плохим, однако на практике проблем от этого не случается.
Возвращаясь к теме, хочется заметить, что проблемы которые можно поиметь в С ничем не хуже С++-ных. Недаром для него написаны утилиты дополнительной проверки. Так что говоря о недостатках С++ не стоит приводить в пример более убогий и просто напичканый проблемами язык вроде С. Ведь когда ты начнешь его защищать ты будешь говорить слова которые будет прекрасно подходить для оправдания проблем С++.
>>Слова о вреде полиморфизма слышу впервые.
MSS>А где они?
Разве не ты говорил о том, что в ООЯ найти функцию которая будет вызвана в коде является большой проблемой?
MSS>Нет. Справятся, и справятся так, что потом умный не разберется в их бреде.
Так ты можешь привести хотя бы один широко известный пример данной проблемы?
VD>>МС сделала верный выбор спроектировав Шарп снуля.
MSS>Точнее, скопировав с Джавы в значительной степени.
В такой же степени они скопировали его с дельфи, С++, Васика, Смолтока и т.п. От явы взяты идеи рантайма и библиотек. Да и они нехило переработаны. То же что скопировано в основном очень неплохо. Можешь попытаться найти слабые места...
>>Очень многих проблем они избежали. >>И я совсем не понимаю почему не забыть об откровенно пережившем себя С, забить на С++ и >>пользоваться современным языком избавленным от большинства проблем.
MSS>То-то практически все серьезное (т.е. системное) программирование делают на Си.
Я незнаю чем системное программирование отличается по серьезности от любого другого. Но знаю, точно что мне лично системное программирование не к чему, как 99% других программистов. Все что выходит за рамки ядра ОС и драйверов прекрасно можно писать на Шарпе и дотнете.
Да и не знаю я статистики по системному программированию. Как? например, узнать на чем пишут драйверы ATI и NVidia?
И интересно чем конкретно занимаешся лично ты? Неужели работа моего ПК зависит от твоего труда?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Почему? Человек, видимо, имел отношение к разработке микрософтного компилятора Джавы.
Судя по его отношению к ней его как раз в это время выгнали.
MSS>Кстати, я не знаю, что там за грабли в Джаве он нашел... ИМХО она как раз свободна от многих извратов Си++. Действительно ОО, а не пародия на него.
Вот как раз сегодня имел удовольствие портировать исходники с Шарпа на Яву... Лучше я помолчу, а то ведь забанят нафиг не поглядев на то что это я родимый.
MSS>Ну Джавы — возможно. Там нет operator+ и прочих abstract datatypes наворотов, которые, кстати, к ОО отношения не имеют. Это из другой оперы.
В Яве к сожалению много чего другого нет. Концептуально она чище, но писать на Шарпе приятнее в разы, да и операторы в нем на месте.
MSS>Да. А вон почитай, как тут человек признавался в романтической любви к Си++ именно потому, что там одно и то же можно выразить по-разному
Дык то не романтик, то фанат.
Он просто еще не видел как можно писать програмы быстрее и проще чем текст в конфе...
>>концептуальной стройности
MSS>Си++ ее давно утерял, да и не факт, что имел (в отличие от Джавы и Шарпа).
Так оно и есть. Но почему? Многие сходятся на мнении, что именно из-за наследства С и неразумной борьбой за скорость, а не из-за ОО и т.п.
ЗЫ
Я согласен с тобой когда ты говоришь о граблях, но твои принипы их устранения путем примитивизации инстумента мне не нравятся. Кстати, именно это мне больше всего не нравится и в Яве. Её создатели пошли именно таким путем. Создали концептуально чистый, но пресный и неудобный язык.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ядро. MSS>Все подсистемы ядра кроме софтового РАЙДа (и его на помойку выбросили, заменив купленной у Веритаса урезанной версией VxVM) и PortCls MSS>SMSS MSS>LSA
LSA значит тоже на С писан? То-то мы поимели гемороя поставив на машину безобидный с виду CvsNT. LSA потек как друшлак. Причем при этом машина просто умирала, если не перезагрузить ее вовремя. Не думаю, что будучи переписаным на С++ что-то изменилось. Но уж больно наболело.
MSS>Короче, почти все, где нет UI. А вот где UI — там сразу Си++.
MSS>Еще прикол. Графический движок в НТ написан на Си++, еще в 91-92 годы. У микрософта тогда не было компилятора, и пользовали cfront. А вот API для драйверов видеокарт — Сишный. Все эти CLIPOBJ_bEnum есть Сишный враппер вокруг CLIPOBJ::bEnum.
MSS>Вот такие вот дела. Интересно, на чем XFree86 написан — на Си или Си++?
Незнаю. Честно говоря для меня особой разницы нет начем написано. Бльше интересует качество. А средства обеспечивающего кочество в таких вопросах я не знаю. Если только тотальная генерация кода на базе каких-нить схем...
MSS>Зато не забыт IA64, который не имеет ничего общего с x86, и во многом дальше от него, чем MIPS.
Дык его поддержка до сих пор нормальной назвать нельзя. Все в какой-то стадии редоделанности. Сдается мен, что АМД еще немного поднапрет и IA64 прикажет долго жить как Альфи и т.п.
MSS>Ага, только опыт и знания были накоплены на VMS некоторые ключевые структуры имеют дословные аналоги в VMS — типа IRP и MDL.
Ну, вот прошло достаточно времени чтобы накопить новый опыт. NT уже далека от той чистоты которую она имела во времена 3.11-3.51. На сегодня — это обросшая заплатками и компромисами свая. Обтеши их и увидишь дыры в проржавевшем корпусе.
MSS>Cairo — внутреннее имя для DCOM. Он-то тут причем?
Не, давным давно МС выпустил слух о том что в его недрах делается ОС нового поколения. И кодовое имя проекта Cairo. Это действительно было до ДКОМ-а. Подробностей я уже не помнь, но среди плано были ОО-файловая систем и т.п. В общем в Лонгхорн — жалкая породия. Возмжно ДКОМ как раз под это дело и делали. Только планы били несколько глобальными. В общем, сделай поиск по словам "Cairo ОС" и погляди на результаты...
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Просто сразу хорошо написали, и все.
Честно говоря не очень то хорошо ее писали. Тупой заем памяти или ресурсов в цикле приводит к полному параличу. И многозадачность далека от идеала. Пора бы им и попробовать переписать все это дело.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Обычный пиар. Было это эдак в 94-95. Тогда была модна идея ОО ОС, которая у всех с треском провалилась — и IBM Workplace OS, и Novell AppWare.
Ну, Next был куда раньше, и ОО там было немало. Да и Лонгхорн очень много от тех концепций поимел...
MSS>На деле — имя cairo использовалось внутри MS как название для DCOM.
Скорее всего DCOM был частью проекта с общим названием каиро. А что до рекламы, то у МС это постоянно. Пару лет назад они были готовы приделать приставку или суфикс .Net к чему угодно.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>По обмолвкам на форуме одного из ключевых людей, которые портировали NT на PPC, получается, что NT на PPC стала коммерчески нафиг никому не нужна тогда, когда Стив Джобс удушил юридически рынок клонов Макинтошей. В конце 90х.
И какая связть с Эплом? Просто NT на экзотике в принципе не целесообразно. МС нужны миллиарды, а в на экзотике можно заработать только имя.
MSS>Теперь общие соображения. Пентиум и Атлон — едва ли не быстрее всех этих Спарков и МИПСов. По целочисленной арифметике быстрее. Причина понятна — у Интела и АМД лучшая силиконовая технология, лучше, чем у Сана и Тексас Инструментс, которые Спарки делают на пару. Лучше, чем у MIPS. И так далее.
В те времена это было не так. Алфы рвали по частотам всех. Вот только под NT они были бесполезным железом. Драйверы левые. ОП нет. Спрос нулевой. К примеру, авишник шел на хваленой альфе в три раза хуже чем на пне. А инженерные рассчеты можно было делать и на других ОС.
MSS>Дальше. Сам процессор типа Спарка может стоит дешевле, чем Пентиум. Но он у нас собственность конкретной компании, которая заодно собирает на нем машины и к ним дает ОС. На этот рынок воткнуть свою ОС очень сложно. Для этого та родная ОС должна быть совсем отстой.
MSS>Именно потому порт НТ просто принесет совсем немного денег Майкрософту. Вот и все. Итаниум — другой разговор. Все еще есть шансы, что это будущее массовых десктопов. Такую штуку Майкрософт не упустит.
А я думаю, что NT на экзатике полностью убыточен. МС наворотила в NT много фич трудных к переносу. Все эти PNP и самовостановления привязывают ОС к железу. До 2000-ных NT переносилась на другую машину простым копированием. Теперь вероятность того что ОС заработает при смене матери стремится к нулю. Это не может не влиять на переносимость. Вернее на ее стоимость. Так что откат от продаж должен быть весомым. И разные Альфи, Мипсы и т.п. это просто не обеспечивают.
MSS>Более того. Есть сплетня, что DEC потребовала от Майкрософта разработать порт Альфы, угрожая судом насчет того, что Катлер унес некоторые конфиденциальные сведения о VMS, на опыте которой была основана архитектура НТ. Якобы без этой угрозы и на Альфу НТ бы не портировал никто.
Видимо вынуждали Компак их купить. Честно говоря идея с NT на альфе была коммерчески дохолой. Скорее это был эксперемент доказывающий возможности переносимости. У МС же тогда это был натуральный комплекс неполноценности.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ilya_ny, Вы писали:
_>смешно.. _>я лично программировал в начале 2001 на C# (Beta 2)
Значит должен знать, что такое DNA и какие ограничения на треп оно распростроняет.
Я программировал еще на пре бете и на бэте 1. И именно по этому могу скзать, что вероятность появления этих слов в 2001 стремится к нулю.
_>более того, я использовал С# код, созданный другим разработчиком в 2000
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>К чему? Мне нужно напечатать значение типа size_t. Как?
VD>Раз формат %u значит к unsigneg int.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Цена баги в человеко-часах. Любой UI по этому параметру — сразу относится к простому программированию. Сразу. Потому как любой баг в UI находится мгновенно. Потому как у UI крайне редко бывают interop issues.
Расскажи — это тем орлам из МС которые Ворд пишут (я так понимаю на С). А то уже так задолбало, что за последние 10 лет они не смогли выпустить ни одной версии ворда без серьезнейших багов.
За одно расскажи команде дотнета и КОМ-а о противоречии метаинформации основам ООП.
Приколько так же будет расскзать группе компиляторов о вреде модификаторов доступа.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>А вот этого — не надо! ЗХ>Нам, зверькам, фанатизм не к лицу — рАмантики мы ЗХ>И ваще — еще раз на меня таким словом заругаешься — за нос укушу.
Да, я так шутя.
VD>>Он просто еще не видел как можно писать програмы быстрее и проще чем текст в конфе...
ЗХ>Дык! Я ж о том и писал — что мне важно не быстро/безглючно писать код, а с удовольствием.
Дык ты видел пиониста получающего удовольствие от того, что его пальцы запутываются в клавишах и прилипают к ним? Вот так же язык можт позволить забыть о деталях и творить. Думать об идях, а не о битах, операторах и другой фигне.
ЗХ>Когда я перестану получать удовольствие от "тупого" кодирования — перестану считать себя программистом и найду другое дело по душе.
Лучше идти в начальство.
ЗХ>(Предвидя толпу любителей фразы "мальчик, с такими понятиями денег не заработать", предупреждаю — зарабатываю. на хлеб с икрой — хватает.)
Да, кто же проитв то? Мериться членами на счет зарабатываемого не буду. Да и не в этом счастье. Я пишу код не за деньги и получаю от этого удовольствие. Вот это я и называю рамантикой.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ЗХ>>Дык! Я ж о том и писал — что мне важно не быстро/безглючно писать код, а с удовольствием.
VD>Дык ты видел пиониста получающего удовольствие от того, что его пальцы запутываются в клавишах и прилипают к ним? Вот так же язык можт позволить забыть о деталях и творить. Думать об идях, а не о битах, операторах и другой фигне.
А вот не надо меня учить, от чего удовольствие получать!
Для меня кайф не только в том, чтоб сообразить крутую архитектуру, по-быстрому реализовать и посмотреть, что получилось.
Но и в создании хелпер-класса на 10 строк, над которым я бился 4 дня. Чес-слово!
Равно как и когда я пишу сказку — мне нравится чувствовать каждое слово, чувствовать, что я нашел единственный вариант из 18000 возможных. Просто вот такой подход у меня к написанию программ.
ЗХ>>Когда я перестану получать удовольствие от "тупого" кодирования — перестану считать себя программистом и найду другое дело по душе. VD>Лучше идти в начальство.
Фигня это, извиняюсь. Кому, может, и лучше.
А нас и тут неплохо кормят.
VD>Вот это я и называю рамантикой.
Каждому свое, и спорить, в общем-то, не о чем.
В "истории одного байта" тоже полно романтики. На самом низком уровне
VD>Не, давным давно МС выпустил слух о том что в его недрах делается ОС нового поколения. И кодовое имя проекта Cairo. Это действительно было до ДКОМ-а. Подробностей я уже не помнь, но среди плано были ОО-файловая систем и т.п. В общем в Лонгхорн — жалкая породия. Возмжно ДКОМ как раз под это дело и делали. Только планы били несколько глобальными. В общем, сделай поиск по словам "Cairo ОС" и погляди на результаты...
Знаю я это. Все, что на деле осталось от этого прожекта — это DCOM.
Отладчик от WinCEшного Platform Builder постоянно показывает полные пути к файлам исходников. Из них сразу делается 2 вывода а) сама ОС называлась mckendrick и б) DCOM назывался cairo.
MSS>>Обычный пиар. Было это эдак в 94-95. Тогда была модна идея ОО ОС, которая у всех с >треском провалилась — и IBM Workplace OS, и Novell AppWare. VD>Ну, Next был куда раньше, и ОО там было немало.
Я щупал руками NextStep в 94ом году.
В самом низу — Mach microkernel. Поверх него — BSD-compatible ядро. Структура директорий почти BSDшная, и совсем не System V.
Поверх этого — графический движок Display Postscript.
А вот уже поверх него начиналась объектность в виде классов UI. Как язык рекомендовался Objective C, и была среда разработки под него, до жути похожая на Дельфи, но старше Дельфей на несколько лет, и потому в те времена поражавшая воображение.
Визуально это предшественник AfterStep и WindowMaker из современных юниксов.
VD>Скорее всего DCOM был частью проекта с общим названием каиро.
Да, наверное, так и было. Проект был зело распиаренный.
MSS>>По обмолвкам на форуме одного из ключевых людей, которые портировали NT на PPC, >получается, что NT на PPC стала коммерчески нафиг никому не нужна тогда, когда Стив >Джобс удушил юридически рынок клонов Макинтошей. В конце 90х. VD>И какая связть с Эплом?
Я так понимаю — НТ планировали как альтернативу МакОСу для клонов Эпплов, чтобы клонмейкеры стали совсем независимы от Эппла.
МакОС тех времен был совсем убог по нижним уровням ОС.
VD>В те времена это было не так. Алфы рвали по частотам всех. Вот только под NT они были >бесполезным железом. Драйверы левые.
Хуже. НТ не на любой Альфе шла, а только на специальном ПАЛкоде, который делал из Альфы 32битный процессор.
VD>А я думаю, что NT на экзатике полностью убыточен. МС наворотила в NT много фич >трудных к переносу. Все эти PNP и самовостановления привязывают ОС к железу.
Во-первых, PnP тогда не было, он в НТ появился только в w2k.
Во-вторых, PnP наоборот развязывает ОС от железа скорее. Модульность увеличилась. Например, до-PnPшный драйвер должен был знать о том, что бывает на свете ISA, а бывает PCI. Если, конечно, его чип бывает для той и для другой шины. А PnPшному драйверу в этом вопросе все пофиг. Дали ему CM_RESOURCE_LIST, где описаны адреса железки — и все.
>До 2000-ных NT переносилась на другую машину простым копированием. Теперь вероятность >того что ОС заработает при смене матери стремится к нулю.
Из-за ИДЕ в основном. Другой ИДЕ чип, не соответствующий драйверу.
Еще из-за ACPI и багливых таблиц в биосах — во времена пентиума-3 была не редкость.
>У МС же тогда это был натуральный комплекс неполноценности.
Факт.
Я еще когда молодой был, в 95ом году, слышал от своего тогдашего шефа (главный менеджер в одной фирме, которая Microsoft Solution Provider) — "Microsoft есть убогая персоналочная компания, у них один Ворд и Эксел, и ихний Бэкофис из пальца высосан — куда они лезут-то на рынок тяжелых систем, они там не понимают ничего..."
Ш>Т.е. его вообще невозможно распечатать используя стандартные коды форматирования.
Гы! У MSа давно есть свои собственные коды. %p, например. Печатает пойнтер. 64бита на Win64, 32 бита на Win32.
VD>>Ну, а то что в С/С++ функции с переменным количеством параметром полное дермо никто >и не спорит.
Дерьмо в основном тем, что туда класс не передашь.
Я чуть ниже начал нитку "Наследование и рефакторинг". Там максимально по делу изложена главная (ИМХО) претензия к ОО. Если есть желание — почитай.
Пока что мне там ответили а) что "ООП еще так молодо" — это за 20-то лет! б) что нельзя наследоваться от конечных классов, а этот запрет нарушался во всех знаменитых (и хороших) ОО фреймворках от ТурбоВижна до наших дней в) что качественный ОО дизайн требует фич, которые толком не поддержаны ни в одном ОО языке, и поддержаны разве что в виде макросов в ATL.
Насчет драйверов. Проекты маленькие по объему (мегабайт густо комментированного исходника — это в этой области большой проект) — но как бы очень насыщенные по логике. В этом области "терять сцепление колес с дорогой" и витать в облаках абстракций вряд ли оправдано. И требования к надежности очень высоки. Потому ИМХО оправдано не прятать детали реализации, а выставлять наружу как есть.
Абстракции там получаются очень крупноблочные, скорее как в COMе, а не как в классических ОО языках типа Дельфей, Джавы и Шарпа.
Здравствуйте, VladD2, Вы писали:
WH>>а если бы был компаил-тайм рефлекшен... то вобще бы сразу сгенерил бы код для сериализации в нужном не формате. VD>Пойми если рефлекшен есть, то он есть. Сделай превую компиляцию, получи мета-информацию, прочти ее и сгенери код сериализации.
Это я могу и сейчас... читаем дебугинфо и... сам не пробовал но кто-то на форуме говорил что у него это работает.
Но это не переносимо
Кроме мейнстрейма для которого .НЕТ и ему подобные пожалуй лучший выбор есть и будут области программирования где нужен zero overhead language те что не использую за то не плачу.
Вот тут то и нужен компаил тайм рефлекшен. Чтобы то что нужно я мог сгенерить прямо во время компиляции и именно так как мне надо. А если мне понадобится метаинформация в рантайме то я мог бы ее вытащить причем только для тех классов для которых она мне нужна и ровно столько сколько мне нужно.
Единственный адекватный способ создать такой язык это проектирование его с нуля и при этом забив на обратную совместимость с С/С++.
К стати. У тебя есть конкретные идеи по выделеной части?
8. Отсуствие системы автоматического контроля памяти, или механизма позволяющего гладко интегрировать такой механизм на уровне библиотеки.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
WH>>А теперь посмотри на амереканцев... жрут в МакДональдсе и выглядят как... ну вы поняли... Короче я считаю что МакДональдс гораздо опаснее чем БенЛаден и компания... В отличии от террористов МакДональдс убивает милионами причем с особой жестокостью и цинизмом.
VD>Не, а мне нравится макдонадльдс. Я им не злоупотребляю. А когда нужно в попыхах перекусить, то это лучше бем пирожок неизвестного качества или наши забегаловки.
В Америке и в Москве МакДональдс — это небо и земля.
Здравствуйте, vstrogov, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Сдается мне, что сей труд написан на днях.
V>Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где-то назад на редмондовском V>форуме разработчиков драйверов (в частности в нем участвуют многие ключевые разработчики NT).
Здравствуйте, Дарней, Вы писали:
Д>Это оказалась очень хорошая иллюстрация к тому, что я хотел сказать Д>и это не первая ошибка в MSDN, на которую я натыкаюсь Д>и не первая ошибка, которую помог бы избежать C++ (при его грамотном применении, конечно)
Во-во...
Так лучше будет(я понятия не имею что этот код делает. просто тупо перебил его на враперы.)
#include <windows.h>
#include <winbase.h>
#include <initguid.h>
#include <ole2.h>
#include <mstask.h>
#include <msterr.h>
#include <wchar.h>
#include <util/co_smart_ptr.h>
//содержимое co_smart_ptr.h
//#pragma once
//#include "smart_ptr.h"
//inline void p_add_ref(IUnknown* ptr_)
//{
// ptr_->AddRef();
//}
//inline void p_release(IUnknown* ptr_)
//{
// ptr_->Release();
//}
//те у меня одни и теже смартпоинтеры на все классы с внутренним подсчетом ссылок...#include <boost/noncopyable.hpp>
struct com_initialize
:boost::noncopyable
{
com_initialize(LPVOID pvReserved=NULL)
{
hr=CoInitialize(pvReserved);
}
~com_initialize()
{
if(SUCCEEDED(hr))
CoUninitialize();
}
operator HRESULT()
{
return hr;
}
private:
HRESULT hr;
};
int main(int argc, char **argv)
{
com_initialize com_init;
if(FAILED(com_init))
return 1;
HRESULT hr=S_OK;
///////////////////////////////////////////////////////////////////
// Call CoInitialize to initialize the COM library and then
// CoCreateInstance to get the Task Scheduler object.
///////////////////////////////////////////////////////////////////
ref_t<ITaskScheduler> pITS;
hr=CoCreateInstance
(CLSID_CTaskScheduler
,NULL
,CLSCTX_INPROC_SERVER
,IID_ITaskScheduler
,(void **)ref_accept(pITS)
);
if (FAILED(hr))
return 1;
///////////////////////////////////////////////////////////////////
// Call ITaskScheduler::Activate to get the Task object.
///////////////////////////////////////////////////////////////////
ref_t<ITask> pITask;
LPCWSTR lpcwszTaskName=L"Test Task";
hr=pITS->Activate
(lpcwszTaskName
,IID_ITask
,(IUnknown**)ref_accept(pITask)
);
if (FAILED(hr))
{
wprintf(L"Failed calling ITaskScheduler::Activate: ");
wprintf(L"error = 0x%x\n",hr);
return 1;
}
///////////////////////////////////////////////////////////////////
// Call ITask::CreateTrigger to create new trigger.
///////////////////////////////////////////////////////////////////
ref_t<ITaskTrigger> pITaskTrigger;
WORD piNewTrigger;
hr = pITask->CreateTrigger
(&piNewTrigger
,ref_accept(pITaskTrigger)
);
if (FAILED(hr))
{
wprintf(L"Failed calling ITask::CreatTrigger: ");
wprintf(L"error = 0x%x\n",hr);
return 1;
}
//////////////////////////////////////////////////////
// Define TASK_TRIGGER structure. Note that wBeginDay,
// wBeginMonth, and wBeginYear must be set to a valid
// day, month, and year respectively.
//////////////////////////////////////////////////////
TASK_TRIGGER pTrigger;
ZeroMemory(&pTrigger, sizeof (TASK_TRIGGER));
// Add code to set trigger structure?
pTrigger.wBeginDay =1; // Required
pTrigger.wBeginMonth =1; // Required
pTrigger.wBeginYear =1999; // Required
pTrigger.cbTriggerSize = sizeof (TASK_TRIGGER);
pTrigger.wStartHour = 13;
pTrigger.TriggerType = TASK_TIME_TRIGGER_DAILY;
pTrigger.Type.Daily.DaysInterval = 1;
///////////////////////////////////////////////////////////////////
// Call ITaskTrigger::SetTrigger to set trigger criteria.
///////////////////////////////////////////////////////////////////
hr = pITaskTrigger->SetTrigger (&pTrigger);
if (FAILED(hr))
{
wprintf(L"Failed calling ITaskTrigger::SetTrigger: ");
wprintf(L"error = 0x%x\n",hr);
return 1;
}
///////////////////////////////////////////////////////////////////
// Call IPersistFile::Save to save trigger to disk.
///////////////////////////////////////////////////////////////////
ref_t<IPersistFile> pIPersistFile;
hr = pITask->QueryInterface
(IID_IPersistFile
,(void **)ref_accept(pIPersistFile)
);
hr = pIPersistFile->Save
(NULL
,TRUE
);
wprintf(L"The trigger was created and IPersistFile::Save was \n");
wprintf(L"called to save the new trigger to disk.\n");
return 0;
}
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Так лучше будет(я понятия не имею что этот код делает. просто тупо перебил его на враперы.)
вот и я когда с этим безобразием (TaskScheduler API) столкнулся, первым делом врапперы понаделал
потому что использовать эти функции как есть — это проще повеситься будет
Здравствуйте, alexkro, Вы писали:
A>Здравствуйте, vstrogov, Вы писали:
V>>Здравствуйте, VladD2, Вы писали:
VD>>>Сдается мне, что сей труд написан на днях.
V>>Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где-то назад на редмондовском V>>форуме разработчиков драйверов (в частности в нем участвуют многие ключевые разработчики NT).
A>Ссылочку пожалуйте.
Когда-то давно эти форумы поддерживались Rational как разработчиком одной из серьезнейших файловых систем для NT для ClearCase, с 2000 поддерживаются Open Systems Resources. Де факто мониторят и принимают участие многие ключевые разработчики режима ядра MS.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Shhady, Вы писали:
S>>Я конечно не использую dynamic_cast, темплейтов и эксепшенов, и очень доволен, и использовать не хочеться.
VD>И очень зря. Чертовски полезные вещи. Хотя исключения сделаны (особенно в компиляторах МС) не очень толково. Но уж шаблоны не использовать работая с КОМ-ом — это верх мазохизма. Все же ATL непропьеш.
Ошибся, я использую темплейты только в виде смарт поинтов внутри реализации ATL не использую, стараюсь писать всё самому, чтоб держать всё под контролем ( я просто собаку сЪел, офигивая, почему моя программа глючила, оказалось что глючил mfc со своими недокументированными фичами и ограничениями ( перепишите отрисовку в производном классе от CButton ( или от чего-то там, не помню ), офигенное поведение обеспечено ). Исключения то же юзаю, но по маленькому и чтоб они не вырывались за пределы класса. Но я это всё использую по минимуму и не фигачу метапрограммирование.
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, VladD2, Вы писали:
VD>Ты будешь смеяться, но в 2001 Шарпа тоже небыло. Он появился в 2002. _>>смешно.. _>>я лично программировал в начале 2001 на C# (Beta 2) VD>Значит должен знать, что такое DNA и какие ограничения на треп оно распростроняет. VD>Я программировал еще на пре бете и на бэте 1. И именно по этому могу скзать, что вероятность появления этих слов в 2001 стремится к нулю.
я не понял что ты имеешь в виду — человек писал, что в 2001 C# не было, а я писал, что был.
_>>более того, я использовал С# код, созданный другим разработчиком в 2000
VD>Ну, прям прозводсво каое-то. Хорошо что ты не программировал на супер продукте под названием COM+: VD>http://www.microsoft.com/msj/1197/complus.aspx VD>http://www.microsoft.com/msj/1297/complus2/complus2.aspx VD>
Здравствуйте, Maxim S. Shatskih, Вы писали:
SS>Прятать мелочи — глупо. Баги будут именно в них. The devil is in the details. Потому имеет смысл выставить эти детали бесстыдно наружу, чтобы быстрее баг увидеть, если он там есть.
Ага. Чтобы чаще об них спотыкаться. Лучше один раз сделать чтобы бага не было и спрятать от греха подальше.
Здравствуйте, WolfHound, Вы писали:
WH>Вот тут то и нужен компаил тайм рефлекшен. Чтобы то что нужно я мог сгенерить прямо во время компиляции и именно так как мне надо. А если мне понадобится метаинформация в рантайме то я мог бы ее вытащить причем только для тех классов для которых она мне нужна и ровно столько сколько мне нужно. WH>Единственный адекватный способ создать такой язык это проектирование его с нуля и при этом забив на обратную совместимость с С/С++.
Ну как бы R# уже сейчас показывает что это не обязательно.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Абстракции там получаются очень крупноблочные, скорее как в COMе, а не как в классических ОО языках типа Дельфей, Джавы и Шарпа.
Компонентная модель дотнета в разы более абстрактна нежели СОМ
Здравствуйте, alexkro, Вы писали:
VD>>Не, а мне нравится макдонадльдс. Я им не злоупотребляю. А когда нужно в попыхах перекусить, то это лучше бем пирожок неизвестного качества или наши забегаловки.
A>В Америке и в Москве МакДональдс — это небо и земля.
Кстате, смотрю вы пропагандирует C#, а как насчет производительности? Мы ж вроде в России, и дофига компов с максимум 800 мегагерцовыми пнями ( и это в офисах многих фирм ).
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, AndrewVK, Вы писали:
WH>>Единственный адекватный способ создать такой язык это проектирование его с нуля и при этом забив на обратную совместимость с С/С++. AVK>Ну как бы R# уже сейчас показывает что это не обязательно.
Или кто-то из нас не понял что сказал... Или R# может С++ компилировать?
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Maxim S. Shatskih, Вы писали: MSS>>Сами по себе обертки уже есть детали. Те самые. MSS>>А если баг в обертке где? Ой млиииин... VD>Если баг в обертке, то рано или поздно он будет обнаружен и устранен. А вот если баги (а они будут такими же что и в обертке) разбросаны по коду, то это уже называется "приплыли".
Тут еще есть конфликт между читателями и писателями.
Говорили тут вот про CWaitCursor. Если этот CWaitCursor будет самодельный класс из 4 строчек. О котором читатель не знает, а знает только что такое BeginWaitCursor. Он естействено будет материться на эту обертку когда в первый раз с ней столкнется. "..Вот в документацию лезть пришлось из-за какой-то козявки,в другие файлы лазить , скрытое поведение искать,разбираться, что за маразматик писал...итд"
Особенно если он с ним только один раз в коде столкнется. Ему все равно, что писателю это жизнь облегчило и в 100 местах это применено.
У писателя и читателя (которорому побыстрее хочется разобраться в небольшом обрывке чужого кода) разные цели. Иногда действительно в плоком виде структура быстрее понимается для участка кода. Но читателю можно порекомендовать запустить отладчик с первой строчки кода и прйтись насквозь через все вложеные функции скрытые поведения итд.
Здравствуйте, Shhady, Вы писали:
S>ATL не использую, стараюсь писать всё самому, чтоб держать всё под контролем ( я просто собаку сЪел, офигивая, почему моя программа глючила, оказалось что глючил mfc со своими недокументированными фичами и ограничениями
Может вы просто не умееите их готовить? (собак)
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Silver_s, Вы писали:
S_> Говорили тут вот про CWaitCursor. Если этот CWaitCursor будет самодельный класс из 4 строчек. О котором читатель не знает, а знает только что такое BeginWaitCursor. Он естействено будет материться на эту обертку когда в первый раз с ней столкнется. "..Вот в документацию лезть пришлось из-за какой-то козявки,в другие файлы лазить , скрытое поведение искать,разбираться, что за маразматик писал...итд"
Запросто может быть обратная ситуация, когда читатель знает про класс CWaitCursor, но понятия не имеет про BeginWaitCursor . Например начитается книг: "ХХХ за 10 дней"
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Да? Если вы не сталкивались с приколами mfc, значит вы и не шибко в нём работали. Я имею ввиду глубокую работы ( переписывание отрисовок контроллеров хотя бы ).
Например, как вы, наверное очень опытный программист, раз пишете такие слова, объясните, что у ms контроллов код отрисовки не всегда ( да почти всегда ) не сидит в OnPaint?
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
S>Например, как вы, наверное очень опытный программист, раз пишете такие слова, объясните, что у ms контроллов код отрисовки не всегда ( да почти всегда ) не сидит в OnPaint?
А причем здесь MFC?
Это фича Windows-а — стандартные контролы Windows обрабатывает сама.
VD>>А разве Borland C++ 3.1 был связан с виндовс? Мне казалось он был под дос. AVK>Среда и компилятор были под дос, но компилировать под Win16 он умел.
Нет. И среда, и компилятор были и под ДОС (ТурбоВижн), и под Win16. Причем под Win16 код компилятора был где-то внутри среды, а не CL.EXE пускался, как у микрософта. На компиляции больших проектов иногда валился.
Была UIная библиотека OWL, и к ней визард рисования диалогов. Си++ был расширен личными борландовскими заморочками типа
virtual void OnChar() = WM_CHAR;
Еще была библиотека EasyWin, которая позволяла тупой порт комманд-лайн программ в Win16, определяя printf() так, что создавалось окно, смахивающее на консоль, и туда шла печать.
Другое дело, что отладчика в Win16ой среде не было. Он был только Turbo Debugger (давали с дистрибутом), текстовый ТурбоВижн UI, и требовал для нормальной работы второго монохромного монитора.
S_> Хотя тут скрытого поведения нету. Вот поэтому крупный софт и глючный на основе >низкоуровневых технологий (без скрытого поведения), и лезут через инет на комп >всякие черви через всякие щели.
То-то одна из самых глючных софтин на настоящий момент — написанный на Си++ MSIE.
То-то ядра Windows и юниксов работают хорошо, то-то компиляторы работают хорошо... все на Си
Здравствуйте, Shhady, Вы писали:
S>Да? Если вы не сталкивались с приколами mfc, значит вы и не шибко в нём работали. Я имею ввиду глубокую работы ( переписывание отрисовок контроллеров хотя бы ).
Я вашу квалификацию под сомнение не ставил и вам рекомендую не сомневаться в чужой.
S>Например, как вы, наверное очень опытный программист, раз пишете такие слова, объясните, что у ms контроллов код отрисовки не всегда ( да почти всегда ) не сидит в OnPaint?
А почему он должен там быть?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
AJD>Я вашу квалификацию под сомнение не ставил и вам рекомендую не сомневаться в чужой.
Может вы просто не умееите их готовить? (собак)
Я не буду предираться.
AJD>А почему он должен там быть?
Так думают и программисты в ms.
MSDN по поводу WM_PAINT ( это относитьяс к OnPaint )
Typically, an application draws in a window in response to a WM_PAINT message.
Понятно, что тупикали, ну если сами программисты ms нифига не тупикали обрабатывают отрисовку черт знает где ( сорсов же контроллов нет ), то как это расценивать? Если это документированная ( хорошо, могу согласиться, они же сами пишут "тупикали" ) и ожидаемая реализация отрисовки, то я пас.
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Нет. И среда, и компилятор были и под ДОС (ТурбоВижн), и под Win16. Причем под Win16 код компилятора был где-то внутри среды, а не CL.EXE пускался, как у микрософта. На компиляции больших проектов иногда валился.
Ты что то путаешь. IDE под винды появилось только в 4.0.
MSS>Была UIная библиотека OWL, и к ней визард рисования диалогов.
Здравствуйте, WolfHound, Вы писали:
WH>Это я могу и сейчас... читаем дебугинфо и... сам не пробовал но кто-то на форуме говорил что у него это работает. WH>Но это не переносимо
Я бы сказал изжогу вызывает. Вообще-то есть ОпенС++ с вроде как полноценным парсером. Тогда уж лучше его использовать.
WH>Кроме мейнстрейма для которого .НЕТ и ему подобные пожалуй лучший выбор есть и будут области программирования где нужен zero overhead language те что не использую за то не плачу.
Ну, zero overhead даже на ассемблере не бывает. Реально речь идет о процентах. Как я уже не раз говорил проигрыш в два раза легко компенсируется высобожденым временем которое можно потратить на оптимизацию алгоритмов. А те в свою очередь дают куда блоший чем двухкратный выигрыш.
Другое дело, что есть драйверы и т.п. Вот их конечно придется делать на С/С++. Как видишь, даже можно поспорить на чем из них луше. Задачи же более менее прикладные легко преводить на дотнет. Если что проблемы вставить пару строк на анменеджед-С++ особого труда не составит.
WH>Вот тут то и нужен компаил тайм рефлекшен. Чтобы то что нужно я мог сгенерить прямо во время компиляции и именно так как мне надо.
Ну, как я тебе уже сказал по большому счету пофику какой он.
WH>...создать такой язык это проектирование его с нуля и при этом забив на обратную совместимость с С/С++.
Ну, я бы все же лучш дополнил существующий.
WH>К стати. У тебя есть конкретные идеи по выделеной части? WH>
WH>8. Отсуствие системы автоматического контроля памяти, или механизма позволяющего гладко интегрировать такой механизм на уровне библиотеки.
В смысле как это можно было бы интегрировать в С++? Или вообще?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ilya_ny, Вы писали:
_>я не понял что ты имеешь в виду — человек писал, что в 2001 C# не было, а я писал, что был.
Человек — это был я. Так вот официально С# вышел в 2002 году. Его бетатестирование было закртытым и сотрудник МС распространяться про него да еще так вольготно словно о нем все давно знают в 2001 попросту не мог. Его а) никто бы не понял, б) выгнали бы с работы.
VD>>Ну, прям прозводсво каое-то. Хорошо что ты не программировал на супер продукте под названием COM+: VD>>http://www.microsoft.com/msj/1197/complus.aspx VD>>http://www.microsoft.com/msj/1297/complus2/complus2.aspx VD>>
_>я программировал.. а тут в чем подвох ?
Тем что это и есть дотнет. И программировать на нем ты мог, только если ты работал в то время в команде его разработки.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shhady, Вы писали:
S>Кстате, смотрю вы пропагандирует C#, а как насчет производительности? Мы ж вроде в России, и дофига компов с максимум 800 мегагерцовыми пнями ( и это в офисах многих фирм ).
На этом сайте есть три статья посвязенные в том числе и этому вопросу. Если в двух словах, то нормально. На супер-новых С++-компияторах можно достичь лучших результатов, но долеко не всгда и ценой несравнимо больших трудозатрат. Целочисленная арифметика вообще мало отличима по скорости, плавающая точка малость отстает. Отстает так же работа со ссылочными типами и большими объемами памяти. За-то писать проще на порядок. И свободное время можно псвящать оптимизации алгоритмов. А это дает реальный выигрыш. Наш R# парсит C#-код как минимум не медленнее МС-ного компилятора. А если сравнивать с ихним парсером используемым для рефактоинга, то наш значительно быстрее.
800 Mz вообще не проблема. Код все же компилируется. Вот к памяти требования по выше. Но на сегодня это уже не проблема.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Silver_s, Вы писали:
S_> Тут еще есть конфликт между читателями и писателями. S_> Говорили тут вот про CWaitCursor. Если этот CWaitCursor будет самодельный класс из 4 строчек. О котором читатель не знает, а знает только что такое BeginWaitCursor. Он естействено будет материться на эту обертку когда в первый раз с ней столкнется. "..Вот в документацию лезть пришлось из-за какой-то козявки,в другие файлы лазить , скрытое поведение искать,разбираться, что за маразматик писал...итд" S_> Особенно если он с ним только один раз в коде столкнется. Ему все равно, что писателю это жизнь облегчило и в 100 местах это применено.
Сдается мне, что CWaitCursor и по названию пекрасно отражает свое предназначение. И если сравнить объем решенным им проблем (отсуствие необходимости вставлять какй-нить EndWaitCursor), то становится очевидным, что CWaitCursor резко упрощает и чтение, и отладку, и написание. Это особенно верно для С++ в котором нет finally.
S_> У писателя и читателя (которорому побыстрее хочется разобраться в небольшом обрывке чужого кода) разные цели. Иногда действительно в плоком виде структура быстрее понимается для участка кода. Но читателю можно порекомендовать запустить отладчик с первой строчки кода и прйтись насквозь через все вложеные функции скрытые поведения итд.
Если для понимания кода его нужно проходить в отладчике — то это плохой код. И пофигу что к этому приводит. Награмождение же совершенно лишних деталей приводит к этому ни чуть не меньше. Логичность и простота кода — это несомненные приемущества, но они никак не зависят от наличия или отсуствия скрытого поведения. Они зависях от лоигичности и качества проектирования. И от соблюдения некого кодекса безапастного програмирования.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вопрос прямизны рук.
Это точно.
MSS>Мерзость врапперов в том, что они из всем известного системного API делают что-то хрен знает какое.
Кому мерзость... А я на пример не хочу КАЖДЫЙ раз лезть в MSDN когда мне надо что-то сделать.
А грамотно писаные враперы интуитивно понятны.
MSS>В известных мне командах в Москве при виде враппера вокруг ReadFile подумали бы — "маньяааааак" — и точно на работу бы не взяли.
Врапер вокруг ReadFile не имеет смысла. А вот высоко уровневая надстройка над файлами очень даже имеет.
MSS>Враппер ничего не скрывает. Как была CreateFile, так и осталась.
Этот от врапера зависит. std::ifstream тоже в конце концов в CreateFile упирается но из его интерфейса это видно?
WH>>Вот только там надо не забыть закрыть фаил... А это геморой. MSS>Правда что ли?
Если бы было не правда то всякая мерхость типа BoundsCheckr'а была бы не нужна.
MSS>Правда что ли? а если это качаемый с HTTP поток? Сериализация из такого потока возможна? да. Ну и на кой требовать произвольный доступ для сериализации?
При чем тут это? Я говорю об абстракции потока в который можно и читать и писать.
Поток из которого можно только читать это я понимаю, поток в который можно только писать я тоже понимаю но поток в который можно и писать и из него читать это маразм.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Гы! У MSа давно есть свои собственные коды. %p, например. Печатает пойнтер. 64бита на Win64, 32 бита на Win32.
Почему у MS?
Не далее чем вчера под пингвином так указатли распечатывал.
WH>bool write_some_in_file1(char const* name)
WH>{
WH> HANDLE file=CreateFile//Когда я первый раз пытался с помощью Win32API пытался прочитать фаил я долго искал OpenFile...
WH> (name//Для того чтобы заполнить параметры функции мне пришлось лезть в MSDN.
WH> ,GENERIC_WRITE
WH> ,0
WH> ,0
WH> ,CREATE_ALWAYS
WH> ,0
WH> ,0
WH> );
WH> if(file==INVALID_HANDLE_VALUE)//За этим мне тоже пришлось лезь в MSDN ибо иногда не валидный хендел NULL и иногда INVALID_HANDLE_VALUE
WH> return false;
WH> DWORD bytes=0;
WH> bool res=WriteFile//И опять таки без MSDN не обошлось
WH> (file
WH> ,name
WH> ,strlen(name)
WH> ,&bytes
WH> ,0
WH> );
WH> CloseHandle(file);
WH> return res;
WH>}
WH>
Во блин... Я даже не понял, что этот код делает...
И чему меня только в институте учат?
Что нужно было сделать? Проверить, можно ли в файл записать?
Это если я конечно ничего не путаю насчёт возвращаемого значения printf'а.
Кто может объяснить, чем первая реализация радикально лучше второй?
Про вторую, например можно сказать, что она
1) очевидна
2) не использует посторонних относительно языка библиотек
3) кроссплатформенна
А первая чем хороша?
Это не стёб, а искренний вопрос второкурсника, который пришёл в ужас от того, как мало он знает...
A>Во блин... Я даже не понял, что этот код делает... A>И чему меня только в институте учат?
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>
A>Это если я конечно ничего не путаю насчёт возвращаемого значения printf'а.
A>Кто может объяснить, чем первая реализация радикально лучше второй? A>Про вторую, например можно сказать, что она A>1) очевидна A>2) не использует посторонних относительно языка библиотек A>3) кроссплатформенна A>А первая чем хороша? A>Это не стёб, а искренний вопрос второкурсника, который пришёл в ужас от того, как мало он знает...
просто придирка : try — зарезервированое слово и если функция возвращает bool, надо возвращать bool
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, VladD2, Вы писали:
VD>Ну, zero overhead даже на ассемблере не бывает.
zero overhead это по сравнению с асмом.
VD>Реально речь идет о процентах. Как я уже не раз говорил проигрыш в два раза легко компенсируется высобожденым временем которое можно потратить на оптимизацию алгоритмов. А те в свою очередь дают куда блоший чем двухкратный выигрыш.
Ты о чем? У C# на алгоритмических задачах как минимум нет преймуществ перед С++.
VD>Другое дело, что есть драйверы и т.п. Вот их конечно придется делать на С/С++. Как видишь, даже можно поспорить на чем из них луше.
Проблема в том что это "и т.п." имеет очень не маленкий обьем... На пример у меня в городе в основном этот самый "и т.п." И туда назрел новый язык. С просто не выдерживает ни какой критики, да и в С++ хватает проблем. Хотя если писать на С++ грамотно то проблемы не возникают. VD>Задачи же более менее прикладные легко преводить на дотнет. Если что проблемы вставить пару строк на анменеджед-С++ особого труда не составит.
Не спорю.
VD>Ну, я бы все же лучш дополнил существующий.
Дополнять существующий очень сложно. Да и проблем в нем хватает... Взять хотябы A Little Detail in Overload 60
Про Сишные маразмы я вобще молчу.
VD>В смысле как это можно было бы интегрировать в С++? Или вообще?
Что либо интегрировать в С++ врятли получится. Хотелось бы вобще.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>Я не буду предираться.
Там еще смайлик был . В любом случае я не хотел сказать ничего плохого.
AJD>>А почему он должен там быть? S>Так думают и программисты в ms.
S>MSDN по поводу WM_PAINT ( это относитьяс к OnPaint ) S>
S>Typically, an application draws in a window in response to a WM_PAINT message.
S>Понятно, что тупикали, ну если сами программисты ms нифига не тупикали обрабатывают отрисовку черт знает где ( сорсов же контроллов нет ), то как это расценивать? Если это документированная ( хорошо, могу согласиться, они же сами пишут "тупикали" ) и ожидаемая реализация отрисовки, то я пас.
Хорошо, а если мне надо вывести контрол на печать или еще куда(в метафайл)? WM_PAINT в данной ситуации не прийдет просто, хотя рисование тоже самое. Поэтому вполне логично, вынеси это все в отдельную функцию на вход которой передается настроенный соответсвенно девайс контекст. И этой функции глубоко начхать в какой девайс контекст рисовать: в экранный или принтерный. Имхо как раз в этой ситуации все правильно.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ilya_ny, Вы писали:
_>>я не понял что ты имеешь в виду — человек писал, что в 2001 C# не было, а я писал, что был.
VD>Человек — это был я. Так вот официально С# вышел в 2002 году. Его бетатестирование было закртытым и сотрудник МС распространяться про него да еще так вольготно словно о нем все давно знают в 2001 попросту не мог. Его а) никто бы не понял, б) выгнали бы с работы.
microsoft в 2000, 2001 гг рассылал диски с Visual Studio.NET RC1, RC2...
я даже помню, что они были белого цвета
и при чем тут закрытое тестирование вообще
VD>>>Ну, прям прозводсво каое-то. Хорошо что ты не программировал на супер продукте под названием COM+: VD>>>http://www.microsoft.com/msj/1197/complus.aspx VD>>>http://www.microsoft.com/msj/1297/complus2/complus2.aspx VD>>>
_>>я программировал.. а тут в чем подвох ?
VD>Тем что это и есть дотнет. И программировать на нем ты мог, только если ты работал в то время в команде его разработки.
COM+ — это то, что было еше под Windows NT — только устанавливалось отдельно — называлось MTS
может внутрене .NET и реализован с использованием COM+ технологии, но так это совсем разные вещи
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Shhady, Вы писали:
S>>Я лично ждал ответа, а не флейма. И что вы хотели этим сказать?
AVK>То что не стоит выдавать это за сокровенное знание и жуткий профессионализм.
Я что-то не понимаю, если вы неправы, то что, сложно это признать? А не ходить до окола.
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, AndrewJD, Вы писали:
AJD>Хорошо, а если мне надо вывести контрол на печать или еще куда(в метафайл)? WM_PAINT в данной ситуации не прийдет просто, хотя рисование тоже самое. Поэтому вполне логично, вынеси это все в отдельную функцию на вход которой передается настроенный соответсвенно девайс контекст. И этой функции глубоко начхать в какой девайс контекст рисовать: в экранный или принтерный. Имхо как раз в этой ситуации все правильно.
Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar? Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?
Ну ладно, это чисто офф
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, SWW, Вы писали:
MSS>>Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, ничтоже сумняшеся, херит его. Программа перестает работать. Что за бред? -- оказывается, конструктор этой переменной устанавливает связь с Exchange'ем (реальный пример из Аутлука). Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но -- что написано пером, не вырубишь топором.
SWW>А я иногда создаю переменную типа CWaitCursor и нигде ее не использую. Похоже, меня тоже скоро уволят.
MSS
1. можно херить простые переменные, которые нигде (int, char, double) не используются, а не объекты — что твой же пример и доказывает
2. что же это за программист, который так херит ничтоже сумняшеся?? может это его надо увольнять ?
3. может если переменная или класс имеет осмысленное имя — ExchangeConnect, например, то ее просто так и не захерят ?
Здравствуйте, Maxim S. Shatskih, Вы писали:
S_>> Хотя тут скрытого поведения нету. Вот поэтому крупный софт и глючный на основе >>низкоуровневых технологий (без скрытого поведения), и лезут через инет на комп >>всякие черви через всякие щели.
MSS>То-то одна из самых глючных софтин на настоящий момент — написанный на Си++ MSIE.
MSS>То-то ядра Windows и юниксов работают хорошо, то-то компиляторы работают хорошо... все на Си
Максим, ну не надо передёргивать. Я думаю, все прекрасно знают, что качество продукта определяется качеством программистов, его писавших. Проза жизни в том, что даже Майкрософт не в состоянии укомплектовать свой штат программистами хотя бы среднего уровня.
Здравствуйте, AndrewJD, Вы писали:
S>>Ничего не понимаю, конечно это удобно, и я так делаю, но где эта функция зарыта в CScrollBar?
AJD>Нигде эта функция не зарыта. Ее вообще нет . MFC не рисует скролбары — их рисует винда.
нее... Вы меня не понимаете вообще, ладно, пойдем по другому: как переписать отрисовку скроллбара?
S>> Логично было бы, что в OnPaint,но это не то, при дефолтном состоянии, всё чики пуки, начинаем кликать, проявляется оригинальная отрисовка — это нормальное по вашему поведение?
AJD>Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары которые есть у каждого окна — то тут немного нужно поплясять с бубном. Но к MFC это никакого отношения не имеет.
Про стандартные я вообще молчу, это действительно жопа. Ну-ну, попробуйте в производном классе от CScrollBar поперехватывать сообщение wm_paint, ехидство тут же поубавиться, гарантирую.
Хорошо, если считать mfc обертку воокруг winapi, тогда все мои претензии относиться к winapi, но сути это не меняет.
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, 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>
Здравствуйте, Maxim S. Shatskih, Вы писали:
NA>>При грамотном проектировании на C++ кода будет меньше, чем на C. NA>>Одна из хороших черт ООП: инкапсуляция. Если классы правильно NA>>реализованы и документированы, то разобраться что делает код можно NA>>быстрее, чем на C.
MSS>Угу. На Си делается то же самое, путем использования слова static перед именем функции.
И действует только в пределах модуля.
На C можно сэмулировать практически любую ООП конструкцию, вопрос только в трудозатратах. На C они в несколько раз выше. Причём увидеть суть происходящего — гораздо сложнее. Код оказывается перегружен кучей технических деталей, вроде таблиц указателей не функции, прекрасно иллюстрирующие ход процесса — в малейщих деталях, но скрывающих его суть.
Эмуляция ООП на C — прекрасный способ обучать начинающих ООП — так как позволяет показать в малейших деталях — как работает та или иная конструкция ООП — как раз те самые технические детали — которые и важны для понимания того, что происходит в недрах программы на ООП языке, где эти детали скрыты.
C — прекрасный язык для того, что бы иллюстировать ход, детали процесса, а С++ — прекрасный язык для иллюстрации смысла процесса.
Вероятнее всего для Вас — важнее детали процесса, или же смысл процесса заключается в деталях. Такие взгляды довольно распространены среди системных программистов.
Здравствуйте, vstrogov, Вы писали:
V>Здравствуйте, alexkro, Вы писали:
A>>Здравствуйте, vstrogov, Вы писали:
V>>>Здравствуйте, VladD2, Вы писали:
VD>>>>Сдается мне, что сей труд написан на днях.
V>>>Нет, не на днях. Максим уже публиковал этот текст в английском переводе пару лет где-то назад на редмондовском V>>>форуме разработчиков драйверов (в частности в нем участвуют многие ключевые разработчики NT).
A>>Ссылочку пожалуйте.
V>Можно найти в архивах www.osronline.com
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... _>я даже помню, что они были белого цвета _>и при чем тут закрытое тестирование вообще
Здравствуйте, ilya_ny, Вы писали:
VD>>Тем что это и есть дотнет. И программировать на нем ты мог, только если ты работал в то время в команде его разработки. _>COM+ — это то, что было еше под Windows NT — только устанавливалось отдельно — называлось MTS _>может внутрене .NET и реализован с использованием COM+ технологии, но так это совсем разные вещи
Здравствуйте, Astaroth, Вы писали:
A>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Гы! У MSа давно есть свои собственные коды. %p, например. Печатает пойнтер. 64бита на Win64, 32 бита на Win32.
A>Почему у MS? A>Не далее чем вчера под пингвином так указатли распечатывал.
Скорее — новые крос-платформенные коды для поддержки 64 битных платформ...
Здравствуйте, 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, и зачем вокруг него врапперы плодить?
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> Это стандартная задача, этому посвящено очень много статей и литературы.
В данном случае, не стоило изобретать велосипед, а стоило хоть один раз прочитать хорошую статью, которая рассказывает, как это делается.
Стандартная? Ну дай мне ссылку на "стандартную" статью, где изменяется отрисовка у скролбара.
Вы кстате противоречите самому себе, у вас логика не страдает? То вы пишете, что это фича винда, изменить нельзя, то теперь, что это "страндартная" задача...
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
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.
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>
A>Это если я конечно ничего не путаю насчёт возвращаемого значения printf'а.
Если в файл нельзя писать, то fopen вернет NULL
fprintf обломается только от переполнения тома, или от того, что винчестер сыпаться начал.
AF> Почему же сказок? Человеку надо видеть что ему править. Мысль о том, что код может не содрежать примитивных ошибок — вроде незакрытого вовремя дескриптора, а содержать ошибки концептуальные, семантические — в голову видимо не приходит...
Си++ от них никак не гарантирует. Тут надо иметь голову, и если ее нет — ни один язык не поможет.
А то, что человеку надо видеть то, что он делает — вот пример. Казалось бы — прекрасная идея — написать объект, который будет брать лок в конструкторе, и отдавать в деструкторе. Локи все вовремя отдадутся типа
Ан нет. Нет визуальной подсказки о том, что лок отдали. Только закрывающая фигурная скобка. В итоге увеличиваются шансы запутаться в том, в каком именно месте кода отдается лок.
AF> Вероятнее всего для Вас — важнее детали процесса, или же смысл процесса заключается в деталях. Такие взгляды довольно распространены среди системных программистов.
AJD>Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары
Кстати, их наличие — равно как и вообще концепция nonclient area — одна из мерзейших фич USERа.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AJD>>Если мы говорим про контролы с классом SCROLLBAR — то перехват сообщений WM_PAINT, WM_NCPAINT спасет отца русской демократии. Если же говорим про стандартные скролбары
MSS>Кстати, их наличие — равно как и вообще концепция nonclient area — одна из мерзейших фич USERа.
Почему?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Дык не в этом вопрос. Можно и fstream заюзать.
Вопрос в том, чем этот подход (fopen/fstream) радикально хуже того ужаса, что был процитирован выше — с какими-то хэндлами и прочими вкусностями?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Вернемся к SMART (протокол съема с ИДЕ винчестера инфы о том, как скоро он посыпется). Человек написал ради этого класс. Зачем? Три вызова — CreateFile, DeviceIoControl, CloseHandle. Вот зачем там — класс?
чтобы не вызывать каждый раз вручную этот самый CloseHandle
Девять раз программер его напишет, на десятый точно забудет
И вообще — ну пусть класс. Что от этого плохого будет?
Только не надо снова про перегруженные операторы и виртуальные функции. В данном случае появление в классе таких "зверей" — это уже клиника, и от языка не зависит.
MSS>Про драйвера. Задумался вчера всерьез над темой "Си++ в драйверах", и получилось вот что. Там некое количество внешних структур, с которыми приходится работать, и которые приходят извне. Ну и толку будет оборачивать NDIS_PACKET в класс? Что это даст-то? Взаимодействие с окружающей ОС все равно делается в терминах NDIS_PACKET, и зачем вокруг него врапперы плодить?
Вот и надо было сказать просто: "весь остальной код написан на С по историческим причинам, поэтому применение C++ во взаимодействии с ним дает мало пользы"
Здравствуйте, Maxim S. Shatskih, Вы писали:
AF>> Почему же сказок? Человеку надо видеть что ему править. Мысль о том, что код может не содрежать примитивных ошибок — вроде незакрытого вовремя дескриптора, а содержать ошибки концептуальные, семантические — в голову видимо не приходит...
MSS>Си++ от них никак не гарантирует. Тут надо иметь голову, и если ее нет — ни один язык не поможет.
MSS>А то, что человеку надо видеть то, что он делает — вот пример. Казалось бы — прекрасная идея — написать объект, который будет брать лок в конструкторе, и отдавать в деструкторе. Локи все вовремя отдадутся типа
MSS>Ан нет. Нет визуальной подсказки о том, что лок отдали. Только закрывающая фигурная скобка. В итоге увеличиваются шансы запутаться в том, в каком именно месте кода отдается лок.
Очень напоминает аргумент конца 70-х против {}. Тогда на полном серьёзе писались научные статьи, доказывающие — примерно с такой же аргументацией, что без BEGIN ... END код вообще писать нельзя, что мол {} никто не заметит и {} — главный источник ошибок...
То же самое и здесь.с локами. Брать новичка, который не имеет представления об ОСНОВАХ языка (а то, что автоматические переменные уничтожаются при выходе из блока — очевидные основы) и отдавать ему написание многопоточного кода — будет грубейшей ошибкой. Потому, как он и на C ужас что напишет — и ещё не известно — где страшнее.
Я видел кучу кода а-ля:
Ну да, править тут ошибку — очень легко, но зачем? Использовался бы здесь класс обёртки — вопроса бы не возникло.
Так что мы таки приходим к естественному выводу — дело в мастерстве, а не в языке...
Здравствуйте, Maxim S. Shatskih, Вы писали:
AF>> Вероятнее всего для Вас — важнее детали процесса, или же смысл процесса заключается в деталях. Такие взгляды довольно распространены среди системных программистов.
MSS>Да, про меня это утверждение верно.
Отсюда и спор с большинством на форуме. Для Вас скорее всего в записи:
CFile obFile;
obFile.Open( "Somefile" );
— Будет важнее всего, какими клонкретно системными вызовами был открыт файл, какие дескрипторы безопасности были переданы, сколько вызовов и в какой последовательности было сделано. Поэтому необходимость лезть внутрь обёртки и разбираться со всем этом — вас раздражает. У большинства же интересы диаметрально противоположны. Гораздо интереснее не детали того, как открыватся файл — а сам факт его открытия и дальнейшие действия — причём опять таки их суть, а не детали...
S>Про 1) S>Если это такая уж фича Windows, как вы это представляете (типа святая), то откуда например у CListCtrl функция DrawItem, позволяющая самому инжектить отрисовку?
Неправильный вывод. Она не "святая", она просто есть, об этом надо знать, и чуть по другому менять отрисовку.
DG>> Это стандартная задача, этому посвящено очень много статей и литературы. S>В данном случае, не стоило изобретать велосипед, а стоило хоть один раз прочитать хорошую статью, которая рассказывает, как это делается.
S>Стандартная? Ну дай мне ссылку на "стандартную" статью, где изменяется отрисовка у скролбара.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Про драйвера. Задумался вчера всерьез над темой "Си++ в драйверах", и получилось вот что. Там некое количество внешних структур, с которыми приходится работать, и которые приходят извне. Ну и толку будет оборачивать NDIS_PACKET в класс? Что это даст-то? Взаимодействие с окружающей ОС все равно делается в терминах NDIS_PACKET, и зачем вокруг него врапперы плодить?
Все таки чем ближе к ядру тем там жарче, тем большее количество мелочей становятся важными, тем сложнее их инкапсулировать, и окружающая среда там истончается. Да возможно там другие приемы проектирования и оформления кода нужны.
Но все таки я настаиваю что для прикладного уровня, какая нибудь примитивная задачка удаления файлов в текущей директории должна выглядеть примерно так
foreach(string s in Directory.GetFileSystemEntries(Directory.GetCurrentDirectory(),"*.tmp"))
File.Delete(s);
Вот так она и выглядит yf С#. Просто но со вкусом, как видится так и делается. Делается незначительная мелочевка, она и в программе секунды занимает чтобы понять что там делается, и что там нет никакого скрытого поведения. Какие там будут извращения на С, без OOP чтобы это сделать через WinAPI.
Но я в принципе не настаиваю чтобы самые глубокие внутренности ядра выглядели и оформлялись примерно так:
class OperatingSystemWin2K
{
static void Main()
{
if(Hardware.Processors.Count<1)
throw new WrongProccessorCountException();
if(Hardware.Processors[0].Family.Name!="x86")
{
Console.WriteLine("Wrong proccessor");
Hardware.Processors[0].Reset();
return;
}
if(!Hardware.Processors[0].IsInProtectedMode)
{
try
{
Hardware.Processors[0].IsInProtectedMode=true;
}
catch
{
Console.WriteLine(" Can not switch to protected mode");
Hardware.Processors[0].Reset();
return;
}
//.........
}
}
};
Это было бы конечно круто. Но есть подозрения что возникли бы небольшие проблемы с некоторыми мелочами.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Так маразм-то — спецификация throw().
А я спорю? Я же назвал это проблемой... Но это фигня по сравнению с граблями которые достались от С. MSS>Кому она нужна-то? излишество, загромождающее код,
Ни кому. MSS>и одна из самых бесящих вещей в Джаве, где она обязательна, в отличие от Си++. .NET и исключения
MSS>Кто-нить реально пользуется этой фичей Си++?
Сомневаюсь MSS>И каким боком из деструктора делается то, что может возбудить ситуацию? Там что, делается то, что может обломиться? Сразу откровенный маразм.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Astaroth, Вы писали:
A>Дык не в этом вопрос. Можно и fstream заюзать. A>Вопрос в том, чем этот подход (fopen/fstream) радикально хуже того ужаса, что был процитирован выше — с какими-то хэндлами и прочими вкусностями?
Для тебя ни чем.
Просто при работе на прямую с виндовыми файлами можно спроецировать фаил в память, производить асинхронное чтение/запись...
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Чем он лучше? FILE и fopen просто синтаксически красивее, чем эта бредятина с кучей ::.
Ты хотел сказать привычнее.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S_> Все таки чем ближе к ядру тем там жарче, тем большее количество мелочей становятся важными, тем сложнее их инкапсулировать, и окружающая среда там истончается.
Ну да. Так и есть. Если мне надо проимплементировать функцию, которая зовется извне, и у которой сигнатура:
— то как-то стремно там в ней оборачивать PIRP в класс. Хотя и можно, наверное. К слову, возврат NTSTATUS отсюда — это еще один грубый misdesign Майкрософта, вслед за INVALID_HANDLE_VALUE. Там было бы достаточно BOOLEAN.
S_> Но все таки я настаиваю что для прикладного уровня, какая нибудь примитивная задачка удаления файлов в текущей директории должна выглядеть примерно так S_>[c#] S_>foreach(string s in Directory.GetFileSystemEntries(Directory.GetCurrentDirectory
Для прикладного уровня — конечно. Можно даже проще. Вот так
for $name(`ls`)
{
...
}
Очень, очень многие программы прикладного уровня стоит писать на этом языке удивительно могучий. Надо текущее состояние файрволла? — пожалуйста:
for $rule(`ipfw show`)
{
...
}
Не надо даже знать, что такое IOCTL, не надо писать классовый враппер вокруг IOCTLей для файрволла. Все проще. И файлы там открываются в том же синтаксисе, что редиректы командной строки. У нас будет
open MYFILE, "ls -l |";
вместо Сишного popen(). Очень хороший язык. Для мелочевки особенно. Один недостаток — по читабельности кода худший
S_> Но я в принципе не настаиваю чтобы самые глубокие внутренности ядра выглядели и оформлялись примерно так: S_>[c#] S_>class OperatingSystemWin2K S_>{ S_> static void Main() S_> { S_> if(Hardware.Processors.Count<1) S_> throw new WrongProccessorCountException();
>вас раздражает. У большинства же интересы диаметрально противоположны. Гораздо >интереснее не детали того, как открыватся файл — а сам факт его открытия и дальнейшие >действия — причём опять таки их суть, а не детали...
Ну, если что-то надо на коленке сляпать, да побыстрее — то, наверное, да. Для таких вещей Перл хорош, например
S>Если это такая уж фича Windows, как вы это представляете (типа святая), то откуда например у CListCtrl функция DrawItem, позволяющая самому инжектить отрисовку?
Потому что USERовский класс LISTBOX поддерживает owner draw в MFC же этой поддержкой воспользовались.
Вывод: нефиг трогать MFC, не зная USERа. Всегда надо знать детали того, с чем работаешь, иначе будешь в глупые положения попадать.
S>Стандартная? Ну дай мне ссылку на "стандартную" статью, где изменяется отрисовка у скролбара.
Надо унаследовать свой класс от CButton, в нем завести обработчик OnPaint, и просубклассить кнопку этим своим классом. Иначе же WM_PAINT пропускается в родную WndProc класса BUTTON, которая сидит в USER32.DLL, и ее не откастомайзишь.
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, и так, и так)
и т.д. и т.п.
Поэтому в прикладной программе, как раз хочется иметь весь функционал, который содержится в стандартных программах, но при этом без лишних неявных зависимостей.
Именно, для этого и пишут классы, и обертки.
Здравствуйте, Maxim S. Shatskih, Вы писали:
>>новые интелектуальные 3D интерфейсы сладящие за нашими глазами, дыханием, биотоками, понимающими нашу речь MSS>Все, дальше не надо пошла научная фантастика.
Ладно не буду. Вернее буду чуть-чуть , специально для тех кто застрял в прошлом.
Это не фантастика, а реально работающие прототипы, демострируемые на выстаках. Некоторые системы — слежение за хрусталиком глаза, и другой биометрией в т.ч. биотоками, давно используются военными и эту фантастику уже продают, правда за большие деньги.
С 3D интерфейсами эксперементируют давно. Но скорее всего официальной вехой развития будет Windows Longhorn, для которого 3D будет родным интерфейсом. Эта фантастика уже есть, и надо просто иногда смотреть новости, чтобы увидеть, нет не рождение, которое уже было, а становление.
Хотя я понимаю — для некоторых С++ и в половинном объёме спецификаций тоже недостижимая фантастика
Здравствуйте, 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() — со мной и сторонники этого языка согласились
>этом широко используемыми резульататами И что удивительно — почему то абсолютное >большинство проектов — именно в этой прослойке. Вот там то и рулит C++, а с >недавнего времени — C#.
Здравствуйте, 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 хотели применить тот же подход.
Но что-то не срослось...
Здравствуйте, 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 очевидно. А вот зачем этот рудимент тут...
Здравствуйте, 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 используют как правило те, у кого зарплата больше, хотя это и локальная закономерность замеченная мной
Можно узнать зачем ты использовал спецификацию исключений?
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Можно узнать зачем ты использовал спецификацию исключений?
Извините, начну с самого дна.
Надеюсь никто не отрицает пользу исключений, поддерживаемых аппаратно. Это нормальный способ передачи сообщений на верх. Хотя некоторых пугает слово "исключение".
Сейчас С++ поддерживает гибкую систему работы с исключениями — передача объекта класса исключения на верх и вызов деструкторов автоматических объектов.
Большей частью мы использовали throw() для повышения самодокоментируемости кода. Если функция может вызвать штатное исключение, то это должно быть описано. В купе с модификатором const и другими подобными вещами, информация в заголовке функции несёт пользу для человека, использующего эту функцию в своём коде. А спецификация С++ следит за корректность использования throw().
К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций, или для автоматической генерации кода обработки исключения. А также всякими профайлерами и CASE средствами.
Флаг вот только в руки реализовывать __CxxFrameHandler в ядре. На DISPATCH_LEVEL же это вообще невозможно, потому как exceptions основаны на thread local storage (сегмент FS), а на DISPATCH_LEVEL это понятие размыто. Запачкаешь FS:[0] какой-то нити, спасибо за это никто не скажет
Еще нюанс. После NdisSend пакет нам не принадлежит. Надо не забыть занулить поле в классе, чтобы деструктор по выходу из блока не решил уничтожить не-принадлежащий нам пакет. В итоге сложности вырастают, они всего лишь заталкиваются внутрь враппера.
Еще нюанс. Написание враппера вокруг обоих структур, а потом еще и "кода по делу" — дольше будет.
B> Большей частью мы использовали throw() для повышения самодокоментируемости кода. Если >функция может вызвать штатное исключение, то это должно быть описано. В купе с
По опыту Джавы могу рассказать, что будет.
Будет ограничение на то, что можно звать из данного метода. Для его обхода придется оборачивать вызов в try/catch, и _преобразовывать exception одного класса в exception другого_. А вот больший маразм и представить себе сложно. Совершенно лишний код, и некрасивый, и не подходит ни под одну нормальную концепцию, и дела не делает.
Честно говоря, хорошие exceptions в OLE Automation. Код ошибки и строка. И все. Хватит. На кой черт нужны _классы_ exceptions?
MSS>>Классы таким людям давать писать нельзя им можно только давать юзать чужие AF> Так так и поступают — дают им чужие классы, да ещё с примерами использования...
Кстати, да.
На Си++ вполне возможен стиль кодирования, не сильно удаленный от Бейсика. Сочетание _com_ptr_t вместо Object, _bstr_t вместо String, и std::vector для массива.
Бизнес-логику на таком писать — одно удовольствие. У меня был на таком написан вебмейл, помнится.
При этом сохраняются преимущества языка низкого уровня — весь API доступен без проблем.
Вот на таком, с позволения сказать, "диалекте" Си++ — можно и лохам давать писать.
AF> У профи редко. А у программиста — шамана, который изучает системы методом научного >тыка — сплошь и рядом... Кроме того, такое сплошь и рядом встречается при плохом >проектировании, что тоже бывает довольно часто...
При плохом проектировании другой гимор. Обычно в виде сложности с развитием кода. А баги все исправить можно и в плохо спроектированном коде (USER тому пример).
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Например, энумами пользуются для объявления побитовых флагов. Такой запрет разрушит это использование.
В C++ (не помню, как в C) битовые флаги через enums делаются ущербно, именно с использованием явного приведения целого к enum:
enum test {one = 1, two = 2};
test t = one | two; // так нельзя, надо (test)(one | two)
В C# для каждого enum-типа автоматически определяются битовые операции и прибавление/вычитание константы, выдающие значение этого же типа, так что такие кривости там не нужны. Но мой пример несколько про другое, пусть Влад подумает.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Так маразм-то — спецификация throw(). WH>А я спорю? Я же назвал это проблемой... Но это фигня по сравнению с граблями которые достались от С. MSS>>Кому она нужна-то? излишество, загромождающее код, WH>Ни кому. MSS>>и одна из самых бесящих вещей в Джаве, где она обязательна, в отличие от Си++. WH>.NET и исключения
Здравствуйте, 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 — ну ОК, перейди на юниксы, которые якобы более надежны — там тоже большая часть софта на Си написана.
Ну это как раз — "исторические причины" в чистом виде. и "якобы более надежны" — это аргумент совсем не в пользу Си
MSS>Редко такое бывает. Ну что такое "смысловая ошибка"? Финансовая система неправильно деньги считает? ОК. Решается как правило переписыванием одного SQLного запроса.
Если бы одного... От изменения логики выполнения одного запроса возникает необходимость править смежные, чтобы данные не "поплыли". Страшное дело, когда вся логика одними запросами выражена.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>А на чем 1С тормозит-то? Это известно? Может, на неоптимальной работе с данными?
Да на пустом месте тормозит. Я бы предположил, что туда просто понапихано циклов задержки, если бы не был почти наверняка уверен, что это не так.
Ещё тормозит на арифметике. У них она реализована, что называется, "собственноручно". Там нет понятий int32, uint64, double и т.д. Есть тип данных "Число", который есть, похоже, некое BCD сумасшедшей точности. В 1Сv7 эта точность ограничена чем-то разумным (чем конкретно — не знаю, не проверял), а в 1Сv8 — такое ощущение, что только объёмом оперативной памяти. Соответственно, в семёрке такая реализация тормозит стабильно, а в восьмёрке можно нарваться просто на срабатывание стопкрана, отработав всего лишь такой простенький участок кода:
// 1Сv7 - 14 секунд
// 1Сv8 - не смог дождаться окончания работы
А = 1
Для Инд = 1 по 1000000 Цикл
А = А / 1.00001;
КонецЦикла;
Зачем так сделано? Да там просто изначально всё ориентировано на простоту и доступность. Типа чтобы программер не задумывался над резрядностью чисел.
Здравствуйте, MadGhost, Вы писали:
MG>Скажем так: опыт программирования на 1С у меня не большой, а точнее сказать ваще не большой, вчера когда читал этот треп скачал и установил, и начал писать на нем ). Но.. MG>Не знаю про Навизион, но: MG>1С, в чем то очень ограниченый язык, согласен что он расширяемый вроде бы, не в курсе, и не буду спорить по этому поводу... опять таки но: MG>чем больше и гибче возможности по программированию задачи тем на мой взгляд лучше. MG>Т.е. на том же Си++ описать можно все... а в 1С только в пределах того что она позволяет..
Хм... И 1С, и С++ обладают полнотой по Тьюрингу. То есть, и там и там в принципе можно запрограммить всё, что можно запрограммить. Один товарищ даже шахматную программку умудрился написать на 1С.
MG>Хотя конечно хотелось бы взглянуть на реализацию расширения 1С кто ссылкой кинется буду очень признателен.
Если интересно, поищи компоненту Rainbow.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Еще нюанс. После NdisSend пакет нам не принадлежит. Надо не забыть занулить поле в классе, чтобы деструктор по выходу из блока не решил уничтожить не-принадлежащий нам пакет. В итоге сложности вырастают, они всего лишь заталкиваются внутрь враппера.
Написал один раз, закомментировал — и можно забыть.
MSS>Еще нюанс. Написание враппера вокруг обоих структур, а потом еще и "кода по делу" — дольше будет.
Если отправка пакета понадобилась тебе один-единственный раз в жизни, то да.
Если же хотя бы два раза, то проще написать обёртку, чем кажый раз колотить на plain C всё работу по созданию/уничтожению пакета.
Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS.
Он и стОить будет дешевле.
А пользуясь этими классами он и работу сделает, и много дров не наломает.
MSS>Еще нюанс. В отладчике страшно будет
Это смотря в каком отладчике
SotfICE с C++ дружит.
Здравствуйте, VladD2, Вы писали:
VD>Ты про Каиру читал? Лет хх назад про нее такое заливали. Мол перва ОО-ОС.
да, пиар у MS всегда на первом месте
уж как они .NET рекламировали, так это смех один. Веб-сервисы там типа самое главное
посмотрим, что они реально в Лонгхорне сделают. хотя избавляться от теперешнего WinAPI давно уже пора
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>А если всё это реализовывать чисто на С, то результат мог бы получиться ещё более плачевным: программа, скомпилированная самым супероптимизирующим компилятором, вполне может оказаться тормознутее, чем то же самое, исполняемое интерпретатором 1С.
S>> Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
V>Ага, но при этом легко получить вариант a la Navision.
Наверное заметил, что 1С предпочитают в связке ДБФ + терминальные сессии, впрочем если и используют SQL то тоже используют терминальные сессии. Хотя SQL на больших выборках работает и быстрее. А проблема в основном та, что невозможно одним запросом получить все нужные данные, из-за нормализации и большой разветвленности объектов. То приходится городить кучу мелких запросов с клиента.
По сути работая как с внешним сервером автоматизации. Надеюсь разница скорости внешнего сервера и внутреннего не нужно объяснять.
Так связка ДБФ + терминальные сессии работает как раз как внутренний сервер, т.к. идет доступ к файлам используя кэширование и без лишних посредников.
Вынос проведения документов внутри хранимых процедур на компилируемом Net при прямом доступе к БД (как к домену приложения) как раз и сгладит все углы.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Maxim S. Shatskih, Вы писали:
V>>Тема-то была про другое. Navision просто под руку попался как иллюстрация
MSS>А на чем 1С тормозит-то? Это известно? Может, на неоптимальной работе с данными?
ДБФ тормозит только за счет интерпритатора плюс представление всех данных ввиде строк (BCD это тоже строка в фокспро) прежде всего из-за возможности сортировки как строк. На Delphi та же модель в десятки сотни раз быстрее.
По поводу SQL здесь риторический вопрос либо приложение должно подгоняться под SQL либо наоборот ( я предпочитаю второе). Зачаточные признаки есть в Юкон но не более.
Посмотрим что выдаст M$ выпустив нетовский MBS.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
P>Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS. P>Он и стОить будет дешевле. P>А пользуясь этими классами он и работу сделает, и много дров не наломает.
Это аргумент?
Наверное будет невредно почитать раздел Philosophy на www.balder.com (очень хорошо соотв. данной рубрике RSDN)
А именно: "The three most important aspects of kernel mode code are quality, quality, and quality."
P>Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS. P>Он и стОить будет дешевле. P>А пользуясь этими классами он и работу сделает, и много дров не наломает.
Ваша миссия как более опытного специалиста объяснить коллеге нюансы IMHO. Ничего личного.
Здравствуйте, vstrogov, Вы писали:
V>Здравствуйте, postmaster, Вы писали:
P>>Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS. P>>Он и стОить будет дешевле. P>>А пользуясь этими классами он и работу сделает, и много дров не наломает.
V>Это аргумент? V>Наверное будет невредно почитать раздел Philosophy на www.balder.com (очень хорошо соотв. данной рубрике RSDN) V>А именно: "The three most important aspects of kernel mode code are quality, quality, and quality."
Это всё так.
Но теперь давай от технических вопросов перейдём к экономическим.
Категория 1: Программист с глубоким знанием NDIS — 3000 USD/месяц.
Категория 2: Программист с очень поверхностным знанием NDIS, но с C++ обёрткой в руках — 1000/месяц.
Результат:
1). Тим из 5-ти человек, состоящий только из 1-ой категории программистов. Стоимость разработки продукта — 15000 USD.
2). Тим из 5-ти человек, один из 1-ой категории, четверо из 2-ой категории. Стоимость разработки продукта при сопоставимом качестве — 7000 USD.
Теперь первый и второй продукт начинают конкурировать.
Дальше рассказывать?
Вдогонку: не мог бы ты объяснить, где в моём примере страдает качество?
Предполагаем, что писатель обёрток на C++ знает своё дело хорошо и кривых обёрток не пишет.
Здравствуйте, vstrogov, Вы писали:
V>Здравствуйте, postmaster, Вы писали:
P>>Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS. P>>Он и стОить будет дешевле. P>>А пользуясь этими классами он и работу сделает, и много дров не наломает.
V>Ваша миссия как более опытного специалиста объяснить коллеге нюансы IMHO. Ничего личного.
Боюсь, что одними нюансами тут не обойтись.
После "галопом по европам" результат будет заведомо хуже, чем при использование готовых обёрток.
Здравствуйте, postmaster, Вы писали:
P>Здравствуйте, vstrogov, Вы писали:
V>>Здравствуйте, postmaster, Вы писали:
P>>>Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS. P>>>Он и стОить будет дешевле. P>>>А пользуясь этими классами он и работу сделает, и много дров не наломает.
V>>Ваша миссия как более опытного специалиста объяснить коллеге нюансы IMHO. Ничего личного.
P>Боюсь, что одними нюансами тут не обойтись. P>После "галопом по европам" результат будет заведомо хуже, чем при использование готовых обёрток.
В таком случае лучше не обертки, а готовые реализованные блоки/модули/движки, на основе которых модульно
реализуется функциональность.
Здравствуйте, postmaster, Вы писали:
P>Вдогонку: не мог бы ты объяснить, где в моём примере страдает качество? P>Предполагаем, что писатель обёрток на C++ знает своё дело хорошо и кривых обёрток не пишет.
Основные затраты(и отсюда конечное качество) в системном программировании — не кодирование, а отладка и исследовательская работа. Всегда нужно знать, что внутри.
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Ты свою семью в McDonalds поведешь?
MSS>Иногда по пути заходим мороженое съесть.
MSS>И разговор-то не о том. А о том, что Макдональдс — успешный бизнес. Вот и все.
как раз из-за такого... успешного бизьнеса был выведен вирус, называемый Бэйсик
MSS>...Когда же программа начинает напоминать сводку новостей времен СССР и приходится докапываться до третьего слоя истины -- это бардак...
особенно это понравилось! давно человек видно на западе живет и не докапывается, что и у них уши от селёдки продают...... и про нас скажем сейчас: докапываться на телеканалах в РФ до чнго-то типа за что Парфенова уволили — просто очень даже повышает степень эрудиции
Здравствуйте, vstrogov, Вы писали:
V>Здравствуйте, postmaster, Вы писали:
P>>Вдогонку: не мог бы ты объяснить, где в моём примере страдает качество? P>>Предполагаем, что писатель обёрток на C++ знает своё дело хорошо и кривых обёрток не пишет.
V>Основные затраты(и отсюда конечное качество) в системном программировании — не кодирование, а отладка и исследовательская работа. Всегда нужно знать, что внутри.
V>Речь в первую очередь об этом.
Программист №1 знает, что внутри, и пишет обёртки для тех, кто не знает.
Обёртки ограничивают свободу программиста, но позволяют корректно писать приложения без глубоких знаний потрохов.
Или ты предлагаешь знать "что внутри" всем? Тогда получаем вариант с 15000 USD за проект.
Здравствуйте, vstrogov, Вы писали:
P>>После "галопом по европам" результат будет заведомо хуже, чем при использование готовых обёрток.
V>В таком случае лучше не обертки, а готовые реализованные блоки/модули/движки, на основе которых модульно V>реализуется функциональность.
Согласен.
Но framework'и как правило слишком универсальны, тяжеловесны, и тянут много лишнего.
Проще обойтись хорошо структурированными обёртками.
Здравствуйте, vstrogov, Вы писали:
V>Сравнение двух команд было некорректно. Требуется не 5 специалистов, а меньше, чем в команде номер 2. Именно специалистов. Отдельно рассматриваются прикладные программисты и QA инженеры.
V>Дело не в категориях программистов, а в областях специализации. V>В том то все и дело. Подчеркиваю, речь идет о системном программировании.
V>----------------------------------
V>И из всего этого обсуждения все больше V>убеждаюсь (да и раньше такие мысли были), что речь идет даже не о разных специализациях, а скорее профессиях. V>(хотя скорость перехода из одной в другую сильно отличаются)
V>И критерии качества разные (в том числе экономически и технически обоснованные).
Мой пойнт: km программист — это не обязательно системщик. [тухлые помидоры летят в сторону докладчика]
Отсюда и желание использовать C++ для прикладников, волей обстоятельств вынужденных писать в km.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Только тем, что половина драйверистов — едва услышав о такой идее закатывают глаза и начинают выть про "святотатство"... В подобных условиях не возможно работать...
Т.е. дело в традициях и малость (а может и не малость) неадекватного к ним отношению? Ну, что же это объяснение очень похоже на правду.
AF> А если серьёзно — то C++ прекрасно можно использовать для драйверов. Главное при написании драйверов это смотреть — какие средства языка используются и каковы будут затраты ресурсов при их использовании.
Согласен на все 100.
AF>Например exceptions в драйверах явно не стоит использовать.
Ну, а почему бы и нет если они используются для выведения блюскринов?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexkro, Вы писали:
A>Я про это и говорю. Никто не будет в Америке делать макдональдсы в каждом городе на том же уровне, что и в Москве. Большинство американцев живут в провинциальных городках и жиреют в провинциальных макдональдсах. Посмотри, например, сюда. Полу-деревня, а макдональдса там целых два!
Сдается еда одинакова во всех маках. Так что тут пробдемы в менталитете аперикосов. Ну, а это савсем уж их пробемы.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Видимо ты не привел перегруженных методов в которых собчка то и порылась.
Скорее всего там есть параметр типа энум. А разные орлы пытаясь сувать туда целочеисленное его значение налетали на боксинг и иную интепретацию. Ну, или еще что-нить в этом роде.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Кстати, чем плохо неявное приведение энума к целому? Наоборот — конечно плохо, но я не уверен, что даже Си это позволяет.
Потому-что — это порождает целый ворох граблей. Одним словом — это нарушение типобезопасности.
MSS>Например, энумами пользуются для объявления побитовых флагов. Такой запрет разрушит это использование.
Дык потому и пользуются, что а) они с С++ убоги, б) нет полноценных специализированных средств. В Дельфи для этого есть set-ы, в Шарпе энумы помеченные атрибутом Flags.
Например, на шарпе можно писать так:
[Flags]
enum E { A = 0x1, B = 0x2 }
static void Main()
{
E ab = E.B | E.A;
}
На С++ так фиг выйдет. При этом вместо энума нельзя случайно подсунуть каую-нить хрень. В целом получается, что явные приведения нужны значительно реже чем в С++, что повышает надежность кода без каких бы то ни было накладных расходов.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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 незнаю, так как с ней незнаком. Но обертки в общем, при правильном их проектировании и использовании могут значительно повысить надежность кода и упростить его.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ilya_ny, Вы писали:
_>microsoft в 2000, 2001 гг рассылал диски с Visual Studio.NET RC1, RC2... _>я даже помню, что они были белого цвета _>и при чем тут закрытое тестирование вообще
RC1 были или в самом конце 2001 или (что скорее) в 2002. В 2000 их быть немогло.
_>COM+ — это то, что было еше под Windows NT — только устанавливалось отдельно — называлось MTS _>может внутрене .NET и реализован с использованием COM+ технологии, но так это совсем разные вещи
Блин, ткни по ссылки и почти чем языком молоть. Весь прикол в том, что КОМ+ — это альфное название прокта который выродился в сегодняшний дотнет. И работать ты на нем не мог.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vstrogov, Вы писали:
V>>Ваша миссия как более опытного специалиста объяснить коллеге нюансы IMHO. Ничего личного.
VD>А что по-твоему проще объяснить "коллеге" или самому написать? И что будет когда объясняльщик уйдет и компании?
VD>Абстракции тем и хороши, что они понятны сами собой. И их не нужно трактовать.
Поддержка и развитие _сложного_ драйвера (по крайней мере для NT базированной OS) невозможна без поддержки
с помощью либо штатного специалиста, либо по договору поддержки и обслуживания с организацией или специалистом.
Есть еще вариант, когда развивать не требуется и все работает без проблем. Но контракт поддержки все равно
рекомендуется иметь.
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, VladD2, Вы писали:
_>>> [Obsolete("use AddWithValue(string, object)", false)] _>>> public SqlParameter Add(string parameterName, object value) { VD>>Скорее всего там есть параметр типа энум. А разные орлы пытаясь сувать туда целочеисленное его значение налетали на боксинг и иную интепретацию. Ну, или еще что-нить в этом роде.
_>Почти угадал. Осталось только объяснить, почему два вызова Add порождают разный код: _>
Хочеш сказать, что 0 таки приводится к этуму автоматом? Нда, это грабли. Зачем они разрешили это совершенно не ясно. Видимо из-за инициализации нулем. Козлы, могли бы запретить хотя бы присваение литералов.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shhady, Вы писали:
DG>>Это фича Windows-а — стандартные контролы Windows обрабатывает сама.
S>Чего? А CButton, CScrollBar (вот что фиг перепишешь, всмысле отрисовки) — это не часть MFC?
Это обертки над АПИ-шными контролами. CButton и CScrollBar отрисовкой не занимаются.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndreyFedotov, Вы писали:
AF> То же самое и здесь.с локами. Брать новичка, который не имеет представления об ОСНОВАХ языка ...
Но кое что разумное в этом есть. Например, новом шарпе конструкции обязанные ограничивать свое действие областью видимости специально спроектировали, так чтобы нельзя было допустить визуальных ошибок. Так usung и lock наспространяют свое действие на вложенный блок:
using (StreamReader reader = new StreamReader("file.txt"))
str = reader.ReadToEnd();
или
lock (obj)
{
// используем obj
}
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Честно говоря, хорошие exceptions в OLE Automation. Код ошибки и строка. И все. Хватит. На кой черт нужны _классы_ exceptions?
Кстати, в КОМ ошибки как раз классы. Их можно подменять и дополнять информацияю.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>>>Единственный адекватный способ создать такой язык это проектирование его с нуля и при этом забив на обратную совместимость с С/С++. AVK>>Ну как бы R# уже сейчас показывает что это не обязательно. WH>Или кто-то из нас не понял что сказал... Или R# может С++ компилировать?
Я думаю, АВК имел в виду, что на С++ свет клином не сошелся. И словосочетание "с нуля" не означает автоматот не наследуясь от С++.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Да прям при любом шаге пятерка была неудачная версия, в шестерке я не чаще раза в год такое вижу. В том компиляторе, что с XP DDK дают — тоже.
Д>Может быть Д>но вообще пример не очень удачный. Насколько я знаю, большая часть кода компиляторов генерируется по грамматикам, так что сам по себе язык большой роли не играет.
Сильно ошибаетесь. По грамматике генерируется только парсер -- и это далеко не самая главная часть кода компилятора.
MSS>>Насчет MSBlaster — ну ОК, перейди на юниксы, которые якобы более надежны — там тоже большая часть софта на Си написана.
Д>Ну это как раз — "исторические причины" в чистом виде. и "якобы более надежны" — это аргумент совсем не в пользу Си
Здравствуйте, vstrogov, Вы писали:
V>Здравствуйте, postmaster, Вы писали:
P>>Ещё один плюс: в моём случае можно посадить за работу программиста без глубоких знаний NDIS. P>>Он и стОить будет дешевле. P>>А пользуясь этими классами он и работу сделает, и много дров не наломает.
V>Это аргумент?
V>Наверное будет невредно почитать раздел Philosophy на www.balder.com (очень хорошо соотв. данной рубрике RSDN)
V>А именно: "The three most important aspects of kernel mode code are quality, quality, and quality."
А для крипографических работ это ещё более важно. Потому что ошибки в криптографии приводят к тому, что система просто не работает. Zero error tolerance. И никакой отладчик причину ошибки вам не раскроет -- в одной из магических констант описались. Вот почему C++ здесь очень помогает -- он открывает такие возможности для верификации кода, которые на чистом C просто невозможны (впрочем, ни на одном другом существующем языке тоже).
Здравствуйте, Шахтер, Вы писали:
Ш>Сильно ошибаетесь. По грамматике генерируется только парсер -- и это далеко не самая главная часть кода компилятора.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Шахтер, Вы писали:
Ш>>Сильно ошибаетесь. По грамматике генерируется только парсер -- и это далеко не самая главная часть кода компилятора.
Д>а где можно почитать, не подскажете?
По компиляторам? На русском языке есть Ахо, Сети, Ульман. Компиляторы. Принципы, технологии, инструменты. Но предупреждаю сразу -- книга на редкость мутная.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Только тем, что половина драйверистов — едва услышав о такой идее закатывают глаза и начинают выть про "святотатство"... В подобных условиях не возможно работать...
VD>Т.е. дело в традициях и малость (а может и не малость) неадекватного к ним отношению? Ну, что же это объяснение очень похоже на правду.
А то! Есть хорошая традиция разделяемая почти всеми программистами: услышав заклинание "Visual Basic" дружно орать: "Фу! Остой!", трясти бубном и совершать другие ритаульно-оскорбительные действия в отношении VB. Причём что меня удивило больше всего, эта традиция распространена и среди самих программистов на VB...
Всё в комплексе напоминает обряды "укрощения плоти" или "очищения от грехов"...
Забавно, но многие начинают думать (из тех кто вообще начинают) лишь после исполнения обрядовой части...
AF>> А если серьёзно — то C++ прекрасно можно использовать для драйверов. Главное при написании драйверов это смотреть — какие средства языка используются и каковы будут затраты ресурсов при их использовании.
VD>Согласен на все 100.
AF>>Например exceptions в драйверах явно не стоит использовать.
VD>Ну, а почему бы и нет если они используются для выведения блюскринов?
Не экономично. В драйвере гораздо проще этого добиться например так:
*( ( DWORD* ) 0x0000000C ) = 0;
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Это как с авиацией. Боингу-747 уже 30 лет. F-16 — тоже 30 лет. И ничего, летают, первый с незначительными изменениями, второй — почти как есть.
Серьезно что ли?
F-16 теперешний очень сильно отличается от F-16 тогдашнего. Новые движки, новая электроника, эффективность выше в разы. По сути неизменным остался только планер.
Здравствуйте, WolfHound, Вы писали:
AVK>>Ну как бы R# уже сейчас показывает что это не обязательно. WH>Или кто-то из нас не понял что сказал... Или R# может С++ компилировать?
Нет. Я к тому что никто не мешает создать аналог R# для С++.
Здравствуйте, VladD2, Вы писали:
AVK>>В смысле? В Москве намного хуже?
VD>В штатах маки — это помойки.
Что то мне кажется что бигмаки везде одинаковы. Другое дело что местный макдональд последнее время продает и нетрадиционные для них блюда, но имхо это дела не меняет.
Здравствуйте, VladD2, Вы писали:
Д>>посмотрим, что они реально в Лонгхорне сделают. хотя избавляться от теперешнего WinAPI давно уже пора
VD>Современная рекламма ЛХ, как ни странно, самя адекватная из слышанных мной от МС.
Здравствуйте, bwowa, Вы писали:
B>Здравствуйте, alexkro, Вы писали:
A>>А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно. B> Есть, только не талмуд, которому никто следовать не будет, а небольшой внутрифирменный документ, стандартизирующий написание кода. Над проектом работает 10 человек, ...
Команда из десяти человек, а сколько бюрократии. Я видел группы побольше, и никаких формальных документов не требовалось. Разумные люди сознательно не будут бардак создавать.
A>>Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку. B> Тоже самое с модификатором const, сделав одну из функций неконстантной, вам прийдёться модифицировать все функции исполюзующие её. Но вы ведь не будете отрицать необходимость этого модификатора.
Это совсем не тоже самое. Во-первых, твоё утверждение о "модификации всех функций" неверно. Во-вторых, ответь мне, почему const входит в сигнатуру функции, а спецификация исключений нет? Я удивлен, что тебе вообще пришла идея такого сравнения в голову.
B>>> К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций, A>>Как раз таки, компилятор должен кучу кода награмаздить, чтобы проверить соответствие спецификации исключения. Тут уж ни о какой оптимизиции речи не идёт, за исключением опять-же пустого throw(). B> На то он и компилятор, чтобы громоздить код вместо человека. Вы же не обижаетесь на автоматически код пролога и эпилога функций, и на автоматические деструкторы и операции копирования.
Ты говорил про оптимизации или про что? А теперь перекинулся на то, как компилятор облегчает генерацию кода. Да-с.
B> К тому же, компиляторы эволюционируют
>>> или для автоматической генерации кода обработки исключения. A>>Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна? B>Кому не нужна, тот и не использует. Кому понадобиться, тот будет рад что такое возможно.
Вот и объясни мне, кому такое понадобится и зачем. Иначе, в твоих словах нет аргументов.
B>Во всех крупных проектах, в которых я участвовал, к конце концов формировалась своя иерархия классов-исключений.
Мы кажется говорим про спецификации исключений, а не про иерархии классов-исключений. Почему-то тебя все время в сторону тянет.
B>Хлтя если вы вообще противник технологии исключений, то можем прикратить нашу дисскусию.
Я не противник технологий, я противник их бездумного применения. Далее прошу оставаться в рамках спецификации исключений и не перепрыгивать на смежные вопросы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>Кроме "throw()", который достаточно важен, так как указывает на то, что функция не порождает исключений.
VD>И как без нее в дотнете живут?
В .NET исключение может на ровном месте произойти. Вот так и живут. В C++ можно гарантировать то, что функция не выбросит. Это, кстати, очень полезно в некоторых случаях.
Здравствуйте, AndrewVK, Вы писали:
VD>>В штатах маки — это помойки.
AVK>Что то мне кажется что бигмаки везде одинаковы. Другое дело что местный макдональд последнее время продает и нетрадиционные для них блюда, но имхо это дела не меняет.
Бигмаки то одинаковые, а вто люди и качество заведений разные. Я собственно сам не видел, но пра друзей приехавших оттуда рассказывали.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, desperado_gmbh, Вы писали:
_>6.1.3 Implicit enumeration conversions _>An implicit enumeration conversion permits the decimal-integer-literal 0 to be converted to any enum-type.[/q]
Да это я посмотрел сразу после догадки.
_>Из-за флаговых enums. Любой здравомыслящий человек при работе с флагами в случае, если ни один из флагов не установлен, захочет передавать литеральный 0, вместо того чтобы явно приводить его или заводить Default = 0,
Видимо я или не любой, или не здравомыслящий. Я как раз бы скорее ввел нечто вроде None.
_> как, скажем, в CommandBehavior. А грабли из-за того, что создателям компилятора было лень проверять FlagsAttribute (он проверяется только в рантайме — Enum.ToString), и все эти 0, |, &, ^, ~ работают даже с нефлаговыми enums.
Уверен? Это форменный бардак.
Мля, что стоило ввести какой нить None в стандарт и приклеивать его ко всем энумам что помечены как флаг?
А еще лучше не брать плохие примеры вроде С, а содрать решение с Дельфи. Set- все таки очень грамотно сделаны были.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, postmaster, Вы писали:
P>Не забудь про деструкторы, в которых разрушаются PNDIS_PACKET и PNDIS_BUFFER. P>Именно в них огромнейшее преимущество C++ перед plain C в данном случае.
Ну, тут ничего не попишешь. Я о другом... я о том, что грамотная обертка упращает код даже если она не на С++ написана.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>В .NET исключение может на ровном месте произойти.
VD>В С++ тоже. Помечай не помечай а аппаратный сбой или где-нить в недрах...
Аппаратный сбой не является исключением C++.
A>>Вот так и живут.
VD>Очень неплохо надо сказать.
A>> В C++ можно гарантировать то, что функция не выбросит.
VD>Кудаж оно детется то? Деление на ноль или еще что и приплыли тапочки...
Деление на ноль не является исключением C++. Я уж не говорю про то, что код можно гораздо более надёжно писать.
A>> Это, кстати, очень полезно в некоторых случаях.
VD>Скорее вредная. Я как-то ни разу на практике необходимости в этом не испытал.
Наверняка испытывал, только не задумывался над этим. Вот типичный код, в котором требуется невыбрасывающая операция:
void Update( ref SomeObject obj )
{
// create a copy
SomeObject copy = obj.Clone();
// update copy (connect to DB, etc), may throw
...
// commit with non-throwing ops
obj = copy;
}
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Флаг вот только в руки реализовывать __CxxFrameHandler в ядре. На DISPATCH_LEVEL же это вообще невозможно, потому как exceptions основаны на thread local storage (сегмент FS), а на DISPATCH_LEVEL это понятие размыто. Запачкаешь FS:[0] какой-то нити, спасибо за это никто не скажет
Смотри ссылку http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/other_23zb.asp, в kernel mode есть SEH, то есть FS:[0] можно свободно "пачкать". Кстати FS:[0] меняется не __CxxFrameHandler, а любой функцией в которой создаётся exception handling frame, например если в функции есть локальный объект класса с деструктором. А зачем обязательно C++ exception handling, можно и SEH использовать:
ExRaiseStatus() вместо throw и
__try/__except/__finally вместо try/catch (он только не может быть в той же функции где используются локальные объекты с деструкторами).
Здравствуйте, VladD2, Вы писали:
_>>Из-за флаговых enums. Любой здравомыслящий человек при работе с флагами в случае, если ни один из флагов не установлен, захочет передавать литеральный 0, вместо того чтобы явно приводить его или заводить Default = 0, VD>Видимо я или не любой, или не здравомыслящий. Я как раз бы скорее ввел нечто вроде None.
Вообще да, 0, наверное, сишная привычка — для указателей я уже привык использовать null. Кстати, default в Whidbey — это именно то, хотя и сделан для других целей. Жаль, уже поздно — есть много кода с нулем и ломать его, запрещая преобразование нуля в enum, не захотят.
VD>А еще лучше не брать плохие примеры вроде С, а содрать решение с Дельфи. Set- все таки очень грамотно сделаны были.
Enums часто напрямую соответствуют параметрам API-функций, и нужна бинарная совместимость значений флагов. Кроме того, бывают хитрые случаи, когда часть битов — флаговая, а часть — число, например, System.Drawing.Drawing2D.PathPointType. Естественно, это можно считать плохим дизайном, но при попытке сделать по-другому обертки над такими API-функциями усложняются и замедляются, почти не выигрывая в удобстве.
Здравствуйте, IT, Вы писали:
IT>Мы сторонники правильных исключенией. А ISupportErrorInfo — это не исключения, это слёзы. Единственно, кто их умеет нормально эмулировать как C++ исключения — это #import.
Не, ну на Шарпе и в Васике им тоже можно пользоваться. В общем, оборачиваем в нормальные исключения и живем как белые люди.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>
Ш>>Типа, .Net rulezzzzzzzzzzzzzzzdox. Где-то тут была дуракоустойчивость...
VD>Какое-то странное окошко. Что-то в нем не то. Расскажи как его повторить и поглядим что это такое.
К сожалению, эффект наблюдал только один раз. Так что насчет повторить -- не знаю как. Вылетело, когда я закрывал Янус.
Здравствуйте, Шахтер, Вы писали:
Ш>К сожалению, эффект наблюдал только один раз. Так что насчет повторить -- не знаю как. Вылетело, когда я закрывал Янус.
Ну, ты хоть опиши конфигурацию системы, расскажи как дело было...
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>К сожалению, эффект наблюдал только один раз. Так что насчет повторить -- не знаю как. Вылетело, когда я закрывал Янус.
VD>Ну, ты хоть опиши конфигурацию системы, расскажи как дело было...
Система -- XP Home Edition. .Net Framework 1.1 , Pentium-M 1.5 Г 256 М ОЗУ. Дело было -- закрываю Янус, винт шуршит, как обычно, вылетает окошко. Вообщем, очнулся -- гипс.
Здравствуйте, iZEN, Вы писали:
ZEN>На изучение Win32 API может уйти вся жизнь. И только небольшая чать документирована в MSDN на нескольких CD.
ну-ну, таки большая часть документирована в MSDN, а про оставшееся написаны книги а-ля "Недокументированые возможности windows nt"
ZEN>...Windows. ZEN>Самая небезопасная ОС в мире.
Здравствуйте, Шахтер, Вы писали:
Ш>Система -- XP Home Edition. .Net Framework 1.1 , Pentium-M 1.5 Г 256 М ОЗУ. Дело было -- закрываю Янус, винт шуршит, как обычно, вылетает окошко. Вообщем, очнулся -- гипс.
Очунь уж н экспишное окошко.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Полная фигня. Энумы никак (семантически) не соотвествуют С-шным. В С энумы ни чем от констант не отличаются. Тут же это разумный тип.
Не совсем. В IL-коде вместо енума фигурирует его underlying тип. Сам enum это честный класс (ссылочный!), наследник System.Enum — обертка для работы с метаданными.
Здравствуйте, Maxim S. Shatskih, Вы писали:
>>У МС же тогда это был натуральный комплекс неполноценности.
MSS>Факт.
MSS>Я еще когда молодой был, в 95ом году, слышал от своего тогдашего шефа (главный менеджер в одной фирме, которая Microsoft Solution Provider) — "Microsoft есть убогая персоналочная компания, у них один Ворд и Эксел, и ихний Бэкофис из пальца высосан — куда они лезут-то на рынок тяжелых систем, они там не понимают ничего..."
лично я вот назвал бы больше "комплексом неполноценности" твоего тогдашнего шефа. Типа убогая компания. А он управлял конечно не убогой компанией, которая куда круче и увереннее была, чем МС. Она просто маленькая была и никто её не замечал, а вот глупые людишки... Только МС и замечают. Только почему-то о компании твоего тогдашнего шефа я ни разу не слышал, а МС давно на рынке "тяжелых систем", хоть "они там не понимают ничего...". И МС поср*ть, что говорил твой шеф, и что говорят тыщи таких шефов по всему миру, она гнет свою линию и у нее все получается как нельзя лучше...
Здравствуйте, alexkro, Вы писали:
A>>>А толмуда с названием "Coding guidelines" у вас нет? Перегнули вы тут явно. B>> Есть, только не талмуд, которому никто следовать не будет, а небольшой внутрифирменный документ, стандартизирующий написание кода. Над проектом работает 10 человек, ... A>Команда из десяти человек, а сколько бюрократии. Я видел группы побольше, и никаких формальных документов не требовалось. Разумные люди сознательно не будут бардак создавать.
"Coding guidelines" есть практически везде, где работают удалённые команды, вот пример самого краткого: Phoenix team guielines
Там же есть ссылки на другие задекларированные аспекты работы, хотя казалось бы зачем GNU разработчикам на себя такие вериги накладывать — знай себе твори. Однако история нам подсказывает — где есть толпа, там должен быть определённый закон, иначе не будет развития. Даже в Open Source движении есть координаторы проектов, своего рода князьки и рядовым разработчиком бывает порой труднее их убедить, чем коммерческого менеджера.
A>>>Самодокументированность липовая, так как проблемы в этом смысле абсолютно такие-же как и в Java, когда в одной функции спецификация меняется, и это заставляет поменять все функции, её вызывающие, а дальше и все функции их вызывающие, и т.д. В конце концов это приводит к бардаку. B>> Тоже самое с модификатором const, сделав одну из функций неконстантной, вам прийдёться модифицировать все функции исполюзующие её. Но вы ведь не будете отрицать необходимость этого модификатора. A>Это совсем не тоже самое. Во-первых, твоё утверждение о "модификации всех функций" неверно. Во-вторых, ответь мне, почему const входит в сигнатуру функции, а спецификация исключений нет? Я удивлен, что тебе вообще пришла идея такого сравнения в голову.
Можно вообще не использовать ни const ни throw, и всё будет работать. Но это IMHO снизит управляемость кода. А сравниваю эти два зарезервированных слова я потому что сторонник порядка. Если функция не изменят состояние объекта, то это должно быть описано; если функция может генерировать исключения, то это тоже должно быть указано.
B>>>> К тому же, уже по моему мнению, информация об исключениях, может быть использована компилятором для оптимизаций, A>>>Как раз таки, компилятор должен кучу кода награмаздить, чтобы проверить соответствие спецификации исключения. Тут уж ни о какой оптимизиции речи не идёт, за исключением опять-же пустого throw(). B>> На то он и компилятор, чтобы громоздить код вместо человека. Вы же не обижаетесь на автоматически код пролога и эпилога функций, и на автоматические деструкторы и операции копирования. A>Ты говорил про оптимизации или про что? А теперь перекинулся на то, как компилятор облегчает генерацию кода. Да-с.
Что дасссс?
Современный компилятор громоздит код гораздно лучше, человека. Чего стоит только вызов деструкторов для автоматических объектов при исключении. Я давно работаю с компилятором Intel C++, и наблюдаю эволюцию их рекомендаций по написанию кода, который будет наилучшим образом оптимизирован, тенденция ведёт к упрощению, к снятию ограничений с кодера.
А вообще давай послушаем что сказали отцы throw
B>> К тому же, компиляторы эволюционируют >>>> или для автоматической генерации кода обработки исключения. A>>>Автоматическая генерация обработчика? std::unexpected()? Кому такая нужна? B>>Кому не нужна, тот и не использует. Кому понадобиться, тот будет рад что такое возможно. A>Вот и объясни мне, кому такое понадобится и зачем. Иначе, в твоих словах нет аргументов.
Как минимум — выдача диагностического сообщения о классе исключения, и если доступна контесктная информация, то и её выдача. Наверняка ты видел много сообщений "IO error" или "Divide by 0 error". Как минимум компилятору доступно имя класса исключения,что он и может использовать в обработчике по умолчанию.
B>>Во всех крупных проектах, в которых я участвовал, к конце концов формировалась своя иерархия классов-исключений. A>Мы кажется говорим про спецификации исключений, а не про иерархии классов-исключений. Почему-то тебя все время в сторону тянет. A>Я не противник технологий, я противник их бездумного применения. Далее прошу оставаться в рамках спецификации исключений и не перепрыгивать на смежные вопросы.
Посмотри на тему дисскусии, там про исключения вообще ничего нет
А про иерархия я говорю, потому что, не вижу смысла говорить о строительной глине, не подразумевя что из неё делают кирпичи, а из них дом. А споры нужна ли белая глина, или достаточно для всего красной, это пустая трата времени.
Вот я и говорю, что на моей практике две разных команды пришли к одному и тому же удобному для них решению — иерархии классов-исключений.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Нижеследующий текст написан нашим соотечественником, работающим в микрософтовской команде компиляторов.
MSS>Ко мне этот текст попал в конце 91го года. Он довольно старый, и старше, чем релиз .NET.
MSS>Предлагаю обсудить.
А что обсуждать? Человек не умеет пользоваться ООП в чем долго и нудно расписывается.
Есть области где ООП оправдано, есть области где оно вредно. К примеру интерфейся куда проще и удобнее писать с применением
ООП.
Большинство чисто алгоритмических задач (как тот же самый компилятор) в ООП не сильно нуждаются.
Здравствуйте, Шахтер, Вы писали:
Ш>Какому? Это зависит от системы. Нет в С способа использовать printf системно-независимым способом. Сейчас Майкрософт вводит Win64. В этой системе size_t -- 64 разрядный. Он будет больше long. Ш>Т.е. его вообще невозможно распечатать используя стандартные коды форматирования.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, году в 1994 я наблюдал изумительный пример маразма в этой области. Одному орлу поручили написать функцию преобразоватия числа в строку прописью (русское написание числа). Так вот он вместо того, чтобы написать одну простую функцию состряпал класс. Это надо было видить. Я плякаль... После этого мы переписали его код выбросив процентов 40. Но это же не проблема ООП. Это проблема умения выделять абстракции.
По поводу этого примера вставлю свои 5 копеек.
Ошибочно мнение, что ООП можно заниматься только на языках, в которых есть поддержка ООП. Это не так.
На Си тоже прекрасно получаются абстракции, наследование, полиморфизм и пр. НО! чтобы сделать
это надо маленько подумать и написать несколько больше букв (размер кода не больше, чем генерит компилятор, поддерживающий ООП),
поэтому абстракцию используют только там, где это реально необходимо и дает преимущества.
На Си вышеозначеный "орёл" не написал бы такой маразм, т.к. это требует значительно большей умственной нагрузки.
Т.о. программист, получив возможность просто объявить класс, а не создавать всю начинку класса самому, получает мнимую легкость
применения ООП, но знания его совсем не соответствуют уровню задачи.
Как аналогия — пересадить человека с машины на вертолет с очень простым управлением. Пока погода хорошая, он сможет летать на вертолете не хуже
чем ездить, но в сложной ситуации он неминуемо разобьется. А если бы управление вертолетом было сложное и требовало бы обучения, то
в ходе обучения человек бы приобрел все необходимые навыки поведения в экстренной ситуации и не разбился.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ilya_ny, Вы писали:
_>>смешно.. _>>я лично программировал в начале 2001 на C# (Beta 2)
VD>Значит должен знать, что такое DNA и какие ограничения на треп оно распростроняет.
VD>Я программировал еще на пре бете и на бэте 1. И именно по этому могу скзать, что вероятность появления этих слов в 2001 стремится к нулю.
Как же мог тогда М.Фаулер в 2002 году выпустить книгу, в которой ссылался на свой опыт использования и разработки под .NET в 2001 году?
Здравствуйте, Karapuz, Вы писали:
K>Как же мог тогда М.Фаулер в 2002 году выпустить книгу, в которой ссылался на свой опыт использования и разработки под .NET в 2001 году?
Мне по фигу. Я сам на бэтах программировал, например.
K>.NET уже 6 лет как вышел
The class library and the CLR together comprise the .NET framework. The framework is intended to make it easier to develop computer applications and to reduce the vulnerability of applications and computers to security threats. First released in 2002, it is included with current versions of Microsoft Windows, and can be installed on most older versions. The 2.0 version of the framework, released in November 2005, remains the current version as of May 2006.
...
This is the initial .NET Framework, released in January 2002. It is available on its own as a redistributable package or in a software development kit. It is also part of the first release of Microsoft Visual Studio .NET (also known as Visual Studio .NET 2002).
Ееще воросы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
-- я поинтересовался, с какой целью мы тратим невероятные усилия на разработку новых методов оптимизации и проч., если процессоры, согласно закону г-на Мура, становятся вдвое быстрее каждые полтора года? -- обычно код, порожденный предельно тупым компилятором ("что вижу, то и пою"), медленнее оптимального ну в полтора, ну в два раза (для RISC и CISC архитектур); поскольку в скором времени "плохой" код на новой машине будет работать столь же быстро, как и хороший на старой, имеет ли смысл так упираться?
Похоже, меня тоже скоро уволят.
)
Если нам не помогут, то мы тоже никого не пощадим.
). Вроде такого: Бейсик -> Паскаль -> С++. А мне сейчас, параллельно с проектом на С++, приходится лабать испытательные программы на языке ОНИКС (Орентированный на Наземные Испытания Космичесих Систем). В нём нет объектов, с этим я ещё согласен мириться. Но в нём ещё нельзя объявлять глобальные переменные, многомерные массивы, указатели, нет даже структур, и нет макросов, чтобы хоть как-то сымитировать некоторые из этих вещей (зато есть потоки). После С++ с STL очень тяжко. Размер программ получается раза в 2-10 больше, чем аналогичных на С++. Не обижайте С++!!! 
, который сам написан на С (ОС QNX-2 /*вам смешно... а я иногда о DOSе мечтаю 
