Сообщение от
Reobne
Странно, я-же просто просил объяснить мне кое что, помочь понять, а в ответ получаю нечто непонятное мне, смахивающее на оправдания.
Reobne, перед нами - типичный случай за "умной" формулировкой замылить смысл происходящего. Мне тоже не нравится, что разговор ушёл в область каких-то абстрактных сопоставлений без детальных наглядных примеров, что я и хочу попытаться исправить.
- Круглые колёса. Исходники любого содержания, хоть большие, хоть маленькие, хоть с инклюдами, хоть без, хоть со static'ами - всё едино - "умная линковка" из коробки, всё оно так и должно быть. В "правильных" компиляторах всё оно так и есть. Но в "неправильных", куда отнесём и SDCC, ВСЕ сущности из одного исходника попадают в один сегмент (*.rel) библиотеки и если использовать хоть ОДНУ сущность из этого сегмента - потянутся все остальные. Лечится распихиванием различных сущностей по разным исходникам. Остаётся проблема многократного запуска SDCC с его инфраструктурой, многократного парсинга инклюдов - она никуда не делась.
- Квадратные колёса (по методу Q-Master). Делаем "резку" цельного исходника "в уме" с помощью препроцессора и #ifdef'ов, как я показал выше. Многократный запуск SDCC и проблема многократной обработки в исходнике инклюдов и static'ов никуда не делась, как бы её ни забалтывали:
Код:
#include "MyIncl.h"
#ifdef _ABC_1
void ABC_1 (void) {
}
#endif
#ifdef _ABC_2
void ABC_2 (void) {
}
#endif
Пусть нам Q-Master пояснит, как он предлагает компилить "в памяти" такую библиотеку с единоразовым запуском компилятора и единоразовой обработкой инклюда. С примерами объяснит и подробно. - Треугольные колёса (smartlib) - та же самая резка, но без #ifdef'ов, а с помощью "линии заголовка" и "линий разреза". При этом вменяемые этому способу проблемы с многократной обработкой инклюдов и static'ами точно и ровно также присутствуют и в "квадратном" варианте колёс.
Разумеется, я за правильные круглые колёса, только не вижу как в таком сообществе добиваться поставленных целей. Либо всё делать одному и выслушивать, что асм Z80 круче всего на свете, либо забить, выбирайте.
---------- Post added at 15:38 ---------- Previous post was at 15:15 ----------
Сообщение от
Q-Master
в твоем случае 1 физический файл разрезается на 100500 кусков, а в моем случае компилятор просто ВЫКИДЫВАЕТ из текста ненужное и ничего никуда не режет.
PS: Можно мне пример исходников библиотеки в твоем исполнении, чтобы я таки понял за дело мы спорим или нет?
Давал уже, но отчего же, извольте.
Код:
#include "MyIncl.h" // Здесь то, что надо включать многократно,
// т.е. нужное ВСЕМ кускам.
// Секция заголовка может быть и ПУСТОЙ, т.е. не включать в себя ничего.
// Также она может просто отсутствовать - результат тот же.
/*================================== Header ==================================*/
#include "MyAbc1.h" // А вот здесь можно поместить нужное только ЭТОМУ куску
void ABC_1 (void) {
}
/*--------------------------------- Cut here ---------------------------------*/
#include "MyAbc2.h"
void ABC_2 (void) {
}
Как видим, присутствует возможность гибко выбирать какие инклюды включать многократно, какие однократно. Линии разреза наглядны. Фразы "Header" и "Cut here" могут быть убраны, решает только присутствие в комменте определённого количества идущих подряд "===" или "---". Т.е. ничем не хуже, а то и нагляднее вашего способа. А разрезанные файлы ОС кэширует (все мы знаем, что поиск во второй раз происходит во много раз быстрее, чем в первый), так что проблем со скоростью трансляции вообще нет.
Но вы лучше расскажите нам как компилить по вашему способу: во-первых "всё в памяти", а во-вторых - единократным вызовом компилятора (а может ещё и библиотекаря? 
), ибо только это мы можем считать твёрдым достоинством квадратных колёс и преимущества их над треугольными.
Ответить с цитированием