LINUX.ORG.RU
ФорумTalks

С++ 2018

 , ,


1

5

Не буду особо подводить итоги года, подведу лучше итоги C++ за 20 лет.

С тех пор как вышел стандарт C++98, утекло довольно много воды, поменялись мейнстримовые операционные системы, браузеры, базы данных, принципы и методы разработки ПО, и вообще, кто бы мог подумать что Microsoft станет одним из главных контрибьюторов в Open Source.

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

В связи с этим вопрос - когда уже закопают труп?

Перемещено jollheef из development

★★

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

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

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

Там координация нескольких систем была скорее. Рендеринг через DirectX, кодирование libavcodec+сопутствующее, наколеночная реализация RTP в C# и прочее.

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

Но я знаю что C# можно надрочить до уровня Си.

Чёт по ссылке не могут, может поможете светлому делу свержения С++ «задрочив» C# до С?

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

Еще раз, вся координация и тот же RTP это значит ты не вызовы прокидываешь, а руками перекладываешь и чекаешь байтики, прямо как в C++

Да, декодеры понятное дело это проблема уровня вызывать libavcodec. Но и то, менеджмент памяти использовался дотнетовский - т.е. byte[], которые там делаются fixed по необходимости итд.

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

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

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

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

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

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

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

Причем дохера оптимизированный не одним поколением лучших разработчиков

Которые все переписывают после своих предшественников. Знаю.

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

GC - течет. Новое веяние в Computer Science. Защищайте диссертацию в MIT, сударь.

Где я говорил про то, что GC - течёт?

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

Реальный код может упереться в производительность небольшого кусочка, который надо будет «задрачивать». Если по ссылкам для вас все задачи «синтетические», то что на счёт упомянутого вами перемножения матриц? Оно ведь встречается в реальном коде? Значит эта «дрочильня» уже не такая абстрактная? Может тогда на ней можно увидеть как C# можно «задрочить»?

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

.Net CLR Team - это реальные четкие парни. У них корни тянутся из лисперов. Там ЕМНИП самый главных до сих пор тот, кто еще в Texas Instruments на CL писал. Мощный чел. Посмотри код .Net Core, благо он опенсорс.

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

Перемножение матриц - синтетическая дрочильня. В реальном мире оно встречается в основном в шейдерах на видеокарте, С++ тут никоим боком вообще.

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

это реальные четкие парни

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

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

Давай определимся что такое утечка. С общераспространенной точки зрения утечка - это кусок недостижимой памяти, который даже если постараться - ну никак системе менеджмента памяти - не отдать назад. Частая история например с reference counting - утечка циклических графов (привет умные указатели). Поясни как такое может допустить GC?

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

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

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

Давай определимся что такое утечка.

Когда у тебя вроде всё нормально, а памяти сожрано немерено.

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

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)

Ждем нормальных концептов, чтобы реализовать все хотелки поехавшего Степанова, будет вообще конфетка!

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

«Обертку переписать» это просто было бы просто прямые вызовы заменить на интероп. Но я там и байтики перекладываю.

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

Проблема в том, что в С++ это пофиксить на порядок сложнее.

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

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

Но я там и байтики перекладываю.

Да молодец, молодец. На, съешь конфетку.

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

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

Мне конечно больше VS2017, но стал за собой замечать что все чаще пользуюсь code. Оригинальную VS еще дождись пока проект загрузит...

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

C#
swift

Не кроссплатформа. Ненужно.

java/kotlin

Не взлетел на десктопе.

бидон

Питон для прикладного софта? Ну ты точно наркоман.

RazrFalcon ★★★★★
()

Всё так. Только ты забыл ещё про комитет упомянуть, который уже лет 10 срётся из-за того, как же всё таки правильнее будет модули запилить.

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

В Qt полезным являются только виджеты. QtCore - это попытка очеловечить std, а все остальные модули следствие отсутствия ПМ для плюсов и в нормальном языке не нужны.

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

Вообще-то mono. C# есть на линуксе, маке, андроиде - вполне кроссплатформа. А на питоне уже понаписано дофигя прикладухи (и не только).

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

Вообще-то mono

Который несовместим с .Net? Ага, знаем.

C# есть на линуксе, маке, андроиде

Core - да. Всё остальное + 100500 либ - нет.

А на питоне уже понаписано дофигя прикладухи

CLI/TUI не считается.

RazrFalcon ★★★★★
()

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

Какие есть ещё альтернативы в 2018г., которые:

1) устоялись в индустрии (есть международный стандарт ЯП, основные баги в компиляторах исправлены, рынок рабочей силы достаточно большой);

2) позволяют писать код с оптимальной и более-менее предсказуемой производительностью;

3) позволяют разрабатывать как околосистемщину, так и ГУИ, без всяких полудохлых экспериментальных биндингов?

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

Mono много для чего нет.

Считать что Win + Mac + Linux - это кросплатформа это зашквар.

Например mono нет для NetBSD, DragonFlyBSD, OpenIndiana, Haiku...

(хотя во FreeBSD и OpenBSD моно есть, правда не совсем последних версий...)

P.P.S openjdk есть на этих ос где нет mono.

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

Дай попробую объяснить. Вот ты сказал, не библиотек. Нет, это не так.

В нашем маленьком(на самом деле нет) .Net мирке есть по сути две основные «запускалки» - .Net Framework(классика) и .Net Core

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

Так вот щас какую библиотеку в .Net экосистеме не возьми - они все под именно этот .Net Standard и делаются. Начиная с JSON.Net и заканчивая какими-нибудь приблудами для DI, MVC, итд.

Поэтому по большей части, для серверной части по крайней мере, оно все совместимо и inter-compatible.

А сейчас так переведут WPF и Windows.Forms под него так всё, считай. Ну WPF будет зависить от windows-only библиотек, конечно, но все-равно.

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

1) устоялись в индустрии

Помоему куда не глянь оно все устоялось.

2) позволяют писать код с оптимальной и более-менее предсказуемой производительностью;

Примерно каждая VM итд. Почитай JMM итд.

3) позволяют разрабатывать как околосистемщину, так и ГУИ, без всяких полудохлых экспериментальных биндингов?

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

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

Уже переводят. И в опенсорс даже. https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for...

Но будет Windows-only конечно. Переводить WPF на уродскую архитектуру иксов и ogl я бы не взялся ни за какие деньги.

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