Re[10]: Два одинаковых типа - C/C++

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

К>Я бы предложил не морочить себе голову, а просто завернуть в структуру.
К>Пусть даже с публичным полем, — чтобы минимально возиться с вопросами, что надо от вектора, а что не надо. Потом при случае отрефакторить, благо, все точки использования хорошо видны (поиском по имени поля либо кровавым рефакторингом — сделать приватным и смотреть, где компиляция сломалась).

К>

К>using IntVec = std::vector<int>;

К>struct ElementId { IntVec data; };
К>struct LogicalId { IntVec data; };
К>

Практически это то же самое, что и в подходе с BOOST_STRONG_TYPEDEF, только без привлечения boost.

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

R>>Так что, вопрос можно ли использовать вектор для задания ID, или нельзя — это вообще оффтоп в данном случае.

_>Прикалываетесь?

Даже не думал.

_>

_>typedef int ID;
_>struct ElementId { ID value; };
_>struct LogicalId { ID value; };
_>

Не понял, что ты хочешь этим сказать. Разверни свою мысль словами, если не трудно.

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

R>Не понял, что ты хочешь этим сказать. Разверни свою мысль словами, если не трудно.

Мысть простоя: на практике идентификатора в виде числа фиксированной длинны более чем достаточно.

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

_>Мысть простоя: на практике идентификатора в виде числа фиксированной длинны более чем достаточно.

А как это противоречит тому, что написал я?

Даже не так. Как это, вообще, связано с тем, что написал я? Какое именно МОЁ высказывание вызывает у тебя несогласие?

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

R>А как это противоречит тому, что написал я?

typedef int ElementId;
typedef int LogicalId;

void func(ElementId&);
void func(LogicalId&); // <- ???

R>Даже не так. Как это, вообще, связано с тем, что написал я? Какое именно МОЁ высказывание вызывает у тебя несогласие?

"Не понял, что ты хочешь этим сказать. Разверни свою мысль словами, если не трудно."

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

_>"Не понял, что ты хочешь этим сказать. Разверни свою мысль словами, если не трудно."

Вот это сообщение я воспринял как несогласие. Только не понял, как какому именно из двух высказываний это несогласие относится:

Главный вопрос этой темы можно было бы переформулировать для чисел;
Вопрос, можно ли использовать вектор для задания ID, является оффтопом для данной темы.

Пояснишь?

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

R>Вот это сообщение я воспринял как несогласие. Только не понял, как какому именно из двух высказываний это несогласие относится:

R> Главный вопрос этой темы можно было бы переформулировать для чисел;
можно
R> Вопрос, можно ли использовать вектор для задания ID, является оффтопом для данной темы.
я просто высказал сомнения что вектор это не самый удачный выбор для типа идентификатора

R>Пояснишь?
Вы просто не в том контексте смотрите. Поэтому и возникли такие разночтения.

> ElementId — это уникальный Id элемента иерархии.
> LogicalId — тоже Id элемента той же иерархии, но без определенного слоя.

ElementId — это путь к элементу
LogicalId — это локальный путь, отностиельно некоторого узла.

То есть это дерево (аналог файловая система)

[ElementId]
root-->a-->b-->c-->element_1
root-->a-->b-->element_2
root-->d-->a-->element_3
root-->e-->a-->element_4

[LogicalId]
a-->element_3

И в качестве идентификаторов логично использовать числа 1,2,3,4

То есть назвать это не Id а Path:
ElementPath
LogicalPath

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

R>>Пояснишь?
_>Вы просто не в том контексте смотрите. Поэтому и возникли такие разночтения.
_> . . .

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

_>я просто высказал сомнения что вектор это не самый удачный выбор для типа идентификатора

Остановились мы вот на чём:

http://rsdn.org/forum/cpp/8871506.1

_> ID это число однозначно идентифицирующее что-либо.
R> Почему только число? А строка может быть?

Вот с этого места давай и продолжим. Твой ход.

Там после этого с твоей стороны была ещё одна фраза, но я её воспринял как шутку, беря во внимание смайлик в конце утверждения.

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

R>Остановились мы вот на чём:

R>http://rsdn.org/forum/cpp/8871506.1

R>

_>> ID это число однозначно идентифицирующее что-либо.
R>> Почему только число? А строка может быть?

R>Вот с этого места давай и продолжим. Твой ход.
Я смотрю вы заядлый шахматист.
Да строка может быть. Но желательно фиксированной длинны. Например "1PRTTaJesdNovgne6Ehcdu1fpEdX7913CK"

R>Там после этого с твоей стороны была ещё одна фраза, но я её воспринял как шутку, беря во внимание смайлик в конце утверждения.

я думала это трюфель

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

_>Да строка может быть. Но желательно фиксированной длинны. Например "1PRTTaJesdNovgne6Ehcdu1fpEdX7913CK"

Было бы здорово, если бы ты обосновывал свои утверждения а не просто постулировал. Для кого желательно, почему желательно, насколько желательно и т.п. В противном случае ты сам лишаешь меня возможности принять твою точку зрения.

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

R>Было бы здорово, если бы ты обосновывал свои утверждения а не просто постулировал. Для кого желательно, почему желательно и т.п.
Для быстродействия желательно фиксированный размер данных равный размеру регистра процессора или хотябы не сильно избыточный (не превосходящий L1 кэш)
Данные фиксированной длинны лучше размещаются в памяти и их проще кэшировать, читать, писать, сравнивать, чем данные непредсказуемой длинны. Для которых обычно используют hash функции, что бы уменьшить кол-во обращений непосредственно к телу. Вобщем сплошные дополнительные накладные расходы из ничего.

ps: промежуточные представления в виде строки, тоже никто не запрещает

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

R>>Было бы здорово, если бы ты обосновывал свои утверждения а не просто постулировал. Для кого желательно, почему желательно и т.п.
_>Для быстродействия желательно фиксированный размер данных равный размеру регистра процессора или хотябы не сильно избыточный (не превосходящий L1 кэш)
_>Данные фиксированной длинны лучше размещаются в памяти и их проще кэшировать, читать, писать, сравнивать, чем данные непредсказуемой длинны. Для которых обычно используют hash функции, что бы уменьшить кол-во обращений непосредственно к телу. Вобщем сплошные дополнительные накладные расходы из ничего.

_>ps: промежуточные представления в виде строки, тоже никто не запрещает

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

Итого, в качестве идентификаторов можно использовать: числа, перечисления и классы. Таким образом, если вернуться к началу дискусси, то ID — это что угодно, однозначно идентифицирующее что-либо.

Хорошо. И как мы приходим к заключению, что тип std::vector<int> не может или не должен использоваться в качестве ID?

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

R>Хорошо. И как мы приходим к заключению, что тип std::vector<int> не может или не должен использоваться в качестве ID.
Я нигде не писал что он не может быть использован. Я писал что возникают вопросы.
Типа:
— а не избыточенли такой тип в качестве идентификатора
— если это путь к объкету в некотором дереве то и называть его логичнее не идентификатором а "положением" location или "путём" path
— если это набор характеристик, то allele, bag of properties или вектором признаков

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

_>Я нигде не писал что он не может быть использован. Я писал что возникают вопросы.

Ну, как обычно: на третий день дискуссии настал момент уточнить предмет спора

_>Типа:
_>- а не избыточенли такой тип в качестве идентификатора

Всё может быть. Это вопрос к автору.

_>- если это путь к объкету в некотором дереве то и называть его логичнее не идентификатором а "положением" location или "путём" path
_>- если это набор характеристик, то allele, bag of properties или вектором признаков

Всё может быть. Чего ты до сих пор не задал эти вопросы автору?

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

R>Всё может быть. Чего ты до сих пор не задал эти вопросы автору?
Не видел в этом смысла.

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

R>>Всё может быть. Чего ты до сих пор не задал эти вопросы автору?
_>Не видел в этом смысла.

Вместо этого ты решил повыносить мозг мне

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

R>Вместо этого ты решил повыносить мозг мне

да

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

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

R>>Вот это сообщение я воспринял как несогласие. Только не понял, как какому именно из двух высказываний это несогласие относится:

R>> Главный вопрос этой темы можно было бы переформулировать для чисел;
_>можно
R>> Вопрос, можно ли использовать вектор для задания ID, является оффтопом для данной темы.
_>я просто высказал сомнения что вектор это не самый удачный выбор для типа идентификатора

R>>Пояснишь?
_>Вы просто не в том контексте смотрите. Поэтому и возникли такие разночтения.

>> ElementId — это уникальный Id элемента иерархии.
>> LogicalId — тоже Id элемента той же иерархии, но без определенного слоя.

_>ElementId — это путь к элементу
_>LogicalId — это локальный путь, отностиельно некоторого узла.

_>То есть это дерево (аналог файловая система)

_>[ElementId]
_>root-->a-->b-->c-->element_1
_>root-->a-->b-->element_2
_>root-->d-->a-->element_3
_>root-->e-->a-->element_4

_>[LogicalId]
a-->>element_3

_>И в качестве идентификаторов логично использовать числа 1,2,3,4

_>То есть назвать это не Id а Path:
_>ElementPath
_>LogicalPath

Путь в данном случае — это способ реализации идентификатора. Id реализовано на основе path.

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

DP> DP>>ElementId — это уникальный Id элемента иерархии.
DP> DP>>LogicalId — тоже Id элемента той же иерархии, но без определенного слоя.
DP> Проблема в названии?
Да, название странное. Это Path, Position, Coords, Address, Location, и т.п. Неясно причём тут ID. Чем является элемент в векторе тогда?

avalon/3.0.0

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

DP> Нет, заводить на это отдельный класс и наследовать все методы вектора нет смысла, ибо они будут просто вызываться с теми же сигнатурами.
Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?
В любом случае, это недостаточное условие для применения наследования. Наследование подразумевает, что оно будет прозрачно приводиться к базовому типу и всё что работает с вектором должно работать так же как и с твоим классом.
https://en.wikipedia.org/wiki/Composition_over_inheritance

avalon/3.0.0

	От:	rg45
	Дата:	23.12.24 10:50
	Оценка:

	От:	rg45
	Дата:	23.12.24 10:53
	Оценка:

	От:	kov_serg
	Дата:	23.12.24 10:58
	Оценка:

	От:	rg45
	Дата:	23.12.24 11:00
	Оценка:

	От:	kov_serg
	Дата:	23.12.24 11:37
	Оценка: