А у меня большинство скриптов и баннеров заблокированы и я этого даже не вижу
Это бесплатьнй хостинг, так что претензии к нему неуместны ((

Дело не в претензии, просто я предпочитаю иметь контроль. Несколько лет назад была уже попытка подобного переезда и через несколько месяцев все вернулось снова сюда (не считая потерянных сообщений в форуме).
Код надо переносить в репозиторий, я склоняюсь к гуглокоду, просто код давно пора серьезно переписать и ориентировать на новые версии OpenGL
Скорее всего перенеся работу с текстурами и расширенями на существующие библиотеки (DevIL, GLEW) - насчет изображений я полностью уверен, про GLEW еще какие-то сомнения остались.
Ну и понятно, чтобы весь фреймворк компилировался в одну библиотеку и не надо было постоянное все файлы перекомпилировать.
Когда что-то более-менее работающее будет я собираюсь это перенести в репозиторий, а пока можно пообсуждать.
Мне интересны какие есть идеи

Насчет GLEW я наткнулся на непреятную фичу - без выставления glewExperimental у меня не подключились VAO (на последних драйверах и GeForce 460)
Иногда возникает ощущение, что проще допилить libExt - дать поддержку GL 4.1 и наиболее важных расширений. Как-то тот факт, что VAO почему-то оказались в разряде экспериментальных очень растроил

Еще очень хочется выкинуть вообще использование STL - меня уже достали дебильный класс string, не имеющий аналога strlwr/strupr, методы вроде remove_if, которые ничего не удаляют и ориентация на фактически макросы. Основное, что меня пока удерживает - это замена стандартных классов своими.
Интересно было бы узнать Ваше мнение.

А чем раздражает именно народ ?
У меня нет ощущения, что именно это сдерживает выход новых статей - там главное разобраться, сделать примеры и текст.

Тем, что верстку приходестя делать тем или иным образом вручную. Что по меньшей мере замедляет исправление ошибок. Плюс, как показывает пример википедии, назло статьи при исправлениях портят крайне редко. И даже если портят - то откат изменений - два щелчка мышкой.

remove_if очень оптимален, для контейнеров типо вектора. И вот честно, мне еще никто не показал, как сделать вектор лучше, чем он реализован в STL.

Если вы про чудо вброс с галвной страницы, то это оформляется в шаблонный метод из одной строчки и не имеет runtime оверхеда. Чего не скажешь, например о NSString, вызов каждого метода которой в лучшем (и крайне редком) случае имеет оверхед на вызов C-метода, в среднем эквивалентен виртуальной функции, в худшем - до 3 раз медленнее, чем виртуальный вызов (я уже приводил пруфлинки на эту тему). И я не могу сказать, что [NSString stringWithCString:"foo" ecoding:NSUTF8StringEncoding] выглядит гораздо лучше, учитывая, что подобные действия приходится делать чаще, чем toupper. При это std::transform имеет (в релизной сборке) нулевой оверхед на вызов и применим к любым контейнерам. Единственное, чего мне не хватает в std::string - метода, аналогичного QString::Arg. И то, необходимость в нем стоит достаточно редко. А весь тот бред на манер Osp::Base::String или, боже упаси, NSString - используется крайне редко, и по логике, не имеет отношения к строкам вообще. Мы с вами не однократно уже спорили на эту тему, и я отлично понимаю, что эти споры бесполезны, но все же, давайте к таким вбросам делать приписки "ИМХО", а не выдавать их за истину в последней инстанции. На gd.ru как-то был мего эпичный спор на тему STL. Противники STL в итоге сами загнали себя в угол, но при этом не прекращали крайне ожесточенных попыток убедить всех, что они правы. То, что вам очень не нравится С++ - уже всем давно понятно. Но зачем постоянно давать нелепые ссылки класса "C++ is bullshit", в которых цепляются к конкрентным вещам на конкретных платформах, причем то, к чему они цепляются одинаково справедливо для любого компилируемого языка? Зачем постоянно приводить некие методы из языка и постулировать, что "они bullshit, вот Obj-C сделанно все круче. Фиг с ним что в n раз медленнее (эпичный NSArray с около-логарифмическим временем доступа к элементу), но вы смотрите как круто"? Зачем, в конце концов, вообще использовать этот язык в своих примерах? Почему не писать на С? Или даже не на Python? То, что язык используется порядка 20 лет, и ему не нужен iPhone, что бы держаться на верху списка самых используемых языков уже говорит о том, что все ошибки в дизайне языка (да, они есть, и их достаточно много) компенсируются его возможностями. Особенно если уметь их применять, а не говорить, что жизнь язык - очень плохая вещь.

Какая версия? Причем не GLEW, а драйвера? Разработчик говорит, что это связанно с тем, что драйвер не всегда корректно возвращает строку с расширениями, если часть из них является экспериментальными в драйвере. Код инициализации VAO (да вообще любого расширения) выглядит так:

#ifdef GL_ARB_vertex_array_object
  CONST_CAST(GLEW_ARB_vertex_array_object) = glewGetExtension("GL_ARB_vertex_array_object");
  if (glewExperimental || GLEW_ARB_vertex_array_object) CONST_CAST(GLEW_ARB_vertex_array_object) = !_glewInit_GL_ARB_vertex_array_object(GLEW_CONTEXT_ARG_VAR_INIT);
#endif /* GL_ARB_vertex_array_object */

Очевидно, что glewExperimental нужен для инициализации только в том случае, если драйвер не вернул VAO в строке расширений. Такая проблема есть, например, на 190.xx драйверах. В любом случае, на его поддержку не надо тратить собственного времени и он вообще не имеет зависимостей при сборке (не нужно даже наличие opengl хедеров).

C шаблонами компилятору всегда проще раскрутить в инлайн. Особенно с однострочными шаблонами. И уж тем более это будет слелано в релизной сборке. Про слово inline я не говорил. Я говорил про in-place инстанцирование.

В соседней ветке я уже задавал вопрос - когда она вам реально была нужна? То есть не в аккадемическом примере, что дескать можно вызвать метод по строчке его сигнатуры? Я могу хоть минимально представить себе ее необходимость в языках, понимающих eval. Но в компилируемых языках - увольте. К тому же по факту, ряд "супер" возможностей Оbj-C, например делегирование, реализуются на С++ чуть ли не построчно. Оно, конечно, нельзя использовать id (хотя можно, можно, было бы желание) в качестве типа делегата, но в промышленном коде никто и никогда не будет использовать id. В первую очередь это небезопастно, особенно для библиотечного интерфейса. Попытка сделать это безопасным приведет к резкому (и абсолютно не оправданному) падению производительности. Так что "гибскости рантайма" всегда будут стараться избежать за счет строгой, статичной типизации. Более того, это касается не только Obj-C.

Попробуйте воспользоваться 1.5.7. Приведенный код из него.

Ну да, а Хелм и компания - сборище не понятных людей. Кстати они совершенно спокойно приводили примеры как C++, так и на Smalltalk.

Простите, но фраза "омерзительный бред" принадлежит не мне. И я не говорил, что Obj-C плохой конкретно сейчас. А мнение, какое мнение? Что конкретно обсуждать? Замену libExt на GLEW? libTexture на Devil? Но с этим и так более менее все понятно. Выбрасывание STL из кода? А какие у этого плюсы? Что это даст? Сколько раз в конкретно коде фреймворка вы нуждались в недостающих методах string? Сколько раз вам мешала "убогость" алгоритмов (если вы вообще их использовали)? Как бы в чем от этого будет профит?

Он удаляет объекты, но по ряду причин не изменяет длину контейнера. Причины, кстати, хорошо описаны у Алены-С++

И причем тут STL? O_O

После самсунговской бады я исключения вообще вдвойне полюбил. Уберубогий способ, основанный на goto вообще не приносит счастья. Эти молодцы даже SjLj умудрились отрубить...

Ну да. Он местами очень забавно шутит. Мне, в принципе, нравятся лямбды и decltype с auto. Глубины дао r-value reference и move-only конструкторов я пока не познал во всей полноте. variadic темплейты применимы сранительно редко, поэтому мне на них глубоко все равно. Нормальных атомиков оченьма хочется, но разработчики компиляторов на них, почему-то, забили. То, как в стандарт внесли многопоточность тоже не потрясает воображения. При этом 90% процентов нововведений охватывет супертонкие материи, которые явно новичкам жизнь не улучшат.

Да, согласен, это очень разумно.

Ну, он видимо нужен) Просто не совсем ясно, что понимается в данном случае под фреймворком...

А что такого в самсунговской баде ?