хочу набрать побольше мнений программистов по двум вопросам: 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++: это весьма нехорошая вещь, и использовать их надо только там, где они действительно нужны: 1) замена ключевых слов языка на свои выражения (некрасивый трюк, но в отладке и в некоторых других ситуациях почти незаменимый) 2) упрощение часто повторяющихся конструкций в объявлениях переменных и типов (типичный пример - макросы обработки сообщений в MFC, без них никуда) (вроде больше ничего не забыл) Во всех остальных случаях применения макросов лучше избегать. А в тех случаях, где они всё-таки необходимы, достаточно и тех возможностей, которые уже заложены в них сейчас. Очень часто макросы можно заменить шаблонами, которые гораздо более безопасные и контролируемые. P.S. Хотя, добавление случайных переменных в язык макросов было бы полезно - в дополнение к __LINE__, __FILE__ и т.д. P.P.S. Впрочем, в языке C альтернативы макросам нет, поэтому всё вышесказанное к нему не относится
Требуется eclipse работающий без тормозов на компах с 256Mb памяти (ну и функциональность чтобы не сильно урезанной была ). А то на открытом кубке в сибоссе он частенько на 2-3 минуты подвисает.
Главное что меня точно раздражает в VS2005 это то что все строки - константы и динамически их шифровать проблемно - только если пре-билдовый анализатор сделать.
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)) )) забавная идея! ))
