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

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, а не вся простыня вектора
}

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

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

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

·> // методы, имеющие смысл для 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> Если человек выбрал вектор для задания собственных типов, то, возможно, ему и нужна вся "простыня"?
Интуитивно уверен, что невозможно в данном случае. Буду рад услышать обоснование нужности, желательно от автора.

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

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

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

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

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

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

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

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

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

typedef std::vector<int> Value;

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

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

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

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

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

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

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

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

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

А где здесь

Автор: ·
Дата: 21.12 15:38

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

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

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

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

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

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

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

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

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