Мое решение отображает процентную долю архива, который в данный момент распаковывается и записывается. Я использую это, когда записываю образы корневой файловой системы 2 ГБ. Вам действительно нужен индикатор прогресса для этих вещей. Я использую gzip --list
, чтобы получить полный несжатый размер тарбола. Исходя из этого, я вычисляю фактор блокировки, необходимый для разделения файла на 100 частей. Наконец, я печатаю сообщение контрольной точки для каждого блока. Для файла объемом 2 ГБ это дает около 10 МБ блока. Если он слишком велик, вы можете разделить BLOCKING_FACTOR на 10 или 100, но тогда будет сложнее распечатать симпатичный результат в процентах.
Предполагая, что вы используете Bash, вы можете использовать следующую функцию оболочки
untar_progress ()
{
TARBALL=$1
BLOCKING_FACTOR=$(gzip --list ${TARBALL} |
perl -MPOSIX -ane '$.==2 && print ceil $F[1]/50688')
tar --blocking-factor=${BLOCKING_FACTOR} --checkpoint=1 \
--checkpoint-action='ttyout=Wrote %u% \r' -zxf ${TARBALL}
}
Да, C # обычно компилируется намного быстрее. Но не всегда достаточно быстро. Моя самая большая база кода C #, содержащая, возможно, миллион строк кода с большим количеством проектов, скомпилировалась примерно за час. Но я подозреваю, что большая часть этого времени связана с плохой системой сборки визуальных студий. С другой стороны, время компиляции для C ++ обычно намного больше, но оно также намного больше зависит от того, как вы организовываете свой код. Плохая обработка зависимостей файла заголовка может легко увеличить время компиляции на несколько порядков.
C++ is so slow to compile as the header files have to be reread and reparse every time they are included. Due to the way “#defines” work, it is very hard for a compiler to automatically pre-compile all header files. (Modula-2 made a much better job of this) Having 100s of headers read for each C++ file that is compiled is normal on a lot of C++ projects.
Sometimes incremental c++ compiles can be a lot faster than C#. If you have all your C++ header files (and design) in a very good state (see books like Large-Scale C++ Software Design, Effective C++) You can make a change to the implementation of a class that is used by most of the system and only have one dll recompile.
As C# does not have separate header files whenever you change the implantation of a class, all uses of the class get recompiled even if the public interface of the class has not changed. This can be reduced in C# by using “interface based programming” and “dependency injection” etc. But it is still a pain.
However on the whole I find that C# compiles fast enough, but large C++ projects are so slow to compile that I find myself not wanting to add a methods to a “base class” due to the time of the rebuild.
Having lots of Visual Studio projects with a handful of classes in each can slow down C# builds a lot. Combining related projects together and then “trusting” the developers not to use class that are private to a namespace can at times have a great benefit. (nDepends can be used to check for people breaking the rules)
(When trying to speed up C++ compiles I have found FileMon very useful. One project I worked on, the STL was added to a header file and the build got a lot slower. Just adding STL to the precompiled header file made a big difference! Therefore track your build time and investigate when it gets slower)
Насколько я могу судить по собственному опыту, да, C # компилируется намного быстрее, чем проекты C ++. Даже для больших приложений.
Это можно объяснить тем фактом, что C # менее сложен как язык, чем C ++, и что C # переведен на IL (который может быть оптимизирован и переведен позже в машинный код), а C ++ переведен сразу на машинный язык.
Я также заметил, что C # компилируется значительно быстрее, чем C ++. Одна из основных причин - это, конечно, шаблоны, которые не обязательно должны быть в заголовках на C #, так как они отсутствуют. Но интенсивное использование шаблонов (в основном любой современной библиотеки C ++, такой как Boost) убивает время компиляции в C ++.