
а gcc выставляет какой-нибудь define, по которому можно определить что текущая ось — фряха?
а gcc выставляет какой-нибудь define, по которому можно определить что текущая ось — фряха?
продолжая (завершая?) тему нелинковки с libstdc++:
$ echo "class A{}; int main(){}">test.cpp
$ g++ test.cpp -Wl,--as-needed
$ ldd a.out
linux-vdso.so.1 => (0x00007fffa91f8000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc5ea754000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc5eaaec000)
к вопросу о том как собрать плюсовую программу без libstdc++:
$ echo "class A{}; int main(){}">test.cpp
$ gcc test.cpp
$ ldd a.out
linux-vdso.so.1 => (0x00007ffff45e3000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb97686b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb976c03000)
единственным способом собрать плюсовую программу без линковки с libstdc++ и при этом со всеми остальными либами — это компилять её с помощью g++, а линковать используя gcc
объясните, нахуя на x86 размер указателя на мембер-функцию — 8 байт, если в старших четырёх байтах лежат нули?
интересно, а когда сабж графитовские оптимизации над циклами делает, он учитывает размер L2 кэша на текущем проце?
stl сабжа теперь активно юзает билтины типа __is_trivial и __decltype, собственно, не так то просто что программа компилируется ещё и шлангом. второтег. ставлю STLport
4.6.2 вышел, а «CFLAGS=-O3 emerge -e wine» всё равно даёт неработающий бинарник
а только меня заёбывает «frame size too large for reliable stack checking»? как боритесь? истории успеха?
компилятор, сука, хитрый. вот тут http://ideone.com/wxFKE он ни разу конструктор копирования не использовал, но стоит этот конструктор копирования в private секцию перенести, так сразу плач и слёзы: http://ideone.com/ahuOZ . copy elision такой copy elision.
делаем ставки, в какой версии gcc c++0x будет заменено на c++11? думается мне что это будет 4.8.0, в 4.7.0 вряд ли пихнут.
поцчему в gcc нет «интерпретатор моде»? шоб компилял бинарь в память и сразу же запускал. куда удобнее тестовые проги было бы храначить. а то создаёт бинарь постоянно
http://www.gentoo.org/doc/en/gcc-optimiz... внезапно всё просто и понятно расписано
столь разное поведение в зависимости от версии компилятора делает меня охуевшей пандой: http://ideone.com/RSskC vs http://ideone.com/ZuBB8, а ведь glibc-то один...
оказалось что в гцц нельзя вызвать препроцессорную директиву #line с аргументом большим 32767
объясните мне кто-нибудь корреляцию второго абзаца здесь: http://gcc.gnu.org/onlinedocs/libstdc++/... и работы вот этого: http://ideone.com/tbtQ7 скомпиленного так: g++ -D_GLIBCXX_PARALLEL -fopenmp parallel.cpp -pthread
я в восхищении, надо бы опробовать: http://gcc.gnu.org/onlinedocs/libstdc++/...
http://gcc.gnu.org/onlinedocs/libstdc++/... отпусти меня чудо трава, я спать хочу, а не с деманглингом и прочими вкусностями ебаться :(
давно было интересно как в STL сделан std::swap(a, b) для объектов у которых определена мембер-функция swap. оказалось что функция просто перегружена для векторов. и это в двадцать первом веке... а я так надеялся посмотреть на новый, годный SFINAE привнесённый новым стандартом.
Довольно просто заставить ебилд билдиться последней установленной версией гцц, а не той, что выставлена в активном профайле: http://dumpz.org/77879/
в снэпшоте 4.7.0-20110806 дела с type_traits лучше чем в 4.6.1 (например появился is_copy_assignable), но всё ещё содержит has_trivial_default_constructor вместо is_trivially_default_constructible.
analizer
0xd34df00d
hirthwork
ulidtko
lexszero
generatorglukoff
beardog
SirAnthony
magog
gelraen
MPogoda
asmer
13oz
mva
238328
4da