Почему unsafe код небезопасен и его редко используют в C#?

Question

[TheTalion]

Интересует это потому что в С++ везде указатели и ничего страшного, вроде бы, не происходит, а в C# нужно обязательно писать, что это unsafe код. Т.е. есть ситуация - у меня есть класс с 150 переменными (int), я хочу непосредственно эти переменные менять, передавая её в другой класс, типа так:

void IncFirst(){
Storage.firstValue++;
}

Т.е. я взял и в функции указал непосредственно где находится объект, НО мне что, 150 функций таких писать чтобы обновлять каждый? Это же бред.
По логике можно сделать так:

void Inc(int* value){
value++;
}

Итого нам хватит одного метода на любое кол-во переменных, но чтобы использовать указатель нужно включить небезопасный код, но, как я понял, он несет в себя ряд проблем, таких как не подлежит отладке (насколько я помню). И везде пишут что это "Очень опасно" и "Небезопасно", хотя, в чем тут реально есть опасность? Есть, например такая фраза из статьи по теме: "Прямое использование указателей отключает систему безопасности", - что это за система безопасности-то? Т.е. не пишет сообщения об ошибках в таком коде или что?

В общем, вопрос в целом такой: в действительности unsafe код так небезопасен и страшен, как его рисуют?

Answer 1

[mafusailmagoga]

Редко unsafe используют - потому что нахрен он нужен в языке, который принципиально улучшен как раз тем что код полностью managled.

Уж всяко не в вашем примере, а ради задач посерьезнее стоит заморачиваться с unsafe.

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

Плюс хуже работает сборщик мусора, когда вы используете указатели.

Считаете себя крутым и пишущим без ошибок (хотя это и не так, 100% не так) и вам не нравятся ограничения C# - ну и не пишите на C#, в чем проблем-то?

Но возмущаться что в одном языке одна идеология, а в другом другая - как то странно.
Зачем бы были нужны языки с одинаковой идеологией.
Они очень разные.

С# и C++ только по синтаксису сходны.
Не нужно чисто механически привносить в один язык подход из другого языка.

Т.е. есть ситуация - у меня есть класс с 150 переменными (int), я хочу непосредственно эти переменные менять, передавая её в другой класс

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

НО мне что, 150 функций

А их и не должно быть у вас 150.
См. антипаттерн - класс Бог.

Comments

[TheTalion]

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

[mafusailmagoga]

TheTalion, а что мешает сделать это в массиве? тогда одной функции-метода класса будет достаточно.

[TheTalion]

Я не могу писать на C++ в Unity, потому что там только C#.

[TheTalion]

mafusailmagoga, там не просто так эти переменные, много переменных через get стоят и одна переменная составляется, например, из 10 других переменных, объявленных в классе, а половина из этих 10-и еще из 3-х и тд. Через массив не так удобно, через список тоже.

[Михаил Усоцкий]

TheTalion, мне сдаётся, что вам надо как-то пересмотреть подходы программирования... mafusailmagoga же явно дал вам наводку на использование массивов. Зачем создавать каждую отдельную переменную с собственной функцией, если можно создать только один массив и метод с номером элемента и типом желаемой операции (или несколько методов на определённые операции) с ref? И это выйдет только одним классом с набором данных.
Вот такой пример:

class ClassA
{
    public int [] Values = new int[150];
    
    public void Int(int numberElement)
    {
        Values[numberElement]++;
    }
    public void Dec(int numberElement)
    {
        Values[numberElement]--;
    }
}

Или так:

static class ClassA
{
    public static void Int(ref Storage storage, int numberElement)
    {
        storage[numberElement]++;
    }
    public static void Dec(ref Storage storage, int numberElement)
    {
        storage[numberElement]--;
    }
}

Или так:

static class ClassA
{
    public static void Int(ref int storage)
    {
        storage++;
    }
    public static void Dec(ref int storage)
    {
        storage--;
    }
}

void Main()
{
    public int [] Values = new int[150];
    
    ClassA.Inc(Values[0]); // Значение Values[0] увеличится на единицу.
}

И ненужно создавать столько классов с функциями.

[TheTalion]

AquariusStar, потому что как вы в массиве к переменной get\set допишите? Конечно, наверное, самое верное вынести все простые переменные с простыми значениями в массив классов, где бы содержались нужные данные по переменной, а остальные, где есть get, оставить как переменные, хотя, это не очень все выглядит, ибо половина значений так, половина так лежит, да и по номеру в массиве брать переменные - это просто безумие, нужно тогда постоянно Array.Find использовать, что тоже не очень хорошо...

[Михаил Усоцкий]

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

[TheTalion]

AquariusStar, ага, шило на мыло выйдет. У меня не одинаковые геттеры и сетеры, мне подобную хрень на каждый отдельный случай нужно будет писать (про индексаторы).

[mafusailmagoga]

TheTalion, если же сеттеры геттеры неодинаковые, значит все хорошо, вполне адекватно вписывается в концепции "закрыть переменную класса вызовом функции"

[Алексей Павлов]

TheTalion, если у вас свойства, а не поля (то есть имеются get и set), то вы их не можете их использовать. Доступ по адресу не связан со свойством, это изменение памяти напрямую.

Answer 2

[eRKa]

Ваша задача нормально решается и без unsafe кода, без костылей и наворотов. Просто мыслить в терминах C++ и писать код на C# не совсем сопоставимо. Если хотите менять непосредственно значения, есть передача значений по ссылке, есть out и ref параметры, для 150 однотипных значений есть массивы, есть списки (и для разнотипных) . Просто нужно подумать в рамках идеологии C#.

Хотя мне не совсем понятна проблема изменить переменные в классе и зачем для этого писать 150 методов. Класс это же объект, который передается по ссылке. Передав объект, Вы будете менять эти переменные у объекта как хотите. Если хотите передать куда-то непосредственно поле класса типа int и хотите, чтоб оно изменилось там, то передайте его как out/ref параметр.

Comments

[TheTalion]

Ок, как выглядеть код должен? Я хочу поменять в классе какое-либо значение. Какое - я не знаю. Например:

void IncFirst()
{
Storage.first++;//явно показываем, что увеличиваем переменную какую-либо
}

void IncLast()
{
Storage.last++;//явно показываем, что увеличиваем переменную какую-либо
}

А теперь мы получаем такое:

void Inc(Storage storage)
{
storage.//как сюда передать то, какую переменную я хочу поменять?
}

Или вы хотите сказать, что если я сделаю так:

class Storage()
{
int first = 0;
}
class Routine()
{
Storage storage;
void Main()
{
Inc(ref Storage.first);
Console.PrintString(Storage.first.ToString());//тут будет 1?
}

void Inc(ref int value)
{
value++;
}
}

[eRKa]

Если Вы хотите получать доступ к значению по смещению, то это однозначно структура данных - массив. Заведите массив, будет доступ по индексу, передавайте индекс. Если Вам важны имена этих переменных, заведите Dictionary и кроме индекса, сможете еще и по ключу обращаться или получать значение по ключу.

Inc(ref Storage.first);
Console.PrintString(Storage.first.ToString());//тут будет 1?

Если правильно написать код - да, там будет 1.

Вам нужно сначала создать объект
var storege = new Storage;
затем поле того объекта передать в Inc()
Inc(ref sorage.fist);

[eRKa]

Переписал Ваш пример как положено в C# )

public class Storage
	{
		public int First = 0;
	}

	public class Routine
	{
		public void Inc(ref int value)
		{
			value++;
		}
	}

И вызов:

var storage = new Storage();
var routine = new Routine();
routine.Inc(ref storage.First);
Console.WriteLine(storage.First);

[TheTalion]

eRKa, зачем создавать объект? У меня в коде он полем объявлен. Словарь нельзя создавать, потому что он не сериализуется, а мне это нужно. Массив классов подходит. Я попробую использовать ref и, надеюсь, получится, но не уверен в этом.

[eRKa]

TheTalion, в примере это класс, поэтому его надо создать, либо сделать его статическим, чтоб не создавать каждый раз. Словарь сериализуется замечательно. Если будете передавать как параметр сам объект, то использовать ref не будет иметь смысла, ref нужен только для значимых типов.

[TheTalion]

eRKa, по первой ссылке "c# сериализуется ли словарь" написано что нет, попробую и отпишу.

[eRKa]

TheTalion, Вы не сказали во что хотите сериализовать. Вообще сериализовать можно все что угодно и во что угодно, просто определить свои правила сериализации. И в этом случае можно сделать тоже самое. Вот пример

Вот еще вариант

// Сериализация
			var document = new XElement(
				"items",
				dictionary.Select(x => new XElement("item", new XAttribute("id", x.Key), new XAttribute("value", x.Value)))
			);
			var xml = document.ToString();
			Console.WriteLine(xml);

			// Десериализация
			var document2 = XElement.Parse(xml);
			var obj = document2.Descendants("item")
				.ToDictionary(x => (int)x.Attribute("id"), x => (string)x.Attribute("value"));

[WayMax]

по первой ссылке "c# сериализуется ли словарь" написано что нет, попробую и отпишу.

TheTalion, по первой ссылке "c# dictionary serialize xml" на староверфлов написано что да.

Answer 3

[d-stream]

Кто триппером не болел - тот не гусар -)

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

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

Comments

[mafusailmagoga]

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

Конечно безопасен.
На нем в конце концов ОС и драйвера написаны и еще много-много сопутствующего софта.

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

[d-stream]

mafusailmagoga, именно так -)

Answer 4

[Griboks]

Всё можно сделать и без указателей. Например, с помощью индексаторов либо массивов. Вы не знаете, как в массиве задать геттеры и сеттеры (get; set;)? Прочитайте побольше о свойствах и узнаете, что это есть ни что иное, как методы доступа к скрытым переменным.

Comments

[TheTalion]

И что же, в массиве можно для каждого отдельного значения задать разные геттеры и сетеры?

[Griboks]

Да, только вам придётся самому написать нужный функционал, а не использовать автореализуемые свойства.

Answer 5

[Ivankon]

Обратите внимание на новые возможности языка C# 7.0 там появились безопасные указатели:
https://docs.microsoft.com/en-us/dotnet/csharp/wha...