LINUX.ORG.RU

Виртуальные деструкторы

 


0

3

Всем привет!

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

Такой код у меня корректно отработал

#include <iostream>

using namespace std;

class A
{
	public:
		A(int a) : a(a){cout<<a<<endl;}
		virtual ~A() =0;
		
	private:
		int a;
};
A::~A()
{
	cout<<"~A"<<endl;
}

class B : public A
{
	public:
		B(int b) : A(b-10), b(b){cout<<b<<endl;}
		virtual ~B(){cout<<"~B"<<endl;}
		
	private:
		int b;
};

class C : public B
{
	public:
		C(int c) : B(c-10),c(c){cout<<c<<endl;}
		virtual ~C(){cout<<"~C"<<endl;}
		
	private:
		int c;
};

int main()
{
	A* f=new C(30);
	delete f;
	C g(67);
	return 0;
}

★★

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

В С++ тоже невозможно, ибо их еще нет в стандарте.

Да ладно, в стандарте есть enable_if:

template<
    class T,
    class = typename enable_if<
        std::is_array<T>::value &&
        extent<T>::value < 256>::type>
void sort_small_array( T& a ) {
}

(is_arithmetic и is_signed лень было выписывать, но суть та же)

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

Но это не равноценный код, ибо длина массива фиксированная.

Тогда на расте будет:

extern crate num;
use num::{Num, Unsigned};

use std::fmt::Display;

fn sort_small_array<T: Num + Unsigned + Display>(a: &mut [T; 4]) {
    for n in a {
        print!("{} ", n);
    }
    println!("");
}

fn main() {
    sort_small_array(&mut [1u8,2u8,3u8,4u8]); // 1 2 3 4 

    // error: the trait bound `i32: num::Unsigned` is not satisfied
    // sort_small_array(&mut [1,2,3,4]);
    
    // note: expected type `&mut [_; 4]`
    // note:    found type `&mut [_; 5]`
    // sort_small_array(&mut [1,2,3,4,5]);
}

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

ибо длина массива фиксированная.

С х-я ли?

extent<T>::value < 256

Точно так же - любой массив с кол-во элементов до 256.

anonymous
()

виртуальный деструктор нужен только если ты собираешься делать delete именно такого типа указателя(т.е. class B : public A {}; B * b; delete b;) И при этом в данный delete может попасть производный класс(class C : public B {}). виртуальный деструктор нужен чтоб отстрелять деструкторы всех последующих(унаследованных) типов. а предки могут быть и «обычными»

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

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

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

Из необходимого нет даже инкапсуляции. Наследование просто никакое.

Наследование интерфейсов есть.

С инкапсуляцией более интересно - чего же там нет?

Для статического полиморфизма например.

Статический полиморфизм на интерфейсах?..

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

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

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

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

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

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

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

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

По-моему, в вашем вопросе заключено противоречие.

Где/почему?

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

Там нет ответа на мой вопрос - а именно какие от этого минусы имеются?

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

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

Где/почему?

Вот здесь как бы предполагается, что минусов нет (либо их мало):

Но разве отсутствие виртуального деструктора в классе, который имеет виртуальные функции, хоть какие-то минусы несёт?

А вот здесь:

Вроде, некоторые компиляторы даже умеют предупреждение выдавать про такие случаи.

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

-----

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

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

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

Наследование интерфейсов есть.

А наследования повеления нет, поэтому наследование это никакое.

С инкапсуляцией более интересно - чего же там нет?

Нет возможности явно сказать «такой-то класс объектов обладает таким-то поведением»; impl Trait for S не имеет спецификаторов доступа, функции в трейтах - тоже (само по себе это понятно). Вместе с отсутствием наследования поведения и данных это и свидетельствует о никакой поддержке ООП. А так, конечно, объектно-ориентированный код на Rust писать можно. Но его и на C можно писать.

Статический полиморфизм на интерфейсах?..

Ещё скажи, что в C++ интерфейсов нет вообще) eao197 выше писал про policy-based design и CRTP - вот это оно.

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

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

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

Вот здесь как бы предполагается, что минусов нет (либо их мало):

Да, мой фейл. Хотел написать «присутствие» вместо «отсутствие».

Соответственно, минус у такого решения есть и это большой минус.

Да, меня «наоборот» интересовало есть ли какие-то выгоды не делать деструктор виртуальным, если виртуальные функции уже есть.

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

А наследования повеления нет, поэтому наследование это никакое.

trait T {
    fn foo() {
        println!("foo");
    }
    
    fn bar();
}

struct S;

impl T for S {
    fn bar() {
        println!("bar");
    }

    // А поведение foo "наследуется".
}

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

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

Нет возможности явно сказать «такой-то класс объектов обладает таким-то поведением»;

Зато можно сказать «такой-то трейт обладает таким-то поведением» и «такой-то класс реализует трейт».

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

Ещё скажи, что в C++ интерфейсов нет вообще)

Это тут при чём?

Просто я под «интерфейсом», особенно в контексте разговора, понимал именно "(абстрактный) класс с виртуальными функциями предназначенный для наследования". Ну да ладно.

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

устоявшийся синтаксис языка

Устоялся. Или есть примеры обратного?

достаточное количество крупных проектов, написанных на языке.

Ну если бы все так рассуждали, то ни один новый язык не взлетел бы: замкнутый круг.

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

Зато можно сказать «такой-то трейт обладает таким-то поведением» и «такой-то класс реализует трейт».

В том то и дело, что можно сказать «вот вам реализация Trait для класса», а не «такой-то класс реализует такие-то трейты». Глядя на класс невозможно понять что это такое, пока не изучишь его реализацию. И в этой реализации будут намешаны как public трейты, так и private.

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

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

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

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

Это, в какой-то степени, справедливо и для плюсов. Ну видишь class A : public B и набор методов, но пока не посмотришь, то можешь только гадать, что там в B имеется и от чего он наследуется. Опять же, override ещё не везде поголовно используется, а без него по методам тоже сложнее предположения делать.

А ещё есть глобальные функции типа A operator+(const A&, const A&), которые не видны из «интерфейса класса». Ну и хитрые макросы, которые могут в функции разворачиваться.

В расте местами наоборот проще: есть набор экспортируемых сущностей из модуля: вот это и есть интерфейс (модуля).

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

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

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

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

Да я, в общем-то, не агитирую.

никто не рискнёт это тащить в коммерческую разработку.

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

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

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

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

Давай ты мне не будешь рассказывать что такое коммерческая разработка, ок? Ещё раз повторю: раст вполне себе используется, например, в дропбоксе. Ещё есть пример с D в фейсбуке и т.д. Или это уже не «коммерческая разработка»?

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

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

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

Ещё раз повторю: раст вполне себе используется, например, в дропбоксе.

Если вы о том, что писалось на hacker news, то использование свелось к переписыванию небольшого узкого места на Rust-е в большой кодовой базе на Go. И главной причиной, похоже, были хорошие отношения этой команды разработчиков из Dropbox-а с разработчиками Rust-а (последние даже регулярно захаживали в офис Dropbox-а, чтобы помогать разбираться с Rust-ом).

Ещё есть пример с D в фейсбуке и т.д. Или это уже не «коммерческая разработка»?

Ну в случае с D и фейсбуком не понятно. Известно, что на D переписали тамошний аналог lint-а для C++. Вроде как речи о том, что D в FB используется для продакшена, не было. Да и какова судьба этого lint-а после ухода Александреску так же не понятно.

Вот использование D в социоматике — это да, более интересный пример. Но и там не так все однозначно.

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

использование D в социоматике

социоматика

И такая наука существует?

D

Оно живое? полезное?

Или я отстал от жизни, или одно из двух.

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

В принципе, наверно тему уже можно в Talks-ы переносить....

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

И такая наука существует?

Речь о конторе, business-critical софт которой написан на D: https://www.sociomantic.com/

Оно живое? полезное?

Лично для меня нет. Но есть люди, которые с удовольствием пользуются.

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

то использование свелось к переписыванию небольшого узкого места на Rust-е в большой кодовой базе на Go.

Да, но какая разница? Продукт коммерческий? Да. Код на расте есть? Да.

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

Касательно «главной причины» у меня мнение тоже отличается: они сами говорили, что взяли бы С++, если бы была готовая инфраструктура. Боюсь, что в этом случае, не помогла бы и «дружба». Всё-таки мне кажется, что решение было довольно прагматичным.

Да и какова судьба этого lint-а после ухода Александреску так же не понятно.

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

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

Да, но какая разница? Продукт коммерческий? Да. Код на расте есть? Да.

Разница огромная. Вы же не будете утверждать, что подходы к разработке программного продукта в 10MLOC и командой в 100 человек будут сильно отличаться от подходов к разработке продукта в 5KLOC с командой из 2-х человек?

Полагаю, Iron_Bug именно об этом вам и пытается сказать. Что Rust пока еще не доказал свою пригодность к использованию в больших коллективах, работающих над большой кодовой базой.

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

Было бы странно, если бы в проекте, для которого Rust и создавался, было бы иначе. Только как раз из-за того, что у Mozilla-овских растоманов на зарплате нет другого выбора, кроме как пилить Servo, этот Servo хорошим примером и не является.

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

Разница огромная.

Не в контексте обсуждения.

Полагаю, Iron_Bug именно об этом вам и пытается сказать.

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

пока еще не доказал свою пригодность к использованию в больших коллективах, работающих над большой кодовой базой.

Вот только об этом не было сказано ни слова.

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

врети! плохой пример! мозилла похитила 500 человек из заставила писать на раст!

Будто кто-то ожидал от тебя чего-то другого.

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

Не в контексте обсуждения.

Вот тут не согласен.

Технические особенности языка в больших коллективах быстро становятся проблемами, которые приходится решать организационными и пр. мерами. Мы тут обсуждали C++, как раз с этим языком в больших командах непросто, т.к. в коллективе на 100 человек все не могут быть гуру. Следовательно, будет много народу, для которых C++ — это слишком мощная штука. И ее нужно ограничивать, путем введения чего-то вроде Google C++ Guidelines. Или чего похуже.

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

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

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

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

Странный аргумент. Что он должен означать? В большинстве «коммерческих проектов» у процентов этак 90 «людей на зарплате» есть ровно один выбор: уволиться. Как вариант - перейти в другой отдел/команду. Иначе как раз остаётся то и на том, что скажут.

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

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

Но тут другое интереснее. Представим гипотетическую ситуацию: есть проект написанный на языке Z. Какие из этого можно делать выводы? Как по мне - только о принципиальной возможности.

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

Странный аргумент. Что он должен означать?

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

Как по мне - только о принципиальной возможности.

Именно. А вот если у нас есть N проектов на языке Z, где N >> 100, да от разных команд, да из разных стран... То это уже не просто принципиальная возможность, а уже доказанная практикой.

Вообще слышали о такой штуке, как crossing the chasm?

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

Вот тут не согласен.

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

Например, запретят в конкретной конторе писать свои макросы.

И в чём проблема? По моему, наоборот хорошая идея. Развечто я бы «просто» требовал тщательного ревью опытными товарищами макросов и unsafe-блоков. Собственно, у нас (на плюсовом проекте) примерно так и сделано: есть гайдлайны, которые частично автоматически контролируются. С последним, как мне кажется, в расте должно быть даже проще. Банально из-за того, что «опасных сущностей» меньше: как раз макросы и unsafe.

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

И спорил с конкретным заявлением про «коммерческие проекты».

Так ведь Iron_Bug явно говорила про те коммерческие проекты, с которыми она имеет дело :) А они такие, масштабные :)

И в чём проблема?

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

Можно, конечно, и без исключений. Но не так удобно.

А ведь в Rust, как я понимаю, пока через макросы решают косяки языка. Те же try! или vector! — это же макросы. Вполне возможно, что для специфических предметных областей нужно будет наваять своих макросов, а они под запретом. И пойдут тонны копипасты...

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

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

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

Вообще слышали о такой штуке, как crossing the chasm?

Всё это я понимаю, но опять же, с чего всё началось: было сказано, что «коммерческий проект не будет использовать сырую технологию». И с этим я не согласен. Давай определимся: ты тоже так думаешь или нет?

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

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

Вот только если ты возьмёшь новый язык, то он вполне может дать (а может и не дать) тебе преимущество по сравнению с этими N проектами, что может быть очень важно, особенно, если у тебя меньше ресурсов.

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

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

Далее, далеко не факт, что со временем затраты на сопровождение проекта на новом языке не превысят затраты на проект на каком-то из старых языков.

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

Так что все это риски, которые тем выше, чем больше размер команды.

Тут можно на тот же Sociomantic с D посмотреть. В начале у них с D все было хорошо. А сейчас такая огромная база на D1 с кастомными доработками, что процесс ее перевода на D2 идет уже не первый год.

«коммерческий проект не будет использовать сырую технологию». И с этим я не согласен. Давай определимся: ты тоже так думаешь или нет?

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

Но в общем случае это утверждение не верно. Early adopters из того самого crossing the chasm это прекрасно демонстрируют.

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

Так ведь Iron_Bug явно говорила про...

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

Ну это как если бы в C++ взять и запретить исключения.

И что характерно, так нередко и делают.

На всякий случай, уточню, что меня исключения вполне устраивают.

И пойдут тонны копипасты...

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

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

А сейчас такая огромная база на D1 с кастомными доработками, что процесс ее перевода на D2 идет уже не первый год.

Что никак не доказывает, что на другом языке у них дела пошли бы лучше.

Касательно «рисков» повторюсь: я не спорю с тем, что «проверенные технологии» несут с собой немало преимуществ.

Но в общем случае это утверждение не верно.

Я рад, что мы друг друга поняли.

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

Что никак не доказывает, что на другом языке у них дела пошли бы лучше.

Ну, если взять такие языки, как Java, C# или C++, то перевод кодовой базы на новую версию языка там происходит сильно проще, чем в случае D1 и D2.

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

Я, наверное, не сумел донести свою мысль. Ограничения, которые могут быть наложены на язык программирования из-за невысокого профессионализма команды, могут сильно снизить эффективность команды. В принципе, это можно наблюдать с C++, где люди вынуждены отказываться от исключений и/или шаблонов. И пока не понятно, насколько будет снижаться эффективность от Rust-а когда Rust попадет в такие же дикие условия. Это еще один из факторов риска.

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

Ну, если взять такие языки, как Java, C# или C++, то перевод кодовой базы на новую версию языка там происходит сильно проще, чем в случае D1 и D2.

Полагаю, что это сильно зависит от кодовой базы.

Это еще один из факторов риска.

Возможно, спорить не буду. Просто мне тут наоборот преимущества раста видится. В том плане, что «опасные» места легче локализовать и держать под контролем из-за чего их не придётся безоговорочно запрещать.

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

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

Полагаю, что это сильно зависит от кодовой базы.

Думаю, что вы не сильно в курсе эволюции D и различий между D1 и D2.

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

Думаю, что вы не сильно в курсе эволюции D и различий между D1 и D2.

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

С другой стороны, я знаю несколько примеров когда проекты на С++ обновлялись с большим трудом. Правда в этом не только язык «виноват» был.

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