The review for C++ Timsort in Boost will commence tomorrow, June 3, and continue through June 12. I am the review manager. The code can be found here: https://github.com/boostorg/sort/pull/12 To merge it into a local copy of the Boost.Sort library: git checkout -b ZaMaZaN4iK-feature_branch/TimSort develop git pull https://github.com/ZaMaZaN4iK/sort.git \ feature_branch/TimSort If you want to see a proposed version of the Sort library source with Francisco's changes and Timsort included, download the zip file. Feel free to compare flat_stable_sort with Timsort. Please answer these questions in reply to this thread: What is your evaluation of the Timsort implementation? What is your evaluation of the comments? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? How familiar are you with the details of hybrid and stable sorts? Would you actually use Timsort if it was in Boost.Sort? If so, how is it better than the next best alternative? Do you think Timsort should be included in Boost.Sort? Please ask Alexander Zaitsev any questions you have about Timsort for this review before submitting your final review. Thanks, Steven Ross

Ого. Спасибо!

А вы меня троллем называете. Зря, скоро запилю свою статейку по Красно-Черным деревушкам, и оптимизирую KD, VP Tree свои. Покажу, как уделать и Stl и в целом многих :)

За счёт чего предполагается rb-tree ускорить?

А в stl оптимизирован аллокатор вершин в _xtree?

если ты хочешь изучить с позиции боли и унижения то gtk+ если хочется приложения красивые писать относительно быстро — qt

Народ, ответьте честно, что вам мешает использовать обе технологии?

Народ, ответьте честно, что вам мешает использовать обе технологии?

Если уж так хотите доказать что одно лучше другого. Сделайте каждый программу, что решает ту же задачу, используя свою любимую технологию, и киньте в открытый доступ сравнить.

использовать gtk-based мне лично мешает опыт реализации на нем довольно мелкой фигни, которая была довольно бажной при размере реализации в 500+ строк (и аналогичный функционал адрес бука для КДЕ, который оказался реализован в 50 строк и работал с первого раза)

А это в gtk+ самопальная объектная система на макросах ведь?

она там не вся на макросах, но да, а-ля Q_OBJECT с владением и прочей фигней

Vala например

А я-то что? Это они наркоманию разводят)

СИ не трож

Этот вообще на лиспе пишет, ты что

На си можно написать то же что на крестах но при этом иметь намного больше контроля

На си можно написать то же что на крестах но при этом иметь намного больше контроля

это эмм, бред

Холивары мы конечно устраивать не будем, если вы перестанете в кресто чате при любом удобном случая указать на дзен постить лисп

это эмм, бред

прекрати нести бред

тру ооп действительно больше в смолтоке чам во всем что ты назвал кроме него

тру ооп действительно больше в смолтоке чам во всем что ты назвал кроме него

а действительно интересно, почему же smalltalk "трушнее" остальных языков в плане ооп?

вот опять бред несешь, какое контрактное программирование ты чего

Не знаю, но про сигналы, и что это болше контрактное программирование а не опп, ты не пиши а то как мне банан даст

а действительно интересно, почему же smalltalk "трушнее" остальных языков в плане ооп?

потому что объекты имеют поведение и состояние, и единственный способ изменить их состояние - это попросить их использовать это свое поведение. это смолток, это начало 70-х и никакого с++ тогда не было еще, это базис симулы-67. по факту одно из самых ранних применений ооп.

https://ru.m.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Контракты не ооп

задрал реально

потому что объекты имеют поведение и состояние, и единственный способ изменить их состояние - это попросить их использовать это свое поведение. это смолток, это начало 70-х и никакого с++ тогда не было еще, это базис симулы-67. по факту одно из самых ранних применений ооп.

а действительно интересно, почему же smalltalk "трушнее" остальных языков в плане ооп?

потому что изначально ООП подразумевало отправку сообщений, совсем не в том смысле как в современном мейнстриме, где вызов метода - просто сахарок для всё той же процедурщины по задумке бати ООП - Алана Кея - язык предоставляет действительно рантайм для сообщений, так сделано в смолтоке и обжс, похожие идеи легли в основу модели акторов

семантически, отправка сообщения слабо отличается от вызова метода

семантически, отправка сообщения слабо отличается от вызова метода

семантически, вызов метода ничем не отличается от обычного вызова функции, как в старой доброй процедурщине

семантически, отправка сообщения слабо отличается от вызова метода

семантически, отправка сообщения слабо отличается от вызова метода

и на самом деле, отличается