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

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

S>>·>Тут как я понимаю вопрос — а зачем этот язык расширять? Он нужен только для чего-то простого, что-то заскриптовать. А если какой-то сложный код, который плохо ложится на сложную задачу, то эту задачу лучше целиком реализовать на каком-то другом языке и интегрировать с 1C каким-то более обычным способом, через WebService, REST или подобное.
S>>·>Но мы опять отбиваемся от темы...
S>> Там не поддерживаются Ws протоколы, Header итд. Куча шифрований, HAMAC итд. Проще не городить свой Rest,а взять готовый класс с сериализацией десериализацией. Тот же часто использукмый для парсинга сайта AnglrSharp, асинхронный вызов и куча куча всего.
·>Так не пиши ничего на 1С-языке, все эти ъ — это же жуть, и наверняка серьёзная проблема с юнит-тестами. Неужели нет никакого способа написать модуль|расширение|плагин на нормальном ЯП?

Ну это касается, того что 1С не хочет передавать объекты ВК в праметрах. Что касается Windows и Idispatch то с этим все нормально. И можно использовать обертки на объектами .Net без всяких ъ.
В данном случае я показываю, что можно сделать и надеюсь, что 1С пойдет на модификацию Native API которое не менялось лет 6.

S>>·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти?
S>> Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml

Автор(ы): Андрей Мистик
Дата: 21.02.2003
В данной статье я постараюсь в общих чертах описать принципы работы менеджера памяти Delphi.
Зачем это нужно? Ведь, казалось бы, работает себе и работает, зачем его трогать? Это нужно по нескольким причинам. Во-первых, никогда не помешает разбор чужого кода, особенно если это грамотный код. Это возможность научиться чему-либо новому, а также получить эстетическое наслаждение. Во-вторых, никогда не лишне поглубже разобраться в чем-то, убедиться в тех вещах, в которых вы ранее не были уверены или же, наоборот, найти слабые места, о которых вы ранее и не подозревали, чтобы в будущем писать более эффективный код.

·>Эээ... И что? Я не понимаю тебя. Не делать дефрагметацию — это плохо. Память закончиться внезапно может. Менеджер памяти не делающий дефрагментацию — плохой, негодный менеджер. Приходится под него подстраиваться.
Ну так на этом все нативные менеджеры построены. И ведь работают. А для твоего теста они подходят лучше всего. Просто в .Net ты можешь комбинировать.
S>>·>А зачем нужен бессмысленный тест?
S>>Это ответ на то как поможет нативный менеджер памяти.
·>Он использует локи, критические секции, что практически не допустимо для LL.
Можно так же использовать все те же interlockedexchange. Этих менеджеров памяти достаточно много.
S>>·>Ок, подытожу.
S>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира).
S>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта.
Ну это нужно сравнивать в тестах. Что лучше.
S>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
·>Нет, он сказал, что там C# и нативный C++ код. Ну, по крайней мере, я его так понял.
Ну можно писать и на нескольких языках если команда большая. Делать смешанные классы на C++, а использовать их на всех других нетовских языках. Сейчас F# продвигается активно.

·>Я продолжу отвечать на твои вопросы, ликбез всегда полезен, но убеждать больше не буду.

ОК

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

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

S>>·>Тут как я понимаю вопрос — а зачем этот язык расширять? Он нужен только для чего-то простого, что-то заскриптовать. А если какой-то сложный код, который плохо ложится на сложную задачу, то эту задачу лучше целиком реализовать на каком-то другом языке и интегрировать с 1C каким-то более обычным способом, через WebService, REST или подобное.
S>>·>Но мы опять отбиваемся от темы...
S>> Там не поддерживаются Ws протоколы, Header итд. Куча шифрований, HAMAC итд. Проще не городить свой Rest,а взять готовый класс с сериализацией десериализацией. Тот же часто использукмый для парсинга сайта AnglrSharp, асинхронный вызов и куча куча всего.
·>Так не пиши ничего на 1С-языке, все эти ъ — это же жуть, и наверняка серьёзная проблема с юнит-тестами. Неужели нет никакого способа написать модуль|расширение|плагин на нормальном ЯП?

Ну это касается, того что 1С не хочет передавать объекты ВК в праметрах. Что касается Windows и Idispatch то с этим все нормально. И можно использовать обертки на объектами .Net без всяких ъ.
В данном случае я показываю, что можно сделать и надеюсь, что 1С пойдет на модификацию Native API которое не менялось лет 6.

S>>·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти?
S>> Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml

Автор(ы): Андрей Мистик
Дата: 21.02.2003
В данной статье я постараюсь в общих чертах описать принципы работы менеджера памяти Delphi.
Зачем это нужно? Ведь, казалось бы, работает себе и работает, зачем его трогать? Это нужно по нескольким причинам. Во-первых, никогда не помешает разбор чужого кода, особенно если это грамотный код. Это возможность научиться чему-либо новому, а также получить эстетическое наслаждение. Во-вторых, никогда не лишне поглубже разобраться в чем-то, убедиться в тех вещах, в которых вы ранее не были уверены или же, наоборот, найти слабые места, о которых вы ранее и не подозревали, чтобы в будущем писать более эффективный код.

·>Эээ... И что? Я не понимаю тебя. Не делать дефрагметацию — это плохо. Память закончиться внезапно может. Менеджер памяти не делающий дефрагментацию — плохой, негодный менеджер. Приходится под него подстраиваться.
Ну так на этом все нативные менеджеры построены. И ведь работают. А для твоего теста они подходят лучше всего. Просто в .Net ты можешь комбинировать.
S>>·>А зачем нужен бессмысленный тест?
S>>Это ответ на то как поможет нативный менеджер памяти.
·>Он использует локи, критические секции, что практически не допустимо для LL.
Можно так же использовать все те же interlockedexchange. Этих менеджеров памяти достаточно много. https://habrahabr.ru/company/billing/blog/238787/


S>>·>Ок, подытожу.
S>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира).
S>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта.
Ну это нужно сравнивать в тестах. Что лучше.
S>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
·>Нет, он сказал, что там C# и нативный C++ код. Ну, по крайней мере, я его так понял.
Ну можно писать и на нескольких языках если команда большая. Делать смешанные классы на C++, а использовать их на всех других нетовских языках. Сейчас F# продвигается активно.

·>Я продолжу отвечать на твои вопросы, ликбез всегда полезен, но убеждать больше не буду.

ОК