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

gammaker
> К сожалению, только я.
Можешь тогда прорекламировать ее как-нибудь. Посоздавать на программерских сайтах темы. Лучше конечно на заморских сайтах, там и в код глянут хотя бы, может и даже попробуют скомпилировать лол.

romgerman
> Лучше конечно на заморских сайтах, там и в код глянут хотя бы, может и даже
> попробуют скомпилировать лол.
По идее перед тем, как идти к заморским, надо ещё комментарии на английский перевести. Да и вообще документацию сделать бы сначала. Боюсь у меня только одна попытка. А то посмотрят один раз, а второй уже не будут смотреть. А так может наличие тестов и документации их зацепит.
Сейчас вот доделаю свой генератор текстур и наверное всё-таки займусь снова либой. Но на этот раз не функционалом, а её продвижением: буду doxygen комментарии дописывать и заодно английскую их версию писать. Надо сделать отдельный сайт под библиотеку, и выложить на него будущую документацию.

romgerman
> Можешь тогда прорекламировать ее как-нибудь. Посоздавать на программерских
> сайтах темы. Лучше конечно на заморских сайтах, там и в код глянут хотя бы,
> может и даже попробуют скомпилировать лол.
Давать ложные надежды нехорошо.

-Eugene-
> Давать ложные надежды нехорошо.
Почему ложные? Если это заинтересует людей, то и у меня мотивация поднимется всё это поскорее доделать. В принципе фич уже довольно много. Остро не хватает только тестов и документации. Ну и рекламы тоже, чтобы кто-то про мою библиотеку вообще узнал.

gammaker
> Почему ложные?
Потому что один человек при всем желании не сможет вложить в свою библиотеку те века трудового времени, которые уже вложены в существующие библиотеки.

-Eugene-
> Давать ложные надежды нехорошо
Ну почему ложные, это у нас только любят обосрать и послать, а там часто вижу проявление интереса и помощи.

-Eugene-
> Потому что один человек при всем желании не сможет вложить в свою библиотеку те
> века трудового времени, которые уже вложены в существующие библиотеки.
Ну так пусть присоединяются, я буду только рад. Будет уже не один человек.

-Eugene-
> Потому что один человек при всем желании не сможет вложить в свою библиотеку те
> века трудового времени, которые уже вложены в существующие библиотеки.
  Тем не менее один человек не сможет так испортить STL как это сделал коллектив разработчиков.

В природе также давно имеется альтернатива STL-у от Electronic Arts >> https://github.com/electronicarts/EASTL
Прямо там же в сборке есть Бенчмарк, у меня вышли такие цифры >> https://pastebin.com/NzdhJijq
Интересен сравнительный тест Intra с EASTL.

Бабер согласен STL - это антипаттерн!
И это подтверждается тормознутостью, избыточностью исходного кода, сложностью процесса отладки при выявлении багов в объектах, лежащих в том же std::vector<T>.
Вот даже сходу про них >> https://sourcemaking.com/antipatterns/design-by-committee

Кстати основные часто используемые всеми нами контейнеры - лаконично и добротно реализованы в далеких 90ых годах аж.
Borland Turbo C++ >> https://thepiratebay.org/search/Borland%20Turbo%20C%2B%2B

А так вообще подсматриваю реализацию необходимого контейнера, создаю свою понятную облегченную версию БЕЗ дефайнов, БЕЗ итераторов и множественного наследования.
Допустим применительно к динамическому массиву как вектор.
https://github.com/Redee/ReJewel/blob/master/src/Tools.h#L7

Redee
> В природе также давно имеется альтернатива STL-у от Electronic Arts >>
> https://github.com/electronicarts/EASTL
Всё равно дизайн как у STL. Разве что исходники читабельные и больше ориентирована на производительность.

Redee
> Интересен сравнительный тест Intra с EASTL.
Если я это поставлю в очередь своих планов на проекты, до этого дело дойдёт не раньше, чем через 2-3 года. Но если кто-то другой сделает, буду только рад, самому интересно.

Redee
> И это подтверждается тормознутостью, избыточностью исходного кода, сложностью
> процесса отладки при выявлении багов в объектах
Насчёт тормознутости вектора не уверен. В дебаге да, тормозит до безобразия, а в релизе вся эта избыточность инлайнится и многие тесты вполне сравнимы с моей Intra. Иногда опережают её, но чаще немного отстают. Вот добавление в начало массива у меня быстро, потому что принципиально другой алгоритм - такой же, как добавление в конец.
Что самое немыслимо тормозное и унылое в стандартной библиотеке C++, так это iostream. Но это уже считается не STL.

Redee
> Вот даже сходу про них >>
> https://sourcemaking.com/antipatterns/design-by-committee
Не нашёл там ничего про них.

Redee
> Допустим применительно к динамическому массиву как вектор.
> https://github.com/Redee/ReJewel/blob/master/src/Tools.h#L7
Это чем-то похоже на самую первую версию динамического массива, которую создавал я когда-то очень-очень давно.
Без Reserve достаточного объёма будет реаллокация при добавлении каждого элемента - тормоза жуткие. Обычно увеличивают Capacity в 1.5 - 2 раза.
Эта реализация при Reserve конструирует все объекты, что довольно странно. Объекты ещё не добавили, но конструкторы по умолчанию уже вызваны. Отсюда также следует, что объекты без конструктора по умолчанию в такой массив класть нельзя. Обычно память выделяют другим способом, который не вызывает конструкторы (operator new(size) или malloc) используют размещающий new, который вызывает конструктор для добавляемого объекта.
Ещё странно, что при копировании массива capacity тоже копируется. Зачем лишнюю память выделять, если она может не пригодиться?
Не говоря уже о том, что нет никакой безопасности с точки зрения исключений. Если при присваивании вылетит исключение, то память останется не освобождённой. Но я и сейчас не уверен, что у меня в Intra всё в этом плане безопасно, особо не проверял код на счёт этого.

А ещё глянул на
>class Shared_Ptr
От этого

T* _ptr = 0;
Dy_Array<Shared_Ptr<T>*> _refs;
Dy_Array<Shared_Ptr<T>*>* _pt_Refs = &_refs;
int _acc_Ind = 0;

чуть глаза не вытекли. Это жеж 6-кратный оверхед на указатели! При этом в многопоточности такой указатель работать не будет без мьютексов, а на атомиках такой код вообще не переписать.

Лучше уж всё-таки использовать std::vector и std::shared_ptr, чем такое.

Дада - я НЕ претендую на "последнюю инстанцию" и вполне хорошо отношусь к аргументированной критике )).

Про то что STL походу делало много человек и много согласований лишних было, код, понимание, документация усложнялись и как следствие вылез анти-паттерн у них - "design by committee".

Intra это полумеры.
Полная мера - C#

iperov
> Intra это полумеры.
> Полная мера - C#
Intra имеет много разных фишек, удобств и кастомизируемости, которые C# даже и не снились.
Обратное тоже верно - в C# куча всего того, что я пока не успел реализовать.
Ну и вообще у каждого инструмента есть свои преимущества и недостатки.
У C++ есть уникальный набор преимуществ, таких как высокая производительность и близость к железу. При этом благодаря шаблонам у него есть огромный потенциал в плане расширяемости, которого нет ни в одном из существующих популярных языков. Если раскрыть этот потенциал, многие преимущества из других языков можно реализовать в библиотеке, сделав C++ наиболее мощным языком из существующих. Intra пока только в середине этого пути.
А вот C#, JVM языки и уж тем более интерпретируемые языки никакими библиотеками сделать быстрыми не получится.
Go нативный, быстрый и у него очень интересная асинхронность и инфраструктура, но без шаблонов иногда приходится копипастить код, или просто писать много кода там, где можно было обойтись одной строчкой в Intra C++.

Так что "полной меры" не существует, но когда-нибудь к ней сможет приблизиться Intra.

ну я был ярым фанатом С++ вообще, пока не начал изучать другие языки. Теперь я не хочу возвращаться в эту грязь.

Довольно странно, boost написан читаемо, но заходишь в header stl и просто охреневаешь.