LINUX.ORG.RU

Замену C++ делают неправильно

 


0

3

Уже не первый год человечество пытается избавиться от переусложненности C++ и массы его исторического наследия со старыми костылями. Появляются полумертвые D, Rust. Почему бы не пойти более простым путем и просто форкнуть нынешний стандарт C++ ? Выпилить оттуда весь груз обратной совместимости, странности и неочевидности, и естественно, добавить улучшательств. Преимущества подхода: а). Программистам в целом не придется переучиваться, библиотеки тоже портировать легче. б). Готовые уже компиляторы, из которых понадобится в большей степени выпилить всякую хрень (можно даже сделать флаг типа --no-legacy-compat). Так где же оно?



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

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

D слишком другой, он сделан скорее с нуля под впечатлением от плюсов. Сборка мусора, достаточно отличий синтаксиса, вот это всё. Я же предлагаю взятьв лоб C++14/17 и, выкинув устаревшую дрянь, слегка подредактировать.

CatsCantFly
() автор топика

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

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

Ага. И получить c+d? Сборка мусора и прочее не случайно притащили в D, к тому же она там элементарно отключается. Вон в objective-C/Swift тоже не парятся с ручным освобождением памяти - это же ускоряет и упрощает разработку программ. Так что сборка мусора в D скорее плюс, чем минус. У D другой недостаток - это слабое community: тухлые биндинги к Qt, и т.п.

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

Вон в objective-C/Swift тоже не парятся с ручным освобождением памяти...

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

mashina ★★★★★
()

Есть такое мнение, что заюзать netfilter руками через ядро намного проще, чем осилить мануал по iptables. Лови параллели.

unt1tled ★★★★
()

просто форкнуть нынешний стандарт C++ ? Выпилить оттуда весь груз обратной совместимости, странности и неочевидности, и естественно, добавить улучшательств

Появляются полумертвые D

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

Сишный препроцессор, сильно урезать инклуды в пользу модулей, множественное наследование, старые enum, голую арифметику указателей без compile-time проверок, deprecate многих C-функций по умолчанию, struct, имеющие методы, C массивы и zero-terminated strings (только возможность конвертить в них значения стандартных классов для вызова C кода), ну и множество мелочей

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

Мне ничего, кроме тех, кто ими таки обмазывается

CatsCantFly
() автор топика

можно даже сделать флаг типа --no-legacy-compat

Ну так можно и не делать новый язык. Возьми clang или gcc и напиши плагин, который обрежет С++ до нужного тебе подмножества.

anonymous
()

Я же предлагаю

Чего предлагаешь, делай давай. Форкай, пили, пиарь, собирай единомышленников. Предлагателей и так достаточно.

unlog1c ★★★
()

можно даже сделать флаг типа --no-legacy-compat

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

tailgunner ★★★★★
()

начинай пилить, чо уж.

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

выкинуть [...] множественное наследование [...] struct, имеющие методы

Так, этого до проектирования языков не допускать.

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

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

Sahas ★★★★☆
()

Для C++ сейчас намного полезнее было бы иметь нормальный кроссплатформенный менеджер зависимостей. И нормальный кроссплатформенный билд-тул (более вменяемый, чем CMake).

eao197 ★★★★★
()

Замену C++ делают неправильно

так уже сделали правильно, qt называется.

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

множественное наследование

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

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

что, например, выкинуть?

Си, все что связанно с си. Си хороший язык, но совместимость с ним портит С++.

Dudraug ★★★★★
()

Еще один улучшатор выискался. Не надо ничего выпиливать! Само со временем окочурится, как new/delete.

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

Для C++ сейчас намного полезнее было бы иметь нормальный кроссплатформенный менеджер зависимостей. И нормальный кроссплатформенный билд-тул (более вменяемый, чем CMake).

...и штобы как в Rust %)

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

125...

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

Вот скажи, что тебе мешает не использовать всё переведенное выше? Зачем именно вырезать из компилятора?

Kroz ★★★★★
()

Напиши, как посоветовали, плагин, который «депрекейтит» все «легаси». Например M$ так сделало и очень сильно ругается на весь протухший сишный рантайм.

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

Система зависимостей для плюсов - фантастика, потому что плюсы - это не жапка, где у тебя стандартная уютненькая vm, куда можно натащить jar-ов и радоваться жизни. На Си/Си++ у тебя множество платформ, систем сборки, тулчейнов, специальных утилит и компиляторов, требуемых при сборке (nvcc, yacc, lex, ...). Тот же opencv собрать по-человечески уже небольшая проблемка.

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

Да, к той же мысли прихожу.

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

Угу. С MOC'ом который накладывает кучу ограничений на шаблоны и макросы. При всём том хорошем, что даёт Qt, замена из него никакая.

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

Ага, и без неё элементарно не работает стандартная библиотека D. И кому он такой нужен? Это как теоретизировать о том, что в плюсы можно притащить GC. Да, можно, но нет больных ублюдков, которые станут это делать.

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

GC даже для C есть: https://github.com/orangeduck/Cello

И, заметь, очень популярен. А зачем тебе работа со стандартной библиотекой с отключенным GC? GC имеет смысл отключать лишь на некоторых участках программы, и то, думаю, это такая редкость - просто ппц. Смысл в том, что разработка на си/си++ не только сложна, но и очень долга по времени. Людям нужна скорость разработки на уровне python/JavaScript, поэтому всякие Swift и выстреливают, думаю здесь даже не только язык важен, но и вливание в него бабок, приглашение на полную ставку крутых разрабов и т.п.

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

Обезьянки не осиливают XML, не получится.

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

Повторю выше сказанное:

1) Никто не заставляет это использовать.

2) К clang можно прикрутить плагин.

anonymous
()

Буду краток: мне концептуально нравится язык D, нравится что есть привязка к Qt5.

Но я очень огорчен уровнем поддержки этого языка в различных IDE и вообще уровнем адаптации в реальных проектах.

Всё еще надеюсь увидеть что именно D будет постепенно завоевывать популярность, а не всякие убогие свефты/шрасты/гоги...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от menangen

И, заметь, очень популярен

Где же он популярен, среди кого? А вообще забавно интересно, даже классы влепили туда - всё как хотел ТС.

Я считаю современный язык должен компилироваться в натив, JVM/CLI, JavaScript, LLVM-байткод... Очень неправильно что для покрытия этих платформ разные языки, будто не 21-й век.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Вообще этот Cello можно сравнить с Qt/MOC или Vala по принципу работы? Вот оно - всё для радости автора темы - расширяй языки но не заморачивайся с компиляторами и поддержкой архитектур.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от invy

Я вот сейчас не понял: вы решили меня просветить на счет той жопы с управлением зависимостями, которая есть сейчас в C++? Или объясняете причины этой жопы? Или пытаетесь сказать, что решение такой задачи в принципе не возможно?

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

Т.е. в рамках своего проекта можно решать проблемы зависимостей, например, через возможности VCS (git submodule, hg subrepos, svn:externals) и привычной для себя системы сборки. А вот поделиться с кем-нибудь результатами своей работы так, чтобы любой пользователь подключил твои исходники к себе буквально одним щелчком... Вот это уже аттракцион.

Впрочем, подвижки есть. biicode умер, но его авторы сейчас conan делают. Еще недавно на reddit-е ссылка на какой-то менеджер зависимостей новый проскакивала. Вроде как даже какие-то альтернативы CMake (вроде premake5) развиваются.

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

В смысле? Оно использует Qt либы, что логично, но собирать им можно что угодно. Там нет завязки на Qt, как у qmake, и на, C++ как у cmake.

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

anonymous
()

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

собственно, D — это попытка сделать, о чём вы говорите

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

Я же предлагаю взятьв лоб C++14/17

неплохо так предлагаете. откуда взять C++14/17 в 2006 году? (примерное появление D)

Сборка мусора

опциональная. кстати, опциональный gc нужен и плюсам

достаточно отличий синтаксиса,

мизерные, хотя и часто спорные нововведения

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

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

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

а что, разве С++ сам по себе это что-то правильное? :)))

Ну раз gcc перевели на него, так как минимум необходимое.

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

к тому же она там элементарно отключается

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

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

опциональная

«Don't want GC? No problem! You can use D with RAII or manual management style as well!» Though true, that's next to useless because there's little support in the standard library for alternative memory management styles (с)

например, устаревшая дрянь это дефайны. но чем их заменить?

Макросами, хотя бы такими как в Rust.

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

сильно урезать инклуды в пользу модулей

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

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