1. C++ / Говнокод #20231

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    void Canvas::drawText(const char* text, SDL_Color sdlColor, int x, int y) const noexcept
    {
        if (!font)
            throw std::runtime_error{"TTF_Font* is null"};
    
        SDL_Surface* const sdlSurface =
            ::TTF_RenderText_Solid(const_cast<TTF_Font*>(font->getTtfFont()), text, sdlColor);
        if (!sdlSurface)
            throw std::runtime_error{"SDL_Surface* is null"};
    
        SDL_Texture* const sdlTexture =
            ::SDL_CreateTextureFromSurface(const_cast<SDL_Renderer*>(renderer->getSdlRenderer()), sdlSurface);
        if (!sdlTexture)
            throw std::runtime_error{"SDL_Texture* is null"};
    
        const SDL_Rect srcrect{0, 0, sdlSurface->w, sdlSurface->h};
        const SDL_Rect dstrect{x, y, sdlSurface->w, sdlSurface->h};
    
        ::SDL_FreeSurface(sdlSurface);
    
        ::SDL_RenderCopy(const_cast<SDL_Renderer*>(renderer->getSdlRenderer()), sdlTexture,
                &srcrect, &dstrect);
        ::SDL_DestroyTexture(sdlTexture);
    }

    Запостил: jangolare, 19 Июня 2016

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

    • ассерт бы делал, чтоли...
      Какой-то "c++ без классов"
      Ответить
      • Обычный сиплюсплюс, просто сишную либу использует. Говнокод, я так понимаю, в содомии с const'ом.
        Ответить
    • > noexcept
      > throw std::runtime_error
      Я думал что noexcept значит что функция не бросает исключений, или это только checked exception, как в Яве?
      Ответить
      • > noexcept значит что функция не бросает исключений

        Да, так и есть. На самом деле, в случае исключений тут будет тупо std::terminate(), вероятнее всего, без раскрутки стека. Кто-то мало того, что не читал про фичи, которые использует, но и не тестировал то, что написал.
        Ответить
        • оффтопну, пока еще помню
          мистер kashitsyn, вы были правы, синглетон мейерса - действительно топовая реализация синглетона в крестах
          остальные - не очень
          Ответить
          • >> остальные - не очень

            остальные сингтоны или остальные на этом сайте?
            Ответить
            • > остальные сингтоны

              Прочитал как "отсталые сингтоны". Отличная характеристика.
              Ответить
          • разве что явно деинициализировать его несколько сложнее.
            Ответить
            • using x = std::decay<decltype(getInstance())>::type;
              getInstance().~x();
              Ответить
              • > std::decay
                А период полураспада где задаётся?
                Ответить
              • обычно у синглтонов конструктор с деструктором приватные
                Ответить
                • Синглтоны нинужны.
                  Ответить
                  • до тех пор пока не попытаешься сишколибу в ооп запихать
                    Ответить
                    • Приведи пример. Не могу представить, зачем нужен синглтон в обертке над сишколибой.
                      Ответить
                      • Для коллбеков. Если либа упоротая, и не принимает void* для контекста вместе с коллбеком.
                        Ответить
                        • pthread_atfork
                          Ответить
                          • Хех, а я давным-давно дал себе обет не юзать fork и треды в одной проге... Ибо сплошной гемор с этими atfork, O_CLOEXEC и прочими...
                            Ответить
                            • А если надо?
                              Ответить
                              • То форкаюсь один раз в самом-самом начале, когда тредов ещё нет и один из процессов юзаю для создания зергов. А второй ему тупо приказывает через IPC.
                                Ответить
                                • прикольно)
                                  Ответить
                                • > То форкаюсь один раз в самом-самом начале, когда тредов ещё нет

                                  Не всегда помогает :) Внезапно pthread_atfork полезен, даже если не используешь треды, как возможность повесить коллбэк на любой форк.

                                  Конкретно в нашём случае было примерно следущее: signal_set из asio создаёт self-pipe, который сидит в бустовом синглтоне. После форка потомки (молча) наследовали этот пайп и тоже использовали (собственный) signal_set, и сигналы уходили то к ним, то к паренту.
                                  Ответить
                      • pcap, например.
                        Ответить
                    • Ну вот как раз недавно заворачивал сишколибу в ООП - прекрасно завернулась, без всякого говна типа синглтонов.
                      Ответить
                      • Вообще, синглтоны нужны. Если тянуть через всю программу контекст какой-нибудь служебной либы типа логера, то это какая-то манада получится.
                        Ответить
                        • Синглтон — хороший способ обмана. Вроде явно глобальные переменные не используешь, а всё работает так, как будто в глобальных переменных.
                          Ответить
                          • Синглтоны/статики - это и есть глобальные переменные. С абсолютно всеми их проблемами и недостатками.
                            Ответить
                          • Мне вот гораздо больше нравится глобальный указатель, который вручную инициализируется при старте, освобождается при выходе и доступен на чтение во время работы.

                            По крайней мере, сам класс не уродуется бесполезным getInstance()'ом и приватными конструкторами, которые мешают тестированию и т.п. Ну и нет проблем с ленивой инициализацией, в которую непонятно как просунуть параметры.
                            Ответить
                            • З.Ы. Причём тогда именно клиент класса решает, нужен ему один инстанс на прогу, один инстанс на тред, один инстанс на сессию и т.п...

                              А у синглтона смешивается ответственность и за полезную работу и за управление инстансами. Нахуй так жить?
                              Ответить
                              • если класс не отвечает за глобальное состояние программы (всякие логгеры, как раз) и нужен везде, то нет ничего плохого обернуть эту кухню в синглтон.
                                Ответить
                                • Обернуть - ок. Главное в сам класс это говно не тащить, как это обычно делают, когда говорят о синглтоне...
                                  Ответить
                                • Т.е. я не против Logger *getInstance() как чего-то внешнего, но я категорически против Logger *Logger::getInstance().
                                  Ответить
                                  • Скорее не согласен. Если дело в возможности переиспользования кода - так синглтоны вообще не должны появляться там, где можно обойтись без них. А если класс "до мозга костей" синглтон, то лишняя подсказка "как пользоваться" в виде метода instance() и приватных деструктора/конструктора не помешает.
                                    Ответить
                                  • 95% синглтонов не отличаются от статичных классов, так что пох. А вообще проще инжектить через интерфейс.
                                    Ответить
                          • писать код с целью наебать читателя можно, но не нужно
                            Ответить
                • Гулять так гулять.
                  #define private public
                  Ответить
                  • template <class T, int id = 0>
                    T &instanceOf() {
                        static T instance;
                        return instance;
                    }

                    вот это - "гулять так гулять". А у тебя какой-то грязный хак
                    Ответить

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