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

Ш>

Ш>size_t s=...;

Ш>printf("%u\n",s);
Ш>

Ш>Слабо найти и исправить баг в этом коде? Как там с азами эргономики поиска багов?

я может чего не понял... но

$ cat t.c                    
#include <sys/types.h>
#include <stdio.h>

int
main(int ac, char **av)
{
        size_t s = 10;

        printf("%u\n", s);
}

$ gcc t.c

$ ./a.out                     
10

вроде работает как ожидалось... или я чего не понял?

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

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

Ш>>

Ш>>size_t s=...;

Ш>>printf("%u\n",s);
Ш>>

Ш>>Слабо найти и исправить баг в этом коде? Как там с азами эргономики поиска багов?

или даже вот так:

$cat t.c 
#include <sys/types.h>
#include <stdio.h>

int
main(int ac, char **av)
{
        size_t s = (size_t)-1;

        printf("%u\n", s);
}

$gcc t.c 

$./a.out 
4294967295

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

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

Ш>>

Ш>>size_t s=...;

Ш>>printf("%u\n",s);
Ш>>

Ш>>Слабо найти и исправить баг в этом коде? Как там с азами эргономики поиска багов?

VD>Ну, видимо надо тип ручками приводить.

К чему? Мне нужно напечатать значение типа size_t. Как?

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

A> size_t s = 10;
A> printf("%u\n", s);
A>}
A>$ gcc t.c
A>$ ./a.out
A>10
A>[/ccode]
A>вроде работает как ожидалось... или я чего не понял?

Непортабельно. Тип size_t не факт, что лезет в %u.

С size_t это не сильно актуально, а вот с off_t — еще как! бывает и 32, и 64 бита.

Я наверное уникальный случай, мой первый язык был c++, а уж потом паскаль и C ( и то, меня этому учили в институте и эгзамен по паскалю я сдавал преподу по теме C++ в виде исключения ). Эти чисто процедурные языки не впечатлили. Я разрабатываю систему наподобии navision axapta на С++ с применением технологии COM, так вот, если б я писал на C ( я на C я всё же ОЧЕНЬ много писал ), я бы повесился. Уже 30 000 строк каркаса, гуи 20 000. Я конечно не использую dynamic_cast, темплейтов и эксепшенов, и очень доволен, и использовать не хочеться.

вот

Здравствуйте, 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х местах из сотни вот тогда... Ой млиииииииин...

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

MSS>Единственное место, где реально нужна reference — это перекрытые операторы, дающие lvalue. operator[], например.
А еще конструкторы копирования, а еще для параметров перегруженных операторов...

MSS>Аргументы есть какие-то для такого вывода? В ядре Windows — где только из самого ядра торчит 1100 функций, а еще есть куча подсистем вне ядра типа NDIS — как-то такой проблемы не возникает.
Re[8]: Применим ли Си++ в серьезном коде?

Автор: AndrewVK
Дата: 12.06.04

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>Скажем точнее — занимаются лучшие.
Ты толькочто оскорбил всех тех кто не пишет драйверы и ОС...
По легче на поворотах.

A>А самое инетресное, что посмотрев исходники Вин2К пришел к выводу, что ядро не
>правилось этак с 96-го года... (ну ессесено драйвера правилились, но основные
>системы похоже что нет )

Просто сразу хорошо написали, и все.

От того, что туда напихают врапперов по WolfHoundу , оно лучше не станет.

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

Вопрос прямизны рук.

Ну если совсем практика показывает, что постоянно хэндлы текут у данной конкретной команды — сделай так:

class CHandle
{
HANDLE m_Handle;
CHandle(HANDLE h){ m_Handle = h; }
~CHandle(){ ::CloseHandle(m_Handle); }
operator HANDLE(){ return m_Handle; }
};

— и юзай как хочешь. Полная прозрачность, как у смартпойнтера. Единственная разница — в месте объявления handle и вызове CreateFile.

Мерзость врапперов в том, что они из всем известного системного API делают что-то хрен знает какое.

WH>Короче тех кто не понимает что такое врапер на работу дешевле не брать.

В известных мне командах в Москве при виде враппера вокруг ReadFile подумали бы — "маньяааааак" — и точно на работу бы не взяли.

MSS>>Смартпойнтеры — один разговор. Обертки — бредятина полная. Забивание мозгов лишней
>информацией.
WH>В чем разница? И те и другие созданы для того чтобы скрывать детали.

Враппер ничего не скрывает. Как была CreateFile, так и осталась.

WH>Вот только там надо не забыть закрыть фаил... А это геморой.

Правда что ли?

WH>2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без
>произвольного доступа что есть маразм.

Правда что ли? а если это качаемый с HTTP поток? Сериализация из такого потока возможна? да. Ну и на кой требовать произвольный доступ для сериализации?

MSS>>Еще забыли про деструктор или release. Раз уж есть хоть один виртуальный метод — то
>виртуальный деструктор — это святое.
WH>Это догмы.

И? Ты же сам тут огласил другую догму, а именно "врапперы обязательны".

Невиртуальный деструктор приводит к отвратительным гиморам, которые очень сложно потом ловить. Есть рекомендация автора языка — везде, где есть вообще VMT, делать виртуальный деструктор. Разумная и обоснованная.

MSS>>Сами по себе обертки уже есть детали. Те самые.
WH>Детали это то что прячет хорошая обертка.

Какие детали прячет обертка вокруг WriteFile?

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

WH>2)Этот интерфейс содержит и Read и Write те имеет input/output сениматику без произвольного доступа что есть маразм.

Имхо,все очень даже логично для последовательного стрима. Для произвольного доступа есть IStream.

Здравствуйте, 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, Вы писали:

A>>А самое инетресное, что посмотрев исходники Вин2К пришел к выводу, что ядро не
>>правилось этак с 96-го года... (ну ессесено драйвера правилились, но основные
>>системы похоже что нет )

MSS>Просто сразу хорошо написали, и все.

MSS>От того, что туда напихают врапперов по WolfHoundу , оно лучше не станет.

За этим дело не встанет... на С уже никто не пишет (ну кроме некоторых) ... а когда надо будет ядро править, придется это на С++ делать .

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

Интересно причем тут это? Он что от оберток над эвентами наследников делел?

ЗЫ

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

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

MSS>Инкапсуляция — это другое. Это отделение интерфейса от имплементации, и запрет лазить к деталям имплементации в обход оговоренного интерфейса.

Гы. Если тебя отделили от реализации , то о побочных эффектах ты принципиально знать не можешь.

Ты снова смотришь на мир со своей колоколни. Слишом низкоуровневой, что ли (?)... А ОО придумывалось не для решения частных задач, а для повышения абстракции. Нормальным положением дел в ООП является мышление на уровне абстракций вроде класса. Его внутреннее поведение — это его проблемы реализации. Тебе важны только предоставляемые возможности. Без доверия в таком случае просто нельзя.

MSS>Синтаксическое упрятывание скрытой семантики к инкапсуляции отношения не имеет. Полно ОО языков (да та же Джава, которая во многом сделана умнее Си++, в ней меньше создающих энтропию вещей) где не бывает "operator T", который вызывается неявно без каких бы то ни было напоминаний.

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

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

>>Слова о вреде полиморфизма слышу впервые.

MSS>А где они?

Разве не ты говорил о том, что в ООЯ найти функцию которая будет вызвана в коде является большой проблемой?

MSS>Нет. Справятся, и справятся так, что потом умный не разберется в их бреде.

Так ты можешь привести хотя бы один широко известный пример данной проблемы?

VD>>МС сделала верный выбор спроектировав Шарп снуля.

MSS>Точнее, скопировав с Джавы в значительной степени.

В такой же степени они скопировали его с дельфи, С++, Васика, Смолтока и т.п. От явы взяты идеи рантайма и библиотек. Да и они нехило переработаны. То же что скопировано в основном очень неплохо. Можешь попытаться найти слабые места...

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

MSS>То-то практически все серьезное (т.е. системное) программирование делают на Си.

Я незнаю чем системное программирование отличается по серьезности от любого другого. Но знаю, точно что мне лично системное программирование не к чему, как 99% других программистов. Все что выходит за рамки ядра ОС и драйверов прекрасно можно писать на Шарпе и дотнете.

Да и не знаю я статистики по системному программированию. Как? например, узнать на чем пишут драйверы ATI и NVidia?

И интересно чем конкретно занимаешся лично ты? Неужели работа моего ПК зависит от твоего труда?

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

VD>>И почему в Шарпе есть все тоже самое, но без макросов?
WH>А то ты не знаешь

И все же? У меня есть своя версия, но хотелось бы услышать и другие мнения.

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

MSS>Не стал бы как представитель компании на публике. В узком кругу — пожалуйста.

Ну, если его слова до сюда добрели значит круг был довольно широкий.

К тому же в 2001 его просто не поняли бы. Дотнет был в бэтах и не связанные с МС люде его заполучить немогли.

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

MSS>Почему? Человек, видимо, имел отношение к разработке микрософтного компилятора Джавы.

Судя по его отношению к ней его как раз в это время выгнали.

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

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

MSS>Ну Джавы — возможно. Там нет operator+ и прочих abstract datatypes наворотов, которые, кстати, к ОО отношения не имеют. Это из другой оперы.

В Яве к сожалению много чего другого нет. Концептуально она чище, но писать на Шарпе приятнее в разы, да и операторы в нем на месте.

MSS>Да. А вон почитай, как тут человек признавался в романтической любви к Си++ именно потому, что там одно и то же можно выразить по-разному

Дык то не романтик, то фанат.
Он просто еще не видел как можно писать програмы быстрее и проще чем текст в конфе...

>>концептуальной стройности

MSS>Си++ ее давно утерял, да и не факт, что имел (в отличие от Джавы и Шарпа).

Так оно и есть. Но почему? Многие сходятся на мнении, что именно из-за наследства С и неразумной борьбой за скорость, а не из-за ОО и т.п.

ЗЫ

Я согласен с тобой когда ты говоришь о граблях, но твои принипы их устранения путем примитивизации инстумента мне не нравятся. Кстати, именно это мне больше всего не нравится и в Яве. Её создатели пошли именно таким путем. Создали концептуально чистый, но пресный и неудобный язык.

Здравствуйте, 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 ОС" и погляди на результаты...

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

MSS>Просто сразу хорошо написали, и все.

Честно говоря не очень то хорошо ее писали. Тупой заем памяти или ресурсов в цикле приводит к полному параличу. И многозадачность далека от идеала. Пора бы им и попробовать переписать все это дело.

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

MSS>Обычный пиар. Было это эдак в 94-95. Тогда была модна идея ОО ОС, которая у всех с треском провалилась — и IBM Workplace OS, и Novell AppWare.

Ну, Next был куда раньше, и ОО там было немало. Да и Лонгхорн очень много от тех концепций поимел...

MSS>На деле — имя cairo использовалось внутри MS как название для DCOM.

Скорее всего DCOM был частью проекта с общим названием каиро. А что до рекламы, то у МС это постоянно. Пару лет назад они были готовы приделать приставку или суфикс .Net к чему угодно.