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

    +155

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    #if __STDC_WANT_SECURE_LIB__
    _Check_return_wat_ _CRTIMP_ALTERNATIVE errno_t __cdecl wcscat_s(_Inout_z_cap_(_SizeInWords) wchar_t * _Dst, _In_ rsize_t _SizeInWords, _In_z_ const wchar_t * _Src);
    #endif
    __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, wcscat_s, _Deref_prepost_z_ wchar_t, _Dest, _In_z_ const wchar_t *, _Source)
    __DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1(wchar_t *, __RETURN_POLICY_DST, _CRTIMP, wcscat, _Pre_cap_for_(_Source) _Prepost_z_, wchar_t, _Dest, _In_z_ const wchar_t *, _Source)
    _Check_return_ _CRTIMP _CONST_RETURN wchar_t * __cdecl wcschr(_In_z_ const wchar_t * _Str, wchar_t _Ch);
    _Check_return_ _CRTIMP int __cdecl wcscmp(_In_z_ const wchar_t * _Str1, _In_z_ const wchar_t * _Str2);
    #if __STDC_WANT_SECURE_LIB__
    _Check_return_wat_ _CRTIMP_ALTERNATIVE errno_t __cdecl wcscpy_s(_Out_z_cap_(_SizeInWords) wchar_t * _Dst, _In_ rsize_t _SizeInWords, _In_z_ const wchar_t * _Src);
    #endif

    Хедеры из Microshit Visual Studio. Там так почти везде...

    Запостил: Говногость, 02 Февраля 2011

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

    • А где говнокод?
      Ответить
      • Каша из дифайнов не говнокод?
        Да и
        #if __STDC_WANT_SECURE_LIB__ 
        #endif
        - конструкцию 10 раз можно было не повторять.
        Ответить
        • Насколько я могу судить, тут идёт группировка по функциям, а не по дефайнам.
          Ответить
          • >группировка по функциям, а не по дефайнам
            А зачем?
            Тут же Вы заявили http://govnokod.ru/5485#comment71857 , что "этот файл не предназаначен для восприятия человеком". Значит не зачем групировать по функциям, а нужно для компилятора сгруппировать, что-бы не было лишних проверок #if __STDC_WANT_SECURE_LIB__. Зачем на это тратить время во время компиляции? Что-бы было понятнее группируют по функциям? Смотря на этот код думается, что этой цели у майкрософта не было...
            Ответить
            • На вопросы "зачем" ответить не могу, но, мне кажется, способ группировки не имеет значения, поэтому судить по нему о качестве кода неправильно.

              И да, если вам кажется, что ошибка компиляции произошла из-за системного заголовка, то, с большой вероятностью, это не так. Обычно в таких случаях я читаю документацию по используемой библиотеке.
              Ответить
              • >И да, если вам кажется, что ошибка компиляции произошла из-за системного заголовка
                Нет. Не кажется и я это оговорил в том говнокоде. В системном заголовке приходится разбираться, если ошибку показывает компилятор в системном заголовке (понятно, что ошибка скорее всего при этом будет не в нем, просто компилятор показывает не в место основной ошибки). Попробуй в системном заголовке разберись, если код в нем говно.
                Ответить
                • А зачем разбираться в системном заголовке, если ошибка скорее всего при этом будет не в нем, даже если говняный компилятор показывает на говнокод в системном заголовке ?
                  Ответить
                  • А как Вы её найдете, если туда компилятор не указывает? Приходится разбираться с тем местом, куда указывает. А уж дальше дедуктивным методом находим реальное место ошибки. Этож С++...
                    Ответить
                    • Собирать по частям, комментировать пользовательский код. Помнится мне в билдере от борланда было, если после определения своего класса точку с запятой не укажешь, так он на системный хедер ругался. А смысла в нем копаться-то и нету, не зависимо от того как он написан: читабельно для человека или не совсем.
                      Ответить
                      • >Собирать по частям
                        Это помогает. Но лучше иметь больше методов нахождения реального места ошибки, а не того, куда указал компилятор.

                        >комментировать пользовательский код
                        А как это помогает в поиске ошибки, которая находится не в том месте (системный хеадер), куда указал компилятор, а в другом?
                        Ответить
                        • >А как это помогает в поиске ошибки, которая находится не в том месте (системный хеадер), куда указал компилятор, а в другом?
                          Ну Вы же сами здесь и ответили. Если ошибка не там, где указал компилятор, скорее всего она в пользовательском коде.
                          Ответить
                          • >Если ошибка не там, где указал компилятор, скорее всего она в пользовательском коде.
                            Спасибо КЭП. Вы большие проекты видили в несколько сотен хедеров и прочих файлов? В каком из них ошибка ведь искать нужно как-то. Для этого и приходится для локализации ошибки разбирать системный хедер, что-бы хоть как-то сузить область поиска.
                            Ответить
                            • >Если ошибка не там, где указал компилятор, скорее всего она в пользовательском коде.
                              У нас код проектов пишется под несколько платформ, поэтому код должен компилироваться на различных компиляторах с различным образом реализованной стандартной библиотекой. Самое интересное, что абсолютно безошибочный код, компилирующийся на нескольких платформах на ура, на других выдаёт ошибки в системных хедерах. Так, что ваше утверждение не верно. Ошибки нет, но компилятор о ней говорит, указывая на системный хедар. Это просто не совместимые реализации стандартной библиотеки.
                              Ответить
                              • >Так, что ваше утверждение не верно.
                                Обратите внимание на "если" и "скорее всего".
                                Если код не собирается - это уже ошибка.
                                Для кроссплатформенной реализации понятно что придется искать различия в компиляторах и библиотеках. Без этого никак.
                                Ответить
                                • >придется искать различия в компиляторах и библиотеках.
                                  Нет. В условиях реалий данной области программирования - мелкие различия не указаны не в каких документах, а на них именно и вылазят ошибки в системных хедерах.
                                  Придется искать реальные места появившихся ошибок, а не различия в компиляторах и библиотеках.
                                  Ответить
                                  • Мы говорим об одном и том же. Я же не предлагаю мануалы сравнивать :) Требуется найти минимальную разницу, достаточную для сборки проекта, а не полную.
                                    Ответить
                      • >Помнится мне в билдере от борланда было, если после определения своего класса точку с запятой не укажешь, так он на системный хедер ругался
                        Это крайне простой случай. Есть такие, что для поиска реального места ошибки приходится разбираться в хедерах. Чего стоит один лишь fatal error C1001: INTERNAL COMPILER ERROR в Microsoft Visual C++ 6.0... Который совсем на место ошибки может не указывать, тк не всегда его знает...
                        Ответить
                        • >Это крайне простой случай.
                          Я и не собирался ничего усложнять :)
                          >fatal error C1001: INTERNAL COMPILER ERROR
                          Поставьте SP6.
                          Ответить
                          • >Я и не собирался ничего усложнять
                            Да не Вы усложняете, а ошибка более сложная, чем эта мелочь.

                            >Поставьте SP6.
                            Давно стоит, а вылазит регулярно в этом недописаном компиляторе...
                            Ответить
                            • >а вылазит регулярно в этом недописаном компиляторе...
                              Разбор хедеров позволяет что-то прояснить ?
                              Ответить
                              • >Разбор хедеров позволяет что-то прояснить ?
                                Ну если голова есть, то конечно. При таком объёме проектов это просто необходимость...
                                Ответить
                • Я правильно понимаю, аргументы насчёт говнокода в данном примере у вас закончились?

                  По поводу ошибок: имеется в виду, что в системных заголовках не нужно разбираться в 99,9% случаях, неужели не понятно.
                  Ответить
                  • Не опытный. Понимаю. Для встроенных устройств пока не программировали...
                    Ответить
                    • Какая связь?
                      Ответить
                      • Я так понимаю, никакой, как и смысла в продолжении обсуждения с данным человеком.
                        Ответить
                      • Просто в таких условиях приходится пользоваться левыми компиляторами с левыми хедарами и с не менее говнокодными проектами, доставшихся "от предков". Там проблема разбирательсва в хедерах стоит особо остро. Вплоть до того, что менять порядок включения хедеров нельзя, иначе ошибка на ошибке.
                        Ответить
                        • Так может стоит найти более качественную альтернативу компилятору и не грести говно лопатой ?
                          Ответить
                          • >найти более качественную альтернативу компилятору
                            Нет под некоторые платформы качественных компиляторов.
                            Ответить
                            • Как-то всё слишком абстрактно. И, вероятно, очень специфично.
                              Ответить

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