Стал замечать , что нужно довольно часто иметь такую структуру данных.
Использование простого Dictionary не очень удобно, т.к. добавление или изменение требует нескольких TryGetValue и Add в случае если нет элементов.
Dictionary<Y,Z> yz;
if (!d.TryGetValue(x, out yz)) { yz = d[x] = new Dictionary<Y,Z>(); }
Z z;
if (!yz.TryGetValue(y, out z)) { z = yz[y] = new Z(); }
z.CallMethod();
На данный момент добавились методы расширения GetOrAdd и код легко переписывается в :
d.GetOrAdd(x, _ => new Dictionary<Y,Z>()).GetOrAdd(y, _ => new Z()).CallMethod();
Однако это начинает утомлять.
В итоге подумываю над созданием более удобного класса NestedDictionary<K,V,W> и возможно далее NestedDictionary<K,V,W,X> ...
Что делаете в таких случаях ?
Есть ли готовый вариант для этого ?
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, agat50, Вы писали:
A>>Здравствуйте, _NN_, Вы писали:
A>>Можно использовать Tuple как ключ. http://stackoverflow.com/questions/955982/tuples-or-arrays-as-dictionary-keys-in-c-sharp
_NN>Тогда сама цель словаря по отдельным ключам пропадает. _NN>В случае с кортежами для удаление ключа X придётся вместо простого d.Remove(x) городить код.
Тогда мб стоит свое расширение для такого вида словарей написать, GetOrAddNew(firstKey,secondKey,...).
Здравствуйте, _NN_, Вы писали:
_NN>Что делаете в таких случаях ?
Решаю исходную проблему — переусложнённый код. NestedDictionary<K,V,W,X> — словарь словарей словарей? Серьёзно?
Вот на 100%, без исключений — если для решения задачи приходится вводить конструкции, которые плохо ложатся на язык, то проблема или в формулировке задачи, или в попытке решить задачу с наскока, без введения промежуточного слоя абстракций.
Вариантов решения много, стандартные:
* Если класс используется для хранения данных (читай, ссылка на словарь в поле) — не ленимся и заводим типизированную коллекцию (как правило, наследника от KeyedCollection<>).
* Для промежуточных вещей, которые не уходят за границы метода, за глаза хватает словаря по составному ключу.
* Для математики — SparseMatrix из Math.Net или отсюда и т.д.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>Что делаете в таких случаях ? S>Решаю исходную проблему — переусложнённый код. NestedDictionary<K,V,W,X> — словарь словарей словарей? Серьёзно?
S>Вот на 100%, без исключений — если для решения задачи приходится вводить конструкции, которые плохо ложатся на язык, то проблема или в формулировке задачи, или в попытке решить задачу с наскока, без введения промежуточного слоя абстракций.
Ну скажем нужен словарь на процесс -> поток -> данные.
И вот получаем Dictionary<int, Dictioary<int, Data>>.
Что взамен предлагается ? Dictionary<Tuple<int,int>,Data>?
Здравствуйте, _NN_, Вы писали: _NN>В итоге подумываю над созданием более удобного класса NestedDictionary<K,V,W> и возможно далее NestedDictionary<K,V,W,X> ...
И в чем проблема? Что-нибудь типа такого?
public class MyDictionary<X, Y> : Dictionary<X, Y>
where Y : new()
{
public new Y this[X index]
{
get
{
if (!base.ContainsKey(index))
base.Add(index, new Y());
return base[index];
}
}
}
public class NestedDictionary<X, Y, Z> : MyDictionary<X, MyDictionary<Y, Z>>
where Z : new()
{ }
//использование
nestedDictionary[x][y].CallMethod();
Можешь еще красивый двойной индексер себе дописать, если лень скобки ставить.
_NN>Что делаете в таких случаях ?
Используем ООП. Dictionary<X, Dictionary<Y, Z>> по глупому же выглядит, нет?
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, _NN_, Вы писали: _NN>Почему по глупому ?
Потому что процесс это не только словарь потоков, а еще какие-то свойства/методы. Пиши класс процесса со словарем потоков и кучей всего остального.
_NN>Как решается такое ? А если будет больше вложенности ?
Используй хештаблицу. Хеш посчитать сможешь? Там даже количество вложений не будет иметь значения.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Sinix, Вы писали:
S>Вот на 100%, без исключений — если для решения задачи приходится вводить конструкции, которые плохо ложатся на язык, то проблема или в формулировке задачи, или в попытке решить задачу с наскока, без введения промежуточного слоя абстракций.
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, _NN_, Вы писали: _NN>>Почему по глупому ?
Р>Потому что процесс это не только словарь потоков, а еще какие-то свойства/методы. Пиши класс процесса со словарем потоков и кучей всего остального.
А если мне нужно только список потоков ?
Давай усложним на более реальный пример.
Сессия -> рабочий стол -> процесс -> поток -> данные.
Какое предложение тут будет ?
class Session : KeyValueCollection<int, Desktop> { ... }
class Desktop : KeyValueCollection<int, Process> { ... }
class Process : KeyValueCollection<int, Thread> { ... }
class Thread : KeyValueCollection<int, Data> { ... }
class Data { ... }
S>>Вот на 100%, без исключений — если для решения задачи приходится вводить конструкции, которые плохо ложатся на язык, то проблема или в формулировке задачи, или в попытке решить задачу с наскока, без введения промежуточного слоя абстракций. EP>В C++ STL это работает из коробки:
Ну так коллекции разные
В дотнете бросается исключение, если ключа нет в словаре. Но ничего не мешает написать свой наследник от Dictionary с поведением, аналогичным плюсам. Именно что-то похожее и имел в виду, когда говорил про нехватку слоя абстракций.
S>>Вот на 100%, без исключений — если для решения задачи приходится вводить конструкции, которые плохо ложатся на язык, то проблема или в формулировке задачи, или в попытке решить задачу с наскока, без введения промежуточного слоя абстракций.
_NN>Ну скажем нужен словарь на процесс -> поток -> данные. _NN>И вот получаем Dictionary<int, Dictioary<int, Data>>.
_NN>Что взамен предлагается ? Dictionary<Tuple<int,int>,Data>?
Как всегда, всё есть в официальных гадлайнах. Начинаем с гипотетического сценария использования:
processes[someId].Thread[threadId];
Т.е. имеем коллекцию процессов, у процесса — свойство с коллекций потоков. Сами коллекции пишутся в одну строчку наследованием от KeyedCollection<,>.
Если с сценарием не угадал, можно попробовать вариант, что подсказал Evgeny.Panasyuk: пишем словарь (или extension метод), поведение: словарь заполняется new TValue(), если ключа нет в словаре. Конечно, придётся следить, чтоб не замусорить словарь ненужными ключами.
Здравствуйте, _NN_, Вы писали:
_NN>>>Почему по глупому ? Р>>Потому что процесс это не только словарь потоков, а еще какие-то свойства/методы. Пиши класс процесса со словарем потоков и кучей всего остального.
_NN>А если мне нужно только список потоков ? _NN>Давай усложним на более реальный пример. _NN>Сессия -> рабочий стол -> процесс -> поток -> данные.
Если это и есть ваша задача, то вы не правильно её понимаете. процессы и потоки (thread) одни и те же среди всех сессий. Их идентификаторы не пересекаются — у разных сессий не может быть процессов или потоков с одинаковыми идентификаторами. Поэтому достаточно иметь словарь поток-данные.
Далее, если нужно, мульти-словарь процесс-потоки итэдэ. Это уже делается довольно просто всего лишь несколькими методами расширения.
Здравствуйте, _NN_, Вы писали:
_NN>Давай усложним на более реальный пример.
_NN>Сессия -> рабочий стол -> процесс -> поток -> данные. _NN>Какое предложение тут будет ?
Всё то же — создавать класс с свойством-коллекцией. Это в одну строчку делается, например
_NN>И все это вместо простых чисел ?
Разумеется. Потому что твоя гипотетическая простота на практике оборачивается усложнением. Вместо удобной объектной модели ты в одной коллекции хранишь кишки каждого из элементов. Мало того, что это неудобно (легко забыть и перепутать порядок ключей), так ещё и сыпется на простейших задачах вида "добавить имя к процессу".
Здравствуйте, Sinix, Вы писали:
S>>>Вот на 100%, без исключений — если для решения задачи приходится вводить конструкции, которые плохо ложатся на язык, то проблема или в формулировке задачи, или в попытке решить задачу с наскока, без введения промежуточного слоя абстракций. EP>>В C++ STL это работает из коробки: S>Ну так коллекции разные S>В дотнете бросается исключение, если ключа нет в словаре.
Это понятно. В STL есть отдельный метод find который не создаёт ничего, а только ищет.
А вообще, вот такое поведение, где operator[] создаёт default в случае отсутствия — очень удобно. Потому что обычно default является нейтральным элементом относительно применяемых операций. Простой пример это подсчёт количества вхождений — ++count[id], или например конкатенация строк result_string[id] += s;, или случай ТС со вложенными контейнерами.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А вообще, вот такое поведение, где operator[] создаёт default в случае отсутствия — очень удобно.
Согласен. Реально удобно для словарей, в которые постоянно складываются данные.
Проблема в том, код в дотнете заточен под политику "все потенциально проблемные действия должны быть оформлены явно".
Добавление элемента в словарь при получении значения очень неочевидно и может выстрелить самым внеапным способом. Например, сценарий "один раз заполнили — потом возвращаем что есть": в теории словарь readonly, по факту — незаметно заполняется "мусорными" ключами.
В общем, с точки зрения оф.гадлайнов для дотнета, такая штука должна предлагаться как приятное дополнение а не быть включённой в дефолтный контейнер
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А вообще, вот такое поведение, где operator[] создаёт default в случае отсутствия — очень удобно. Потому что обычно default является нейтральным элементом относительно применяемых операций. Простой пример это подсчёт количества вхождений — ++count[id], или например конкатенация строк result_string[id] += s;, или случай ТС со вложенными контейнерами.
Дефолтное значение это обычно null=) И далеко не каждый класс имеет дефолтный конструктор. Имхо лучше не надо такое добавлять.
Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>Это понятно. В STL есть отдельный метод find который не создаёт ничего, а только ищет. EP>А вообще, вот такое поведение, где operator[] создаёт default в случае отсутствия — очень удобно. Потому что обычно default является нейтральным элементом относительно применяемых операций. Простой пример это подсчёт количества вхождений — ++count[id], или например конкатенация строк result_string[id] += s;, или случай ТС со вложенными контейнерами.
А для классов default(T) будет null. И не всегда нужен 0 по умолчанию для чисел.
По уму нужно передавать в конструктор словаря конструктор значения по умолчанию.
Тогда
d.GetOrAdd(ключ) будет возвращать значение по умолчанию. И логика понятна.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, agat50, Вы писали:
EP>>А вообще, вот такое поведение, где operator[] создаёт default в случае отсутствия — очень удобно. Потому что обычно default является нейтральным элементом относительно применяемых операций. Простой пример это подсчёт количества вхождений — ++count[id], или например конкатенация строк result_string[id] += s;, или случай ТС со вложенными контейнерами. A>Дефолтное значение это обычно null=)
Это только при pointer/reference-semantics. У value-типов, превалирующих в C++, обычно есть вполне конкретный дефолт-конструктор, и это очень удобно.
A>И далеко не каждый класс имеет дефолтный конструктор.
Без проблем. Нет дефолтного конструктора — метод нельзя использовать, он не работает — ошибка компиляции. Если есть — то можно.
Здравствуйте, Serginio1, Вы писали:
S>По уму нужно передавать в конструктор словаря конструктор значения по умолчанию. S>Тогда S> d.GetOrAdd(ключ) будет возвращать значение по умолчанию. И логика понятна.
Либо тип-wrapper, у которого будет другой конструктор — так не будет оверхеда на хранение значения.
Либо просто отдельная функция как уже выше предлагали, а-ля get_or_default(map, key, default).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>По уму нужно передавать в конструктор словаря конструктор значения по умолчанию. S>>Тогда S>> d.GetOrAdd(ключ) будет возвращать значение по умолчанию. И логика понятна.
EP>Либо тип-wrapper, у которого будет другой конструктор — так не будет оверхеда на хранение значения. EP>Либо просто отдельная функция как уже выше предлагали, а-ля get_or_default(map, key, default).
Так есть же GetOrAdd Method в разных вариациях
Вот простейший
public TValue GetOrAdd(
TKey key,
Func<TKey, TValue> valueFactory
)
А с дефаултным конструктором значения код будет значительно короче, так как конструктор значения в основном всегда одинаков
То есть
Но по большому разница то не велика, если определить Func<TKey, TValue> как переменную
d.GetOrAdd(ключ)
d.GetOrAdd(ключ,Конструктор)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, _NN_, Вы писали:
_NN>Использование простого Dictionary не очень удобно, т.к. добавление или изменение требует нескольких TryGetValue и Add в случае если нет элементов.
Если я правильно понял, весь сыр-бор из-за того, что какой-то умник решил вместо удобного "дефолтового значения" сыпать исключения при отсутствии ключа. В Перле (за 20 лет практического применения!) ни один не пожаловался, что есть дефолтовая величина. Отсюда простой вывод — гнать в шею этих танцоров-архитекторов и внедрять нормальный словарь.
X>Далее, если нужно, мульти-словарь процесс-потоки итэдэ. Это уже делается довольно просто всего лишь несколькими методами расширения.
Это как вариант конечно.
Подумываю об этом.
X>Если рассуждать об абстрактной задаче, то X>
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, _NN_, Вы писали: _NN>>Dictionary и есть хештаблица. _NN>>Или я чего-то не понимаю ?
Р>Ну да. Так и посчитайте один хеш из всех своих параметров и храните в одном dictionary без вложенности.
А удобство пользования ?
Вместо d[x][y] писать d.Where(_ => _.X == x && _.Y == y).First() ?
Удалить вместо простого Remove придется писать намного больше кода.
Здравствуйте, Sinix, Вы писали:
_NN>>И все это вместо простых чисел ? S>Разумеется. Потому что твоя гипотетическая простота на практике оборачивается усложнением. Вместо удобной объектной модели ты в одной коллекции хранишь кишки каждого из элементов. Мало того, что это неудобно (легко забыть и перепутать порядок ключей), так ещё и сыпется на простейших задачах вида "добавить имя к процессу".
Осталось написать код для MyCollection и перейти на C# 6
Здравствуйте, _NN_, Вы писали: _NN>А удобство пользования ?
Блин, хеш подсчитать, не новые объекты составлять. Вот тебе простейший со стрингом (не делай так, придумай какой-нибудь более приятный алгоритм)
public class MyCoolDictionary<T>
where T : new()
{
private Dictionary<string, T> _internalDictionary = new Dictionary<string, T>();
public T this[object x, params object[] others]
{
get
{
var hash = this.GetHash(x, others);
if (!_internalDictionary.ContainsKey(hash))
_internalDictionary.Add(hash, new T());
return _internalDictionary[hash];
}
}
private string GetHash(object x, params object[] others)
{
var str = new StringBuilder();
str.Append(x.GetHashCode());
foreach (var obj in others)
str.Append(obj.GetHashCode());
return str.ToString();
}
}
_NN>Вместо d[x][y] писать d.Where(_ => _.X == x && _.Y == y).First() ?
d[x, y, z /*...*/]
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, _NN_, Вы писали: _NN>>А удобство пользования ?
Р>Блин, хеш подсчитать, не новые объекты составлять. Вот тебе простейший со стрингом (не делай так, придумай какой-нибудь более приятный алгоритм)
Об этом я изначально и говорил, создать специализированные словари для множественных вложений.
Я тут вижу простой список объектов Data. Если будет достаточно простым перебором списка найти нужный объект, то городить огород с вложенными словарями не требуется. Добавь в Data идентификаторы для процессов, потоков, окон, да и всё.
Вместо двух словарей проще использовать один с составным ключом. Редко пеишу на C# но что типа такого
public struct MyStruct<X,Y>
{
public X СвойствоX;
public Y СвойствоY;
public MyStruct(X СвойствоX, Y СвойствоY)
{
this.СвойствоX = СвойствоX;
this.СвойствоY = СвойствоY;
}
public override int GetHashCode()
{
//Упростим задачу и сделаем по простомуstring str= Convert.ToBase64String(BitConverter.GetBytes(СвойствоX.GetHashCode()))+ Convert.ToBase64String(BitConverter.GetBytes(СвойствоY.GetHashCode()));
return str.GetHashCode();
}
//Можно взять из Tuple
//internal static int CombineHashCodes(int h1, int h2)
//{
// return (h1 << 5) + h1 ^ h2;
//}public override bool Equals(object obj)
{
if (obj.GetType()!= GetType()) return false;
var Объект = (MyStruct<X, Y>)obj;
return СвойствоX.Equals(Объект.СвойствоX) && СвойствоY.Equals(Объект.СвойствоY);
}
}
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Ромашка, Вы писали:
Р>>Здравствуйте, _NN_, Вы писали: _NN>>>Dictionary и есть хештаблица. _NN>>>Или я чего-то не понимаю ?
Р>>Ну да. Так и посчитайте один хеш из всех своих параметров и храните в одном dictionary без вложенности.
_NN>А удобство пользования ? _NN>Вместо d[x][y] писать d.Where(_ => _.X == x && _.Y == y).First() ? _NN>Удалить вместо простого Remove придется писать намного больше кода.
Не намного пройтись по ключам и найти Ключи по X. Всего 2 строчки
var ключи=d.Keys.Where(key=> key.Item1==x).Select(key=> key).ToList();
foreach (var ключ in ключи) d.Remove(ключ );
Здравствуйте, Serginio1, Вы писали:
S> Либо сделать наследника от Dictionary и использовать конструктор значения по умолчанию S>http://rsdn.ru/forum/dotnet/6218191.1
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Serginio1, Вы писали:
S>> Либо сделать наследника от Dictionary и использовать конструктор значения по умолчанию S>>http://rsdn.ru/forum/dotnet/6218191.1
_NN>Либо специализированный класс и всё еще проще: _NN>
_NN>d.RemoveByFirst(x)
_NN>d[x,y]
_NN>
Наследник проще в том, что нужно добавить всего несколько методов, но используя методы словаря плюс расширения.
специализированный класс я так понимаю будет врапером?
Хотя конечно можно все сгенерить по метаданным например T4.
А можно взять исходники и переделать под себя.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Наследник проще в том, что нужно добавить всего несколько методов, но используя методы словаря плюс расширения.
Можно и так, но тогда есть риск , что кто-то сделает не по правилам.
S>специализированный класс я так понимаю будет врапером?
Да. Снаружи удобство использования, внутри реализация как угодно.
S> Хотя конечно можно все сгенерить по метаданным например T4.
Да методов не так много нужно
S> А можно взять исходники и переделать под себя.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Serginio1, Вы писали:
S>> Наследник проще в том, что нужно добавить всего несколько методов, но используя методы словаря плюс расширения. _NN>Можно и так, но тогда есть риск , что кто-то сделает не по правилам.
Ну я особо разницы в удобстве
d[x,y] и d.GetOrAdd(x).GetOrAdd(y) не вижу. Зато минимум изменений.
Да и при работе с туплами можно еще упростить
d.MyGetOrAdd(x,у).
и солнце б утром не вставало, когда бы не было меня