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

GNU C — de facto стандарт. Зачем поддерживать что-либо другое?

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

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

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

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

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

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

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

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

то есть, ты предлагаешь менять стандарты, линкеры и компиляторы на *всех* платформах, потому что тебе лень писать скрипт?

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

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

Может тогда под каждый процессор писать программу будем? Или тоже «лень»?

В видимости имен (функции, переменные) и видимости символов есть большая разница

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

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

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

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

на языке ассемблера, конечно. Зачем сишечка, абстракция для слабаков и лентяев

Хех, можно под байт машину. Например, Java.

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

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

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

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

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

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

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