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

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

S>>Это запросто могут быть координаты в многомерном пространстве.
_>Это уже не id а набор признаков

В проекте, которому сейчас помогаю, как раз объекты однозначно идентифицируются координатами в N-мерном пространстве. И это именно что полный аналог Id, а не набор признаков.

S>>И запросто может быть так, что количество измерений в этом пространстве определяется динамически и неизвестно на этапе компиляции, поэтому и std::vector, а не std::array.

_>Дело не в этом. Id предполагает хотя бы сравнение этих самых id

Если вы не в курсе, то для std::vector определены операторы сравнения: https://en.cppreference.com/w/cpp/container/vector (раздел Non-member functions).

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

DP>Возможно ли сделать так, чтобы такое не компилилось, или хотя бы компилилось с предупреждением?

typedef struct ElementId : std::vector<int> {};
typedef struct LogicalId : std::vector<int> {};

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

·>Не надо так делать. Лучше так:

Обоснование будет какое-нибудь?

·> // методы, имеющие смысл для id, а не вся простыня вектора

А почему ты уверен, что не вся простыня вектора имеет смысл для ID? Если человек выбрал вектор для задания собственных типов, то, возможно, ему и нужна вся "простыня"?

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

DP>Привет. Есть два типа определенные одинаково:

Сейчас это один тип

DP>Возможно ли сделать так, чтобы такое не компилилось, или хотя бы компилилось с предупреждением?

Тут уже посоветовали наследоваться от вектора. Имхо, это плохая идея, так как она может в некоторых местах протечь (где-нибудь перепутать пользовательский тип и сырой вектор — в ту или другую сторону).

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

using IntVec = std::vector<int>;

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

Код становится громоздче на несколько символов, кажется, не жалко. Зато читаемость повышается.

void func(ElementId id) {
  ..... for (int i: id.data) .....
  ..... id.data[0] .....
  ..... std::size(id.data) .....
}

.... func(ElementId{.data = {1,2,3,4,5}} .....

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

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

DP>Привет. Есть два типа определенные одинаково:
DP>

DP>typedef std::vector<int> ElementId;
DP>typedef std::vector<int> LogicalId;
DP>

.....
DP>Возможно ли сделать так, чтобы такое не компилилось, или хотя бы компилилось с предупреждением?

Ы?
https://www.boost.org/doc/libs/1_61_0/libs/serialization/doc/strong_typedef.html

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

DP> Привет. Есть два типа определенные одинаково:
DP>

DP> typedef std::vector<int> ElementId;
DP> typedef std::vector<int> LogicalId;
DP>

Не надо так делать. Лучше так:

class ElementId
{
private: 
   std::vector<int> value;
public:
   // методы, имеющие смысл для id, а не вся простыня вектора
}

avalon/3.0.0

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

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

Не. думаю не стоит

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

R>>Почему только число? А строка может быть?
_>Потому что из простых соображений на практике достаточно int32 или int64 для распределённых систем guid(int128)

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

typedef int ElementId;
typedef int LogicalId;

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

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

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

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

R>typedef int ElementId;
R>typedef int LogicalId;

R>void func(ElementId&); // <- ???
R>

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

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

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

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

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

да

Привет. Есть два типа определенные одинаково:

typedef std::vector<int> ElementId;
typedef std::vector<int> LogicalId;

Есть функция, принимающая один из них:

void func(ElementId& id)
{
}

Получается что такой вызов прокатывает без предупреждения:

LogicalId logical_id;
func(logical_id);

Возможно ли сделать так, чтобы такое не компилилось, или хотя бы компилилось с предупреждением?

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

DP>>Возможно ли сделать так, чтобы такое не компилилось, или хотя бы компилилось с предупреждением?
_>

_>typedef struct ElementId : std::vector<int> {};
_>typedef struct LogicalId : std::vector<int> {};
_>

?

А чтобы эти можно было ещё и пользоваться, нелишним будет открыть доступ к конструкторам базового класса. И typedef здесь избыточен:

struct ElementId : std::vector<int> {using vector::vector;};
struct LogicalId : std::vector<int> {using vector::vector;};

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

R>А чтобы эти можно было ещё и пользоваться, нелишним будет открыть доступ к конструкторам базового класса. И typedef здесь избыточен:

R>

R>struct ElementId : std::vector<int> {using vector::vector;};
R>struct LogicalId : std::vector<int> {using vector::vector;};
R>

Да вы правы typedef избыточен, я просто скопировал из вопроса

Но в целом название ElementId и LogicalId с реализацие в виде вектора, например у меня вызывают некоторые вопросы.

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

_>Но в целом название ElementId и LogicalId с реализацие в виде вектора, например у меня вызывают некоторые вопросы.

Ну так, тебе ни что не мешает задать эти вопросы автору.

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

r> ·>Не надо так делать. Лучше так:
r> Обоснование будет какое-нибудь?
Код проще читать и поддерживать.

r> ·> // методы, имеющие смысл для id, а не вся простыня вектора
r> А почему ты уверен, что не вся простыня вектора имеет смысл для ID?
Потому что ID это (is-a) не вектор.

r> Если человек выбрал вектор для задания собственных типов, то, возможно, ему и нужна вся "простыня"?
Интуитивно уверен, что невозможно в данном случае. Буду рад услышать обоснование нужности, желательно от автора.

avalon/3.0.0

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

r>> Обоснование будет какое-нибудь?
·>Код проще читать и поддерживать.

Ты про какой код? Любой, или конткретный?

r>> А почему ты уверен, что не вся простыня вектора имеет смысл для ID?
·>Потому что ID это (is-a) не вектор.

Откуда ты знаешь, что у него за ID? Он мог бы заменить оригинальные имена на безликие Foo и Bar. К чему бы ты тогда придрался?

·>Интуитивно уверен, что невозможно в данном случае. Буду рад услышать обоснование нужности, желательно от автора.

Обоснования делает тот, кто делает утверждения. Так заведено.

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

r>> А почему ты уверен, что не вся простыня вектора имеет смысл для ID?
·>Потому что ID это (is-a) не вектор.

А если он напишет так:

class ElementId
{
private: 
   typedef std::vector<int> Value;
   Value value;
public:
   // методы, имеющие смысл для id, а не вся простыня вектора
};

У тебя тоже возникнут замечания?

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

r>>> Обоснование будет какое-нибудь?
R>·>Код проще читать и поддерживать.
R>Ты про какой код? Любой, или конткретный?
Конкретный, конечно. Любой код можно писать любым способом.

r>>> А почему ты уверен, что не вся простыня вектора имеет смысл для ID?
R>·>Потому что ID это (is-a) не вектор.
R>Откуда ты знаешь, что у него за ID? Он мог бы
Тогда бы это бы был бы другой вопрос бы. И я бы отвечал бы по-другому бы.

R>·>Интуитивно уверен, что невозможно в данном случае. Буду рад услышать обоснование нужности, желательно от автора.
R>Обоснования делает тот, кто делает утверждения.
Судя по именам, это какая то конкретная предметная область, а значит это бизнес сущности, публичный интерфейс которых задаётся бизнес-требованиями, а не Стандартной библиотекой.

R>Так заведено.
Ещё в форумах заведено рассказывать о решаемой задаче, а не спрашивать почему выбранное решение не работает.

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

R>·>Потому что ID это (is-a) не вектор.
R>А если он напишет так:
R>...
R>У тебя тоже возникнут замечания?
Ок. А чем это принципиально отличается от моего?

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

R>>У тебя тоже возникнут замечания?
·>Ок. А чем это принципиально отличается от моего?

Так это к тебе вопрос. Видишь ли ты здесь принципиальные отличия от своего варианта и есть ли у тебя какие-либо замечания?

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

R>>Ты про какой код? Любой, или конткретный?
·>Конкретный, конечно. Любой код можно писать любым способом.

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

R>>Откуда ты знаешь, что у него за ID? Он мог бы
·>Тогда бы это бы был бы другой вопрос бы. И я бы отвечал бы по-другому бы.
·>Судя по именам, это какая то конкретная предметная область, а значит это бизнес сущности, публичный интерфейс которых задаётся бизнес-требованиями, а не Стандартной библиотекой.

То есть, ты по одним только именам реконструировал полную семантику типов и требования к ним. Ну, круто. Все экстрасенсы мира завидуют.

R>>Так заведено.
·>Ещё в форумах заведено рассказывать о решаемой задаче, а не спрашивать почему выбранное решение не работает.

То есть, если какой-то новичок в форуме допускает какую-то погрешность, это сразу даёт тебе повод говорить что попало?

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

r> ·>Конкретный, конечно. Любой код можно писать любым способом.
r> Похоже, ты знаешь больше деталей. Ну, так расскажи тогда, почему именно в этом конкретном случае "так делать не надо".
Я рассказал выше.

r> То есть, ты по одним только именам реконструировал полную семантику типов и требования к ним. Ну, круто. Все экстрасенсы мира завидуют.
Не экстрасенс, а опыт. Буду рад ошибиться, чему-нибудь новому научусь.
Ещё раз. Читай внимательно. Наследование — это создание is-a отношения. Т.е. "хитровывернутый вектор" может наследовать вектор. А вот id вектором не является, по крайней мере в общепринятой терминологии. Если у него там какой-то особенный такой id, который ещё и вектор, то у него плохое именование сущностей.

r> То есть, если какой-то новичок в форуме допускает какую-то погрешность, это сразу даёт тебе повод говорить что попало?
Так я не говорил что попало.

avalon/3.0.0

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

r> R>>У тебя тоже возникнут замечания?
r> ·>Ок. А чем это принципиально отличается от моего?
r> Так это к тебе вопрос. Видишь ли ты здесь принципиальные отличия от своего варианта и есть ли у тебя какие-либо замечания?
не вижу, замечаний нет.

avalon/3.0.0

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

·>не вижу, замечаний нет.

Ну так я же и интересуюсь, почему вот так "делать не надо":

typedef std::vector<int> ElementId;
typedef std::vector<int> LogicalId;

А вот так "замечаний нет":

typedef std::vector<int> Value;

Если "Value" может быть вектором, то почему "Id" не может быть вектором?

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

·>Я рассказал выше.

Выше я видел только домыслы и голословное постулирование

·>Не экстрасенс, а опыт. Буду рад ошибиться, чему-нибудь новому научусь.

Уникальный опыт, нужно заметить. Об этом опыте кто-нибудь ещё знает, кроме тебя?

·>Ещё раз. Читай внимательно.

Давай договоримся сразу: ты не говоришь мне, что делать, а я не говорю, куда тебе идти. Хорошо?

·>Наследование — это создание is-a отношения. Т.е. "хитровывернутый вектор" может наследовать вектор.

А где здесь наследование? Ни в стартовом сообщении, ни в твоём, где "не надо так делать", никакого наследования не было. Вы с Shmj не из одной команды случайно?

·>А вот id вектором не является,

А это откуда следует? Просто потому что тебе так захотелось?

·>по крайней мере в общепринятой терминологии.

А почему ты уверен, что общепринятая терминология применима в данном конкретном случае?

·>Если у него там какой-то особенный такой id, который ещё и вектор, то у него плохое именование сущностей.

О, "если"! Т.е. сначала даем "эксперные" оценки, а после этого начинаем строить предположения — если то, а если это. Ну, сразу видно — опыт

·>Так я не говорил что попало.

Хорошо, говорил, не обосновывая. Разница не велика, имхо.

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

_>Но в целом название ElementId и LogicalId с реализацие в виде вектора, например у меня вызывают некоторые вопросы.

Это запросто могут быть координаты в многомерном пространстве.
И запросто может быть так, что количество измерений в этом пространстве определяется динамически и неизвестно на этапе компиляции, поэтому и std::vector, а не std::array.

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

S>Это запросто могут быть координаты в многомерном пространстве.
Это уже не id а набор признаков

S>И запросто может быть так, что количество измерений в этом пространстве определяется динамически и неизвестно на этапе компиляции, поэтому и std::vector, а не std::array.

Дело не в этом. Id предполагает хотя бы сравнение этих самых id

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

r>

r> typedef std::vector<int> Value;
r>

r> Если "Value" может быть вектором, то почему "Id" не может быть вектором?
"private:" — важная деталь.

avalon/3.0.0

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

r>> Если "Value" может быть вектором, то почему "Id" не может быть вектором?
·>"private:" — важная деталь.

А как ты понял, что определения автора, указанные в стартовом сообщении, не находятся в секции private?

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

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

_>>Но в целом название ElementId и LogicalId с реализацие в виде вектора, например у меня вызывают некоторые вопросы.

S>Это запросто могут быть координаты в многомерном пространстве.
S>И запросто может быть так, что количество измерений в этом пространстве определяется динамически и неизвестно на этапе компиляции, поэтому и std::vector, а не std::array.

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

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

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

DP>> Привет. Есть два типа определенные одинаково:
DP>>

DP>> typedef std::vector<int> ElementId;
DP>> typedef std::vector<int> LogicalId;
DP>>

·>Не надо так делать. Лучше так:
·>

·>class ElementId
·>{
·>private: 
·>   std::vector<int> value;
·>public:
·>   // методы, имеющие смысл для id, а не вся простыня вектора
·>}
·>

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

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

S>В проекте, которому сейчас помогаю, как раз объекты однозначно идентифицируются координатами в N-мерном пространстве. И это именно что полный аналог Id, а не набор признаков.
Но у вас же, скорее всего, нет ситуации, когда в некотором N-мерном пространстве вместе существуют объекты с N-x и N+y размерностям?

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

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

ID это число однозначно идентифицирующее что-либо.
А тут это путь к объекту в некоторой иерархии.

std::dict<ID,Path> absolute_paths;
std::dict<ID,Path> logical_paths;
std::dict<ID,Path> some_other_paths;
std::dict<ID,Metadata> some_metadata;

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

_>ID это число однозначно идентифицирующее что-либо.

Почему только число? А строка может быть?

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

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

_>>ID это число однозначно идентифицирующее что-либо.

R>Почему только число? А строка может быть?
Потому что из простых соображений на практике достаточно int32 или int64 для распределённых систем guid(int128)

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

_>Потому что из простых соображений на практике достаточно int32 или int64 для распределённых систем guid(int128)

Ну, как шутка проканает

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

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

S>>В проекте, которому сейчас помогаю, как раз объекты однозначно идентифицируются координатами в N-мерном пространстве. И это именно что полный аналог Id, а не набор признаков.
C>Но у вас же, скорее всего, нет ситуации, когда в некотором N-мерном пространстве вместе существуют объекты с N-x и N+y размерностям?

А при чем здесь это? Посыл же был в том, что вектор целых вряд ли может служить в качестве ID. Я привел пример ситуации, когда может.

Касательно предметной области из которой был взят пример, то да, в рамках одного и того же N-мерного пространства не может быть объектов, координаты которых содержат (N-x) или (N+y) значений. Но в самом приложении одновременно существует несколько пространств разных размерностей.

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

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

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

_>ID это число однозначно идентифицирующее что-либо.
_>А тут это путь к объекту в некоторой иерархии.

_>std::dict<ID,Path> absolute_paths;
_>std::dict<ID,Path> logical_paths;
_>std::dict<ID,Path> some_other_paths;
_>std::dict<ID,Metadata> some_metadata;

Проблема в названии? У меня это вектор. Слава богу язык этого не запрещает. Про std::dict наверно раньше не слышал.

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

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

r>> ·>Не надо так делать. Лучше так:
r>> Обоснование будет какое-нибудь?
·>Код проще читать и поддерживать.

r>> ·> // методы, имеющие смысл для id, а не вся простыня вектора
r>> А почему ты уверен, что не вся простыня вектора имеет смысл для ID?
·>Потому что ID это (is-a) не вектор.

r>> Если человек выбрал вектор для задания собственных типов, то, возможно, ему и нужна вся "простыня"?
·>Интуитивно уверен, что невозможно в данном случае. Буду рад услышать обоснование нужности, желательно от автора.

Нужны все основные методы вектора. И переопределять их в новом классе смысла нет.

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

DP>Нужны все основные методы вектора. И переопределять их в новом классе смысла нет.

тогда так

struct ElementId: std::vector<int> {};

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

DP>Проблема в названии? У меня это вектор. Слава богу язык этого не запрещает. Про std::dict наверно раньше не слышал.
Не заморачивайся это опечатка должно было быть std::map. Я просто обычно его переименовываю в dict

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

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

К>

К>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>>Всё может быть. Чего ты до сих пор не задал эти вопросы автору?
_>Не видел в этом смысла.

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

Здравствуйте, 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

От:	so5team	https://stiffstream.com
Дата:	22.12.24 12:17
Оценка:	+2

	От:	kov_serg
	Дата:	20.12.24 17:40
	Оценка:	3 (1)

	От:	rg45
	Дата:	21.12.24 12:57
	Оценка:	1 (1)

	От:	Кодт
	Дата:	23.12.24 10:30
	Оценка:	1 (1)

	От:	wander
	Дата:	20.12.24 17:42
	Оценка:	+1