Здравствуйте, Кодт, Вы писали:
К>Я бы предложил не морочить себе голову, а просто завернуть в структуру. К>Пусть даже с публичным полем, — чтобы минимально возиться с вопросами, что надо от вектора, а что не надо. Потом при случае отрефакторить, благо, все точки использования хорошо видны (поиском по имени поля либо кровавым рефакторингом — сделать приватным и смотреть, где компиляция сломалась).
К>
Здравствуйте, kov_serg, Вы писали:
R>>Так что, вопрос можно ли использовать вектор для задания ID, или нельзя — это вообще оффтоп в данном случае.
_>Прикалываетесь?
Даже не думал.
_>
_>typedef int ID;
_>struct ElementId { ID value; };
_>struct LogicalId { ID value; };
_>
Не понял, что ты хочешь этим сказать. Разверни свою мысль словами, если не трудно.
--
Справедливость выше закона. А человечность выше справедливости.
я воспринял как несогласие. Только не понял, как какому именно из двух высказываний это несогласие относится:
Главный вопрос этой темы можно было бы переформулировать для чисел;
Вопрос, можно ли использовать вектор для задания ID, является оффтопом для данной темы.
Пояснишь?
--
Справедливость выше закона. А человечность выше справедливости.
я воспринял как несогласие. Только не понял, как какому именно из двух высказываний это несогласие относится:
R> Главный вопрос этой темы можно было бы переформулировать для чисел;
можно R> Вопрос, можно ли использовать вектор для задания ID, является оффтопом для данной темы.
я просто высказал сомнения что вектор это не самый удачный выбор для типа идентификатора
R>Пояснишь?
Вы просто не в том контексте смотрите. Поэтому и возникли такие разночтения.
> ElementId — это уникальный Id элемента иерархии. > LogicalId — тоже Id элемента той же иерархии, но без определенного слоя.
ElementId — это путь к элементу
LogicalId — это локальный путь, отностиельно некоторого узла.
Здравствуйте, kov_serg, Вы писали:
R>>Пояснишь? _>Вы просто не в том контексте смотрите. Поэтому и возникли такие разночтения. _> . . .
Разночтения возникли из-за того, что ты неожиданно перескочил к тому, что мы обсуждали выше. Я считал, что тот вопрос мы уже закрыли, но если хочешь, можем продолжить обсуждение.
_>я просто высказал сомнения что вектор это не самый удачный выбор для типа идентификатора
_>> ID это число однозначно идентифицирующее что-либо.
R>> Почему только число? А строка может быть?
R>Вот с этого места давай и продолжим. Твой ход.
Я смотрю вы заядлый шахматист.
Да строка может быть. Но желательно фиксированной длинны. Например "1PRTTaJesdNovgne6Ehcdu1fpEdX7913CK"
R>Там после этого с твоей стороны была ещё одна фраза, но я её воспринял как шутку, беря во внимание смайлик в конце утверждения.
Здравствуйте, kov_serg, Вы писали:
_>Да строка может быть. Но желательно фиксированной длинны. Например "1PRTTaJesdNovgne6Ehcdu1fpEdX7913CK"
Было бы здорово, если бы ты обосновывал свои утверждения а не просто постулировал. Для кого желательно, почему желательно, насколько желательно и т.п. В противном случае ты сам лишаешь меня возможности принять твою точку зрения.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Было бы здорово, если бы ты обосновывал свои утверждения а не просто постулировал. Для кого желательно, почему желательно и т.п.
Для быстродействия желательно фиксированный размер данных равный размеру регистра процессора или хотябы не сильно избыточный (не превосходящий L1 кэш)
Данные фиксированной длинны лучше размещаются в памяти и их проще кэшировать, читать, писать, сравнивать, чем данные непредсказуемой длинны. Для которых обычно используют hash функции, что бы уменьшить кол-во обращений непосредственно к телу. Вобщем сплошные дополнительные накладные расходы из ничего.
ps: промежуточные представления в виде строки, тоже никто не запрещает
Здравствуйте, kov_serg, Вы писали:
R>>Было бы здорово, если бы ты обосновывал свои утверждения а не просто постулировал. Для кого желательно, почему желательно и т.п. _>Для быстродействия желательно фиксированный размер данных равный размеру регистра процессора или хотябы не сильно избыточный (не превосходящий L1 кэш) _>Данные фиксированной длинны лучше размещаются в памяти и их проще кэшировать, читать, писать, сравнивать, чем данные непредсказуемой длинны. Для которых обычно используют hash функции, что бы уменьшить кол-во обращений непосредственно к телу. Вобщем сплошные дополнительные накладные расходы из ничего.
_>ps: промежуточные представления в виде строки, тоже никто не запрещает
А, то есть, желательно с точки зрения быстродействия. Ну, ОК. То есть, в тех местах, где быстродействие не критично, допустимо применять также и строки переменной длины, согласен?
Итого, в качестве идентификаторов можно использовать: числа, перечисления и классы. Таким образом, если вернуться к началу дискусси
Здравствуйте, rg45, Вы писали:
R>Хорошо. И как мы приходим к заключению, что тип std::vector<int> не может или не должен использоваться в качестве ID.
Я нигде не писал что он не может быть использован. Я писал что возникают вопросы.
Типа:
— а не избыточенли такой тип в качестве идентификатора
— если это путь к объкету в некотором дереве то и называть его логичнее не идентификатором а "положением" location или "путём" path
— если это набор характеристик, то allele, bag of properties или вектором признаков
Здравствуйте, kov_serg, Вы писали:
_>Я нигде не писал что он не может быть использован. Я писал что возникают вопросы.
Ну, как обычно: на третий день дискуссии настал момент уточнить предмет спора
_>Типа: _>- а не избыточенли такой тип в качестве идентификатора
Всё может быть. Это вопрос к автору.
_>- если это путь к объкету в некотором дереве то и называть его логичнее не идентификатором а "положением" location или "путём" path _>- если это набор характеристик, то allele, bag of properties или вектором признаков
Всё может быть. Чего ты до сих пор не задал эти вопросы автору?
--
Справедливость выше закона. А человечность выше справедливости.