Intra - альтернатива STL / Boost (3 стр)

HardMorg
> если бы мне нужен был студи  ный проект я бы загенерил его одной кномкой,
> посмотри какой-нибудь опен сорс проект, как там все делают

zlib сойдет за пример? ну или google test?

вообще то это нормальная практика:
из коробки предоставлять разные решения под разные потребности
своих пользователей.

gammaker,
я ещё покамест только присматриваются,
но за natvis уже отдельное спасибо.

сборка Visual Studio 12 Win64, release

замечания по cmake:

замечание по сборке:

Добавил мак как линукс, попытался скомпилить, быстро поправил мелкие недоработки в мэйклистах и коде, но потом реально достали всякие конфликты со стандартной библиотекой типа переопределение, фиговая перегрузка, и тд и тп. Начинается с косячного new.

PS
А ворнинги вообще читались?

PoolAllocator(ArrayRange<byte> buf):
    list(buf, element_size, alignment) {}

AnyPtr Allocate(size_t& bytes, const SourceInfo& sourceInfo)
  {
    (void)sourceInfo;
    INTRA_ASSERT(bytes <= element_size);
    bytes = element_size;
    list.Allocate();
  }

И тестов на этот PoolAllocator нету, ествно.

Kartonagnick
> нигде не использовался параметр CMAKE_BUILD_TYPE
> это означает отсутствие поддержки мульти-конфигурации
> для проектов вижуал студии.
CMake был сделан на скорую руку, позже доделаю как полагается.

Kartonagnick
> Этот файл объекта не определ ет какие-либо ранее неопределенные открытые
> символы, поэтому он не будет использоватьс  никакими операци ми компоновки,
> обращающимис  к этой библиотеке
Какой-то бессмысленный warning. Можно ли его отключить? Ну и в CMake потом добавлю, чтобы в зависимости от платформы и настроек он выкидывал такие пустые файлы.

dpryg
> А ворнинги вообще читались?
Да, и в студии, как ни странно, их нет.

dpryg
> Забыт return.
Вот тут должен был быть варнинг, но почему-то не было. А ведь ещё и работало как-то, когда я проверял...

dpryg
> И тестов на этот PoolAllocator нету, ествно.
Да, я совсем недавно стал писать тесты, поэтому их очень мало - 3 штуки по-моему всего. Но я буду их постепенно дописывать, как и документацию.

dpryg
> В element_size, alignment - мусор.
Сам удивляюсь, как мог такое написать. В общем, спасибо за найденные баги, завтра буду править.

dpryg
> но потом реально достали всякие конфликты со стандартной библиотекой типа
> переопределение, фиговая перегрузка, и тд и тп. Начинается с косячного new.
Да, короче мне изрядно придётся помучаться, чтобы заставить это работать с не MSVC стандартной библиотекой, другими компиляторами и платформами... Займусь этим наверное в выходные. А что с шаблонами, не было ошибок? Внутренних ошибок компиляции не вылезало?

gammaker
Судя по забытым ретурнам предложение должно заканчиваться так:
> Да, короче мне изрядно придётся помучаться, чтобы заставить это работать.

gammaker
> Скорость нужна в тестах производительности заполнения контейнеров, чтобы рандом вносил как можно меньше погрешности.
  Что ж ты тогда сам у себя-то в тестах его не использовал, а сортировал статический массив, заполненный аж целыми 20-ю (!) заранее заданными значениями? Наверное опять чем-то не подошёл, но разве нельзя было для этого ещё один шаблон специально замутить? :)
  Во вторых, чтобы рандом не вносил погрешностей достаточно просто не замерять время заполнения массива. Вот так вот всё просто, оказывается.

Zefick
> Что ж ты тогда сам у себя-то в тестах его не использовал, а сортировал
> статический массив, заполненный аж целыми 20-ю (!) заранее заданными
> значениями?
Это юниттест, там бы всё подошло, но я вот просто так захотел.

Zefick
> Во вторых, чтобы рандом не вносил погрешностей достаточно просто не замерять
> время заполнения массива. Вот так вот всё просто, оказывается.
В тестах скорости заполнения массива без замеров скорости заполнения массива ну никак не обойтись. А вот в остальных тестах я скорость заполнения массива как раз не замеряю.

Тесты производительности запускал кто-нибудь? Как вам логи?

gammaker
> Это юниттест
  Ты кажется чего-то не понимаешь, юнит-тест не надо делать десять миллионов раз на массиве из двадцати элементов, его нужно сделать один раз на массиве из десяти-ста миллионов :)
  А если уж и брать мелкие массивы, то со специальными свойствами, например уже упорядоченный массив, все элементы в обратном порядке и т.д. Собственно суть юнит-тестов и состоит в том, чтобы проверить работу алгоритма на различных наборах данных, включая краевые случаи. Так что у тебя это не юнит-тесты, хоть там и стоит какая-то проверка.
  Ну и так, для справки: Heap Sort и Merge Sort и раньше не были рекордсменами производительности, а сегодня тем более. Про сортировку вставками я уже промолчу.

Zefick
> юнит-тест не надо делать десять миллионов раз на массиве из двадцати элементов
Не помню, чтобы у меня такое было. Это на какой строчке? Я имел в виду INTRA_UNITTEST, где никаких циклов нет, а не то, что идёт ниже.

Zefick
> Собственно суть юнит-тестов и состоит в том, чтобы проверить работу алгоритма
> на различных наборах данных, включая краевые случаи. Но то, что у тебя это не
> юнит-тесты, хоть там и стоит какая-то проверка.
Я пока ещё не до конца проникся идеей тестов, но в общем, всё постепенно будет. Это только самое начало. Это я написал так, между делом, чтобы проверить, что алгоритмы в принципе хоть как-то работают.

Zefick
> Ну и так, для справки: Heap Sort и Merge Sort и раньше не были рекордсменами
> производительности, а сегодня тем более. Про сортировку вставками я уже
> промолчу.
В некоторых частных случаях у них вроде есть свои плюсы. Например многие алгоритмы сортировки сводятся к сортировке вставками, когда остаётся малое количество элементов. До недавнего времени я в сортировках практически не разбирался, и решил реализовать все, чтобы наглядно видеть их производительность и разобраться получше.

Zefick
> Лучше бы ты для них собственный софтварный рендер написал.
Это ещё зачем?

Andrey
> нафиг class ??? это усчтарело пользуйся современным синтаксисом.
В 11 стандарте class предпочтительнее чем typename, а так, это одно и то же. Сам юзаю class ибо короче.

gammaker
> А что с шаблонами, не было ошибок? Внутренних ошибок компиляции не вылезало?
Внутренних не было пока что.
По поводу шаблонов - обрати внимание на http://en.cppreference.com/w/cpp/language/dependent_name (секцию The template disambiguator for dependent names).

gammaker

#if INTRA_PLATFORM_OS==INTRA_PLATFORM_OS_Windows
    struct _stat32 attrib;
    result.Exist = _stat(fn.CStr(), &attrib)==0;
#else
    struct stat attrib;
    result.Exist = stat(fn.CStr(), &attrib)==0;
#endif

size_t bytesRead = fread(data, 1, bytes, (FILE*)hndl);
fwrite(data, 1, bytes, (FILE*)hndl);
#ifdef _MSC_VER
    return ftello64((FILE*)hndl);
#else
    return ftell((FILE*)hndl);
#endif
#ifdef _MSC_VER
    fseeko64((FILE*)hndl, bytes, SEEK_SET);
#else
    fseek((FILE*)hndl, (long)bytes, SEEK_SET);
#endif

  signal(SIGSEGV, on_crash);
  signal(SIGTERM, on_crash);
  signal(SIGILL, on_crash);
  //signal(SIGABRT, on_crash);
  signal(SIGFPE, on_crash);

std::chrono::high_resolution_clock::now()
  auto newHndl = clock();

Andrey
> под windows есть и версия struct stat и функции stat, зачем _stat ? лишний
> макрос. Или варнинги есть?
Не помню, видимо была причина, потому что я делал это именно на винде. Вообще File.cpp я собирался переделать более аккуратно и чисто.

Andrey
> Мона избавиться от FILE* лучше использовать нативную работу с файлами
> CreateFile/ReadFile/SetFilePointer(Windows), open/close/read/write/lseek для
> POSIX
> Ты же вроде за скорость и оптимизацию размера? размер бинарника уменьшиться,
> все-же нативные вызовы на пару процентов быстрее, даже для бинарного чтения
> записи :).
Нативные вызовы не буферизированные. В WinAPI вроде буферизацию можно включить, но я всё равно не уверен, что он будет быстро читать по одному байту.
Придётся сначала сделать буферизацию. Вообще у меня в планах переделать все потоки, сделав так, чтобы они основывались на InputRange. И сделаю специальный BufferedRange, который может строиться поверх любого другого Range и потока. И вот тогда можно будет повыкидывать кучу кода, связанного с потоками.
Вообще я по-максимуму использовал стандартную либу Си как раз для уменьшения бинарника, потому что я динамически линкуюсь со старой CRT, встроенной в винду. Но мне уже разонравился такой подход. Я его конечно оставлю, но планирую перейти на родные функции платформы. Но после того, как переделаю потоки.

Andrey
> Вау! круто.Ну чо работает Access Viloation через SIGSEGV на Windows ?
Да работает. Только трассировка стека при выводе сообщения об ошибке бесполезна - показывает обработчик исключения.

Andrey
> Только не надо говорить что std::set_unexpected это STL, ок ? а то могут такое утверждать.
Не вся стандартная библиотека C++ - STL. К тому же я использую некоторые части стандартной библиотеки как одну из возможных реализаций. Главное, чтобы это можно было упрятать в заголовочный файл. В этом случае всё ок. Но чем это лучше signal, который везде и так работает?

Andrey
> Не хочешь использовать нативную работу с временем для Windows/Posix ?
У меня там разные реализации. Под виндой по умолчанию используется QPC. А что в POSIX?

Andrey
> LoaderKTX.cpp - писал на основе libktx ?
Нет, писал сам по доке какой-то. Уже давно, не помню, что за дока была. И аналогично загрузку DDS писал сам по докам с MSDN.

gammaker
> Но чем это лучше signal, который везде и так работает?
Вообще-то обработка ошибок через сигналы и std::set_unexpected разные вещи, сигнал мало чего информативного может показать в случае той ошибки которую перехватывает std::set_unexpected, или ты не понял функцию std::set_unexpected?
>А что в POSIX?
я же писал clock_gettime/gettimeofday, причем для MacOSX/IOS только gettimeofday, но есть их функция clock_get_time из ядра Mach.

Kartonagnick
А что в googletest? Посмотри как там это красиво все сделано, собрано в одном месте.
Хм... в ридми вообще сказано что это легаси и что активно не поддерживаются и рекомендуеют через смейк.
И разве в репозитории лежат левые бинари?
Вы бы хотя бы посмотрели как там все устроено прежде писать.