In C++, members are destroyed in reverse construction order and the elements of an initializer list are evaluated in lexical order, so field initializers must be specified in order.
Конечно, понятно. По мне, это просто делает нововведение бесполезным. Так можно было бы эмулировать тэгированные параметры функций как в C# — завести параметры по умолчанию в середине, не запоминать порядок аргументов. А тут такая шляпа.
В С не нужно соблюдать порядок элементов, то есть в нашем примере можно сначала инициализировать с, а потом а. В С++ так делать нельзя, поскольку вещи конструируются в порядке, в котором они объявлены.
> Во многих библиотеках (например Qt) трендово сейчас называть методы получения свойств так же как и свойство, что повышает читабельность программы особенно среди англоязычных программистов.
Yes. От безысходности. Но работал довольно давно с библиотекой, там .married() ещё возвращало ссылку на значение вместо поддержки тривиальных сеттеров, так что можно было .married() = false;. С тех пор косо посматриваю на безпрефиксные геттеры и сеттеры. Ну а проблем расширить C# при этом никогда не было: named parameters в C# 4, properties изначально, и т.д. и т.п. (Сам пишу 90% времени на С++).
Идеализм этот с некоторыми от C++, «убрать макросы», ну come on. Как я без макросов организую себе удобоваримые properties в классах, например? Пофиксите мне язык, добавьте адекватные class properties чтобы без этого вот бесконечного .set_value (a.get_value () + b.get_value()), добавьте named orderless function arguments, чтобы я мог тренировать свою память где-нибудь ещё кроме как привязки аргумента к его имени «на глазок», и проводить вечера с семьёй, а не с перетасовыванием аргументов при рефакторинге — вот тогда поговорим о удалении макросов. А пока я это всё только макросами и могу более-менее организовать, чтобы писать линейный код, а не продираться сквозь завалы тривиального синтаксиса.
Может добавим опросник? У меня единицы знакомых программистов из десятков, кто использует темные темы. В основном сидят в светлой, разве что регулируют яркость и юзают f.lux.
Невиртуальный деструктор не обязательно означает, что класс не может быть использован в качестве базового. Это лишь означает, что удаление объекта производного класса через указатель на базовый не будет работать. Мне сложно представить, что в идиоматичном С++17 кто-то будет делать delete именно указателям на вектора. Надо убедиться, что этого нет, и тогда наследование не будет беспокоить. Для кода, который пишут вновь, это возможно сделать. А профит от наследования от вектора хорош — 1) добавленные плюшки в коде очень компактны (не надо по-новой ваять весь интерфейс вектора в своём классе), 2) все, кто принимает вектора или их итераторы, продолжат работать с инстансами и вашего класса. В своём коде сам делаю как Яндекс и очень доволен.
Саша прав про пытливый ум. Это касается любой профессии. Просто врач, не интересующийся своим трудом, просто никого не вылечит. Такие должны менять область деятельности, если им неинтересно – они выбрали не свое дело.
Нет причин проводить водораздел между прикладным и фундаментальным. Гораздо чаще, чем кажется, задачу можно удовлетворительно решить только на более глубоком уровне её понимания, а не одним лишь весёлым кодингом и созданием 100500+ нового JS фреймворка. С другой стороны, склонность людей из академической среды избегать реального мира также широко распространена и требует работы. Людей, эффективно оперирующих на стыке — решающих реальные ПРИКЛАДНЫЕ задачи на адекватном ФУНДАМЕНТАЛЬНОМ уровне — сотые доли процентов в нашей индустрии.
Давно мечтаю о книге, которая бы излагала современные физические концепции для более чистых математиков. Чтобы поменьше текста, побольше формул, и все – ёмко, конкретно и по делу, но при этом доходчиво для математика и метафорично. В стиле пособий от Босса или очерков из журнала Квант, если вы понимаете, о чем я. Пока видны только два экстрима – либо книги без формул вообще, либо фундаментальные учебники, которые, чтобы раскусить, нужны солидные инвестиции времени.
Мне интересно, как развивается технология Компрено в свете развития нейросетевых технологий, ебмедденги, BERT и т.д. В ABBYY была проведена гигантская ручная работа по составлению интерлингвы. Казалось бы, сейчас эта задача решается означенными нейросетевыми подходами.
Благодарю за столь глубокую проработку темы. Если вы решите продолжить работать с темой, может быть, стоит попробовать вот этот подход: habr.com/ru/post/358352? Не исключено, что расширение горизонта прогнозирования на 1 порядок с помощью нейросетей позволит центаврянам отказаться от захвата землян в ближайшем будущем. :)
Гипотетические жители Проксимы-Б тихо захватывали Землю, не обнаружив в земном интернете подобных вот знаний, которых у них не было у самих? core.ac.uk/download/pdf/25201586.pdf :)
Почему не решает? В математике понятие интегрируемости ≡ решению системы в виде явного аналитического выражения. Для трёх тел это, действительно, в общем случае невозможно. Как и отсутствует символьное выражение для многих определённых интегралов. Отсюда и пошёл термин «интегрируемость», кстати. Не берутся некоторые интегралы, ну и интегралу всегда соответствует некоторый дифур. Ну и конечно, неингетрируемость системы, как и неинтегрируемость интегралов, в каком-либо явном символьном виде, не мешает решать их численно. Потому я и никак не избавлюсь от ощущения всего этого романа непростительной окологуманитарной ошибкой. Я уже и читать начал, и только пока укрепляюсь в этом впечатлении. Как, видимо, и комментаторы ниже.
Конечно, понятно. По мне, это просто делает нововведение бесполезным. Так можно было бы эмулировать тэгированные параметры функций как в C# — завести параметры по умолчанию в середине, не запоминать порядок аргументов. А тут такая шляпа.
Который день сижу и плАчу.
Yes. От безысходности. Но работал довольно давно с библиотекой, там .married() ещё возвращало ссылку на значение вместо поддержки тривиальных сеттеров, так что можно было .married() = false;. С тех пор косо посматриваю на безпрефиксные геттеры и сеттеры. Ну а проблем расширить C# при этом никогда не было: named parameters в C# 4, properties изначально, и т.д. и т.п. (Сам пишу 90% времени на С++).
Может добавим опросник? У меня единицы знакомых программистов из десятков, кто использует темные темы. В основном сидят в светлой, разве что регулируют яркость и юзают f.lux.
deleteименно указателям на вектора. Надо убедиться, что этого нет, и тогда наследование не будет беспокоить. Для кода, который пишут вновь, это возможно сделать. А профит от наследования от вектора хорош — 1) добавленные плюшки в коде очень компактны (не надо по-новой ваять весь интерфейс вектора в своём классе), 2) все, кто принимает вектора или их итераторы, продолжат работать с инстансами и вашего класса. В своём коде сам делаю как Яндекс и очень доволен.Саша прав про пытливый ум. Это касается любой профессии. Просто врач, не интересующийся своим трудом, просто никого не вылечит. Такие должны менять область деятельности, если им неинтересно – они выбрали не свое дело.
Давно мечтаю о книге, которая бы излагала современные физические концепции для более чистых математиков. Чтобы поменьше текста, побольше формул, и все – ёмко, конкретно и по делу, но при этом доходчиво для математика и метафорично. В стиле пособий от Босса или очерков из журнала Квант, если вы понимаете, о чем я. Пока видны только два экстрима – либо книги без формул вообще, либо фундаментальные учебники, которые, чтобы раскусить, нужны солидные инвестиции времени.
И по-прежнему никакого курсива. Шёл 2019-ый, ЛОЛ.