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

    +55

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    QByteArray ba;
    char x;
    
    x = 0x05;
    ba.append (&x, sizeof (x));

    Qt. Продолжаем мучить QByteArray :)

    Запостил: ealx, 26 Ноября 2014

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

    • и? где лопата?
      Ответить
      • Видимо, в выборе не той перегрузки append
        QByteArray & QByteArray::append ( char ch )
        This is an overloaded function.
        Appends the character ch to this byte array.
        И ещё лопаточка-совочек в самой Qt.
        QByteArray & QByteArray::append ( const char * str )
        QByteArray & QByteArray::append ( const char * str, int len )
        Там, где обычно принято брать данные по void*, в Qt их берут по char*, из-за чего а) нужно кастовать структуры к char* и б) бывает, путаешься и забываешь положить размер структуры после указателя на неё и вызывается перегрузка для нуль-завершающей-сука-блядь строки.
        Ответить
        • А вдруг там древний-предревний компилятор, не умеющий в void *?
          Ответить
          • Были и такие?
            Ответить
            • В самых первых компиляторах C не было типа void, поэтому функции, не возвращающие никакого значения, оставлялись вообще без объявления типа возвращаемого значения (неявный int), а для указателей на произвольные блоки памяти использовался тип char *.
              Ответить
              • Кстати, в The Algorithm Design Manual Скиены весь код написан на такой древней сишке, даже в свежих изданиях.
                Ответить
                • Свят-свят-свят!
                  Ответить
                  • А ещё там нет ни одного вызова malloc, весь код в стиле древнего юникса с массивами длины MAXV.
                    Но сама книжка годная, да и сишка там скорее как превдокод.
                    Ответить
              • А зачем потом ввели воид? Чтоб явно отключить арифметику указателей для неизвестного типа?
                Ответить
        • > путаешься и забываешь положить размер структуры после указателя

          вы так жалуетесь, как если бы никогда STL не пользовались. те же грабли, вид с боку.

          ваши жалобы говорят что вам на Java пересаживатся надо: наличие утилит и синтакс шугар вас "путает".
          Ответить
          • То я не только за себя говорил, но и за коллег, у которых такая ошибка встречалась.
            Лучше бы у QByteArray был метод append, принимающий const void * и размер. Так и писать проще - не нужен каст к const char *, и компилятор при попытке аппенда структуры не найдет подходящей перегрузки и ругнется.

            > STL <...> те же грабли, вид с боку
            Вот про STL даже не подумал, вспомнив в первую очередь write/fwrite и boost::asio::buffer, у которых нет проблем с логичностью типов аргументов.
            Ответить
            • > попытке аппенда структуры
              Но зачем аппендить структуры в байтовый буфер? Какой вообще в этом толк? Там же паддинг и мусор, для чего он?
              Кмк, логично ограничить вход байтами (char) и заставлять людей делать явную сериализацию.
              Ответить
              • > Какой вообще в этом толк?
                В моей скромной практике осталось только одно место, в котором это требуется: работа с двоичными протоколами. К некоторым протоколам соседние отделы прикладывают заголовки с плотно упакованными структурами и считать структуру одним разом всё-таки удобнее, чем читать каждое поле по отдельности.

                > Кмк, логично ограничить вход байтами (char) и заставлять людей делать явную сериализацию.
                Ага, поди, заставь закоренелого сишника с 20+ годами практики читать или писать XML, будет потом как в gk#17139 на одних sprintf :)
                Ответить
                • > работа с двоичными протоколами
                  > считать структуру одним разом всё-таки удобнее, чем читать каждое поле по отдельности

                  Но ведь byte order...
                  Ответить
                  • > Но ведь byte order...
                    Эх. Даже писать об этом не хочется, ибо ожидаю, что полетят в меня какашки.
                    В нашей конторе порядок байт всегда был фиксирован на little endian. В скором времени это ограничение может быть внезапно снято с расширением на другие архитектуры и тогда придется покупать на работу кофе-машину и ведёрко вазелина...
                    Ответить
                    • > порядок байт всегда был фиксирован на little endian
                      > ожидаю, что полетят в меня какашки

                      Удивительно, но такой подход является скорее правилом, нежели исключением. Сам работал в компании, где за 10 лет работы продукта никто по этому поводу даже не думал, хотя продукт был полностью построен на бинарных сетевых протоколах.

                      > придется покупать на работу кофе-машину
                      У вас нет на работе кофе-машины? Срочно купите.
                      Ответить
                      • Казалось бы: во всех букварях по сетевому программированию сразу же рассказывают про host order / network order. Каким же образом люди умудряются упустить это для своих протоколов? Или в наше время кругом один интел, и можно не париться?
                        Ответить
                        • > Каким же образом люди умудряются упустить это
                          >> Удивительно

                          Когда мне впервые пришлось столкнуться с сериализацией в бинарный файл (а ведь это ещё даже не сеть), я сразу узнал про порядки байт и навелосипедил свой буфер для сериализации.

                          Видимо, большинство людей просто не изучает проблему перед тем, как начать реализацию.

                          Пообещай менеджеру всё сделать за неделю @ напиши первое, что пришло в голову
                          Ответить
                          • > навелосипедил свой буфер
                            Кстати, вот первые версии
                            http://govnokod.ru/12465
                            Ответить
                          • Это еще что... а вот в адобовских форматах часто можно встретить в одном файле и больших и маленьких индейцев. При чем иногда бывает так, что кусок передается в системно-зависимом порядке, а для другого куска порядок определен однозначно.
                            Ответить
                            • > в адобовских форматах
                              Ну они же не думали, что их когда-нибудь придется открывать...

                              P.S. А открыли ли?
                              Ответить
                              • Иногда открыты, но большей частью - частично. ПДФ - даже вроде стандарт есть, но Адоб туда пихает кучу всего нестандартного. SWF - спецификация опубликована, но компилятор умеет генерировать пару недокументированых тегов, линкер вообще по сути не документирован (т.е. встраиваемые ресурсы, особенно кодеки - проприетарная тайна). АМФ - ворде открыт и задокументирован, но есть недокументированые возможности. ФЛВ - тоже примерно так же.
                                Самые плохие, правда, это ПСД и ФЛА, вот в ФЛА там как раз встречаются разные индейцы, говорят, что в ПСД - тоже.

                                Что хуже всего, это даже проистекает не от нежелания, а изза бюрократии. Когда Адоб решил сплавить Апачу Флекс, то поняли, что в потрохах куча всего, что открыть тяжело (или стремно). Шейдеры так и остались проприетарными, даже АПИ стандартной библиотеки (сами заголовки) не отркыли (хотя они естесственно находятся в свободном доступе). Кодек для шрифтов - тоже не открыли и т.д.
                                Ответить
            • При живом QDataStream пихать структуры в QByteArray...
              Ответить
        • Да. Писатель за час до высера узнал о существовании удобненького байтаррэя и заюзал первую попавшуюся перегрузку аппенда. Далее он ее юзает почти всюду.
          Ответить

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