LINUX.ORG.RU

Rust и типобезопасность

 ,


3

7

Решил я тут немного изучить Rust, чтобы не состариться, так и не вкусив плодов современной цивилизации.

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

Почитав документацию:

The as keyword does safe casting

Набросал такой примерчик:

fn main() {
        let a: f64 = std::f64::MAX;  // данное значение просто пример "большого числа"
        let b = a as i64;
        println!("{}", b);
}

Вопросы:

1) С какой стати это вообще компилируется?

2) Да, f64 и i64 нужно одно и то же количество битов для хранения значения, ну и что?

3) Почему результат меняет знак?

Представьте, что какой-то тех. процесс идет, и определенный параметр нельзя изменять скачкообразно, иначе физически система (по крайней мере, один из компонентов) выйдет из строя (встанет в раскоряку, взорвется, выпустит токсичный газ, убивающий 100тыс. населения; нужное подчеркнуть). И вот значение в f64 положительное и увеличивается постепенно, с i64 все вроде в порядке (и тестирование проходит на тестовых значениях), и вдруг хренак! и уже -9223372036854775808

Как так?

★★★★★
Ответ на: комментарий от RazrFalcon

unsafe в rust - фи, а JNI и уязвимости в JVM - это ок. Ну и манёвры.

Если бы ты не торопился и прочел больше трех слов, то увидел бы «Rust не тормозит, безопасен».

Serral
()
Ответ на: комментарий от Serral

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

Тут спасает документация. Даже если её нет, то всё равно можно будет посмотреть на методы и реализованные трейты.

DarkEld3r ★★★★★
()
Ответ на: комментарий от RazrFalcon

Но когда очередной C++-спец начинает рассказывать, что инкапсуляция - это когда программист (а не компилятор) видит код - это клиника.

вы вики для начала про инкапсуляцию прочитайте. https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

Инкапсуляция (англ. encapsulation, от лат. in capsula) — в информатике размещение в одном компоненте данных и методов, которые с ними работают. Также может означать скрытие внутренней реализации от других компонентов.

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

alysnix ★★★
()
Ответ на: комментарий от vertexua

Царь, ты? Где блог написаный с нуля на плюсах?

К слову, а где твой сервак написанный на Rust? Ты ж грозился написать?

Serral
()
Ответ на: комментарий от Serral

Тормозит, но безопасна, удобна для разработки и имеет много батареек.

По поводу удобства Java – это что-то новенькое. Ну хз, давно, к счастью, в сторону Java не смотрел, может из нее какое-то подобие удобного ЯП с годами и сделали.

Там, где можно, чтобы тормозило, Java уже давно живет. А вот там, где тормозить не нужно, лучше уж без Java.

Rust не тормозит, безопасен, но брать его для проекта - риск, да и не факт, что несколько десятков нанятых программистов не окажутся «экспертами» с ЛОР.

Фокус в том, что в наших палестинах найти на рынке что два десятка свободных опытных C++ника, что два десятка нормальных Rust-опрограммиста одинаково нереально. Посему потребуется брать что есть и готовить из них. И вот тут-то, подозреваю, выяснится, что за обозримое время из новичков сделать пряморуких Rust-окодеров будет сильно проще, чем таких же C++ников. Плюс к тому большая безопасность в runtime снизит тяжесть последствий от багов, которые неизбежно в продакшен проберутся. Да и есть надежда, что отлавливать эти баги может быть проще.

Ну и с батарейками печаль.

Далеко не для всех задач, особенно заточенных под производительность, есть нужда в готовых батарейках. Зачастую приходится писать что-то свое, с оглядкой на свою специфику.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

По поводу удобства Java – это что-то новенькое

Инструменты и инфраструктура. Причем не обязательно брать именно Java, можно и Kotlin.

Фокус в том, что в наших палестинах найти на рынке что два десятка свободных опытных C++ника, что два десятка нормальных Rust-опрограммиста одинаково нереально

Я потому и предложил Java :) Джаверов можно по акции на вес брать.

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

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

Serral
()
Ответ на: комментарий от RazrFalcon

И где по вашей ссылке написано о скрытии от глаз программиста?

пока вы не врубитесь в идеальную инкапсуляцию на уровне модулей, в стиле definition и implementation модулей, нам мало есть о чем поговорить. современная кухня в виде - модуль,а то что из него экспортируется помечено внутри декларациями public - это сюр, я не инкапусляция в полном смысле. вы вынуждены давать сорцы человеку, что хотел бы просто выяснить заголовки экспортируемых функций. вы видимо инкапсуляцию понимаете так. а на самом деле инкапсуляция, это когда вы даете модуль дефиниций тому, кто хочет это использовать, а сорцы у вас живут в сейфе и их никому показывать не положено, не положено с силу каких-то соображений.

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

alysnix ★★★
()
Ответ на: комментарий от Serral

то возможность относительно легко прикрутить их хотелку

ХЗ, может в каком-нибудь корпоративном бизнес-софте и можно легко прикрутить хотелку. Типа, нам бы вот такую-то бы выгрузку данных вот в такой формат.

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

eao197 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ну спорить с вашим манямирком я не буду.

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

и это правильный подход к пониманию инкапсуляции. верней она должна начинаться именно с этого. если у тебя распиханная по неймспейсам и классам имплементационаая требуха торчит наружу, и ее видимость именно ВРАЖДЕБНОМУ ГЛАЗУ(коим может быть даже твой коллега с шаловливыми ручками) никак не может быть ограничена средствами языка, то с точки зрения настоящей инкапсуляции это язык фиговый.

alysnix ★★★
()
Ответ на: комментарий от unC0Rr

Ну чувак явно живёт в своей собственной вселенной. Вы его не убедите :)

htower_ ★★
()
Ответ на: комментарий от khrundel

К слову сказать, в моём начальном посте не было ни слова о C++, и я таки нашел в Rust багу за полчаса, или во всяком случае, дефект, не достойный языка с safe-архитектурой.

И есть как минимум 1 язык, который в подобной ситуации диктует хотя бы рантайму адекватное для safe-архитектуры поведение. И это не C++.

Это потом в тред пришли эксперты, и начали сравнивать с C++ (у кого что болит).

Напоминает диспут политиканов:

  • в России тюрьмы переполнены преступниками!
  • а вот в Америке тоже!
seiken ★★★★★
() автор топика
Ответ на: комментарий от red75prim

Весь секретный код должен быть инкапсулирован на air-gapped сервере. API через первый отдел.

в реальности полно случаев, когда нормальная инкапсуляция(в моем понимании) необходима. полезна она всегда, а необходима уже в команде, где доступ к сорцам надо разграничить. Зачем вообще посторонним нужна реализация?

  1. детали реализации могут подтолкнуть к «использованию на основе знания имплементации» - тогда смена реализации может привести к проблемам. также неверное понимание имплементации может к проблемам привести.
  2. исходный код является проприетарным, закрытым к разглашению или еще что.
  3. в команде есть парни, что любят что-то хакнуть, поиспользовать недокументрованные, недоскрытые возможности и это тоже проблема.

короче одни проблемы и радости никакой.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Как-то вы путанно выражаетесь.

Вот, допустим, есть С++ код типа:

class Demo {
private:
   int a_;
   int b_;

public:
   Demo();
   void f();
};

Это определение лежит в заголовочном файле, реализация в cpp-файле. Соответственно, тот, у кого есть заголовочный файл, знает, что внутри Demo есть два int-овых поля a_ и b_.

Вот это знание внутренностей Demo – нарушение вашей инкапсуляции или нет?

eao197 ★★★★★
()
Ответ на: комментарий от unC0Rr

В паскале ровно такая же фигня. А теперь расскажи, как не бывает closed-source модулей для дельфи.

а причем тут дельфи вообще? если там есть настоящая инкапсуляция(о которой я тут толкую), то и слава богу. а если нет…то и бог с ним.

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

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

я могу дать правильно написанные хидеры+ либы

А так же версии компилятора, libc и libstdc++.

В расте можно сделать так же. Дать *.rlib (метаданные включены), доки, версии rustc и libc. И всё слинкуется.

red75prim ★★★
()
Ответ на: комментарий от eao197

Вот это знание внутренностей Demo – нарушение вашей инкапсуляции или нет?

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

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

вот открытость приватных методов - это упущение самого языка, поскольку их можно не декларировать. можно в реализации просто обьявлять байндинги к классу(то есть новый метод, что видит все приватные поля класса), как это есть во многих языках. но у плюсов тут проблема в том, что нет модулей и хидер ни кому не принадлежит. то есть получится, что байндинг можно обьявить где угодно и поиметь доступ к приватным полям, и вся приватность летит к черту. то есть в плюсах декларация ВСЕХ методов в декларации класса есть плата за немодульность и хидеры.

alysnix ★★★
()
Ответ на: комментарий от red75prim

А так же версии компилятора, libc и libstdc++.
В расте можно сделать так же. Дать *.rlib (метаданные включены), доки, версии rustc и libc. И всё слинкуется.

Вот только в одном случае есть обратная совместимость, а в другом нет.

Serral
()
Ответ на: комментарий от red75prim

В расте можно сделать так же. Дать *.rlib (метаданные включены), доки, версии rustc и libc. И всё слинкуется.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

в плюсах инкапсуляция поддержана кой-как существованием хидеров

Я не хочу рушить ваш манямирок, но к растовской либе тоже можно написать хедер. Ибо сишний хедер - это тупо описание интерфейса, который при желании, можно «среверсиженирить».

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от red75prim

Это встроено: cargo doc

средство языка - это его синтаксис и семантика. внешние тулы, представляемые пакетом к компилятору, или даже сама возможность компилятора генерить файлы экcпортов по тексту - это не средство языка.

и потом. дефинишн модуль - это контракт, который должен исполнить модуль имплементации. кто-то пишет дефинишн и отдает на реализацию программисту. программист реализует дефинишн в модуле имплементации(не трогая дефинишн) и компилятор ругается, если не все, что описано в дефинишне, реализовано. то есть соотвествие контракту устнавливается австоматически.

если же у вас эти «контракты» генерятся чем-либо из имплементации - никакого соответствия контракту нет, поскольку нет самого контракта. допустим мне надо 150 функций с такими-то параметрами(что я бы описал в контракте-дефинишене и дал бы вам, но тут все не так). но в вашем случае я дал вам бумажку с просьбой - вот это все реализовать…вы написали нечто, по чему сгенерили экспорты…и как понять, что вы выполнили то, что мне было нужно? вычитывать ваш сгенерированный документ и сравнивать со своей бумажкой?

alysnix ★★★
()
Ответ на: комментарий от red75prim

То есть описание интерфейсов там есть

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

alysnix ★★★
()
Ответ на: комментарий от RazrFalcon

Зачем, когда и так C++ чешется, во всю полыхает.

seiken ★★★★★
() автор топика
Ответ на: комментарий от alysnix

или там может быть описана статическая функция, которой не нужен селф?

Естественно может.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Serral

да и не факт, что несколько десятков нанятых программистов не окажутся «экспертами» с ЛОР

Конкретно эта претензия странная. Не важно какой язык, тебе на собеседование могут прийти чуваки, являющиеся ««экспертами» с ЛОР», что бы это не значило. Тут уже твоя задача их отсеивать. Я бы ещё понял, если бы ты на малое количество потенциальных кандидатов пенял.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Serral

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

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

Ну или объясни о чём мы спорим.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

Кроме того:

  • дефолтное значение параметра нарушает инкапсуляцию. Обычно это или bool, отключающий некоторые шаги алгоритма, в особо продвинутых случаях параметр даже называться будет doNotDoSomething, или реальное значение, открывающее особенности кишок. Иногда, например чтоб установить значение следующего параметра, проще скопировать значение из сигнатуры, потом, когда дефолтное значение поменяется, будет невозможно определить, было ли это значение установлено сознательно, или просто не поменяли синхронно с значением из сигнатуры.
  • дефолтные значения позволяют объединить разные функции в одну, там где по смыслу нужны несколько разных для разных случаев, создают видимого снаружи монстра с кучей параметров, половина из которых будет с дефолтными значениями.
    • что создаёт возможность непредусмотренных комбинаций, которые надо или обрабатывать внутри, или игнорировать риск, что кто-то решит, что такой вариант возможен и получит ошибку в рантайме.
    • затрудняет поиск ненужного кода. Если функция не используется, это позволит обнаружить любое IDE, часто в автоматическом режиме, а обнаружить, что некий параметр всегда равен одному и тому же значению сложно. Соответственно, при рефакторинге придётся поддерживать нафиг не нужный код.
    • при удалении ненужного параметра с дефолтным значением произойдёт сдвиг позиций и, в некоторых случаях, это не приведёт к ошибке компиляции (это также касается перегрузки, но там вероятность чуток меньше).
    • рано или поздно с этой порнографией придётся что-то делать, в язык придётся добавить возможность указывать имена параметров при вызове, линтеры даже будут требовать это, в случаях когда параметров много и в итоге выйдет, что сэкономив на написании трёх методов под разные потребности (которые, возможно, вызывали бы такого же монстра с 10 параметрами, но приватного), придётся каждый раз писать многословный вызов с именованием каждого параметра.
khrundel ★★★★
()
Ответ на: комментарий от DarkEld3r

Конкретно эта претензия странная. Не важно какой язык, тебе на собеседование могут прийти чуваки, являющиеся ««экспертами» с ЛОР»

На других языках много опытных программистов, которые передают друг другу опыт, подзатыльники и рекомендации. А на вакансию Rust пойдут в основном увлеченные фанатики без реального опыта его использования в коммерческом софте, но зато со своим уникальным видением, что правильно, а что нет. Или придут просто те, кому захотелось попробовать что-то новое, и вместо нормального кода они будут пытаться изображать тот же C++ или Java на Rust, и придется тратить массу времени на их обучение и ревью их кода.

Serral
()
Ответ на: комментарий от vlad9486

К приватным полям нету доступа даже через unsafe.

Нет преграды патриотам unsafe для доступа к чему угодно. Для нахождения смещения тоже костыли имеются.

Serral
()
Ответ на: комментарий от RazrFalcon

Это и с С не сработает

Прекрасно сработает.

А можно скачать Qt для MSVC и пытаться использовать его из mingw, но ничего не выйдет.

Мне понравилось описание совместимости ABI у tdm:

Ideally, the binaries and compiled code produced by TDM-GCC would be ABI-compatible with other Windows compilers. This is sadly not the case.

Generated code:

[NO: MSVC]

Microsoft Visual C/C++ generated code is not compatible with GCC unless you are truly elite.

DLL linkage:

[WITH CARE: MSVC]

If you take care to match calling conventions and catch exceptions, C linkage is possible.

C++ linkage for classes is fraught and for STL / libstdc++ objects is not possible.

Maybe there’s a compatibility layer somewhere.

Так что по такому описанию все всегда правы. И те кто говорят что можно и те кто говорят что нельзя :)

fsb4000 ★★★★★
()
Ответ на: комментарий от alysnix

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

https://it.wikireading.ru/27994

alysnix ★★★
()
Ответ на: комментарий от alysnix

в яве,шарпе,русте и проч. нет реальной инкапсуляции на уровне модулей…

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

DarkEld3r ★★★★★
()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от khrundel

Обычно дефолтные параметры используются для быстрого и грязного патча существующей функции под особый случай.

draw_line(color = black) - это будет считаться «быстрым и грязным патчем»?

С некоторыми аргументами согласен, но далеко не со всеми. Спорить особого смысла не вижу. Как по мне, дефолтные параметры позволяют сделать апи удобнее, ну а неправильно использовать можно всё что угодно.

Aнтипаттерн Option как дефолтное значение - ещё хуже, а такое иногда встречается. Опять же, отсутствие дефолтных параметров приводит к таким замечательным штукам в апи как with_capacity, with_hasher и with_capacity_and_hasher. Билдер тоже не всегда хочется городить.

придётся каждый раз писать многословный вызов с именованием каждого параметра

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

В ишью о добавлении дефолтных параметров, которая периодически продолжает вяло обсуждаться, насколько я помню, основным аргументом выступает, что это ещё одна возможность случайно добавить ломающие изменения в апи. Вообще было бы здорово встроить в cargo publish проверку на отсутствие ломающих изменений, если не была увеличена мажорная версия, но это не так-то просто. Конечно, есть rust-semverver, но не знаю насколько надёжно оно работает и, в прошлый раз когда проверял, проверка занимала довольно много времени.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Serral

На других языках много опытных программистов, которые передают друг другу опыт, подзатыльники и рекомендации.

Это довольно оптимистичная точка зрения.

А на вакансию Rust пойдут в основном увлеченные фанатики без реального опыта его использования в коммерческом софте

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

Кстати, я согласен с точкой зрения, которую eao197 тут озвучивал. Недавно как раз собеседовался в одну контору, так они честно и заявили, что у них нет достаточного количества крутых сишников/плюсовиков, а писать надо код относительно низкоуровневый. И раст взяли именно потому, что меньше выстрелов в ногу будет. Говорят, что пока довольны.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

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

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

alysnix ★★★
()
Ответ на: комментарий от fsb4000

Лол, он реально не понимает что там тип из push выводится?

НЕ ТАЙПЧЕКАЕТСЯ

ДИНАМИЧЕСКИЙ ИНТЕРФЕЙС

Kuzy ★★★
()
Ответ на: комментарий от alysnix

Константностью не тривиальных полей ты ломаешь move конструктор/оператор и они в нем начинают копироваться. Это то почему эта константность фактически бесполезна в плюсах.

Kuzy ★★★
()
Ответ на: комментарий от alysnix

Почему бы не почитать что-нибудь про раст и не понять, что никакого виртуального метода и vtable тут нет?

Kuzy ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.