Здравствуйте, Evgeny.Panasyuk, Вы писали:
dot>>Но каких либо особенных сложностей нет. EP>Привыкли есть кактус
Ещё неизвестно какой кактус более колючий — с явным управлением памятью в каждой строчке кода или byte[]-структуры в 1% кода.
dot>>Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы. EP>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше. EP>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
"new int[1<<30]" тоже за одну. Но, если у тебя такие массивы будут выделяться|освобождаться каждую секунду... в общем плохо будет.
EP>Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.
Вот и считай, вместо кода специального аллокатора ты просто пишешь сразу GC-free код. Без лишних уровней абстракции.
dot>>Там где offheap или нарезание на массивы — будут structure-of-arrays. EP>Сам же понимаешь что это передёргивание. EP>Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры. EP>Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде. EP>Причём SoA требуются на порядки реже чем обычные структуры.
Да и оптимизация обычных структрур требуется на порядки реже.
EP>>>Не прикалываюсь dot>>И как оказалось по факту есть только boehm EP>Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет
Для DOM/js афаир, но не для всего кода. Т.е. создать собираемую песочницу можно, но не "пишем на С++ с мусоросборщиком".
EP>>>Например Boehm GC есть очень давно, и используется в реальных проектах dot>>Он используется в особенного типа проектов — gcj, mono, lisp и т.п. Прикладной код, а уж тем более LL — что-то очень сомневаюсь. EP>Например Inkscape — вполне прикладной код EP>http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Boehm-GC
Интересно для чего он там используется. Как я понимаю это, там gc не для всего кода используется... опять поди какой-нибудь скриптинг?
EP>>>>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java". dot>>>>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java". EP>>>От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул. dot>>Да сколько раз повторять. Нет проблем никаких. EP>То есть ты извращения с off-heap за проблемы не считаешь? Ну ок
Не считаю. Ибо в реальной системе количество off-heap кода составляет 0.2% (специально сейчас посчитал). Ладно, накинь порядок, на тот случай если я посчитал как-то неправильно. Пусть 2%.
Этот код пишется один раз, покрывается тестами и забывается.
EP>>>>>И уровень кода ниже чем C, и больше его во много раз. dot>>>>Не знаю что тут значит "уровень кода", но это не важно. EP>>>На C есть структуры — это выше уровнем чем ручное нарезание буферов. dot>>И что они дают? EP>Например абстракцию над пачкой байт лежащих в массиве.
Допустим. И какая выгода? И какую долю составляет эта выгода от всей системы?
dot>>Без них всё работает замечательно, зачем лишняя сущность? EP>Несерьёзно, это уже blub-аргументация.
Нет, это KISS.
dot>>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода. EP>Действительно, подумаешь код не работает. EP>Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?
Тестами, без всяких valgrind.
dot>>В-третьих, этот кусок кода довольно примитивный, при желании можно даже формально доказать отсутствие расстрелов. EP>Да не то что доказать, тут подобный кусок без ошибки написать не смогли
.
Бывает. Тестов у них не было.
dot>>В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами. EP>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
dot>>В-пятых, обычно это красиво оборачивается, например, в Disruptor, за много лет отлаженная библиотека. EP>Со своими структурами что делать?
"свои" структуры наверняка в LL не заработают. Нужно очень хорошо продумывать структуры с оглядкой на LL.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>>>Все эти вещи когда то писали на Си/С++. Питон, перл, пхп — все это выстрелило уже после того, как С++ оттуда ушел. I>·>Что-то сомневаюсь. C ещё может быть, С++ — очень вряд ли. Но С просто старше. А уж LAMP всегда был классикой. Веб на С — это либо экзотика, либо старьё. I>Смешно. "всегда" началось совсем недавно, от силы 10 лет назад.
10 лет уже было в самом разгаре. Собственно совпало с бумом Web. А до этого помню каждый второй изобретал шаблонный движок, очередное PHP-подобие... JSP, ASP, CFML и прочий треш. Но С массово никогда в вебе не было.
I>>>·>Наравне с Java. I>>>Джава в роли догоняющего. I>·>Примерно как С++ догоняет Кобол. I>Кобол в HFT ? Пудозреваю, исключительно за счет С++.
В finance.
I>>>·>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту. I>>>По факту запрещено многие вещи вызывать именно из за этого ограничения. I>·>Что запрещено? Не понял мысль. I>Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`. I>Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд.
Ага... А если ты заюзаешь чужую либу, а она там malloc делает и все кастомные аллокаторы фтопку.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Вариантов куча. Можно через рефлексию зная, что для типа существуют импликиты.
S>>>>Ну и джененрики интефейсы EP>>>Покажи код. S>> Нет времени.
EP>Необязательно прям сейчас.
Самое простое это
interface IEquatable<T>
{
T Add(T obj,T obj1);
T Add(T obj,T obj1);
итд
}
И не забываем про T4. S>>>> Вот а в C# практически все в одном. EP>>>Язык менее гибкий чем Python. А плюсы-то какие? S>> Это с чего это менее гибкий?
EP>Покажи пример с apply — на нём видно как раз.
S>>То есть ты плюсов не видишь? Я потратил кучу времени, а ты даже плюсов не нашел. Смысл в разговоре?
EP>Какие плюсы у C# перед Python примирительно к скриптам?
На C# можно писать в стиле скриптов через динамики, компилировать динамические сборки.
Напиши динамическую обертку IDispatch над любым объектом С++
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Вообще то мы сравнивали сложность написания C# и C++ кода, который потом будут вызывать из 1C. Так вот в этом разницы не видно. Если же ты хочешь поговорить о возможности запуска из 1C некого чужого, скомпилированного в бинарник кода, то это уже совсем другой вопрос для другой дискуссии. S> Да написания C# кода вообще не существует. Используются любые нетовские классы. S>Так запускается то скомпилированный код сборки. Ну читайте внимательно о чем речь. Вы же С++ ники белая кость.
Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там.
Здравствуйте, ·, Вы писали:
·>QtCreator проще тем, что это только С++ и больше ничего. Другие IDE — это целая платформа с кучей расширений и плагинов.
Я в курсе. Но я же сравниваю их в контексте использования именно для C++, так что всё честно. Ну и в QtCreator тоже есть плагины) Да и если говорить про подсветку синтаксиса, то там естественно тоже есть все возможные (собственно загружаются из инета по требованию). А вот другие возможности IDE там действительно только для C++.
Здравствуйте, ·, Вы писали:
_>>·>Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь. _>>Ну так у меня же мало практики в написание заведомо некорректного кода. Я вообще сам delete раз год вижу, даже с корректным кодом. А тут такое... ))) ·>Ты написал его типично. Чаще так оно и происходит. Время жизни в одном месте, удаление в другом месте, добавленное в другое время, другим девом в другом потоке.
Это типично для C. На C++ такой код вообще не встречается. Просто на нормальном для C++ коде было бы невозможно продемонстрировать описываемый тобой баг (в отличие от Жабки, где это без проблем):
{
auto x=make_unique<T>();
//...
} //в этой точке вызывается delete (сам!)
// а здесь уже не добраться до указателя, чтобы продемонстрировать обсуждаемое поведение
_>>·>И ты правда не видел битых указателях в реальных проектах? Укажи, плиз, номер твоей планеты в тентуре. _>>В своих, ушедших в продакшен, — не видел. ) ·>А сколько девов принимало участие? Сколько человеколет? Если меньше 5 девов, менее сотни человеколет, то это мелкие проекты... Их хоть на ассемблере пиши, не принципиально.
От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
MX>Не понял, для каких простых случаев, какими ручками? Ты же оборачиваешь произвольную .NET сборку в COM.
Попробую как я наконец то динамическую компиляцию. Например http://rsdn.ru/forum/src/3165397
Здравствуйте, ·, Вы писали:
_>>·>В дефолтном случае и GC замечательно работает. А вот эти обсуждаемые извращения в Яве это и есть те самые редкие случаи. _>>Нет, это как раз совсем разные случаи. Единственный сценарий, на котором GC начинает конкурировать с обычной работой с памятью в C++ — это режим создания/удаления множества мелких объектов в куче. Так вот этот режим в C++ встречается на очень редком классе задач (и для них уже есть смысл рассматривать спец. аллокаторы и т.п.). И задачи типа реалтайма или высокой нагрузки точно не относятся к этому исключению — там как раз эффективны стандартные техники C++. ·>Говорю же — два режима оптимальны. Второй режим — объекты создаются и уничтожаются редко. Редко меняется граф объектов в памяти. (т.е. топология графа не меняется, но данные внутри объектов меняться могут). ·>Неоптимальный режим — создали кучу объектов, помариновали их какое-то время и потом грохаем.
"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.
Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).
_>>В то же время в Java режим создания/удаления множества мелких объектов в куче — это норма. И хотя GC не так плохо справляется тут, но он намного отстаёт от C++ на большинстве задач, т.к. в C++ в этих случаях используется другой режим (который априори быстрее). И только в том случае, когда и в C++ необходимо плодить сущности типа shared_ptr, быстродействие может сравниться (при условие, что в C++ не будем вводить кастомные извращения). _>>Соответственно, чтобы догнать C++ на задачах реалтайма, высокой нагрузки и т.п. (в остальных областях тоже медленно, но всем просто пофиг) в Java переходят от дефолтного режима на некое извращение с рукопашными буферами и т.п. ужасами для эмуляции стандартных техник C++. ·>Собственно и в плюсах ты переходишь от комфортного by-value/on stack к хитрым аллокаторам, жонглированию различными типами указателей, повышая риск что-то поломать или потерять.
Ещё раз повторяю: на C++ я перехожу к такому режиму только на очень узком спектре задач, требующих постоянное создания/удаления мелких объектов. Обычно такое наблюдается при написание каких-нибудь компиляторов, интерпретаторов и т.п. На большинстве задач такого нет даже близко. И уж тем более не в области LL, где все выделения памяти рекомендуется сделать вне главного цикла.
_>>Т.е. главный нюанс в том, что хотя в обоих языках есть области, требующие неких нестандартных для языка подходов, эти области совершенно разные у данных языков. И размеры этих областей тоже принципиально разные. ·>Собственно в LL-системе "плохая" часть очень маленькая. Только из малой области кода выжимаются все соки, а остальное пишется как обычно, с комфортом GC.
Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))
_>>·>Собственно та же ситуация и с GC. _>>Абсолютно не такая же. Напомню, что мы здесь обсуждали возможности JIT выбрать расположение и типы данных (куча/стек, ссылка/значение и т.д.) наиболее оптимальным способом. И в отличие от качества генерирования ассемблерного кода оптимизаторами C++, тут ситуация даже не приблизилась к идеалу. И я сомневаюсь что приблизится когда-нибудь, т.к. тут задача намного сложнее. ·>Принципиально — для JIT оптимизаций доступно гораздо больше информации, т.к. оно работает во время испонения. И оптимизация происходит именно в соответствии с реальной нагрузкой. Есть, конечно Profile Guided Optimisation, но она, насколько я знаю, представляет в основном академиеческий интерес.
Я говорю не про теорию, а про практику. В теории компиляторы могли создавать отличный ассемблерный код и 30 лет назад — ничего этому не мешало. Однако на практике они достигли уровня, сравнимого с человеком, только лет 5-10 назад. Так вот в области автоматической оптимизации типов и т.п. на практике нет пока почти ничего реально работающего. Может лет 10-20 и появится что-то существенное, но пока такого нет.
_>Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там.
_>P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает.
Я тебе некажется, что это далеко не то. Прочитай повнимательнее http://infostart.ru/public/238584/
Опя ть путаешь ОПП с процедурным программированием. Это даже сравнивать нельзя.
Ну дык сделайте, раз все так просто.
Я на это http://rsdn.ru/forum/dotnet/4296659.1
потратил всего 15 минут.
Уверяю 1С ники будут вам благодарны.
Сделайте аналогичные примеры с вэб сервисам, а то народ мучается http://1c.mista.ru/topic.php?id=755069 с PHP шными массивами.
и солнце б утром не вставало, когда бы не было меня
_>{
_> auto x=make_unique<T>();
_> //...
_>} //в этой точке вызывается delete (сам!)
_>// а здесь уже не добраться до указателя, чтобы продемонстрировать обсуждаемое поведение
_>
_>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.
Или передаем голые указатели и C++ превращается в C_с_классами.
Кстати проблема вовсе не в delete, а в том, что указатель может быть сохранен в поле класса или статической переменной и произойдёт обращение к освобожденной памяти.
Здравствуйте, ·, Вы писали:
_>>·>А тебе вообще доводилось писать LL код? _>>Я же тебе уже даже примеры приводил. ) И да, оно не из области финансов. ))) ·>В смысле видео|игры?
Видео) Но не только) Бывают ещё всяческие управляющие сигналы, которые должны передаваться без задержек и т.п. Кстати, мне тут подумалось, что во всяких онлайн-играх тоже всё очень похоже. Но с играми я никогда дел не имел (как создатель ).
_>>Да, написание приложения на C++ со встроенным скриптовым языком — это стандартная техника написания сложных и эффективных приложений. Это не только браузеры, но и тяжёлые игры и всякий профессиональный софт (CAD'ы, редакторы/рендереры и т.п.)и ещё много где. Проще вспомнить где такого нет. ))) Кстати, мы такое тоже используем. ·>Вот и считай... что java это такой встроенный скриптовый язык для решения прикладных задач — обработать 20000 заявок в секунду. И нет такой прикладной задачи "разместить структуру данных в памяти последовательно с минимумом индирекций".
На скриптовой язык Java не тянет по удобству. )
_>>Да, и браузер — это совсем не системный софт (с каких это пор взаимодействие с ОС стало признаком системного софта?), т.к. работает на обычном пользовательском уровне. Системный софт — это всяческие драйверы, сервисы и т.п. ) ·>Браузер не решает _прикладные_ задачи (т.е. задача непосредственно решаемая конечным пользователем). Прикладная задача — читать емейл, инвестировать деньги, купить беззеркалку, поставить лайк. А рендер html/css, выполнение js — это не прикладные задачи. И, что характерно, всякие прикладные вещи в браузере типа управление списком скачанных файлов, диалоги настроек и т.п — пишется на js/xul.
О, тогда и все современные 3D игры являются системным софтом? ))) Потому как в них тоже полно взаимодействия с ОС и всю логику задаёт некий скрипт...
_>>·>Кеш в районе всего лишь нескольких мегабайт — копейки же, миллиончик элементов — и упс, кончилось. _>>Хыхы, в данном случае важнее размер не всего кэша, а именно его линий (в соотношение с размером самого объекта). А так же очевидная для предсказателя последовательность выборки. ·>Линия вроде вообще 64 байта или что-то типа того. Или я с чем-то путаю?
Здравствуйте, Serginio1, Вы писали:
_>>Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там. _>>P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает. S> Я тебе некажется, что это далеко не то. Прочитай повнимательнее http://infostart.ru/public/238584/
Что не то? ) Это вызов в 1C произвольной функции из произвольной нативной DLL. Ты кажется этого хотел или нет? )
S>Опя ть путаешь ОПП с процедурным программированием. Это даже сравнивать нельзя. S> Ну дык сделайте, раз все так просто. S>Я на это http://rsdn.ru/forum/dotnet/4296659.1
потратил всего 15 минут. S>Уверяю 1С ники будут вам благодарны.
Что сделать то? ) Напиши чётко и ясно. Работа с произвольным C++ классом (данным нам в исходниках) показана. Работа с произвольной dll тоже. Чего ещё не хватает? )
S>Сделайте аналогичные примеры с вэб сервисам, а то народ мучается http://1c.mista.ru/topic.php?id=755069 с PHP шными массивами.
Здравствуйте, gandjustas, Вы писали:
_>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе. G>Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.
Это с каких это пор нельзя передавать параметром? ) shared_ptr — это для очень специфического кода.
G>Или передаем голые указатели и C++ превращается в C_с_классами.
Ты путаешь. Голые указатели — это как раз нормально (а как ты без них скажем с win api поработаешь?). Не нормально это ручное удаление памяти и т.п.
G>Кстати проблема вовсе не в delete, а в том, что указатель может быть сохранен в поле класса или статической переменной и произойдёт обращение к освобожденной памяти.
Ну т.е. проблема в том, что delete вызван раньше, чем положено. Опять же проблема кривой архитектуры.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там. _>>>P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает. S>> Я тебе некажется, что это далеко не то. Прочитай повнимательнее http://infostart.ru/public/238584/
_>Что не то? ) Это вызов в 1C произвольной функции из произвольной нативной DLL. Ты кажется этого хотел или нет? )
Разницу не чувствуешь, статический метод и метод класса. Сделай примеры из статьи. И посмотрим. В чем проблема?
S>>Опя ть путаешь ОПП с процедурным программированием. Это даже сравнивать нельзя. S>> Ну дык сделайте, раз все так просто. S>>Я на это http://rsdn.ru/forum/dotnet/4296659.1
потратил всего 15 минут. S>>Уверяю 1С ники будут вам благодарны.
_>Что сделать то? ) Напиши чётко и ясно. Работа с произвольным C++ классом (данным нам в исходниках) показана. Работа с произвольной dll тоже. Чего ещё не хватает? )
В статье есть куча примеров. S>>Сделайте аналогичные примеры с вэб сервисам, а то народ мучается http://1c.mista.ru/topic.php?id=755069 с PHP шными массивами.
_>Эээ что? )))
Ну опять же в статье есть пример использования Вэб сервисов. Правда нужно сгенерить сборку в VS и её использовать.
Вот выдержка из статьи использования
Процедура ВызовСервисаИспользуяConfigFileНажатие(Элемент)
// Вставить содержимое обработчика.
врап=новый COMОбъект("NetObjectToIDispatch45");
//Сборка=врап.загрузитьСборку("d:\MyPrograms\Test\NestNet45\NestNet45\bin\Debug\NestNet45.dll");
Сборка=врап.загрузитьСборку(ИмяФайлаСборки);
TChannel=Сборка.GetType("NestNet45.ServiceReference1.MorpherSoap");
ConfigFile=ИмяФайлаСборки+".config";
endpointConfigurationName="MorpherSoap";
endpointAddress=Неопределено;
Клиент=врап.СоздатьКлиентаWCFConfigFile(ConfigFile,TChannel,endpointConfigurationName,endpointAddress);
// Вызываю метод и вывожу результат
рез = Клиент.GetForms("Вася Пупкин");
Для каждого стр Из рез Цикл
сообщить(стр)
КонецЦикла;
КонецПроцедуры
Легко используются доступ к Вэб сервисам из сборки.
Все очень красиво
Сборка представляет собой описание клиента.
Вот исходник
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.17929
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------namespace NestNet45.ServiceReference1 {
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://morpher.ru/webservices/", ConfigurationName="ServiceReference1.MorpherSoap")]
public interface MorpherSoap {
[System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/PropisRUB", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
string PropisRUB(decimal summa);
[System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/PropisRUB", ReplyAction="*")]
System.Threading.Tasks.Task<string> PropisRUBAsync(decimal summa);
[System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/GetForms", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
string[] GetForms(string s);
[System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/GetForms", ReplyAction="*")]
System.Threading.Tasks.Task<string[]> GetFormsAsync(string s);
[System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/Soglasovat", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
string Soglasovat(uint n, string s);
[System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/Soglasovat", ReplyAction="*")]
System.Threading.Tasks.Task<string> SoglasovatAsync(uint n, string s);
}
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
public interface MorpherSoapChannel : NestNet45.ServiceReference1.MorpherSoap, System.ServiceModel.IClientChannel {
}
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
public partial class MorpherSoapClient : System.ServiceModel.ClientBase<NestNet45.ServiceReference1.MorpherSoap>, NestNet45.ServiceReference1.MorpherSoap {
public MorpherSoapClient() {
}
public MorpherSoapClient(string endpointConfigurationName) :
base(endpointConfigurationName) {
}
public MorpherSoapClient(string endpointConfigurationName, string remoteAddress) :
base(endpointConfigurationName, remoteAddress) {
}
public MorpherSoapClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) :
base(endpointConfigurationName, remoteAddress) {
}
public MorpherSoapClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) :
base(binding, remoteAddress) {
}
public string PropisRUB(decimal summa) {
return base.Channel.PropisRUB(summa);
}
public System.Threading.Tasks.Task<string> PropisRUBAsync(decimal summa) {
return base.Channel.PropisRUBAsync(summa);
}
public string[] GetForms(string s) {
return base.Channel.GetForms(s);
}
public System.Threading.Tasks.Task<string[]> GetFormsAsync(string s) {
return base.Channel.GetFormsAsync(s);
}
public string Soglasovat(uint n, string s) {
return base.Channel.Soglasovat(n, s);
}
public System.Threading.Tasks.Task<string> SoglasovatAsync(uint n, string s) {
return base.Channel.SoglasovatAsync(n, s);
}
}
}
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
I>>>>·>Наравне с Java. I>>>>Джава в роли догоняющего. I>>·>Примерно как С++ догоняет Кобол. I>>Кобол в HFT ? Пудозреваю, исключительно за счет С++. ·>В finance.
HFT это уже не финансы ?
I>>Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`. I>>Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд. ·>Ага... А если ты заюзаешь чужую либу, а она там malloc делает и все кастомные аллокаторы фтопку.
В С++ аллокация кастомизируется
1 Многие либы поддерживают аллокаторы
2 можно дефолтный аллокатор соптимизировать под нужные сценарии
Это конечно трудная техника, но возможная. Что взамен в джаве, кастомный GC ?
Здравствуйте, ·, Вы писали:
EP>>>>Анализатору же придётся это доказывать проинлайнив весь код. dot>>>Да пусть доказывает, он железный, зарплату не просит. EP>>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей. dot>Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.
На C++ зачем это доказывать? Мы же про EA говорим.
dot>>>При сборке Eden Space оно и грохнется, EP>>Оно бы грохнулось в тот же самый момент и без EA. dot>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
dot>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.
Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
dot>Разница может быть заметна, если у тебя этот vector возвращается по значению из функции и его размер большой, что передачу by-value сделает неэффективой. А значит ты должен будешь его в unique_ptr обернуть или надеяться на RVO.
Сейчас есть гарантия: в худшем случае что случится в описанном варианте это move, то есть никакой unique_ptr тут не нужен, также как и во многих других случаях.
Да и RVO/NRVO прекрасно работает даже на старых MSVC.
dot>>>А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr. EP>>У него тоже ничего не поломается. Даже если бы это был просто vector<T>, без unique_ptr — то тоже ничего бы не поломалось dot>Это если голые указатели не использовать.
Так я же говорю, их можно использовать когда нет владения. При передачи владения нужно это кодировать в типах.
dot>>>>>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё. EP>>>>Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет. dot>>>Ты так говоришь, как будто это что-то плохое. EP>>Это очевидный недостаток. Например есть текст, нужно передать куда-то отдельный абзац — на C++ достаточно например либо двух указателей, либо указателя и числа символов, либо просто указателя на начало абзаца. На Java же придётся ещё таскать ссылку на сам текст. dot>В общем да, есть такое. Хотя далеко не факт, что это может стать какой-либо проблемой... В типичном приложении у тебя скорее всего будет ссылка на какой-нибудь Document, по которому можно найти его текст. Поэтому будет достаточно пары индексов. А в большинстве случаев помещение двух или трёх чисел на стек — погоды не делает.
На стеке да, а вот например если нужно хранить массив абзацев из разных документов — то уже будет существенная разница.
dot>>>>>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC. EP>>>>Штуки типа cuckoo hashing не на ровном месте появились. dot>>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n). EP>>Меняет — поиск и удаление константы в худшем случае. dot>А добавление?
С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
dot>>>>>Не смертельно. EP>>>>Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код. dot>>>Комбинации чего? EP>>Структура данных * контейнер * алгоритм * etc. ЕМНИП даже в C# для разных структур generic даёт разные воплощения. dot>Круто, конечно. Но в горячем коде таких комбинаций обычно единицы. А остальному коду это всё не важно.
У меня как раз в "горячем" коде их очень много.
dot>>>Сколько их? (только практику плз, а не теоретические рассуждения) EP>>Очень много, это практика, реальный код. EP>>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию. dot>Не факт, что это принесёт хоть какую-то пользу. compile time же.
В смысле?
dot>>>>>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой. EP>>>>А например в хэш-таблице? dot>>>Если значение большое, то индирекция нужна, иначе сам массив хеш-таблицы будет слишком большим и не помещаться в кеш. EP>>1. Если малое — то уж точно не нужна, тут разногласия нет. EP>>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме EP>>3. Ключ может хранится отдельно от значения, причём без индерекции. dot>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.
Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
dot>>>Если значение маленькое, то это скорее всего будет примитив. EP>>С чего бы это? dot>Потому что примитив это те же 8 байт, что уже не так уж мало.
На C++ там где удобно без проблем оборачиваю даже одно значение примитивного типа в класс
dot>>>Собственно это соответствует сложному жонглированию владением в C++, EP>>Не сложному, и не соответствует. Большинство случаев владения (и "жонглирования" им) C++ это простейший by-value. dot>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.
by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
EP>>>>Конечно будет, и это одна из причин почему положит на лопатки.EP>>>Именно так и происходит
в Emscripten, который компилирует C++ в JS. EP>>>>И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить. dot>>>Ну и кому эти микробенчмарки нужны? EP>>Тем кого интересует скорость dot>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.
Так говоришь как будто быстрое означает не полезное.
dot>>>Ты давай пример системы на плюсах, компилированных под jvm. EP>>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой. dot>Потому и не знаешь, что принципиально невозможно.
Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
dot>>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места. EP>>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею. dot>Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.
1. В том тесте вообще GC остался за бортом, его действия не замеряли. Замеряли только обход массива с простой операцией.
2. Причём тут вообще JS GC? В случае C++ -> JS — там практически все данные находятся в одном большом буфере.
Здравствуйте, ·, Вы писали:
dot>>>Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы. EP>>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше. EP>>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию. dot>"new int[1<<30]" тоже за одну.
Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
EP>>Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free. dot>Вот и считай, вместо кода специального аллокатора ты просто пишешь сразу GC-free код. Без лишних уровней абстракции.
Ещё раз — в одном случае отличие от дефолта это несколько параметров, в другом изменение всего кода. Разница кардинальная.
Поэтому аргументы типа "ну и что что весь код GC-free, зато у вас несколько параметров меняются" — несостоятельны.
dot>>>Там где offheap или нарезание на массивы — будут structure-of-arrays. EP>>Сам же понимаешь что это передёргивание. EP>>Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры. EP>>Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде. EP>>Причём SoA требуются на порядки реже чем обычные структуры. dot>Да и оптимизация обычных структрур требуется на порядки реже.
Реже чем что? Чем смирение с тормозами, повышенным энергопотреблением и т.п.?
EP>>>>Не прикалываюсь dot>>>И как оказалось по факту есть только boehm EP>>Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет dot>Для DOM/js афаир, но не для всего кода. Т.е. создать собираемую песочницу можно, но не "пишем на С++ с мусоросборщиком".
Там это используется для interop JS (DOM?) <-> C++ — то есть не просто внутри JS.
dot>>>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода. EP>>Действительно, подумаешь код не работает. EP>>Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap? dot>Тестами, без всяких valgrind.
Так в C++ будут и тесты и valgrind/etc. Об этом и речь, готовых инструментов на Java видимо нет, значит трата ещё дополнительных ресурсов.
dot>>>В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами. EP>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово. dot>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
Здравствуйте, Serginio1, Вы писали:
S>>>>>>>>> Кстати а чем С++ хуже питона, раз питон используется с С++? S>>>>>>>>>C# точно ничем не хуже. EP>>>>>>C# менее гибкий для обобщённого кода. Например EP>>>>>>Python: EP>>>>>>C++: EP>>>>>>C#? S>>>>>https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx EP>>>>И как это относится к примеру? S>>> https://msdn.microsoft.com/ru-ru/library/s53ehcz3.aspx S>>>Я могу через рефлекшн вызвать соответствующие методы. S>>>https://msdn.microsoft.com/ru-RU/library/system.datetime.op_addition(v=vs.71).aspx EP>>Да причём тут это? Пример про простую функцию высшего порядка apply — на Python и C++ она элементарно реализуется. Покажи аналог на C#. S>Вариантов куча. Можно через рефлексию зная, что для типа существуют импликиты.
Так покажи — на Python и C++ это несколько простых строчек.
S>>>>>Ну и джененрики интефейсы EP>>>>Покажи код. S>>> Нет времени. EP>>Необязательно прям сейчас. S> Самое простое это S>
S>interface IEquatable<T>
S>{
S> T Add(T obj,T obj1);
S> T Add(T obj,T obj1);
S> итд
S>}
S>
Да причём тут Add? Тут основная фишка в apply.
S> И не забываем про T4.
То есть там где на Python и C++ пара строчек, ты предлагаешь использовать кодогенерацию T4, и причём это в контексте скриптов? Мощно
EP>>Какие плюсы у C# перед Python примирительно к скриптам? S> На C# можно писать в стиле скриптов через динамики, компилировать динамические сборки.
Напиши apply, посмотрим на это "в стиле скриптов".
S>Напиши динамическую обертку IDispatch над любым объектом С++
Я же сказал, для этого проще всего взять интерпретатор Cling — сможешь обращаться к любому объекту.
А вообще непонятно к чему это, вопрос-то был какие плюсы у C# перед Python в отношении скриптов
S>А в чём красота, что нашли (наконец) куда засунуть пользовательские суффиксы?
Почему "наконец"? Их вводили вполне под конкретные нужды.
А вообще там оппонент непонятно зачем начал показывать готовый Complex в C#, хотя пример был совершенно не про это. В ответ я и показал что есть из коробки в C++
S>Кто-то после этого попрекает C# синтаксическим сахаром.
Кто? Я как раз говорю что язык в том числе и не гибкий.
).
Можем кстати сравнить.
