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

    +22

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    string toString( int i ) {
    	stringstream s;
    	s << i;
    	return s.str();
    }

    Наткнулся на эту функцию в одном из своих старых проектом.

    Запостил: Fai, 11 Сентября 2012

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

    • Ну так классика же ;)
      boost::lexical_cast вроде бы так и реализован.

      Но вот скорее всего оно не нужно, т.к. в большинстве случаев из подобных кусочков пособирают сложную строку, и лучше там и вставить стрингстрим (будет пошустрее, не намного длиннее, и можно будет управлять форматированием):
      // было
      std::string s = "a = " + toString(a) + "; b = " + toString(b);
      // стало
      std::stringstream buf;
      buf << "a = " << a << ";b = " << b;
      std::string s = buf.str();
      Ответить
      • лексикал каст для int давно работает быстрее, чем через поток
        http://www.boost.org/doc/libs/1_51_0/doc/html/boost_lexical_cast/performance.html
        Ответить
    • поковырялся я тут слегка с различными способами int -> string
      думал, распиаренный спирит всех уделает
      http://liveworkspace.org/code/bf5f36d2c7dc43e7a0be550aa5796179
      надо бы как-нибудь буст 1.51 уже поставить на свой комп и поиграться с ключами оптимизаций
      Ответить
      • boost::spirit мегабыстрый? Пусть boost::lexical_cast кинет в него камень.
        Ответить
        • я много раз слышал, что спирит круче брюса ли в этом вопросе
          http://tinodidriksen.com/2010/02/07/cpp-convert-int-to-string-speed/
          Ответить
          • Так вот, дедушка, твои данные устарели. Они boost::lexical_cast очень сильно подтянули для простых типов. Теперь для таких типов boost::lexical_cast не использует стрим. Технологии не стоят на месте и библиотека буст тоже развивается.

            И да, boost::spirit самый тормозной (как до времени компиляции, так и выполнения) генератор парсеров, из всех что я видел. А знаешь почему? Потому что его написали через одно место. Вместо того, чтобы генерировать код, условно говоря, машины состояний, чтобы он работал очень быстро, они написали его на основе комбинаторов. Конечно же получилось такое же тормозное говно, как и Parsec из Хаскеля. А все почему? Потому что кресты не могут в кодогенерацию в отличии от какого-нибудь D или Nemerle (где парсеры быстрые) или специальных кодогенерящих утилит генераторов парсеров ОЛОЛОЛ КРЕСТОПРОБЛЕМЫ.
            Ответить
            • был опыт со спиритом (версии около 2.1) пару лет назад - для жены по курсу теории компиляторов паскалеподобный синтаксис надо было транслировать - вместо подразумеваемых по умолчанию lex/yacc и иных им подобных

              на скорость выполнения жаловаться не приходилось - все работало мгновенно, но бенчмарков я не делал
              вносить правки прямо в с++ код и видеть результат по F5 - это замечательно
              описывать грамматику практически в терминах задания - великолепно

              ну а скорость компиляции - спирит тут вне конкуренции, бесспорно, я не знаю ничего подобного - пришлось заодно решать задачу как снизить пиковые потребления памяти компилятором, потому что если на 8 гигах на десктопе оно ворочалось, то на 2 гигах на ноуте был сразу пиздец - студийный компилятор просто падал

              ну а для реальной жизни - спирит не пригодился ни разу, вообще
              Ответить
              • >я не знаю ничего подобного
                D и Nemerle. Генератор парсеров на уровне библиотеки языка в обоих. Второй вон даже подчеркивает неправильные места со внятными всплывающими сообщениями о причинах ошибки даже ещё до компиляции и нет не читабельных ошибок в стиле кококо длинный список инстансов шаблона на страницу из нутрей буста кококо, разбирайся как хочешь).
                Ответить
                • не знаю ничего подобного, что бы требовало гигабайты оперативы и десятки минут при компиляции несчастных 1к строк своего кода
                  вот что я хотел сказать
                  потом конечно пришлось вовсю пользоваться трюками, позволившими обойтись минутой и гигом оперативы в пике, но осадочек остался
                  Ответить
    • КРЕСТОПРОБЛЕМЫ
      Ответить
      • А что вы так на меня смотрите? Я не ошибся. Это именно они. Во всех нормальных языках есть готовые средства для такого простого случая. Нет же, каждый уважающий себя крестушок просто обязан написать свой велосипедный туСтринг. Комитет стандартизации С++ наверное думает, что ему больше и заняться нечем... Хоть в С++11 наконец исправились.
        Ответить
        • Что там в одиннадцатом?
          Ответить
          • http://en.cppreference.com/w/cpp/string/basic_string/to_string
            Ответить
            • А что с форматами?
              Ответить
              • 21.5/7
                Returns: Each function returns a string object holding the character representation of the value of its argument that would be generated by calling sprintf(buf, fmt, val) with a format specifier of "%d", "%u", "%ld", "%lu", "%lld", "%llu", "%f", "%f", or "%Lf", respectively, where buf designates an internal character buffer of sufficient size.

                уверен, вендоры не парились и фразу would be поняли как should be
                Ответить
                • Ну да, как раз работает чуть-чуть медленнее printf'а.

                  Но absolut наверное имел в виду "как указать другой формат, если не устраивает стандартный".
                  Ответить
                  • я и привел цитату, намекающую, что этим инструментом - никак
                    sprintf разве умеет в локали?
                    Ответить
                    • К сожалению. Лучше бы не умел.
                      http://ideone.com/AVaSW
                      Ответить
                      • что то я затупил
                        как сишную ru_RU перевести в крестоблядскую std::locale?
                        > what(): locale::facet::_S_create_c_locale name not valid
                        Ответить
                        • Вроде как полное название локали нужно, в духе ru_RU.utf-8.

                          P.S. У меня в бубунте работает, на Ideone краш. Видимо нет у них русской локали.

                          Вот так (с пиндосским en_US):
                          http://ideone.com/pS8wQ
                          Ответить
                          • да я именно что кучу вариантов перепробовал
                            походу сишный компилятор и крестоблядский на разных физических машинах у них

                            ну будем честны, lexical_cast тоже по умолчанию использует глобальную локаль
                            http://liveworkspace.org/code/03f4d4b6e2921ecbced6c0e445d1ee25
                            (это если волшебный макрос не дефайнить)
                            Ответить
        • ведущие собаководчики рекомендуют вендорам пилить и пилить еще поддержку с++11
          тот же тест с std::to_string
          http://liveworkspace.org/code/87bb59f32327b64ef9c6758c9b00b1e6
          Ответить
      • Тарас, перелогинься
        Ответить
    • На все знают каком сайте теперь почти работает каст пользователей. };
      Ответить
      • Ολολω, я вернулся из отпуска, тоже чё-нить законтрибьючу на досуге.
        Удобно ведь писать экстеншены? :)
        Ответить
        • Не лги. У тебя просто бан закончился.
          Ответить
        • Как раз спросить хотел: как бы туда прикрутить отправку уведомлений? Ничего, кроме костылей, не придумал.
          Ответить

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