имо программирование входит в информатику, информатика входит в математику
если программирование 1С, формошлепство и прочий быдлокодинг это приличный профессиональный уровень, то математика естественно не нужна
более того алгоритмы сейчас писать не модно, модно юзать композиции функций стандартных библиотеки где все уже есть
вот например в С++ есть stl vector, из тех кто его юзает и половина не знает что такое вектор вообще, и почему эта структура так названа, однако это приличные программисты

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

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

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

бррр... чушь. Что теперь, недилетанты только те кто в машинных кодах пишут? Или физики оперирующие законами Ньютона тоже дилетанты в физике?

ок, но я буду зарабатывать деньги, а такие "математики" будут всю жизнь STL с BOOST'ом переписывать и без денег сидеть, ну собсно кто на что учился..

Я думаю те люди, которые пишут STL и BOOST ваши деньги и за деньги не считают. Так что в крайности впадать не надо

Daevaorn, я не говрю о людях котрые написали STL И пишут boost, я говорю о тех кто его переписывает, а этим страдает очень большая часть C\C++ программистов.

при том делают это просто из за комплекса.. например то что окна "рисуются" системой и многие другие библиотеки не вызывают у них желание переписывания,
также то что в паскале имеется тип строки и динамический массив аналогичный std::string и std::vector тоже никого не беспокоит.
А вот то, что в cpp  допускается свобода выбора, и чтоб не ущемлять права, часть языка вынесена в namespace std ,
а также то, что наряду с контейнерами и алгоритмами, существует возможность пользоваться и "голыми" указателями и массивами,
то сразу слышны категоричные возгласы о том, что кто использует что то кроме голых типов являются неучами.
Сила cpp именно в том, что он предоставляет именно те средства, которые требует от него программист. 
И если некоторые программисты тупые, то это не вина языка. Кстати совсем "тупым" программистам на cpp составить нормально работающую программу, даже с учетом всех вспомогательных средств, гораздо труднее, чем таким же на дельфи/ паскале, т.к. последний убрегает от многих ошибок(правда ограничивая свободу мысли)

Это сообщение отредактировал(а) mes - 2.2.2009, 20:22

mes, это С++ создает ошибки, там где в других ЯП их не может возникнуть
алсо приведи пример

С++ ничего не создает, их создают неграмотные\невнимательные\неопытные программисты. С++ инструмент, и инструмент довольно хороший.

Ок. Тут полностью согласен.

даже так ?! я думал все таки неправильное обращение с языком. 



Это сообщение отредактировал(а) mes - 2.2.2009, 20:53

mes, вот ты например пишеш
if(r==INVALID_HANDLE) ...
или
if(INVALID_HANDLE==r) ...
?

GoldFinch, оба варианта равнозначны.
Если имелось в виду, что можно перепутать == и = в if выражении, то обычно компилятор предупреждение выдает в таком случае...

зачастую так:
if(r==INVALID_HANDLE) 
но во-первых, насколько мне известно, эта ошибка свойственна всем си-подобным языкам в том числе яве и шарпу,
во-вторых  я не так часто пользуюсь if чтоб в куче ифов не заметить опечатку при повторном просматривании,
в третьих когда мне случалось ошибиться, компилятор (gcc) выдавал предупреждение,
итого за время моего общения с cpp, подобная ошибка ни разу не пробралась в готовый код.

mes, я раз за тебя, что ТЫ не можешь совершить эту ошибку, но это ничего не говорит о семействе С-образных ЯП
кстати вначале ты говорил о , а тут на C# перешел

основываясь на Вашей фразе :



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

и для меня возможность написания подобного кода :

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


Это сообщение отредактировал(а) mes - 2.2.2009, 21:42

mes, я могу ошибаться, то такой код 
if (A* a=getA()) a->f();
- это плохой код, не соответствующий правилам "хорошего" стиля программирования

почему? Вполне себе обычный C++ код. Получили указатель, сразу же проверили его, и если все ОК, используем.)

а что именно Вас смутило ? то что объект создается внутри условия ? само приравнивание там или нечто другое ?
что плохого Вы видете здесь?

Это сообщение отредактировал(а) mes - 2.2.2009, 22:03

Я пишу (r==INVALID_HANDLE). Считаю второй вариант придурью.


В шарпе....



....не скомпиляется.

А в случае с bool, будет выведено предупреждение.

а я думал эта тема будет как минимум о пяти страницах =\

это не плохой стиль программирования, вот плохой стиль -
  

а вообще, в языке С++мне много чего не нравится, но достойной замены ему я не вижу ((

Какой-то странный аргумент. Да неужели мало что ли мест, где можно ошибиться?! А можно меньше на больше перпутать и полалгоритмы где-нить работать не будет. Так давай это делать не просто разными символами (меньше и больше), а какие нибудь вообще разные конструкции (например, словами!). Чтобы программист подумал прежде чем писать. Замечательный язык получится 

Далее: о чем толком тема - что-то не понял. Надеюсь ещё прояснится ;)


Множественные отношения программирования и пр. в данной фраз не очень логичны, если честно. Это всё пересекающиеся области. Ну, ладно, что есть информатика толком не знаю (за определениями лень лезть). Если под этим понимать алгоритмы, структуры данных и пр. - то это точно отдельная область (пересекается и с программированием и с математикой, но не входит ни туда, ни туда).

Ну 1С - это вообще ИМХО не в тему. Формошлёпство - хотелось бы уточнить терминологию  Если это те мегакалькултяторы, которые делает каждый пятый новичок на дельфях с кучей Button5_Click (ну или как там точно дизайнер их обзывает - уж не помню..), то это одно. А если просто использования визуальных средств проектирования UI - совсем другое.

И к программированию у вас странное отношение. Конечно, это вечный спор, но всё же.. Программирование сегодня - это очень обширное понятие. Но ценится не тот программист, который знает наизусть кучу алгоритмов на графах, реализует сбалансированные бинарные деревья в каждом проекте и т. д. Современное программирование - это во многом умение проектирования, дизайна модели системы. Это знания множества технологий, умение эффективно использования средства разработки (не только ИДЕ само собой, а кучу всяких кодогенераторов, анализаторов, профайлеров и пр.). Ну.. и собственно опыт программирования 

Ну да ладно. Из заголовка темы так и не понял - ругаем С++ за стл и пр.? Вообщем, плиз, идею темы более понятно в студию 

изначально тема называлась "программирование и математика"

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

Goliaf777, я не предлагаю писать гуй на асме. я говорю о том что есть люди которые кодят на ЯВУ и знают как написать гуй на асме, а есть люди которые кодят на ЯВУ и не знают что такое асм.

Конечно есть. А в чём мораль?

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

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

бред сивой кобылы, приведи мне хотя бы один аргумент зачем ,например, Java программисту знать ассемблер, да и любому другому? Зачем, если его работа с этим не связана?

Вобщем-то неочевидно, что ширина кругозора както связана с эффективностью работы, и может показаться если два программиста пишут на С++, одни знает а асм, а другой его не знает, то код они напишут одинаковый.
Однако тут важно не знание асма как такового, а умение на стадии проектирования кода представить как этот код скомпилиться и как он будет выполняться. Тогда можно сказать что один вариант по тем или иным параметрам будет оптимальнее другого. Для этого надо знать свой компилятор (его кодогенерацию, т.е. асм) и знать среду в которой программа будет выполняться (ОС).
Например зная размер страницы памяти (гранулярность памяти) в винде, организацию хипа, стека, и размещение секций образа программы в памяти можно более правильно выбрать как и где именно размещать буферы в памяти, чтобы программа не требовала 512Мб оперативки для работы с 1Мб текстовым файлом.
Я уже не говорю об оценке сложности алгоритмов, много ли программистов вообще имеют представление что это такое?
Зная как будет компилиться та или иная конструкция кода, можно будет прикинуть ее размер и быстродействие, может сейчас такие параметры и не важны, но от того что код оптимален, хуже никому не будет.

vinter, Java программисту надо знать байткод, принцимы работы ВМ java и т.п. 
вродебы в java используются стековые ВМ, и наверное это может както влиять на оптимальность того или иного кода, это тоже надо знать
много ли java программистов знают как выполняется их код?

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


сложность stl гарантирована стандартом, самописных - головой.

я может и не прав, но по моему, с уровнем нынешних компиляторов это почти нереально.


зачем?


важно знать, что он делает на том уровне, на котором его пишут, низкий уровень не важен. 
Вот тебе пример, тебе допустим надо создать клиент\серверное приложение на базе TCP, ты же не пойдешь смотреть формат IP пакета, и уж тем более фрейма физического уровня. У каждого уровня абстракции есть стандарт и гарантии по выполнению, использовать более низкий уровень из высокого можно только на свой страх и риск.

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


"лишний повод"
Но всё-равно программист, не видевший асма, это всё-таки подозрительно

Это сообщение отредактировал(а) Carnifex - 5.2.2009, 15:54

какое это имеет значение? Видел, но видел на университетском уровне, т.е никогда ничего на нем серьезного не писал.

ничего не задевало, просто утверждение, что программист не видевший ниразу ассемблера не программист, это мягко говоря некорректно.

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

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

Зачем прежде? Программировать можно и без этого, обратного я нигде не говорил. До какого уровня спускаться, до схемотехники или до квантовой механики  - личное дело каждого, но ассемблер - всё-таки в этой иерархии почти наверху.


каюсь, забыл

Вот и я о том же...


Вот блин. Опять унылый троль?  

PS Мой опыт асма это две вещи: тривиальные универский задачки + "анализ" других приложний на уровне среднесложных алгоритмов, классических пакеров и т. д. Ну и плюс тривиальный анализ кода, генеримого компилером для некоторых случаев. В основном just for fun.

Carnifex, я не понимаю смысла опускаться ниже языка, на ктором ты пишешь. Объясни свою позицию, только аргументировано, желательно с примерами из реальных проектов в твоей жизни. 

И тем не менее он есть. И так у большинства. О чём я и говорю.


Пользы от этого мало, просто знание, бессмысленное, да

Это сообщение отредактировал(а) Carnifex - 5.2.2009, 16:53

vinter, с точки зрения языка есть разница в 

и

?

а между

и например

?

Кстати свитчи при достижении некоторого n компилятором превращаются в jump-tables или как там они называются, и эффективность будет почти такая же, как 

, разница только в константе. А с точки зрения языка в первом случае писать больше.

Это сообщение отредактировал(а) Carnifex - 5.2.2009, 17:23

GoldFinch, если функция у тебя действительно возвращает константу - то поверь любой нормальный компилер с этим справится (с подстановкой значения). Что касается второго примера - аналогично. Создаст он таблицу переходов, если сочтёт нужным. Только свитч - это много буков, потому я так писать не буду. И вообще - твой пример перерождается в key - '0' (раз уж это си).

были времена - не справлялись. Как узнать что эффективнее и почему это так без смены уровня абстракции?

Блин, да очевидно ведь! Если мы делаем больше вычислений (в цикле) - это хуже. Меньше - лучше. Причём тут асм?!  Если бы вы привели хотя б какой-нибудь пример, ориентированный на особенности работы процессора, выравнивания там скажем - другое дело. А это... Банальное число операций. Математика уж скорее, чем асм ))

GoldFinch, примеры высосаны из пальца.

есть кончено, в 1 примере при ф-ии возвращающей класс я бы руки оторвал, за второй вариант.

это вообще че за конструкция? впервые вижу 
нафиг там свитч x=key - '0' И все. Примеры элементарные
Упс страницу пропустил 

Это сообщение отредактировал(а) vinter - 5.2.2009, 18:49

+1, вот например 
Любитель и Carnifex знают что switch компилится с использованием таблицы переходов, а толку-то никакого

компилится в массив адресов меток m1..mN ("таблица переходов"), из которого выбирается адрес для перехода на нужный case, N операторов присваивания константы переменной, и N переходов на конец switch
итого N адресов, N присваиваний, N констант, N+1 переходов, в процессе выполнения происходит 2 перехода и 1 присваивание


здесь N констант и 1 операция присваивания

Добавлено через 1 минуту и 20 секунд
vinter, считай это псевдокодом, а не кодом С++
примеры вырожденные, чтобы было виднее их суть

GoldFinch, в идеале, чем выше уровень абстракции тем лучше, в этом направлении программирование и развивается.
Раньше, когда компьютеры были большими а /me ходил в первый класс, программисты были не глупее чем сейчас но софт был, скажем так не очень функциональный. А все из-за уровня абстракции, программировать с использованием прерываний, регистров и тд это конечно круто, но написание более менее сложной программы потребует слишком много человеко-лет. То, что сейчас пишет один программист на сишарпе за неделю в одно рыло, раньше писала-бы куча народу много месяцев.
Поэтому я считаю, что нужно использовать достижения прогресса в нашей профессии, вместо того, что-бы изучать все, что когда-то было мэйнстримом, в общем нужно смотреть вперед а не назад.
В то-же время есть вещи, не теряющие ценности со временем, дискретная математика, тервер, алгоритмы и структуры данных так-же актуальны для современных программистов как и раньше  

1) Знание принципов генерации байткода даёт знание того, почему одни конструкции в языке эффективнее других. Нередко в книгах их вбивают в голову на уровне аксиом - "эффективнее так, а не иначе", но на практике понимание движущих механизмов сильно полезнее тупого зазубривания.

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

Лишнее? Ну... можно писать код и без всего этого мусора в голове (и даже без знания математики, проверено  ). Только вот выше быдлокодера подняться будет проблематично.

И вообще, С++, на мой взгляд - достаточно низкоуровневый язык, те кто пробовал программировать на python/ruby ну или даже C#/Java в общем на современных языках программирования, или на функциональных ЯП, таких как haskell, которые многие считают языками программирвания будущего, меня поймут ;)

дело было не в том, что небыло стандартных библиотек с готовыми алгоритмами, это все было достаточно давно. проблема была в железе с крайне жесткими ограничениями по объемам памяти и производительности. мне повезло попрограммировать ГУЙ для ДОС когда у тя может быть не более 10 64Кб сегментов памяти, а процессор с трудом тянет всякую анимацию типа анимированного курсора мыши (последовательность битмапов хранить негде, поэтому анимация рассчитывалась в реал-тайме)

Добавлено через 2 минуты и 19 секунд
Lazin, функциональные языки не менее древние чем императивные. Недостатков у них более чем хватает.

ты приводишь знания о спецификации языка, а это есть стандарт(не знаю как там со стандартом в яве), Знание принципа раскрытия инструкций в байт код, не дает никаких преимуществ. Если считаешь иначе, приводи конкретный пример.

например?


Ну а я про что, раньше этого так и было, а сейчас это все не актуально.
Сейчас новый сервер дешевле нового программиста, так-что делайте выводы. Раньше программисты оптимизировали все что только можно на микроуровне, там операцию сэкономили, там избавились от лишней отрисовки на экране и вроде как быстрее заработало. Но на современном железе ты этого "быстрее" скорее всего не заметишь. Какая нафик разница сортируется массив из 1kk строк за 0.1 сек или за 0.05 сек. Такой импрувмент начальство скорее всего не оценит. Оценят максимально корректную программу, которая создаст как можно меньше проблемм. 
В большинстве современных приложений причина тормозов - I/O, неоптимально разработанные алгоритмы( O(N*N) когда можно сделать O(ln(N))), неправильная работа с динамической памятью(фрагментация, слишком частое выделение - освобождение памяти), локи в многопоточных приложениях. Все это борется не с помощью вставок на асме, а на более высоком уровне, использованием асинхронного ввода вывода, буферизованного, оптимальных алгоритмов обработки данных, написанием своего специализированного менеджера памяти, ну и правильным проектированием приложеиня и использоанием наиболее подходящих в конкретном случае примитивов синхронизации.

Это сообщение отредактировал(а) Lazin - 5.2.2009, 22:44

Классика из любой книги на Java:

Общеизвестно - присваивание String в цикле является признаком неумелого программирования и просаживает скорость приложения. Какова причина? Смотрим байткод с помощью "javap -c":

Механика: исходная строка сохраняется в стеке (2). В цикле на каждой итерации создаётся новый объект StringBuilder (12), сохранённая строка извлекается из стека и добавляется к нему (к слову: и если её размер больше 16 символов, происходит новое выделение памяти и перемещение на неё объекта) (16-20), добавляется строка "abc" (25), из содержимого StringBuilder создаётся новый объект String (28) и сохраняется обратно в стек (31). А всё оттого, что объект String является неизменяемым (immutable), и операции со сложением строк через оператор (+) неявным образом используют StringBuilder. Но одно дело зазубрить и поверить на слово, а другое - увидеть в байткоде собственными глазами. Понимаю, пример выглядит чрезмерно наглядным и даже в какой-то степени уникальным - но мой point про полезность понимания подтверждает на сто процентов. Плюс на форуме есть цикл статей от Domestic Cat. Вот, к примеру, цитата из второго поста после обсуждения некоторого количества кода, подтверждающая полезность тщательного изучения генерируемого байткода:



Сборщики мусора в стандарт языка не входят, это спецификация JVM, с которой знакомится гораздо меньшее число разработчиков. Однако при приёме на работу про них могут серьёзно спросить. Почему JVM легко относится к огромным количествам короткоживущих объектов; особенности работы JVM, при запуске которой установлен ключ "-client"; или "-server"; чем отличается на деле работа последовательного GC от параллельного; для чего разработан инкрементальный GC и в каких специфичных случаях он даёт выигрыш приложению; почему требуется быть осторожным с вызовом System.gc() (считается, что это всего лишь рекомендация JVM к запуску сборки мусора, которую она вправе проигнорировать. Однако на деле при запуске такого GC чистится не только молодое поколение, но и старое, в результате приложение может серьёзно приостановиться и ни о каком soft real-time речи уже не будет).


P.S. про ассемблер: только после его изучения до меня на самом деле дошло, что такое "передача по значению" и "передача по ссылке". Думать о них стало значительно проще. И в Джаве они используются в том числе.

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

Shaggie, дальше свпорить с тобой не буду, т.к боюсь моих познаний в Java для этого не хватит. Пока тебе поверю на слово 

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

Для примера возьмём умножение матриц. Много зависит от того, как мы храним матрицу в памяти(линейно, либо построчно), а для этого нужно понимать, что при линейном хранении вероятно кэш-промахов меньше, чем при построчном. В то же время для маленьких матриц(эмперически установил для себя границу таких матриц, где общее число элементов < 50000) это не имеет смысла, т.к. маленькая матрица может уместиться полностью в кэш современных процессоров. С другой стороны, хотим мы реализовать умножение. Сколько бы мы не оптимизировали классический алгоритм нифига путнего из этого не выйдет. Для больших матриц частые кэш-промахи съедят любую оптимизацию(одно обращение к памяти может занимать тысячи тактов). А вот если взять и транспонировать одну из матриц, а потом перемножать последовательно строка*строка(а не строка*столбец), то мы получаем эффективную работу с кэшем и, допустим в моём случае, десятикратный прирост производительности на матрицах размером 1024х1024. Далее можно этот процесс векторизировать, т.е. заюзать SSE2, но тут уже действительно надо знать ассемблер и подходящии инструкции, а так же принципы их работы, понимать саму парадигму SIMD. А кому этого мало, можно вообще перенести перемножение больших матриц на GPU,  а там опять новая архитектура и её особенности и опять же, чем лучше знаком с аппаратными особенности(в разумных пределах), тем лучше. 

Знание ассемблера полезно при профайлинге приложений, чтобы не смотреть как осёл на асм-листинги и тайминги без понимания сути.

В тоже время, лично я, стараюсь использовать сторонние библиотеки. Зачастую, кстати, в них находишь очень хорошие реализации многих вещей(если заглянуть в исходники), но в моём последнем проекте, например, присутствует огромные объём вычислений связанных с матрицами. Я решил, что будет лучше написать свой класс для работы с матрицами, нежели пользоваться сторонним, т.е. просто изобрёл свой велосипед, но это было обоснованно в итоге и вполне оправдано. 

Всё зависит в итоге от разработчика и его профессионализма. Если я знаю, что у меня какой-то цикл выполняется 10 раз в час, при этом он совсем не нагружен, то лучше я вызов метода/функции в него помещу, ибо код будет более читабелен, а вынос переменной за цикл здесь является излишней оптимизацией, никому ненужной. 

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

на самом деле я согласен с 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