• Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
    +2
    Да нет, я проверял только стандартные 12 веток по умолчанию. А Interupted checking как раз говорит о том, что --force я не трогал.

    Я проводил сравнение анализаторов для своего работодателя около года назад. Тогда как раз и пришел к выводу, что Cppcheck работает долго и большая часть настоящих предупреждений относится к стилю. Почему и высказал замечание по поводу ваших результатов первым же комментарием. Я, кстати, нисколько не имел в виду какое-либо «украшательство» результатов, лишь то, что с набором проверок по умолчанию Cppcheck действительно малополезен.
  • Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
    +3
    Не совсем понял, как у вас вышло за 5 минут проверить source-sdk. Я взял все скопом с официального репозитория, запустил cppcheck на четырех ядрах i3-2330M — и он молотил код примерно 20 часов.

    Получилось так:
    2 — (error) Analysis failed
    2 — (error) Internal error
    2 — (error) Invalid number of character * when these macros are defined
    2 — (error) Mismatching allocation and deallocation
    2 — (error) Uninitialized variable
    2 — (error) printf format string has * parameters but only * are given
    2 — (portability) Extra qualification '*' unnecessary and considered an error by many compilers.
    2 — (performance) Possible inefficient checking for '*' emptiness.
    2 — (style) Found duplicate if expressions.
    2 — (style) Variable '*' is allocated memory that is never used
    2 — (warning) '*' should check for assignment to self
    2 — (warning) Suspicious pointer subtraction
    2 — (warning) memset() called to fill * bytes of '*'
    4 — (style) Clarify calculation precedence for * and?
    4 — (style) Checking if unsigned variable '*' is positive is always true.
    4 — (style) Unused private function '*'
    4 — (style) Variable '*' is not assigned a value
    4 — (warning) Using char type as array index
    6 — (error) Array '*' index * out of bounds
    6 — (error) Memory leak
    6 — (performance) Prefer prefix +±- operators for non-primitive types.
    6 — (style) The struct '*' does not have a constructor.
    6 — (warning) Redundant assignment of "*" to itself
    8 — (error) Resource leak
    8 — (style) Unused variable
    10 — (warning) A boolean comparison with the string literal "*" is always true.
    10 — (error) Null pointer dereference
    12 — (style) Checking if unsigned variable '*' is less than zero.
    24 — (style) struct or union member '*' is never used
    32 — (style) Same expression on both sides of '*'.
    38 — (error) Possible null pointer dereference
    38 — (style) Consecutive return, break, continue, goto or throw statements are unnecessary
    76 — (style) Statements following return, break, continue, goto or throw will never be executed
    158 — (warning) scanf without field width limits can crash with huge input data
    182 — (warning) Redundant code
    256 — (style) Variable '*' is assigned a value that is never used
    334 — (style) The scope of the variable '*' can be reduced
    348 — (style) The class '*' does not have a constructor.
    1438 — (information) Interrupted checking because of too many #ifdef configurations.
    1728 — (style) C-style pointer casting
    4720 — (warning) Member variable '*' is not initialized in the constructor.

    Total: 9496


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

  • Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
    0
    Ну, строго говоря, это нормальная практика. Klocwork тоже цены не публикует. Но всегда можно связаться с менеджером, договориться. Для такого рода продукта это нормально.
  • Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
    +10
    А мы обсуждаем методику исследования, или хорошесть Cppcheckа?
  • Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
    +6
    Fair enough. Действительно, разгребать всякие inconclusive, performance и portability может быть весьма непросто. Но как раз самые серьезные ляпы там и находятся. Например, у меня недавно было inconclusive срабатывание такого типа:

    memset(ctx, 0, sizeof(ctx));

    (warning, inconclusive) Size of pointer 'ctx' used instead of size of its data.


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

    Или, например:

    if(time_cicl<0) time_cicl+=86400;

    (style) The unsigned variable 'time_cicl' will never be negative


    Очевидная ошибка программиста.

    Или так:
    if((bResultRead[0].bPortValue1[28]&2)!=1)

    (style) The expression '(X & 0x2) != 0x1' is always true


    Очень много действительно важного идет как style. Практически все логические ошибки, дубли веток, мертвый код и так далее. Но да, вычленять это все среди рекомендаций непросто.
  • Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
    +7
    А почему для Cppсheck включены только errors и warnings? Если уж считать результативность анализа в найденных штуках, было бы честно сделать --enable=all, а неинтересные сообщения отсеивать через --suppress.

    Он, кстати, будет работать значительно медленнее, если в проекте много вложенных веток препроцессора. Они обычно плодятся как раз в процессе отладки, а в более-менее финальной версии режутся. Поэтому если проверять чужие проекты — да, будет быстро. Если свои в самом разгаре рабочего процесса — быстро не получится. Можно, конечно, поотсекать отладочные ветки через -U, но это надо постоянно перенастраивать анализатор под проект. Да и не факт, что отладочные ветки не нуждаются в анализе.
  • Анализируем исходный код с помощью cppcheck
    0
    CppCheck можно подключить к студии как внешний инструмент. Там есть флажок --template=vs как раз для форматирования вывода под студию. Работает с любой версией начиная с шестой.
  • Objective-D — альтернатива или дополнение к Objective-C
    +1
    Однако, иногда имена параметров излишни, поэтому в Objective-D их можно опустить.


    Это не работает. Именованные параметры есть и в питоне, и в шарпе, и вообще много где. Но если их можно опускать, их будут опускать.

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

    Для С++, кстати, есть Cocos-2dx. Но он откровенно отстает от оригинала.
  • Objective-D — альтернатива или дополнение к Objective-C
    +5
    Строго говоря, как Objective-J не имеет ничего общего к J, так и Objective-D имеет право не иметь ничего общего с D.
  • Цветовая азбука
    +2
    Идея-то интересная. Но типографике как дисциплине уже много сотен лет, все нюансы со знаками, кернингом, полями, интервалами отработаны очень большой практикой. А нюансы эти как раз и нужны для того, чтобы сделать текст легче читаемым. Вряд ли можно просто заменить буквы квадратами и оставить при этом все преимущества обычной книжной верстки.

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

    Было бы еще интересно увидеть цифры какого-нибудь исследования. Мол, у такой-то группы читалось столько-то слов в минуту, после какого-то времени тренирововок стало читаться столько-то.
  • Почему [не]нужно комментировать код
    +8
    Давайте начистоту. Если
    в реальной жизни, не всегда получается выдавать красивый и логичный код

    то и
    быть внимательным, и не забывать исправлять комментарии при исправлении кода

    тоже не получится.

    С одной стороны, комментарии — зло, хотя и зло разной степени необходимости. Я сейчас сталкиваюсь с проблемой, что даже в экстремуме: устаревший ассемблерный код, тонны его, — комментарии помогают и путают примерно одинаково. Нет абсолютно никакой гарантии, что в коде слева от комментария происходит именно то, что в нем написано. Все критичное приходится проверять и перепроверять в коде. Комментарии сильно помогают в том, чтобы понять общую суть, помогают ориентироваться в тексте программы, помогают быстро пролистать много страниц по диагонали. Но в деталях на них полагаться нельзя, а детали как раз и важны в первую очередь.

    Проблема в том, что есть множество инструментов для валидации и верификации кода. Есть статические и динамические анализаторы, есть профайлеры и отладчики, есть модульное, интеграционное, регрессионное тестирование. А вот комментарии верифицировать можно только вручную и только через ревью.

    Можно, конечно, формализировать ревью. Взять, к примеру, методику Фагана, она правда тоже для кода, а не комментариев. Но она требует участия минимум трех участников на протяжении часа-полутора и позволяет инспектировать 200-300 строк за сессию. Это очень долго, дорого и никогда не применяется для комментариев. Вообще никогда. А вот документация, например, там где надо, в рамках формальной процедуры верифицируется.

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

    Но с другой стороны, с кодом всегда что-то не так. Такая уж природа ПО. Считается, что хороший софт имеет плотность дефектов менее одного на тысячу строк кода. То есть даже при самых жестких V&V процедурах, никто и не ожидает, что программа будет безошибочной. Всего лишь дефектной в рамках дозволенного. Даже если процедура утверждает, что дефектов нет, это означает только то, что они не были найдены в рамках конкретной процедуры. Нулевая плотность дефектов — это не гарантия, а обещание.

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

    Но и если кто-то думает, что может сделать свой код лучше комментируя все подряд без очевидной необходимости, это тоже самообман. Поддержка комментариев стократно сложнее поддержки кода, а внимания ей уделяется несравнимо меньше.
  • [Неочевидные алгоритмы очевидных вещей] Алгоритм 2. Принадлежность точки треугольнику в пространстве
    +5
    Не надо трогать Герона. Можно взять сумму векторов векторных произведений от точки к вершинам (главное не потерять порядок) и сравнить квадрат ее нормы с квадратом нормы векторного произведения двух любых сторон. Это те же площади, но без корней и конских формул, а если компилятор позволяет, еще и с мультискалярными операциями на всех векторных вычислениях.
  • Язык программирования J. За что любить?
    0
    К слову сказать, Айверсон придумал APL (IBM) именно как разновидность математической нотации. Новая нотация должна быть проще, логичнее и удобно записываться в строчку. Ну и в целом у него получилось. К классической нотации даже до учебника по высшей математике привыкают лет десять, APL можно освоить за семестр или два.

    J страдает не из-за плохой нотации, а из-за неподходящих средств ее выражения. Нотация хорошая. Но для того, чтобы читать J, надо не просто знать нотацию, а еще и то, как он ложится на ASCII. Это двойной барьер для восприятия, да. Хотя и преодолимый.
  • Язык программирования J. За что любить?
    0
    Проблема читаемости J в том, что это адаптация APL под ASCII. Нотация APL непривычная, но неплохая. Не хуже привычной математической. Конечно, если взять его графемы и «втиснуть» в алфавит телетайпа, получится плохо. Это примерно как писать по-русски латиницей, только в восемнадцать раз хуже.

    И вот меня все не покидает одна забавная конфабуляция: APL на планшетах. Символы можно рисовать пальцем, например, можно выбирать на нарисованной клавиатуре. Хранить код в уникоде вообще не проблема. Краткость в условиях небольшого экрана — огромный плюс. Мне почему-то кажется, что для обработки каких-нибудь данных в полевых условиях это все было бы полезно и интересно.

    Но почему-то J под андройд есть, а APL нет.
  • О бедном Фортране замолвите слово
    +5
    Нетрудно заметить, что как мы думаем, так и записываем код

    Обратное верно. Программированию стоит учиться, чтобы научиться думать больше и лучше.

    Например, лисп, пролог, смолтолк и D несут в себе заряды идей, которые меняют во многом сам образ мышления. Пролог ломает голову декларативностью, лисп — макросами, смолтолк — объектами и интерфейсами, D — статическим метапрограммированием. Поломанная голова срастается и становится крепче, чем была когда-либо до этого. Суть такого обучения понятна и очевидна.

    Фортран же, равно как и питон и даже С++ — языки практические и потому неинтересные. Они во многом впитывают чужие идеи, подстраивая их под свой синтаксис и свою инфраструктуру. Плюсы, например, имеют и объекты, и метапрограммирование, и функции как объекты первого рода, но все это намного больше похоже на эмуляцию, чем реализацию. Как говорил Алан Кей: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++».

    Поэтому может Фортран и годится в качестве первого языка, но разве что первого. С дидактической точки зрения он не так уж ценен.
  • Почему будущее за удалённой работой (часть 1)
    +1
    Офисное пространство на этом фоне может показаться просто рабочим раем — особенно часто такое мнение встречается среди тех, кто пробовал какое-то время работать удалённо, но не сумел правильно всё организовать и вернулся в офис.

    Потому что офисное пространство и предназначается для работы. Сделать его раем — работа работодателя.

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

    Меня все время, что я работал удаленно, не покидало чувство, что я в танке заряжающий. Вроде как что-то происходит, кто-то побеждает, а я только снаряды забрасываю и гадаю на копоти: нас, или мы? Чтобы притупить это чувство пришлось съездить в Киев, поймать там лида, чтобы он мне за полчаса нарисовал на бумажках, что вообще происходит. Этот разговор оказался полезнее, чем вся проектная документация.
  • По поводу создания российско-патриотических игр
    +7
    А играть в них — жадные дети бездарных чиновников. И прекрасно! Пусть круг замкнется.
  • Делаем Refal на Prolog. Магия в семь строк
    +1
    У меня лежит дома ГОСТ на АГЛАМС. На самом деле это Алгол, но советский. Не уверен, что это считается самостоятельным языком, но создано в СССР, да.

    Книжечка, кстати, страниц тридцать со всеми формальностями.
  • Останется только несколько
    0
    Я так думаю, если книга хорошая, то она увлекательная, аддиктивная. Если аддиктивная, то это наркотик. А если наркотик, то и распространять его надо через криминальную сеть пушеров. Тогда да, цены по 500 евро за том никого особо не удивят. И да, аресты, облавы, книжная мафия, изъято три тонны подпольной литературы, — вся эта романтика обязана присутствовать. Иначе за что платить-то?

    А если книга плохая, то ее издавать и вовсе не стоит.
  • Язык программирования J. Взгляд любителя. Часть 1. Введение
    +1
    А хорошая идея в общем-то. Странно, что никто еще не сделал такого.
  • Метод генерации тестовых заданий на основе деревьев И/ИЛИ и его программная реализация
    +1
    Как всегда хочется несферических примеров. Я своим студентам контрольные генерировал скриптом. Это действительно удобно и здорово. Но увы, получалось все-таки не так сказачно, как в примере с Аней-Светой-Мариной, потому что воросы касались вещей весьма конкретных, например, делегатов C#, и пространства для рандомизации вопросов фактически не получалось.

    Даже просто перемешать вопросы по билетам, чтобы билеты не повторялись — уже не вполне автоматизируемая задача. Некоторые вопросы просто не должны стоять рядом, потому что один является ответом на второй. Я обычно билеты генерировал с запасом, а потом фильтровал выдачу вручную, как Лукашенко в анекдоте. Вот поэтому было бы здорово посмотреть, как ваш метод работает на практике.

    И еще отдельный вопрос. Там где, например, решить уравнение. Задание я построю, ок. А решение? Ну ладно линейное уравнение, а если что-то поинтересней?
  • Язык программирования J. Взгляд любителя. Часть 1. Введение
    0
    Да, это я в курсе. Но J по большому счету и нужен для того, чтобы можно было в ASCII. А вот APL потрогать (буквально!) было бы по меньшей мере забавно.
  • Язык программирования J. Взгляд любителя. Часть 1. Введение
    +1
    Кажется, я где-то слышал про попытки возродить APL на планшетах. Нет клавиатуры — нет проблемы с символами, стилом или пальцем можно нарисовать что угодно.

    Одно но, я не уверен, что это мне не приснилось.
  • Что такое скрипты и с чем их едят — Lua & C++
    +3
    Первая мысль — написать свой интерпретатор своего скриптового языка, выкидывается из мозга через несколько секунд. Логика игрока определенно не стоит таких жутких затрат.


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

    Первый мой опыт в этой области касался AngelScript. Ну, это было давно, Луа еще был не на слуху, а вот этот ангельский скриптец казался нам тогда вполне годным. К тому же у него был сиподобный синтаксис, что с нашей программистской точки зрения было несомненным плюсом. Мы прикрутили скриптовый движок и тупо вывели интерфейсы один в один, но не все. Получилось, что у нас есть язык, на котором предполагается писать логику игры, который хуже чем плюсы, имеет меньше возможностей, чем плюсы, но при этом похож на плюсы и чтобы пользоваться им, надо знать плюсы. Скриптеры посмотрели на это дело, сказали: «как-нибудь в другой раз». В итоге сцены на всем этом мы же и писали, потому что больше некому.

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

    А вот в третий раз от меня ненадолго отвернулось начальство, и, пока никто не видит, я внезапно написал собственный язык с блекджеком и шлюхами. Точнее, писал его не я, я только программировал. Сам язык создавал по-сути Женя Гомельский, геймдизайнер, который просто знал, чего хочет и умел это сформулировать. Язык получился местами очень даже ничего. Там были предлоги, похожие на именнованные параметры в Обджектив-Си, местоимение «it», как в Хаскелевском ghci, метапрограммирование в стиле миксинов Ди, и даже некоторые уникальные вещи, как, например, переменная по умолчанию. Ну, можно было, например, написать цикл так: [for {i=0} {i++; i<10}], а можно так: [10x]. Во втором случае счетчиком цикла считалась переменная по умолчанию "?".

    Мы выпустили с ним пару проектов, вполне между прочим успешных, а потом перешли на новую платформу и забросили скрипты вообще в пользу машины состояний и визуального программирования. И, честно сказать, это было определенное облегчение. Писать языки надо уметь, я не умею. Кроме красивых фичей, он закономерно оброс костылями и велосипедами. Если код на языке был вполне даже читаем, то код самого интерпретатора заболотило по самые осины. Его стало очень сложно поддерживать. Причем, не само ядро, конечно, там-то как раз ничего сложного изначально не было, а вот все эти «концы». Например, в одном проекте меню выезжает справа, в другом — снизу, и в язык попадают, условно говоря, две взаимоисключающие функции для красивого выезда меню. И вот так вот все.

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

    А туториал годный, кстати.
  • Шесть загадок по С++
    +1
    Целый арсенал таких перегрузок для увольнения: gist.github.com/aras-p/6224951 :-)
  • Шесть загадок по С++
    +11
    Деление флота на ноль вполне соотвествует IEEE 754. Именно поэтому в HICPP рекомендуется в таком случае вводить какие-нибудь предусловия. Пусть лучше грациозно падает прямо сейчас, чем когда-нибудь еще.
  • Эдвард руки — С++
    0
    Спасибо, исправил.
  • Эдвард руки — С++
    0
    Есть, и вообще его там и надо :-)
  • Эдвард руки — С++
    +1
    Ну, как-то начал: github.com/akalenuk/la
  • PVS-Studio. Отсчёт цен в обратную сторону
    +2
    Ни в коей мере не склоняю! Уж что-что, а второй Cppcheck никому точно не нужен. Наоборот, пытаюсь сказать, что конкуренция на поле статических анализаторов из коробки бесполезна, потому что с одной стороны PRQA и LDRA с огромным штатом и десятилетиями научной работы, а с другой стороны подпирает Cppcheck, который становится лучше и лучше и привлекает все больше людей. Надо выходить за рамки этого поля.

    На самом деле, практически все крупные игроки уже предлагают инжениринговые услуги того или иного рода, но на этом поле вполне реально с ними потягаться. Например, в случае адаптации того же анализатора под внутренние стандарты большинству отечественных контор старой школы банально проще составить ТЗ на русском и по ЕСПД, чем залазить в дебри международного сотрудничества.
  • PVS-Studio. Отсчёт цен в обратную сторону
    +7
    Это может взлететь как рекламная акция. Действительно отказаться от препроцессирования для гитхаба, собрать пауком 100500 проектов, загрузить ими свободное время сервера, отчеты с дефектами разослать авторам с объяснением, почему с препроцессированием (и регулярное использование, раз уж речь зашла) было бы еще круче.

    Если бы мне пришло на почту, мол, в таком-то файле на такой-то строке дескриптор потек, я бы заинтересовался.
  • Эдвард руки — С++
    +1
    В Джулии просто целый зоопарк разложений, там писать и писать :-)

    Ок, почитаю-поиграюсь с языком, в понедельник определюсь окончательно. Кое-что я уже переписывал на плюсах, питоне и шарпе, — в принципе видение задачи есть. Меня, конечно, смущает, что про D я пока только введение Александреску читал, но с другой стороны не боги горшки обжигают: будет востребовано — будет комьюнити, будет комьюнити — научат как надо.
  • PVS-Studio. Отсчёт цен в обратную сторону
    +1
    Просто отвечаю на предыдущий комментарий. Раскрывать код — не страшно.
  • PVS-Studio. Отсчёт цен в обратную сторону
    0
    У нас в отраслевом стандарте прописана независимая верификация. То есть исходники не просто можно, а обязательно необходимо показать независимым специалистам.
  • PVS-Studio. Отсчёт цен в обратную сторону
    +9
    Самый ваш опасный конкурент — не Gimpel и Coverity, а CppCheck, как ни странно. Он открытый и у него 77 контрибьюторов. Да, он кривоват, и ложных срабатываний там многовато, и не все проверяется достаточно хорошо, но это живой проект, в который имеет смысл инвестириовать время и деньги. Лучше вложить в проект, который развивается сообществом и кастомизируется под наши нужды, чем в коммерческий проект, который сегодня есть — завтра кризис.

    С другой стороны, определенная ниша CppCheck не покрывается. Например, у нас на фирме ветер дует в сторону внутреннего стандарта на С++. Потребуется инструмент для поддержки этого несуществующего стандарта. Вот перепилить Cppcheck под него можно, конечно, но получится плохо, долго и дорого. Потому что хорошо мы делаем железки для АЭС, а не статические аназизаторы. Нам проще, соотвественно, купить статический анализатор с грамотно кастомизированной сборкой правил, чем делать ее самостоятельно. И за это уже можно и заплатить хороших денег.
  • PVS-Studio. Отсчёт цен в обратную сторону
    +2
    Кто-то по такой модели уже работает. Veracode, кажется.
  • Эдвард руки — С++
    +1
    А что именно вам нужно от библиотеки ЛА? От предметной области сильно зависит скоуп такой библиотеки. В геймдеве, например, не нужны обобщения векторных произведений, а в деформативном моделировании — суперскалярные операции.

    Вообще, я давно хотел попробовать D, ну и с линейной алгеброй немного знаком. Если это кому-то надо, могу попробовать заняться.
  • Эдвард руки — С++
    +2
    Я думаю, к этому разговору можно будет вернуться лет через двадцать.
  • Эдвард руки — С++
    +1
    Например, map. Функция, которая применяет функцию к каждому элементу чего-либо. Как for-each. Разницы на самом деле немного. В Питоне, например, циклы сделаны в императивном стиле, но фактически работают над ленивыми списками.

    Ну и классика — рекурсия. В теле функции проверям: если счетчик дошел до конца, ничего не делаем, если нет — делаем что-то, запускаем саму же функцию с подвинутым счетчиком. Сперва выглядит неуклюже, но это дело привычки.
  • Эдвард руки — С++
    +3
    Имеем функцию, принимаем объект константно по значению, создаем новый объект в контексте, делаем с ним все что угодно, возвращем по значению (кстати, перемещение тут работает норм). GC не нужен.

    В принципе мы можем вообще не создать ни одного объекта вне контекста той или иной функции.