Кресты / Говнокод #27691 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
// этот код дает Segment Fault

struct TypeNames
{
    std::string typeName;
};

class LLVMRTTIHelperVCLinux
{
    SmallVector<TypeNames> types;
}

// a этот нет

class LLVMRTTIHelperVCLinux
{
    SmallVector<std::string> types;
}

ну и гавно этот ваш Clang. MSVC работает, GCС работает а Clang нет

Запостил: ASD_77 ASD_77, (Updated )

Комментарии (29) RSS

  • Clang хуйня, я его ненавижу. Он такой хуёвый, потому что на LLVM или потому что яблблядочный?
    Ответить
    • хер знает почему.. наверно думает что очень умный.
      Ответить
  • у меня подозрение что деструктор в "struct" убивает обьект string ... но на каком основании... нее... я лучше с GC буду чем с этим гов-ом
    Ответить
    • > у меня подозрение что деструктор в "struct" убивает обьект string

      А что, не должен? 😉
      Ответить
      • нет не должен . т.е. move коструктор никто не отменял 🙂
        Ответить
        • А с чего ты взял, что move отменяет вызов деструктора? Никаких магических флажочков там нету. Просто деструктору после мува обычно делать нечего кроме какой-нибудь проверки на nullptr.
          Ответить
          • просто при муве обьект должен отдать свои внутрение буфера и деструктор уже должен убить мертвый инстанс класса .. но нет ... походу он его грохает так качественно что и мув не успевает передать буфера
            Ответить
            • Ну тогда в дебаггере пробегись или логов добавь... Вангую, что косяк где-то в реализации SmallVector, просто с голой стрингой оптимизация по-другому легла.
              Ответить
            • У меня в Си никаких "мувов объектов" нет, поэтому я за Си.
              Ответить
              • Концептуально они в «Си» были с момента его создания.
                И так же напарывались на проблемы с ними.
                Ответить
                • > Концептуально они в «Си» были с момента его создания.

                  В смысле? В "Си" нет концепции "объект" как в "C++", и нет естественно никаких "деструкторов" и "move-семантики".
                  Ответить
                  • Есть у тебя буфер, который ты заполнил. Вот тебе концептуально "объект", "область памяти", "неведомая ёбаная хуйня", называй, как хочешь. Вот ты передал его в другую фунцию/тред/ещё куда, но важно то, что удалять его, передавать дальше, вертеть на хую его будет эта функция, и тебе следует о нём забыть. Вот тебе концептуально "мув"/"передача владения"/"сепуление", называй, как хочешь. И тут ты забываешь выкинуть указатель на этот буфер и в конце, когда чистишь вилкой ресурсы (вот тебе концептуально "деструктор"), удаляешь его вместе с остальными своими буферами. Вот так напарываются на проблемы с "мувами" в Си.

                    От того, что на уровне языка поддержки какой-то хуйни нет, это не означает, что и базовая концепция этой хуйни неприменима. Блядь, да большинство си-подобных языков сделаны по принципу "а давайте запилим синтаксический сахарок чтобы Х делать автоматически/одной строкой"
                    Ответить
                    • > Вот тебе концептуально "мув"/"передача владения"/"сепуление", называй, как хочешь.

                      Не, ну если так рассуждать, то это "владение" и в ассемблере есть. Там же тоже можно что-то как-то выделить через какую-то "функцию" и потом куда-то там передавать и как-то освобождать
                      Ответить
    • Поддерживаю, у меня повторить не получилось, а проводить расследование, какой именно SmallVector из какой версии какой библиотеки, мне никуда не впёрлось.
      Ответить

Добавить комментарий

Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

    А не использовать ли нам bbcode?


    8