И опять ни слова о связности... Похоже её в этом чипе просто нет (если там вообще есть хоть что-то, в чём, как уже написали выше, есть большие сомнения).
Вообще-то в оригинале "зачем идти пешком, когда можно ехать верхом" и фразу это говорят погонщики силтстрайдеров, очевидно подразумевая поездку на силтстрайдере. Так что фраза как фраза и отсутствующие лошади в ней не упоминаются.
когда у тебя реальный коммерческий проект, разбросанный по 50 000 файлов, где в каждом файле класс с пространствами имён, вызовами методов и функций, в которые нужно проваливаться и ходить по цепочке вызовов
... и кастомной ни с чем не совместимой системой сборки, ничем не анализируемой, так что в IDE это всё не засунуть никак. И разумеется всё это не поддерживает отладку ни в каком виде.
И нет, разница не принципиальна. Да, всё делается медленнее, да искать функции грепом, чтобы "провалиться" не так удобно как делать это нажатием одной кнопки. Но никакой "невозможности" даже и близко нет. Просто немножко неудобно. И это речь о поддержке, а уж при написании нового кода даже и в производительности при написании в "блокноте" и IDE разницы практически не будет. Просто не всем нравится, потому что неудобно.
Классическое ООП — это конечно плохо, хотя оно и дало много хороших идей, которые ныне применяются даже и в не-ООП языках.
Но! Вот уже много лет я пытаюсь сделать библиотеку виджетов (в моём случае псевдографических виджетов, но это не важно) без ООП. И хотя я вроде добился определённых успехов в очередной попытке, всё же есть определённые проблемы — прежде всего с кастомизацией. И я не вижу как решить эти проблемы без использование полноценного ООП с наследованием классов.
Реалистических (от слова "реализм") интерпретаций, притом ясно и отчётливо сформулированных, никогда не было много, хотя и побольше чем "парочка". А вполне удовлетворительных, не имеющих серьёзных проблем, — было ноль и остаётся ноль. Сколько же из них прямо "зарубленных" сказать сложно — вы не найдёте публикаций вида "X interpretation is proved wrong" если будете искать, так что тут надо опираться на собственную экспертизу и остаётся под вопросом насколько полученные таким образом выводы можно считать общепринятыми.
Это серая зона. Формально UB до C++23, но по весьма забавной причине: из-за сборщика мусора. На который никто обычно никак не рассчитывает при написании C++ кода, но возможность наличия которого учтена в стандарте. Источник: https://pvs-studio.ru/ru/blog/posts/cpp/1178/
Насчёт "равномерности распределения". Масса чёрной дыры — понятие довольно условное. Дело в том, что гравитационное поле чёрной дыры на большом удалении такое же, как поле некоего сферического тяжёлого объекта в ньютоновской (нерелятивистской) гравитации. Вот массу этого эквивалентного тяжёлого объекта и называют массой чёрной дыры. Но она, эта масса, не образована веществом чёрной дыры, вещества там вообще нет, если оно и было — то упало в сингулярность. Про заряд сказать не могу ничего, только что "всё сложно".
Просто есть три ступени развития программиста: до-ООП, ООП и после-ООП. И хотя для человека, который сам находится на средней ступени (ООП), код после-ООП может быть неотличим от кода до-ООП, реально они очень разные. А некоторые достигнув стадии после-ООП по привычке называют и считают свой код ООП, хотя это уже нечто иное.
Если как в Rust можно объявить интерфейс и тут же его реализовать для нужных типов — то да, вполне эквивалентно получается. К сожалению в том же C# так нельзя и реализация всех интерфейсов должна быть одном модуле с объявлением класса, что несколько ограничивает.
Я пробовал — уже сейчас наследование можно довольно неплохо эмулировать сочетанием portrait и моего dynamic-cast. Чуть-чуть многословно и есть трудности с изменением иерархии (так как каждый наследник должен перечислять всех предков при объявлении), но жить можно.
Очень просто. Делается алгебраический тип данных и далее можно определять сколь угодно много точек с полиморфным поведением без всякой связи с объявлением самого типа.
Разве это проблема ООП, а не плохого программиста, который создает непонятные иерархии?
Именно проблема ООП, которое позволяет и подталкивает к такому. В большинстве случаев наследование реализации вообще не нужно, но у ООП-программистов нет идиосинкразии к этому, а у кого есть — значит он уже начал расти за пределы привычного ООП-подхода.
то же как раз кейс, где ошибочно использовать абстрактный класс, а нужно использовать интерфейс
Класс, интерфейс — неважно, проблема остаётся. Причём проблема элементарно решаемая средствами функционального программирования.
И опять ни слова о связности... Похоже её в этом чипе просто нет (если там вообще есть хоть что-то, в чём, как уже написали выше, есть большие сомнения).
Вообще-то в оригинале "зачем идти пешком, когда можно ехать верхом" и фразу это говорят погонщики силтстрайдеров, очевидно подразумевая поездку на силтстрайдере. Так что фраза как фраза и отсутствующие лошади в ней не упоминаются.
... и кастомной ни с чем не совместимой системой сборки, ничем не анализируемой, так что в IDE это всё не засунуть никак. И разумеется всё это не поддерживает отладку ни в каком виде.
И нет, разница не принципиальна. Да, всё делается медленнее, да искать функции грепом, чтобы "провалиться" не так удобно как делать это нажатием одной кнопки. Но никакой "невозможности" даже и близко нет. Просто немножко неудобно. И это речь о поддержке, а уж при написании нового кода даже и в производительности при написании в "блокноте" и IDE разницы практически не будет. Просто не всем нравится, потому что неудобно.
Какая отборнейшая чушь. Да, в IDE чуть-чуть поудобнее, но совершенно не принципиально. Может и остальная аналитика такого же уровня?
Вы исходите из того, что кто больше работает, тот больше делает. Но в общем случае это неверно.
Классическое ООП — это конечно плохо, хотя оно и дало много хороших идей, которые ныне применяются даже и в не-ООП языках.
Но! Вот уже много лет я пытаюсь сделать библиотеку виджетов (в моём случае псевдографических виджетов, но это не важно) без ООП. И хотя я вроде добился определённых успехов в очередной попытке, всё же есть определённые проблемы — прежде всего с кастомизацией. И я не вижу как решить эти проблемы без использование полноценного ООП с наследованием классов.
Реалистических (от слова "реализм") интерпретаций, притом ясно и отчётливо сформулированных, никогда не было много, хотя и побольше чем "парочка". А вполне удовлетворительных, не имеющих серьёзных проблем, — было ноль и остаётся ноль. Сколько же из них прямо "зарубленных" сказать сложно — вы не найдёте публикаций вида "X interpretation is proved wrong" если будете искать, так что тут надо опираться на собственную экспертизу и остаётся под вопросом насколько полученные таким образом выводы можно считать общепринятыми.
Это очень однобоко. Например, ни слова что в Rust есть ADT, а в Vale нет (по крайней мере пока).
Очень странный код. Наверно я чего-то не понимаю. Почему не написать
let str_bytes: &'static [u8] = b"abcdefg";
?
Ну если не перегонять в
uintptr_t, то конечно это UB везде. Но перегнать-то несложно.Это серая зона. Формально UB до C++23, но по весьма забавной причине: из-за сборщика мусора. На который никто обычно никак не рассчитывает при написании C++ кода, но возможность наличия которого учтена в стандарте. Источник: https://pvs-studio.ru/ru/blog/posts/cpp/1178/
Насчёт "равномерности распределения". Масса чёрной дыры — понятие довольно условное. Дело в том, что гравитационное поле чёрной дыры на большом удалении такое же, как поле некоего сферического тяжёлого объекта в ньютоновской (нерелятивистской) гравитации. Вот массу этого эквивалентного тяжёлого объекта и называют массой чёрной дыры. Но она, эта масса, не образована веществом чёрной дыры, вещества там вообще нет, если оно и было — то упало в сингулярность. Про заряд сказать не могу ничего, только что "всё сложно".
А что, у Бугаенко были хорошие и правильные идеи? На мой взгляд у него были идеи как сделать код ужасным с точки зрения архитектуры.
А что для вас "длина строки"? Количество кодепойнтов? Количество графем? Ширина графем в моноширинном шрифте?
Тяжёлые операции рекомендуется запускать мимо тредпула с помощью опции
LongRunning.Просто есть три ступени развития программиста: до-ООП, ООП и после-ООП. И хотя для человека, который сам находится на средней ступени (ООП), код после-ООП может быть неотличим от кода до-ООП, реально они очень разные. А некоторые достигнув стадии после-ООП по привычке называют и считают свой код ООП, хотя это уже нечто иное.
Если как в Rust можно объявить интерфейс и тут же его реализовать для нужных типов — то да, вполне эквивалентно получается. К сожалению в том же C# так нельзя и реализация всех интерфейсов должна быть одном модуле с объявлением класса, что несколько ограничивает.
Я пробовал — уже сейчас наследование можно довольно неплохо эмулировать сочетанием
portraitи моегоdynamic-cast. Чуть-чуть многословно и есть трудности с изменением иерархии (так как каждый наследник должен перечислять всех предков при объявлении), но жить можно.Очень просто. Делается алгебраический тип данных и далее можно определять сколь угодно много точек с полиморфным поведением без всякой связи с объявлением самого типа.
Именно проблема ООП, которое позволяет и подталкивает к такому. В большинстве случаев наследование реализации вообще не нужно, но у ООП-программистов нет идиосинкразии к этому, а у кого есть — значит он уже начал расти за пределы привычного ООП-подхода.
Класс, интерфейс — неважно, проблема остаётся. Причём проблема элементарно решаемая средствами функционального программирования.