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

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>С во многих местах сильно продуманнее С++.
Это в каких же?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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