Здравствуйте, Tilir, Вы писали:
T>Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы разрушим до основанья, а затем... Вот есть большие подозрения, что затем окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал C подмножеством C++. И C++ очень быстро и без лишней агитации подгрёб под себя громадное C-сообщество, которое уже потом, перейдя на C++, потихоньку научилось наследовать классы и пользоваться STL. Аналогично произошло с Delphi и Pascal-подмножеством в нём. Если бы начали делать D и сказали: "любимые наши C++ — разработчики, вот вам C++-подмножество в D, наслаждайтесь. А на досуге, оцените ещё наши новые фичи — туплы, вариативные шаблоны и ещё кучу всякой радости". Да я бы обеими руками был бы за переход на такой язык и начальство бы уговорил.
Ага, однажды пришёл C и разрушил всё до основания. Он предложил некоторые вещи, которые были круче, чем в Фортране. Но C не был надмножеством Фортрана, так что народ, мы идём по неправильному пути! Долой всякие там C/C++/C#! Даёшь Мегафортран с ФВП, лямбдами, замыканиями, метапрограммированием и STL! Но главное, чтобы прога на Фортране была так же прогой на Мегафортране.
Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое" и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mirrorer, Вы писали:
M>Я в свое время делал это на Delphi. И никак не мог понять почему COM программирование считается большим анусом... Потом прочитал книгу Inside COM, посмотрел на реализацию простейшего СОМ сервера на С++. Как бы это помягче выразится.. Впечатления были очень протеворечивые..
Это потому, что Дельфи начиная с 4-ой версии (если не ошибаюсь) поддерживала КОМ на уровне языка, а в С++ все эмулировалось на уровне паттернов.
На дельфи 2.0 писать КОМ-объекты было еще противнее чем на С++, так как оддержики фактически не было, а эмуляция получалась еще более убогая чем на С++.
По большому счету поддеркжу КОМ можно представить как внутренний ДСЛ. И лучше всего тут будет выглядеть язык хорошо поддерживающий встравание внутренних ДСЛ-ей (или содержащий такой ДСЛ, как Дельфи).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Вообще-то, обычно да. Той же JVM/C# приходится сделать достаточно много C>работы для вызова неуправляемого кода — за-pin'ить объекты, сохранить C>контекст GC и т.п.
Ерунду говоришь полнейшую. "Запинить объект" == установить ровно один бит в его заголовке. Никаких контекстов ЖЦ сохранять не нужно.
Другое дело, что форматы дотнета и WinAPI различаются. Так что в не тривильных случаях приходится производить конвертацию данных (маршалинг). Но оные действия приходится производить и в С++-коде. Ведь ты не будешешь оперировать скажем char*, wchar_t* или BSTR. Ты скорее всего скопируешь данные в std::string или его аналог. А это тот же маршалинг. Причем может быть лично ты напишешь код конвертации очень грамотно. А вот В.Пупкин может написать его криво и тормозно. Так что не факт, что дотет тут проиграет.
Рельно скорость маршалинга довольно высока. По крайней мере я за все время его использования не наблюдал ни одногшо солучая когда бы он стал узким местом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinclair, Вы писали:
M>>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков. S>>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.
VD>Совершенно верно. Но можно сказать проще. Миксины/трэйтсы просто меняют структуру классов. Ни для кого не сикрет, что сами методы это просто глобальные фукнции получающие в качестве параметра ссылку на объект нужного типа. Так что миксины/трэйтсы не вызвают оверхэд, а на оборот приводят в итоге к более простым решениям в компиляторе.
VD>Например, для разрешения ссылок на множество базовых классов в С++ часто испльзуется "двойной" указатель (на 32-битных платформах его размер обычно больше 32-х бит). Это вынуждает компилятор порождать код пересчета адресов, что естественно отражается на скорости вызова метода доводя его до скорости вызова интерфейса в дотнете. А раз так, ток каой смысл заниматься всеми этими сложностями?
Это к чему ? Вы думаете это секрет что МН реализуется нетривиально ? Должен вас огорчить, к сожалению Страуструп в курсе. А в целом рекомендую почитать дизайн и эволюцию , про принцыпы C++ "не платим за то , что не используем". Удачи.
VladD2 wrote: > Ерунду говоришь полнейшую. "Запинить объект" == установить ровно один > бит в его заголовке.
Агащаз. Еще надо его добавить в список за-pin'еных объектов. В JVM он
хранится в виде single-linked списка. А это уже overhead.
> Никаких контекстов ЖЦ сохранять не нужно.
Нужно.
> Ведь ты не будешешь оперировать скажем char*, wchar_t* или BSTR. Ты скорее > всего скопируешь данные в std::string или его аналог.
Буду работать с char*, обернутым в мою строку
Здравствуйте, VladD2, Вы писали:
VD>Рельно скорость маршалинга довольно высока. По крайней мере я за все время его использования не наблюдал ни одногшо солучая когда бы он стал узким местом.
Я вот недавно профайлил своё приложение, которое очень интенсивно юзаем COM компоненты и с удивлением обнаружил, что служебный код interop находится в топе списка по сумме времени проведённом в вызове. В итоге я просто попросил профайлер не показывать его мне, ибо без толку — отказаться от использования этих компонент я не могу.
Кстати, есть где-нибудь детальное описание механики .NET-COM interop'а, чтобы знать, что именно там происходит?
Здравствуйте, VladD2, Вы писали:
VD>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++.
Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.
Здравствуйте, VladD2, Вы писали:
VD>Что касается конкуренов С++, то для меня это само по себе смешно. С++ маральный урод. Он устарел еще 10 лет назад. Его испоьзуют не потому что он лучий, а потому, что к нему привыкли и потому что вокруг него море фобий.
Ещё потому, что есть прорва legacy code написанного на нём, которую никто в здравом уме просто так не выбросит, а итероперировать с C++ проще всего на C++
now playing: Impulse & Submerged — Dirty Bomb (Scorn Remix)
Здравствуйте, minorlogic, Вы писали:
M>Это к чему ? Вы думаете это секрет что МН реализуется нетривиально ?
Для кого как.
M> Должен вас огорчить, к сожалению Страуструп в курсе.
Почему это должно меня было огорчить?
M> А в целом рекомендую почитать дизайн и эволюцию
Спасибо за рекомендацию, но я уже читал этот исторический экскурс.
От себя осмелюсь порекомендовать в следующий раз прежде чем давать рекомендации, спрашивать нуждается ли в них тот кому ты их даешь.
M> , про принцыпы C++ "не платим за то , что не используем".
Вот МН замечательный случай когда приходится платить за то что не нужно. Миксины/трэйтсы решают те же проблемы не создавая при этом ненужных накладных рассходов.
Собственно Страуструпу то простительно. Он просто не додумался до более простого и эффективного решения. Ведь трыйтсы били проработаны и описаны только недавно. Но для разработчиков языков сегодня повторение ошибок Страуструпа уже не проститльно. В прочем эти ошибки никто и не повторил (пока что).
M>Удачи.
Спасибо.
ЗЫ
И не надо так оверквотинг.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Ещё потому, что есть прорва legacy code написанного на нём,
Вот это чистейшей воды миф. Практически все API делаются совместимыми с C или одной из VM.
EC> которую никто в здравом уме просто так не выбросит, а итероперировать с C++ проще всего на C++
В здравом уме люди не стали бы писть сегодня на С++. Но они же это делают? Так что апелляция к здравому уму по меньшей мере неуместна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
VD>>Обойтись без компиляции вообще невозможно, так как такова реализация. Так что говоря о дотенете просто бессмысленно рассуждать о байткоде.
M>Если говорить именно о микрсофтовском .Net, то ты несомненно прав. Но ведь спецификация CLR вроде не обязывает иметь JIT или я ошибаюсь ?
CLR — это runtime для Microsoft .Net. Microsoft .Net — это реализация стандарта CLI от Microsoft. Если говорить о CLI, то потенциально, нет. Но серьезной реализацией интерпретатор не считается. В Моно тоже имеется компиляция. В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.
M>З.Ы. В своем посте под .Net я подразумевал именно CLR, а не конкретно MS .Net. возможно из-за этого путаница возникла.
И в очередной раз ошибаешся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Агащаз. Еще надо его добавить в список за-pin'еных объектов. В JVM он C>хранится в виде single-linked списка. А это уже overhead.
Мне плевать на JVM. В дотнете никаких списков нет. Это ровно один бит расположенный рядом с битом использованием для пометки объекта как посещенного. Так что у тебя проблемы с матчастью.
>> Никаких контекстов ЖЦ сохранять не нужно. C>Нужно.
ОК. Подверди, плиз свои утверждения. Сразу предупреждаю, чно кивать на Яву не надо.
>> Ведь ты не будешешь оперировать скажем char*, wchar_t* или BSTR. Ты скорее >> всего скопируешь данные в std::string или его аналог. C>Буду работать с char*, обернутым в мою строку
Ладно. Тебе можно. Работай с BSTR и char* обернутые в твою троку. Главное незабудь сказать когда этот софт будут запускать на АЭС.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Я вот недавно профайлил своё приложение, которое очень интенсивно юзаем COM компоненты и с удивлением обнаружил, что служебный код interop находится в топе списка по сумме времени проведённом в вызове. В итоге я просто попросил профайлер не показывать его мне, ибо без толку — отказаться от использования этих компонент я не могу.
Думаю, твой профайлер показывал не время именно интеропа, а время проведенное вне управляемого кода.
EC>Кстати, есть где-нибудь детальное описание механики .NET-COM interop'а, чтобы знать, что именно там происходит?
В одном из старых номеров МСДН Маг-а (анклийсгого) была статья по этому повду.
А вообще, все сильно зависит от типов данных. Скажем для массива байтов вообще маршалинг не требудется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, minorlogic, Вы писали: M>Я встречал людей делящихся на 2 типа по отношению к МН, те которые его понимают и те которые его просто не знают. А вы мне говорите про какие то сложности ? Видимо вы исключение из правил.
Если честно, я не понял, про что эта фраза. Да, я понимаю, как работает МН в С++. Я это вообще в университете преподавал. И естественно, я думаю, что МН в С++ — это нелепое нагромождение компромиссов. Да, я в курсе, почему и зачем оно так сделано. Это всего лишь демонстрация того, как неверно сделанное в начале предположение приводит к кривому и запутанному дизайну.
M>Классический пример — наследование реализации для иерархии интерфейсов.
Конкретнее можно? Покажите мне, где я буду наследоваться от одного и того же класса и невиртуально и виртуально? Чтобы вот эта процитированная фраза реально применилась:
If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.
S>>Все эти правила призваны всего лишь разрулить неопределенности, возникающие из-за самой идеи двух видоа наследования. Никакой практической полезности в них нет. M>Для вас нет ?
Я признаю их полезность как только мне ее продемонстрируют. Где она? Мое мнение: в реальной жизни это не применяется.
M>>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков. S>>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов. M>Не факт , но мне хочется иметь возможность выбрать , а вам ?
Выбрать что? Мне хочется иметь возможность не выбирать. Меня вполне устраивает ситуация, в которой такие вещи, как инлайнинг кода, выбирает компилятор. Никакого требования копировать код в миксинах нету. Есть масса альтернативных стратегий. Лишь бы семантика была та же самая.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
1.2.0 alpha rev. 655
Если нам не помогут, то мы тоже никого не пощадим.
