Не помогает.

никто не знает VS2017 между апдейтами бинарно совместима? То есть бинарь, собранный с VS2017 15.0 будет нормально линковаться с бинарём от VS2017 15.5?

что значит "бинарь будет нормально собираться"? Если из исходников, то это не бинарная совместимость

или ты про линковку?

что значит "бинарь будет нормально собираться"? Если из исходников, то это не бинарная совместимость

линковка, конечно же)

In Visual Studio 2015 and Visual Studio 2017, the C++ toolset major number is 14 (v140 for Visual Studio 2015 and v141 for Visual Studio 2017). This reflects the fact that both the runtime libraries and the applications compiled with either version of the compiler are--for the most part--binary compatible. И, насколько я помню, STL на reddit писал, что пока внутренняя версия 14, всё будет совместимо.

Всем привет! Коллеги, есть ли среди вас те, кто работает не в Москве, а в любом другом городе вместе со своей командой, и кто находится в поисках работы не только для себя, но и для своей группы/отдела?

Всем привет! Коллеги, есть ли среди вас те, кто работает не в Москве, а в любом другом городе вместе со своей командой, и кто находится в поисках работы не только для себя, но и для своей группы/отдела?

с вакансиями - в личку @AlexFails

с вакансиями - в личку @AlexFails

Таки я не предлагала вакансии_))) я пока только интересуюсь

Можно как-нибудь выкидывать compile-time error при компиляции асма (especially gnu/gcc) в не PIC-код?

Можно как-нибудь выкидывать compile-time error при компиляции асма (especially gnu/gcc) в не PIC-код?

мне кажется, разве что костылём через #ifndef PIC static_assert(), и держать дефайн и флаги компиляции в соответствии

мне кажется, разве что костылём через #ifndef PIC static_assert(), и держать дефайн и флаги компиляции в соответствии

не, флагов недостаточно же, сам асм может быть не PIC, проблема - искать подобный код

тогда я видимо не совсем понял вопрос

Ну есть ассемблерный код, который потенциально может быть не PIC, e.g: mov %eax, my_var ; вместо-> mov %eax, my_var(%rip) Вот хочется подобный код искать на этапе преобразования этого кода в объектный файл, а не на этапе линковки

код возникает из ассемблерных вставок, из результатов трансляции, или просто из исходников написанных на асме?

последнее

оу, тогда ничего не могу сказать(

Есть подозрение, что вставки при -fPIC должны выдавать ошибку компиляции; тут все тривиально

или собираться и работать как получится

@kitsu а как ты делаешь не pic код в x86_64 режиме?

у меня на это gcc сразу ругался, например

ну то есть, в x86_64 в ассемблере из-за rip addressing PIC получается автоматом, а сделать иначе будет миниум варнинг от компилятора, а, возможно, и ошибка - не помню

ну то есть, в x86_64 в ассемблере из-за rip addressing PIC получается автоматом, а сделать иначе будет миниум варнинг от компилятора, а, возможно, и ошибка - не помню

Почему-то не варнинга, ни ошибки нема

вот, нашел письмо старое

Please note, that I've changed your code slightly as you cannot load labels using 32-bits absolute address in 64-bits mode (so you'd need to use something like movq constant(%rip),%rax instead of movq constant,%rax). Gnu assembler is not strict about this issue, but clang refuses to compile it.

значит, собирал это на макоси шлангом

(простите за мой безграмотный английский)

сейчас @isenbaev придёт и отругает

ну т.е. имеем: - gas не знает ничего про -fPIC и писатель на ассемблере сам себе бог и может вставить любую ссылку; - gcc/clang получают -fPIC при компиляции кода, и проносят это в ld - тогда линкер при сборке shared модуля должен обозваться на неправильный фиксап, типа relocation R_X86_64_32S against `var1' can not be used when making a shared object; recompile with -fPIC и если в ассемблере вы имеете не %rip адресацию то надо смотреть на конкретный случай и смотреть тип получаемого fixup в объектнике

да, ровно такая ошибка и была

угу, проблема при линковке есть, хочется при компиляции

при компиляции gas-ом вряд ли получится, вот через пост-процессинг (а линкер тот же постпроцессор в данном случае) можно сделать

эх, жаль

если нужен ранний feedback (сразу после компиляции объектника из асма), то берете redelf/objdump смотрите типы релокейшенов, которые не хотите получать. оформляете как скрипт - запускаете в пачке с ассемблером.

Добрый день! Друзья, скажите, можно ли здесь публиковать вакансию?)

Вакансии - в лс @AlexFails.

так в описании группы написано, по крайней мере

А, увидела, спасибо)

Вики меня запутала, себя запутала, поэтому Вопрос: С++ поддерживает функциональное программирование ?

В целом да, но не с таким приятным синтаксисом, как это делают некоторые другие языки. Ну и вся стандартная библиотека под ФП скорее не заточена, так что нужно что-то сторонее (тот же Boost местами вполне себе функциональный по слухам)

нет, гораздо проще ответить на вопрос: является ли функция объектом первого рода - можно ли вернуть функцию из функции или принять функцию в виде аргумента

и ответ на этот вопрос: нет

принимаются либо указатели, либо врапперы

даже лямбды - это объекты с определенной семантикой, а не функции в чистом виде

Вики меня запутала, себя запутала, поэтому Вопрос: С++ поддерживает функциональное программирование ?

в С++ можно писать в функциональном стиле: да, но свойствами функционального языка С++ не обладает

нет, гораздо проще ответить на вопрос: является ли функция объектом первого рода - можно ли вернуть функцию из функции или принять функцию в виде аргумента

а в чем в данном случае различие?

ну, необходимым свойством функционального языка является именно это

различие в галочке: поддерживает парадигму или нет ...

ну, необходимым свойством функционального языка является именно это

Спс

принимаются либо указатели, либо врапперы

Я не вижу никакой принципиальной разницы между передачей врапперов или "напрямую" функций. Кажется, что она чисто синтаксическая?

она чисто концептуальная :)

ну, необходимым свойством функционального языка является именно это

просто пытаюсь понять, если такую поддержку сделают явно в синтаксисе, чем это будет отличаться от синтаксического сахара? То есть может есть какой то побочный эффект того что функции не первоклассные объекты в с++?

просто пытаюсь понять, если такую поддержку сделают явно в синтаксисе, чем это будет отличаться от синтаксического сахара? То есть может есть какой то побочный эффект того что функции не первоклассные объекты в с++?

Не дай бог, лучше уж пусть с другими проблемами разберутся.

Достаточно сахара

ну а какой должен быть побочный эффект? если язык работает в терминах композиций функций, то он функциональный, а если он считает функции рефренсами, указателями или же объектами, то он нефункциональный

но писать на нефункциональном языке можно и в функциональном стиле, только, зачастую, очень кондово

на шаблонах поди вполне можно в функциональном стиле

шаблоны - это вообще декларативный язык

Нуу, там не то чтобы функциональный, там скорее всё просто иммутабельное.

система логического вывода, пролог, make, вот это все

нет, иммутабельность - это вообще из другой оперы

Окей, что-то из логического там тоже что-то есть из-за сопоставления типов и специализаций.

где там? в шаблонах только это и есть

Ну по своей природе шаблоны ближе к лямбда-исчислению, чем к Тьюрингу

не уверен насчет близости. SFINAE - это механика логического ЯП

ну и подстановки в целом

ну а какой должен быть побочный эффект? если язык работает в терминах композиций функций, то он функциональный, а если он считает функции рефренсами, указателями или же объектами, то он нефункциональный

не знаю, может отсутствие lazy evaluation?

какой тип?

lambda closure оно unspecified по стандарту

пролог - логический язык

лямбды тут при том, что если ты возвращаешь функцию, то в терминах c++ возвращается объект или указатель

но не функция

опять же: различие концептуальное

конечно, не один и тот же

1) это адрес 2) это адрес в ячейке)

раннее связывание и позднее

auto func() { return [](){ return 42; }; } - во что отрезолвится auto

в указатель?

или в каком плане - одно и тоже ?

эм