Исправление hobbit, (текущая версия) :
Что явно от небольшого ума.
Переход на личность оппонента характеризует не столько оппонента, сколько Вас. Но ладно, покормлю ещё.
Вам просто не нравится, что ваша тривиальная ошибка не самоустраняется компилятором как нянькой.
Ну вы уже определитесь. Либо самоустраняется, либо компилятором. :)
Если серьёзно - про какого рода ошибку речь? Если про ту, которую у ТС - она от недопонимания процесса сборки. Но на самом деле здесь ещё закладывается избыточность, которая может привести к более глубоким ошибкам. Представьте себе, что на какой-то стадии extern int globalValue переименовали, а та, которая в сишнике, осталась нетронутой. Сообщение об ошибке будет, конечно, только вот увидеть его связь с источником может оказаться непросто.
Не понимая, что в других случаях эта «я знаю лучше что вам на самом деле хочется» будет чудовищно бесить.
Вы опять занимаетесь телепатией. Где у меня «я знаю лучше что вам на самом деле хочется», не покажете?
Я объяснил, какую модульность я считаю хорошей - это когда модуль является не только файлом, но и лексической единицей, со своими проверками. В C и C++ не так.
Вот одно из следствий (не единственное). Если я в паскале забуду включить в uses нужный мне модуль - я гарантированно получу сообщение об ошибке. Ибо uses контролируется компилятором и не обладает транзитивностью. Если же я в C или C++ забуду написать #include, то может случиться так, что на одной версии используемой библиотеки программа соберётся, а на другой вывалит ошибку.
Это потому, что в первом случае я из своего example.cpp вызвал lib1.h, а тот, в свою очередь, включает lib2.h, в котором по случайному совпадению, определена нужная мне функция/класс. А в другой версии lib API оставили, но включаемые файлы отвязали друг от друга. И в общем-то, авторы библиотеки имеют на это право, поскольку порядок вхождения заголовочных файлов друг в друга - это такая внутренняя кухня, которая обычно даже не документируется толком. Единственный способ обеспечить однозначность здесь - это самому следить за тем, чтобы в прикладном проекте были написаны #include для всех имён, которые должны быть разрешены. Ошибиться тут очень легко (и не только новичку).
Приведённый пример - не академический, я такую ситуацию встречал в проекте на C++/Qt, который должен был собираться на трёх разных ОС, и Qt и gcc там были разных версий. Код писали три программиста. На двух платформах собирается, на третьей не хочет.
Я не хочу, чтобы компилятор исправлял ошибки за меня (если Вам так показалось). Я хочу, чтобы сообщения об ошибках были предсказуемы и однозначны. Это тоже, по-вашему, называется «я знаю лучше что вам на самом деле хочется»?
Исходная версия hobbit, :
Что явно от небольшого ума.
Переход на личность оппонента характеризует не столько оппонента, сколько Вас. Но ладно, покормлю ещё.
Вам просто не нравится, что ваша тривиальная ошибка не самоустраняется компилятором как нянькой.
Ну вы уже определитесь. Либо самоустраняется, либо компилятором. :)
Если серьёзно - про какого рода ошибку речь? Если про ту, которую у ТС - она от недопонимания процесса сборки. Но на самом деле здесь ещё закладывается избыточность, которая может привести к более глубоким ошибкам. Представьте себе, что на какой-то стадии extern int globalValue переименовали, а та, которая в сишнике, осталась нетронутой. Сообщение об ошибке будет, конечно, только вот увидеть его связь с источником может оказаться непросто.
Не понимая, что в других случаях эта «я знаю лучше что вам на самом деле хочется» будет чудовищно бесить.
Вы опять занимаетесь телепатией. Где у меня «я знаю лучше что вам на самом деле хочется», не покажете?
Я объяснил, какую модульность я считаю хорошей - это когда модуль является не только файлом, но и лексической единицей, со своими проверками. В C и C++ не так.
Вот одно из следствий (не единственное). Если я в паскале забуду включить в uses нужный мне модуль - я гарантированно получу сообщение об ошибке. Ибо uses контролируется компилятором и не обладает транзитивностью. Если же я в C или C++ забуду написать #include, то может случиться так, что на одной версии используемой библиотеки программа соберётся, а на другой вывалит ошибку.
Это потому, что в первом случае я из своего example.cpp вызвал lib1.h, а тот, в свою очередь, включает lib2.h, в котором по случайному совпадению, определена нужная мне функция/класс. А в другой версии lib API оставили, но включаемые файлы отвязали друг от друга. И в общем-то, имеют право, поскольку порядок вхождения заголовочных файлов друг в друга - это такая внутренняя кухня, которая обычно даже не документируется толком. Единственный способ обеспечить однозначность здесь - это самому следить за тем, чтобы в прикладном проекте были написаны #include для всех имён, которые должны быть разрешены. Ошибиться тут очень легко.
Приведённый пример - не академический, я такую ситуацию встречал в проекте на C++/Qt, который должен был собираться на трёх разных ОС, и Qt и gcc там были разных версий. А, и код писали три программиста. На двух платформах собирается, на третьей не хочет.
Я не хочу, чтобы компилятор исправлял ошибки за меня. Я хочу, чтобы сообщения об ошибках были предсказуемы и однозначны. Это тоже, по-вашему, называется «я знаю лучше что вам на самом деле хочется»?