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

D>Приходилось, все же с ATL удобнее. С Microsoft всегда удобно работать через инструменты от Microsoft, но на этом все заканчивается.
D>Да и причем тут COM — что, это панацея? Многие CORBA используют.
D>Да, за счет множественно наследования и неудачной организации процесса обработки сообщений, библиотеки ATL, MFC, WTL не годятся для современных языков. Приходилось мне, естественно, достаточно долго работать с каждой из этих библиотек.

Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы разрушим до основанья, а затем... Вот есть большие подозрения, что затем окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал C подмножеством C++. И C++ очень быстро и без лишней агитации подгрёб под себя громадное C-сообщество, которое уже потом, перейдя на C++, потихоньку научилось наследовать классы и пользоваться STL. Аналогично произошло с Delphi и Pascal-подмножеством в нём. Если бы начали делать D и сказали: "любимые наши C++ — разработчики, вот вам C++-подмножество в D, наслаждайтесь. А на досуге, оцените ещё наши новые фичи — туплы, вариативные шаблоны и ещё кучу всякой радости". Да я бы обеими руками был бы за переход на такой язык и начальство бы уговорил.

Кстати, я так и не дождался от вас конкретного примера, чего собственно изначально просил. Насчёт кучи всякой радости: зачем она нужна и радость ли это (в кучах не только радость бывает). Без ссылок на книги. Примерно как я вам привёл два куска актуального и нужного кода.

Tilir wrote:
> Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы
> разрушим до основанья, а затем... Вот есть большие подозрения, что затем
> окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал
> C подмножеством C++.
D замечательно интегрируется с С. Но не с С++.

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

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

T>Вот этот "прожектизм" меня и отталкивает от D. Весь мир наC-лья мы разрушим до основанья, а затем... Вот есть большие подозрения, что затем окажемся у разбитого корыта. Возмите как пример Страуструпа — он сделал C подмножеством C++. И C++ очень быстро и без лишней агитации подгрёб под себя громадное C-сообщество, которое уже потом, перейдя на C++, потихоньку научилось наследовать классы и пользоваться STL...

Что же тогда сделал Хейлсберг, что всех так проперло (до сих под дым из ушей)?
Подмножества — это как раз то страшное зло, от которого успешно ушли создали D.

T>Кстати, я так и не дождался от вас конкретного примера, чего собственно изначально просил. Насчёт кучи всякой радости: зачем она нужна и радость ли это (в кучах не только радость бывает). Без ссылок на книги. Примерно как я вам привёл два куска актуального и нужного кода.

Если вам нужны примеры, видимо вы не знакомы с языком. Там все очевидно без глупых примеров.

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

M>Ээээ C++ ?
Это сложный и слабый язык.

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

D>Xn = Y
D>Xv = V + Y

D>Xn != Xv
->>
D>X != V + Y
D>V > 0
->>

D>Xn < Xy


D>Xn — общее время выполнения native приложения
D>Xv — общее время выполнения managed приложения
D>Y — время выполнения кода приложения
D>V — время выполнения функций VM


Гм. А что такое "функции VM"? Кстати, если я правильно читаю запись, вы сначала исходите из аксиомы о неравенстве времен выполнения, а уже потом доказываете наличие какой-то злой силы.
Данная математика подразумевает модель, в которой в любом режиме выполняется один и тот же код, а "виртуальная машина" — это некоторое зло, которое крутится под ногами и занимает CPU. Это в корне неверно.
Во-первых, для начала, получить 100% одинаковый код практически невозможно. В том смысле, что, к примеру, использование смарт поинтеров приводит к тому, что у объектов постоянно изменяется m_refcount, даже при передаче только для чтения. И это в лучшем случае — когда код смарт поинтера заинлайнен, в КОМ это еще и неустранимые косвенные вызовы. В управляемой среде такие ухищрения не нужны, и этот мусорный код исполняться не будет.
Во-вторых, никаких особых "функций виртуальной машины" не существует в природе. JIT-компиляция? Не смешите меня, она выполняется максимум 1 раз за время использования кода. Это если не использовать предкомпиляцию — а ведь ее никто не запрещает. Сборка мусора? Для среднестатистического приложения она стоит столько же, сколько вызов деструкторов. В некоторых случаях она дешевле, в некоторых — нет.

D>Никие ощущения VM вам не помогут, когда дело дойдет до отладки системных API.
А что, вызовы системных API из управляемой среды ощущаются как-то иначе, чем они же из С++?

Здравствуйте, minorlogic, Вы писали:
M>>>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?
VD>>Это где же такое написанно?
M>C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" ("class B : virtual A"), C++ takes special care to only create one A object, and uses of A's members work correctly. 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.
Это не решение. Это и есть проблема. Во-первых, понять вот эту концепцию виртуального и невиртуального наследования крайне трудно. А главное — зачем? Вот покажите мне хоть один жизненный пример смешивания виртуального наследования с невиртуальным! Все эти правила призваны всего лишь разрулить неопределенности, возникающие из-за самой идеи двух видоа наследования. Никакой практической полезности в них нет.

M>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.
Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

Здравствуйте, fmiracle, Вы писали:
F>Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.
Это закрытая информация. Всё, что я могу сказать: сейчас на RSDN нет форума, в историю которого входит такой прецедент. И для вашего же благополучия — оставьте эти расспросы.

Sinclair wrote:
> D>Никие ощущения VM вам не помогут, когда дело дойдет до отладки
> системных API.
> А что, вызовы системных API из управляемой среды ощущаются как-то иначе,
> чем они же из С++?
Вообще-то, обычно да. Той же JVM/C# приходится сделать достаточно много
работы для вызова неуправляемого кода — за-pin'ить объекты, сохранить
контекст GC и т.п.

В обычных системах это часто может маскироваться затратами на
переключение контекста, но я сейчас работаю на встроеной системе без MMU
— так там overhead вполне заметен.

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

S>Здравствуйте, minorlogic, Вы писали:
M>>>>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?
VD>>>Это где же такое написанно?
M>>C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" ("class B : virtual A"), C++ takes special care to only create one A object, and uses of A's members work correctly. 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>Это не решение. Это и есть проблема. Во-первых, понять вот эту концепцию виртуального и невиртуального наследования крайне трудно. А главное — зачем?

Я встречал людей делящихся на 2 типа по отношению к МН, те которые его понимают и те которые его просто не знают. А вы мне говорите про какие то сложности ? Видимо вы исключение из правил.


S> Вот покажите мне хоть один жизненный пример смешивания виртуального наследования с невиртуальным!
Классический пример — наследование реализации для иерархии интерфейсов.

S>Все эти правила призваны всего лишь разрулить неопределенности, возникающие из-за самой идеи двух видоа наследования. Никакой практической полезности в них нет.

Для вас нет ?



M>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.
S>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

Не факт , но мне хочется иметь возможность выбрать , а вам ?

Здравствуйте, minorlogic, Вы поставили минус:

Те ты считаешь что С++ простой и мощьный?

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

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

D>>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++
ANM> Много эмоций, мало конкретики.
Да вы что? Писать предикаты вам не надоело? Думать об opertaor= и КК или писать boost::noncopyable? Чудовищный COM на котором построена винда вам тоже очень нравится? Даже со всеми хлеперами, вы должны от того отнаследоваться, здесь прописать... Вот простой вопрос. Вы видите определение шаблона для типа T. Каков должен быть тип T? Должен он иметь КК, operator= или там подразумевается скалярный тип или он должен поддреживать некий интерфейс? Только не заливайте, что это должно быть в комментариях. Смотрим boost и STL как вечно пихаемые примеры хорошего кода. Ну ну, разберитесь без доки. И где ваша хваленая читабельность кода? Я вижу определение шаблона, кочу узнать его интерфейс и ВЫНУЖДЕН тупо скролить тела функций (ну нет пока export). И вообще — в C++ слишком много ПИСАТЬ, он давно затраты/польза скатился ниже плинтуса. Конечно он не умрет, многие будут (и вы наверное) за него деражаться, и плыть на тех тоннах кода который уже существует — НО! — за C++ останется поддрежка текущего кода и специфичные сегменты рынка. Для новых приложений его вряд ли выберут. Программист стоит дороже, а пользы меньше. Ну подумаешь на секунду две больше грузится будет. А sprintf с его опасностью не только несовпадения типов, но и выхода за предел буфера. Стримы? Но несмотря на них ОЧЕНЬ большое количество людей попрежнему использует printf. Два типа delete вам тоже по душе? И понимате, это все капает на мозг. Я не секретарша, и мозг и так нагружен — а еще С++ давит.

D>>когда десяками лет тянется старое, извините, говнооптимизации
ANM> Что это такое?
Например, bitfields. Например, то что переменные по умолчанию не инициализируются. А эти инклюды... А триграфы, про которые только приколы и пишут? Вам мало? Это значит только одно — вам больше нравится писать, чем думать, потому что мысли должны естьтественно и немногословно ложиться код. Выводы делайте сами — обезьянки никому не нужны. Сюда включаем пережитки синтаксиса. И все хранится и пылится, а потом выползает в самый неудобный момент — как те же триграфы, выражения типа 3["hello!"] и прочей несуразицы.

D>>И нет человека способного это прекратить волевым решением.
ANM> Конечно. Потому что очень много компаний используют C++.
Ну да, да. Не спорю. В таких компаниях наверно никогда не находится время на рефакоринг. И только сознательные сотрудники, выкраивая своё время делают его. Разве боссу такой компании удасться втемяшитью что 3 месяца работы нудны на то что переделать внутреннюю структуру? Он согласится оплачивать работу своей орыва программистов, узнав, что фичи продукта остануться теми же? Умные архитекторы работают по схеме разработки когда разработка особенно нового сочетается с рефакторингом.

D>>Бесят смарт поинтеры (assist зачасту не способен на -> нормальную подсказку выдать, мытарства когда надо F11 при дебаге),
ANM> Не знаю.. У вас что сотни методов в классе? Если так то есть повод подумать над дизайном проекта.
Не сотни. А скажем 15. Умножьте на ~50 классов. Я не хочу и НЕ БУДУ дословно запоминать имена методов. Я предпочитаю начать писать его имя скажем, из серидины, пусть ассист сам найдет где такое встречается.

D>> бесит тормознутость C0x
ANM> По сравнению с чем ?
Тормознуость я плохо выразился. Я имел в виду, почему так долго они его там мусолят. Почему не так сложно сделать его не backward-compatible? То что происхлодит с C++ — это уже не эволюция. Это деградация. Великая империя не умрет, пока не сгниет из нутри — говорил умный философ. Ясно что в С++ гораздо сложнее вносить что-то новое чем более молодые языки.

D>>бесит список инициализации (вместо int const member = 10; )
ANM> Ну да. Но этого явно недостаточно для смены языка. Мало ли что вас будет бесить в новом.
Это к примеру. Я не буду тут плакаться что то не то, это не то. C++ есть, пока жив, но скоро он отойдет в тень. Еггоь вытеснили из CGI сферы. Его вытеснелили из Business приложений. Он сдает позиции. Это факт. Но с новыми технологиями дешевеет программист. Это факт. Грустный факт.

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

C>Кстати, будешь смеяться, но мой софт скоро будет использоваться на АЭС
C>(Indian Point Energy Center) для учета персонала

Незабудь сообщить дату запуска. Я поищу к этому времни надежное бомбоубежище.

C>Прямо жаль, что я его писал на Java, а не на С++. А то бы можно было бы
C>начать флейм "Только С++ пригоден для использования на АЭС". Эххх...

Ну, это если пронесет.

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

M>А меня 3 года назад сватали разработчиком С++ на Запорожскую АЭС.
M>Причем что плюсы я не знал тогда не знаю и сейчас
M> Плюсы там используются в системе контроля. То бишь датчики там разные, с них снимается информация и при превышении допустимого уровня звучит алярма. А для отладки и разработки используется эмулятор атомной станции писанный то ли в Беркли то ли еще где. И тоже писан на плюсах. Такие дела...

Хорошо вы от нас далеко.

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

M>Ну да, я имел ввиду что на после компиляции имеет байт код. А JIT это уже часть рантайма. Чисто гипотетически можно обойтись и без него. Правда о скорости в таком случае можно забыть

Компиляция в донете может производиться и до запуска программы. Обойтись без компиляции вообще невозможно, так как такова реализация. Так что говоря о дотенете просто бессмысленно рассуждать о байткоде.

M>Веришь, в моем тоже Хотя конечно все от задач зависит. Но задач, которым нужен с++ с его возожностью ручного управления памятью я вижу все меньше и меньше...

+1

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

M>>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.
S>Не факт, что это недостаток. Виртуальное наследование предотвращает некоторые оптимизации, потенциально доступные для миксина. Компилятор точно знает, в какой класс он примешивает миксин, поэтому есть шанс выполнить инлайнинг и прочие агрессивные оптимизации. При виртуальном наследовании копия кода ровно одна, и она должна подходить для всех классов.

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

Например, для разрешения ссылок на множество базовых классов в С++ часто испльзуется "двойной" указатель (на 32-битных платформах его размер обычно больше 32-х бит). Это вынуждает компилятор порождать код пересчета адресов, что естественно отражается на скорости вызова метода доводя его до скорости вызова интерфейса в дотнете. А раз так, ток каой смысл заниматься всеми этими сложностями?

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

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

WPF — сложная библиотека (большой объем кода). Единственное ее приемещество — она сразу рассчитана на довольно малый по объему модуль нэйтив-кода и не завист огромного WinAPI. Но объем работ все же не позволит быстро и лего ее реализовать. Так что будучи реализованной ее наверно действительно будет легко переностить, но вот реализовать ее будет не просто.

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


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

VD>WPF — сложная библиотека (большой объем кода). Единственное ее приемещество — она сразу рассчитана на довольно малый по объему модуль нэйтив-кода и не завист огромного WinAPI.

О том и речь. Разделение идёт на уровне заранее подготовленных абстрагирующих базовых классов, которых совсем немного. (DrawingContext, WindowHost и т.д.)


VD>Но объем работ все же не позволит быстро и лего ее реализовать. Так что будучи реализованной ее наверно действительно будет легко переностить, но вот реализовать ее будет не просто.

А рефлектор на что?

Просто я с трудом представляю себе суммарный объем работы для того, чтобы заставить на Линухе полноценно работать c Windows.Forms. Суммарный в смысле с wine, ибо в оригинале идёт жесткая спайка с WinApi в каждом втором методе, да еще надо поддержать юзверские контролы, в которых такое же WinAPI мракобесие творится (сам пишу контролы постоянно для Windows.Forms). В общем, зря моновцы изначально за эту задачу взялись и столько сил угробили.

Глядя на всё это я как-то пару лет назад уселся писать Lite-GUI библиотеку, кое-что сделал (общий енжин хостинга канваса, пару контролов), но затем слухи о подробностях реализации "Авалона" (тогда еще) прервали полёт творческой мысли.

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

D>Это к примеру. Я не буду тут плакаться что то не то, это не то. C++ есть, пока жив, но скоро он отойдет в тень. Еггоь вытеснили из CGI сферы. Его вытеснелили из Business приложений. Он сдает позиции. Это факт. Но с новыми технологиями дешевеет программист. Это факт. Грустный факт.
Не дешевеет. Просто он за тоже время может сделать больше.
В этом смысле для работодателя программист дешевле и это хорошо.
Но никаких причин платить меньше нет ибо хороших программистов всегда мало и никакие технологии это не изменят.

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

V>А рефлектор на что?

Они же не могут украсть исходники 1 в 1? Тогда вообще не ясно зачем рефлектор. Сборки ведь перенесутся на ура. Создать только интеропные нэйтив-библиотеки и все.
Только при этом их МС сразу за жабры возьмет.

V>Просто я с трудом представляю себе суммарный объем работы для того, чтобы заставить на Линухе полноценно работать c Windows.Forms.

Тем не менее болшая часть (по их словам) уже работает.

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

WH>Здравствуйте, demi, Вы писали:
WH>Не дешевеет. Просто он за тоже время может сделать больше.
WH>В этом смысле для работодателя программист дешевле и это хорошо.
WH>Но никаких причин платить меньше нет ибо хороших программистов всегда мало и никакие технологии это не изменят.

С одной сторон меня это обраджовало, но потом подумал к каким себя причислить. С другой, это означает что программистский труд будет далее делиться на уровни. Уже "отпочковались" тестеры, архитекторы. Далее наверно будет по платформам — (Java, .NET, С++), (embedded-asm-C-WinAPI), (ASP/интернет/HTML,cкриптеры) — так сказать выбирай по способностям Причем в скобках группы так сказать — базисные, низовые или железячники, и GUI-сты. Кстати, много ли есть контор сейчас, которые держат дизайнеров для окон, кнопок, сплеш-скринов? Это тоже мне кажется потихоньку придет — GUI отдойдет от клепания формочек программистами до уровня когда это легко как HTML (здесь лол на легко ) будут делать дизайнеры и уже не в Visual Studio, и сразу со скинами — хошь такой стиль, хошь такой. Благо виста богатые технологии отображения предоставляет. Насколько я знаю, Adobe и MS движутся в эту сторону — XML окна, легко сочитающие скины и функциаональность кнопочек.


Отвлеклись. Для объективности надо сделать голосование в таком формате — Устравивает ли вас C++? Если нет, то на какой язык вы хотели бы писать: Java, C#, D, функциональный. Ах, ну да, еще Nemerle Basic и Pascal в меньшинства, как не собравшие достаточное число подписей