[C++] Чего вам нехватает в языке?

Эм, единого для всех компиляторов способа доступа ко всем возможностям языка из С. Нечто вроде libtinycc++. Не нравится мне, что для привязывания плюсовых библиотек требуется столько сил. Но поскольку всё чаще стараюсь писать компонентами в стиле XPCOM или по DBus взаимодействующих, то и это не так важно в общем.
PS: использую C++ только тогда, когда приходится юзать чей-то код на нём написанный.

Лямбд. Человеческих.

> Лямбд. Человеческих.

тогда уж сразу замыканий. человеческо-лексических

1. Системы типов с алгебраическими типами данных, параметрическим полиморфизмом и классами типов.

2. Наличия только контролируемой перегрузки функций.

3. Отсутствия неявных преобразований типов.

4. Автоматического вывода типов.

5. Нормальной системы модулей.

6. Функций как объектов первого класса, и лексического замыкания их в контексте определения.

7. Отсутствия бардака с вызываемыми значениями (функции, функции-члены, фнукциональные объекты).

8. Гарантированной оптимизации оконечной рекурсии.

9. Сопоставления с образцом.

10. Сборщика мусора.

11. Ну и отложенные вычисления можно добавить.

Вот только это уже не С++ получается :-)

Честно говоря, мне больше не хватает возможностей C++ в JavaScript :)

12. зависимых типов

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

Вы случайно не фан Scala? Очень палевно. Если да, то +1

в русском языке не хватает правила, которое позволяло бы писать «не» с глаголами слитно

> Вы случайно не фан Scala?

Это мог быть и OCaml. Да и Haskell почти подходит.

>в русском языке не хватает правила, которое позволяло бы писать «не» с глаголами слитно

Ладно. Ладно. Уделал меня.

З.Ы. Хотя строго говоря неверно.

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

Haskell почти подходит

с учётом пункта 11 подходит, вообще говоря, только Haskell. во всяком случае - если требовать его из коробки

THIS LANGUAGE NEEDS MORE LESBIAN PARENTHESES.

> оконечной рекурсии.

такого варианта я еще не встречал...

Речь, вообще-то, шла о Haskell.

такого варианта я еще не встречал...

«Алгоритмы: построение и анализ», Кормен и др.

> «Алгоритмы: построение и анализ», Кормен и др.

ок, не буду это читать =)

во всяком случае перевод

http://habrahabr.ru/blogs/cpp/66021/

В этих лямбдах чего-то не хватает? Есть в последней VS и GCC 4.5.

мне скорее не «нехватает», а «мешает»: кривой синтаксис — в этой смеси ужа с ежом (процедурного С, ориентированного на системное программипрование, и некое подобие ООП) всё как будто держится вместе на соплях, пластелине и скотче =(… наличие препроцессора вместо родной системы алиасов и макросов сильно усложняет понимение и поддержку такого кода… написать систему рефакторинга кода без дополнительных ограничений при таком бардаке практически невозможно… система хэдеров — это ужас просто (не-не, о жабе и аде я ничего не говорил %)).

как человек постоянно на нем программирующий, единственное чего мне не хватает - когда он помрет...

> В этих лямбдах чего-то не хватает? Есть в последней VS и GCC 4.5.

да, нехватает вменяемого, понятного человекам синтаксиса

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

мне скорее не «нехватает», а «мешает»

В чём-то согласен. С++ явно бы не помешала тотальная чистка синтаксиса. Местами коду не хватает «прозрачности» и «интуитивной понятности».

Отсутствие «интуитивной понятности» порождает такое явление как «грабли».

>С++ явно бы не помешала тотальная чистка синтаксиса.

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

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

> как человек постоянно на нем программирующий,

единственное чего мне не хватает - когда он помрет..

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

И я не стал дожидаться, когда он «помрёт», а просто поменял задачи и поменял языки :)

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

Если бы С++ проектировался как-то централизованно

Так он изначально и проектировался централизованно - Страуструпом. И целый ряд костылей возник именно в достандартный период. С++ приобрёл такую популярность именно потому, что проектировался как «такое угробище».

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

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

> Мне кажется, что в современном языке программирования должен быть продуман процесс взаимодействия с IDE. Как именно не скажу, но на сегодняшний день IDE играет большую роль в удобстве написания программ. Возможно даже более важную роль чем сам язык. Было бы хорошо если бы код подвергался гарантированно корректному анализу со стороны IDE.

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

>1-11

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

для плюсов вопиющий пример недемократичности — реализация виртуальных функций — мы не можем ни оптимизировать ее, ни расширить (сделав множественную диспетчирезацию)

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

Ты сорвался:) -10 кармы тебе

> В чём-то согласен. С++ явно бы не помешала тотальная чистка синтаксиса. Местами коду не хватает «прозрачности» и «интуитивной понятности».

c++ нужна глубокая ресинтаксификация — даже сишный синтаксис содержит неудобства

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

Тут в первую очередь важно, что бы программы на языке было просто анализировать. Для С++ такой возможности нет, в IDE придётся встраивать полкомпилятора (может чуть помеьше :-)).

Не хватает нормального синтаксиса существующих операторов и конструкций.

В первую очередь не хватает нормальной семантики.

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

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

> 1. Системы типов с алгебраическими типами данных, параметрическим полиморфизмом и классами типов.

согласен

2. Наличия только контролируемой перегрузки функций.

А. подробнее? в описании D есть примеры багов языка (из-за перегрузки функций), решение — overload sets

В. разные правила перегрузки шаблонов и функций — это разве хорошо?

3. Отсутствия неявных преобразований типов.

они нужны (хотя бы иногда), или речь о продвижениях?

4. Автоматического вывода типов.

в основном локального вывода типов.

5. Нормальной системы модулей.

чем нейспейсы и статически члены-методы классов не устроили?

6. Функций как объектов первого класса, и лексического замыкания их в контексте определения.

согласен

7. Отсутствия бардака с вызываемыми значениями (функции, функции-члены, фнукциональные объекты).

а разве это можно сделать, сохранив C calling convention?

8. Гарантированной оптимизации оконечной рекурсии.

в gcc есть

9. Сопоставления с образцом.

согласен

10. Сборщика мусора.

согласен

11. Ну и отложенные вычисления можно добавить.

lazy как в D?

>5. Нормальной системы модулей.

чем нейспейсы и статически члены-методы классов не устроили?

Я так понял тут про убогость хедеров речь идет.

> 12. зависимых типов

согласен, но на практике больше нужны разные ослабленные варианты зависимых типов

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

13. *запрет* произвольных фич языка (для создания чего-то типа Ravenscar profile)

14. region inference

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

>14. region inference

15. Ну тогда ещё нужна возможность написания атомарных(по отношению к исключениям) кусков кода. Т.е. где не могут «ВНЕЗАПНО» выпрыгнуть исключения.

тогда уже 16

16. Ну тогда ещё нужна возможность написания атомарных(по отношению к исключениям) кусков кода. Т.е. где не могут «ВНЕЗАПНО» выпрыгнуть исключения.

17. статический вариант рефлексии

18. статический вариант Meta Object Protocol

19. возможность написать универсальный proxy для классов