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

·>Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?

Ну, с тем же успехом можно доколупаться и до простого целочисленного ID: "А вы точно собираетесь использовать, инкремент, унарный минус, исключающее или и др?".

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

R>·>Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?
R>Ну, с тем же успехом можно доколупаться и до простого целочисленного ID: "А вы точно собираетесь использовать, инкремент, унарный минус, исключающее или и др?".
Можно. Внезапно для этого и придумали пользовательские типы, инкапсуляцию и т.п.
Сабж же, как раз и спрашивают как типы сделать различными.

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

·>Можно. Внезапно для этого и придумали пользовательские типы, инкапсуляцию и т.п.

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

Да почему, собственно, только простые — любые! Хочешь использовать какой-то определенный пользователем класс, но не используешь все операции? Будь добр, напиши для него класс-обертку! Ты только так всегда делаешь?

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

R>·>Можно. Внезапно для этого и придумали пользовательские типы, инкапсуляцию и т.п.
R>Внезапно, таким путём мы очень быстро придем к тому, что простые типы данных вообще нельзя использовать в чистом виде, а только через классы-обёртки.
А вы не приходите.

R>Да почему, собственно, только простые — любые! Хочешь использовать какой-то определенный пользователем класс, но не используешь все операции? Будь добр, напиши для него класс-обертку! Ты только так всегда делаешь?
Нет.

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

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

DP>> Нет, заводить на это отдельный класс и наследовать все методы вектора нет смысла, ибо они будут просто вызываться с теми же сигнатурами.
·>Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?

Да, все. Для индентификации элемента и перемещения по иерархии больше ничего не надо. Сравнения LogicalId и ElementId не существует, тут долго объяснять, не буду.

·>В любом случае, это недостаточное условие для применения наследования. Наследование подразумевает, что оно будет прозрачно приводиться к базовому типу и всё что работает с вектором должно работать так же как и с твоим классом.
·>https://en.wikipedia.org/wiki/Composition_over_inheritance

Ну так оно и сейчас прозрачно приводится и работает, без перегрузки методов, нет?

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

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

R>>·>Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?
R>>Ну, с тем же успехом можно доколупаться и до простого целочисленного ID: "А вы точно собираетесь использовать, инкремент, унарный минус, исключающее или и др?".
·>Можно. Внезапно для этого и придумали пользовательские типы, инкапсуляцию и т.п.
·>Сабж же, как раз и спрашивают как типы сделать различными.

Я как раз и использую C++ для скорости и меньшего объема ресурсов, здесь же предлагается перейти подобию джаваскрипта или ему подобного, причем там, где это не нужно. Типы уже сделали различными во втором посте.

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

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

не совсем. Для целочисленных зачастую лучше enum class.

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

DP> ·>Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?
DP> Да, все. Для индентификации элемента и перемещения по иерархии больше ничего не надо. Сравнения LogicalId и ElementId не существует, тут долго объяснять, не буду.
Если использовать наследование, например как "struct Id : std::vector<int> {}", то сравниваться будут, а не должны.

DP> ·>https://en.wikipedia.org/wiki/Composition_over_inheritance
DP> Ну так оно и сейчас прозрачно приводится и работает, без перегрузки методов, нет?
Так не должно же.

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

DP>·>Сабж же, как раз и спрашивают как типы сделать различными.
DP>Я как раз и использую C++ для скорости и меньшего объема ресурсов, здесь же предлагается перейти подобию джаваскрипта или ему подобного, причем там, где это не нужно. Типы уже сделали различными во втором посте.
Не понял. Какие варианты из тут предложенных отличаются по скорости или ресурсам?! Ты, видимо, полагаешь, что C++ подобно джаваскрипту каждую строчку выполняет?

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

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

DP>>·>Сабж же, как раз и спрашивают как типы сделать различными.
DP>>Я как раз и использую C++ для скорости и меньшего объема ресурсов, здесь же предлагается перейти подобию джаваскрипта или ему подобного, причем там, где это не нужно. Типы уже сделали различными во втором посте.
·> Не понял. Какие варианты из тут предложенных отличаются по скорости или ресурсам?! Ты, видимо, полагаешь, что C++ подобно джаваскрипту каждую строчку выполняет?

"Не множте сущности без необходимости". Не надо обертывать-переобертывать там, где этого не надо.

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

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

DP>> ·>Точно все? и erase, и emplace, etc? А сравнение LogicalId и ElementId?
DP>> Да, все. Для индентификации элемента и перемещения по иерархии больше ничего не надо. Сравнения LogicalId и ElementId не существует, тут долго объяснять, не буду.
·>Если использовать наследование, например как "struct Id : std::vector<int> {}", то сравниваться будут, а не должны.

DP>> ·>https://en.wikipedia.org/wiki/Composition_over_inheritance
DP>> Ну так оно и сейчас прозрачно приводится и работает, без перегрузки методов, нет?
·>Так не должно же.
Честно говоря лень читать эту простыню на википедии. Не силен я в академических знаниях. Но зная проект думаю что проблем в этой части не возникнет.

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

·>Если использовать наследование, например как "struct Id : std::vector<int> {}", то сравниваться будут, а не должны.

Справедливое замечание. Но, опять же, масштаб трагедии здесь ровно такой же, как и при использовании целочисленных айдишников. А их использовали, используют и будут использовать.

Мне и самому вариант решения с наследованием не очень нравится. Я вообще не люблю наследование, стараюсь его избегать. Но даже в этом варианте решения возможно достичь приемлемой типовой безопасности, накидав в тело класса несколько дополнительных определений. А чтоб не делать это для каждого типа в отдельности, можно использовать шаблон:

http://coliru.stacked-crooked.com/a/0e65b861f54e6293

#include <iostream>
#include <vector>

template <typename Category>
struct MultiDimensionalId : std::vector<int> 
{
    using vector::vector; // Открываем все конструкоры vector для использования в этом классе
    bool operator == (const MultiDimensionalId&) const = default;
    auto operator <=> (const MultiDimensionalId&) const = default;
    bool operator == (const auto&) const = delete;
    auto operator <=> (const auto&) const = delete;
};

using ElementId = MultiDimensionalId<class ElementCategory>;
using LogicalId = MultiDimensionalId<class LogicalCategory>;

int main()
{
    std::cout << (ElementId{1, 2, 3} == ElementId{1, 2, 3}) << std::endl;
    std::cout << (ElementId{1, 20, 3} >= ElementId{1, 2, 3}) << std::endl;
    std::cout << (ElementId{1, 2, 3} < ElementId{1, 20, 3}) << std::endl;
    // std::cout << (ElementId{1, 2, 3} == LogicalId{1, 2, 3}) << std::endl; // error: use of deleted function
    //std::cout << (ElementId{1, 2, 3} >= LogicalId{1, 2, 3}) << std::endl; // error: use of deleted function
}

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

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

·>Сабж же, как раз и спрашивают как типы сделать различными.

Так вот именно. И для того, чтобы сделать типы различными, совсем не обязательно урезать список доступных операций. И получившиеся различные типы вполне могут быть подтипами одного типа без нарушения принципа подстановки Лисков. Это полностью отдельная задача.

Я не говорю, что твое решение плохое. Просто аргументация у тебя ни в дугу. А поначалу и вовсе никакой аргументации не было. Вроде царский указ зачитал.