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

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

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

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

void func(ElementId& id)
{
}

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

LogicalId logical_id;
func(logical_id);

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Ну так, тебе ни что не мешает задать эти вопросы автору.

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

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

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

Здравствуйте, 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, Вы писали:

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

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

typedef int ElementId;
typedef int LogicalId;

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

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

Здравствуйте, 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
	Дата:	20.12.24 17:35
	Оценка:

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

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

	От:	rg45
	Дата:	21.12.24 11:45
	Оценка:

	От:	·
	Дата:	21.12.24 12:38
	Оценка:	+1

От:	so5team	https://stiffstream.com
Дата:	22.12.24 05:36
Оценка: