«Я не пишу на С», «Я не знаком с миром микроконтроллеров», " скачки по указателям, которые мажут мимо кэша" может тебе не стоит пытаться обсуждать вещи, в которых ты не разбираешься?
Пока в качестве мануалов только примеры и комментарии по исходникам. В планах подровнять комментарии для Doxygen, и получить подобную Gtk документацию есть.
По списку виджетов есть еще option_box, scrollbar, progressbar, аналог TImageButton, menu в двух вариантах, file_browser, tree_list, frame.
Для С-- есть дополнительно 14шт уникальных виджетов, хотя некоторые из них дублируют уже имеющиеся, но они с 3D или плоским дизайном. В области разработки библиотек всегда требуются добровольцы ;-)
Степень совместимости tcc и gcc по компилируемому исходному коду очень хорошая (им даже на пробу скорости компилировалось ядро linux), а из отличий AFAIK неполная поддержка всех возможностей __asm__ и некоторых других директив. В Колибри есть ffmpeg 2.8, собранный gcc. Так что шанс собрать есть и с помощью TinyC, но не уверен что это хорошая идея — использовать для вычислительных задач неоптимизирующий компилятор.
На самом деле, перекомпилировать не нужно. Это же Си — обычные константы!
Просто новые Визиторы должны видеть дополненный enum.
Вот интересно скорость сравнить — мой вариант сравнить с табличкой производительности.
Ассемблерный код switch я уже посмотрел — 2 инструкции сравнения )
А, действительно. Но как пишет Александреску — это самый неудачный паттерн, потому редко используемый.
В вашем примере в итоге весь выигрыш из-за неудачной реализации dynamic_cast, который вы с помощью 3х листов исходного кода, с блекджеком и шаблонами реализуете руками с помощью map<>.
На мой взгляд, не нужно множить сущности, http://ideone.com/K0KQhk вот реализация проще, расширяемая и более эффективная, т.к switch() отлично оптимизируется компилятором
Непонятно, зачем нужен dynamic_cast<geometry_visitor*>(&obj)) в типичной реализации, если obj.visit() — виртуальный? Соответственно, вызов виртуального метода быстрее, чем RTTI.
Ну и тогда проблемы, которая решается в статье, нет вообще.
Вообще то статья не о качестве исходного кода, а об оптимизации.
STL наоборот, дает еще преимущества отсутствия необходимости работы с указателями и дает некоторую защиту от выхода за рейнж при отладке.
Зачем оптимизировать метод Гаусса компилятором или пытаться прикрутить к нему STL, если есть гораздо более эффективные _алгоритмы_? Неудачный пример, но не надо конечно везде совать шаблоны, согласен.
Статически или на стеке — для скорости работы не важно. Но невозможно для компилятора создать объект неизвестного заранее размера с фиксированным адресом. Да и не нужно.
Пример стекового аллокатора я привел, как оптимизация в плане исключения запросов выделения памяти ОС.
Если вкратце, то стоит просто посмотреть, в какой машинный код превращается программа с использованием STL при компиляции с разной степенью оптимизации. Тогда можно начинать спорить.
Смотреть после опытов
Как ни странно, но STL-шаблоны бывают эффективнее С-кода. И можно сделать кастомный аллокатор на стеке, если смущает куча.
В общем понятно, что Вы, с помощью некоторой ловкости рук, хотите объявить несостоятельным формат IEEE754 и предложить свою модификацию или даже новейшую разработку.
Будет интересно посмотреть.
Я недавно столкнулся с задачей реализовать стандартный набор С-функций math.h на ассемблере. В процессе чего выяснилось — что набор инструкций, удобный процессору, во многом перпендикулярен привычным человеку математическим функциям.
Соответственно, разрабатывая новый формат, Вам нужно спроектировать к нему и набор инструкций, эффективно с ним работающий.
Хотя, если попытки были давно, можно что конкретное поиском по форуму
По списку виджетов есть еще option_box, scrollbar, progressbar, аналог TImageButton, menu в двух вариантах, file_browser, tree_list, frame.
Для С-- есть дополнительно 14шт уникальных виджетов, хотя некоторые из них дублируют уже имеющиеся, но они с 3D или плоским дизайном. В области разработки библиотек всегда требуются добровольцы ;-)
Просто новые Визиторы должны видеть дополненный enum.
Вот интересно скорость сравнить — мой вариант сравнить с табличкой производительности.
Ассемблерный код switch я уже посмотрел — 2 инструкции сравнения )
В вашем примере в итоге весь выигрыш из-за неудачной реализации dynamic_cast, который вы с помощью 3х листов исходного кода, с блекджеком и шаблонами реализуете руками с помощью map<>.
На мой взгляд, не нужно множить сущности, http://ideone.com/K0KQhk вот реализация проще, расширяемая и более эффективная, т.к switch() отлично оптимизируется компилятором
Ну и тогда проблемы, которая решается в статье, нет вообще.
Индексы в С это и есть указатели, точнее смещение к указателю.
Ладно, с алгоритмом обращения я похоже спутал какой то другой алгоритм, который в новостях недавно пробегал.
Прекращаю оффтопить.
STL наоборот, дает еще преимущества отсутствия необходимости работы с указателями и дает некоторую защиту от выхода за рейнж при отладке.
Зачем оптимизировать метод Гаусса компилятором или пытаться прикрутить к нему STL, если есть гораздо более эффективные _алгоритмы_? Неудачный пример, но не надо конечно везде совать шаблоны, согласен.
Статически или на стеке — для скорости работы не важно. Но невозможно для компилятора создать объект неизвестного заранее размера с фиксированным адресом. Да и не нужно.
Пример стекового аллокатора я привел, как оптимизация в плане исключения запросов выделения памяти ОС.
Если вкратце, то стоит просто посмотреть, в какой машинный код превращается программа с использованием STL при компиляции с разной степенью оптимизации. Тогда можно начинать спорить.
На С
Будет интересно посмотреть.
Я недавно столкнулся с задачей реализовать стандартный набор С-функций math.h на ассемблере. В процессе чего выяснилось — что набор инструкций, удобный процессору, во многом перпендикулярен привычным человеку математическим функциям.
Соответственно, разрабатывая новый формат, Вам нужно спроектировать к нему и набор инструкций, эффективно с ним работающий.
Удачи.