Обновить
154
0.3
Григорий@bfDeveloper

Программист на C++, D, Brainfuck

Отправить сообщение

Как правильно отметили выше, это работает начиная с С++20. До этого было компиляторозависимо, где-то даже работало, кажется в GCC. Но как это часто бывает, свежий стандарт в работе недоступен.

На днях меня очень не порадовало, что structured binding это не объявление переменной. Оно, вроде понятно, но то, что их нельзя захватывать в замыканиях, очень не удобно.

А кто-то эту возможность отбирал? Когда мне захотелось использовать функцию, которую можно сравнить на ==, взял и написал https://github.com/CrazyPandaLimited/panda-lib/blob/master/src/panda/function.h
Она не основывается на std::function, написана на самом C++.
Все типы в std можно написать на C++ без библиотек за исключением std::initializer_list, разве что. Возможно, reflection принесёт большую пачку таких типов, но пока что библиотека хорошо отделена от языка и написана на нём самом.

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

Тема интересная, но так и не понял, какие вы сделали выводы из годового наблюдения. Общую статистику про 60/40 утром/днём понял, но что про рассадки? То, что все хотят сидеть рядом с женщинами это ваше умозрительное заключение или результат анализа наблюдений?

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

Посмотрите на отличия произношения в советских фильмах годов 60-х и страше и вы увидите существенную разницу. В первую очередь в лексике, но и в фонетике тоже. Прямо сейчас идут процессы изменения произношения, не все новые слова подчиняются новым правилам. Да, это связано в основном с заимствованиями из других языков, но сути это не меняет. Грамматические изменения тоже постоянно происходят: кофе не единственный пример. Почему людям не нравился кофе в мужском роде? Да просто звучит как слово среднего. И вот такие "звучит как" будут всегда.
Любая система правил будет слишком сложна для масс, поэтому люди неизбежно будут делать "ошибки" основываясь на своей собственной логике. Люди путают надеть/одеть не потому, что правила плохие, а потому что эти отличия для большинства некритичны. В голове понятие одно, а слов - два, вот и путаются.
Тся/ться не для всех звучат одинаково. Для меня нет разницы, у меня чёткое ЦА, но у других людей я постоянно слышу чёткое проговаривание с хорошми отличием твёрдой и мягкой Т. Люди говорят по-разному. И это в перемешанном и гомогенизированном русском, посмотрите на акценты британцев!
Можно возразить, что, мол, в хорошей системе правил таких проблем будет меньше. Очень сомневаюсь, но допустим. Стоит ли оно того? Точно ли получится что-то ценное?

Большинство сложностей языка определяются его развитием. Я про реальные сложности и неконсистентности, а не те, которые вам не нравятся, потому что их нет в вашем родном языке. Язык меняется каждый день.
Предположим, вы создали идеальный язык и идеальную письменность: 1 к 1, одна буква - один звук, никаких исключений и тд. Уже через пару дней его использования вы услышите диалекты и отличия, среди которых будут побеждать одни, а проигрывать другие. Некоторые звуки при беглом произношении пропустят, некоторые добавят. Любая грамматика будет содержать сложности, которые люди будут путать, сами появятся тся/ться, одеть/надеть, покорёжит смысл как произошло с нелицеприятным, одиозным, утилизацией, экспертизой и тд и тп. Люди не роботы.
Крайне глупо с дилетанским подходом без понимания законов языка лезть и объяснять всем, как сделать идеальный язык. Разберитесь сначала с тем, почему языки такие, какая логика в них. Поверьте, там не только "легаси", там очень много сложных внутренних правил.
Язык - не протокол, но даже в компьютерных стандартах куча разночтений. Хорошие библиотеки json и http умеют читать разные "диалекты", потому что никто не следует стандартам в реальном мире.

А куда воду при этом девать? Допустим вы забрали у неё всё тепло и передали водороду, но сама вода у вас осталась. Везти с собой? Это баласт. Выкидывать? Так вы только что потеряли все свои достижения удельного импульса.

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

После вашего комментария освежил формулу в памяти. Ничего нового не увидел, всё, как я помнил. Где вы там кратное увеличение нашли, там наоборот логарифм? В прямом виде фрумула:
V = I * ln(M1/M2).
M1 - стартовая, M2 - сухая масса. Ну будет под логарифмом на 10% больше, итоговая скорость вырастет на ln(1.1), то есть 9.5% , а никак не в разы. Ну или при фиксированной скорости (выход на орбиту), вся ракета полегчает на те же 10%. Звучит неплохо, но никак не полёт к звёздам.

Откуда вы возьмёте энергию для повышения удельного импульса? Классический РД с соплом уже имеет кпд выше 70%. Даже если вы каким-то электромагическим чудом получите ещё десяток процентов, большой разницы это не даст.
Допустим, вы поднимете тяговооружённость, уменьшив массу двигателя. Но даже у первой ступени двигатели составляют небольшую часть сухой массы (у falcon 9 - 4.4 тонны из 22). То есть в общей сложности можно наторговать лишь проценты стартовой массы ракеты. И это всё при условии, что предложенная схема работает. В чём есть очень много причин сомневаться.

Это скорость из кинетической энергии. V = sqrt (2*E)
Удельный импульс измеряется либо в м/с и равен скорости истечения, либо в секундах и тогда это чуть более сложная концепция со временем работы на 1кн тяги, но по факту отличие в g раз. 3210 это как раз скорость истечения на уровне моря. В вакууме там вообще 3560, что ещё ближе к теоретическому максимуму.

Позволю себе чуть-чуть скепсиса со "школьными расчётами"

Удельная теплота сгорания метана около 50 МДж/кг. В ракете кислород везём с собой, для горения его нужно в 4 раза больше по массе, значит для смеси это 10 МДж/кг. В самом идеальном случае, когда вся энергия горения будет потрачена на движение, скорость истечения будет равна sqrt(2*10^7) = 4472 м/с. Это абсолютный теоретический максимум, не важно, разгоняем ли мы газ соплом или магнитным полем. В реальности же часть энергии остаётся в тепле. С учётом того что Raptor уже взял 3210, простор для оптимизации не так велик, КПД уже больше 50%. Понятно, что скорость в показателе степени в формуле Циалковского, и каждый м/с важен, но даже теоретически, много ли вы сможете предложить?

Очень рекомендую что-нибудь написать на самом Brainfuck и запустить в вашем эмуляторе. Мне в своё время очень помогло получить ощущение контроля:

  • память это ячейки, интерпретируй как хочешь,

  • алгоритмы это про логику, а не конструкции языка

  • в программировании есть свой юмор

Можно. Я почти 10 лет геймдеве (пусть и не ААА) и примерно столько же ни во что почти не играю. На мне это сработало как с колбасой - когда знаешь как делают, сам есть уже не можешь. Очень на многих работает наоборот - так что предугадать сложно.

Могу представить, чем не нравится "выделение" в разных контекстах, можно спутать с выделением (переносом) в отдельный класс/модуль. Но есть же и альтернативы: подсвечивание (дословно highlighting, кстати), обозначение. Да, тут можно спутать с подсветкой синтаксиса (которая тоже highlight), но скорее всего это значение и нужно. В русском произношение хайлайтинга язык ломает, особенно на склонениях. Получится улучшить слайд хайлайтингами?

Чтобы был нужный порядок парентов можно взять theirs

UPD. Попутал, нет theirs как стратегии.

note that, unlike ours, there is no theirs merge strategy to confuse this merge option with.

Это своего рода эквивалент того, что все файлы из старого мастера заменили файлами из нового во время мержа. Внутри гита отличия будут, потому что это два разных дерева файлов, но с точки зрения пользователя отличий нет. Даже blame будет одинаковым.

Но вариант из поста сильно быстрее, если знаешь, что делаешь - не нужен второй чекаут из которого копировать файлики.

Проблема в том, что это не общепринятый термин, это банальный англицизм, который можно заменить на русский эквивалент без потери смысла. Англицизмы сами по себе в профессиональной сфере это нормально, но не когда они пересекаются с существующими русскими словами. Если я скажу, что испытываю симпатию к девушке, то я сочувствую нелёгкой доле (sympathy) или всё же она мне нравится? Жаргон и термины должны избавлять от разночтений, а не добавлять их. В "департаменте утилизации CPU" есть разночтения. Использование б/у железа - очень даже актуальная тема.

Информация

В рейтинге
2 535-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность