С появлением in всё стало немного сложнее :) Так как реализация это просто передача по ссылке и дополнительный атрибут, C++/CLI его попросту игнорирует и позволяет изменить объект неявно.
class Program
{
public static void Main()
{
int i = 2;
new A().F(i);
Console.WriteLine(i); // 1
}
}
public ref class A
{
public:
A(){}
void F([System::Runtime::CompilerServices::IsReadOnlyAttribute] int% a)
{
a = 1; // OK
}
};
Ещё одно применение для P/Invoke, чтобы не писать ref. Следует использовать с умом, не стоит преподносить сюрпризов лишний раз :)
[DllImport("abc")]
public static extern F(in POINT pt);
Пусть не умеет убирать в труднодоступных местах, зато заметно разгружает домашнюю уборку, и помогает содержать дом в более чистом состоянии чем без него. Можно , например, запускать каждый день пока на работе, а потом раз в неделю пройтись обычным пылесосом.
На какой системе запускаете, чтобы можно было попробовать воспроизвести.
Mono, увы, периодически чинят баги, а потом снова ломают. В какой-то момент я от них устал и проверял периодически, а сейчас уже не смотрю, но посмотрю для вас.
А какие именно проблемы со старым железом?
Я поставил 11 на компьютер 9-тилетней(!) давности.
Всё работает плавно без никаких проблем.
Это C++/CLI, а учитывая поддержку .NET 6, немного рано говорить про смерть :)
У меня в примере нет ничего из вышеперечисленного.
Всего лишь язык неподдерживающий «in» также как C#.
С появлением in всё стало немного сложнее :)
Так как реализация это просто передача по ссылке и дополнительный атрибут, C++/CLI его попросту игнорирует и позволяет изменить объект неявно.
Ещё одно применение для P/Invoke, чтобы не писать ref.
Следует использовать с умом, не стоит преподносить сюрпризов лишний раз :)
Добавлю положительные отзывы.
Однозначно стоит.
Пусть не умеет убирать в труднодоступных местах, зато заметно разгружает домашнюю уборку, и помогает содержать дом в более чистом состоянии чем без него.
Можно , например, запускать каждый день пока на работе, а потом раз в неделю пройтись обычным пылесосом.
Это правильный и переносимый вариант.
ifdef умеют все компиляторы, а если знакомы с pragma once, то используем.
И волки сыты и овцы целы.
Сегодня на C# прекрасно используем кроссплатформенный Rider.
Прямо сейчас пишу код в macOS, билд сервер собирает в докере Linux, а результат запускаю в Windows.
Вполне возможная причина это компиляторы, неподдерживающие эту прагму.
Гугл компания немолодая, мало ли какое старьё у них в закромах :)
Так и есть, но в функции SinCos нет цикла.
Потому как ломает много кода, по желанию легко превратить предупреждения в ошибки: .editorconfig
GitLab вполне можно поставить локально даже забесплатно и никаких проблем доступа не будет.
"статичный анализ кода" , может всё таки "статический анализ кода" ?
Думаете, просто так появились телефоны с 1ТБ ? :)
Как минимум производительность C# тестировать через Stopwatch неверно.
Следует использовать https://benchmarkdotnet.org/
Также C# проверяет границы массива каждый раз, в отличии от C++.
Чтобы этого избежать можно взять указатель на массив или воспользоваться MemoryMarshal.GetArrayDataReference
Мы о каком C говорим ?
C99 или C11 или C2x ?
Количество "пары моментов" не так уж и мало.
Можно перегрузить "!" ?
Alt+Shift тоже если чуть дольше задержать Alt.
Проблема не с .NET , а с конкретной реализацией т.е. Mono :)
До недавнего времени .NET Core не поддерживал нормальную работу с System.Reflection.Emit на которую завязан компилятор Nemerle.
Вполне возможно, что портировать на .NET 5 или 6 это гораздо более посильная задача чем портирование на .NET Core.
Ну вот, оказывается известный баг Mono: https://github.com/mono/mono/issues/18970
Есть полный стек компилятора, вдруг сходу придумается обход?
На какой системе запускаете, чтобы можно было попробовать воспроизвести.
Mono, увы, периодически чинят баги, а потом снова ломают. В какой-то момент я от них устал и проверял периодически, а сейчас уже не смотрю, но посмотрю для вас.
Если есть возможность завести баг в соответствующем месте будет совсем замечательно: https://github.com/rsdn/nemerle