Здравствуйте, Shmj, Вы писали:

S>h-файл при грамотном использовании можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации. Ну круто же, что это придумали полвека назад.

Это пока не появляются шаблоны, инлайн функции и constexpr/consteval где внезапно реализацию надо прописать в заголовочном файле

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И что? Ты считаешь что этого достаточно чтобы делать двойную работу и бороться с рассинхроном?

Да.

vsb>> Ничего концептуального там нет. По сути его можно вообще механически генерировать.

НС>Т.е. информации там строго 0. Так нафига?

Я уже писал, нафига. Чтобы всё было в одном месте.

vsb>> Или в IDE сделать кнопку "скрыть всё лишнее". Но не сделали.

НС>И Rider и VS для шарпа уже давно умеют показывать структуру файла.
НС>Image: FileStructure.png

Это полная лажа. Я текст пишу и читаю, а не в крохотных окошечках что-то там пытаюсь разглядеть. Где жавадоки? Где нормальный синтаксис? Почему не на весь экран? Почему шрифт не моноширинный? Где возможность редактировать этот текст? Где возможность выделить что мне надо? Где возможность контрол-кликать по всему, чему душе угодно.

Это окошко просто максимально бесполезное.

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

Здравствуйте, Homunculus, Вы писали:

[]

H>и правка, например, названия и аргументов функции тоже в двух местах- не нужная трата времени.

Мне бы ваши проблемы (с)

Здравствуйте, vsb, Вы писали:

НС>>И что? Ты считаешь что этого достаточно чтобы делать двойную работу и бороться с рассинхроном?
vsb>Да.

Ну вот а большинство считает иначе, поэтому нив одном современном языке предварительных деклараций, к счастью, нет.

vsb>>> Ничего концептуального там нет. По сути его можно вообще механически генерировать.
НС>>Т.е. информации там строго 0. Так нафига?
vsb>Я уже писал, нафига. Чтобы всё было в одном месте.

Т.е. ради чистоты концепций. ЧТД. Не работает.

НС>>И Rider и VS для шарпа уже давно умеют показывать структуру файла.
НС>>Image: FileStructure.png
vsb>Это полная лажа. Я текст пишу и читаю, а не в крохотных окошечках что-то там пытаюсь разглядеть.

Вкусовщина.

vsb>Это окошко просто максимально бесполезное.

А им никто и не пользуется. Пользуются Go To Member.

vsb>Я не спорю, что в IDE можно что-то подобное сделать. Но не делают и непонятно, сделают ли.

А может не делают, потому что, помимо нескольких эстетов, оно и не нужно никому, не?

N>Не путаем. Это вы путаете:
N>

N>6.10.2 Source file inclusion
N>Constraints
N>A #include directive shall identify a header or source file that can be processed by the implementation.

N>Слова "source file" присутствуют. Слово "header" присутствует (формально header не обязан быть файлом).
N>Слово "module" отсутствует.
Вот именно!
Модуль — это пространство имен, имена из которого я могу экспортировать или нет.

Здравствуйте, _NN_, Вы писали:

S>>h-файл при грамотном использовании можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации. Ну круто же, что это придумали полвека назад.
_NN>Это пока не появляются шаблоны, инлайн функции и constexpr/consteval где внезапно реализацию надо прописать в заголовочном файле

Их можно прописывать в отдельных файлах.

Здравствуйте, Homunculus, Вы писали:

H>У всех по-разному, видимо. Кому-то видимо и в голову не приходит, что раздувание количества файлов в два раза и правка, например, названия и аргументов функции тоже в двух местах- не нужная трата времени.
Эээ....
Зачем править названия аргументов (или, таки, параметров?) в двух местах?

Здравствуйте, Shmj, Вы писали:

S>h-файл при грамотном использовании можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации. Ну круто же, что это придумали полвека назад.

Чего крутого в копипасте кучи кода?

Здравствуйте, Homunculus, Вы писали:

H>Ну глянь опен-сорсные крутые проекты.
Быгыгы. Там качество всегда было так себе, каждый дрочит как хочет.

H> Или куча хедеров в начале файла или все хидеры включены в один и подключается ко всему.
Компилеры давно умеют в автоматический PCH, так что не очень понятно на что ты тут жалуешься

H>Ну, когда вынужден ради функции int GetValue() {return a;} создавать отдельный файл — да, плохой знак.
Зачем отдельный? Что мешает её оставить в .h?

Здравствуйте, omgOnoz, Вы писали:

O>Чего крутого в копипасте кучи кода?
Не кода а деклараций. Копипаста кода приведёт к тому что результат не слинкуется.

Здравствуйте, Shmj, Вы писали:

S>h-файл при грамотном использовании можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации. Ну круто же, что это придумали полвека назад.

Еще бы оно этим и ограничивалось было бы вообще замечательно.

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

Здравствуйте, kaa.python, Вы писали:


KP>Да, файлов больше. Но в то же время у тебя есть возможность посмотреть чисто на интерфейс и не выискивать его за реализацией.

А это возможность стоит трудозатрат на ее обеспечение? Может эту возможность как-то по другому можно обеспечить? Генератором документации каким-нибудь. И посмотреть можно и руками все дублировать/синхронизировать не нужно.

Здравствуйте, Константин Б., Вы писали:

КБ>А это возможность стоит трудозатрат на ее обеспечение? Может эту возможность как-то по другому можно обеспечить? Генератором документации каким-нибудь. И посмотреть можно и руками все дублировать/синхронизировать не нужно.

Трудозатраты около нулевые на самом деле, так как все IDE давно умеют разом всё добавлять и править. В то же время как польза большая, т.к. когда IDE нет, иметь возможность видеть декларацию отдельно от реализации очень удобно.

Здравствуйте, Vzhyk2, Вы писали:



V>Кстати, я сильно удивляюсь, почему компиляторы уже мильон раз переписали, омтимизировали, а линкер всё тот же самый, по сути, что и 40 лет назад.

Gold, mold, lld — народ старается. Другое дело, что у линкера руки связаны и родить что-то принципиально другое, что позволило бы кардинально сменить архитектуру и ускорить сборку, невозможно — без смены архитектуры самого формата и загрузчика ОС.

Здравствуйте, Homunculus, Вы писали:

H>Здравствуйте, Shmj, Вы писали:

S>>h-файл при грамотном использовании можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации. Ну круто же, что это придумали полвека назад.

H>Ну попрограммируй еще пару годиков и поймешь какой это геморрой.

А как вы без .h файла подключите сторонюю библиотеку к проекту без описания его api?

Здравствуйте, Shmj, Вы писали:

S>h-файл при грамотном использовании можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации. Ну круто же, что это придумали полвека назад.

В нормальных ЯП необходимость в to separate declaration from implementation практически отсутствует ( но есть, например, в ДИ, ФШАРП).
слышал, вроде в си хидеры юзают для ускорения компиляции.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/signature-files

https://dlang.org/spec/interfaceToC.html#using-c-libraries

Здравствуйте, kaa.python, Вы писали:

KP>Да, файлов больше. Но в то же время у тебя есть возможность посмотреть чисто на интерфейс и не выискивать его за реализацией.

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

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, Константин Б., Вы писали:

КБ>>А это возможность стоит трудозатрат на ее обеспечение? Может эту возможность как-то по другому можно обеспечить? Генератором документации каким-нибудь. И посмотреть можно и руками все дублировать/синхронизировать не нужно.

KP>Трудозатраты около нулевые на самом деле, так как все IDE давно умеют разом всё добавлять и править.

Какие именно умеют? В студии и CLion ничего такого не нашел.

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, kaa.python, Вы писали:

KP>>Здравствуйте, Константин Б., Вы писали:

КБ>>>А это возможность стоит трудозатрат на ее обеспечение? Может эту возможность как-то по другому можно обеспечить? Генератором документации каким-нибудь. И посмотреть можно и руками все дублировать/синхронизировать не нужно.

KP>>Трудозатраты около нулевые на самом деле, так как все IDE давно умеют разом всё добавлять и править.

КБ>Какие именно умеют? В студии и CLion ничего такого не нашел.

Плохо искали? Как минимум в CLion:
1. Задаётся объявление в теле класса, потом можно перейти к реализации — оно создаёт метод с пустым телом в парном .cxx/etc.
2. Если менять имя или сигнатуру, меняется одновременно в .hxx, .cxx, и всех местах использования, о которых оно в курсе.

Здравствуйте, Homunculus, Вы писали:

H>Но это все фигня по сравнниею с тем, что надо тратить время на обдумывание включений. Какой файл куда подключать, куда не надо. А уж ругать компилятора про множетсвенные включения с реализацией несмотря на #pragma once — ммм, что может быть лучше да, когда вместо того, чтоб делать работу — занимаешься этой херней.
Постой, чта?
Друг, понимание что куда включать приходит приблизительно на вторую неделю программирования на плюсах. Потом даже не задумываешься.
А раз уж тебе приходиться задумываться да ещё и круговые включения у тебя получаются, то скорее всего ты не разобрался либо с плюсами, либо с проектом.