История изменений

Это понятно, но компилятор (сишный) же не позволит подключить две библиотеки у которых две функции имеют одинаковые имена. (Или ошибаюсь?) Получается неоднозначности тоже быть не может.

У меня в институте был доставляющий случай в сишке. Дело было под ДОСом. Я использовал функцию, кажется, fabs(), но подключил неправильный заголовочник (в справочнике была ошибка, кажется, я написал #include <sddlib.h> вместо math.h). Компилятор (турбо си начала 90-х), не найдя прототип функции, сгенерировал прототип по умолчанию, с интовым аргументом и интовым же результатом. Потом линкер эту функцию в библиотеке, естественно, нашёл, и она вызывалась, но из-за несоответствия параметров портился стек.

Вишенкой на торте было то, что функция использовалась исключительно в условии цикла do-while в критерии сходимости итерационного алгоритма. Т.е. функция запускалась, бодро считала, причём промежуточные результаты были абсолютно правильные, но по мере порчи стека всё начинало тормозить, и в конце концов программа вешалась (кажется, вместе с ДОСом). Я НЕДЕЛЮ искал, где ошибка. При том, что прототип на паскале был написан и отлажен за вечер.

А, ещё вот такая дивная хаутушка по одному очень популярному и пугающему новичков сообщений об ошибке. Там, правда, на тараканов C++ накладываются ещё тараканы Qt, но корни проблемы схожие.

Отсюда же совет принимать живительный ребилдол при непонятно откуда взявшихся ошибках сборки. (И ведь помогает!)

Я не против #include там, где он действительно нужен. Но расходовать его как изоленту для костылей отсутствующей модульности в 2018 году слегка подбешивает.

На мой взгляд инклуды и дефайны простой и понятный инструмент.

Он простой по своей сути. Но вот описанное применение его приводит к далеко не простым и неоднозначным последствиям.

Вродь у китайцев есть пословица: когда в руке молоток, любая проблема кажется гвоздем.

Угу, это использовалось в те же 90-е в рекламе не то у сана, не то у силикон графикса.

Это понятно, но компилятор (сишный) же не позволит подключить две библиотеки у которых две функции имеют одинаковые имена. (Или ошибаюсь?) Получается неоднозначности тоже быть не может.

У меня в институте был доставляющий случай в сишке. Дело было под ДОСом. Я использовал функцию, кажется, fabs(), но подключил неправильный заголовочник (в справочнике была ошибка, кажется, я написал #include <sddlib.h> вместо math.h). Компилятор (турбо си начала 90-х) сгенерировал для функции прототип по умолчанию, с интовым аргументом и интовым же результатом. Потом линкер эту функцию в библиотеке, естественно, нашёл, и она вызывалась, но из-за несоответствия параметров портился стек.

Вишенкой на торте было то, что функция использовалась исключительно в условии цикла do-while в критерии сходимости итерационного алгоритма. Т.е. функция запускалась, бодро считала, причём промежуточные результаты были абсолютно правильные, но по мере порчи стека всё начинало тормозить, и в конце концов программа вешалась (кажется, вместе с ДОСом). Я НЕДЕЛЮ искал, где ошибка. При том, что прототип на паскале был написан и отлажен за вечер.

А, ещё вот такая дивная хаутушка по одному очень популярному и пугающему новичков сообщений об ошибке. Там, правда, на тараканов C++ накладываются ещё тараканы Qt, но корни проблемы схожие.

Отсюда же совет принимать живительный ребилдол при непонятно откуда взявшихся ошибках сборки. (И ведь помогает!)

Я не против #include там, где он действительно нужен. Но расходовать его как изоленту для костылей отсутствующей модульности в 2018 году слегка подбешивает.

На мой взгляд инклуды и дефайны простой и понятный инструмент.

Он простой по своей сути. Но вот описанное применение его приводит к далеко не простым и неоднозначным последствиям.

Вродь у китайцев есть пословица: когда в руке молоток, любая проблема кажется гвоздем.

Угу, это использовалось в те же 90-е в рекламе не то у сана, не то у силикон графикса.