Здравствуйте, B0FEE664, Вы писали:

BFE>>>Исходя из этого для многих проектов просто запрещается динамическая аллокация памяти.
CC>>С чего бы вдруг?
BFE>А вы доверили свою жизнь автопилоту с динамической аллокацией памяти?

Отказ автопилота — это штатная ситуация. К аварии она приводит, если авиакомпания экономит на обучении персонала, и пилоты не имеют навыка летать "на руках".

Здравствуйте, B0FEE664, Вы писали:

BFE>Я это написал к тому, что нет никакой динамически выделяемой памяти, а тогда вместо С++ получается С с классами.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>А вы доверили свою жизнь автопилоту с динамической аллокацией памяти?

Аллокация памяти — это просто инструмент. Аллоцировать можно большим количеством способов, в том числе избегая фрагментации и исчерпания памяти при любом развитии событий. То что ты в это не умеешь — не значит, что аллокация это какая-то МАГИЯ, которая мистическим образом может всё сломать.

BFE>Часть функционала оказывается неиспользуемой. Зачем, например, виртуальные функции, если нет динамически создаваемых объектов?

Ты прикинь, да?

Здравствуйте, so5team, Вы писали:

S>им видится и полэкрана кода, который ничего не делает, и, что еще важнее, проверки на каждом присваивании.

Тут и есть полэкрана кода. Там 12 строк, в стандартном экране их 24.

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

Строгие typedef'ы можно даже и в C сделать:

typedef struct {int v;} distance;
typedef struct {int v;} weigh;

Арифметику будет делать неудобно (но не сильно хуже шаблонного месива), но метры с килограммами уже случайно не сложишь.

Но мне больше нравится, как в Go:

type int distance
type int weigh

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

Здравствуйте, Pzz, Вы писали:

S>>им видится и полэкрана кода, который ничего не делает, и, что еще важнее, проверки на каждом присваивании.

Pzz>Тут и есть полэкрана кода. Там 12 строк, в стандартном экране их 24.

Типа должно быть убедительно?

Pzz>Строгие typedef'ы можно даже и в C сделать:

Pzz>

Pzz>typedef struct {int v;} distance;
Pzz>typedef struct {int v;} weigh;
Pzz>

Чем они строгие? Любой в v может записать все, что захочет.

Pzz>Арифметику будет делать неудобно (но не сильно хуже шаблонного месива)

Да где вы таких страшилок только набираетесь? В C++ у вас будет:

distance d1 = 1_m;
distance d2 = 100_cm;
distance d3 = d1 + d2;

Покажите в какой строке вы шаблонное месиво увидели.

Pzz>но метры с килограммами уже случайно не сложишь.

Вы их вообще забабахаетесь складывать.

Pzz>Но мне больше нравится, как в Go:
Pzz>

Pzz>type int distance
Pzz>type int weigh
Pzz>

Это в Pascal-е было за 30 лет до появления Go.

Ну и те, кто в C++ не застрял в 1988-ом, могли все это делать начиная с C++98. Т.е. еще лет за 10 до появления Go.

Здравствуйте, so5team, Вы писали:

BFE>>Ну раз нет динамического выделения памяти, значит нет виртуальных функций,
S>Каким боком динамическая память к виртуальным функциям?

А зачем вам виртуальные функции если у вас есть целый объект?

BFE>>контейнеров...
S>STL-ных не будет. А вот какие-нибудь small_vector/small_set/small_map которые используют буфер фиксированного размера или тот же std::array вполне себе.
S>Опять же, где именно шаблоны, лямбды или structured binding с if constexpr взаимоувязаны с динамической памятью?
Вопрос не только в динамической памяти, это просто пример. Всё гораздо сложнее.
Например, в std::array::at(size_type n ); есть ветка бросающая исключение. Если в коде нет ошибки, то эта ветка никогда не вызовется => нет 100% покрытие кода тестами => проверка кода провалена. Я же писал: бюрократия и особые требования.

Здравствуйте, B0FEE664, Вы писали:

BFE>>>Ну раз нет динамического выделения памяти, значит нет виртуальных функций,
S>>Каким боком динамическая память к виртуальным функциям?

BFE>А зачем вам виртуальные функции если у вас есть целый объект?

А каким боком виртуальность функций к целому или не целому объекту?

Есть ощущение, что вам матчасть нужно сперва подучить.

S>>Опять же, где именно шаблоны, лямбды или structured binding с if constexpr взаимоувязаны с динамической памятью?
BFE>Вопрос не только в динамической памяти, это просто пример. Всё гораздо сложнее.

Давайте разберемся с более простыми вещами: где именно шаблоны, лямбды или structured binding с if constexpr взаимоувязаны с динамической памятью?

BFE>Например, в std::array::at(size_type n ); есть ветка бросающая исключение. Если в коде нет ошибки, то эта ветка никогда не вызовется => нет 100% покрытие кода тестами => проверка кода провалена. Я же писал: бюрократия и особые требования.

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

Здравствуйте, B0FEE664, Вы писали:

_>>Глупости какие. Я например периодически пишу код для МК и использую там на полную удобства C++17 (скоро уже на 20 буду переползать). При этом там естественно нет динамического выделения памяти в принципе.
BFE>Ну раз нет динамического выделения памяти, значит нет виртуальных функций, смарт указателей, контейнеров...

Вот как раз понимание C++, как C с динамическим ООП — это и есть тот самый "C с классами" из 90-ых. С тех пор развитие языка ушло совершенно в другом направление.

BFE>Что именно от C++17 вы используете?

Относительно C или относительно старого C++? Да и в любом случае список будет слишком длинный, т.к. есть множество мелких удобств нового стандарта (ну типа того же структурного связывания), которые просто утомишься перечислять. Без них можно жить, но с ними намного красивее и короче код выходит.

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

И всё вышеописанное ортогонально вопросам динамической памяти.

Здравствуйте, Nikе, Вы писали:

BFE>>Я это написал к тому, что нет никакой динамически выделяемой памяти, а тогда вместо С++ получается С с классами.
N>Ты показал, что не умеешь применять инструмент там где он нужен и не применять там где он не нужен. Ты не в ладах с простой логикой. Ты не знаешь С++ на хоть сколько то серьёзном уровне.
N>Т.е. уровень как С++ разработчика хорошо если джуниорский. Тут вопрос скорее зачем в такой ситуации делаешь утверждения, а не задаёшь вопросы?

У меня 46 позиция в рейтинге С/С++ на этом сайте, а вас только 191-ая.

Здравствуйте, B0FEE664, Вы писали:

BFE>У меня 46 позиция в рейтинге С/С++ на этом сайте, а вас только 191-ая.

Зато я С++ знаю, а ты — нет.

Здравствуйте, Pzz, Вы писали:

Pzz>Арифметику будет делать неудобно (но не сильно хуже шаблонного месива), но метры с килограммами уже случайно не сложишь.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>А зачем вам виртуальные функции если у вас есть целый объект?
Их придумали, только чтобы тормозить выполнение в 100 раз, "Денис" не даст соврать!

Здравствуйте, so5team, Вы писали:

DI>>Для меня все это пустой звук.

S>Во-первых, врать нехорошо.

Вот и не ври:

S>Как минимум, вы читаете мой блог. А так же анонсы наших релизов на RSDN.

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

S>Во-вторых, суть не в громкости имен и известности разработок. Полагаю, что для большинства здесь присутствующих "Александр Сибиряков", "Scrapinghub" и "Frontera" не менее пустые звуки.

Ок.

S>Суть в том, что мне не страшно назвать ни свое реальное имя, ни место работы.

Ну мне твое имя ни о чем не говорит, можно поставить знак равенства с анонимусом.

DI>>Да вы просто ссыкло. (С)

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

Где-то я уже это слышал. Ах, да, у smeeld. Не смеши — были бы интересные кейсы использования ваших поделий непременно бы рассказали.

S>Вот вы о рисках, связанных с деловой репутацией, вряд ли задумываетесь, поскольку своим унылым троллингом и трусливым поведением уже создали Scrapinghub-у отрицательную карму.

А вдруг не я не имею отношения к Scrapinghub? Извинишься перед ними?

Здравствуйте, B0FEE664, Вы писали:

CC>>Это всё решается на уровне библиотек и требований к стилистике кода. Функционал языка же остаётся.
BFE>Часть функционала оказывается неиспользуемой. Зачем, например, виртуальные функции, если нет динамически создаваемых объектов?

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

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

Здравствуйте, Pzz, Вы писали:

BFE>>>>Исходя из этого для многих проектов просто запрещается динамическая аллокация памяти.
CC>>>С чего бы вдруг?
BFE>>А вы доверили свою жизнь автопилоту с динамической аллокацией памяти?

Pzz>Отказ автопилота — это штатная ситуация. К аварии она приводит, если авиакомпания экономит на обучении персонала, и пилоты не имеют навыка летать "на руках".

Это ответ на вопрос? Т.е. вам всё равно, есть в автопилоте динамическая аллокация памяти или нет?

Здравствуйте, Nikе, Вы писали:

BFE>>А вы доверили свою жизнь автопилоту с динамической аллокацией памяти?

N>Аллокация памяти — это просто инструмент. Аллоцировать можно большим количеством способов, в том числе избегая фрагментации и исчерпания памяти при любом развитии событий. То что ты в это не умеешь — не значит, что аллокация это какая-то МАГИЯ, которая мистическим образом может всё сломать.

Согласен.
А на вопрос вы ответите?

Здравствуйте, B0FEE664, Вы писали:

BFE>Согласен.
BFE>А на вопрос вы ответите?

Я ответил.

Здравствуйте, alex_public, Вы писали:

_>Ну а если говорить о крупных вещах, то я уже довольно давно не представляю себе современного кода без автоматического вывода типов
А! Ну, это прямо запрещено правилами: никаких целых без указания размерности. Т.е. не int, а int32_t; не char, а uint8_t ...

Здравствуйте, alex_public, Вы писали:

BFE>>Часть функционала оказывается неиспользуемой. Зачем, например, виртуальные функции, если нет динамически создаваемых объектов?
_>Хы, и что в этом страшного то? Ты же ничем не платишь за их наличие в языке, если не используешь их в своём коде.
Ничего страшного. Просто зачем? Как вы собираетесь использовать виртуальные функции?

_>Более того, я могу предположить, что не существует вообще ни одной программы, которая использовала бы вот прямо все все возможности C++.
Да я не об этом. Я о том, что требования к коду написаны так, что почти ничего из С++ использовать нельзя.

Здравствуйте, Pzz, Вы писали:

Pzz>>>Это, на самом деле, отзвук прозвучавшей здесь в другой нитке обсуждения мысли, что C++ — язык, пригодный для работы со сложными абстрактными данными. Не пригодный, как и C не пригодный.
_>>Нуу если C++ не пригодный, то мне тогда весьма интересно услышать какой пригодный и почему (желательно с конкретными примерами).
Pzz>Ну, первая версия компилятора rust была написана на ocaml'е, и неспроста...
Pzz>На самом деле, с этим беда. Нет мейнстримового языка, пригодного для таких задач. Возможно потому, что такие задачи относительно нечасто встречаются.

В такой постановке вопроса, я конечно же соглашусь. Более того, могу с уверенностью предположить, что никто из "сторонников C++" в данной темке не считает его идеальным языком и наверняка имеет огромный список претензий (по крайне мере у меня он есть) к комитету.

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

_>>Можно какой-нибудь конкретный пример подобного? Естественно это должна быть часть стандарта языка, а не какая-нибудь левая библиотечка, написанная студентом...
Pzz>Даже в статье есть примеры.
Pzz>На самом деле, то, что ты сказал, это еще один камень в огород C++. Ты неявно говоришь, что прикладной код могут и простые смертные писать, а стандартные контейнеры — это задача для небожителей. Почти любая часть стандартной библиотеки C или Go может быть написана обычным рядовым программистом, там нет никакой магии.

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

_>>Ну с этим то я естественно согласен. У меня вот только один вопрос остался: о дикой сложности программирования на C++ ты узнал из собственного опыта или по чужим рассказам? )
Pzz>В основном из собственного.

Странно. Ну да ладно, может почему-то личное тебе не пошло. Бывает...