Задать вопрос
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames, а ведь ты мог бы просто согласиться с тем, что твое изложение идет с т.з. некоторой этики разработки. Ведь именно это на самом деле и происходило. Ты оперировал на уровне некоторой смысловой надстройки над стандартом, созданной с учетом изложения стандарта. И ведь я трижды дал понять что не против этого. Для меня важно только провести границу.

    Чрезмерная опека, чем и являются подобные смещения смысловых надстроек в область стандартов, всегда приводит людей к бессознательному соблюдению определенных ритуалов. Своеобразный карго-культ. В результате, конкретно в этой ситуации, слабо квалифицированный человек может прочитать твои слова и подумать что он вообще и всегда будет защищен со стороны std::is_trivial. И это будет ошибкой.
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames,
    Именно поэтому я даже предположить не мог, что объект с указателем формально может считаться тривиальным.

    Это изложено в стандарте или это продиктовано какой-либо формой этики? Если это изложено в стандарте, то нужны цитаты с точно такой же передачей смысла.

    Если объект владеет адресуемым объектом, то, в корректно реализованном объекте, согласно стандарту, адресуемый объект находится по значению, т.е. расположен в памяти своего хозяина и имеет характеристику жизни своего хозяина. Только так стандарт определяет владение.
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames, указатель является скаляром, т.е. тривиален. Наличие поля с типом указателя в составном типе не приводит к ошибке трансляции если для составного типа не определены необходимые конструкторы. Стандарт не форсирует пользователя отказываться от тривиальности определяемого типа на основании только лишь того, что в составе типа есть указатели.

    Повторюсь что я легко могу понять твое утверждение на уровне концепций разработки, уже выше формальных правил стандарта. Однако изначально я говорил только в рамках формальных правил стандарта и просил тебя дать информацию только в рамках стандарта.
    В качестве примера. Формальные правила стандарта не запрещают тебе делать битовый сдвиг вправо для целого числа, но если число будет отрицательным, стандарт формально говорит что дальнейшее поведение программы не определено. Это уже на более высоком уровне мы строим логические правила и договариваемся не сдвигать отрицательные целые, т.к. будет UB.
    Разделять важно, т.к. в иной ситуации опираясь на логические правила ты можешь ошибиться в изложении формального кода и транслятор эту ошибку не обозначит.
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames,
    Если он владеет объектом, то, по определению (из данной вами ссылки), не может быть тривиальным, потому что у него будет нетривиальный конструктор копирования и деструктор (не рассматриваем вариант с утечкой памяти).

    Это утверждение требует точной ссылки на цитату в стандарте.
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames,
    Сам по себе указатель - тривиальный тип

    Да, по приведенным мной ссылкам это написано.
    но класс, содержащий указатель (и владещющий адресуемым объектом) не является тривиальным типом.

    Но вот этого там не написано.

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

    Сейчас, согласно стандарту, я знаю что тривиальность составного типа выводится из тривиальности его конструкторов. Тривиальность конструкторов подтверждается через тривиальность типов полей рассматриваемого составного типа.
    Указатель является тривиальным т.к. является скаляром, значит его наличие в составном типе разрешает типу оставаться тривиальным.
    Это не дает лично мне опираться на формальную тривиальность типа при написании некоторого обобщенного кода. Поэтому если у тебя есть точная информация из стандарта или документации, которую я мог упустить, то я буду рад если ты ей поделишься.
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames, а покажи документ, где явно говорится о том, что тривиальный тип не может содержать указатели.
  • Будет ли это являться сериализацией?

    @MarkusD Куратор тега C++
    maaGames, да, но нет. POD или тривиальные типы могут спокойно содержать указатели.
  • Ошибка undefined reference to vyb(). Как исправить вызов кейса?

    @MarkusD Куратор тега C++
    didol, если ответ помог решить твой вопрос, тебе стоит отметить такой ответ решением.
  • Идентификатор не определен. Как решить эту проблему?

    @MarkusD Куратор тега C++
    Никита , а где у тебя в вопросе заявлен текст ошибки и точное место этой ошибки в твоем коде?
  • Почему выкидывает ошибку "нарушение прав доступа" и деление на ноль, но ноля нет?

    @MarkusD Куратор тега C++
    Evgeniy V. , а ты не хочешь указать точные места, где у тебя останавливается отладка с приведенными тобой исключениями?
    В ином случае помогать тебе мало кто захочет.
  • Как следить за знаком переменной при переполнении в C++?

    @MarkusD Куратор тега C++
    dmasloff , если в результате операции со знаковым типом происходит переполнение разрядов, дальнейшее поведение программы не определено.
    У тебя код полностью не верен. Как вариант правильного кода, ты можешь использовать операцию над беззнаковыми целыми, переполнение которых определено и ведет к отбрасыванию данных вне диапазона бит используемого целого типа.
  • Как вычислить Z для линии?

    @MarkusD Куратор тега C++
    Евгений Якушов, не забывай ставить упоминания пользователей. Я чисто случайно сейчас увидел твой комментарий.
    Показывай весь код. Пока выглядит так, что ты неправильно реализовал суть алгоритма.
  • Как лучше всего преобразовать картинку в unsigned char?

    @MarkusD Куратор тега C++
    larikojaan , твой вопрос решается примерно так.

    std::vector <std::vector <myType::myRGB>>
    Тебе это не нужно. Матрица у тебя регулярная. Задать ее можно на линейном участке памяти, а к элементам обращаться через функцию преобразования координат в индекс. Просто заведи для этого отдельный тип, в котором будут отслеживаться все контракты.
  • Вопрос о использовании mutex и lock_guard?

    @MarkusD Куратор тега C++
    Chemodan228 , на заметку просто.
    std::lock_guard является реализацией идиомы Scope Guard - прикладного шаблона, суть которого состоит в гарантии освобождения ресурса при выходе из области видимости функции.
    Собственно, ресурсом тут является критическая секция.

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

    @MarkusD Куратор тега C++
    sanek2005, если это движок Сталкера, то зависимость, которую тебе надо подключить в проект, лежит здесь. Это уже собранный код, который нужно просто поставить в зависимости твоего проекта.
  • Проблема со сборкой одного проекта?

    @MarkusD Куратор тега C++
    sanek2005, значит все должно быть написано в документации AWS xray.
  • Как вычислить Z для линии?

    @MarkusD Куратор тега C++
    Евгений Якушов , аналогично другим осям пробовал делать?
    У Брезенхама есть критерий приращения по оси. И этот критерий одинаков для всех осей, как и само приращение.
  • Проблема со сборкой одного проекта?

    @MarkusD Куратор тега C++
    sanek2005 , а откуда у тебя взялся код, о котором даже интернет не знает?
  • Уточнение типа дочернего класса C++?

    @MarkusD Куратор тега C++
    Дарья Сафонова, отмеченный решением ответ таковым не является, даже ответом на деле не является.
    В решении твоего вопроса тебе достаточно сделать всего один крохотный дополнительный тип - невладеющий контейнер линейной памяти. Выглядеть он может вот так (привожу псевдокод):
    template< typename TElement >
    class Span final
    {
    public:
        Span() = default;
        Span( const Span& ) = default;
        Span( Span&& ) = default;
        
        Span( TElement* memory, const size_t length )
            : m_memory{ memory }
            , m_length{ length }
        {}
    
    public:
        inline const size_t size() const   { return m_length; };
        inline TElement* begin() const     { return m_memory; };
        inline TElement* end() const       { return m_memory + m_length; };
        
        inline TElement* operator [] ( const size_t index ) const
        {
            return m_memory[ index ];
        }
    
    private:
        TElement*  m_memory    = nullptr;
        size_t     m_length    = 0;
    };


    Все, больше тебе незачем узнавать размерность массива дочернего типа в базовом. Достаточно только в базовом типе объявить чисто-виртуальный метод virtual Span<int> GetMetrics() const = 0; и правильно реализовать его в дочерних типах.

    Шаблон типа является очень специфической вещью. class A1 : public A<1> означает что A1 наследуется от инстанцирования шаблона A с аргументом 1.
    A<1>, A<2>, A<42> - это все полностью разные типы, хоть они и инстанцированы из одного шаблона. Твоя задача шаблонами решается очень криво и приводит к тому, что единой иерархии типов у тебя не будет.
  • Есть ли у кого нибудь рабочий алгоритм Плавной Сортировки на ЯП?

    Proger5913, так если ты сам впервые о таком алгоритме слышишь, то зачем ты его ищешь?