Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, мыщъх, Вы писали:
N>Интересно, а есть примеры проектов с такой организацией?
да много их. crt любого компилятора (той же студии), хром, лис...
N> По-моему опыту, удобней случаи с функциями, организованными в файлах по общей тематике. N> Например, математические функции в одном файле, работа со строками — в другом,
а в чем удобсто такого подходе? классика жанра при работе со строками -- сначала реализовали простые и тупые функции. страшно тормозные. потом заюзали продвинутые алгоритмы. потом еще более продвинутые. при этом начали постепенно отказываться от тупых функций. если функции были в разных файлах, то мертвый код не компилируется и не попадает в целевой файл. если же все функции в одном файле, нам придется вычищать их руками, при этом кое-где они все-таки могут использоваться. скажем, в тестах.
N>В чём удобство такой организации?
1) компилятор транслирует весь файл целиком и линкер не в состоянии "выковыривать" оттуда реально используемые функции;
2) если у нас есть только один файл, то в общем случае мы нагружаем только одно ядро ЦП (большинство компиляторов однопоточные), а вот множество файлов могут транслироваться параллельно;
3) при изменении большого файла компилятор вынужден транслировать кучу кода, который не был изменен, но компилятор об этом не знает;
N>Во-первых, можно быстро, без документации узнать что есть в библиотеке, найти функцию, о которой даже и не думал.
посмотрите как устроены штатные библиотеки компилятора. там все-таки каждая функция задвинута в свой файл. после трансляции эти файлы заворачиваются в один библиотечный файл, т.к. множество мелких файов это плохо для любой фс.
> А так: заглянул, увидел, применил.
заглянул это как? сценарий "один файл на одну функцию" -- посмотрели на имена файлов и поняли какие функции у нас есть. а так нужно парсить исходный файл.
N>Во-вторых, меньше инклудов писать руками.
как раз инклуды могут вкючать в себя другие инклуды. это не проблема
N>И, в-третьих, уже лично для меня: не надо запоминать кучу сущностей. Помнить про один файл легче, чем про 10 или 20.
вы все-таки посмотрите на сорцы того же ms vc crt.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
М>1) компилятор транслирует весь файл целиком и линкер не в состоянии "выковыривать" оттуда реально используемые функции;
Это не так. Можно сказать компилятору класть каждую функцию в свою секцию. И тогда линкер прекрасно может выбросить любую неиспользуемую функцию. Знаю несколько компиляторов это поддерживающих, и GCC среди них (-ffunction-sections). Правда иногда за это приходится платить более длинными вызовами (напривер в АРМ с -mlong-calls)
Здравствуйте, gardener, Вы писали:
М>>1) компилятор транслирует весь файл целиком и линкер не в состоянии "выковыривать" оттуда реально используемые функции;
G> Это не так. Можно сказать компилятору класть каждую функцию в свою секцию. G> И тогда линкер прекрасно может выбросить любую неиспользуемую функцию.
если ставить целью опровергунть мое высказывание, то еще глобальную оптимизацию кода можно вспомнить. но это частный случай. а в общем -- намного удобнее иметь библиотеку, созданную библиотекорем из кучи объектных файлов.
это удобнее хотя бы уже потому, что парадигма "одна функция — один файл" сильно упрощает повторное использование кода и включение его в другой проект.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>это удобнее хотя бы уже потому, что парадигма "одна функция — один файл" сильно упрощает повторное использование кода и включение его в другой проект.
Можно подумать, C запрещает косвенную рекурсию между функциями, описанными в разных файлах.
(...Ах да, это ж C... поправляюсь: при условии, что для f.c и g.c существуют f.h и g.h, включаемые в оба .c. Господи, я уже и забыл за давностию лет, как это удобно — заголовочные файлы! Теперь можно не по одному, а по целых два файла на функцию сделать! А если ещё и препроцессор с преподвыпертом заюзать!.. Впрочем, я отвлёкся.)
А если не запрещает, то никакого преимущества для повторной используемости это не даст: спагетти можно забабахать точно такое же что в одном файле, что в тысяче.
Кстати, хотел спросить. Часто обнаруживаю, что на озоне нет тех книг которые я хотел бы прочесть.
К примеру Таненбаума(ОС: разработка и реализация) и вот этих тоже нет. Есть ли достойная альтернатива озону(хочется в русском переводе почитать)?
Здравствуйте, -n1l-, Вы писали:
N>Кстати, хотел спросить. Часто обнаруживаю, что на озоне нет тех книг которые я хотел бы прочесть. N>К примеру Таненбаума(ОС: разработка и реализация) и вот этих тоже нет. Есть ли достойная альтернатива озону(хочется в русском переводе почитать)?
Можно смотреть my-shop и Лабиринт.
Там частенько бывает, если на озоне нет.
Можно в магазины конкретных издательств ткнуться. Например, Питер имеет собственный магазин — там, кстати, можно Таненбаума поискать.
Еще полезно в букинистический alib.ru ходить — там даже новые книги можно иногда обнаружить.
Хороший магазин urss.ru — там часто бывают научные книги, которых больше нигде нет.
И старые программистские — тоже.
Еще на Озоне можно оставить заявку на ожидание.
Когда книжка появится — вас известят.
Если заявок много — озон как-то решает этот вопрос, книжка обычно появляется.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, -n1l-, Вы писали:
N>>Кстати, хотел спросить. Часто обнаруживаю, что на озоне нет тех книг которые я хотел бы прочесть. N>>К примеру Таненбаума(ОС: разработка и реализация) и вот этих тоже нет. Есть ли достойная альтернатива озону(хочется в русском переводе почитать)? LVV>Можно смотреть my-shop и Лабиринт. LVV>Там частенько бывает, если на озоне нет. LVV>Можно в магазины конкретных издательств ткнуться. Например, Питер имеет собственный магазин — там, кстати, можно Таненбаума поискать. LVV>Еще полезно в букинистический alib.ru ходить — там даже новые книги можно иногда обнаружить. LVV>Хороший магазин urss.ru — там часто бывают научные книги, которых больше нигде нет. LVV>И старые программистские — тоже.
Спасибо огромное.
LVV>Еще на Озоне можно оставить заявку на ожидание. LVV>Когда книжка появится — вас известят. LVV>Если заявок много — озон как-то решает этот вопрос, книжка обычно появляется.
Да в курсе, только либо у них е-мэйл оповещения нет, либо я просто не успеваю купить. Помню зашел просто так на сайт, а там оповещения о том что книги есть, зашел на страницу покупки, а книг уже нема.
Я не ставил показать целью что удобнее, а что нет. Я просто указал что один из доводов как минимум имеет ограниченую область.
Выше в треде прозвучало SQLite распространяется как один файл. Я не думаю что это сильно связано с удобством компиляции. Скорее всего это из-за того, что более эффективный код генерируется — например за счет того что компилятор может агрессивно инлайнить (в моей практике link time optimizations это скорее пока экзотика), за счет того что на этапе генерации кода уже известны многие расстояния для джампов и соответственно можно использовать короткие переходы.Кстати где-то встречал компилировали насколько я помню что-то из KDE как один файл и получали более быструю систему.
Я бы сказал что одна функция на файл это не правило. Зависит. Баланс бежду удобствами и эффективностью.
G>Выше в треде прозвучало SQLite распространяется как один файл.
вот что пишут сами разработчики: http://www.sqlite.org/amalgamation.html
The core SQLite library consists of 100 files of C code (as of Version 3.8.6) in the core with 14 additional files in the FTS3 and RTREE extensions. Most of these are "source" files in the sense that they are stored in the configuration management system and are maintained directly. But 6 of the core C files are generated automatically using scripts or auxiliary programs during the compilation process. Of the 100 core files, 71 are C code and 29 are C header files.
...
We have measured performance improvements of between 5 and 10% when we use the amalgamation to compile SQLite rather than individual source files. The downside of this is that the additional optimizations often take the form of function inlining which tends to make the size of the resulting binary image larger.
кроме того надо понимать, что SQLite это "одна сущность". если же мы пишем... ну, скажем, криптобиблиотеку, то там будет набор несвязанных или слабосвязанных криптофункций. смысл держать их в одном файле?
G> Я бы сказал что одна функция на файл это не правило. Зависит. Баланс бежду удобствами и эффективностью.
о чем и речь. если я хочу заюзать чужой код, то в одном случае выберу самую быструю библиотеку из всех, чтобы рвать конкурентов, а в другом — ту, которая не требует тащить ничего лишнего в проект.
я просто поделился своими наблюдениями. что хороший код (хром, например) имеет высокую степень дробления на файлы. SQLite я не собирал, так что ничего за него не скажу. но вот лис под виртуалкой собирается по принципу — запустил и лег спать. утром проснулся и обнаружил ошибку. мммать! во всяком случае первая сборка это очень долго. потом намного быстрее. а с учетом того, что на выходе у нас далеко не один исполняемый файл, то можно вносить изменения и тут же видеть результат. экономит кучу времени.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
5-10% — это реально много. У меня выходило на нашем проекте пара процентов и все. Ну там правда все и так было прилично сгруппиовано и вынесено в инлайн хедера где надо.
Насчет времени компиляции тоже по разному. У меня компилятор на каждый запуск/файл ходил по VPN через океан за лицензией. Если много мелких файлов — то не дождешься пока проект закончится собираться.
Здравствуйте, andyag, Вы писали:
A>Это вы очень хорошо написали. Вещи очевидные, но интересно, что в явном виде обычно об этом не пишут. Я бы даже немного обобщил: у любого программиста есть какое-то количество ресурсов, которые ему при "занятиях работой" нужно раскидать по примерно такому списку направлений:
A>1. Понимание задачи (чтение, коммуникации, анализ, "постановка для себя", риски, гуглинг) A>2. Выдумывание решения (понимание "достаточно хорошего решения", риски, самокритика, эксперименты, поиск готовых решений, гуглинг, релевантный опыт) A>3. Решение задачи (написание кода, самокритика, рефакторинг, тестирование, релевантный опыт)
Очень интересно — как увеличивать свой ресурс. Вы можете конкретизировать, что понимаете под "ресурсом" программиста?
Здравствуйте, kleng, Вы писали: K>В курсе. Но каждый добавочный файл — это нехилые накладные расходы, даже если он не компилируется, а только линкуется.
+1. Ещё хочу отметить, что make, чтобы не компилировать файл, вынужден проверять его last modify timestamp.
То есть, предположим, у нас был один файл размером в 64 килобайта. Его компиляция — это два обращения на чтение — одно в MFT, второе — за данными (понятно, что контроллер диска читает данные экстентами). Мы порезали его на 70 мелких файлов (1 файл: 1 функция). Теперь его компиляция — это 70 чтений с диска (т.к. у нас нет гарантии последовательного размещения записей этих файлов в MFT). Причём это 70 чтений независимо от того, нужно ли реально перекомпилировать каждый из этих файлов — с их размерами у них есть отличный шанс целиком попасть в MFT, и мы вообще ничего не экономим. То есть на самом деле нам нужно ещё 70 обращений, чтобы проверить дату результата компиляции.
То есть в полном варианте мы говорим о:
— 1 чтение метаданных large.obj
— 1 чтение метаданных large.с
— 1 чтение данных large.c
— 1 запись данных large.obj
— 1 запись метаданных large.obj
против (предполагаем мелкое изменение ровно в одной функции):
— 70 чтений метаданных smallxxx.obj
— 70 чтений метаданных smallxxx.с
— 1 (либо даже 0, если файл маленький) чтение данных small035.c
— 1 запись данных small035.obj
— 1 запись метаданных small035.obj
итого, затраты на IO — 5:143. То есть make мелких файлов продул в 29 раз.
Понятно, что в реальности всё это скорее всего берётся из кэша; тем не менее, сборка больших мелкогранулярных проектов часто упирается в поиск изменений — стоимость сканирования директорий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, taichiman, Вы писали:
T>Здравствуйте, andyag, Вы писали:
A>>Это вы очень хорошо написали. Вещи очевидные, но интересно, что в явном виде обычно об этом не пишут. Я бы даже немного обобщил: у любого программиста есть какое-то количество ресурсов, которые ему при "занятиях работой" нужно раскидать по примерно такому списку направлений:
A>>1. Понимание задачи (чтение, коммуникации, анализ, "постановка для себя", риски, гуглинг) A>>2. Выдумывание решения (понимание "достаточно хорошего решения", риски, самокритика, эксперименты, поиск готовых решений, гуглинг, релевантный опыт) A>>3. Решение задачи (написание кода, самокритика, рефакторинг, тестирование, релевантный опыт)
T>Очень интересно — как увеличивать свой ресурс. Вы можете конкретизировать, что понимаете под "ресурсом" программиста?
Ресурс — это количество действий, которое программист может сделать за 1 рабочий день (или месяц), таких что каждое действие будет увеличивать прогресс по текущим задачам.
Определение какое-то не очень, но вот пример:
1. Джуниор делает 20 попыток поиска в гугле и только последняя попытка приводит к желаемому результату. Сделал "1 действие", потратил на это 10 минут.
2. Сеньор делает 2 попытки поиска в гугле, вторая попытка приводит к желаемому результату. Сделал "1 действие", потратил на это 1 минуту.
Если глупо проэкстраполировать, получается, что у сеньора ресурс в 10 раз больше, чем у джуниора. И объясняется это не тем, что он быстрее заходит в гугл или запросы быстрее вводит. Объясняется это тем, что он просто "лучше умеет искать" — он знает какие запросы писать бесполезно, а какие с большой вероятностью первой же ссылкой выдадут именно то, что нужно.
И тут, возвращаясь к "как увеличивать свой ресурс" — ответ очень простой: "нужно больше опыта". А "опыт" в свою очередь это просто способность быстро отличать движение в правильную сторону от движения не туда. Вот примеры:
1. Если есть минимальные сомнения по поводу постановки задачи, лучше обсудить это с автором задачи, а не пытаться угадать. (Хак: а ещё можно быть тем самым "автором задачи")
2. Если есть есть ощущение, что задача "не нужна", лучше сначала попытаться убедить автора, что она не нужна. (Хак: как обычно, лучше самому быть автором и не заводить такие тикеты)
3. Если есть 2 более-менее одинаковых библиотеки А и Б, при этом с Б опыта нет, лучше использовать А. (Хак: а ещё можно просто заранее иметь опыт с Б)
4. Если есть необходимость изучить что-то новое, нужно честно потратить N времени, чтобы понять масштаб, изучить то, что кажется понятным, а потом оценить сколько непонятного остаётся (Хак: а ещё можно этим заниматься дома, чтобы потом требовать на работе повышение зарплаты с аргументом "смотрите как хорошо я работаю благодаря обширным знаниям")
5. Если есть понимание, что "не справлюсь с задачей", лучше сообщить об этом как можно раньше, чем раз в неделю говорить "нужна ещё неделя" (Хак: можно сначала громко сказать, что задача очень сложная, а потом поднапрячься по 16 часов в день, и решить её — это позволит громко сказать "я решил очень сложную задачу, где моя премия?". Особенно хорошо работает, если задача не только сложная, но и важная для бизнеса.)
Все эти примеры более-менее очевидны и вроде как все о них знают, но на практике почему-то работают совсем не так, предпочитая собрать это всё в виде шишек. И вот после тысяч таких шишек появляется "достаточно хороший программист"
Здравствуйте, andyag, Вы писали:
A>Ресурс — это количество действий, которое программист может сделать за 1 рабочий день (или месяц), таких что каждое действие будет увеличивать прогресс по текущим задачам.
Ресурс это не количество действий, это время и мозг.
