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 эвент в Си++ный класс
типа объектно оно
А вот о том, что от эвента нечего наследовать, что примитивы синхронизации уже полиморфны и уже инкапсулированы — человек забыл.
Легче создать программу, которая делает 
