Здравствуйте m.a.g., Вы писали:
VD>>Значит все таки не всё... mag>Все, что можно реализовать на C# — точно
Теоритически. На практике может банально не хватить времени и сил.
VD>>Во-во. Существует большое количество чего угодно. Но у меня вот, даже самые опытные программисты время от времени проходятся по памяти.
mag>А для этого есть Bounds Checker и прочее. Для профилактики разок запустить раз в день — все отлавливается превосходно.
Существует. И мы его пользуем. Но к сожалению он не ловит все пролем. Да и выявить с его помощью ошибки можно далеко не все. В общем, жизнь показывает, что если есть возможность сделать ошибку, то она обязательно будет сделана.
mag>О резкой смене темы. В исходном сообщении было про бейсик и перл, про бейсик сказал, а вот про перл умолчал, вроде бы ненамеренно...
Вообще-то в исходном сообщении было про С++. Ну, а ты говорил о строгой типизации. Которй "нет" в бэйсике и перле. Про перл я и не спорю.
mag>>>Это проблемы не C++, а COM VD>>Аааа. Я то думал — это попытки обойти проблемы C++ связанные с тем что язык вообще не ориентирован на связь с рантаймом.
mag>Не понял фразу. Что есть "связь с рантаймом"?
А то и есть. Все проверки в С++ делаются во время компиялции. Для остальных случаев предлагается вручную шарить по памяти. Это прошлый век. На сегдня нужно использовать рантайм-сервисы типа рефлекшена (динамической информации о типах).
mag>>>, который к C++ отношения не имеет. VD>>Надо мужикам рассказать... До тебя все думали, что COM писали на C++ и, что у C++ было взято очень многое.
mag>А какая разница на чем писано?
Да! Вот! Какая разница... И что же ты тогда к этому С++ прилип?
mag>Главное, что пытались сделать универсальную систему, вот она такой уродливой и получилась
Она свои задачи прекрасно решает. Уродливой она выглядит из-за полного отсутствия в тогдашних языках какой-либо рантайм-поддержки.
Ты можешь предложить замену для QI? Да так чтобы она не противоречила пипизации С++ и была доступна из других языков и в рантайме?
mag>, ведь если делать что-либо унифицированно для многих языков, то будешь ограничен пересечением возможностей всех этих языков.
Вот и был изобретен .NET где сразу оговариваются (стандартизуются) некоторые моменты. Т.е. вместо того чтобы подгонять компонентную модель под устаревшие языки было принято решение предявить некоторые требования к самим языкам.
mag>>>Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель. VD>>Ты бы ссылку дал, что ли...
mag>Да загнулся он, из-за плохого менеджмента
Жаль. А то COM получатся единственная (если не считать Яву и .NET) компонентная технология дожившая до зрелости.
VD>>Если этот твой сом такой крутой. Что же о нем никто не знает? Она хоть сколько языков поддерживает. И как реализует информацию о типах для рантайма?
mag>Почему никто не знает — см. выше. mag>Поддерживает она все, на что есть маппинг OMG IDL.
OMG IDL к компонентам никакого отношения не имеет. Он был создан для CORBA. Ну, а CORBA — это действительно разновидность объектного RPC.
mag>В метаклассах.
Т.е. бинарной совместимости там не было?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
S>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.
Мне, кстити, больше ненравится не прямой вызов деструктора, а прямой вызов конструктора. Ну и общее применение одного экземпляра объекта для двух виртуальных объектов. Одно дело симантика подключить/отключить, а другой рукопашный вызов конструктора. Хотя невозможность вызова виртульных методов из деструктора в С++ наталкивает на подобный код. Но это всего лишь еще один недостаток языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
S>Ну все, на стенку полез :) Нормальная библиотека. А вот чем тебе не понравились две строчки стандартного S>кода на С++, я не пойму.
Тем что это, как сказал один аноним, хакерство. Хотя и отвечающее стандарту. Такой код трудно воспринимать. Экономия от него не большая, а вот проблем с пониманием он может вызвать не мало. Не очень понимаю, почему нельзя быо создать новый экземпляр и присвоить его этому. Ну, или еще как нибудь по-человечески. В конце концов есть такое правило — "не удивляй без крайней необходимости.".
S>Дык что самое смешное, так и делаем. Пишу, например, манипуляторы вывода для специфичных типа в basic_ostream. Все работает, все замечательно. Через некоторое время (месяца два) использую эти классы в другом месте — все работает ровно до тех пор, пока в одной из функций не объявляю локальную переменную типа CString. После чего — internal compiler error :))
Ну, глючат все компиляторв. Это же ведь программы. Я как-то раз задал пол часа не мог понять почему gcc вылетает при компиляции. Потом переставил переменные местами и все зарабтало.
S>Через день траха и шаманства (код то был рабочий, и переписывать/по новой отлаживать его влом) меняю basic_ostream на ostream (если ты забыл, это специализация basic_ostream<char, char_traits<char> > ) — все компиляется. Вот такой вот прикольный компилятор :???: Шаблоны ему слишком сложными показались, мать его...
У нас почти все на шаблонах и проблем не видно.
S>Много всего есть в виде C++ классов с открытым кодом нахаляву. Гораздо лучше чем кот в мешке за немалые деньги.
Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.
S>Посмотрим.
Посмотрим...
S>Но вот сколько клиентов мы потеряли, включив в дистрибутив MDAC 2.6...
И сколько же? Я так понимаю вместо этого можно было датастрим ручками разбирать?
S>>>Угу, только 99% этих компонентов написаны одной фирмой.
VD>>Ну, не приувеличивай. Есть еще пара сотен компаний специализирующихся на компонентах. Самые большие (Инфрагистик, Видеософт, ...) зарабатывают на этом немалые деньги. Их продукцией пользуются миллионы прогаммистов во всем мире.
S>А этот прием ведения дискуссии называется демагогией — речь шла о компонентах
Ты задал — вопрос используем ли мы компоненты других производителей. Я сказал — да. Ты сказал — что все компоненты делаются одним производителем. Я сказал — нет. Где здесь демогогия?
S>, из которых состоит полвинды. Ты хочешь сказать, что MS использует в винде компоненты более чем двух сотен компаний, причем именно в качестве компонентов, т.е. не имея исходного кода?
А вот это уже и в правду демогогия. Кстит MS действительно использует чужие компоненты. Правда конечно не всех 200 производителей.
VD>>Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.
S>Только потом хер чего работать будет :) Причем сразу ты этого не заметишь :)
У нас все работает. Может проблема в руках людей делающих инсталляторы?
S>И для MS это не компоненты, поскольку у нее есть исходные коды, а не только сигнатуры/документация.
Класс! Значит компонент — это или нет определяется наличием у тебя исходников. Ну, а как же быть с компонентами которые поставляются вместе с исходниками?
S>Ну, скажем, процедурное программирование пришло на смену spagetti.
А последнее это парадигма? :)
S> Ты хочешь сказать, среднее количество ошибок на килобайт екзешника при этом не уменшилось?
Я хочу сказать, что если сравнить процедурное программирование и ОО, то количество ошибок будет одинаковым и зависящем от класса программиста, используемого языка, качества транслятора, качества библиотек, и еще тучи параметров. В С++, к примеру, ты можешь спрятать управление жизнью ресурсом в конструктор и деструктор обертки. А в ОПасклае нет. Так как деструктор нужно вызывать вручную. Если же сравнивать компонентный подход... Да с чем его вообще можно сравнивать? Он пока что единственный для решения этого класса задач.
S>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?
Ну глупость утверждаешь. Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.
VD>>Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.
S>Орфографию проверять и печатать ему второй процессор не помогает, надо полагать?
Ты когда нибудь открывал в ворде большие документы? Вот я тебе могу сказать, что разницы в количестве процессоров не чувствется. Что есть второй процессор, что нет. :( Проверка же орфографии тоже особо не ускоряется, да и толку от нее нет. На больших документах она все равно отключается. Зато ускорение процессора дает ощутимый результат.
VD>>Для серверного рантайма есть. Клиентский они почему-то считают однопроцесорным.
S>Что именно? И правда интересно.
Ну, открывай мсдн и читай. Или дезасемблируй Анакриной. В основном как я понимаю там оптимизация GC, но наворотили они не моло.
S>Есть в posix и boost, этого почти достаточно.
Я не знаю кому достаточно, но вот софта маштабируемого раз два и обчелся. Если .NET переломит эту ситуация, я буду тлько рад. Ну, а нет, так хуже уже точно не будет. В конце концов работать с потоками в .NET уже сегодня намного проще чем на С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
... VD>Жаль. А то COM получатся единственная (если не считать Яву и .NET) компонентная технология дожившая до зрелости.
... VD>OMG IDL к компонентам никакого отношения не имеет. Он был создан для CORBA. Ну, а CORBA — это действительно разновидность объектного RPC.
По-моему COM-Java и COM-.NET неправильное противопоставление (сравнение). DCOM-CORBA более логично. Следовательно в Ваших словах намечается противоречие:
либо COM — компонентная технология, значит и CORBA не просто OO RPC;
либо CORBA просто OO RPC, а значит и COM.
Как считаете?
(Замечание на последок. В спецификации 2.6 OMG CORBA появилась компонентная технология. Реализации ростут как на дрожжах.)
Здравствуйте epflorov, Вы писали:
E>По-моему COM-Java и COM-.NET неправильное противопоставление (сравнение). DCOM-CORBA более логично. Следовательно в Ваших словах намечается противоречие: E>либо COM — компонентная технология, значит и CORBA не просто OO RPC;
А кто сказал что COM == DCOM? DCOM — это расширение COM-а позволяющее таскать данные по сети. Т.е. это ORPC для COM. CORBA — это чистый ORPC. В новой вестии вроде намечались какие-то компонентные расширения. Но я пока их не видел.
E>либо CORBA просто OO RPC, а значит и COM. E>Как считаете?
Считаю что у вас произошла подмена понятий.
E>(Замечание на последок. В спецификации 2.6 OMG CORBA появилась компонентная технология. Реализации ростут как на дрожжах.)
Вот когда их увидим, то и говорить будем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
mag>>Почему никто не знает — см. выше. mag>>Поддерживает она все, на что есть маппинг OMG IDL.
VD>OMG IDL к компонентам никакого отношения не имеет. Он был создан для CORBA. Ну, а CORBA — это действительно разновидность объектного RPC.
Но, тем не менее, интерфейсы SOM описывались (к сожалению, в прошедшем времени) на OMG IDL.
mag>>В метаклассах.
VD>Т.е. бинарной совместимости там не было?
Нет. Была идея сделать небольшую и красивую компонентную модель специально для C++.
VD>>Т.е. бинарной совместимости там не было?
mag>Нет. Была идея сделать небольшую и красивую компонентную модель специально для C++.
Или это компонентная модель. Или это "специально для C++". Мне не нужна компонентная модель для одного языка. Мы делаем комерческие проекты, а не пишим для души.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>Ну все, на стенку полез :) Нормальная библиотека. А вот чем тебе не понравились две строчки стандартного S>>кода на С++, я не пойму.
VD>Тем что это, как сказал один аноним, хакерство. Хотя и отвечающее стандарту. Такой код трудно воспринимать. Экономия от него не большая, а вот проблем с пониманием он может вызвать не мало. Не очень понимаю, почему нельзя быо создать новый экземпляр и присвоить его этому. Ну, или еще как нибудь по-человечески. В конце концов есть такое правило — "не удивляй без крайней необходимости.".
А еще есть правило — не вводить новые сущности без необходимости и не выполнять действия, нужды в которых нет. Если у кого-то проблемы с пониманием шаблонов C++, так что мне, и их не использовать?
S>>Дык что самое смешное, так и делаем. Пишу, например, манипуляторы вывода для специфичных типа в basic_ostream. Все работает, все замечательно. Через некоторое время (месяца два) использую эти классы в другом месте — все работает ровно до тех пор, пока в одной из функций не объявляю локальную переменную типа CString. После чего — internal compiler error :))
VD>Ну, глючат все компиляторв. Это же ведь программы. Я как-то раз задал пол часа не мог понять почему gcc вылетает при компиляции. Потом переставил переменные местами и все зарабтало.
Ну так я о чем и толкую — весьма посредственный компилятор этот VC 6.0. Явно не заслуживающий своей популярности.
S>>Через день траха и шаманства (код то был рабочий, и переписывать/по новой отлаживать его влом) меняю basic_ostream на ostream (если ты забыл, это специализация basic_ostream<char, char_traits<char> > ) — все компиляется. Вот такой вот прикольный компилятор :???: Шаблоны ему слишком сложными показались, мать его...
VD>У нас почти все на шаблонах и проблем не видно.
Значит, не слишком навороченные шаблоны используете.
S>>Много всего есть в виде C++ классов с открытым кодом нахаляву. Гораздо лучше чем кот в мешке за немалые деньги.
VD>Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.
Вот комовских контейнеров я и вправду не видал — не любит OpenSource community за рамки языков выходить. Зато есть почти все, чтобы обходиться без COM.
S>>Но вот сколько клиентов мы потеряли, включив в дистрибутив MDAC 2.6...
VD>И сколько же?
Да около сотни, наверное.
VD>Я так понимаю вместо этого можно было датастрим ручками разбирать?
Датастрим — это где? MDAC у нас потянулся из-за грида, который был нужен, чтоб показывать данные нашего же OLE DB провайдера. Выкинули с радостью и грид, и MDAC.
S>>>>Угу, только 99% этих компонентов написаны одной фирмой.
VD>>>Ну, не приувеличивай. Есть еще пара сотен компаний специализирующихся на компонентах. Самые большие (Инфрагистик, Видеософт, ...) зарабатывают на этом немалые деньги. Их продукцией пользуются миллионы прогаммистов во всем мире.
S>>А этот прием ведения дискуссии называется демагогией — речь шла о компонентах
VD>Ты задал — вопрос используем ли мы компоненты других производителей. Я сказал — да. Ты сказал — что все компоненты делаются одним производителем. Я сказал — нет. Где здесь демогогия?
Видимо, тв и вправду забыл, о чем речь шла. Напоминаю — не о тех компонентах, которые вы используете, а о тех, из которых винда состоит:
VD>Ты случам не с Салярки пишешь? Вот и мне кажется из IE запушенного под одной из версий Виндов. Так вот они почти полностью из компонентов состоят. И как видишь живут. Про падучесть это форменный предрассудок.
S>Угу, только 99% этих компонентов написаны одной фирмой. Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от S>компонентного подхода, IMHO.
S>>, из которых состоит полвинды. Ты хочешь сказать, что MS использует в винде компоненты более чем двух сотен компаний, причем именно в качестве компонентов, т.е. не имея исходного кода?
VD>А вот это уже и в правду демогогия. Кстит MS действительно использует чужие компоненты. Правда конечно не всех 200 производителей.
Угу, и исходники MS из сторонних поставщиков тоже вытрясти не в состоянии :)
VD>>>Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.
S>>Только потом хер чего работать будет :) Причем сразу ты этого не заметишь :)
VD>У нас все работает. Может проблема в руках людей делающих инсталляторы?
Только конечному пользователю это уже не интересно — ему систему переставлять надо :)
S>>И для MS это не компоненты, поскольку у нее есть исходные коды, а не только сигнатуры/документация.
VD>Класс! Значит компонент — это или нет определяется наличием у тебя исходников. Ну, а как же быть с компонентами которые поставляются вместе с исходниками?
S>>Ну, скажем, процедурное программирование пришло на смену spagetti.
VD>А последнее это парадигма? :)
Не худшая парадигма, чем анархия :)
S>> Ты хочешь сказать, среднее количество ошибок на килобайт екзешника при этом не уменшилось?
VD>Я хочу сказать, что если сравнить процедурное программирование и ОО, то количество ошибок будет одинаковым и зависящем от класса программиста, используемого языка, качества транслятора, качества библиотек, и еще тучи параметров. В С++, к примеру, ты можешь спрятать управление жизнью ресурсом в конструктор и деструктор обертки. А в ОПасклае нет. Так как деструктор нужно вызывать вручную. Если же сравнивать компонентный подход... Да с чем его вообще можно сравнивать? Он пока что единственный для решения этого класса задач.
S>>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?
VD>Ну глупость утверждаешь.
Ну тогда признавайся — сколько раз тебе приходилось в отладчике внутри, скажем, MFC'шного кода лазить? И это при вполне добротной документации, практически лучшей в отрасли. Сколько времени тебе наличие исходников сэкономило?
VD> Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.
А зачем мне что-то в рантайме парсить и вызывать? Чем хуже жесткий набор интерфейсов?
VD>>>Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.
S>>Орфографию проверять и печатать ему второй процессор не помогает, надо полагать?
VD>Ты когда нибудь открывал в ворде большие документы? Вот я тебе могу сказать, что разницы в количестве процессоров не чувствется. Что есть второй процессор, что нет. :( Проверка же орфографии тоже особо не ускоряется, да и толку от нее нет. На больших документах она все равно отключается. Зато ускорение процессора дает ощутимый результат.
И че, переписанный под .нет он летать на двухпроцессорной тачке начнет? С чего бы вдруг?
S>>Что именно? И правда интересно.
VD>Ну, открывай мсдн и читай. Или дезасемблируй Анакриной. В основном как я понимаю там оптимизация GC, но наворотили они не моло.
Ну здрасте — я думал мы про Фому беседуем, а ты оказывается, про Ерему :) При чем тут оптимизация GC, если в C++ GC мало кому нужен?
Ты тут чуть ли не про AI рассказывал, а оказывается — это всего лишь реализация многопоточного GC (нетривиальная, должно быть, штука).
S>>Есть в posix и boost, этого почти достаточно.
VD>Я не знаю кому достаточно, но вот софта маштабируемого раз два и обчелся. Если .NET переломит эту ситуация, я буду тлько рад. Ну, а нет, так хуже уже точно не будет. В конце концов работать с потоками в .NET уже сегодня намного проще чем на С++.
Ну дак если .NET сама не умеет потоки плодить (в том же qsort) по числу процессоров, то о каком переломе ситуации идет речь?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.
VD>Есть такая штука — культура программирования. :) Ну, а ошибок больше там где грязнее код. Хотя это тоже всего лишь наблюдения.
Именно. А код тем грязнее, чем больше в нем ненужных объектов и указателей :)
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.
VD>Мне, кстити, больше ненравится не прямой вызов деструктора, а прямой вызов конструктора.
И правильно не нравиться. Прямой вызов конструктора — хак, не поддерживаемый языком (но допускаемый некотороми компиляторами). Вместо этого есть placement new.
VD>Ну и общее применение одного экземпляра объекта для двух виртуальных объектов. Одно дело симантика подключить/отключить, а другой рукопашный вызов конструктора. Хотя невозможность вызова виртульных методов из деструктора в С++ наталкивает на подобный код. Но это всего лишь еще один недостаток языка.
Прекрасная теория на голом месте. Объект мне там был нужен ровно один, просто ему (это битмап для сохранения куска изображения) надо было поменять размер, чего битмэп не поддерживает :).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Sergey, Вы писали:
S>А еще есть правило — не вводить новые сущности без необходимости и не выполнять действия, нужды в которых нет.
И к чему здесь это? Да и вообще что ты под сущьностями здесь понимаешь?
S>Если у кого-то проблемы с пониманием шаблонов C++, так что мне, и их не использовать?
Да и под шаблонами?
А вообще... плюй на все лепи как получается. Код же пишится не для того чтобы его читали другие!
S>Ну так я о чем и толкую — весьма посредственный компилятор этот VC 6.0. Явно не заслуживающий своей популярности.
Он ее уже заслужил. Для работы и его за глаза хватает. Он делался в 96-97 коду и для тех времен он был очень даже ничего. Теперь есть VC7 он по новее.
VD>>У нас почти все на шаблонах и проблем не видно.
S>Значит, не слишком навороченные шаблоны используете.
А нам работать нужно, а не выпендриваться. Проблемы свои решаем. Остальное не наше дело.
VD>>Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.
S>Вот комовских контейнеров я и вправду не видал — не любит OpenSource community за рамки языков выходить. Зато есть почти все, чтобы обходиться без COM.
Да нихрена путного там нет. Одни игры студентов. Вон Моно уже год делают и что толку?
S>Датастрим — это где? MDAC у нас потянулся из-за грида, который был нужен, чтоб показывать данные нашего же OLE DB провайдера. Выкинули с радостью и грид, и MDAC.
Да ребят что-то у вас там совсем криво. Какой же смысл в OLE DB если ADO не используется? И как же вы без грида то? Хотя можно было бы его и самим написать...
S>Угу, и исходники MS из сторонних поставщиков тоже вытрясти не в состоянии :)
А какая разница? Компонент интересен своей отчуждаемостью, а не тем есть ли у него исходники или нет.
VD>>У нас все работает. Может проблема в руках людей делающих инсталляторы?
S>Только конечному пользователю это уже не интересно — ему систему переставлять надо :)
Ну, значит найдет поставцика котоый сделает не только систему но и инсталлятор к ней. ;)
S>>>Ну, скажем, процедурное программирование пришло на смену spagetti.
VD>>А последнее это парадигма? :)
S>Не худшая парадигма, чем анархия :)
А мне кажется это она и есть.
S>>>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?
VD>>Ну глупость утверждаешь.
S>Ну тогда признавайся — сколько раз тебе приходилось в отладчике внутри, скажем, MFC'шного кода лазить?
Ни разу. Я MFC не люблю. Но какое это отношение имеет к твоему утверждению?
S> И это при вполне добротной документации, практически лучшей в отрасли. Сколько времени тебе наличие исходников сэкономило?
Да я не против наличия исходников. Но, ни наличие, ни отсуствие исходников к С++ не изменит того факта, что язык морально устарел и ребует реформы. :)
VD>> Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.
S>А зачем мне что-то в рантайме парсить и вызывать? Чем хуже жесткий набор интерфейсов?
Тем что все что ты пишишь будет компилирваться как единая сущьность. Вот у нас проекты по двадцать минут копиилируются. Виндовс вобще часами... Ну, еще к твоей программе никто расширение сделать не сможет. Да моного у компонентный технолгий приимуществ. Убеждать тех кто считает, что это никчемная идея я не буду. Вон на ixbt есть Рыбинкин. Так он вообще считает, что С++ это извращение идей ОО и вообще уродство, а С (и его убогий интерпретатор на массивах) лучшее в мире средство разработки. Его всем миром пытались убедить в обратном, но никакого толку в этм нет. Если моги приросли к старому и на горизонте нет задач которые были бы сложенее чем те что ты уже решал, то понять зачем нужно новое невозможно. Вот понадобятся тебе атрибуты компонентной технологии, вот тогда ты и сам задумешься изобретать ли тебе велосипед или взять готовый.
S>И че, переписанный под .нет он летать на двухпроцессорной тачке начнет? С чего бы вдруг?
Дык люди всю рантайм-подсистему для этого затачивают.
S>Ну здрасте — я думал мы про Фому беседуем, а ты оказывается, про Ерему :) При чем тут оптимизация GC, если в C++ GC мало кому нужен?
Он многим там нужнет. Вот только встроить его туда безшовно без изменения языка невозможно. Слабоват язык. Расширяется хреново, а Страуступ перешел в стан консерваторов. :)
S>Ты тут чуть ли не про AI рассказывал, а оказывается — это всего лишь реализация многопоточного GC (нетривиальная, должно быть, штука).
Я сразу сказал, что сделано на сегодня не много. Но уже хоть что-то. В обычном мире (анмэнеджет) и того нет.
S>Ну дак если .NET сама не умеет потоки плодить (в том же qsort) по числу процессоров, то о каком переломе ситуации идет речь?
Дык вот они и делают рантайм который будет учитывать особенности железа.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
VD>>Есть такая штука — культура программирования. Ну, а ошибок больше там где грязнее код. Хотя это тоже всего лишь наблюдения.
S>Именно. А код тем грязнее, чем больше в нем ненужных объектов и указателей
Понимаешь ли в чем дело?... Объектов должно быть не много и не мало, а в самый раз. И указатли нужы только там где они нужны. И грязь появляется там где человек не хочет думать о коллективе в котором он работает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>А вообще... плюй на все лепи как получается. Код же пишится не для того чтобы его читали другие!
Ладно, эта тема исчерпала себя.
S>>Ну так я о чем и толкую — весьма посредственный компилятор этот VC 6.0. Явно не заслуживающий своей популярности.
VD>Он ее уже заслужил. Для работы и его за глаза хватает. Он делался в 96-97 коду и для тех времен он был очень даже ничего.
И ни в одном из пяти сервис паков практически ни одну серьезную ошибку, связанную с шаблонами, не исправили.
VD>Теперь есть VC7 он по новее.
И почти такой же убогий :) Не, кое-что, конечно поправили, но ключевые фичи шаблонов до сих пор не поддерживаются. Blitz++ под него не компилиться (абыдна), от буста — только половина (еще абыдней).
VD>>>У нас почти все на шаблонах и проблем не видно.
S>>Значит, не слишком навороченные шаблоны используете.
VD>А нам работать нужно, а не выпендриваться. Проблемы свои решаем. Остальное не наше дело.
Проблемы у всех разные.
VD>>>Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.
S>>Вот комовских контейнеров я и вправду не видал — не любит OpenSource community за рамки языков выходить. Зато есть почти все, чтобы обходиться без COM.
VD>Да нихрена путного там нет. Одни игры студентов. Вон Моно уже год делают и что толку?
Надо просто смотреть на те проекты, которые лет пять-десять делают :) Если их за это время не забросили, значит жить будут.
S>>Датастрим — это где? MDAC у нас потянулся из-за грида, который был нужен, чтоб показывать данные нашего же OLE DB провайдера. Выкинули с радостью и грид, и MDAC.
VD>Да ребят что-то у вас там совсем криво. Какой же смысл в OLE DB если ADO не используется? И как же вы без грида то? Хотя можно было бы его и самим написать...
OLE DB юзается напрямую, грид теперь свой, затраты на поддержку этого кода стремятся к нулю. А если клиентам нужен доступ к нашему провайдеру через ADO, пусть сами его ставят — мы тут не причем, все вопросы к MS :) Конечно, такие перлы как MDAC 2.6 MS не часто выдает, но вот последствия от них уж больно неприятные.
S>>Угу, и исходники MS из сторонних поставщиков тоже вытрясти не в состоянии :)
VD>А какая разница? Компонент интересен своей отчуждаемостью, а не тем есть ли у него исходники или нет.
Я совсем не против компонентов с исходниками :) Только таких что-то не попадается...
S>>>>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?
VD>>>Ну глупость утверждаешь.
S>>Ну тогда признавайся — сколько раз тебе приходилось в отладчике внутри, скажем, MFC'шного кода лазить?
VD>Ни разу. Я MFC не люблю. Но какое это отношение имеет к твоему утверждению?
Утверждение простое — единственным полным описанием компонента является его исходный код. Впрочем, вру — исполняемый модуль тоже является полным описанием, но малопригодным для человеческого восприятия. Так вот, компонентная модель не требует наличия исходного кода у пользователя компонента, а потому ущербна и применение ее на практике чревато большими издержками. Вопрос только в том, когда издержки больше — если ее применять или не применять, цены разные в каждом конкретном случае.
S>> И это при вполне добротной документации, практически лучшей в отрасли. Сколько времени тебе наличие исходников сэкономило?
VD>Да я не против наличия исходников. Но, ни наличие, ни отсуствие исходников к С++ не изменит того факта, что язык морально устарел и ребует реформы. :)
Я тоже не отрицаю того факта, что в C++ много не хватает. Но GC уж точно не является самой востребованной фичей.
VD>>> Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.
S>>А зачем мне что-то в рантайме парсить и вызывать? Чем хуже жесткий набор интерфейсов?
VD>Тем что все что ты пишишь будет компилирваться как единая сущьность. Вот у нас проекты по двадцать минут копиилируются. Виндовс вобще часами... Ну, еще к твоей программе никто расширение сделать не сможет. Да моного у компонентный технолгий приимуществ. Убеждать тех кто считает, что это никчемная идея я не буду. Вон на ixbt есть Рыбинкин.
Угу, а в фидо обитает Луговский, так он ничего, кроме функциональных языков не переваривает и вообще ведет себя неадекватно. Ну и что с того?
VD>Так он вообще считает, что С++ это извращение идей ОО и вообще уродство, а С (и его убогий интерпретатор на массивах) лучшее в мире средство разработки.
Я тоже считаю, что C++ — это коммерчески успешное извращение идей ОО. Уродства в C++ тоже хватает. А C — вообще древнее убожество. Не видел, правда, С99, но думаю, и там ситуация не сахар. Только вот ничего более путного пока, к сожалению, не сделали. И вряд ли в ближайшем будущем сделают. Хотя могли бы.
VD>Его всем миром пытались убедить в обратном, но никакого толку в этм нет. Если моги приросли к старому и на горизонте нет задач которые были бы сложенее чем те что ты уже решал, то понять зачем нужно новое невозможно.
Я ж не говорю, что новое не нужно. Я говорю, что сделали это новое как всегда, а не как лучше. Отобрали больше, чем добавили.
VD>Вот понадобятся тебе атрибуты компонентной технологии, вот тогда ты и сам задумешься изобретать ли тебе велосипед или взять готовый.
Из того, что я не люблю компонентную технологию, вовсе не следует, что я ее не использую. Только приходиться трижды подумать, что именно применять и во что это обойдется.
S>>И че, переписанный под .нет он летать на двухпроцессорной тачке начнет? С чего бы вдруг?
VD>Дык люди всю рантайм-подсистему для этого затачивают.
В чем именно эта заточка заключается? Про GC я уже слышал.
S>>Ну здрасте — я думал мы про Фому беседуем, а ты оказывается, про Ерему :) При чем тут оптимизация GC, если в C++ GC мало кому нужен?
VD>Он многим там нужнет. Вот только встроить его туда безшовно без изменения языка невозможно.
Безболезненно GC вообще никуда не встроить. C GC ведь не определен момент вызова деструкторов, что очень фигово при работе с внешними объектами. Так что или Finilize руками вызывай, или delete не забывай писать — хрен редьки не слаще.
VD>Слабоват язык. Расширяется хреново, а Страуступ перешел в стан консерваторов. :)
Это еще вопрос, кто больший консерватор — Страуступ или Мокрософт. Они б сначала для имеющегося языка компилятор реализовали, а потом новые идеи толкали. Подозреваю, что в комитете им примерно это же и сказали бы, если б они туда с новшествами сунулись.
S>>Ты тут чуть ли не про AI рассказывал, а оказывается — это всего лишь реализация многопоточного GC (нетривиальная, должно быть, штука).
VD>Я сразу сказал, что сделано на сегодня не много. Но уже хоть что-то. В обычном мире (анмэнеджет) и того нет.
В обычном мире это просто не нужно.
S>>Ну дак если .NET сама не умеет потоки плодить (в том же qsort) по числу процессоров, то о каком переломе ситуации идет речь?
VD>Дык вот они и делают рантайм который будет учитывать особенности железа.
И что, этот рантайм будет плодить потоки без участия программиста, ориентируясь по контексту вычислений? Когда MS реализует это в своем рантайме, железо будет само учитывать свои особенности :) Оно уже сейчас зачастую делает это лучше софта.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
[...]
ГВ>>ИМХО, больше похоже на попытку причесать все языки под одну гребёнку .NET :maniac:
А>сам-то понял, чё написал?
Конечно. Вот ещё раз CLS перечитаю, если найду. И докажу. ;) Возможно.
А>опять сказки про злого Дядю Билла, который всех "причесывает"...
И то верно — он никого не причёсывает, все сами "причёсываются". ;)
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>И то верно — он никого не причёсывает, все сами "причёсываются".
Интересно, когда Страус все причесывает своими кривыми идеями, то это нормально и называется "стандартизация", ну, если MS стандарты клепать начинает, то это называется "причесывание всех под одну гребенку" и "угнетение невинно обиженных".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Геннадий Васильев, Вы писали:
ГВ>>И то верно — он никого не причёсывает, все сами "причёсываются". ;)
VD>Интересно, когда Страус все причесывает своими кривыми идеями, то это нормально и называется "стандартизация", ну, если MS стандарты клепать начинает, то это называется "причесывание всех под одну гребенку" и "угнетение невинно обиженных". :)))
Во-первых, не один Страус. Там ещё и комитет ANSI есть.
А во-вторых — ИМХО, Страус больше апеллирует к интеллектуальности, а MS — к её отсутствию. Типа: "Вот вам рецепт и всем срочно радоваться!" Вторая позиция понятна для продавцов, но... программисты, ИМХО, всё-таки больше тяготеют к первому.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Во-первых, не один Страус. Там ещё и комитет ANSI есть. ГВ>А во-вторых — ИМХО, Страус больше апеллирует к интеллектуальности, а MS — к её отсутствию. Типа: "Вот вам рецепт и всем срочно радоваться!" Вторая позиция понятна для продавцов, но... программисты, ИМХО, всё-таки больше тяготеют к первому.
Да к маразму старческому (не по годам) этот Страуструп апеллирует. А MS решает проблемы кторые перед ней стаят. Этот орел как то ляпнул, что мол GC интересная и хорошая идея, но мол, ее легко можно реализовать средствами языка. Вот Мишка.Нэт попробывал риалзоват... вошло как у тебя, много кода и совершенно не применимо на практике.
Хочет решать проблемы средствами самого языка? Пожалуйста... только пусть этот язык расширят, чтобы можно было делать то что нужно. И не через одно место автогеном, а просто и лаконично.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
