O>>Релиз, VS2005 с выключенной оптимизацией (/Od) на q8400:
__>это все-таки не дефолтная оптимизация, а ее полный запрет — дебаг. на низком уровне для базовых типов ++i — инкремент, i++ — копирование в другой регистр и там уже инкремент, чтобы иметь одновременно значения i и i++. но так как значение i нафиг никому не нужно, то убирание этой пересылки это наипримитивнейшая оптимизация, с которой справиться любой думаю абсолютно компилятор имеющий оптимизацию вообще. я лично пишу i++ потому что там красивее
Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается

Здравствуйте, ononim, Вы писали:
O>Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается
не, ну меня тоже многие вещи коробят, например в приведенном коде конкретно DWORD, printf, в меньшей степени wmain и wchar_t, но я терпимо отношусь к любым рабочим решениям в принципе.

Здравствуйте, alexeiz, Вы писали:

A>Нужно учить студентов больше, чем решать задачи. Их нужно учить software engineering. Туда должно входить гораздо больше, чем просто умение решать задачи. Так же туда должно входить хорошее владение хотя бы одним широко распостраненным языком программирования. Иначе будут продолжать приходить вчерашние студенты и писать в production код свои собственные сортировки (с багами), свои алгоритмы и структуры данных, которые уже существуют в языке или библиотеке.

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

Здравствуйте, __kot2, Вы писали:

__>а вы наверняка из руководства. потому что инженер имеет аналитический склад ума, никому по дефолту не доверяет и не будет ссылаться на мнение в стиле "все знают, что"

Все знают, что программисты не будут ссылаться на мнение в стиле "все знают, что". Рекурсия, брат!

Здравствуйте, minorlogic, Вы писали:

M>На питоне тяжело базовые алгоритмы изучать , контролировать расход памяти. Адресная арифметика и т.п.

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

Ну, а от явного выделения памяти и адресной арифметики я и в С++ уже давно отошел. Так что, какое это имеет отношение к алгоритмам?

Кстати есть такая книжка Python Algorithms. Рекомендую почитать.

Здравствуйте, оwl, Вы писали:

оwl>Зато на с++ шароварой проще заниматься.

Сомнительно мне.

Здравствуйте, __kot2, Вы писали:

__>меня просто вырвет, если я попробую написать что-то на Actionscript или написать длинный sql запрос.

Умница, хоть кто-то тут есть здоровый на голову.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, ononim, Вы писали:
O>>Эот очень субъективно и вообще дело привычки. Раньше мне тоже i++ больше нравилось, а теперь наоборот, и ваще меня коробит и я переделываю в префиксный инкремент везде где под руку подворачивается
__>не, ну меня тоже многие вещи коробят, например в приведенном коде конкретно DWORD, printf, в меньшей степени wmain и wchar_t, но я терпимо отношусь к любым рабочим решениям в принципе.

DWORD, printf, etc в данном коде есть мелочи по сравнению с алгоритмическим идиотизмом. Например с использованием set. Кстати, любой приличный оптимизатор выкинет из релиз код вложеный "пустой" цикл. И на сравнени "релиз" и "дебаг" мы получим не очень адекватные циферки — алгоритм поменялся.

E>DWORD, printf, etc в данном коде есть мелочи по сравнению с алгоритмическим идиотизмом. Например с использованием set. Кстати, любой приличный оптимизатор выкинет из релиз код вложеный "пустой" цикл. И на сравнени "релиз" и "дебаг" мы получим не очень адекватные циферки — алгоритм поменялся.
Алгоритм — не вещь в себе, а в данном случае он здесь — лишь средство демонстрации _возможности_наличия_ разницы. Отсюда и DWORD — потому что GetTickCount имеет меньше накладных расходов чем CRTшный clock. А printf — ну я немного старомоден
set здесь как раз таки потому что у него итератор надеюсь тяжелее чем у вектора. Вообще итераторы бывают самописные, а не только у стандартных контейнеров, и может так оказаться, что они будут намного толще и с побочками, изза которых оптимизатор не выкинет лишнюю копию итератора от постфиксного инкремента.
Цикл оптимизатор не выкинул — спасибо ему на этом, а то пришлось бы вставлять вычитывание элементов в volatile переменную.
Оптимизаторы работают не одинаково на всех платформах. Более того — оптимизация MSVC по размеру (а это — не дебаг) оставила разницу.

Здравствуйте, мыщъх, Вы писали:

М>известно ведь, что:

М>1) не самый востребованный язык (уже жаловались, что вакансий на java больше);
М>2) язык далеко не самый быстрый, доступный и легкий в плане обучения;
М>3) средние зарплаты программиста на плюсах не самые высокие;


М>вывод -- учить плюсы, чтобы заработать много денег -- смысла нет. что же тогда толкает на его изучение?

+100 к ЧСВ, и сразу на форум — меряться, у кого оно больше

Здравствуйте, ononim, Вы писали:

O>Алгоритм — не вещь в себе, а в данном случае он здесь — лишь средство демонстрации _возможности_наличия_ разницы. Отсюда и DWORD — потому что GetTickCount имеет меньше накладных расходов чем CRTшный clock. А printf — ну я немного старомоден
Вы не внимательно читаете. Как я уже говорил DWORD, printf, wmain — это мелочи, которые относятся к стилю написания. А вот GetTickCount имеет меньше накладных расходов чем CRTшный clock — это уже серьезные пробелы в алгоритмической части. В данном случае скорость выполнения этой функции нам вообще не важна — ибо временные затраты k на вызов и выполнение вносят всего лиш ~2*k, где k/(n*T) -> 0 при большом числе n итераций (T — это период выполнения итерации). Т.е., фактически, при любом значение k мы можем выбрать такое число тестовых итераций, что величина k/(n*T) будет сильно меньше погрешности измерения времени. Плюс, выбор GetTickCount очень плох — у нее очень большая погрешность (гораздо больше 1мс), обычно ее значение растет шагами по 200-300мс — это очень много. Соответсвенно число шагов в несколько тысяч недостаточно для уверенной оценки.

O>set здесь как раз таки потому что у него итератор надеюсь тяжелее чем у вектора. Вообще итераторы бывают самописные, а не только у стандартных контейнеров, и может так оказаться, что они будут намного толще и с побочками, изза которых оптимизатор не выкинет лишнюю копию итератора от постфиксного инкремента.
Мерять надо не абсолютную величину, а разницу для цикла с префиксным и постфиксным оператором, внутри одного и того же исполняемого образа. То что вы меряли — подправим соберем и померим, потом опять подправим цикл соберем и померяем уже само по себе может дать далекие от реальности цифры (например ОС начала при повторном измерении свопится), либо оптимизатор полностью переделал скелет программы.

O>Оптимизаторы работают не одинаково на всех платформах. Более того — оптимизация MSVC по размеру (а это — не дебаг) оставила разницу.
Оптимизация по размеру (точнее ее выключение) скорее всего развернула цикл, в результате разница получилась за счет отсутсвия джампов. Кстати да, обычно пр тестах, чтобы минимизировать влияние джампов, вручную раскатывают циклы. Плюс к этому, как я уже говорил, меряют разницу а не абсолютные значения.

O>>Алгоритм — не вещь в себе, а в данном случае он здесь — лишь средство демонстрации _возможности_наличия_ разницы. Отсюда и DWORD — потому что GetTickCount имеет меньше накладных расходов чем CRTшный clock. А printf — ну я немного старомоден
E>Вы не внимательно читаете. Как я уже говорил DWORD, printf, wmain — это мелочи, которые относятся к стилю написания. А вот GetTickCount имеет меньше накладных расходов чем CRTшный clock — это уже серьезные пробелы в алгоритмической части. В данном случае скорость выполнения этой функции нам вообще не важна — ибо временные затраты k на вызов и выполнение вносят всего лиш ~2*k, где k/(n*T) -> 0 при большом числе n итераций (T — это период выполнения итерации). Т.е., фактически, при любом значение k мы можем выбрать такое число тестовых итераций, что величина k/(n*T) будет сильно меньше погрешности измерения времени. Плюс, выбор GetTickCount очень плох — у нее очень большая погрешность (гораздо больше 1мс), обычно ее значение растет шагами по 200-300мс — это очень много. Соответсвенно число шагов в несколько тысяч недостаточно для уверенной оценки.
Во клонит вас в сухие алгоритмы, а я смотрю на вещи со стороны жизни
100 мсек — это почти минимальная разница которую имеет смысл намерять, ввиду того что в винде размер time slice'а выделяемого консольным процессам — 90 мсек.
А для 100 мсек мне пришлось ждать уже 6 секунд на эксперимент, что меня уже немного утомляло.
Внесение дополнительной погрешности в мерялку возможно повлекло бы за собой необходимость увеличения времени эксперимента, что меня бы утомляло еще больше. А может и не повлекло бы, но я изначально писал код чтобы минимизировать последующее время его юзания, которое включает в себя его запуск и модификацию, если вдруг оказалось бы что нуна чтото менять. Потому я сразу взял максимально тяжелый контейнер и максимально быструю мерялку. А на алгоритм, как вещь в себе — мне пофиг с большего Возможно с помощью этого минимального кода я бы не намерял разницу — тогда бы я написал свой контейнер с итератором который в конструкторе/деструкторе делает Sleep, для эмуляции толстого итератора, но слава оптимизатору, не пришлось — обошлось минимальным примером, использующим максимальные граничные предположения о стандартных контейнерах и функциях.

O>>set здесь как раз таки потому что у него итератор надеюсь тяжелее чем у вектора. Вообще итераторы бывают самописные, а не только у стандартных контейнеров, и может так оказаться, что они будут намного толще и с побочками, изза которых оптимизатор не выкинет лишнюю копию итератора от постфиксного инкремента.
E>Мерять надо не абсолютную величину, а разницу для цикла с префиксным и постфиксным оператором, внутри одного и того же исполняемого образа. То что вы меряли — подправим соберем и померим, потом опять подправим цикл соберем и померяем уже само по себе может дать далекие от реальности цифры (например ОС начала при повторном измерении свопится), либо оптимизатор полностью переделал скелет программы.
O>>Оптимизаторы работают не одинаково на всех платформах. Более того — оптимизация MSVC по размеру (а это — не дебаг) оставила разницу.
E>Оптимизация по размеру (точнее ее выключение) скорее всего развернула цикл, в результате разница получилась за счет отсутсвия джампов. Кстати да, обычно пр тестах, чтобы минимизировать влияние джампов, вручную раскатывают циклы. Плюс к этому, как я уже говорил, меряют разницу а не абсолютные значения.

Фишка в том что пофиг ПОЧЕМУ разница. Главное что РАЗНИЦА ЕСТЬ И раз она есть — значит она МОЖЕТ БЫТЬ. ЧТД.

O>Возможно с помощью этого минимального кода я бы не намерял разницу — тогда бы я написал свой контейнер с итератором который в конструкторе/деструкторе делает Sleep, для эмуляции толстого итератора,

Вот, взял и написал, вернее благодаря своей природной лени кодить (лень — необходимейшая черта любого программера ИМХО ) переделал пример с кодепрожекта, добавив Sleep(100) в деструктор итератора: http://zalil.ru/32416421
Разница на итерировании по 10 элементам — 400msec vs 2400msec. Даже больше и совсем не так, как я ожидал, но да фиг с ним.
На маячащий на горизонте вопрос "А откуда в иераторее Sleep?) предложу потенциальную возможность существования итераторов по файлам/БД, создающих отдельный хэндл/конекшн на инстанс самого итератора. Вопрос эффективности таких итераторов оставим за скобками, факт что они могут быть. + факт того что при некоторых настройках оптимизации на некоторых платформах имеется разница в стандартных контейнерах — то какой смысл спрашивается писать i++, а не ++i, просто потому что "так привык"? Неправильно вы привыкли, фигли

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, MescalitoPeyot, Вы писали:

C>Учитывая, что Андроид существует в публичном виде менее 6 лет, то график слегка веселит.
Не менее веселит то, что, судя по графику, после 7 лет опыта в embedded начинают платить меньше

Здравствуйте, __kot2, Вы писали:

__>программирование на С++ это и есть соб-но программирование, другие языки — лишь попытки упрощения некоторых достаточно узких областей.
Странное заявление. Не затруднит ли аргументировать?

Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, __kot2, Вы писали:
__>>программирование на С++ это и есть соб-но программирование, другие языки — лишь попытки упрощения некоторых достаточно узких областей.
0>Странное заявление. Не затруднит ли аргументировать?
когда появлялся веб и все пользовались нетскейпом мы написали свой первый игровой веб-сервер. он был на С++. потом я еще писал несколько плагинов, которые забирали инфу с бева и прокси-сервера. тоже на ++. но С++ действительно не совсем удобен в этом плане, приходится разбирать текст и нужен более удобный инструмент разбора текста, который к тому же без всякого гемора работает с юникодом. только поэтому и появились (или появились раньше но получили популярность) веб-языки типа perl, php — это все языки быстрого разбора текста. для тех, кто из всего С++ использовал только работу с текстом и ему неохота было разбираться во всем остальном.
в ембедеде и в вебе у криворуких программистов С++ были проблемы — приложения падали и глючили в многопоточности. к тому же работа с БД в С++ никогда удобством не отличалась, а для веба это было очень нужно. Чтобы приложения не падали С++ урезали, сильно проработали над исключениями, занесли код в виртуальную машину и запретили программисту ручками лезть в память. чтобы многопоточность не глючила внесли синхронизацию в язык, для ускорения работы с БД и разбором текста поработали над строками. получилась Java. Microsoft захотел так же, склонировал ее, но решил заодно убить Delphi и сделал так, что в C# очень удобно стало формочки делать.
Javascript это язык позволяющий оживить интерфейс странички. больше он ничего не умеет. это вообще язык дизайнера, а не программиста. вот хочется, чтобы менюшка выплывала слева — вот, javascript.
Lua это язык на котором пишутся скрипты игровых уровней. если бы не было игр, то не было бы Lua.
Ruby вообще был написал японцем. страна, в которой нет своей школы программирования. это в чистом виде велосипед, созданный из-за того, что человек не понял, как пользоваться другим.

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

Здравствуйте, abibok, Вы писали:

F>>Итак С++ — мощная низкоуровневая пушка с кучей возможностей, на этом звере написано почти все крутое и самое сложное )

A>Что, по вашему мнению, в С++ низкоуровнего и о какой куче возможностей, которых нет в других языках, идет речь?

Например, прямой доступ к памяти.

F>>Код на С++ быстрее и эффективнее остальных

A>Как вы понимаете "эффективнее" и чем это отличается от "быстрее"?

Можно ещё уменьшить количество использования оперативной памяти, увеличить шанс попадания в кэш процесоора.

F>>В общем требует четкого понимания что ты делаешь

A>А какая область человеческой деятельности не требует четкого понимания что ты делаешь? На каком языке можно писать программы в стиле "что-то как-то само собой получилось, не знаю даже как это вышло"?

В С++ понимать приходится некоторые детали, которые совершенно не относятся к решаемой задаче.

F>>ты должен понимать почему в цикле нельзя определять переменные, а должен их выносить на уровень выше

Это не аргумент fromegg. Подобное надо будет делать и в других языках (при условии что там есть переменные и циклы).

F>>+ контроль использования памяти

A>Сделал new — сделай delete. Что в этом эзотерического, переводящего С++ в разряд чего-то элитарного?

Это очень сложно. Ведь создают и удаляют в разных местах.
Реализация очень многих алгоритмов упрощается, когда не надо думать об освобождении памяти.
Например простая функция чтения строки с консоли. gets какая-нибудь. Вот как её написать?
Представьте себя её проектировщиком?
Если она принимает указатель на массив и заполняет его, то есть вероятность получить переполнение буфера. Если передавать её размер массива, то что делать, если не хватило? Да и пользователь должен правильно вычислить этот размер. А иногда ещё и массив удалить.
Если выделять память внутри, и возвращать на неё указатель, то кто должен освобождать эту память? Можно сделать какую-нибудь функцию delete_after_get и написать в комментариях, что пользователь должен её использовать. И надеяться, что он читает комментарии.
Можно иметь свой статический буфер и возвращать указатель на него. Но опять же переполнение, плюс пострадает многопоточность.
Ладно, сложности реализации — это на писателях библиотек, но пользоваться ими тоже сложно, т.к. везде нашли свои решения, и надо обо всех их помнить.

Здравствуйте, __kot2, Вы писали:

__>Actionscript это была попытка повышения абстрактной никому не понятной интерактивности интернета. этот язык имел настолько ущербные концепции, и был написан такими жопорукими идиотами, что его в конце концов решили пристрелить. даже такая огромная компания как Adobe не смогла своим авторитетом заставить людей использовать этот кал.

Тем не менее, у него очень мощное коммунити и годные зарплаты разработчиков.
Просто его ниша — не корпоративная разработка формочек, а браузерные игры и интерактивные презентации/тачскрины.

C>Берёшь boost::variant и читаешь. Может поймёшь.

То что программу на BrainFuck трудно читать никак не мешает самому языку BrainFuck быть простым для изучения. И говорит лишь о том, что у этого языка не хватает удобных и выразительных средств для представления данной функциональности. На любом языке можно написать страшную абракадабру, с целью оптимизации или запутывания. Однако для большинства практических задач язык остается достаточно простым в плане "прочитать код и понять как он соотносится с алгоритмом" даже для новичка. Чтобы начать программировать на С++, читать и понимать исходники stl или boost совсем не обязательно. Boost — не язык С++, а библиотека написанная на С++. Видите разницу?