Здравствуйте, niXman, Вы писали:
DE>>ATL хедеры mingw, вроде, не переваривает. X>это не Си/С++?
Как бы С++, но по моему как раз из-за расширение и не получалось использовать. Позже до проекта доберусь — смогу глянуть.
DE>>Плюс некоторые виндовые хедеры из тех, что с твоим mingw идут не полные. X>почему не репортуешь?
В sal.h содержимого гораздо меньше, чем в виндовом, например.
DE>>Ну и как-то мелкий проект было желание на mingw перевести, получил "out of memory allocating x bytes". X>при компиляции?
Да. К сожалению исхoдники показать не могу. Выделить проблемный кусок тоже не удалось.
DE>>Ну хз. Если один инструмент позволяет использовать привычное окружение, а другой нет, то первому одножначно плюс. X>"привычное окружение" — понятие относительно. как мы выяснили, привычное окружения для меня и Абикса — несовместимы. тем не менее, я на венде вполне себе нормально кожу, если нужно. криейтор+мингв — все, что нужно. иногда даже в консоль спускаюсь.
Естественно, относительно. Тем не менее, при возможности пользоваться привычными инструментами люди предпочитают это и делать. И при переходе будут упираться. Особенно если нет никаких особых преимуществ. Возможности нового стандарта, к сожалению ("как ни странно"), не всех убеждают.
DE>>Смысл в том, что код уже написан. Переделывать его никто не будет. X>понятно. X>так и со стандартом — что-то кардинально менять никто не хочет, и волокут обратную совместимость, которая мешает всему новому. так кому от этого выгода? — новым проектам которые решают использовать компилируемый ЯП, но не хотят С++ из-за его "багажа", и, таким образом, выбирают Go/D?
Так если бы они начали выкидывать "старое барахло", то было бы ещё хуже — в куче проектов тупо зафиксировали бы старую версию и всё. А так хоть ограниченно новые фичи вносить можно.
К D, кстати, даже в текущих условиях часто претензии высказывают из-за ломающих изменений.
DE>>Ну и такое отношение весьма показательно, не находишь? X>показательно. X>но, GCC не имеет среди таргетных платформ венду. то, что GCC умеет компилить для венды, безо всякой эмуляции и прослоек — это заслуга mingw.org и mingw-w64. оба эти проекта проделали огромнейшую работу, но, видимо, недостаточную...
Я понимаю и уважаю труд этих людей (ага и твой в том числе). Просто хочу сказать, что силанговский подход (если они, конечно, завершат начатое) имеет свои плюсы.
Re[11]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DarkEld3r, Вы писали:
DE>>Здравствуйте, niXman, Вы писали:
X>>>это тоже самое, как и ругать GCC за то, что он предоставляет свои расширения, которые не поддерживают другие компиляторы. нелогично же? DE>>Ну скажем интеловский компилятор с майкросовтовским совместим... X>правда? хм.. Да, правда не могу сказать насколько полностью.
Про совместимость с GCC у них тоже есть.
Re[10]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, skeptic, Вы писали:
NB>>>>единственный случай когда отладчик нужен, это когда разбираешься в чужом коде. NB>>>>для остального хватает обычного логирования.
S>>>Ну и вообще, нельзя быть таким категоричным, вот чужой код, это чей?
NB>>тут все просто, свой код это код, который написал сам. если приходится лезть в чужой модуль, или в код, который после тебя переписали, то естественно этот код чужой
S>Ну и к чему тогда было заявление про логирование, которого в теории хватает, но на практике за чередой всевозможных "если", кейс с достаточностью одного лишь логирования никогда не выполняется?
на практике, лезть в чужой код приходится довольно редко.
те ситуации что ты описал конечно встречаются, но они имхо являются тревожным признаком. и в таких случаях иногда бывает проще переписать с нуля чем разбираться в чужом г-не.
опыта работы в больших компаниях не имею, поэтому допускаю что там все происходит по-другому.
Re[10]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, DarkEld3r, Вы писали:
DE>Как бы С++, но по моему как раз из-за расширение и не получалось использовать. Позже до проекта доберусь — смогу глянуть.
если доберешся — дай знать. хотелось бы понять причину.
DE>В sal.h содержимого гораздо меньше, чем в виндовом, например.
скинь плиз sal.h от msvc, гляну.
DE>Да. К сожалению исхoдники показать не могу. Выделить проблемный кусок тоже не удалось.
исходники не нужны. просто если появится время/желание — дай знать, возможно таки сможем победить.
DE>Я понимаю и уважаю труд этих людей (ага и твой в том числе). Просто хочу сказать, что силанговский подход (если они, конечно, завершат начатое) имеет свои плюсы.
по поводу clang-cl — я это сделаю для мингва, типа gcc-cl
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[11]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
DE>>Как бы С++, но по моему как раз из-за расширение и не получалось использовать. Позже до проекта доберусь — смогу глянуть. X>если доберешся — дай знать. хотелось бы понять причину.
Проблемы, например, в "throw( ... )", например (atlalloc.h):
.../Microsoft Visual Studio 10.0/VC/atlmfc/include/atlalloc.h: At global scope:
.../Microsoft Visual Studio 10.0/VC/atlmfc/include/atlalloc.h:493:44: error: expected type-specifier before '...' token
CTempBuffer(_In_ size_t nElements) throw( ... ) :
^
Нестандартно (и бесполезно), но править хедеры не хочется.
Кстати, когда гуглил что-то про mingw + ATL, то находил ответы, что включить ATL хедеры в мингщ нельзя из-за лицензии. Не вникал правда.
DE>>В sal.h содержимого гораздо меньше, чем в виндовом, например. X>скинь плиз sal.h от msvc, гляну. Вот (который с 2010 студией идёт).
Re[7]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, DarkEld3r, Вы писали:
DE>Кстати, когда гуглил что-то про mingw + ATL, то находил ответы, что включить ATL хедеры в мингщ нельзя из-за лицензии. Не вникал правда.
разузнаю.
DE>Вот (который с 2010 студией идёт).
как написано в самом sal.h: "sal.h provides a set of annotations to describe how a function uses its parameters — the assumptions it makes about them, and the guarantees it makes upon finishing." — т.е. это макросы, использующие в описании API. таким образом, они по логике не должны перетекать в пользовательский код.
так что да, если mingw-w64 в описании API не использует часть этих макросов, то его содержание может отличаться.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[8]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DarkEld3r, Вы писали:
DE>>Кстати, когда гуглил что-то про mingw + ATL, то находил ответы, что включить ATL хедеры в мингщ нельзя из-за лицензии. Не вникал правда. X>разузнаю.
можно. там действует тот же принцип, что и для остальных хидеров — они не копируются из msvc, а пишутся руками. иначе, любые хидеры нельзя было бы включать в мингв.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[10]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
X>кто-нибудь, приведите пример нескольких популярных опций cl.exe. хочу из кланга взять карту соответствий, но не могу понять где она. X>спасибо.
их много.
вот например опции по умолчанию для Debug x86
Здравствуйте, Abyx, Вы писали:
A>минимально необходимые это наверное пути к файлам и дефайны. A>остальное можно сделать заглушками
думаю, сделать поддержку основных опций оптимизации(-O0,-O1,-O2,-O3), дефайнов, и путей к хидерам.
A>также надо не забыть про командные файлы, они вроде используются в msbuild — http://msdn.microsoft.com/en-us/library/x2khzsa1.aspx
эм.. поможешь, если что, с пониманием? а то я читаю доку, и реально чего-то недопонимаю... это что-то вроде баша для вендус?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[14]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
A>>также надо не забыть про командные файлы, они вроде используются в msbuild — http://msdn.microsoft.com/en-us/library/x2khzsa1.aspx X>эм.. поможешь, если что, с пониманием? а то я читаю доку, и реально чего-то недопонимаю... это что-то вроде баша для вендус?
не, там те же опции командной строки, только в файле.
In Zen We Trust
Re[7]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
A>>- код компилируется медленно X>ну да, слышал уже неоднократно) X>намного медленнее?
не сильно медленнее, но ощущается. и виной тут не gcc сам по себе, а его прослойка mingw.
две библиотеки ICU и xerces-c. на VC собираются быстро.
беру msys2 (чтобы не наткнутся на проблему с компилированием в несколько потоков), gcc. запускаю сборку в число_ядер+1 потоков. времени уходит больше.
сейчас пытаюсь переползти на написание кода в linux (надеюсь получить больше плюсов, таких как valgrind и более адекватное поведение нужных библиотек). т.е. это рабочее место, а код потом уже в win собрать под mingw. виртуальная машина с fedora на том же компе, что и mingw/VC .версия gcc та же (4.8.2). запускаю сборку библиотек — если сказать, что сборка идет быстро — ничего не сказать. а уж момент конфигурации по сравнению с msys идет почти мгновенно.
Re[8]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, ctapmex, Вы писали:
C>и виной тут не gcc сам по себе, а его прослойка mingw. C>... C>беру msys2
противоречий не замечаете?
C>надеюсь получить больше плюсов, таких как valgrind
бестолковый инструмент для плюсового кода.
C>момент конфигурации по сравнению с msys идет почти мгновенно.
так очевидно же, msys трансформирует пути/аргументы/етц налету.
вот только к мингву это не имеет отношения.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[9]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, ctapmex, Вы писали:
C>>и виной тут не gcc сам по себе, а его прослойка mingw. C>>... C>>беру msys2
X>противоречий не замечаете?
при запуске из под msys2 mingw-gcc работает ведь напрямую, не беря ничего от msys ? согласен, что make может не так эффективно работать под виндой.
mingw-шный make умеет в потоках собирать ?
C>>надеюсь получить больше плюсов, таких как valgrind X>бестолковый инструмент для плюсового кода.
ну бестолковый или нет, а под виндой бесплатного ничего нет для поиска утечек. использование всяких либ для этого как то не сложилось. то не видят проблем при работе с классами из библиотек (надо все библиотеки пересобирать вместе с ней), то не работают под mingw по причине "posix gcc детектим, и меняем хедеры — не собирается; win gcc — не имеет имплементацию потоков). это гугловская библиотека, название не помню
C>>момент конфигурации по сравнению с msys идет почти мгновенно. X>так очевидно же, msys трансформирует пути/аргументы/етц налету.
согласен. X>вот только к мингву это не имеет отношения.
Re[8]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, ctapmex, Вы писали:
C>надеюсь получить больше плюсов, таких как valgrind
оно, вам наверное нужно для поиска утечек памяти?
приведу пример из личного опыта, произошедший совсем недавно.
есть проект, довольно таки большой проект, ~200000 loc.
начали подготавливать проект к релизу, и обнаружились "стандартные" Си`шные чудеса в виде произвольных падений программы. при том валилась программа в совершенно разных участках, порою даже не связанных(разве что адресным пространством). я в течении нескольких дней понял, что мы имеем дело либо с порчей кучи/стека, либо с висячими указателями, либо и то, и другое.
и вот, три человека, в течении месяца, полный рабочий день занимаются только поисками этих багов. по истечении месяца стало понятно, что ничего найти не получается. стандартные средства типа отладчика и стек-трейсера никак не помогают, а только путают. так же опробован valgrind, который, к слову, тоже только "голову морочил". не для плюсового кода он, однако.
и вот, как последняя надежда, решили попробовать AddressSanitizer, который был включен в gcc-4.8.х(так же был добавлен и ThreadSanitizer, но его пока не приходилось опробовать), и, с его помощью, за один день пофиксили баги.
баги, как оказалось, были однотипные, и всего три — висячие указатели smile
хз, сколько еще месяцев потребовалось бы на поиски этих багов, без AddressSanitizer %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[10]: [ann] Visual C++ Compiler November 2013 CTP
Здравствуйте, ctapmex, Вы писали:
C>при запуске из под msys2 mingw-gcc работает ведь напрямую, не беря ничего от msys ?
напрямую.
C>mingw-шный make умеет в потоках собирать ?
уже более года, как.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
