Я не считаю удобным использование -D<SOME_OBSCURE_DEFINE> вместо ./configure --with-option=.
Есть еще одна претензия — вместо шелла cmake изобретает свой собственный язык, который я вынужден использовать для написания вариации на тему configure.in:
почему
add_definitions(-D_CRT_SECURE_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE)
удобнее, чем
CFLAGS="$CFLAGS -D_CRT_SECURE_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE"
?
Я с первого взгляда не скажу что делает add_definition, а в случае с CFLAGS очевидней уже некуда.
>Ну откуда система сборки знает, что, например, вы используете функции из библиотеки A,
>а не аналогично обозванные функции из библиотеки Б?
вы ей это скажете, конечно.
человек говорит компьютеру ЧТО делать, это его функция.
>Затем, когда система наткнется на функцию f1, если присутствует #include <h1.h>
сразу нет.
кто из нас делает проект — я или система сборки?
значит, я буду решать что, где и как подключать, а не какой-то магический автомат.
>А как она узнает, куда вы предполагаете скомпилированные файлы разложить?
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
вот вам куча всяких ручек, крутите на здоровье.
>А что делать с условной сборкой, когда у клиента нет библиотеки l1, но она необязательна
проверить наличие, сообщить о присутвии/отсутствии и продолжить сборку.
на все эти вопросы уже давно есть ответы, надо просто уметь их искать, а не изобретать свои системы сборки.
Комментарии приветствуются.
Можно просто собрать и прогнать тесты.
demo на 100000 даёт такой результат:
Running tests
stdlib qsort time: 13593.00 us per iteration
quick sort time: 7162.00 us per iteration
bubble sort time: 16568472.00 us per iteration
merge sort time: 9386.00 us per iteration
binary insertion sort time: 1676846.00 us per iteration
heap sort time: 11884.00 us per iteration
shell sort time: 12984.00 us per iteration
tim sort time: 10967.00 us per iteration
in-place merge sort time: 8215.00 us per iteration < — NB
Ок, вы меня заинтересовали =) Как собрать ваш пример?
Споткнулся на этом:
mmerge.cpp: In function ‘void msort(int*, int)’:
mmerge.cpp:105:15: error: ‘s’ was not declared in this scope
То ли в такого рода шрифтах фантазии разыграться особо негде, то ли до вас кто-то уже использовал keyrus в кач-ве источника вдохновения.
В любом случае, различия между Misc Console и keyrus незначительны:
Есть еще одна претензия — вместо шелла cmake изобретает свой собственный язык, который я вынужден использовать для написания вариации на тему configure.in:
почему
add_definitions(-D_CRT_SECURE_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE)
удобнее, чем
CFLAGS="$CFLAGS -D_CRT_SECURE_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE"
?
Я с первого взгляда не скажу что делает add_definition, а в случае с CFLAGS очевидней уже некуда.
>а не аналогично обозванные функции из библиотеки Б?
вы ей это скажете, конечно.
человек говорит компьютеру ЧТО делать, это его функция.
>Затем, когда система наткнется на функцию f1, если присутствует #include <h1.h>
сразу нет.
кто из нас делает проект — я или система сборки?
значит, я буду решать что, где и как подключать, а не какой-то магический автомат.
>А как она узнает, куда вы предполагаете скомпилированные файлы разложить?
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
вот вам куча всяких ручек, крутите на здоровье.
>А что делать с условной сборкой, когда у клиента нет библиотеки l1, но она необязательна
проверить наличие, сообщить о присутвии/отсутствии и продолжить сборку.
на все эти вопросы уже давно есть ответы, надо просто уметь их искать, а не изобретать свои системы сборки.
Писать руками Makefiles — это Свежая и Оригинальная Идея (tm).
размеры массивов генерятся 1 раз для всех тестов.
результаты тестов тут: pastebin.com/v0PcruiR
Я бы прогнал их на алгоритмах из sort.h чисто любопытства ради.
Комментарии приветствуются.
Можно просто собрать и прогнать тесты.
demo на 100000 даёт такой результат:
Running tests
stdlib qsort time: 13593.00 us per iteration
quick sort time: 7162.00 us per iteration
bubble sort time: 16568472.00 us per iteration
merge sort time: 9386.00 us per iteration
binary insertion sort time: 1676846.00 us per iteration
heap sort time: 11884.00 us per iteration
shell sort time: 12984.00 us per iteration
tim sort time: 10967.00 us per iteration
in-place merge sort time: 8215.00 us per iteration < — NB
(и что написать в копирайте?)
Действительно, на рандомных данных tim sort выходит процентов на 12-15 медленнее, чем этот алгоритм. Любопытно.
Я только не совсем понял — как этот подвид merge sort называется? merge sort with extra memory? А где тут extra memory?
Споткнулся на этом:
mmerge.cpp: In function ‘void msort(int*, int)’:
mmerge.cpp:105:15: error: ‘s’ was not declared in this scope
Правда, никакого Visual Studio — только Linux, только хардкор ©.
Особенно рекомендую попробовать Tim sort.
В любом случае, различия между Misc Console и keyrus незначительны: