LINUX.ORG.RU

Видимость символов (компилятора)

 , , , ,


0

3

Почему в С/C++ до сих пор нет стандартизации управления видимостью символов, что упросило бы процесс переноса разделяемых библиотек на уровне исходного кода на системы с отличным компилятором? Макроопределения, в зависимости от задачи, могут сильно разрастаться и уродовать код. В С++ ведь уже давно есть спецификация атрибутов для передачи дополнительной информации компилятору. Ожидается ли в стандарте специальный атрибут для специализации символов?

PS. Речь о символах из секции .dynsym в elf файле, например


на системы с компилятром, отличным от чего? от стандарта? и как бы это «упростило» перенос? если библиотека написана и работает, то с ней ничего делать не надо. в конце концов, не нравится C - используй C++.

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

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

Rot1 ()
Ответ на: комментарий от Iron_Bug

если библиотека написана и работает, то с ней ничего делать не надо

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

Rot1 ()
Последнее исправление: Rot1 (всего исправлений: 1)
Ответ на: комментарий от Rot1

напиши скрипт и не парься. для стандарта никакой разницы нет. стандарт он и в Африке стандарт.

и на С как раз всё весьма неплохо переносится на другие системы. особенно если все обращения к API ядра вынесены в отдельный файл, как обычно и делается. но для большинства сишных программ этого не нужно, потому что они используют POSIX.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

напиши скрипт и не парься

Можно много всего написать, я ж с этим не спорю. Просто если стандартизировать, то писать ничего не нужно будет, а код будет очевидней и чище. Интересно, почему этого нет

Rot1 ()

нет стандартизации управления видимостью символов

Есть деление на компилируемые единицы, есть статик, есть блоки. В стандарте про них написано, видимостью они управляют.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от Rot1

А, понял, что ты хочешь.

Само собой, ждать такого в стандарт не стоит. Насколько помню, в стандартном C вообще нет контроля за видимостью в эльфах, это всё в гнутых расширениях только.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от Rot1

ну, вообще-то не под процессор, а под ось. ты как на сишечке под процессор-то собрался писать?

не, если у тебя там макросы по прямой работе с памятью - то придётся под каждый процессор. архитектурозависимые части. опять же, их обычно выносят в отдельный файл.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)

Зачем? Не портабельно.

К тому же надо понимать, что мало того само понятие видимости может и не существовать на целевой платформе, так ещё и «дефолтная» видимость у всех разная.

В Linux все символы как правило видимые. Поэтому очень забавно получается, когда разные глобальные переменные в двух библиотеках одинаково называются. В Windows и вроде бы OSX, символы скрытые по умолчанию.

a1batross ★★★★★ ()
Ответ на: комментарий от a1batross

В Linux все символы как правило видимые. Поэтому очень забавно получается, когда разные глобальные переменные в двух библиотеках одинаково называются. В Windows и вроде бы OSX, символы скрытые по умолчанию.

Из-за это и возникают трудности при переносе. Поведение компиляторов в этом вопросе различается. Приходится для конкретной системы модифицировать код

Не портабельно

Согласно стандарту компиляторы могут игнорировать атрибуты, неподдерживаемые на целевой платформе. Поэтому не вижу в этом причины...

Rot1 ()
Последнее исправление: Rot1 (всего исправлений: 1)