Чего вам не хватает в языке программирования и в IDE?

хочу набрать побольше мнений программистов по двум вопросам:
1 Какие фичи стоит добавить в С++ (или в другие языки которыми вы пользуетесь)? (или, может быть, не добавить в существующий язык, а чтобы эти фичи были в новом языке программирования)
2 Какие фичи стоит добавить в IDE которой вы пользуетесь?
наверняка ведь у всех были подобные идеи и мысли

 

Всегда мечтал, чтобы компилятор сам код писал, а отладчик ошибки находил )

 

Ну это и так понятно))
А если серьезно?

 

VS 2005 в общем-то всем устраивает как IDE, кроме тормозов и глюков IntelliSence. Сильно не хвтает нормальной системы управления проектами и билдами (что-то типа метасолюшнов).

В Cишнике хотелось бы немного более расширенный язык макросов (например, чтобы можно было генерить случайные числа в компил-тайме)

ЗЫ: По большому счету, думаю, что С - оптимальный вариант языка программирования для негуевых и невебовых приложений

 

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

 

Читай опции - очень полезно.

#pragma comment(linker,"/ENTRY:SuperWinMain") - любая main + нет стартового кода.

 

1. Ключевое слово auto (оно сейчас есть, но толку от него ноль).
Вроде в новой версии Стандарта будет разрешён такой код:
auto iter = some_vector.begin();
Где тип переменной iter будет определён автоматически. Это будет очень полезная фича, которая заметно сократит и упростит код (при активном использовании STL)

2. Функционал boost, например, "умные" указатели (auto_ptr не в счёт - его область применения слишком узка). По крайней мере, shared_ptr почти наверняка появится в новой версии Стандарта.

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

4. Для MS: улучшить производительность стандартной библиотеки, особенно ввода-вывода и особенно потоков. В настоящий момент скорость ввода-вывода в потоках в десятки раз меньше потенциальной (мои потоки sin/sout, основанные на чистом WinAPI, в 80 раз быстрее стандартных!).

5. Для MS: сделать в RTL и STL такую опцию компилятора, чтобы компилировать их без поддержки исключений (сейчас, если выключить исключения, то компилятор разразится сотнями warning'ов). А то приходится прибегать к ручному редактированию файлов стандартной библиотеки.

6. Для MS: уменьшить зависимость компилятора от RTL. Сейчас, даже если ты абсолютно не используешь RTL, она всё равно полностью присоединяется к программе. Даже если опциями компилятора подавить подключение RTL, он всё равно пытается заменить мои функции на стандартные (например, my_memcpy на memcpy), что приводит к ошибкам линковки.

 

FreeManCPM
в msvc это всё итак есть, rtfm) по поводу его инлайн-асма - хочу чтоб там были какие-то нормальные директивы для для задания констант/переменных, ато уродливо смотрится, когда забиваешь какую-нибуь строку __emit-тами по одному байту =)

gilg
согласен насчёт макросов, чтоб было что-нибуть более продвинутое, чем простая макроподстановка =)

 

на первых порах в майкрософтовском C компилере убивало приведение к типам >

 

По поводу макросов в C++: это весьма нехорошая вещь, и использовать их надо только там, где они действительно нужны:
1) замена ключевых слов языка на свои выражения (некрасивый трюк, но в отладке и в некоторых других ситуациях почти незаменимый)
2) упрощение часто повторяющихся конструкций в объявлениях переменных и типов (типичный пример - макросы обработки сообщений в MFC, без них никуда)
(вроде больше ничего не забыл)
Во всех остальных случаях применения макросов лучше избегать. А в тех случаях, где они всё-таки необходимы, достаточно и тех возможностей, которые уже заложены в них сейчас. Очень часто макросы можно заменить шаблонами, которые гораздо более безопасные и контролируемые.

P.S. Хотя, добавление случайных переменных в язык макросов было бы полезно - в дополнение к __LINE__, __FILE__ и т.д.

P.P.S. Впрочем, в языке C альтернативы макросам нет, поэтому всё вышесказанное к нему не относится

 

Требуется eclipse работающий без тормозов на компах с 256Mb памяти (ну и функциональность чтобы не сильно урезанной была ). А то на открытом кубке в сибоссе он частенько на 2-3 минуты подвисает.

 

Главное что меня точно раздражает в VS2005 это то что все строки - константы и динамически их шифровать проблемно - только если пре-билдовый анализатор сделать.

 

Хочу чтоб диаграммы наследования строила и хочу функцию AutoCompleteCode

IDE - GIDE for windows

 

maxdiver
Про исключения и RTL - в VS все это без проблем выключается (если речь, конечно, о С; в плюсах не знаю). Ну а макросы вещь очччень удобная и хорошая, если они, конечно, правильно написаны. Опять же речь о С. В плюсах, вероятно, действительно нужно юзать шаблоны и хитрые тайп-касты. Тока писать больно много тогда нужно

[offtop] А кто-нибудь умудрился собрать на Сишных макросах криптор для строк с динамическим ключом? Мне в голову ничего разумнее перлового скрипта для этих целей в голову не пришло [/offtop]

 

gilg
Полюбому. На codeproject.com видел прогу для авто-инкремента билдов, этакий пре-билдовый анализатор который ищет что нужно и заменяет. Так же можно сделать и шифратор для строк, если есть время можем попробовать вместе.

 

im1111
Внешнюю программулину привесить не вопрос, а еще проще скрипт. Хотелось красиво А в таком случае проще пакер использовать

 

а вот мои пять копеек:

1. не существует способа явно задать порядок вычисления операндов в выражении
2. необходимо явно указывать типы аргументов при вызове функций с переменным числом параметров (например, printf)
3. нельзя передать стрктуру в качестве аргумента, не создав для этого временную переменную (кажется, в gcc есть такое расширение, но это не стандарт)
4. нельзя использовать рантаймовое число аргументов при вызове функции с переменным числом параметров (впрочем, для этого есть va_list)
5. в switch нельзя использовать continue (кстати, почему???)
6. не существует нормального способа для получения смещения поля структуры (кроме ((char*)(void*)(&((type*)NULL)->field)-(char*)NULL) ) - не спрашивайте, зачем это надо
7. goto, конечно, стиль плохой, но все равно хотелось бы видеть переменные типа label (так.. поизвращаться))
8. раздражает синтаксис определения указателя на функцию (или на метод) - нельзя определить сразу несколько указателей без typedef
9. нельзя определить по typedef'у саму функцию, задав только имена формальных параметров - приходится описывать всю функцию целиком, начиная с модификаторов и типа возвращаемого значения
10. +=, -=, *=, /= итд, конечно, штука полезная, но хотелось бы еще видеть конструкцию, которая была бы эквивалентна, например, выражению: var>=1 && var<100 && var!=7 && var%8, но при этом не требовала бы периодического повторения идентификатора var

 

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

5. А какова должна быть ф-ция continue в switch?
6. +1
7. +1! Безобразие, в C++ нельзя явно закодировать косвенный джамп!
8. +1. Это касается и массивов.
10. +=, -=, *=, /=, ... - это не просто синтакс. сахар, а отражение типичной архитектуры проца.

 

Хотелось бы иметь возможность строить новые енумы на базе существующих. Что-то типа наследования.

 

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

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

10. иногда хочется просто сахара ))
особенно в конструкциях вида:
if(lpConfig->DDSSynchronizationMode==1 || lpConfig->DDSSynchronizationMode==4 || lpConfig->DDSSynchronizationMode==7 || lpConfig->DDSSynchronizationMode>=9 && lpConfig->DDSSynchronizationMode<13)
а вместо этого хочется чего-то типа:
if(lpConfig->DDSSynchronizationMode: (==1 |||| ==4 || ==7 || >=9 && <13))

))
забавная идея! ))