на самом деле я согласен с W4FhLF



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

Добавлено через 7 минут и 16 секунд

unreal mode? ;)

MAKCim, 640Кб памяти под ОС+софт - 10 сегментов по 64Кб...

GoldFinch, 
это понятно
я к тому, что есть unreal mode

Я согласен. 

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

Добавлено через 1 минуту и 52 секунды


Более того, это зачастую на первых парах мешает. Потому что заставляет часто думать о технических деталях, вместо того, чтобы сосредоточиться на проблеме и мыслить абстрактыми сущностяим.

Гмм... делетанты, неделетанты...

При поиске элемента в векторе, в каждой итерации вектор делает только одну проверку. Какую именно и как это реализовано?

Если бы вы писали СТЛ::вектор, то писали бы также?

Добавлено через 3 минуты и 37 секунд

Угу. Желательно знать как в конкретном камне реализованы бранчи, кэш, пайпы. Тогда можно сделать очень качественный рескеджулинг. Правда компилятор сделает эту же работу с 70-80% успеха. Стоит оно того?

вот возьми и посмотри как это реализовано, както кроме if Xi=Y на ум больше ниче не приходит, что еще можно проверять, развечто if f(Xi)=f(Y)

а СТЛ::вектор я бы не писал, потомучто мне вообще непонятен синтаксис этой части С++, зачем надо юзать два двоеточия и угловые "скобки"


только не везде вообще нужна такая оптимизация, а там где нужна компилятор накосячит в других очевидных местах, например будет пихать в стек float'ы через стек сопроцессора

Убило  

 Ну типа программы писать... но это для программистов, остальным это делать не надо.

почему-то в С++ есть . :: -> ,а в vba и делфи только .
что же удобнее?

насчет удобства шаблонов, цитата из википедии



" real_p[push_back_a(v)] >> "  - это называется удобный синтаксис??

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


ну почему же, есть еще проверка на эквивалентность. Которая используется в ассоциативных массивах.
!( x < y ) && !( x > y )

GoldFinch, какое то странное использование спирита, на хабре есть более удачный пример.

Это сообщение отредактировал(а) vinter - 16.2.2009, 17:53

Uгу, вот именно эту проверкu оn i делает Bез проверки, дошел оn дo концa или нет.

 Ну как бы -> юзать никто не заставляет - это лишь аналог *.
А аналогов :: нету, насколько помню.


Хотя мне самому это не нравится =\

есть проверка, если элемент не найден возвращается last iterator

Gмм... Pо-моему проверки тo каk раз нет i POJETOMU возвращается ласт_итератор. Kаk сделат' просмотр массива быстрым. Pоставить искомыj элемент в конец и сканироват' пока не нашел. Tаким образом не надо провеят' вышеl ты за границы массива или нет. A с другой стороны всегда есть индиация того nашел ли ты искомый элемент или нет.

Zвиняйте за транслит. Iз-под оперы пшу. Ет' еще конкуеррор, но в неm тоже транслиt не пашеt.

neutrino, че то я тебя не понимаю, как по твоему он может вернуть последний итератор, если у него нет проверки? при отсутсвии проверки был бы ексепшн

класно, а если для вставки понадобиться перераспределение памяти? Да и это в корне не правильно, так использовать немодифицирующий алгоритм.

Добавлено через 1 минуту и 50 секунд
реализация msvc