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

SWW>>Разумеется, если operator+ выполняет действия, не имеющие ничего общего со
>>сложением, то с таким программистом надо разбираться в другом месте.

MSS>Во! Золотые слова! А такое ведь почти всегда бывает. Например, оператор <<, означающий печать.

Дык тебе и говорят, что нет проблем в операторах. Ты их сам придумал. А есть проблемы в идиотах использующих вещи не по назначению. Ведь с таким же успехом можно назвать функцию вывода в консоль Shift и начать рассуждать о неполноценности процедурного подхода и приемуществах ассемблера.

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

A>Может, здесь просто ачипятка и имеется в виду 2001 год?

Може, то выглядет смешно. Кстати, в 2001 это тоже вряд ли могло быть написано. Дотнет официально вышел в 2002-ом и трепаться о Шарпе в таком стле разумный человек работающий на МС не стал бы.

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

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

WH>А теперь посмотри на амереканцев... жрут в МакДональдсе и выглядят как... ну вы поняли... Короче я считаю что МакДональдс гораздо опаснее чем БенЛаден и компания... В отличии от террористов МакДональдс убивает милионами причем с особой жестокостью и цинизмом.

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

Здравствуйте, 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> Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.



Короче, кончай пропаганду каменного века. Это уже не смешно.

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

V>Кстати, никто не знает тайную причину того, что в С/С++ так популярны макросы? Во многих других языках их вообще ведь нет. И даже как-то не хочется!

Тайного тут ничего нет. Многие проблемы в С++ решаются крайне криво. И макросы позволяют скрыть эту кривоту.

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

MSS>>>Ко мне этот текст попал в конце 91го года. Он довольно
>>старый, и старше, чем релиз .NET.
BK>>в 91-м году ни Жабы, ни тем более C# не было вроде...

MSS>Пардон, 2001, конечно. Запутался

Ты будешь смеяться, но в 2001 Шарпа тоже небыло. Он появился в 2002.

Но спор твой как раз из того самого 91-вого. Я бы это назвал синдромом Рыбинкина. Залезь на IXBT и поищи на эту фамилию. Думаю, неделя увлекательного чтива тебе обеспечена.

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

B>Это как начинающий водитель и проффесиональный гонщик — если перед ними поставить 2 машины: болид формулы 1(18 скоростей) и чтто нибудь отечественное, то, думаю, не надо особой фантазии чтобы представить последсвия, а также переимущества и недостатки возможных комбинаций.

[offtopic]
На болиде Ф1 обычно 6-7 скоростей. На моём велосипеде 24!
[/offtopic]

А по-хорошему перед тем, как садиться в болид Ф1, надо потренироваться в картинге, с чего и начинал Шумахер (чтоб он наконец-то проиграл хоть этот чемпионат ). Вроде такого: Бейсик -> Паскаль -> С++. А мне сейчас, параллельно с проектом на С++, приходится лабать испытательные программы на языке ОНИКС (Орентированный на Наземные Испытания Космичесих Систем). В нём нет объектов, с этим я ещё согласен мириться. Но в нём ещё нельзя объявлять глобальные переменные, многомерные массивы, указатели, нет даже структур, и нет макросов, чтобы хоть как-то сымитировать некоторые из этих вещей (зато есть потоки). После С++ с STL очень тяжко. Размер программ получается раза в 2-10 больше, чем аналогичных на С++. Не обижайте С++!!! А С давно пора выкинуть в помойку как мелкое подмножество С++, по моему скромному мнению.

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

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

Эксхумер, вы не правы. Для драйверов С++ очень даже самое полезное средство. Тем более, что современный компилятор (MSVC или Intel) сделает из С++ такой же качественный код как из С. Чего только стоят С++ классы от Intel для простой и удобной работы с MMX, SIMD1 и SIMD2 без знания асемблера. Впрочем для С у Intel тоже есть аналогичные библиотеки.
Прошу прощения у поклонников *nix, их любимые компиляторы не тестировал.

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

E>Вывод можно сделать только один. Плохие программисты были и будут всегда и везде. И если MS (ну и не только) берет на работу студентов, то и качеству кода удивляться не приходится. Они же только учатся, а получают копейки. И научившись чему-то, сразу уходят на нормальную зарплату в другое место. Так что это проблемы фирмы.

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

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

A>>Может, здесь просто ачипятка и имеется в виду 2001 год?

VD>Може, то выглядет смешно. Кстати, в 2001 это тоже вряд ли могло быть написано. Дотнет официально вышел в 2002-ом и трепаться о Шарпе в таком стле разумный человек работающий на МС не стал бы.

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

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


Высокая стоимость сопровождения кода C++ и вред скрытой семантики — факт. С тоже не лишен недостатков.


Но главным критерием на мой взгляд является уместность употребления языка в конкретном культурном контексте и традиции.

Хорошо то, что принимается сообществом (или большей/авторитетной частью с возможными исключениями) и соответствует большинству доступных материалов.

Для системного программирования (режим ядра) — С, в других областях — могут быть другие языки.

Здравствуйте, VladD2, Вы писали:
VD>Дык тебе и говорят, что нет проблем в операторах. Ты их сам придумал. А есть проблемы в идиотах использующих вещи не по назначению.


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

Когда Максим говорит про перегрузку, он совершенно прав.
Правило коммутативности обязано выполнятся, стало быть, те ситуации, которые по разному интерпретируют (a+b) и (b+a) должны идти в сад. Во избежание.


Maxim S. Shatskih, мой respect.

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


О>На болиде Ф1 обычно 6-7 скоростей. На моём велосипеде 24!

О>А по-хорошему перед тем, как садиться в болид Ф1, надо потренироваться в картинге, с чего и начинал Шумахер (чтоб он наконец-то проиграл хоть этот чемпионат ).

Вы неверно истолковали мой ответ. Ненавистник, он же новичок в С++, тут только один — это автор всего этого безобразия, Maxim. Я сам был таким лет 8 назад, когда работал с ассемблером, но был плох в С++, благо теперь я повзрослел

О>Вроде такого: Бейсик -> Паскаль -> С++. А мне сейчас, параллельно с проектом на С++, приходится лабать испытательные программы на языке ОНИКС (Орентированный на Наземные Испытания Космичесих Систем). В нём нет объектов, с этим я ещё согласен мириться. Но в нём ещё нельзя объявлять глобальные переменные, многомерные массивы, указатели, нет даже структур, и нет макросов, чтобы хоть как-то сымитировать некоторые из этих вещей (зато есть потоки). После С++ с STL очень тяжко. Размер программ получается раза в 2-10 больше, чем аналогичных на С++. Не обижайте С++!!! А С давно пора выкинуть в помойку как мелкое подмножество С++, по моему скромному мнению.

Сам прошел этот путь Basic -> Pascal -> C -> C++. Только межде Pascal и С я освоил Asm, на который до сих пор есть коммерческий спрос. Сейчас работаю одновременно с C, С++, Delphi, Asm. Естесвенно С++ самы гибкий и удобный, а с разросшимся проектом на Delphi я просто мучаюсь, и жалею что сразу не был заложен С++. Так что понимаю ваши чувства при работе с ОНИКС.

О>А С давно пора выкинуть в помойку как мелкое подмножество С++, по моему скромному мнению.
Э, какой горячий джигит ,).
Кроме x89 архитектуры процессоров есть ещё десятки других платформ, иногда очень экзотических. И для этих платформ нет С++ компилятора, а есть только С. То есть это вопрос переносимости, который очень актуален для некоторых промышенных отраслей.
А лет через 10-20 и С++ тоже могут на свалку викинуть, как когда то перфокарты. Будем сидеть на диване обвешанные электродами и мыслить программы на самых глубоких уровнях подсознания. Не вечно же клавиатуру терзать

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

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

2 возможно. Но в 2001 ти слова вряд ли могли прозвучать.

V>Высокая стоимость сопровождения кода C++ и вред скрытой семантики — факт.

Собственно с этим я и не спорю. Но С в поддержке как минимум не дешев.

V>С тоже не лишен недостатков.

Во-во. И если уж говорить о стоимости сопровождения и развития, то плевки в сторону явы и плюсов выглядят просто смешно.


V>Но главным критерием на мой взгляд является уместность употребления языка в конкретном культурном контексте и традиции.

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

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

Я бы поспорил на счет уместности С++ в драйверах, ну, да не мне судить. Я ими почти не занимался. Но ты на название темы взгляди? Или у нас драйверы — это единственное серьезное место?

Нзвал бы "Уместность С++ в драйверах и ядре ОС" и вряд ли кто особо спорить стал. Да и вообще читать.

ЗЫ

Тут давно идут баталии C++ vs. C#, и на их фоне C++ sv. C выгдядит как неудавшаяся шутка.

Более безопастный, надежный, простой, читабельный и т.п. нужен. Но при этом не хочется отказываться от удобных и приятных вещей. Да и простота языка сегодня понимается не так примитивно как понимает ее Maxim S. Shatskih. Например, синтаксис шарпа намного сложнее чем С++, но писать на нем (и что важнее читать!) проще и быстрее.

На сегодня важна не простота в смысле приметивности. Важна простота в смысле непротиворичивости, отсуствия множества способов выражения одного и тогоже, концептуальной стройности, сбалансированности и т.п.

Здравствуйте, VladD2,


Мне лично тенденция развития программирования бизнес-приложений на C# кажется положительной(есть такое субъективное ощущение).

Все хорошо, что легче писать и главное читать.

А С — в основном близкий к машине язык программирования, но не ассемблер. NT во многом закрепила такую роль C
своей идеологией переносимой системы (и является примером очень сложной операционной системы, реализованной простыми языковыми средствами).

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

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

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

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

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

AT>Когда Максим говорит про перегрузку, он совершенно прав.
AT>Правило коммутативности обязано выполнятся, стало быть, те ситуации, которые по разному интерпретируют (a+b) и (b+a) должны идти в сад. Во избежание.

И причем тут это и перегрузка? Ну, где ты на практике видел проблемы от пергрузки операторов? Да не так часто их и переопределяет. Слава богу те идиоты просто не справятся с перегрузкой.

В общем, высасал из пальца проблему и на основании этого обосновывает ненужность очень полезной фичи.

ЗЫ

Не стоит воевать с ветренными мельницами. Есть куча куда более интересных проблем.

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

МС сделала верный выбор спроектировав Шарп снуля. Очень многих проблем они избежали. И я совсем не понимаю почему не забыть об откровенно пережившем себя С, забить на С++ и пользоваться современным языком избавленным от большинства проблем.

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

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

V>Мне лично тенденция развития программирования бизнес-приложений на C# кажется положительной(есть такое субъективное ощущение).

Сдается мне, что Шарп все же новый универсальный язык, а не замена жлабэйсику.

V>Все хорошо, что легче писать и главное читать.

Именно!

V>А С — в основном близкий к машине язык программирования, но не ассемблер. NT во многом закрепила такую роль C
V>своей идеологией переносимой системы (и является примером очень сложной операционной системы, реализованной простыми языковыми средствами).

Ну, NT далеко не на С написан. Ядро возможно. Но оно не составляет основную часть ОС. Да и переносимость NT на сегодня уже ушла в прошлое (все Мипсы и ППиСи давно забыты).

Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT ведь в свое время была написана с чистого листа (только на основе опыта и знаний). Сейчас как раз такой же момент. Опыта и знаний накопилось много. Имеющиеся ОС уже настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать каую-нить Каиру.

Здравствуйте, 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 она портировалась куда проще. Оптимизация производетельности бьет больно не только по надежности, но и портируемости.

ЗЫ

Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых (в том числе и раньше) платформ.

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

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

V>>С этим не могу согласиться, сравнительная быстрота портирования на IA64 и AMD64 говорит о том, что ничего не ушло в прошлое.

VD>Быстрота? На IA64 виндовс портируется уже лет пять, и все есть проблемы. AMD64 вообще считай та же архитектура. Да и IA64 имеет много общего в плане управления железом.

VD>Сдается мне что партирование даже на близкие платформы дается МС не дешего. Именно по этому и забили на PPC и Mips. Денег приходилось вкладывать море, а окумпаемость фиговая.

VD>Сдается мне, что во времена NT 3.11 она портировалась куда проще. Оптимизация производетельности бьет больно не только по надежности, но и портируемости.

VD>ЗЫ

VD>Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых (в том числе и раньше) платформ.

Использование C как максимально распространенного и стандартизированного (на всех теоретически возможных платформах) было заложено в требования проекта NT.