пишем на java (:

А почему код не опенсорцевый?!;)

Да, и вот это вот nodei*3 + 0, nodei*3 + 1, nodei*3 + 2 вызывает грусть. Почему не завести какой-нибудь idx и не сделать idx++, idx++, idx++. И даже умножать на 3 не надо будет...

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

Можно подробнее, чего не хватает? Какой эффективности? Чем не устраивает обычный цикл с индексом или ArrayList?

ну, в связи с тем, что я тоже отношусь к партии "я не вижу места c++ в нашем мире и, мне честно сказать, он не очень приятен" я развею миф о быдлокодерстве данного случая (:
дело в том, что вот эти вот три троечки и от нолика до двух до того как по коду пройдет препроцессор задефайненный являются константами, которые соответственно подставляются непосредственно в момент сборки, исходя из того что собирается и какие дефайны объявлены. т.е. там могут быть и не троечки, а 6, 2, 7, тоже самое и с остальными цифрами, в связи с чем оптимизировать данный кусок особой необходимости нет, тем паче что это все развернется в неимоверные конструкции на стадии обфускации, proguard`а.
так менее грустно? (:

может я не допонимаю сути заявление, но с итераторами по массивам и коллекциям никогда проблем не возникало.
или ключевое слово *эффективных*?

> Чем не устраивает обычный цикл с индексом или ArrayList?

Скоростью. ArrayList вообще не обсуждается - он медленнее даже массива с индексом. Но и массив с индексом - медленнее, чем работа с указателем.

В голом С (извините, дальше идет C, ибо в жабке нет указателей) правильный путь - завести указатель и гулять им по массиву, через инкрементацию.

Вместо

for (i=0;i<SIZE;i++)
a[i] = b[i];

правильнее делать

char* pa = a;
char* pb = b;

for (i=SIZE;--i>=0;)
*pa++ = *pb++;

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

PS Я в курсе про memcpy, пример специально взят бессмысленный.

> я развею миф о быдлокодерстве

Где ж я Вас так обругал? Вообще выставлять свой код в галерею - требуется известная смелость, так что я обычно до оскорблений не дохожу;)

Объяснение довольно туманное. Я так понял, что кроме указателей, в Вашем случае еще не хватает препроцессора;) Да, разумеется, мой комментарий взят вне контекста всего проекта. Но Вы все-таки подумайте - нафига вам 6 арифметических операций (да еще 3 умножения) - вместо трех инкрементов. Лишний раз подумать же никогда не вредно?;) Исправите что-нибудь - хорошо. Не исправите - это Ваш код, и Вам виднее.

Если обфускатор портит логику и снижает эффективность жабского кода, а не только корежит идентификаторы - как-то хочется сказать "фтопку".

> ключевое слово *эффективных*?

!

ну в данном случае, указатели сработают быстрее, можно конечно проверить, но думаю не стоит.
хотя System.arraycopy конкретно для данного случая должен показать результат гораздо выше нежели инкремент.
суть ясна, но опять же сравнение C и java удел холиварщиков.

> сравнение C и java удел холиварщиков.

Отнюдь не собирался начинать какие бы то ни было холивары (тем более что мне придется разорваться в такой войне:). Просто есть хорошая вещь в С, которую (желательно без введения сущности "указатель") хотелось бы иметь в жабке на уровне языка. Может, однажды появится какой-нибудь JSR на эту тему...

> Объяснение довольно туманное. Я так понял, что кроме указателей, в Вашем случае еще не хватает препроцессора;)
это код после препроцессора, изначально эта конструкция выглядит примерно так:
x * CONST.MAP_SYNC_POINT_1 + CONST.MESH_INDEX
x * CONST.MAP_SYNC_POINT_2 + CONST.NO_TRANSFORM
x * CONST.MAP_SYNC_POINT_3 + CONST.DEFAULT

а после препроцессора, появляется увиденный Вами код, суть в том, что в каждом билде свои значения CONST и до момента сборки они явно не определены, т.е. туманны (:

насчет обфускатора я как нибудь напишу "хвалебную" оду, кровопийца еще тот.
был там печальный баг, который Thread.sleep в условии if разворачивал как for, искали долго...

А-а... Так это ПОсЛЕ препроцессора. Тогда ... У вас хреновый препроцессор %) Ну или надо б его (или входной код) как-нибудь вздрючить на предмет инкрементации вместо умножения. Использовать тот факт, что SYNC_POINT одинаковые и индексы последовательные... Если это так, конечно, в общем случае (или хотя бы в половине случаев).

А обфускатору нельзя опции помягче поставить? Или просто заопенсорсить код нафиг?;)

а обфускатор во владении EA (: если я его заопенсорсю то меня заклозяд (:
оптимизатор в дальнейшем срабатывает хорошо, в связи с чем там константы на выходе получаются без математического вмешательства. препроцессор настроен так умышленно, для удобоварения кода не только людьми его писавшими, что в принципе по моему мнению правильное решение.
SYNC_POINT разные, поток перебирается трижды в данном коде, опять же связано с тем, что поддерживать код будут другие люди и думаю сэкономят пару часов времени.

Ну, Вам виднее

ЗЫ Я говорил про открытие кода игрушки, не обфускатора. Тогда обфускатор будет просто не нужен;)

насчет "виднее" конечно не дефакто, ибо с удовольствием слушаю мнения других людей и даже иногда соглашаюсь (:
они жмоты там, не дают опенсорсить даже то, что уже давно продано-перепродано и просто пылится чуть не на лентах.