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

    +165

    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
    class Exception {
      public:
        Exception() { }
        Exception(const char *fmt, ...) {
          va_list  argPtr;
          va_start(argPtr, fmt);
          Str_VSPrintf(desc, sizeof(desc), fmt, argPtr);
          va_end(argPtr);
    
          throw(*this);
        }
    
        char desc[8096];
      };

    http://www.gamedev.ru/code/forum/?id=151712#m6

    >Всё работает иа рад :)

    Запостил: CPPGovno, 29 Августа 2011

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

    • Как мало нужно человеку для счастья!
      Иным достаточно, чтобы компилятор не ругался.
      Ответить
    • throw(*this) в конструкторе?
      Ответить
    • мне одному кажется, Тарас учит ненавистный C++?
      Ответить
      • где то уже поднималась эта тема, а конкретнее про то, что Тарас учит Delphi и C++, чтобы троллить тех кто знает лишь один из этих языков.
        Ответить
        • Чёрд, слышали новость?
          Тарас выучил хаскел.
          Ответить
        • фак мой мозг!

          тарас решил стать крестоблядью? он троллит сам себя или у него раздвоение личности?
          Ответить
    • Пусть лучше использует мой String::Format.
      Ответить
      • Вы реимплементили всю стандартную библиотеку, или ещё остались незавершённые разделы?
        Ответить
        • Пока только массив, строку и дерево (но его, по-моему, нет в STL).
          Ответить
          • Вроде бы map основан на двоичных деревьях. Ваше дерево RB или AVL?
            Ответить
            • У меня обычное небинарное дерево. От одного узла ответвляется любое количество других деревьев. Я использую его для реализации меню. Кстати, map свой тоже сделал, но давно. Пока работает медленно, всё не соберусь никак доделать. Там обычный линейный поиск.
              Ответить
              • Мы ждём вашу реализацию, как замену STL.
                Ответить
                • Да, можно создать проект на github или google.code и выкладывать туда наработки gammaker. Назовём его STLI - STL Improved.
                  Ответить
                • Ждём GTL
                  Ответить
                • Прикольно будет, если это добавят в стандарт. Я стараюсь делать свою библиотеку как можно безопаснее, но при этом достаточно производительной. Здесь не будет никаких итераторов. Из контейнеров значение можно будет получать только по индексу. Как-нибудь надо будет реализовать List (уже придумал, как сделать быстрый доступ по индексу, странно, что в STL об этом не догадались). Но сначала надо доделать Map.
                  Ответить
                  • Для листа у тебя будет сохранение результатов нескольких последних поисков?
                    В многопоточной проге будет тормозить, поиски будут друг друга перебивать.
                    Ответить
                    • Я пока не работал с многопоточностью(и не планирую в ближайшее время), но разве никак нельзя для каждого потока хранить отдельную позицию?
                      Ответить
                      • Я не знаю, как ты это реализуешь.
                        Кстати, как ты по хеш-массиву и по дереву сделаешь быстрый поиск по индексу?
                        Ответить
                        • Значит придётся делать итераторы. Постараюсь сделать их безопасными и чтобы они не могли стать недействительными.
                          Ответить
                          • > чтобы они не могли стать недействительными.
                            даже после удаления контейнера
                            Ответить
                            • Надо сделать, чтобы при обращении к такому итератору, выбрасывалось исключение.
                              Ответить
                              • вы уж определитесь : не могли стать недействительными или выбрасывалось исключение.
                                Ответить
                                • В смысле, делать так, чтобы они не становились недействительными при изменении размеров контейнера. Если они по каким-то причинам стали недействительными, то при обращении к итератору выбросить исключение.
                                  Ответить
                                  • Это называется "робастный итератор". Для вектора его реализация нетривиальна.
                                    Ответить
                                    • Если под тривиальной понимать реализацию в виде указателя — то да.
                                      Ответить
                                  • >не становились недействительными при изменении размеров контейнера
                                    Размер в 0. Что делать дальше?
                                    Ответить
                                    • То есть при увеличении. А вообще, хватит придираться.
                                      Ответить
                                      • >хватит придираться
                                        Формируйте мысли четче. Как вас компилятор вообще понимает?
                                        Ответить
                                        • Компилятор C++ понимает даже такую хрень, в которой человек в жизни не разберётся.
                                          Ответить
                                          • Суть в том, что компилятор понимает всё однозначно.
                                            Ответить
                                    • >Размер в 0. Что делать дальше?
                                      Ничего не делать гораздо проще, чем что-то делать. ... (с)
                                      Ответить
                      • Для mutable связных списков реализация быстрого доступа по индексу (особенно, в многопоточной среде) чревата чудовищными косяками.
                        Ответить
                  • >уже придумал, как сделать быстрый доступ по индексу, странно, что в STL об этом не догадались
                    Сделаете, как предложил Тарас, или какой-то другой вариант?

                    Тарас то растёт...
                    Ответить
                    • Думал сделать так, но появились сомнения. Надо подумать.
                      Ответить
                    • Да нифига, я и 6 лет назад был круче некуда - под ДОС 3д-игры писал на турбопасе, куда тут круче.
                      640кб, перехват прерываний, битоёбство...
                      Кстати, а при программировании встраиваемых систем какая специфика ещё есть?
                      Ответить
                      • >при программировании встраиваемых систем какая специфика ещё есть?
                        Работа с различными платформами, а не только с х86. Необходимость совместного функционирования нескольких платформ (например связь через самые разные сетевые протоколы или схематехнически). Протоколы и платформы могут быть велосипедами из отдела аппаратчиков. Кривые оси\ядра\окружение, кривые компиляторы под эти нестандартные платформы. Особенно это касается С++, тк его реализовать под контроллер - убийство со всеми его шаблонами и соответствиями тонким моментам стандарта.
                        Ответить
                      • Работа с различными велосипедами от аппаратчиков. Умение выявить ошибку в велосипеде от аппаратчиков и доказать им это.
                        Ответить
                      • Работа с системами реального времени (см википедию). Умение писать быстрый код для тормозных контроллеров на любом языке при любом даже не оптимизирующем компиляторе. Уменее писать код, работающей одновременно на нескольких платформах и даже с разной разрядностью
                        Ответить
              • А префиксное дерево будет?
                Ответить
              • это называется направленный граф

                настоятельно советую отправить свои поделки в буст. только там их могут оценить по достоинству
                Ответить
            • binary heap msvc8/msvc10
              Ответить
    • http://ru.fishki.net/picsw/082011/29/post/komiks/komiks-036.jpg
      Ответить
      • Дык так и есть. Гамммер же и говорит, что хочет написать мегаигру, но уже как много времени занимается майбустостлстроительством.
        Ответить
        • Вообще-то, я хочу написать движок. Полностью свой, без использования каких-либо библиотек, в том числе и STL. Всё должно быть написано в одном стиле. Мои массивы меня уже несколько раз спасали от нескольких часов отладки ошибки обращения по неверному индексу. Глядишь, так и окупится их создание. Ещё мой класс строк позволяет в десятки раз быстрее сравнивать строки, чем std::string.
          Ответить
          • >Ещё мой класс строк позволяет в десятки раз быстрее сравнивать строки, чем std::string.
            Как вы этого добились? Хеш?
            Ответить
            • Точнее в десятки раз быстрее в частных случаях: только на равенство\неравенство, длины строк отличаются и сравнение String со String. Но такие случаи достаточно часты. В остальных случаях где-то в 2 раза быстрее. Хэш не использую.
              Ответить
              • А ваши строки тоже copy-on-first-write?
                Ответить
                • Строки лишний раз не копируются. Они копируются только при перераспределении буфера при конкатенации и присваивании, и то, только когда нет свободного места в буфере (буфер создаётся с запасом).
                  Ответить
                  • >Строки лишний раз не копируются.
                    Да ну. А при присвоении или обмене то зачем копировать?
                    Оптимизация при присвоении делается так:
                    str1=str2;//Теперь str1 содержит ссылку на данные из str2;
                    str1+="^_^";//Теперь str1 содержит копию из str2+"^_^";

                    Также используй оптимизацию RValue-ссылок&&. Так же уберёт лишнее копирование.
                    Ответить
                    • Счётчика ссылок пока нет. В std::string тоже нет (хотя слышал, что в старом Visual C++ было, но потом выкинули из-за проблем с многопоточностью. Надо разобраться, что это за проблемы и как их решать.
                      Ответить
                      • Счётчик ссылок не имеет отношения к &&
                        Ответить
                        • Я про str1=str2. str2 не является временным объектом, поэтому && здесь не поможет. && я и так использую в конструкторе и операторе=.
                          Ответить
                          • >поэтому && здесь не поможет
                            зато поможет в других случаях.
                            Ответить
                            • Мы обсуждали этот случай. В других случаях rvalue-ссылки я использую и они помогают ускорить присваивание временных объектов.
                              Ответить
                        • Спасибо, кеп.
                          Ответить
                  • >при перераспределении буфера
                    Память выделяй из пулов памяти (погугли) - будет во много раз быстрее.
                    Ответить
                    • О нет, они объединились...
                      Ответить
                    • А точно ли это будет быстрее? Как быть с фрагментацией памяти?
                      Ответить
                      • фрагментации памяти не будет вообще ибо из одного пула будет выделяется память только под один тип данных.
                        про другие реализации хз, но я бы делал именно так
                        Ответить
                        • Я всегда думал, что строки могут быть разной длины. Пул хорош, когда есть структура фиксированного размера.
                          Ответить
                          • Ну тогда несколько пулов, под строки на 64, на 128, итд на 2^30 символов.
                            Ответить
                            • именно!

                              единственный минус, что память будет расходоваться не оптимально. за это мы получаем быстрое выделение/освобождение памяти.

                              у нынешних юзверей итак оперативы жопой жуй
                              Ответить
                              • >у нынешних юзверей итак оперативы жопой жуй
                                обычно данный подход перетекает в крайность
                                Ответить
                • дешевый подъеб однака. copy-on-first-write сделать просто. единственная залупа с char &operator[](), но и ее можно решить с помощью разврата с прокси-объектом
                  Ответить
    • striker, прикрути уже git, а то gavedev'у негде размещать свои поделки
      Ответить
      • ждем реализацию Qt от афтора или на худой конец MFC
        Ответить
        • Кстати, я уже делаю аналог MFC на Windows API. Правда это займёт много времени.
          Ответить
          • Вы любите кататься на велосипеде?
            Ответить
            • А я кстати изобретаю свой велосипед.
              Ответить
            • Забыл рассказать о преимуществах: простая программа на MFC занимает полмегабайта, та же программа у меня займёт 10-15 КБ. Ещё не используются уродливые макросы как у MFC. Вместо этого можно использовать указатель на функцию, лямбду (в C++0x) или функтор.
              Ответить
              • На очереди OpenGL. Уж вы то с вашим опытом сможете сделать его правильно.
                Ответить
                • Я из низкоуровневых вещей делаю высокоуровневые. А OpenGL сам низкоуровневый. Хотя, может быть, можно работать с драййвером напрямую.
                  Ответить
                  • так оберни вызовы OpenGL в высокоуровневый мегадвижок с блекджеком и шлюхами
                    Ответить
                    • Движок уже делаю. Только он мультиапи, используется и OpenGL, и DX9.
                      Ответить
          • Я вам завидую. Хотел бы и я иметь столько свободного времени.
            Ответить
            • Вообще-то, у меня сейчас будет его гораздо меньше. Каникулы кончаются...
              Ответить
      • striker обязательно зайдет сюда, прочитает, и свяжется с вами, когда все будет готово!
        Ответить
    • У этого кода 2 плюса, как и у языка, на котором он написан:
      1)Чтобы кинуть это исключение - достаточно написать короче, чем это делается обычно.
      2)Есть форматированное формирование диагностического сообщения.
      Ответить

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