LINUX.ORG.RU

Странный C++

 ,


0

1

Тут MS выложила свой калькулятор в опенсорс и я решил посмотреть его сорцы.

В целом всё очень даже прилично, за исключением странных примесей, типа:

    void WindowFrameService::RegisterRuntimeWindowService(TypeName serviceId, _In_opt_ Object^ service)
    {
        if (TryResolveRuntimeWindowService(serviceId))
        {
            throw ref new InvalidArgumentException(serviceId + L" already registered");
        }

        m_runtimeServicesMap[serviceId.Name] = service;
    }

_In_opt_, ^, throw ref? С MSVC почти не сталкиваюсь, к счастью, но они настолько исказили язык? У этого чуда есть название? Github по прежнему считает что это C++.

★★★★★

Прогони через препроцессор, скорее всего, это какие-нибудь макросы. В M$ это дело любят

XMs ★★★★★
()
Ответ на: комментарий от fsb4000

Да, именно это и искал.

Да и изменений не так уж много, чтобы так извращаться.

RazrFalcon ★★★★★
() автор топика

Это C++/CX, который вырос из C++/CLI, который в свою очередь вырос из Managed C++. Всё это привязки C++ к их .NET’овской платформе.

P.S. немного поковырялся в коде этого калькулятора:

Microsoft снова внёс весомый вклад в течение Open Source

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)

managed C++.

Нормальные люди на нём решения не пишут, а используют его как очень быстрый клей между обычным c++ и другими .Net технологиями.

pon4ik ★★★★★
()
Ответ на: комментарий от EXL

Страшно подумать, что когда-то они даже хотели эту херню в стандарт пропихнуть.

rupert ★★★★★
()
Последнее исправление: rupert (всего исправлений: 1)
Ответ на: комментарий от Makhno

Это, просто Г-споди, C++/CLI.

Не, это C++/CX.

EXL ★★★★★
()

_In_opt_ Object^ service

Это вроде какая-то ссылка на объект, хранимый в области сборщика мусора.

Говно этот управляемый (managed) си++. Но похоже майкрософт стремится к нему привязать тех кто девелопит под винду.

А еще вроде мешать нельзя, т.е. ф-ии из управляемого си++ нельзя юзать в обычном бинарнике. Т.к. это какой-то совершенно другой инстанс, вероятно .net в.м.

bonta ★★★★★
()
Ответ на: комментарий от RazrFalcon

managed C++ это общее название для CLR расширений, а cli/CX и чёт там ещё есть это рантайм и конкретные расширения. Но это точно не точно. Лично я использовал c++/cli как клей, и тут он явно вне конкуренции, с pinvoke медленнее в разы, местами на порядки. А тут включаются оптимизации типа rvo и знания о типе класса с виртуальными функциями, можно слать лесом сборщик мусора и хранить просто указатели на нативные объекты, при этом есть дырки для их освобождения. В общем по соотношению качество выхлопа/количество кода, вне конкуренции, хотя, используя api почти так же конечно можно и на шарпах делать.

Но писать с нуля на этом подмножестве с четырьмя(это если только основные виды брать) типами ссылок на объект, я бы не стал :)

Если верить msdn - мелкомягкие таки сделали рантайм для обычных плюсов без расширений - WinRT под свой uwp.

pon4ik ★★★★★
()
Ответ на: комментарий от bonta

Т.е. чтобы их юзать, нужно собирать со спец. Ключами и на выходе компилятора получается не x86/x86_64 бинарник а бинарник для .net платформы, хотя казалось бы это си++. Но это не точно, но такое впечатление у меня пару лет назад сложилось, когда нужно было что-то портировать на винду и заюзать её апи для отслеживания событий на файлах «через ядро». И вот нашел удобную си++ ф-ю из msdn но компилятор мне сказал это для .net_managed_c++. Пришлось искать более «старомодные» вин_апи для евентов на файлах

bonta ★★★★★
()
Ответ на: комментарий от bonta

C++/CLI компилировался в байт-код для .NET платформы.
С++/CX компилируется в обычный бинарник с машкодом.

EXL ★★★★★
()
Ответ на: комментарий от pon4ik

Ну если в си++ юзается:

1. Сборщик мусора

2. 4 типа ссылки чтобы юзать его (хотя обычный си++ и так весьма сложен, так давай еще добавим разновидностей)

То может и дураки.

Ибо 1. В си++ не должно быть сборки мусора, как только она появится, то си++ станет не нужен, это просто убъёт си++ в пользу того же Шарпа.

2. Если таки примут решение ввести сборщик -то явно не через такое усложнение синтаксиса

bonta ★★★★★
()
Последнее исправление: bonta (всего исправлений: 2)
Ответ на: комментарий от bonta

В си++ не должно быть сборки мусора

Да-да скажи это всем тем ребятам которые свои менеджеры памяти делают со сборкой мусора :) 20/80 наше всё.

Если инструмент использовать по назначению, он обычно подходит хорошо, если пытаться закрутить шуруповёртом гвоздь, может выйти конфуз - да.

Ну, и мои познания про технологии МС успели устареть, судя по комментам товарища выше.

pon4ik ★★★★★
()
Ответ на: комментарий от EXL

О! Спасибо за классификацию. А оно по abi совместимо с обычными плюсами собранными той же версией cl но без расширений?

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Так менеджеры памяти вроде как делают для повышения эффективности работы проги, всякие аллкаторы все дела.. повышение эффективности, это не про сборщик мусора.

bonta ★★★★★
()
Ответ на: комментарий от bonta

Чё эт? Если у тебя есть возможность выбирать где вручную управлять памятью а где довериться отлаженным и тонконастраиваемым эвристикам в которые вложено количество человеколет и которое твоя утлая конторка в принципе не может себе позволить не разорившись?

Я почти уверен, что ты даже замерить влияние сборщика мусора не сможешь грамотно, но при этом кричать про эффективность - конечно же это не мешает :)

pon4ik ★★★★★
()
Ответ на: комментарий от bonta

Неплохие на самом деле. Без нативных кусков кода можно на порядок всего просерать в лэйтенси при гарантии скорости ответа в 99.99% случаев в микросекундном разрешении. Ну т.е. 100us против 10us на событие. Учитывая скорость разработки и простоту поддержки - многим хватит. Например, игрушки можно было бы и на java делать с такими временами отклика, просто слишком много кукаретиков сразу бренд яйцом тухлым забросают если он так поступит. Вот гугелю пох например.

pon4ik ★★★★★
()
Ответ на: комментарий от bonta

Да и многим вендорам AA игрулек насколько я знаю - тоже пох, только узкие места на крестах, остальное всё на C# или вообще на скриптоте. Но тут я не то, что бы сильно в теме.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

А хорошо спроектированная внутренняя работа с памятью - дает четкий контроль и прогнозируемые задержки.

bonta ★★★★★
()
Ответ на: комментарий от pon4ik

Ну да, некоторое время назад си++ был лидеров в геймдеве (если не брать в учет смартфоны), сейчас там сишарп и си++. Есть как чисто поюсовые движки, есть как чисто шарповые. Всякое что в шарпе в узких местах си++, аси++ в узких ассемблер (как не странно для оптимизации графики) можно не учитывать

bonta ★★★★★
()
Ответ на: комментарий от bonta

Утверждение в общем то верное. Но, зачастую задача стоит «не медленнее, чем» с такой-то частотой, и допустимая величина вылета.

И, если, грамотно развесить потоки по ядрам, на практике даже разброс между min/max в рамках распределения оказывается не таким уж и плохим. А при понимании механизмов работы этого самого сборщика мусора, ещё и предсказуемым. Но всё же, справедливости ради - этот кейс работает только когда под приложение выделена вся железка, а остальное ПО считается побочным и работает на жалком клочке ресурсов.

Несомненно - пользователю жилось бы лучше если бы всё ПО было написано на плюсах, а лучше на асме под конкретное железо и оптимизировано опытными системными программистами? А вот и нет, ибо ПО этого было бы котом наплакано ещё долгие столетия.

Я ещё взоржал, когда увидел что в этом калькуляторе pgo прикручено.

хорошо спроектированная внутренняя работа с памятью - дает четкий контроль и прогнозируемые задержки

В общем-то да, но устройство менеджеров мамяти типа tcmalloc или jemalloc точно не проще чем устройство сборщиков мусора(и во многом его напоминает :)). И надо либо этот функционал реализовывать вручную либо о5 же просто знать как устроенны потроха.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Например, игрушки можно было бы и на java делать с такими временами отклика, просто слишком много кукаретиков сразу бренд яйцом тухлым забросают если он так поступит.

То есть мнение тысяч специалистов ничего не стоит, это всё заговор. Так?

RazrFalcon ★★★★★
() автор топика

но они настолько исказили язык?

Так это не с++, это c++-cli, с++ с заинтегиророваным .NET, можно создавать управляемые объекты у которых есть рефлексия, сборщик мусора. Можно описывать как обычные нативные классы, так и управляемые. Управяляемые с++ классы можно будет юзать в c#, если в одном проекте есть подпроекты на с++ и с#

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

Dudraug ★★★★★
()
Ответ на: комментарий от XMs

Прогони через препроцессор, скорее всего, это какие-нибудь макросы

Нет, это расширенный язык. Те же ^ означает - ссылка на управляемый объект, с подсчетом ссылок и всего такого прочего. Но класс должен быть описан как управляемый(там спец синтаксис измененый для описания класса). В итоге ты можешь описать класс, который будет виден в c#, который будет поддерживать рефлексию, сборку мусора, другие особенности .net, а внутри у тебя будет нативный код(возможно в перемешку с управляемым).

Dudraug ★★★★★
()
Ответ на: комментарий от invy

Это язык похожий на плюсы но на самом деле .NET

Отчасти да, отчасти нет. Код написанный без расширеного синтаксиса будет по прежнему нативным.

Dudraug ★★★★★
()
Ответ на: комментарий от RazrFalcon

Тысячи специалистов успешно пилят игрульки и VR в котором если тайминг не соблюл ползователь в рвотного коня сыграет на C# который концептуально от Java ушёл недалеко, разве что дефолт на косьюмерское железо а не на сервера у рантайма настроен.

pon4ik ★★★★★
()
Ответ на: комментарий от bonta

А еще вроде мешать нельзя, т.е. ф-ии из управляемого си++ нельзя юзать в обычном бинарнике.

Да, но наоборот можно. Ты можешь вызывать нативные с++ функции и либы из управляемого с++.

Dudraug ★★★★★
()
Ответ на: комментарий от EXL

C++/CLI компилировался в байт-код для .NET платформы.
С++/CX компилируется в обычный бинарник с машкодом.

О как, вот этого не знал. Спасибо за новую инфу. Отстал я от жизни

Dudraug ★★★★★
()
Ответ на: комментарий от bonta

Ибо 1. В си++ не должно быть сборки мусора, как только она появится, то си++ станет не нужен, это просто убъёт си++ в пользу того же Шарпа.

Ты не прав. Ты можешь использовать сборщик мусора на хай левеле(для управления хай левел классами), а внутри класса использлвать натив код. Так к примеру управляемый класс в c#, который ты юзаешь вполне может быть под капотом натив-кодом(обычным бинарником, код которого был произведен на с++), а для тебя он выглядить будет как класс c#. Управялемый с++ нужен когда весь проект девлопится на .net(тот же c#), но нужно написать узкие места на с++.

Ну или длря разработки gui приложений, .net предоставляет отличный, удобный, понятный и простой инструментарий для создания gui приложений. Поэтому ты можешь написать gui или на управляемом с++, или c#, а движок приложухи на с++. Но в обоих случаях управялемый с++ тебе будет нужен, или для написания фронтенда, или для написания прослойки между фронтендом и бакэндом.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

поддерживать рефлексию

Сильное заявление :) Я обычно сам этим занимаюсь, без инструментальных средств.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Сильное заявление :) Я обычно сам этим занимаюсь, без инструментальных средств.

В смысле? Управляемый класс в «управляемом с++» поддерживает рефлексию из короки и неотличим по испольованию от c# класса, или любого другого .net.

Dudraug ★★★★★
()
Ответ на: комментарий от Dudraug

Т. е. какая-то помесь плюсов с решёткой?

XMs ★★★★★
()
Ответ на: комментарий от pon4ik

игрушки можно было бы и на java делать

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

anonymous
()
Ответ на: комментарий от anonymous

И не в сборщике мусора, да. Указанное тобой скорее следствия.

pon4ik ★★★★★
()
Ответ на: комментарий от RazrFalcon

А что с ней?

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

Просто есть люди которые пишут системные компоненты, есть люди которые делают решения под конкретные требования ради получения максиальной прибыли, есть школоло которому наполовину поучиться наполовину попонтоваться. И это нормально.

Даже в браузере использование нативного кода более обоснованно чем в игрулях. Задумайся - в игрушки с богатой графикой можно можно играть через !интернет!. Да медленней интернета только жёсткие диски и то не все.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Задумайся - в игрушки с богатой графикой можно можно играть через !интернет!. Да медленней интернета только жёсткие диски и то не все.

Ну точно наркоман.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Стриминг - это утопия. На деле это ужас.

RazrFalcon ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.