Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+59
std::transform( keyframes.begin(), keyframes.end(), std::back_inserter( result ),
boost::bind( & qMakePair< KeyframeType::first_type, KeyframeType::second_type >,
boost::bind( & Prm::TType::view, _1 ),
boost::bind( & Prm::Time::value, boost::bind( & Prm::TType::time, _1 ) ) ) );boost bind головного мозга
Запостил: 
QBatman,
24 Сентября 2014
Follow us!
С введением range-based for loop он стал особенно бесполезен.
Только вот что это за страшное auto&& такое? И вообще с каких это пор появились ссылки на ссылки?
T&& - введённый в С++11 синтаксис. Он означает (в зависимости от контекста) либо rvalue-ссылку (вкратце - ссылку на объект, состояние которого можно украсть, например, временный), либо "universal reference", как правило используемый в шаблонах и позволяющий не дублировать код для константных и rvalue ссылок.
В цикле используется как раз второй вариант - universal reference, см.
rvalue references - это одна из главных и интересных фишек нового стандарта, но в двух словах её не объяснить. Когда понимаешь, что это такое, возникает вопрос - НУ ПОЧЕМУ ИХ НЕ БЫЛО РАНЬШЕ???
По-моему крестобляди решают в новом стандарте проблемы, которые им создал их же инструмент.
Сначала мы сделаем сахарок для неявных созданий и копирований объектов, подчёркиваю неявных.
Объявили — объект, присвоили — объект, return — снова объект.
Проходит дждесять лет, мы вводим какую-то новую непонятную терминологию, новые неочевидные для непосвященных значки для говносинтаксиса уже перегруженного ими по самый крест. Всё только для того чтобы сделать работу компилятора или jita — понять где у нас в программе есть ненужные, лишние копирования и убрать их.
Что же мы имеем в итоге? Новые объекты по-прежнему создаются(sic!) но при этом переносятся ссылки изнутри них. То есть по-просту не выполняется deep copy.
Ждемс новой версии стандарта, с новой семантикой, которая будет подменять ссылки.
Взять к примеру Ржавку - в её синтаксисе указалетей даже матёрые крестоложцы путаются. Хотя вроде с нуля спроектировали, без легаси.
А что сложного?
Конкретно в move-семантике используется факт, что ссылок на объект и его внутренности объекта больше нигде нет.
Чтобы второй delete не привел к крашу.
Так это можно реализовать посредством анализа кода компилятором. Он сам раздуплит и поставит себе флажок что объект никуда не убежал. Зачем выводить на уровень пользователя и вносить в типизацию.
std::move имхо не нужен. Это как inline - хинт который компилятор успешно может херить.
Откуда инфа? Сам придумал?
Объект, из которого вынули душу, должен оставаться валидным объектом, т.е. все его инварианты должны соблюдаться. Потому что как минимум на нём будет вызван деструктор.
Во многих случаях можно ожидать, что замувленный объект стал "инициализированным по умолчанию", т.е. замувленные вектор или строка тупо пусты.
> хинт который компилятор успешно может херить
std::move - это и есть такой хинт. По сути это попытка каста в rvalue-ссылку. Константная ссылка в rvalue не превратится, сколько её не мувай.
Я именно об этом и написал. Только зачем программисту засорять код, попытками сделать работу вместо компилятора?
> Потому что как минимум на нём будет вызван деструктор.
Вызываем на объекте деструктор. delete удаляет душу.
Если ссылка на душу убежала куда-то еще, то что случится delete души в другом месте?
Как он может удалить то, что предварительно вынули? Мув - это не получение копии кишков, это именно извлечение, передача владения. Душа жертвы в результате мува зануляется.
Никакой магии, всё логично и понятно.
delete нового удаляет душу.
Ну правильно.
>Мув - это не получение копии кишков, это именно извлечение, передача владения.
Компилятор должен проконтролировать что ссылка на душу больше никуда не убежала. Чтоб delete нового объекта не сломал другие.
Компилятор и сам умеет синтезировать правильные мув-конструктры для простых классов.
Для сложных самому придётся контроллировать, но там, как правило, можно полагаться на уже существующие мув-конструкторы.
Верно. Если бы не определённые особенности крестов, это вообще можно было б сделать оптимизацией компилятора, не меняя ни байта исходных кодов, и не вводя новый синтаксис.
>Для сложных самому придётся контроллировать
Это как - простые циклы компилятор умеет сам разворачивать, а сложные придется развернуть руками. PHP-way.
Ошибка крестов. Можно было бы убрать это правило, заменив на "объект, который перемещён, не должен никак вообще трогаться ничем, и деструктором тоже".
Кстати, а просто вернуть ссылку на тот объект нельзя было? При этом естественно не выполнять деструктор.
Ну только если он создан на стеке, то тогда перенести его в кучу. Плюс там же может случится инлайн, тогда и вовсе ничего копировать не надо.
В лучших традициях крестоблядства будет создать тип, который представляет объект на стеке и дать программисту руками откастить его в объект на куче и наоборот. Я даже символ могу предложить: auto☰
тут как раз для этого нужен специальный перемещатель
то, что его изначально не предусмотрено дизайном - это косяк, в Аде тоже кстати
По стеку?
Это полезно, но не всегда. Допустим объект так возвращается по цепочке из пучины функций, тогда при определённой вложенности оптимальнее будет положить его в кучу и копировать ссылку, вместо того чтобы постоянно двигать по стеку всё его нутро.
Со стека в область видимости кода, вызывающего функцию.
Хотя есть вариант, когда компилятор видит, что функция работает только с одним объектом и потому можно сразу работать именно с ним, не копируя. В Аде для этого есть оператор
return X do
... -- работаем с X
end do;
чтобы сразу непосреднственно конструировать объект на том месте, где он нужен
Так же верно обратное, когда мы решаем не передавать в метод много аргументов, а делаем один — структуру с ними, и при передаче оной по цепочке методов копируем через стек одну ссылку, а не десяток .
Так а если мы пишем некий обобщённо-шаблонный код и решаем возвращать/передавать его по значению.
А потом мы хотим повторно использовать этот же код, но для довольно тяжелого класса.
Оно в большинстве случаев так и реализовано. Временные объекты автоматически rvalue, компилятору не надо об этом говорить. Локальные объекты в инструкции return тоже неявно становятся rvalue.
Явный std::move нужен, когда вынимаем душу из объекта, который не является временным. Автоматически такое подставлять нельзя - сломается обратная совместимость. Может, кто-то рассчитывал получить именно копию.
Ну вот! Я ж об этом и говорю:
крестобляди решают в новом стандарте проблемы, которые им создал их же инструмент
Сначала мы сделаем сахарок для неявных созданий и копирований объектов, а потом с ним боремся.
О каком сахарке ты говоришь?Идея была в том, чтобы семантика пользовательских классов была максимально близка к семантике встроенных.
Куда лучше необходимости писать отдельный метод или класс на каждый примитивный тип в жабе или работать с чудесными недоковариантными массивами.
Костылей много, но бОльшая часть из них пришла из сишки, а без сишки кресты бы не взлетели.
Если человек явно пишет
y=makeMeACopy(x));
Он наверняка желает получить копию. Никакая обратная совместимость не сломается.
Если ты начал c этого, то от этой семантики уже никуда не убежишь.
В ржавке сделали в таких случаях неявный мув, а для копии нужен clone().
Я не говорю, что в крестах идеально, там хотя бы рационально и объяснимо, и лучше с учётом имевшихся ограничений было сделать сложно (разве что имплисит преобразования в конструкторах было тупостью).
Это ж примитив.
Как копировать сложные объекты сишка не говорит. Вернее говорит: тупо копируй указатель.
Просто скопировать ссылку? Сделать memcopy класса, или сделать полный deep-copy скопировав вложенные объекты и их содержимое.
Это всё особенности крестов, и копирование, имхо ввёдено для того чтоб джва раза не выполнился delete при работе RAII.
В сишке мы ж не можем присваивать массивы, а присваивание указателя структур ничего не копирует.
структуры так же копируются при присваивании
рот в рот значениями
массивы копировать нельзя, да, тут недоработка
но если массив - член структуры, то снова можно
Но неглубоко. Если внутри структуры сидит указатель, то обе копии будут указывать на один и тот же адрес.
Прильните же к слову пророка вашего.
www.stroustrup.com/siblings_short.pdf
www.stroustrup.com/sibling_rivalry.pdf
In the spirit of [10], Classic C breaks [3] by adding structure assignment and structure argument passing to K&R C.
Ну он же их когда компилит, то может выставить для себя внутренний флаг - можно ли этот объект мувать и самостоятельно сделать мув.
По сути в крестах он делает всё то же (выводя что это rvalue-ref), только посредством дальнейшего усложнения языка.
мораль сей басни такова - крестоблядями не становятся, крестоблядями рождаются
А вот физиком, например, можно быть пока ласты не склеишь. Чтобы быть программистом до конца жизни, нужно заниматься теорией, но это для единиц, и в производстве не особо востребовано.
Или в архитекторы, гуро
Если компьютеры милее людей
Любая инженерная специальность имеет те же выводы. А уж что говорить о врачах, учителях, слесарях, музыкантах...
Я практически не встречал программистов со стажем больше 10 лет работающих программистами. (Но людей занимавшихся программированием 10 и больше лет назад встречал относительно много). Поэтому и выводы такие.
Инженеры? Ну я бы не сказал. Мой дядя проработал всю жизнь инженером. Сначала эхолокация на подводных лодках, потом другая всякая электроника связаная с обработкой звука. Сейчас работает в гос. комисси которая занимается проверками соблюдений экологических норм. Как-то в администраторы даже не собирался никогда.
Если речь не о личной встрече, то Кен Томпсон, Роб Пайк, Роберт Лав, тыщи их
Когда работа интересная, можно программировать всю жизнь. Особенно работая в компаниях, где инженеры не считаются людьми второго сорта.
на фоне миллионов - это всего лишь доли процента.
> Это нормально проработать всю карьеру участковым врачем. Учителем - да то же самое.
вот они примеры настоящего успеха и перспективы выбранной профессии - за 30 лет стажа попытаться развиться только горизонтально (только 80% врачей и учителей даже этого не могут, когда на участке ты лечишь всю жизнь только орз парацетамолом, или читаешь алгебру 8 класса 30 лет)
у меня на старой работе был программист, овер 50 лет (для интересующихся - дельфин)
борозды не портил, только здоровье его начинало подводить
сколько было занятых в индустрии разработки ПО 20 лет назад?
ну, вот, 1994 год, что там было?
виндовс 3.11, зачатки сетей передачи данных, о какой индустрии можно говорить, сколько миллионов людей было занято в разработке, хоть 10к наберется?
а ведь, допустим, молодой программист тех времен сейчас был бы как раз 40-50 летним
никто не удивляется, увидев 45 летнего врача или учителя, но wvxvw удивляется, увидев 45 летнего программиста
шок, быть программистом бесперспективно, если хорошо справляешься - вынуждают идти на повышение, идите, дети, в участковые врачи
Я пишу, что встречал достаточно людей занимавшихся программированием 10 лет назад, и при этом не занимающихся программированием сегодня, из чего дефекейт делает вывод, что я не встречал людей занимавшихся программированием 10 лет назад - конечно же, очень логично. 10 лет назад - это не так давно, это всего-навсего 2004 год, какой в жопу Виндовс 3.11? Это ХР доживал последние годы. Программирование как раз подходило к одному из пиков развития (в 2006 случился обвал, но до этого стартапы росли как на дрожжах и их скупали за сумасшедшие деньги всякие американские корпорации).
Откуда взялась цифра 20?
Но я более того скажу: да, участковый врач не чувствует себя ущербным, если проработает на одном и том же месте всю жизнь. Его любят, уважают, никому и в голову не прийдет считать его недоразвитым, если он не делал административной карьеры. Быть врачем - призвание, и люди делают это не только изза зарплаты, а потому, что считают, что это полезное и правильное занятие, которое нужно обществу. Программист, по крайней мере то, что в индустрии называется программистом - это профессия типа "читатель текстов". Через поколение, может два-три таких программистов просто не будет, т.как формальное мышление станет обязательным предметом школьной программы и, следовательно, в программировании останутся только специалисты по программированию (аналогично с лингвистикой: будут только люди изучающие алгоритмы, или переводчики, энциклопедисты, библиотекари, професси просто "писать и читать" не будет).
Если контора государственная, то человек может в ней просидеть до пенсионного возраста и дальше. Если частная - такое маловероятно.
Если область, в которой человек работает, не меняется, то специалист останется ценным хоть до 60. В случае педиатра - дети и болезни из года в год практически одинаковые. Сишка и юниксы просуществуют даже после смерти человечества.
Да даже если государственная, и даже если нет: просидеть, конечно, может, но кто такого человека будет считать хорошим специалистом? - Никто, его будут считать неудачником, или похуистом. Типа как Уолли из комиксов про Диллберта. А почему так? - потому что самореализоваться в качестве "человека делающего сайты на ПХП+ж.скрипт" - нельзя. Любое существо, способное хоть в небольшой степени представить себе что возможно сделать в программировании, окажется в скором времени перед выбором: либо депрессия от повторяющейся, бесперспективной, иррациональной и бесполезной работы, либо начать делать что-то другое.
> либо депрессия от повторяющейся, бесперспективной, иррациональной и бесполезной работы, либо начать делать что-то другое.
По-моему, можно оставаться программистом-практиком и делать всегда что-то новое. Когда надоест делать сайтики на PHP+JS, можно пересесть на ASP.NET можно податься куда-нибудь ещё. В базы данных, высоконагруженные сайтики, написание драйверов, программирование для разных устройств вроде больших железных станков, ... Да и у заказчиков области совсем разные. Физика, математика, биология, ...
Да, надо каждый раз переучиваться и начинать практически с нуля. Но это для тех, кто трудится не ради ЧСВ, карьерной лестницы и прочей ненужной питушни.
Вариантов, на самом деле, гораздо больше. Можно начать пить. Можно натаскивать молодых на предметную область. Или развивать смежную область, чтобы делать свою работу ещё лучше/быстрее/етц.
Бесполезность работы тоже под вопросом: деньги приносит? Удовольствие доставляет? Если есть спрос, то К.О. подсказывает, что это кому-то нужно.
> самореализоваться в качестве "человека делающего сайты на ПХП+ж.скрипт"
Есть многое на свете, друг Горацио. Помимо этих ваших вебов, областей, куда можно приткнуться, овердохуя. Но нет, нужно привести пример самой голимой, динамичной, быстро развивающейся.
Чем это отличается от депрессии?
> Или развивать смежную область,
Чем это отличается от "делать что-то другое"?
> Есть многое на свете
Думай ширше. Это не про ПХП конкретно было сказано. Смысл в том, что то, что сегодня называется программированием, по сути, является своего рода продвинутым (а иногда и не очень) IT. До 15-16 веков в Европе, да и позже тоже, но не в такой степени, была профессия "уметь читать и писать". За нее платили, и вполне прилично. Но потом оказалось, что это умение нужно всем, и профессией оно быть перестало. Та же судьба ждет и программирование (в современном понимании). Не будет веб-программистов. Будут, возможно, редакторы сайтов, которые будут заниматься вещами типа оформления, или заполнения информацией, но не нужны будут специальные люди умеющие только ж.ксрипт и верстку. Редакторы будут уметь ж.скрипт, или чем там будут описывать эти сайты в такой же степени, как они будут уметь читать и писать.
Это сейчас происходит в естесственных науках. Нельзя заниматься биологией, или физикой без того, чтобы программировать. Но биолог себя не считает программистом не смотря на то, что практически все, что делает, это пишет программы. Точно так же, как не считает себя литератором, не смотря на то, что большую часть рабочего времени проводит за чтением и письмом.
я с тобой категорически не соглашусь
возможно, ты себя со стороны именно как писарь домашних страничек и оцениваешь, дело твое
однако, моё мнение как раз противоположное
всё идёт к автоматизации всех сфер человеческой деятельности
программирование - инструмент автоматизации
начиная от бизнес-задач, которые никто и никогда не отменит, перспективной робототехникой, безводительным транспортом, заканчивая умными холодильниками и чайниками
то, что ты можешь починить кран или даже положить плитку в санузле, ещё не значит, что инженеров-строителей и архитекторов уже отменили, потому что читать и писать совсем не то же самое, что знать и применять сопромат
то, что можешь вылечить свою простуду - не значит, что вылечишь аппендицит
то, что можешь ходить и бегать - не значит, что можешь построить самолёт
а вот представить в то, что через много лет нас (наших правнуков) будут лечить, возить, кормить роботы, следить за чистотой, строить жилье и т.д. - я могу
кто будет писать системное ПО для этого всего? каждая кухарка? микро-скрипты в рамках фреймворка - да, как смски, но ничего сложнее, т.к. этим будут заниматься специалисты, как и сейчас
> Чем это отличается от депрессии?
Вероятно, тем, что работа проходит веселее. Не знаю, я не прикасаюсь к алкоголю :) Тут можно было бы дать ссылку на серию South Park про цинизм, но не могу вспомнить, на какую именно серию.
> > Или развивать смежную область,
> Чем это отличается от "делать что-то другое"?
Тем, что это "что-то" пересекается с основной областью. Писал человек дрова под винду, скучно ему было. Взял и перенёс один под линукс. Пример высосан из пальца, но, надеюсь, мысль поясняет :)
> Думай ширше.
Думал! Пассивное микроисследование показывает, что процент людей, которые могут в программирование если и вырос лет за десть, то очень незначительно. Как мне кажется, программист, который переносит в код те же расчетные задачи химиков, биологов, инженеров и т.д., останется отдельной профессией.
Вычислительные мощности машин по архитектуре фон Неймана приближаются к своему потолку, поэтому появляются такие вещи, как OpenCL, CUDA, Мультиклет, квантовые компьютеры и тому подобное. Средства становятся сложнее, появляются новые парадигмы, знать и понимать которые и становится задачей программиста. А химикам, биологам и патологоанатомам такие вещи не нужны, у них своих забот в предметной области хватает.
Я не отрицаю, что вероятно будущее, в котором программист - часть профессии, но сомневаюсь, что это будет справедливо для большинства.
Программирование делает, хоть и не радикально, формальное мышление необходимостью. С другой стороны заучивание перестает быть полезным по двум причинам:
1. Технология меняется очень быстро.
2. Автоматизация.
Успешность водителя такси будет зависеть не от его навыков вождения или знания того, где и в какое время можно найти больше клиентов, а от того, на сколько он сможет запрограммировать автопилот. Люди как бы ни старались не смогут сильно усовершенствоваться, как водители. Если не через десять, то через пятдесят лет компьютеры будут лучше водить машины, чем люди, а имея возможность проанализировать больше данных за короткое время, смогут лучше предсказать где искать пассажиров. Человеку будет просто бесполезно в этом соревноваться.
ой тыж блядь. А лекарства постоянно меняются. Если всех лечить клизмой то оно конечно можно всю жизнь так проработать. Единственная профессия где ничего не меняется это учитель физики в школе. Вот там то вообще ни каких сдвигов. только методы преподавания меняются но на них и забить можно.
Лекарства меняются, состав остаётся приблизительно тем же. Как сбивали температуру десять лет назад парацетамолом, так до сих пор и делают, только с красителями, подсластителями и в яркой упаковке с надписью "фервекс", "колдрекс", "хуйнекс" и т.п.
по простудам вообще всё не так однозначно - если её лечить, то проходит за неделю, а если не лечить - то за 7 дней
так-то дело терапевта заподозрить более сложный и опасный пиздец и выписать направление к специалисту - чтобы от пневмонии или менингита не окочуриться
впрочем, те, кто болеют хоть 2 раза в год, способны вылечить свое ОРЗ сами, без больничного листа
Тебе не пох кто там что крутит?
Делать надо то, что нравится.
а серьезно - никогда не поздно начать делать то, что действительно нравится. Тем более если поступил на прогера и отучился, то видимо душа лежит к точным наукам - математика и физика приветствуют тебя
Разве что дискретная.
Тензоры не вкушал.
Что бы учиться на мехмате математику нужно любить безумно и безответно.
Нельзя любить одну часть математики и плохо переваривать другую.
Если я не понимаю, как это вычислять, значит, для меня этого нет.
А тут из-за специализации вышло, что хуерга Abbath'а - это очевидное понятное явление для kegdan'а, оттого и багор.
хуезабивание - я знаю, что это есть, я знаю, что я не понимаю этого, и мне не нужно это понимать на данный момент
оо-уо теперь ты в армии
нахуй
к году окончания вуза всё повернулось наоборот, и с военки забирали максимум на сборы, давали военный билет в руки и прощались
но если сейчас так, то через 2 года никто не даст гарантию, что снова не станут всех поголовно принуждать к контрактной службе
кроме того, с 3 курса можно уже идти работать и лишний день в неделю тратить с бОльшей пользой
военка, если не ошибаюсь, длилась 6 семестров
семестр - 16 учебных недель
т.е. 1*6*16 = 96 дней
96/22 (среднее число рабочих дней в календарном месяце) = 4.3 трудомесяца
не считая сборов, на которые тебя тоже могут забрать вместо работы
Направление - Фундаментальная информатика и информационные технологии (Компьютерные науки)
Узкой специализации нет
По-моему, надо учиться у сраной жабы и крестов.
Да оно уже давно взлетело. Docker написан на Go. В аппэнджин эксперементальную поддержку добавили. У нас даже в продакшене используется, нехило экономит сервера по сравнению с пистоном.
Нахера вообще пейсон на сервера было тащить? Обезьян проще учить?
>Да оно уже давно взлетело.
Ну вы же понимаете насколько спорное это утверждение?
Дык большая часть веба не cpu-bound. И в общем-то насрать, какой язык будет ожидать запросов от клиента, ожидать чтения с диска и ожидать ответа от СУБД.
> Нахера вообще пейсон на сервера было тащить?
Чтобы побыстрее наваять приложение. На той же жабе всяко больше сил и времени уйдет.
На самом он деле многопоточный сервер не ожидает, он обрабатывает то что пришло раньше. А в рамках большой компании сервер явно не один, потому можно обойтись меньшим числом нод.
Даже в сишке есть select для io.
>Чтобы побыстрее наваять приложение.
Это да. Только потом надо его переписывать.
pypy должен быть стабильно быстрее обычного питона в раз 50.
К сожалению это не так http://speed.pypy.org/
*десятичных порядков
Go became a public open source project on November 10, 2009. After a couple of years of very active design and development, stability was called for and Go 1 was released on March 28, 2012. Go 1, which includes a language specification, standard libraries, and custom tools, provides a stable foundation for creating reliable products, projects, and publications.
With that stability established, we are using Go to develop programs, products, and tools rather than actively changing the language and libraries. In fact, the purpose of Go 1 is to provide long-term stability. Backwards-incompatible changes will not be made to any Go 1 point release. We want to use what we have to learn how a future version of Go might look, rather than to play with the language underfoot.
От них сейчас можно ждать только консервативности и неспешности в добавлении новых фич и сахарозы.
Может потому что не часто захожу с iceweasel браузера, хотя последнее время всё чаще.