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

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

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

KP>А сколько лет надо ждать до понимания? Мне 18 лет как эта особенность языка нравится.

А где я сказал про «нравится»? Я сказал, что это геморрой. Кому-то и геморрой нравится.

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

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

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

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

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

А сколько лет надо ждать до понимания? Мне 18 лет как эта особенность языка нравится.

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

H>У всех по-разному, видимо. Кому-то видимо и в голову не приходит, что раздувание количества файлов в два раза

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

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

2022 на дворе, даже у меня в Vim есть рефакторинг

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

То есть противоречия в своем ответе не видишь?
Вот именно, что современные IDE позволяют свернуть всю реализацию и видеть лишь интерфейсы.

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

H>>Беда. Ну люблю ничего лишнего, когда можно без этого обойтись.
CC>Ну смотря что считать лишним.
CC>Комменты в коде хоть пишешь?

Комментарии цветом отфильтровываются мозгом.
А вот куча приватных полей и функций, которые нифига не интерфейс класса, но забивают h файл — визуально отфильтровать сложнее

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

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

S>А при неграмотном — как источник мерзких ошибок линкера.
А нафига подпускать неграмотных к мощным инструментам?

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

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

KP>Ладно, сколько времени ждать до того как придет понимание что это геморрой?

У всех по-разному, видимо. Кому-то видимо и в голову не приходит, что раздувание количества файлов в два раза и правка, например, названия и аргументов функции тоже в двух местах- не нужная трата времени.

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

H>То есть противоречия в своем ответе не видишь?
H>Вот именно, что современные IDE позволяют свернуть всю реализацию и видеть лишь интерфейсы.

Нет, не вижу. Код просматриваешь не только в IDE, но и часто онлайн, в том же ГитЛабе или чем-то подобном без поддержки сворачивания/разворачивания.

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

H>Комментарии цветом отфильтровываются мозгом.

Нет уж, или крестик, или штаны. Цвет тебе тоже IDE дает, та самая, которая позволяет рефакторить, разом меняя сигнатуру метода не только в этих 2х файлах, но и во всех других местах, где этот метод используется.

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

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

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

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

H>А где я сказал про «нравится»? Я сказал, что это геморрой. Кому-то и геморрой нравится.

Ладно, сколько времени ждать до того как придет понимание что это геморрой?

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

H>раздувание количества файлов в два раза
От жеж беда какая

H> и правка, например, названия и аргументов функции тоже в двух местах
Как часто ты это делаешь и именно чтобы врукопашную.

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

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

А при неграмотном — как источник мерзких ошибок линкера. Предпочитаю систему, делающую этот вид проблем невозможным.

N>Вот потому их ставят в отдельную секцию и обычно рекомендовано после публичных функций.
В этой части я в какой-то степени с твоим оппонентом согласен. А еще в хидерах шаблоны с имплементацией по сути инлайновые функции...
было бы лучше, если бы при введении этого в С++ попытались бы продумать этот момент.
Например, чего стоят хидер-онли библиотеки. С одной стороны хороши, с другой стороны жуткая жуть.
Но это лажи С++, а не С. С во многих местах сильно продуманнее С++.

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

_>>Вообще то модификатор inline совсем для другого работает. Более того, если ты посмотришь на пример кода по своей же собственной ссылке, то увидишь, что там функция с этим модификатором расположена опять же в h файле. )))
S>Так?

Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы по воздействию на компоновщик, но при этом это воздействие направлено скорее наоборот классическому пониманию инлайна функций. Оно просто позволяет компоновщику не нервничать в том случае, когда он встречает несколько функций с одинаковым именем в разных единицах трансляции (т.е. в том случае, когда компилятор решил не делать инлайн этих функций).

Реальный же инлайн функций, как известно, полностью определяется настройками компилятора, а не какими-то там модификаторами. Но при этом очевидно, что для его хотя бы потенциальной возможности совершенно необходимо наличие в единице трансляции исходного кода функции, которую мы хотим заинлайнить. В случае размещения кода внутри определения класса это выполняется автоматически. А в случае размещения кода функции в cxx файлах (с модификатором inline на случай если компилятор откажется делать реальный инлайн), тебе ради шанса на инлайн придётся скопировать этот код руками в каждый из них, где используется твой класс. Очевидно, что подобную глупость никто и никогда не делает, а всегда размещают такой код один раз, в том же hpp файле, что и определение класса.

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

_>>Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы ...
S>А тут как раз разговор про оформление кода — пользовать inline и размещать реализацию в cpp

от такого применения инлайна толку 0 целых хрен десятых

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

_>>Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы ...
S>А тут как раз разговор про оформление кода — пользовать inline и размещать реализацию в cpp или не пользовать и реализовывать метод сразу в заголовке. Я предпочту inline.

Так я же тебе вроде чётко описал в предыдущем сообщение, что такое использование inline просто не будет делать ничего. И будет гарантировать отсутствие реального инлайна функций.

Ну разве что ты не будешь делать #include этого самого cpp файла, во всех остальные cpp файлы... Вот при такой архитектуре твой подход будет работать... )))

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

_>Так я же тебе вроде чётко описал в предыдущем сообщение, что такое использование inline просто не будет делать ничего. И будет гарантировать отсутствие реального инлайна функций.
Угу, компилятор тупой. Ок.

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

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

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

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

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

vsb>В дельфи похожая система была. А вот в жаве и в языках после неё почему-то не стали продолжать. Мне тоже нравилась такая система. Конечно IDE может показать структуру класса, но мне больше нравился программный текст.

Вот да, в Паскале как раз интерфейсная часть более продуманная, чем комбинация языка (объявления и реализация классов) и препроцессора (#include) в С++. Можно сразу понять, что за класс и чем он занимается. В С# и всех остальных — только если IDE покажет, иначе — самому продираться сквозь код. И если в C# и Java ещё принято классы раскладывать по файлам, то в Rust это зачастую помойка на несколько [десятков] тысяч строк в одном файле.

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

H>>раздувание количества файлов в два раза
CC>От жеж беда какая

Беда. Ну люблю ничего лишнего, когда можно без этого обойтись.

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

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

Сама по себе #include довольно рульная штука, как пример файлизма и текст-процессинга, хотя никто её в этом качестве не любит (

Мне даже в HTML не хватает, когда нужно, допустим, сделать футеры для локального хелпа — без сервера, скриптов, СМС и регистрации.

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

vsb>В дельфи похожая система была. А вот в жаве и в языках после неё почему-то не стали продолжать.

Потому что неудобно. Любые попытки пожертвовать удобством человека ради чистоты концепций постигает одна и та же судьба. Так произошло с предварительными декларациями контрактов, так же произошло с throws в Java.

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

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

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

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

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

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

Либо ты не работал над реальными огромными проектами, а так, демками из книжек баловался. На второй неделе, ага

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

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

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

CC>>Функция-геттер, которая тупо возвращает значение может быть заинлайнена.
S>inline уже deprecated? Ну и вот тут тоже почитай
Когда имплементация затолкана в отдельный с/cpp хоть обвешайся inline, но вне этого c/cpp ничего есессна заинлайнено не будет.
Чтоб хоть как то попытаться это поправить придётся расчехлять PGO а это будет как из Доры по сусликам хреначить. Суслика в итоге может быть и накроет, но вот какой ценой?
Куда проще будет сразу сделать правильно.

CC>>В c/cpp файл есть смысл выносить что то большое.
S>Ну как по мне — либо к умным, либо к красивым. Но без фанатизма
Бессмыслица какая то.

S>Ну я так понял что ты вообще всё хочешь в хидере писать. Видимо неправильно понял.
Да просто капец как неправильно.

CC>>Нет, не положить. Мне важен результат. Я ещё и на сгенерённый код порой смотрю.
S>Ну лично я бы предпочёл пользоваться возможностями языка и делать удобно себе, а не компутеру.


S>Компилятор, ВНЕЗАПНО, может сгенерировать более оптимальный код по умолчанию.
Внезапно, надо таки понимать как используемый инструмент работает.
К примеру вумные люди говорят что бензопилой пилить куда сподручнее если в неё таки залить бензин.
А ещё ловчее выходит если после этого её ещё и завести.

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

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

_>Вообще то модификатор inline совсем для другого работает. Более того, если ты посмотришь на пример кода по своей же собственной ссылке, то увидишь, что там функция с этим модификатором расположена опять же в h файле. )))
Так?

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

_>Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы ...
А тут как раз разговор про оформление кода — пользовать inline и размещать реализацию в cpp или не пользовать и реализовывать метод сразу в заголовке. Я предпочту inline.

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

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

В дельфи похожая система была. А вот в жаве и в языках после неё почему-то не стали продолжать. Мне тоже нравилась такая система. Конечно IDE может показать структуру класса, но мне больше нравился программный текст.

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

H>Вот именно, что современные IDE позволяют свернуть всю реализацию и видеть лишь интерфейсы.

Я так и не смог привыкнуть к этому. Не удобно и все. Уже и расширения разные ставил, чтобы сворачивало по клику — но не оно. Фича вроде заявлена — но для меня она бесполезна. Пока не могу объяснить почему — но просто не удобно.

Кроме того, с h-файлами можно подменить одну реализацию на другую.

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

KP>Нет, не вижу. Код просматриваешь не только в IDE, но и часто онлайн, в том же ГитЛабе или чем-то подобном без поддержки сворачивания/разворачивания.

А вы сворачиванием пользуетесь? Мне оно не удобно почему-то. Даже как-то ставил плагин, который по умолчанию сворачивал все тела методов по клику одной кнопки. Но нет — не то.

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

H>Вот именно, что современные IDE позволяют свернуть всю реализацию и видеть лишь интерфейсы.

Вот, кстати, вы какой плагин используете для удобного сворачивания/разворачивания тела всех методов?

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

S>А вы сворачиванием пользуетесь? Мне оно не удобно почему-то. Даже как-то ставил плагин, который по умолчанию сворачивал все тела методов по клику одной кнопки. Но нет — не то.

Очень редко, ближе к почти никогда. Хотя в Vim даже ставить для этого ничего не надо, и za работает из коробки.

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

KP>Очень редко, ближе к почти никогда. Хотя в Vim даже ставить для этого ничего не надо, и za работает из коробки.

Но тут в чем фишка. Иногда нужно видеть все тела методов закрытыми (когда ты в режиме архитектора). А иногда нужно видеть сразу все открытым — и достает кликать по каждому методу, если они сокрыты по умолчанию.

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

S>можно рассматривать как некий контракт системы, краткая сводка что умеет тот или иной модуль без вникания в детали реализации

Я ничего не понял. Можно примеры?

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

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

KP>>Очень редко, ближе к почти никогда. Хотя в Vim даже ставить для этого ничего не надо, и za работает из коробки.

S>Но тут в чем фишка. Иногда нужно видеть все тела методов закрытыми (когда ты в режиме архитектора). А иногда нужно видеть сразу все открытым — и достает кликать по каждому методу, если они сокрыты по умолчанию.

Студия из коробки позволяет свернуть все и развернуть все. Жаль, по умолчанию развёрнуто. У VisualAssist тоже что-то на эту тему есть.

VSCode — не помню, но тоже должно быть.

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

S>А вы сворачиванием пользуетесь?
Очень иногда.

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

H>Беда. Ну люблю ничего лишнего, когда можно без этого обойтись.
Ну смотря что считать лишним.
Комменты в коде хоть пишешь?

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

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

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

S>А при неграмотном — как источник мерзких ошибок линкера.

Мерзкие ошибки линкера это сообщение типа _Z3abciv не найден, зато есть _Z3abchv? Ну так это вполне себе нормальная ошибка.

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

H>>>Беда. Ну люблю ничего лишнего, когда можно без этого обойтись.
CC>>Ну смотря что считать лишним.
CC>>Комменты в коде хоть пишешь?

H>Комментарии цветом отфильтровываются мозгом.
H>А вот куча приватных полей и функций, которые нифига не интерфейс класса, но забивают h файл — визуально отфильтровать сложнее

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

А вообще это идея: попросить авторов основных IDE дать настройки красить в зависимости от области видимости.
А ещё свёртывать приватную часть.

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

Это когда такое происходит?

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

KP>>Очень редко, ближе к почти никогда. Хотя в Vim даже ставить для этого ничего не надо, и za работает из коробки.

S>Но тут в чем фишка. Иногда нужно видеть все тела методов закрытыми (когда ты в режиме архитектора). А иногда нужно видеть сразу все открытым — и достает кликать по каждому методу, если они сокрыты по умолчанию.

У vim есть полный набор команд "свернуть всё", "развернуть всё"...

N>Мерзкие ошибки линкера это сообщение типа _Z3abciv не найден, зато есть _Z3abchv? Ну так это вполне себе нормальная ошибка.
Эт ерунда, мерзкие, это когда линковать либы нужно в правильном порядке и никак иначе. А пишет он об этом точно также, как и выше.

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

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

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

KP>>Ладно, сколько времени ждать до того как придет понимание что это геморрой?

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

Ну ok, пусть какая-нибудь Java и

public interface Moo {
  int run(int);
}
public class Foo implements Moo {
  @Override
  int run(int);
}
а также Foo2, Foo3, Bar2, Bar3...

ты их все меняешь чтобы принимали и возвращали long — это тоже "в двух местах- не нужная трата времени"?

И таки спрошу — IDE с рефакторингом запретили решением ВЦСПС? (Да, я видел ветку, где вы обсуждаете IDE, но мне вывод таки непонятен.)

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

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

N>Мерзкие ошибки линкера это сообщение типа _Z3abciv не найден, зато есть _Z3abchv? Ну так это вполне себе нормальная ошибка.

Какой-то у вас еврейский линкер!

Я такого вообще не помню, помню два основных типа: 1) имплементация не найдена; 2) имплементация слишком много найдена.

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

Из-за этого вынуждены использовать pimpl. Костыль тот еще

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

N>>Мерзкие ошибки линкера это сообщение типа _Z3abciv не найден, зато есть _Z3abchv? Ну так это вполне себе нормальная ошибка.
V>Эт ерунда, мерзкие, это когда линковать либы нужно в правильном порядке и никак иначе. А пишет он об этом точно также, как и выше.

Это далеко не типовой случай и возникает в случае использования всяких платформенных извращений.

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

Далеко не такой же, естественно. Современные линкеры умеют, как минимум:
1) Объединять идентичные секции (например, случай генерации кода из шаблонов C++).
2) Обеспечивать динамическую подгрузку модулей (Unix и Windows — сильно по-разному).
3) Генерировать код переходников (для динамических вызовов, переходов, не укладывающихся в "короткие" команды процессора, и т.д.)
4) Отрабатывать приоритеты линковки (из каких источников что брать). Сюда же — отрабатывать области видимости отдельных символов.
5) Выполнять LTO оптимизацию, фактически вызывая рекомпиляцию отдельных частей.

И это я ещё не вспомнил специфику динамического (ран-тайм) линкера.

А с другой стороны, что по-вашему могло измениться при соблюдении рамок задачи "создать пригодное для запуска в машинных кодах"? Почему не сравнить с тем, что происходит в JVM или .NET машине, там ведь по факту исполняется такая же роль линкера, но на более высоком уровне?

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

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

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

N>>Мерзкие ошибки линкера это сообщение типа _Z3abciv не найден, зато есть _Z3abchv? Ну так это вполне себе нормальная ошибка.

S>Какой-то у вас еврейский линкер!

Это Unix манглинг имён (хотя я наверняка налажал в суффиксах). Windows эквивалент будет выглядеть примерно как ??R?abc?i@i

S>Я такого вообще не помню, помню два основных типа: 1) имплементация не найдена; 2) имплементация слишком много найдена.

Ну так это как раз ошибки, которые очевидно, как править.

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

S>Мне даже в HTML не хватает, когда нужно, допустим, сделать футеры для локального хелпа — без сервера, скриптов, СМС и регистрации.

iframe — это то, что ты хочешь. Он тяжелый, но это вполне логично, если хочешь без СМС и регистрации.

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

UPDATE: извините, был замучен, криво прочёл. (Там всё немного сложнее, но не к текущей ветке.)

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

S>>Мне даже в HTML не хватает, когда нужно, допустим, сделать футеры для локального хелпа — без сервера, скриптов, СМС и регистрации.

УП>iframe — это то, что ты хочешь. Он тяжелый, но это вполне логично, если хочешь без СМС и регистрации.

Конечно же, нет. Для осознания предлагаю попробовать сверстать футер на фреймах.

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

S>Конечно же, нет. Для осознания предлагаю попробовать сверстать футер на фреймах.

Конечно да. Ты не первый, кто путает iframe и frameset/frame

N>Это далеко не типовой случай и возникает в случае использования всяких платформенных извращений.
Например, при линковке многих интелловских либ. Хотя, я уже год их явно не юзал, может таки навели порядок.

N>Далеко не такой же, естественно. Современные линкеры умеют, как минимум:
N>5) Выполнять LTO оптимизацию, фактически вызывая рекомпиляцию отдельных частей.

Но не умеют развязать порядок линковки, не умет многопоточную (многопроцессную) линковку. Т.е. некие глубинные вещи делаем, но вот те что на поверхности и достали многих — не трогаем.

N>А с другой стороны, что по-вашему могло измениться при соблюдении рамок задачи "создать пригодное для запуска в машинных кодах"? Почему не сравнить с тем, что происходит в JVM или .NET машине, там ведь по факту исполняется такая же роль линкера, но на более высоком уровне?
В этой части я ничего не знаю, посему и не пишу.

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

S>>Конечно же, нет. Для осознания предлагаю попробовать сверстать футер на фреймах.
УП>Конечно да. Ты не первый, кто путает iframe и frameset/frame

Давно iframe научился подставлять текст, чтобы не было ни единого разрыва?

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

vsb> В дельфи похожая система была. А вот в жаве и в языках после неё почему-то не стали продолжать.

Ну в шарпе-то понятно почему — тупо копировали жабу. В результате, читать жабошарповый код без иде это убицца можно. В паскале сделано идеально — декларация отделена от реализации, и при этом они не разнесены по разным файлам. Паскаль — рулеzzz!!!

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

S>Давно iframe научился подставлять текст, чтобы не было ни единого разрыва?

Не текст, а готовый документ html. Всегда умел.

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

N>>Это далеко не типовой случай и возникает в случае использования всяких платформенных извращений.
V>Например, при линковке многих интелловских либ. Хотя, я уже год их явно не юзал, может таки навели порядок.

N>>Далеко не такой же, естественно. Современные линкеры умеют, как минимум:
N>>5) Выполнять LTO оптимизацию, фактически вызывая рекомпиляцию отдельных частей.

V>Но не умеют развязать порядок линковки,

Расшифруй.

V> не умет многопоточную (многопроцессную) линковку.
V>Т.е. некие глубинные вещи делаем, но вот те что на поверхности и достали многих — не трогаем.

Я не знаю, в каком ты мире, но gold и lld уже много лет умеют в нитки, и есть реальное ускорение.
GNU ld не умеет, но он сейчас частично уже образцовая мумия.

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

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

S>>Давно iframe научился подставлять текст, чтобы не было ни единого разрыва?
УП>Не текст, а готовый документ html. Всегда умел.

А надо текст. Повернёт ли дискуссия в столь любимое мной русло: «Нет, на самом деле вам надо не текст, а документ!»?

N>Расшифруй.
Ну выше уже 2 поста обсуждаем. Код есть в либе, но, если она не в том порядке в списке линковки, то линкер ее не найдет. В частности такое с интелловскими либами.

N>Я не знаю, в каком ты мире, но gold и lld уже много лет умеют в нитки, и есть реальное ускорение.
N>GNU ld не умеет, но он сейчас частично уже образцовая мумия.
Тем ни менее основная для юзания в линухах. А подменять ее на что-то поновее без детального знания всего в линухе часто опасно, что линух помрет.

N>С другой стороны, сама задача такая, что параллелить её не очевидно. Подумай над реализацией — там основные места все толком не параллелятся без кардинальных реформ (типа изменения структуры выходных файлов, часто с заметной потерей эффективности хранения).
Задача не простая. Но мы редко решаем простые задачи. Большинство в каких-то своих частях непростые. Но решаемая и уже даже решенная, ты выше указал.

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

S>А надо текст. Повернёт ли дискуссия в столь любимое мной русло: «Нет, на самом деле вам надо не текст, а документ!»?

Нет, не повернет. Я выше написал, что это тяжелый способ, если подумаешь — поймешь почему.

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

H>А вот куча приватных полей и функций, которые нифига не интерфейс класса, но забивают h файл — визуально отфильтровать сложнее
Каша в декларации говорит лишь о том, что качество кода так себе

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

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

V>Например, чего стоят хидер-онли библиотеки. С одной стороны хороши, с другой стороны жуткая жуть.
V>Но это лажи С++, а не С.
С чего бы?

V>С во многих местах сильно продуманнее С++.
Это в каких же?

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

S>>А надо текст. Повернёт ли дискуссия в столь любимое мной русло: «Нет, на самом деле вам надо не текст, а документ!»?

УП>Нет, не повернет. Я выше написал, что это тяжелый способ, если подумаешь — поймешь почему.

Вряд ли. Вряд ли я пойму когда-нибудь, как можно говорить о «тяжести» или «лёгкости» способа, который способом вообще не является. Предлагаю на этом и закончить.

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

CC>Каша в декларации говорит лишь о том, что качество кода так себе

Ну глянь опен-сорсные крутые проекты. Или куча хедеров в начале файла или все хидеры включены в один и подключается ко всему. Зашибись решения
Конечно, говорить о красоте кода и архитерктры в маленьком проекте — это увеличиет ЧСВ говорящего, вот только в реальных больших проектах обычно не так все радужно.

CC>И это тоже плохой знак

Ну, когда вынужден ради функции int GetValue() {return a;} создавать отдельный файл — да, плохой знак.

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

H>>А вот куча приватных полей и функций, которые нифига не интерфейс класса, но забивают h файл — визуально отфильтровать сложнее
CC>Каша в декларации говорит лишь о том, что качество кода так себе

Если все руками, то точно так же руками в Java/C# ты можешь расписать отдельно интерфейсы, и компилятор, кстати, гарантирует что никто не напихает туда приватных полей.

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

vsb>>В дельфи похожая система была. А вот в жаве и в языках после неё почему-то не стали продолжать.

НС>Потому что неудобно.

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

>Любые попытки пожертвовать удобством человека ради чистоты концепций постигает одна и та же судьба. Так произошло с предварительными декларациями контрактов, так же произошло с throws в Java.

Я не согласен, что тут дело в чистоте концепций. Это же просто выделенный в одном месте без ничего лишнего публичный контракт класса. Ничего концептуального там нет. По сути его можно вообще механически генерировать. Или в IDE сделать кнопку "скрыть всё лишнее". Но не сделали.

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

N>>Мерзкие ошибки линкера это сообщение типа _Z3abciv не найден, зато есть _Z3abchv? Ну так это вполне себе нормальная ошибка.
V>Эт ерунда, мерзкие, это когда линковать либы нужно в правильном порядке и никак иначе. А пишет он об этом точно также, как и выше.

Это *nix'овые порядки, MSVC всегда работал нормально

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

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



>>Любые попытки пожертвовать удобством человека ради чистоты концепций постигает одна и та же судьба. Так произошло с предварительными декларациями контрактов, так же произошло с throws в Java.
vsb>Я не согласен, что тут дело в чистоте концепций. Это же просто выделенный в одном месте без ничего лишнего публичный контракт класса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Здравствуйте, 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, и всех местах использования, о которых оно в курсе.

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

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

Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
Смотри, есть две крайности:
1. Всё в одном файле
2. Каждый метод реализуется в отдельном файле.
Ты волен выбирать любой вариант в промежутке между 1 и 2, включая 1 и 2.

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

S>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
На то есть рациональные причины.

S>Смотри, есть две крайности:
S>1. Всё в одном файле
Дык крайности по определению плохо.

S>2. Каждый метод реализуется в отдельном файле.
И сразу теряем на возможности инлайнинга, чтобы вернуть которую надо включать WPO а что по сути является переносом компиляции всего на этап линковки и требует "много нефти" (tm), ибо технически сводится к первой крайности
Этот подход имеет своё применение при написании либ, когда методы большие и надо точно быть уверенным что компилятор не поместит их в один сегмент.

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

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

Про студию я не в курсе, а в CLion в рамках рефакторинга всё это есть.

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

S>>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
CC>На то есть рациональные причины.
Расскажи о них. Лично я вижу только одну: сплошные шаблоны. Да и то настолько всё плохо, что нельзя реализацию шаблонов в отдельном файле написать и включить его в заголовок (да, наоборот).


S>>Смотри, есть две крайности:
S>>1. Всё в одном файле
CC>Дык крайности по определению плохо.
Именно.


S>>2. Каждый метод реализуется в отдельном файле.
CC>И сразу теряем на возможности инлайнинга, чтобы вернуть которую надо включать WPO а что по сути является переносом компиляции всего на этап линковки и требует "много нефти" (tm), ибо технически сводится к первой крайности
CC>Этот подход имеет своё применение при написании либ, когда методы большие и надо точно быть уверенным что компилятор не поместит их в один сегмент.
А тебе ли не положить как оно там компилирует и насколько оно напрягается для компиляции?
Ты уверен что нужно облегчать работу железной голове, жертвуя своим удобством?

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

S>>>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
CC>>На то есть рациональные причины.
S>Расскажи о них.
Да тот же инлайнинг.
Функция-геттер, которая тупо возвращает значение может быть заинлайнена.
В c/cpp файл есть смысл выносить что то большое.

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

S>А тебе ли не положить как оно там компилирует и насколько оно напрягается для компиляции?
Нет, не положить. Мне важен результат. Я ещё и на сгенерённый код порой смотрю.

S>Ты уверен что нужно облегчать работу железной голове, жертвуя своим удобством?
Я уверен что не надо пессимизировать на ровном месте.

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


S>>>>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
CC>>>На то есть рациональные причины.
S>>Расскажи о них.
CC>Да тот же инлайнинг.
CC>Функция-геттер, которая тупо возвращает значение может быть заинлайнена.
inline уже deprecated? Ну и вот тут тоже почитай

CC>В c/cpp файл есть смысл выносить что то большое.
Ну как по мне — либо к умным, либо к красивым. Но без фанатизма

S>>Да и то настолько всё плохо, что нельзя реализацию шаблонов в отдельном файле написать и включить его в заголовок (да, наоборот).
CC>Почему это вдруг нельзя? Или ты тут что то другое имел в виду на самом деле.
Ну я так понял что ты вообще всё хочешь в хидере писать. Видимо неправильно понял.

S>>А тебе ли не положить как оно там компилирует и насколько оно напрягается для компиляции?
CC>Нет, не положить. Мне важен результат. Я ещё и на сгенерённый код порой смотрю.
Ну лично я бы предпочёл пользоваться возможностями языка и делать удобно себе, а не компутеру.

S>>Ты уверен что нужно облегчать работу железной голове, жертвуя своим удобством?
CC>Я уверен что не надо пессимизировать на ровном месте.
Преждевременно оптимизировать тоже не стоит. Компилятор, ВНЕЗАПНО, может сгенерировать более оптимальный код по умолчанию.

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

S>inline уже deprecated? Ну и вот тут тоже почитай

Вообще то модификатор inline совсем для другого работает. Более того, если ты посмотришь на пример кода по своей же собственной ссылке, то увидишь, что там функция с этим модификатором расположена опять же в h файле. )))

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

_>>Так я же тебе вроде чётко описал в предыдущем сообщение, что такое использование inline просто не будет делать ничего. И будет гарантировать отсутствие реального инлайна функций.
S>Угу, компилятор тупой. Ок.

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

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

S>пользовать inline и размещать реализацию в cpp

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

S>>Угу, компилятор тупой. Ок.
PM>Наоборот же, компилятор слишком умный и имеет больше информации, чем программист расставляющий бесполезные inline.

На самом деле в данном случае компилятор действительно тупой, т.к. не может сделать определённые полезные оптимизации без помощи от программиста (в виде размещения нужного кода в hpp файле).

И в принципе эта его тупость вроде как легко излечивается с помощью включения LTO.

Однако на практике это работает только для простеньких проектов: хотел бы я посмотреть на тех, кто попытается собрать например Chromium или Qt с включённой LTO...

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

S>>>Угу, компилятор тупой. Ок.
PM>>Наоборот же, компилятор слишком умный и имеет больше информации, чем программист расставляющий бесполезные inline.

_>На самом деле в данном случае компилятор действительно тупой, т.к. не может сделать определённые полезные оптимизации без помощи от программиста (в виде размещения нужного кода в hpp файле).

А ну в этом смысле да, программисту приходится пока писать код руками, а в C++ так вообще иногда надо выбирать, где ссылку для аргумента функции использовать, где по значению передавать.

_>И в принципе эта его тупость вроде как легко излечивается с помощью включения LTO.

_>Однако на практике это работает только для простеньких проектов: хотел бы я посмотреть на тех, кто попытается собрать например Chromium или Qt с включённой LTO...

Так вроде же в Гугле делали ThinLTO как раз для сборки Хрома, или я что-то путаю?

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

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

Она там есть, просто маскируется. Присмотрись и увидишь

public Interface Foo {}

Class FooImpl implements Foo {}

Вот это повсеместное разделение на Foo и FooImpl это оно и есть.

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

БП>Вот это повсеместное разделение на Foo и FooImpl это оно и есть.

Не отрицаю, но речь была изначально об особых интерфейсных файлах,
типа *.di вместо *.d, *.fsi вместо *.fs. Все это упрощает компиляцию и инкапсуляцию, но не более.
Если функция не экспортируется/импортируется, думаю излишне ложить объявление сигнатуры в отдельный файл.